Date   

ACRN Project Technical Community Meeting Minutes - 2/20/2019

Wang, Hongbo
 

 
ACRN Project TCM - 20th February 2019
Location
Agenda
 
  1. ACRN project update
 
  1. CHEN, Jason: ACRN Debug Tool and Tips
Download foil from ACRN Presentation->ACRN_TCM->WW08’19
 
3. All: Community open discussion.
 
4. Next meeting agenda proposal:
 
WW Topic Presenter Status
WW02 TPM2.0 virtualization in ACRN DENG, Wei 1/9
WW03 Polling mode Virtio and its advantage for RT VM DENG, Jie 1/16
WW04 Buffer sharing from UOS to SOS, HyperDMA usage LIU, Xinyun 1/23
WW05 USB HUB Virtualization WU, Xiaoguang 1/30
WW07 ACRN Device Model QoS Design LIU, Long 2/13
WW08 ACRN Debug Tips CHEN, Jason 2/20
WW09 GVT-g debug trace tool GONG, Zhipeng
WW10 Kata Container Introduction Dhanraj, Vijay
WW11 Power button key mediator design in ACRN Wang, Yu
WW12 TBD
WW13 I2C Virtualization Wang, Yu
WW14 TBD ZHU, Bing
 
Marketing/Events
  1. TBD
Resources
  1. Project URL:
  1. Portal: https://projectacrn.org   
  2. Source code: https://github.com/projectacrn   
  3. email: info@...g
  4. Technical Mailing list: acrn-dev@...g
  1. Recommended Hardware platform (reference):
  1. Apollo Lake (SoC) UP2 (with serial port): AAEON UPS-APLC2-A10-0232
  2. Apollo Lake (SoC) NUC (without serial port): NUC6CAYHL (at least 8G memory)
  3. Kabylake (Core) NUC (with serial port): NUC7i5BNH
 
================================
 
 
 
Best regards.
Hongbo
Tel: +86-21-6116 7445
MP: +86-1364 1793 689
 


[Announce] ACRN ver0.6 Release Notes

Wang, Hongbo
 

Hi all,

 

We are pleased to announce version 0.6 release of ACRN. You can see the Release Notes in the website https://projectacrn.github.io/latest/release_notes.html.

 

