Re: tx_queue_size with tap device

[Michael S. Tsirkin]

On Thu, Jul 28, 2022 at 10:51:22AM +0200, Markus Frank wrote:
> Hello,
> 
> I have a few questions concerning these commits.
> 
> commit 9b02e1618cf26aa52cf786f215d757506dda14f8
> commit 2eef278b9e6326707410eed23be40e57f6c331b7
> commit 0ea5778f066ea5c5e73246a4c11f0773edc4c45d
> 
> Therefore I added the developers in CC.
> 
> Do backends other than vhost-user or vhost-vdpa really not support the
> maximum tx_queue_size and why?
> Example: When using tap as backend and adding NET_CLIENT_DRIVER_TAP as a case
> to the switch statement, so that it can use the maximum size, ethtool also 
> shows
> the configured tx_queue_size of 1024.
> 
> In the commit 9b02e1618cf2 is stated, that the maximum tx_queue_size for other
> backends is 512. Is this still the case? If yes shouldn't it be possible to
> default to that (512), if something higher (1024) is configured, instead of 
> 256?
> 
> Also is there another way to check/test the tx_queue_size than ethtool?
> 
> Thanks in advance.
> 
> Markus

This is qemu virtio queue size which limits two things at the same time:
1- how many packets in queue
2- how long can a scatter gather list be

2 is what we are trying to limit here and so it has nothing to do
with ethtool.

That did not change.

In practical terms linux guests will not push scatter gather lists
larger than 512 even if queue size is larger, so you most likely
can increase the tx queue size and things will still work,
they are just not guaranteed by the spec.

As for changing defaults whether that is a gain or a loss will
depend on the workload.

-- 
MST

Re: modify NetdevUserOptions through QMP in QEMU 6 - how?

[Michael S. Tsirkin]

On Wed, Dec 15, 2021 at 08:03:50AM +0100, Thomas Huth wrote:
> So if changing netdev parameters on the fly is something that we want, we
> should implement this properly instead indeed, and not via such an
> accidental bug.

How to do it is a separate thing, users don't really care at all.

-- 
MST

Re: modify NetdevUserOptions through QMP in QEMU 6 - how?

[Michael S. Tsirkin]

On Wed, Dec 15, 2021 at 08:03:50AM +0100, Thomas Huth wrote:
> On 15/12/2021 04.31, Jason Wang wrote:
> > On Tue, Dec 14, 2021 at 10:53 PM Michael S. Tsirkin  wrote:
> > > 
> > > On Mon, Dec 13, 2021 at 09:02:15AM +0100, Thomas Huth wrote:
> > > >   Hi!
> > > > 
> > > > On 10/12/2021 18.02, Alexander Sosedkin wrote:
> > > > > With QEMU 5 I could totally issue a QMP netdev_add
> > > > > with the same ID to adjust the NetdevUserOptions I want,
> > > > > such as restrict or hostfwd. No deleting needed,
> > > > > just a netdev_add with what I want changed as a param.
> > > > 
> > > > I'm a little bit surprised that this worked, since AFAIK there is no 
> > > > code in
> > > > QEMU to *change* the parameters of a running netdev... likely the code 
> > > > added
> > > > a new netdev with the same ID, replacing the old one?
> > > > 
> > > > > With QEMU 6 it started failing, claiming the ID is already used.
> > > > > And if I do netdev_del + netdev_add, I just lose connectivity.
> > > > > What's even stranger, I still see old netdev attached in info network:
> > > > > 
> > > > > > netdev_del {'id': 'net0'}
> > > > > {}
> > > > > > human-monitor-command {'command-line': 'info network'}
> > > > > virtio-net-pci.0:
> > > > > index=0,type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56
> > > > >\ net0: index=0,type=user,net=10.0.2.0,restrict=off
> > > > 
> > > > I think that's "normal" - there used to be problems in the past that the
> > > > devices (virtio-net-pci in this case) did not like the netdevs to be 
> > > > removed
> > > > on the fly. So the netdevs are kept around until you remove the device, 
> > > > too
> > > > (i.e. issue a device_del for the virtio-net-pci device).
> > > > 
> > > > > > netdev_add {'type': 'user', 'id': 'net0', 'restrict': False, 
> > > > > > 'hostfwd': [{'str': 'tcp:127.0.0.1:58239-:22'}]}
> > > > > {}
> > > > > > human-monitor-command {'command-line': 'info network'}
> > > > > unseal: virtio-net-pci.0:
> > > > > index=0,type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56
> > > > >\ net0: index=0,type=user,net=10.0.2.0,restrict=off
> > > > > net0: index=0,type=user,net=10.0.2.0,restrict=off
> > > > > 
> > > > > What's the correct QMP command sequence to modify NetdevUserOptions?
> > > > 
> > > > AFAIK there is no way to modify running netdevs - you'd have to delete 
> > > > the
> > > > netdev and the device, and then add both again. But I might have missed
> > > > something here, so I CC:-ed some people who might be more familiar with 
> > > > the
> > > > details here.
> > > > 
> > > >   Thomas
> > > > 
> > > > 
> > > > > Please CC me on replies.
> > > 
> > > 
> > > Wow this really goes to show how wide our feature matrix is.
> > > 
> > > Yes it's probably an unintended side effect but yes it
> > > did work it seems, so we really should not just break it
> > > without warning.
> > > 
> > > 
> > > Probably this one:
> > > 
> > > commit 831734cce6494032e9233caff4d8442b3a1e7fef
> > > Author: Markus Armbruster 
> > > Date:   Wed Nov 25 11:02:20 2020 +0100
> > > 
> > >  net: Fix handling of id in netdev_add and netdev_del
> > > 
> > > 
> > > 
> > > Jason, what is your take here?
> > 
> > I might be wrong, but I agree with Thomas. Adding a netdev with the
> > same ID looks wrong, if it works, it looks like a bug.
> 
> It certainly calls for trouble as soon as you try to delete the netdev again
> - does it delete the first (inactive) instance? Does it delete the second
> active one? Does it delete both? (Otherwise it will leave a dangling
> instance behind) ...
> So if changing netdev parameters on the fly is something that we want, we
> should implement this properly instead indeed, and not via such an
> accidental bug.
> 
>  Thomas


Alexander, could you supply a reporoducer so we can check in which
QEMU versions it worked?
If it worked for a long time, then even if it was a result of a bug
it's an accidental ABI and we should not just break it.

-- 
MST

Re: modify NetdevUserOptions through QMP in QEMU 6 - how?

[Michael S. Tsirkin]