To learn more about ACRN: ACRN is a flexible, lightweight reference hypervisor, built with real-time and safety-criticality in mind, optimized to streamline embedded development through an open source platform. Check out the ACRN project portal (https://projectacrn.org/) for more information.

 

 

 

 

Best regards.

Hongbo

Tel: +86-21-6116 7445

MP: +86-1364 1793 689

Mail: hongbo.wang@...

 


Re: RAM configuration

Wang, Hongbo
 

Hi Tim,
For "NUC splash screen" issue, can you submit a bug and attach log? We'll follow up to try to fix the bug.


Best regards.
Hongbo
Tel: +86-21-6116 7445
MP: +86-1364 1793 689
Mail: hongbo.wang@...

-----Original Message-----
From: acrn-users@... [mailto:acrn-users@...]
On Behalf Of Tim Orling
Sent: Tuesday, February 19, 2019 2:12 PM
To: acrn-users@...
Cc: Dong, Eddie <eddie.dong@...>
Subject: Re: [acrn-users] RAM configuration



On Feb 14, 2019, at 5:44 PM, Eddie Dong <eddie.dong@...> wrote:

Hi Ross:
This is a tradeoff between flexibility and functionality certification. In server
virtualization, YES, we want one binary for all platforms with flexible
configuration at run time -- this is a must to have features. But, in IOT, usually the
image is released with particular platform with particular usage, and people
usually build the image per the product. The more important thing is functional
safety certification (FuSa) & real time requirement, which is the fundamental
feature of ACRN. FuSa requires it to not use dynamic allocation policy to avoid
the potential possible failure of allocation -- this is why ACRN is removing all of
the "malloc" like code, and this is why we must pre-identify the size of buffer
used in the VMM. For this purpose, we need to know the MAX RAM size at
compile time to statically allocate memory for EPT for example.

The fact that a KBL NUC 32GB system will simply hang at the EFI shell or the Intel
NUC splash screen is really undesirable for our customers. We need to find a way
to handle this gracefully. It is acceptable to have a strict configuration (for FuSA
requirements). It is not acceptable to simply hang with no feedback to the user.

Regards,

—Tim

There are other considerations in ACRN for Real time usage too. This is why
we tradeoff between the flexibility and the FuSa/RT.

Thx Eddie


-----Original Message-----
From: acrn-users@...
[mailto:acrn-users@...] On Behalf Of Ross Burton
Sent: Friday, February 15, 2019 9:07 AM
To: acrn-users@...
Subject: [acrn-users] RAM configuration

Why does ACRN need to be told how much RAM the system has? Surely it
can probe PLATFORM_RAM_SIZE? Then maybe default SOS_RAM_SIZE to 0
(meaning 'all of the RAM') and so on.

Ross





Re: RAM configuration

timothy.t.orling@...
 

On Feb 14, 2019, at 5:44 PM, Eddie Dong <eddie.dong@...> wrote:

Hi Ross:
This is a tradeoff between flexibility and functionality certification. In server virtualization, YES, we want one binary for all platforms with flexible configuration at run time -- this is a must to have features. But, in IOT, usually the image is released with particular platform with particular usage, and people usually build the image per the product. The more important thing is functional safety certification (FuSa) & real time requirement, which is the fundamental feature of ACRN. FuSa requires it to not use dynamic allocation policy to avoid the potential possible failure of allocation -- this is why ACRN is removing all of the "malloc" like code, and this is why we must pre-identify the size of buffer used in the VMM. For this purpose, we need to know the MAX RAM size at compile time to statically allocate memory for EPT for example.
The fact that a KBL NUC 32GB system will simply hang at the EFI shell or the Intel NUC splash screen is really undesirable for our customers. We need to find a way to handle this gracefully. It is acceptable to have a strict configuration (for FuSA requirements). It is not acceptable to simply hang with no feedback to the user.

Regards,

—Tim

There are other considerations in ACRN for Real time usage too. This is why we tradeoff between the flexibility and the FuSa/RT.

Thx Eddie


-----Original Message-----
From: acrn-users@...
[mailto:acrn-users@...] On Behalf Of Ross Burton
Sent: Friday, February 15, 2019 9:07 AM
To: acrn-users@...
Subject: [acrn-users] RAM configuration

Why does ACRN need to be told how much RAM the system has? Surely it
can probe PLATFORM_RAM_SIZE? Then maybe default SOS_RAM_SIZE to 0
(meaning 'all of the RAM') and so on.

Ross




Re: RAM configuration

Eddie Dong
 

Hi Ross:
This is a tradeoff between flexibility and functionality certification. In server virtualization, YES, we want one binary for all platforms with flexible configuration at run time -- this is a must to have features. But, in IOT, usually the image is released with particular platform with particular usage, and people usually build the image per the product. The more important thing is functional safety certification (FuSa) & real time requirement, which is the fundamental feature of ACRN. FuSa requires it to not use dynamic allocation policy to avoid the potential possible failure of allocation -- this is why ACRN is removing all of the "malloc" like code, and this is why we must pre-identify the size of buffer used in the VMM. For this purpose, we need to know the MAX RAM size at compile time to statically allocate memory for EPT for example.
There are other considerations in ACRN for Real time usage too. This is why we tradeoff between the flexibility and the FuSa/RT.

Thx Eddie

-----Original Message-----
From: acrn-users@...
[mailto:acrn-users@...] On Behalf Of Ross Burton
Sent: Friday, February 15, 2019 9:07 AM
To: acrn-users@...
Subject: [acrn-users] RAM configuration

Why does ACRN need to be told how much RAM the system has? Surely it
can probe PLATFORM_RAM_SIZE? Then maybe default SOS_RAM_SIZE to 0
(meaning 'all of the RAM') and so on.

Ross


RAM configuration

Ross Burton <ross.burton@...>
 

Why does ACRN need to be told how much RAM the system has? Surely it
can probe PLATFORM_RAM_SIZE? Then maybe default SOS_RAM_SIZE to 0
(meaning 'all of the RAM') and so on.

Ross


ACRN Project Technical Community Meeting Minutes - 2/13/2019

Wang, Hongbo
 

 
ACRN Project TCM - 13th February 2019
Location
Agenda
 
  1. ACRN project update
 
  1. LIU, Long: QoS Design In ACRN
Download foil from ACRN Presentation->ACRN_TCM->WW07’19
 
Q1: What’s the color code for the “ACRN Device-Model QoS Architecture” page?
Q2: What’s the difference of Cgroup QoS management and Kata Container QoS management for ACRN?
A2: Cgroup QoS is only used for ACRN device-model to control UOS devices resource.            Kata Container QoS management is a part of Kata container, when you enable container in ACRN I think the it’s no need for Cgroup QoS
Q3: Can we pin the vCPU to UOS?
A3:  By current ACRN hypervisor design, the vCPU will be pin to pCPU, and do not support CPU sharing so far. That is means once the pCPU assigned to specific UOS, then it can't be shared with other VMs.
Q4: What’s the current implementation of ACRN DM QoS?
A4: Right now there was no QoS feature for ACRN DM, we will commit the QoS patch this week.
Q5: Can we explain the SOS vCPU bandwidth quota?
A5: This example is SOS CPU bandwidth. Right now in ACRN there only one CPU for SOS. So all  SOS’s process run in the CPU.
We setup two  Cgroups subdirectory for two UOS and set UOS1 CPU quota value is 30000us(30ms) and period value is 100000us(100ms), set UOS2 CPU quota value is 50000us(50ms) period value is 100000us(100ms)
That means in every 100000us(100ms) time slice UOS1 will run 30000us(30ms) and UOS2 will run 50000us(50ms).

3. All: Community open discussion.
4. Next meeting agenda proposal:
 
WW Topic Presenter Status
WW02 TPM2.0 virtualization in ACRN DENG, Wei 1/9
WW03 Polling mode Virtio and its advantage for RT VM DENG, Jie 1/16
WW04 Buffer sharing from UOS to SOS, HyperDMA usage LIU, Xinyun 1/23
WW05 USB HUB Virtualization WU, Xiaoguang 1/30
WW07 ACRN Device Model QoS Design LIU, Long Today
WW08 ACRN Debug Tips CHEN, Jason
WW09
WW10
WW11 Power button key mediator design in ACRN Wang, Yu
WW12
WW13 I2C Virtualization Wang, Yu
WW14 Security related topics ZHU, Bing
 
Marketing/Events
  1. TBD
Resources
  1. Project URL:
  1. Portal: https://projectacrn.org   
  2. Source code: https://github.com/projectacrn   
  3. email: info@...g
  4. Technical Mailing list: acrn-dev@...g
  1. Recommended Hardware platform (reference):
  1. Apollo Lake (SoC) UP2 (with serial port): AAEON UPS-APLC2-A10-0232
  2. Apollo Lake (SoC) NUC (without serial port): NUC6CAYHL (at least 8G memory)
  3. Kabylake (Core) NUC (with serial port): NUC7i5BNH
 
 
 
Best regards.
Hongbo
Tel: +86-21-6116 7445
MP: +86-1364 1793 689
 


Re: UOS kernel

Geoffroy Van Cutsem
 

-----Original Message-----
From: acrn-users@... [mailto:acrn-
users@...] On Behalf Of Ross Burton
Sent: Thursday, February 14, 2019 12:55 AM
To: acrn-users@...
Subject: Re: [acrn-users] UOS kernel

That's good to know. Our 'standard' kernel is linux-intel-lts so it will have all the
acrn-kernel patches in already, we just need to make sure they're enabled.
So that may not turn out to be too hard to do then, good! :)

Geoffroy


Ross

On Wed, 13 Feb 2019 at 23:41, Geoffroy Van Cutsem
<geoffroy.vancutsem@...> wrote:

I had started looking into this a bit since I knew the engineering was mostly
out on holiday last week, the quick summary is that there are at least a number
of virtio FE drivers that are not upstream (yet): RPMB, HECI, Audio, IPU, TSN,
HyperDMA buffer, HDCP and COREU (see [1]). You may not need all of them but
I suspect you'll want at least a few. I think this is pretty much it for the User OS
kernel but I will let the engineering confirm that.

Geoffroy

[1]
https://projectacrn.github.io/latest/developer-guides/hld/hld-virtio-d
evices.html#virtio-device-table


-----Original Message-----
From: acrn-users@... [mailto:acrn-
users@...] On Behalf Of Ross Burton
Sent: Wednesday, February 13, 2019 10:52 PM
To: acrn-users@...
Subject: Re: [acrn-users] UOS kernel

Hit send way too early. Obviously virtio and friends need to be
enabled. Is any *KVM guest enabled* kernel suitable, or are there
further guest improvements in the acrn-kernel tree?

Ross

On Wed, 13 Feb 2019 at 21:50, Burton, Ross <ross.burton@...>
wrote:

Hi,

Obviously the SOS needs the acrn patches (which I'm obtaining via
linux-intel-lts) but are there any UOS-specific patches in that
kernel tree too? Does any modern kernel work as well, or are
there patches and/or kconfig options that improve the guest
performance?