On Wed, Dec 15, 2021 at 07:48:06AM +0100, Markus Armbruster wrote:
> Jason Wang  writes:
> 
> > On Tue, Dec 14, 2021 at 10:53 PM Michael S. Tsirkin  wrote:
> >>
> >> On Mon, Dec 13, 2021 at 09:02:15AM +0100, Thomas Huth wrote:
> >> >  Hi!
> >> >
> >> > On 10/12/2021 18.02, Alexander Sosedkin wrote:
> >> > > With QEMU 5 I could totally issue a QMP netdev_add
> >> > > with the same ID to adjust the NetdevUserOptions I want,
> >> > > such as restrict or hostfwd. No deleting needed,
> >> > > just a netdev_add with what I want changed as a param.
> >> >
> >> > I'm a little bit surprised that this worked, since AFAIK there is no 
> >> > code in
> >> > QEMU to *change* the parameters of a running netdev... likely the code 
> >> > added
> >> > a new netdev with the same ID, replacing the old one?
> >> >
> >> > > With QEMU 6 it started failing, claiming the ID is already used.
> >> > > And if I do netdev_del + netdev_add, I just lose connectivity.
> >> > > What's even stranger, I still see old netdev attached in info network:
> >> > >
> >> > > > netdev_del {'id': 'net0'}
> >> > > {}
> >> > > > human-monitor-command {'command-line': 'info network'}
> >> > > virtio-net-pci.0:
> >> > > index=0,type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56
> >> > >   \ net0: index=0,type=user,net=10.0.2.0,restrict=off
> >> >
> >> > I think that's "normal" - there used to be problems in the past that the
> >> > devices (virtio-net-pci in this case) did not like the netdevs to be 
> >> > removed
> >> > on the fly. So the netdevs are kept around until you remove the device, 
> >> > too
> >> > (i.e. issue a device_del for the virtio-net-pci device).
> >> >
> >> > > > netdev_add {'type': 'user', 'id': 'net0', 'restrict': False, 
> >> > > > 'hostfwd': [{'str': 'tcp:127.0.0.1:58239-:22'}]}
> >> > > {}
> >> > > > human-monitor-command {'command-line': 'info network'}
> >> > > unseal: virtio-net-pci.0:
> >> > > index=0,type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56
> >> > >   \ net0: index=0,type=user,net=10.0.2.0,restrict=off
> >> > > net0: index=0,type=user,net=10.0.2.0,restrict=off
> >> > >
> >> > > What's the correct QMP command sequence to modify NetdevUserOptions?
> >> >
> >> > AFAIK there is no way to modify running netdevs - you'd have to delete 
> >> > the
> >> > netdev and the device, and then add both again. But I might have missed
> >> > something here, so I CC:-ed some people who might be more familiar with 
> >> > the
> >> > details here.
> >> >
> >> >  Thomas
> >> >
> >> >
> >> > > Please CC me on replies.
> >>
> >>
> >> Wow this really goes to show how wide our feature matrix is.
> >>
> >> Yes it's probably an unintended side effect but yes it
> >> did work it seems, so we really should not just break it
> >> without warning.
> 
> Depends.  See below.
> 
> >> Probably this one:
> >>
> >> commit 831734cce6494032e9233caff4d8442b3a1e7fef
> >> Author: Markus Armbruster 
> >> Date:   Wed Nov 25 11:02:20 2020 +0100
> >>
> >> net: Fix handling of id in netdev_add and netdev_del
> 
>CLI -netdev accumulates in option group "netdev".
> 
>Before commit 08712fcb85 "net: Track netdevs in NetClientState rather
>than QemuOpt", netdev_add added to the option group, and netdev_del
>removed from it, both HMP and QMP.  Thus, every netdev had a
>corresponding QemuOpts in this option group.
> 
>Commit 08712fcb85 dropped this for QMP netdev_add and both netdev_del.
>Now a netdev has a corresponding QemuOpts only when it was created
>with CLI or HMP.  Two issues:
> 
>* QMP and HMP netdev_del can leave QemuOpts behind, breaking HMP
>  netdev_add.  Reproducer:
> 
>$ qemu-system-x86_64 -S -display none -nodefaults -monitor stdio
>QEMU 5.1.92 monitor - type 'help' for more information
>(qemu) netdev_add user,id=net0
>(qemu) info network
>net0: index=0,type=user,net=10.0.2.0,restrict=off
>

Re: modify NetdevUserOptions through QMP in QEMU 6 - how?

[Michael S. Tsirkin]