Thanks,
Ross



Re: UOS kernel

Ross Burton <ross.burton@...>
 

That's good to know. Our 'standard' kernel is linux-intel-lts so it
will have all the acrn-kernel patches in already, we just need to make
sure they're enabled.

Ross

On Wed, 13 Feb 2019 at 23:41, Geoffroy Van Cutsem
<geoffroy.vancutsem@...> wrote:

I had started looking into this a bit since I knew the engineering was mostly out on holiday last week, the quick summary is that there are at least a number of virtio FE drivers that are not upstream (yet): RPMB, HECI, Audio, IPU, TSN, HyperDMA buffer, HDCP and COREU (see [1]). You may not need all of them but I suspect you'll want at least a few. I think this is pretty much it for the User OS kernel but I will let the engineering confirm that.

Geoffroy

[1] https://projectacrn.github.io/latest/developer-guides/hld/hld-virtio-devices.html#virtio-device-table


-----Original Message-----
From: acrn-users@... [mailto:acrn-
users@...] On Behalf Of Ross Burton
Sent: Wednesday, February 13, 2019 10:52 PM
To: acrn-users@...
Subject: Re: [acrn-users] UOS kernel

Hit send way too early. Obviously virtio and friends need to be enabled. Is any
*KVM guest enabled* kernel suitable, or are there further guest improvements
in the acrn-kernel tree?

Ross

On Wed, 13 Feb 2019 at 21:50, Burton, Ross <ross.burton@...> wrote:

Hi,

Obviously the SOS needs the acrn patches (which I'm obtaining via
linux-intel-lts) but are there any UOS-specific patches in that kernel
tree too? Does any modern kernel work as well, or are there patches
and/or kconfig options that improve the guest performance?

Thanks,
Ross



Re: UOS kernel

Ross Burton <ross.burton@...>
 

On Wed, 13 Feb 2019 at 23:52, Tzeng, Tonny <tonny.tzeng@...> wrote:
You can reference tons of patches in the Clear Linux package repo [1], if you want to build the SOS from the upstream kernel, instead of using the acrn-kernel tree. Alternative is to use the Clear Linux developer tooling framework [2] to rebuild the SOS. FYI.

[1] https://github.com/clearlinux-pkgs/linux-iot-lts2018
[2] https://github.com/clearlinux/common
linux-iot-lts2018 is Intel Production Kernel with two Clear-specific
patches on top. We already build the Production Kernel for our IA
BSP, so I'm just using a custom defconfig.

Ross


Re: UOS kernel

Tzeng, Tonny <tonny.tzeng@...>
 

Hi Ross,

You can reference tons of patches in the Clear Linux package repo [1], if you want to build the SOS from the upstream kernel, instead of using the acrn-kernel tree. Alternative is to use the Clear Linux developer tooling framework [2] to rebuild the SOS. FYI.

[1] https://github.com/clearlinux-pkgs/linux-iot-lts2018
[2] https://github.com/clearlinux/common

Regards,
Tonny

-----Original Message-----
From: acrn-users@... [mailto:acrn-users@...] On Behalf Of Ross Burton
Sent: Thursday, February 14, 2019 5:52 AM
To: acrn-users@...
Subject: Re: [acrn-users] UOS kernel

Hit send way too early. Obviously virtio and friends need to be enabled. Is any *KVM guest enabled* kernel suitable, or are there further guest improvements in the acrn-kernel tree?

Ross

On Wed, 13 Feb 2019 at 21:50, Burton, Ross <ross.burton@...> wrote:

Hi,

Obviously the SOS needs the acrn patches (which I'm obtaining via
linux-intel-lts) but are there any UOS-specific patches in that kernel
tree too? Does any modern kernel work as well, or are there patches
and/or kconfig options that improve the guest performance?

Thanks,
Ross


Re: UOS kernel

Geoffroy Van Cutsem
 

I had started looking into this a bit since I knew the engineering was mostly out on holiday last week, the quick summary is that there are at least a number of virtio FE drivers that are not upstream (yet): RPMB, HECI, Audio, IPU, TSN, HyperDMA buffer, HDCP and COREU (see [1]). You may not need all of them but I suspect you'll want at least a few. I think this is pretty much it for the User OS kernel but I will let the engineering confirm that.