On Mon, Dec 13, 2021 at 09:02:15AM +0100, Thomas Huth wrote:
>  Hi!
> 
> On 10/12/2021 18.02, Alexander Sosedkin wrote:
> > With QEMU 5 I could totally issue a QMP netdev_add
> > with the same ID to adjust the NetdevUserOptions I want,
> > such as restrict or hostfwd. No deleting needed,
> > just a netdev_add with what I want changed as a param.
> 
> I'm a little bit surprised that this worked, since AFAIK there is no code in
> QEMU to *change* the parameters of a running netdev... likely the code added
> a new netdev with the same ID, replacing the old one?
> 
> > With QEMU 6 it started failing, claiming the ID is already used.
> > And if I do netdev_del + netdev_add, I just lose connectivity.
> > What's even stranger, I still see old netdev attached in info network:
> > 
> > > netdev_del {'id': 'net0'}
> > {}
> > > human-monitor-command {'command-line': 'info network'}
> > virtio-net-pci.0:
> > index=0,type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56
> >   \ net0: index=0,type=user,net=10.0.2.0,restrict=off
> 
> I think that's "normal" - there used to be problems in the past that the
> devices (virtio-net-pci in this case) did not like the netdevs to be removed
> on the fly. So the netdevs are kept around until you remove the device, too
> (i.e. issue a device_del for the virtio-net-pci device).
> 
> > > netdev_add {'type': 'user', 'id': 'net0', 'restrict': False, 'hostfwd': 
> > > [{'str': 'tcp:127.0.0.1:58239-:22'}]}
> > {}
> > > human-monitor-command {'command-line': 'info network'}
> > unseal: virtio-net-pci.0:
> > index=0,type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56
> >   \ net0: index=0,type=user,net=10.0.2.0,restrict=off
> > net0: index=0,type=user,net=10.0.2.0,restrict=off
> > 
> > What's the correct QMP command sequence to modify NetdevUserOptions?
> 
> AFAIK there is no way to modify running netdevs - you'd have to delete the
> netdev and the device, and then add both again. But I might have missed
> something here, so I CC:-ed some people who might be more familiar with the
> details here.
> 
>  Thomas
> 
> 
> > Please CC me on replies.


Wow this really goes to show how wide our feature matrix is.

Yes it's probably an unintended side effect but yes it
did work it seems, so we really should not just break it
without warning.


Probably this one:

commit 831734cce6494032e9233caff4d8442b3a1e7fef
Author: Markus Armbruster 
Date:   Wed Nov 25 11:02:20 2020 +0100

net: Fix handling of id in netdev_add and netdev_del



Jason, what is your take here?


Alexander, what happens if we just drop the duplicate ID check? Do
things work for you again?
Warning: completely untested.

Signed-off-by: Michael S. Tsirkin 


diff --git a/net/net.c b/net/net.c
index f0d14dbfc1..01f5a187b6 100644
--- a/net/net.c
+++ b/net/net.c
@@ -1055,12 +1055,6 @@ static int net_client_init1(const Netdev *netdev, bool 
is_netdev, Error **errp)
 }
 }
 
-nc = qemu_find_netdev(netdev->id);
-if (nc) {
-error_setg(errp, "Duplicate ID '%s'", netdev->id);
-return -1;
-}
-
 if (net_client_init_fun[netdev->type](netdev, netdev->id, peer, errp) < 0) 
{
 /* FIXME drop when all init functions store an Error */
 if (errp && !*errp) {
-- 
MST

Re: Windows 10 Inaccessible Boot device starting 5.2.0-rc0

[Michael S. Tsirkin]

On Wed, Mar 03, 2021 at 05:57:45PM -0800, Nick S wrote:
> When you say "instal", do you mean configuring another VM with the same SSD in
> libvirt? I am not actually using the manually compiled version of qemu with
> libvirt, I just grabbed the command line from it and adjusted it a bit to work
> separately. And the libvirt that created it is fairly recent. I can certainly
> change the machine type there if you tell me what you want tested.

Sure, just change it to 5.2.

> This is my
> Windows to go image that I use in all kinds of places and it should be able to
> boot in both UEFI and Bios modes.
> 
> On Wed, Mar 3, 2021 at 2:06 PM Michael S. Tsirkin  wrote:
> 
> OK great, good to know. note it works because you
> specified an old machine type as libvirt does for
> old installed VMs.
> 
> My next question then is, what happens if you install
> a new VM? Does it work fine for you then?
> 
> 
> On Wed, Mar 03, 2021 at 08:56:32AM -0800, Nick S wrote:
> > This change works perfectly, thank you!
> >
> > On Wed, Mar 3, 2021 at 1:26 AM Michael S. Tsirkin  
> wrote:
> >
> >     Can you try this please:
> >
> >       git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git tags/
> for_upstream
> >
> >     ?
> >
> >
> >     On Tue, Mar 02, 2021 at 09:59:47PM -0800, Nick S wrote:
> >     > I found the commit that breaks my VM. Anybody has any background 
> on
> why
> >     it was
> >     > done? The comments are fairly extensive, but they are Mac related
> and I
> >     am
> >     > running Windows 10 with UEFI.  My VM is pc-q35-4.2 and this change
> >     definitely
> >     > breaks Windows 10. Anything before I can check out, compile and it
> runs
> >     fine.
> >     > Anything after this commit and it produces that boot device
> inaccessible
> >     error.
> >     > Reverting this change on the current master also makes it work
> fine.
> >     >
> >     > git diff af1b80ae56c9495999e8ccf7b70ef894378de642~
> >     > af1b80ae56c9495999e8ccf7b70ef894378de642
> >     > diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
> >     > index b7bc2a..7a5a8b3521 100644
> >     > --- a/hw/i386/acpi-build.c
> >     > +++ b/hw/i386/acpi-build.c
> >     > @@ -1497,7 +1497,7 @@ build_dsdt(GArray *table_data, BIOSLinker
> *linker,
> >     >          dev = aml_device("PCI0");
> >     >          aml_append(dev, aml_name_decl("_HID", aml_eisaid
> ("PNP0A03")));
> >     >          aml_append(dev, aml_name_decl("_ADR", aml_int(0)));
> >     > -        aml_append(dev, aml_name_decl("_UID", aml_int(1)));
> >     > +        aml_append(dev, aml_name_decl("_UID", aml_int(0)));
> >     >          aml_append(sb_scope, dev);
> >     >          aml_append(dsdt, sb_scope);
> >     >  
> >     > @@ -1512,7 +1512,7 @@ build_dsdt(GArray *table_data, BIOSLinker
> *linker,
> >     >          aml_append(dev, aml_name_decl("_HID", aml_eisaid
> ("PNP0A08")));
> >     >          aml_append(dev, aml_name_decl("_CID", aml_eisaid
> ("PNP0A03")));
> >     >          aml_append(dev, aml_name_decl("_ADR", aml_int(0)));
> >     > -        aml_append(dev, aml_name_decl("_UID", aml_int(1)));
> >     > +        aml_append(dev, aml_name_decl("_UID", aml_int(0)));
> >     >          aml_append(dev, build_q35_osc_method());
> >     >          aml_append(sb_scope, dev);
> >     >          aml_append(dsdt, sb_scope);
> >     >
> >     > It looks like a regression issue in 5.2.x so I registered a bug 
> for
> >     it: https:/
> >     > /bugs.launchpad.net/qemu/+bug/1917565
> >     >
> >     >
> >     > On Sun, Feb 28, 2021 at 9:13 PM Nick S 
> wrote:
> >     >
> >     >
> >     >     I have a VM set up on a USB SSD drive that I assign directly
> using
> >     linux
> >     >     device (-blockdev '{"driver":"host_device","filename":"/dev/
> disk/
> >     by-id/
> >     >   
> >   
>   
> scsi-1SanDisk_Extreme_SSD_20072F404043&qu

Re: Windows 10 Inaccessible Boot device starting 5.2.0-rc0

[Michael S. Tsirkin]

OK great, good to know. note it works because you
specified an old machine type as libvirt does for
old installed VMs.

My next question then is, what happens if you install
a new VM? Does it work fine for you then?


On Wed, Mar 03, 2021 at 08:56:32AM -0800, Nick S wrote:
> This change works perfectly, thank you!
> 
> On Wed, Mar 3, 2021 at 1:26 AM Michael S. Tsirkin  wrote:
> 
> Can you try this please:
> 
>   git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git tags/for_upstream
> 
> ?
> 
> 
> On Tue, Mar 02, 2021 at 09:59:47PM -0800, Nick S wrote:
> > I found the commit that breaks my VM. Anybody has any background on why
> it was
> > done? The comments are fairly extensive, but they are Mac related and I
> am
> > running Windows 10 with UEFI.  My VM is pc-q35-4.2 and this change
> definitely
> > breaks Windows 10. Anything before I can check out, compile and it runs
> fine.
> > Anything after this commit and it produces that boot device inaccessible
> error.
> > Reverting this change on the current master also makes it work fine.
> >
> > git diff af1b80ae56c9495999e8ccf7b70ef894378de642~
> > af1b80ae56c9495999e8ccf7b70ef894378de642
> > diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
> > index b7bc2a..7a5a8b3521 100644
> > --- a/hw/i386/acpi-build.c
> > +++ b/hw/i386/acpi-build.c
> > @@ -1497,7 +1497,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
> >          dev = aml_device("PCI0");
> >          aml_append(dev, aml_name_decl("_HID", aml_eisaid("PNP0A03")));
> >          aml_append(dev, aml_name_decl("_ADR", aml_int(0)));
> > -        aml_append(dev, aml_name_decl("_UID", aml_int(1)));
> > +        aml_append(dev, aml_name_decl("_UID", aml_int(0)));
> >          aml_append(sb_scope, dev);
> >          aml_append(dsdt, sb_scope);
> >  
> > @@ -1512,7 +1512,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
> >          aml_append(dev, aml_name_decl("_HID", aml_eisaid("PNP0A08")));
> >          aml_append(dev, aml_name_decl("_CID", aml_eisaid("PNP0A03")));
> >          aml_append(dev, aml_name_decl("_ADR", aml_int(0)));
> > -        aml_append(dev, aml_name_decl("_UID", aml_int(1)));
> > +        aml_append(dev, aml_name_decl("_UID", aml_int(0)));
> >          aml_append(dev, build_q35_osc_method());
> >          aml_append(sb_scope, dev);
> >          aml_append(dsdt, sb_scope);
> >
> > It looks like a regression issue in 5.2.x so I registered a bug for
> it: https:/
> > /bugs.launchpad.net/qemu/+bug/1917565
> >
> >
> > On Sun, Feb 28, 2021 at 9:13 PM Nick S  wrote:
> >
> >
> >     I have a VM set up on a USB SSD drive that I assign directly using
> linux
> >     device (-blockdev '{"driver":"host_device","filename":"/dev/disk/
> by-id/
> >   
>  
> scsi-1SanDisk_Extreme_SSD_20072F404043","aio":"native","node-name":"libvirt-2-storage","cache":
> >     
> 
> {"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}')
> >
> >     I've been using it for a few years now and recently decided to
> compile the
> >     most recent version of qemu to do some hacking. To my surprise, when
> I
> >     compiled the master branch, Windows failed to load with the "Boot
> Device
> >     Inaccessible" error. I went through tags in git and the latest tag
> that
> >     works is 5.1.0. On 5.2.0-rc0 I started getting this error. Was
> something
> >     changed recently for passing a linux block device as "raw"?
> >
> >     Thank you,
> >     Nick
> >
> 
> 

Re: Windows 10 Inaccessible Boot device starting 5.2.0-rc0

[Michael S. Tsirkin]

Can you try this please:

  git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git tags/for_upstream

?


On Tue, Mar 02, 2021 at 09:59:47PM -0800, Nick S wrote:
> I found the commit that breaks my VM. Anybody has any background on why it was
> done? The comments are fairly extensive, but they are Mac related and I am
> running Windows 10 with UEFI.  My VM is pc-q35-4.2 and this change definitely
> breaks Windows 10. Anything before I can check out, compile and it runs fine.
> Anything after this commit and it produces that boot device inaccessible 
> error.
> Reverting this change on the current master also makes it work fine.
> 
> git diff af1b80ae56c9495999e8ccf7b70ef894378de642~
> af1b80ae56c9495999e8ccf7b70ef894378de642
> diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
> index b7bc2a..7a5a8b3521 100644
> --- a/hw/i386/acpi-build.c
> +++ b/hw/i386/acpi-build.c
> @@ -1497,7 +1497,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
>          dev = aml_device("PCI0");
>          aml_append(dev, aml_name_decl("_HID", aml_eisaid("PNP0A03")));
>          aml_append(dev, aml_name_decl("_ADR", aml_int(0)));
> -        aml_append(dev, aml_name_decl("_UID", aml_int(1)));
> +        aml_append(dev, aml_name_decl("_UID", aml_int(0)));
>          aml_append(sb_scope, dev);
>          aml_append(dsdt, sb_scope);
>  
> @@ -1512,7 +1512,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
>          aml_append(dev, aml_name_decl("_HID", aml_eisaid("PNP0A08")));
>          aml_append(dev, aml_name_decl("_CID", aml_eisaid("PNP0A03")));
>          aml_append(dev, aml_name_decl("_ADR", aml_int(0)));
> -        aml_append(dev, aml_name_decl("_UID", aml_int(1)));
> +        aml_append(dev, aml_name_decl("_UID", aml_int(0)));
>          aml_append(dev, build_q35_osc_method());
>          aml_append(sb_scope, dev);
>          aml_append(dsdt, sb_scope);
> 
> It looks like a regression issue in 5.2.x so I registered a bug for it: 
> https:/
> /bugs.launchpad.net/qemu/+bug/1917565
> 
> 
> On Sun, Feb 28, 2021 at 9:13 PM Nick S  wrote:
> 
> 
> I have a VM set up on a USB SSD drive that I assign directly using linux
> device (-blockdev '{"driver":"host_device","filename":"/dev/disk/by-id/
> 
> scsi-1SanDisk_Extreme_SSD_20072F404043","aio":"native","node-name":"libvirt-2-storage","cache":
> 
> {"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}')
> 
> I've been using it for a few years now and recently decided to compile the
> most recent version of qemu to do some hacking. To my surprise, when I
> compiled the master branch, Windows failed to load with the "Boot Device
> Inaccessible" error. I went through tags in git and the latest tag that
> works is 5.1.0. On 5.2.0-rc0 I started getting this error. Was something
> changed recently for passing a linux block device as "raw"?
> 
> Thank you,
> Nick
> 

Re: [Qemu-discuss] virtio device instances identification by guest

[Michael S. Tsirkin]

On Thu, Nov 08, 2018 at 05:20:53PM +0600, Artem Pisarenko wrote:
> Ok, I found a way better, but it still not elegant, because depends on machine
> hardware configuration. One may use 'addr' property to assign address on PCI
> bus (and, if there are multiple PCI buses, identify bus somehow, but I didn't
> looked at).
> In my case on x86_64 target with default machine and given '-device
> virtio-net-pci,addr=.0,...' on command line guest application can
> get network interface name with:
> `ls /sys/devices/pci\:00/\:00\:.0/virtio*/net/`

I'm not sure I understand the requirements.
If you are after arbitrary strings, one way would be to add support
to vpd capability to devices... Want to try coding it up?

> 
> чт, 8 нояб. 2018 г. в 14:56, Artem Pisarenko :
> 
> Forgot to clarify that identification needs to be unique only to machine
> scope. 'virtio-net-pci' has 'mac' property, but if user wants to
> instantiate multiple such machines and connect them in one network, then
> 'mac' value also needs to be unique per this network. Thus, user have to
> generate 'mac' from some  and  parts and guest
> should find network interface by mac address masked with  part.

You need to create unique MACs anyway. If you don't it isn't guaranteed 
networking
will work.

> Itsn't as elegant as in examples above. Although, it's better than
> nothing...
> 
> чт, 8 нояб. 2018 г. в 14:18, Artem Pisarenko 
> :
> 
> Hi everyone,
> 
> Is there are any way to make guest system able to identify specific
> instances of virtio devices as specified by qemu user (on command line
> or via qmp command)?
> More specifically, I'm interested in virtio-net devices.
> I know it's possible for some other devices:
> - virtserialport/virtconsole have 'name=' property and guest
> application accesses serial device via "/dev/virtio-ports/"
> - virtio-9p-pci/virtfs have 'mount_tag=' and guest
> application mounts filesystem with "mount -t 9p -o trans=virtio
>  ..."
> But I cannot find any way to associate '-device virtio-net-pci'
> instances with eth network interfaces in guest.
> 
> Thanks in advance,
> Artem
> 
> 

Re: [Qemu-discuss] Fwd: qemu VM cannot be killed

[Michael S. Tsirkin]

Yes - I suspect a packet is stuck somewhere in networking stack.
This is what vhost is waiting for.

Yes, host reboot is the only way out.

RHEL disables zero copy tx in vhost to avoid these issues.

On Wed, Nov 15, 2017 at 02:55:32PM +0100, Lukáš Kubín wrote:
> CC-ing Michael and Jason as I was suggested in OFTC:#virt forum. Thanks!
> 
> -- Forwarded message --
> From: Lukáš Kubín 
> Date: Wed, Nov 15, 2017 at 1:39 PM
> Subject: qemu VM cannot be killed
> To: qemu-discuss@nongnu.org
> 
> 
> Hi, we've experienced an issue with kvm instance which got stuck at reboot.
> It's an OpenStack environment, with OpenContrail networking (vrouter agent
> running on host), Ubuntu 16.04.
> 
> Machine was first called to reboot from guest OS by user, had issues with NFS
> unmount during that, user sent a hard-reboot call from OpenStack again then.
> Then we (platform operator) got involved, tried to "virsh destroy" it with 
> this
> output:
> 
> 
> error: Failed to destroy domain instance-4243
> error: Failed to terminate process 140529 with SIGKILL: Device or resource
> busy
> 
> 
> Neither "kill -9" sent to the qemu process helped.
> 
> Good guys at OFTC:#virt have guided me to collect the following traces and ask
> for help here:
> 
> 
> # cat /proc/140529/wchan
> vhost_net_ubuf_put_and_wait
> 
> # cat /proc/140529/stack
> [] vhost_net_ubuf_put_and_wait+0x54/0xa0 [vhost_net]
> [] vhost_net_ioctl+0x354/0x8a0 [vhost_net]
> [] do_vfs_ioctl+0xa1/0x5f0
> [] SyS_ioctl+0x79/0x90
> [] entry_SYSCALL_64_fastpath+0x1e/0xa8
> [] 0x
> 
> 
> The versions we use are:
> 
>   • kernel 4.8.0-41-generic
>   • qemu-kvm 1:2.5+dfsg-5ubuntu10.2~xenial0+contrail1
>   • libvirt-bin 1.3.1-1ubuntu10.1~xenial1+contrail1
> 
> What can be the cause for this error? What can we do in such a situation to
> destroy the VM - is physical server reboot the only option?
> 
> Thanks and greetings,
> 
> Lukáš
> 

Re: [Qemu-discuss] Using vhost scsi

[Michael S. Tsirkin]

On Wed, Jul 27, 2016 at 09:34:25AM +0100, Stefan Hajnoczi wrote:
> On Tue, Jul 26, 2016 at 06:35:30PM +, Yehuda Yitschak wrote:
> > Thanks a lot for the detailed answer 
> > 
> > I managed to run virtio-scsi and i am benchmarking the performance
> > 
> > just curios, does virtio-scsi deliver about the same performance as 
> > vhost-scsi ? 
> 
> Both virtio-scsi and vhost-scsi support many different configurations.
> If achieving the best performance is critical then you need to benchmark
> them yourself.
> 
> > i was surprised to learn that vhost-scsi isn't widely used.
> > i thought vhost-scsi should be the favored solution since it should be 
> > faster but i guess the features you mentioned are also a significant factor.
> 
> Since virtio-scsi is QEMU userspace code it poses a lower security risk,
> is easier to update in sync with QEMU itself, and has all the QEMU block
> layer features.  The performance of vhost-scsi and virtio-scsi should be
> about the same - they both do the same thing and there's no great
> advantage to a kernel thread vs userspace thread (they use essentially
> the same functionality inside the kernel).
> 
> Stefan

That would depend on the workload.  I remember seeing reports of performance
differences, e.g.:

http://thread.gmane.org/gmane.comp.emulators.kvm.devel/93601/focus=93777

That was 4 years ago, it would be very interesting to see where we are now.

-- 
MST