Geoffroy

[1] https://projectacrn.github.io/latest/developer-guides/hld/hld-virtio-devices.html#virtio-device-table

-----Original Message-----
From: acrn-users@... [mailto:acrn-
users@...] On Behalf Of Ross Burton
Sent: Wednesday, February 13, 2019 10:52 PM
To: acrn-users@...
Subject: Re: [acrn-users] UOS kernel

Hit send way too early. Obviously virtio and friends need to be enabled. Is any
*KVM guest enabled* kernel suitable, or are there further guest improvements
in the acrn-kernel tree?

Ross

On Wed, 13 Feb 2019 at 21:50, Burton, Ross <ross.burton@...> wrote:

Hi,

Obviously the SOS needs the acrn patches (which I'm obtaining via
linux-intel-lts) but are there any UOS-specific patches in that kernel
tree too? Does any modern kernel work as well, or are there patches
and/or kconfig options that improve the guest performance?

Thanks,
Ross


Re: UOS kernel

Ross Burton <ross.burton@...>
 

Hit send way too early. Obviously virtio and friends need to be
enabled. Is any *KVM guest enabled* kernel suitable, or are there
further guest improvements in the acrn-kernel tree?

Ross

On Wed, 13 Feb 2019 at 21:50, Burton, Ross <ross.burton@...> wrote:

Hi,

Obviously the SOS needs the acrn patches (which I'm obtaining via
linux-intel-lts) but are there any UOS-specific patches in that kernel
tree too? Does any modern kernel work as well, or are there patches
and/or kconfig options that improve the guest performance?

Thanks,
Ross


UOS kernel

Ross Burton <ross.burton@...>
 

Hi,

Obviously the SOS needs the acrn patches (which I'm obtaining via
linux-intel-lts) but are there any UOS-specific patches in that kernel
tree too? Does any modern kernel work as well, or are there patches
and/or kconfig options that improve the guest performance?

Thanks,
Ross


Re: Networking from UOS

Wang, Hongbo
 

Thanks!
Our ACRN team will follow up to check if any improvement needed.


Best regards.
Hongbo
Tel: +86-21-6116 7445
MP: +86-1364 1793 689
Mail: hongbo.wang@...

-----Original Message-----
From: acrn-users@... [mailto:acrn-users@...]
On Behalf Of Geoffroy Van Cutsem
Sent: Tuesday, February 5, 2019 9:03 PM
To: acrn-users@...
Subject: Re: [acrn-users] Networking from UOS

Great stuff - thanks for the update Ross!

-----Original Message-----
From: acrn-users@... [mailto:acrn-
users@...] On Behalf Of Ross Burton
Sent: Tuesday, February 5, 2019 12:31 PM
To: acrn-users@...
Subject: Re: [acrn-users] Networking from UOS

Fixed: a combination of using the right TAP name and ensuring the
guest had the right kernel modules: the Clear KVM image doesn't ship
the IOT kernel modules, and I missed the bit of the getting started
guide where they're copied into the image.

Ross

On Mon, 4 Feb 2019 at 21:16, Geoffroy Van Cutsem
<geoffroy.vancutsem@...> wrote:

On Mon, Feb 4, 2019 at 09:59 PM, Geoffroy Van Cutsem wrote:

I had missed that in your original email, but I think the correct
parameter to
be given to acrn-dm is "-s 4,virtio-net,tap0" (so drop the "acrn_"
part from the tap name).

Confirmed, acrn-dm will automatically add "acrn_" to the tap name
you give it - see
https://github.com/projectacrn/acrn-hypervisor/blob/master/devicemod
el
/hw/pci/virtio/virtio_net.c#L667


Re: Networking from UOS

Geoffroy Van Cutsem
 

Great stuff - thanks for the update Ross!

-----Original Message-----
From: acrn-users@... [mailto:acrn-
users@...] On Behalf Of Ross Burton
Sent: Tuesday, February 5, 2019 12:31 PM
To: acrn-users@...
Subject: Re: [acrn-users] Networking from UOS

Fixed: a combination of using the right TAP name and ensuring the guest had
the right kernel modules: the Clear KVM image doesn't ship the IOT kernel
modules, and I missed the bit of the getting started guide where they're copied
into the image.

Ross

On Mon, 4 Feb 2019 at 21:16, Geoffroy Van Cutsem
<geoffroy.vancutsem@...> wrote:

On Mon, Feb 4, 2019 at 09:59 PM, Geoffroy Van Cutsem wrote:

I had missed that in your original email, but I think the correct parameter to
be given to acrn-dm is "-s 4,virtio-net,tap0" (so drop the "acrn_" part from the
tap name).

Confirmed, acrn-dm will automatically add "acrn_" to the tap name you
give it - see
https://github.com/projectacrn/acrn-hypervisor/blob/master/devicemodel
/hw/pci/virtio/virtio_net.c#L667


Re: Networking from UOS

Ross Burton <ross.burton@...>
 

Fixed: a combination of using the right TAP name and ensuring the
guest had the right kernel modules: the Clear KVM image doesn't ship
the IOT kernel modules, and I missed the bit of the getting started
guide where they're copied into the image.

Ross

On Mon, 4 Feb 2019 at 21:16, Geoffroy Van Cutsem
<geoffroy.vancutsem@...> wrote:

On Mon, Feb 4, 2019 at 09:59 PM, Geoffroy Van Cutsem wrote:

I had missed that in your original email, but I think the correct parameter to be given to acrn-dm is "-s 4,virtio-net,tap0" (so drop the "acrn_" part from the tap name).

Confirmed, acrn-dm will automatically add "acrn_" to the tap name you give it - see https://github.com/projectacrn/acrn-hypervisor/blob/master/devicemodel/hw/pci/virtio/virtio_net.c#L667


Re: Networking from UOS

Eddie Dong
 

This week is CNY holiday, and almost entire team are in holidays.. Thanks Ross & Geoff!

-----Original Message-----
From: acrn-users@...
[mailto:acrn-users@...] On Behalf Of Ross Burton
Sent: Tuesday, February 5, 2019 5:34 AM
To: acrn-users@...
Subject: Re: [acrn-users] Networking from UOS

On Mon, 4 Feb 2019 at 21:31, Geoffroy Van Cutsem
<geoffroy.vancutsem@...> wrote:
Confirmed, acrn-dm will automatically add "acrn_" to the tap name
you give it - see
https://github.com/projectacrn/acrn-hypervisor/blob/master/devicem
odel
/hw/pci/virtio/virtio_net.c#L667
That seems... unobvious.
No disagreement here. I don't actually recall if that was discussed and if
there were any reason for doing it this way. Hopefully, someone from the
engineering team can enlighten us.

I'd advocate for principle of least surprise: if the user says the virtio tap
device is called tap24, look for a device called tap24...

Ross


Re: Networking from UOS

Ross Burton <ross.burton@...>
 

On Mon, 4 Feb 2019 at 21:31, Geoffroy Van Cutsem
<geoffroy.vancutsem@...> wrote:
Confirmed, acrn-dm will automatically add "acrn_" to the tap name you
give it - see
https://github.com/projectacrn/acrn-hypervisor/blob/master/devicemodel
/hw/pci/virtio/virtio_net.c#L667
That seems... unobvious.
No disagreement here. I don't actually recall if that was discussed and if there were any reason for doing it this way. Hopefully, someone from the engineering team can enlighten us.
I'd advocate for principle of least surprise: if the user says the
virtio tap device is called tap24, look for a device called tap24...

Ross


Re: Networking from UOS

Geoffroy Van Cutsem
 

-----Original Message-----
From: acrn-users@... [mailto:acrn-
users@...] On Behalf Of Ross Burton
Sent: Monday, February 4, 2019 10:21 PM
To: acrn-users@...
Subject: Re: [acrn-users] Networking from UOS

On Mon, 4 Feb 2019 at 21:16, Geoffroy Van Cutsem
<geoffroy.vancutsem@...> wrote:
I had missed that in your original email, but I think the correct parameter to
be given to acrn-dm is "-s 4,virtio-net,tap0" (so drop the "acrn_" part from the
tap name).

Confirmed, acrn-dm will automatically add "acrn_" to the tap name you
give it - see
https://github.com/projectacrn/acrn-hypervisor/blob/master/devicemodel
/hw/pci/virtio/virtio_net.c#L667
That seems... unobvious.
No disagreement here. I don't actually recall if that was discussed and if there were any reason for doing it this way. Hopefully, someone from the engineering team can enlighten us.

Geoffroy

1001 - 1020 of 1237