Re: [Qemu-devel] SMM error in 2.4 changelog
On Tue, Nov 3, 2015 at 10:01 AM, Paolo Bonzini wrote: > Yes, this is correct. Thanks! The mistake seems to be still present in changelog. -- William
[Qemu-devel] SMM error in 2.4 changelog
Hello, I think there might be a mistake in the 2.4 changelog: http://wiki.qemu.org/ChangeLog/2.4 "Support for system management mode (requires Linux 4.1)." But I believe it's included in Linux v4.2 see https://lwn.net/Articles/648995/ for the merge window. Sorry for the noise if it is not the right way to report a wiki/changelog mistake. Best regards, -- William
Re: [Qemu-devel] Patch Round-up for stable 2.1.3, freeze on 2015-01-14
Hello, On Jan09 23:42, Paolo Bonzini wrote: > That's commit 364c3e6b8dd7912e01d19122d791b8c8f6df4f6c on branch > uq/master of git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git. maybe the one for: fix regression when reading memory size from config file is also a patch to think about. Thanks, -- William signature.asc Description: Digital signature
Re: [Qemu-devel] [PATCH v3] vl.c: fix regression when reading machine type from config file
On Jan07 14:11, Marcel Apfelbaum wrote: > After 'Machine as QOM' series the machine type input triggers > the creation of the machine class. > If the machine type is set in the configuration file, the machine > class is not updated accordingly and remains the default. I have also tested it; it does work. Thanks, > Fixed that by querying the machine options after the configuration > file is loaded. > > Cc: qemu-sta...@nongnu.org > Reported-by: William Dauchy > Signed-off-by: Marcel Apfelbaum > --- > v2 -> v3: > - Addressed Paolo Bonzini's comments: >- fixed whitespace > v1 -> v2: > - Addressed Paolo Bonzini's comments: >- moved the call to machine_parse after the switch > and brought QEMU_OPTION_M near QEMU_OPTION_machine > > vl.c | 15 --- > 1 file changed, 8 insertions(+), 7 deletions(-) > -- William signature.asc Description: Digital signature
Re: [Qemu-devel] [PATCH] Fix irq route entries exceed KVM_MAX_IRQ_ROUTES
On Dec31 03:45, kevinnma(马文霜) wrote:
> diff --git a/kvm-all.c b/kvm-all.c
> index 18cc6b4..f47e1b1 100644
> --- a/kvm-all.c
> +++ b/kvm-all.c
> @@ -1123,6 +1123,17 @@ static int kvm_irqchip_get_virq(KVMState *s)
> int i, bit;
> bool retry = true;
>
> +/*
> + * PIC and IOAPIC share the first 15 GSI numbers,available GSI
> + * numbers greater than IRQ route entries. If allocate GSI number
> + * succeeds, a new route entry can be added, so total IRQ route
> + * enties can exceed gsi_count, flush dynamic MSI entries when
> + * IRQ route entries arrive gsi_count.
> + */
> +if (!s->direct_msi && s->irq_routes->nr == s->gsi_count) {
> +kvm_flush_dynamic_msi_routes(s);
> +}
> +
> again:
> /* Return the lowest unused GSI in the bitmap */
> for (i = 0; i < max_words; i++) {
Any comments on this patch?
--
William
signature.asc
Description: Digital signature
Re: [Qemu-devel] readconfig with machine section and type option ignored
On Dec16 13:09, Markus Armbruster wrote: > Broken since main()'s case QEMU_OPTION_machine doesn't just parse its > option argument with qemu_opts_parse(), it also implements parameter > "type". Copying Marcel because "he touched it, he owns it". yes indeed, the type option is also not working, and there was an older report about it -- William signature.asc Description: Digital signature
[Qemu-devel] readconfig with machine section and type option ignored
Hello,
I'm trying to specify machine type using the config file; for example:
[machine]
type = "pc-i440fx-2.1"
It seems to be ignored:
qom-get path=/machine property=type
{ u'return': u'pc-i440fx-2.2-machine'}
It does work with the command line:
-M "pc-i440fx-2.1"
qom-get path=/machine property=type
{ u'return': u'pc-i440fx-2.1-machine'}
Is it considered as a bug? I am using qemu-2.2
Thanks,
--
William
signature.asc
Description: Digital signature
Re: [Qemu-devel] [Bug 1358287] Re: -readconfig file doesn't interpret memory size correctly
No news about it in qemu2.2? Thanks, -- William
Re: [Qemu-devel] migration from qemu2.1.2 to qemu2.2
On Dec11 14:34, Dr. David Alan Gilbert wrote: > > I dont get your last statement; > > my common use case is to live migrate an old userland to a new one > > (so 2.1 to 2.2 here); so if I guarantee same HW, it should work, right? > > I wouldn't trust -host cpu to be the same on the same HW between > different QEMUs, especially on newer hardware than your older QEMU new > about. understood. What are your recommendations then? Using kvm64 proc? Thanks for your feedback, -- William signature.asc Description: Digital signature
Re: [Qemu-devel] migration from qemu2.1.2 to qemu2.2
On Dec11 14:05, Dr. David Alan Gilbert wrote: > Hmm, it might even do it on the same hardware between different qemus; I dont get your last statement; my common use case is to live migrate an old userland to a new one (so 2.1 to 2.2 here); so if I guarantee same HW, it should work, right? -- William signature.asc Description: Digital signature
Re: [Qemu-devel] migration from qemu2.1.2 to qemu2.2
On Dec10 18:21, Dr. David Alan Gilbert wrote: > Can you try stripping your config down to the bare minimum and see if > it goes away? e.g. balloon, rng-pci, network I guess you can probably > test without easily enough. If you can also try with a normal boot off > disk rather than kernel that would be good. harder to reproduce now (I have less and less VM running on 2.1 and cant reproduce on my dev platform wiath fresh VM on 2.1->2.2 scenario) anyway I was wondering if the option `-cpu host` could be the cause of the issues since the HW is not always the same accross the infrastructure. Thanks, -- William signature.asc Description: Digital signature
Re: [Qemu-devel] migration from qemu2.1.2 to qemu2.2
On Dec10 17:31, Dr. David Alan Gilbert wrote: > OK, and just checking, 2.2->2.2 and 2.1->2.1 works for you? > It's just 2.1->2.2 that's breaking? yes -- William signature.asc Description: Digital signature
Re: [Qemu-devel] migration from qemu2.1.2 to qemu2.2
+ maybe the last patch from Paulo "kvm/apic: fix 2.2->2.1 migration" is related? -- William signature.asc Description: Digital signature
Re: [Qemu-devel] migration from qemu2.1.2 to qemu2.2
On Dec10 17:10, Dr. David Alan Gilbert wrote: > As previously requested, please show your full command line. qemu-system-x86_64 -m 2048 -cpu host -nodefconfig -nodefaults -nographic -readconfig /var/lib/qemu/X/config -pidfile /var/lib/qemu/X/pid -M pc-i440fx-2.1 -serial pty -d unimp,guest_errors -daemonize config file: [name] guest = "X" process = "X" [chardev "compat_monitor0"] backend = "socket" path = "/var/lib/qemu/X/sock" server = "on" wait = "off" [device] driver = "virtio-balloon" [rtc] base = "utc" [mon "compat_monitor0"] mode = "control" chardev = "compat_monitor0" default = "on" [device] driver = "virtio-rng-pci" [device "scsi0"] driver = "virtio-scsi-pci" hotplug = "on" [machine] kernel = "/boot-vm/bzImage-3.12-x86_64" append = "root=/dev/sda console=ttyS0 ro" accel = "kvm" [netdev "vif15196.1"] type = "tap" br = "p43" vhost = "on" vhostforce = "on" ifname = "vif15196.1" downscript = "no" script = "no" queues = "1" [device "vif15196.1"] driver = "virtio-net-pci" netdev = "vif15196.1" mac = "00:16:3e:2e:ea:7c" mq = "on" vectors = "3" [drive "disk0"] if = "none" id = "disk0" cache = "none" aio = "native" format = "raw" file = "/dev/sda" [device "disk0"] driver = "scsi-hd" drive = "disk0" scsi-id = "0" removable = "on" dpofua = "off" [drive "swap0"] if = "none" id = "swap0" cache = "none" aio = "native" format = "raw" file = "/dev/sdb" [device "swap0"] driver = "scsi-hd" drive = "swap0" scsi-id = "1" removable = "on" dpofua = "off" [smp-opts] cpus = "1" sockets = "1" cores = "1" threads = "1" maxcpus = "16" -- William signature.asc Description: Digital signature
Re: [Qemu-devel] migration from qemu2.1.2 to qemu2.2
On Dec10 08:58, Dr. David Alan Gilbert wrote: > Yes, you've got to keep the same machine type to do a live migration; > think of it like keeping the same motherboard/cpu combination in a real > machine - we can't squash the state from one shape machine into > a different shape machine without the guest getting very confused. I now have done some other tests: with source -M pc-i440fx-2.1 and target -M pc-i440fx-2.1 still getting: Unknown combination of migration flags: 0 warning: error while loading state section id 2 -- William signature.asc Description: Digital signature
Re: [Qemu-devel] migration from qemu2.1.2 to qemu2.2
Hi David, Thank you for the quick answer. On Dec09 18:55, Dr. David Alan Gilbert wrote: > You don't tell us what that command line is! > If you're using -M pc or -M q35 that's expected; if you're not > it's probably a bug - please show us the command line. sorry it's indeed with `-M pc`. So I misunderstood the usage of supported machines option since I was looking for a way to upgrade the version and avoiding being stuck on a specific release. I now understand I am supposed to keep the same version between live migration and wait for a complete stop/start to upgrade. Or if there is a trick, please advice. Thanks, -- William signature.asc Description: Digital signature
Re: [Qemu-devel] migration from qemu2.1.2 to qemu2.0
(sorry bad subject, I meant qemu2.2) -- William signature.asc Description: Digital signature
[Qemu-devel] migration from qemu2.1.2 to qemu2.0
Hello, I have been testing live migration from qemu2.1.2 to qemu2.2.0 under kvm - with same config and same command line. the process crashes with: Unknown combination of migration flags: 0 qemu: warning: error while loading state section id 2 Don't know if it's supposed to be supported or not. Thanks, -- William signature.asc Description: Digital signature
Re: [Qemu-devel] hotremoving a disk qmp/hmp
On Nov18 18:15, Markus Armbruster wrote: > Looks like you're using an old version of QEMU. drive_del has been > fixed to refuse touching a backend created with blockdev-add: I am using the last v2.1.x version but there was indeed some commits since > You can't destroy a backend created with blockdev-add, yet. I hope to > have blockdev-del in 2.3. thanks for the information > My advice is to stick to drive_add and drive_del for now. Not in QMP, > so you need to use HMP. You can do that in QMP with > human-monitor-command. ok understood that's what I was suspecting after not finding a way to delete an object added by blockdev-add Thanks, -- William signature.asc Description: Digital signature
Re: [Qemu-devel] hotremoving a disk qmp/hmp
On Nov18 15:22, Markus Armbruster wrote:
> This is block backend "disk1".
yes indeed.
> I presume you're deleting the device using backend "disk1".
yes
> What kind of device is this? PCI, perhaps?
> Please show us a complete QMP conversation.
Here it is:
live vm with one disk:
(QEMU) query-block
{ u'return': [ { u'device': u'disk0',
u'inserted': { u'backing_file_depth': 0,
u'bps': 0,
u'bps_rd': 0,
u'bps_wr': 0,
u'detect_zeroes': u'off',
u'drv': u'raw',
u'encrypted': False,
u'encryption_key_missing': False,
u'file': u'/dev/sda',
u'image': { u'actual-size': 0,
u'dirty-flag': False,
u'filename': u'/dev/sda',
u'format': u'raw',
u'virtual-size':
3221225472},
u'iops': 0,
u'iops_rd': 0,
u'iops_wr': 0,
u'ro': False},
u'io-status': u'ok',
u'locked': True,
u'removable': True,
u'tray_open': False,
u'type': u'unknown'}]}
hotplugging one disk:
(QEMU) blockdev-add
with
{'options' : {
'driver': 'raw',
'id': 'disk1',
'file': {
'driver': 'file',
'filename': /dev/sdb,
}
}}
(QEMU) device_add
with:
{
'driver': 'scsi-hd',
'id': 'disk1',
'drive': 'disk1',
'scsi-id': 1,
'removable': 'on',
'dpofua': 'off'
}
(QEMU) query-block
{ u'return': [ { u'device': u'disk0',
u'inserted': { u'backing_file_depth': 0,
u'bps': 0,
u'bps_rd': 0,
u'bps_wr': 0,
u'detect_zeroes': u'off',
u'drv': u'raw',
u'encrypted': False,
u'encryption_key_missing': False,
u'file': u'/dev/sda',
u'image': { u'actual-size': 0,
u'dirty-flag': False,
u'filename': u'/dev/sda',
u'format': u'raw',
u'virtual-size':
3221225472},
u'iops': 0,
u'iops_rd': 0,
u'iops_wr': 0,
u'ro': False},
u'io-status': u'ok',
u'locked': True,
u'removable': True,
u'tray_open': False,
u'type': u'unknown'},,
{ u'device': u'disk1',
u'inserted': { u'backing_file_depth': 0,
u'bps': 0,
u'bps_rd': 0,
u'bps_wr': 0,
u'detect_zeroes': u'off',
u'drv': u'raw',
u'encrypted': False,
u'encryption_key_missing': False,
u'file': u'/dev/sdb',
u'image': { u'actual-size': 0,
u'dirty-flag': False,
u'filename': u'/dev/sdb',
u'format': u'raw',
u'virtual-size':
3221225472},
u'iops': 0,
u'iops_rd': 0,
u'iops_wr': 0,
u'ro': False},
u'io-status': u'ok',
u'locked': True,
u'removable': True,
u'tray_open': False,
u'type': u'unknown'}]}
hotremoving disk1:
(QEMU) device_del
with:
{'id': 'disk1'}
(QEMU) query-block
{ u'return': [ {
[Qemu-devel] hotremoving a disk qmp/hmp
Hello,
When hotremoving a disk I'm using the QMP API with device_del command;
Previous query-block command result:
{ u'device': u'disk1',
u'inserted': { u'backing_file_depth': 0,
u'bps': 0,
u'bps_rd': 0,
u'bps_wr': 0,
u'detect_zeroes': u'off',
u'drv': u'raw',
u'encrypted': False,
u'encryption_key_missing': False,
u'file': u'/dev/sda',
u'image': { u'actual-size': 0,
u'dirty-flag': False,
u'filename': u'/dev/sda',
u'format': u'raw',
u'virtual-size': 3221225472},
u'iops': 0,
u'iops_rd': 0,
u'iops_wr': 0,
u'ro': False},
u'io-status': u'ok',
u'locked': True,
u'removable': True,
u'tray_open': False,
u'type': u'unknown'}
After a device_del command I have the same thing but "'locked': False"
Then I can also do `eject device=disk1` which bring me to:
{ u'device': u'disk1',
u'io-status': u'ok',
u'locked': False,
u'removable': True,
u'tray_open': False,
u'type': u'unknown'}
But I did not found a way to completely remove the disk1 entry in order
to be able to add it again.
To complete the operation I need to use the old HMP API and use
`drive_del` command.
Did I miss something? or is it still something missing in QMP API?
Best regards,
--
William
signature.asc
Description: Digital signature
Re: [Qemu-devel] [PATCH v2] RFC: Add blockdev-del QMP command
Hi, On Wed, Feb 12, 2014 at 6:36 PM, Ian Main wrote: > This is the sister command to blockdev-add. In Fam's example he uses > the drive_del HMP command to clean up but it would be much nicer to > have a way to do this via QMP. Is there any news on this subject? It seems like we still need to clean up with drive_del from HMP command when hotremoving a disk. Did I miss something? Thanks, -- William
[Qemu-devel] network traffic throttling
Hi, I'm looking for a way to limit the number of PPS using vhost-net interface in kvm. I saw http://www.linux-kvm.org/page/NetworkingTodo network traffic throttling block implemented "continuous leaky bucket" for throttling we can use continuous leaky bucket to network IOPS/BPS * RX/TX/TOTAL Developer: Amos Kong just wondering if someone started to work on it or if they were another project working on it. Thanks, -- William signature.asc Description: Digital signature
Re: [Qemu-devel] [PULL 13/13] vhost_net: start/stop guest notifiers properly
On Sep02 18:07, Michael S. Tsirkin wrote: > From: Jason Wang > > commit a9f98bb5ebe6fb1869321dcc58e72041ae626ad8 vhost: multiqueue > support changed the order of stopping the device. Previously > vhost_dev_stop would disable backend and only afterwards, unset guest > notifiers. We now unset guest notifiers while vhost is still > active. This can lose interrupts causing guest networking to fail. In > particular, this has been observed during migration. > > To adapt this, several other changes are needed: > - remove the hdev->started assertion in vhost.c since we may want to > start the guest notifiers before vhost starts and stop the guest > notifiers after vhost is stopped. > - introduce the vhost_net_set_vq_index() and call it before setting > guest notifiers. This is used to guarantee vhost_net has the correct > virtqueue index when setting guest notifiers. > > Cc: qemu-sta...@nongnu.org > Reported-by: "Zhangjie (HZ)" > Tested-by: William Dauchy please use: Tested-by: William Dauchy > Signed-off-by: Michael S. Tsirkin > Signed-off-by: Jason Wang > Reviewed-by: Michael S. Tsirkin > Signed-off-by: Michael S. Tsirkin Thanks, -- William signature.asc Description: Digital signature
Re: [Qemu-devel] adding a parameter in qemu tap option
Hi Stefan, Thanks for you answer. On Aug22 14:22, Stefan Hajnoczi wrote: > I don't see any obvious reason from the small diff you have posted. Are > you sure this is the only change you've made and the environment is > unchanged? absolutely. I suspect a bug related to options coming from the config file because I dont have any issue if I pass the config through command line. -- William signature.asc Description: Digital signature
[Qemu-devel] adding a parameter in qemu tap option
Hi,
I'm trying to understand how to add a parameter in tap option.
I currently have a working config for a vm; i.e several interfaces using
multiqueues.
I had a try with:
--- a/qapi-schema.json
+++ b/qapi-schema.json
-2006,6 +2008,7 @@
##
{ 'type': 'NetdevTapOptions',
'data': {
+ '*foo': 'str',
'*ifname': 'str',
'*fd': 'str',
'*fds': 'str',
i.e just adding a foo parameter; nothing change in my config file (I'm
using -readconfig option and not cmdline)
multiqueue is no longer working in some cases.
I don't get how is it possible. I don't even understand why I don't have
the same behaviour using the cmdline.
Maybe I forgot something obvious.
Does someone has some hints?
Thanks,
--
William
signature.asc
Description: Digital signature
Re: [Qemu-devel] vhost-net issue with multiples interfaces using MQ
On Aug19 15:02, William Dauchy wrote: > I'm using readconfig option to read the three vif interfaces. > thanks for testing I will re-triple test to see what's wrong so indeed sorry for the noise, I was wrong in my tests. -- William signature.asc Description: Digital signature
Re: [Qemu-devel] [PATCH V3] vhost_net: start/stop guest notifiers properly
On Aug19 12:56, Jason Wang wrote: > commit a9f98bb5ebe6fb1869321dcc58e72041ae626ad8 vhost: multiqueue > support changed the order of stopping the device. Previously > vhost_dev_stop would disable backend and only afterwards, unset guest > notifiers. We now unset guest notifiers while vhost is still > active. This can lose interrupts causing guest networking to fail. In > particular, this has been observed during migration. > > To adapt this, several other changes are needed: > - remove the hdev->started assertion in vhost.c since we may want to > start the guest notifiers before vhost starts and stop the guest > notifiers after vhost is stopped. > - introduce the vhost_net_set_vq_index() and call it before setting > guest notifiers. This is used to guarantee vhost_net has the correct > virtqueue index when setting guest notifiers. > > Reported-by: "Zhangjie (HZ)" > Cc: William Dauchy > Signed-off-by: Michael S. Tsirkin > Signed-off-by: Jason Wang > > -- > Changes from Michael's patch: > - Remove the assertion > Changes from V1: > - Rebase to latest > Changes from V2: > - Introduce vhost_net_set_vq_index() to unbreak multiqueue indeed I had with v2: qemu-system-x86_64: hw/virtio/vhost.c:990: vhost_virtqueue_mask: Assertion `n >= hdev->vq_index && n < hdev->vq_index + hdev->nvqs' failed. v3 seems ok to me -- William signature.asc Description: Digital signature
Re: [Qemu-devel] vhost-net issue with multiples interfaces using MQ
On Aug19 11:40, Jason Wang wrote: > What's the qemu command line for your testing? I try simple command line > with 3 mq cards in qemu 2.1. Everything works fine. I'm using readconfig option to read the three vif interfaces. thanks for testing I will re-triple test to see what's wrong > Is this a regression? If yes, you can probably bisect to find the first > bad commit. nope first time I'm using it -- William signature.asc Description: Digital signature
Re: [Qemu-devel] [PATCH] vhost_net: start/stop guest notifiers properly
On Mon, Aug 18, 2014 at 11:51 AM, Jason Wang wrote:
> err:
> @@ -254,16 +254,16 @@ void vhost_net_stop(VirtIODevice *dev, NetClientState
> *ncs,
> VirtioBusClass *k = VIRTIO_BUS_GET_CLASS(vbus);
> int i, r;
>
> +for (i = 0; i < total_queues; i++) {
> +vhost_net_stop_one(tap_get_vhost_net(ncs[i].peer), dev);
> +}
> +
> r = k->set_guest_notifiers(qbus->parent, total_queues * 2, false);
> if (r < 0) {
> fprintf(stderr, "vhost guest notifier cleanup failed: %d\n", r);
> fflush(stderr);
> }
> assert(r >= 0);
> -
> -for (i = 0; i < total_queues; i++) {
> -vhost_net_stop_one(tap_get_vhost_net(ncs[i].peer), dev);
> -}
> }
since
ed8b4af Refactor virtio-net to use generic get_vhost_net
get_vhost_net is used instead of tap_get_vhost_net
Could you rebase your patch to facilitate tests or is it intentional?
Thanks,
--
William
[Qemu-devel] vhost-net issue with multiples interfaces using MQ
Hello, Using qemu2.1.0, a linux v3.14.X x86_64 as host and a linux v3.12.X x86_64 as guest I'm starting a VM with these network interfaces: [netdev "vifA.0"] type = "tap" vhost = "on" ifname = "vifA.0" downscript = "no" script = "no" queues = "2" [device "vifA.0"] driver = "virtio-net-pci" netdev = "vifA.0" mac = "00:16:3e:1a:4e:11" mq = "on" vectors = "5" (and same config for two other interfaces but with a different MAC address) In the error message I'm getting during startup: unable to start vhost net: 95: falling back on userspace virtio I saw that it's failing in `vhost_dev_start` where `vhost_dev_set_features` is returning an error. r = vhost_dev_set_features(hdev, hdev->log_enabled); I'm hitting the issue starting from three interfaces, i.e no problem with one or two. I also don't have the issue with disabling multi queue. Am I wrong on something? What can I do to help debug this situation? Regards, -- William signature.asc Description: Digital signature
Re: [Qemu-devel] using virtio-net multiqueues
On Wed, Aug 13, 2014 at 8:03 PM, William Dauchy wrote: > during qemu startup I see several queues in > /sys/devices/virtual/net/vifA.0/queues and it quickly disappears; at > the end I see only one rx and one tx. > Am I wrong on something? What can I do to help debug this situation? finally found what was wrong; need to enable it in guest (with ethtool) in order to see it since commit: 55257d7 virtio-net: fill only rx queues which are being used Sorry for the noise, -- William
Re: [Qemu-devel] using virtio-net multiqueues
On Wed, Aug 13, 2014 at 8:03 PM, William Dauchy wrote: > Using qemu2.1 I'm starting a vm with this network interface: > > [netdev "vifA.0"] > type = "tap" > vhost = "on" > ifname = "vifA.0" > downscript = "no" > script = "no" > queues = "2" > > [device "vifA.0"] > driver = "virtio-net-pci" > netdev = "vifA.0" > mac = "00:16:3e:1a:4e:11" > mq = "on" > vectors = "5" > > during qemu startup I see several queues in > /sys/devices/virtual/net/vifA.0/queues and it quickly disappears; at > the end I see only one rx and one tx. > Am I wrong on something? What can I do to help debug this situation? my host is a linux3.14.X and the guest VM is running a linux3.12.X -- William
[Qemu-devel] using virtio-net multiqueues
Hello, Using qemu2.1 I'm starting a vm with this network interface: [netdev "vifA.0"] type = "tap" vhost = "on" ifname = "vifA.0" downscript = "no" script = "no" queues = "2" [device "vifA.0"] driver = "virtio-net-pci" netdev = "vifA.0" mac = "00:16:3e:1a:4e:11" mq = "on" vectors = "5" during qemu startup I see several queues in /sys/devices/virtual/net/vifA.0/queues and it quickly disappears; at the end I see only one rx and one tx. Am I wrong on something? What can I do to help debug this situation? Best regards, -- William
Re: [Qemu-devel] [questions] about qemu log
On Wed, Aug 6, 2014 at 12:43 PM, William Dauchy wrote:
> this make it incompatible with -daemonize option.
> there should be a possibility to detach the process and also redirect
> stderr somewhere.
I have done a quick and dirty patch for my own qemu binary so I can
use daemonize and also redirect stderr to syslog.
diff --git a/include/sysemu/os-posix.h b/include/sysemu/os-posix.h
index f131521..bf92ec1 100644
--- a/include/sysemu/os-posix.h
+++ b/include/sysemu/os-posix.h
@@ -34,6 +34,7 @@ void os_setup_signal_handling(void);
void os_daemonize(void);
void os_setup_post(void);
int os_mlock(void);
+void tolog(FILE **pfp);
typedef struct timeval qemu_timeval;
#define qemu_gettimeofday(tp) gettimeofday(tp, NULL)
diff --git a/os-posix.c b/os-posix.c
index cb2a7f7..8d8d425 100644
--- a/os-posix.c
+++ b/os-posix.c
@@ -33,6 +33,8 @@
#include
#include
#include
+#include
+#include
/* Needed early for CONFIG_BSD etc. */
#include "config-host.h"
@@ -250,6 +252,28 @@ void os_daemonize(void)
}
}
+static size_t writer(void *cookie, char const *data, size_t len)
+{
+while(*data == ' ') {
+++data;
+ --len;
+}
+
+syslog(LOG_DEBUG, "%.*s", len, data);
+return len;
+}
+
+static int noop(void) {return 0;}
+static cookie_io_functions_t log_fn = {
+(void*) noop, (void*) writer, (void*) noop, (void*) noop
+};
+
+void tolog(FILE **pfp)
+{
+*pfp = fopencookie(NULL, "w", log_fn);
+setvbuf(*pfp, NULL, _IOLBF, 0);
+}
+
void os_setup_post(void)
{
int fd = 0;
@@ -280,8 +304,8 @@ void os_setup_post(void)
if (daemonize) {
dup2(fd, 0);
-dup2(fd, 1);
-dup2(fd, 2);
+ tolog(&stdout);
+ tolog(&stderr);
close(fd);
}
diff --git a/vl.c b/vl.c
index fe451aa..6b6b62c 100644
--- a/vl.c
+++ b/vl.c
@@ -3969,6 +3970,10 @@ int main(int argc, char **argv, char **envp)
loc_set_none();
os_daemonize();
+if (is_daemonized()) {
+ tolog(&stdout);
+ tolog(&stderr);
+}
if (qemu_init_main_loop()) {
fprintf(stderr, "qemu_init_main_loop failed\n");
--
William
Re: [Qemu-devel] [questions] about qemu log
On Wed, Aug 6, 2014 at 12:40 AM, Peter Crosthwaite wrote: > Well -D will log to file only loggable (i.e. qemu_log()) information > (which has all sorts of options and switches). Stderr, is a little > more static and should in theory be limited to genuine errors. But if > you want a combined log of both you can simply omit -D to default > qemu_log output to stderr. This gives you a combined log that you can > redirect anywhere. To be honest, this is what I do as a matter of > course (2> foo rather than -D foo). understood; this make it incompatible with -daemonize option. there should be a possibility to detach the process and also redirect stderr somewhere. -- William
Re: [Qemu-devel] qemu live migration error from 2.0 to 2.1
On Wed, Aug 6, 2014 at 11:17 AM, Dr. David Alan Gilbert wrote: > The trick is to pick a -M value and stick with it; then you should be > able to keep migrating to newer QEMU versions easily (just don't > go with dev versions because things are often broken in them). ok for dev versions, I'm just cherry picking interesting fixes which are not yet released in stable. > -M pc is special, don't use that if you want to be able to migrate understood, I guess it's the default value -- William
Re: [Qemu-devel] qemu live migration error from 2.0 to 2.1
On Wed, Aug 6, 2014 at 9:49 AM, Paolo Bonzini wrote: > This is a development version between 2.0.0 and 2.0.0-rc1; it may have > bugs such as the one that was fixed in 2.0.0-rc5. you mean 2.1.0-rc5 > Migration from development versions is not supported. You must either > upgrade to 2.1.0, or downgrade to the released 2.0.0 version. in all case I would have the same issue with 2.0.0 version since the fix has been pushed in 2.1.0-rc5 -- William
Re: [Qemu-devel] qemu live migration error from 2.0 to 2.1
On Wed, Aug 6, 2014 at 9:47 AM, Paolo Bonzini wrote: > I suspect he's using "-M pc" on both. Is it the default value? because it's not the case in my command line. > You must use "-M pc-i440fx-2.0" > on both if you're migrating from 2.0 to a different version. wow. I wasn't expecting such behavior; i.e migration between qemu version does not seem trivial and it removes the benefits; better using stop/start. thanks for the info. -- William
Re: [Qemu-devel] [questions] about qemu log
On Tue, Jul 29, 2014 at 9:51 PM, Eric Blake wrote: > The output is on qemu's stderr. You are in control of what that stderr is. I don't get why we can configure -D /path/to/unique/file/name.log but we also have to redirect stderr (I didn't checked if the daemonize option was closing it). What's the purpose of this logfile option? -- William
Re: [Qemu-devel] qemu live migration error from 2.0 to 2.1
On Tue, Aug 5, 2014 at 8:57 PM, Dr. David Alan Gilbert
wrote:
> Can you confirm this is on the final 2.1 release (there was a fix that
> went in just around rc5).
for the receiver, I'm using 2.1
# qemu-system-x86_64 --version
QEMU emulator version 2.1.0, Copyright (c) 2003-2008 Fabrice Bellar
for the sender side, here is the qmp result:
(QEMU) query-version
{ u'return': { u'package': u'',
u'qemu': { u'major': 2, u'micro': 50, u'minor': 0}}}
> What's your command line on both ends?
the receiver:
qemu-system-x86_64 -m 2048 -cpu host,level=9 -nodefconfig -nodefaults
-nographic -readconfig /var/lib/qemu/VM_A/config -pidfile
/var/lib/qemu/VM_A/pid -serial pty -D /var/lib/qemu/VM_A/log -d
unimp,guest_errors -incoming tcp:0:32768
/var/lib/qemu/VM_A/config:
[name]
guest = "VM_A"
process = "VM_A"
[chardev "compat_monitor0"]
backend = "socket"
path = "/var/lib/qemu/VM_A/sock"
server = "on"
wait = "off"
[device]
driver = "virtio-balloon"
[rtc]
base = "utc"
[mon "compat_monitor0"]
mode = "control"
chardev = "compat_monitor0"
default = "on"
[machine]
kernel = "/boot/bzImage"
append = "root=/dev/sda console=ttyS0 ro"
accel = "kvm"
[device]
driver = "virtio-rng-pci"
[device "scsi0"]
driver = "virtio-scsi-pci"
hotplug = "on"
[...] vif config
[...] disk config
[smp-opts]
cpus = "2"
sockets = "1"
cores = "1"
threads = "1"
maxcpus = "12"
the sender has the exact same command (without tcp receiver) and also
the same config; I'm just issuing a migrate command through qmp.
--
William
[Qemu-devel] qemu live migration error from 2.0 to 2.1
Hello, For a qemu live migration from 2.0 to 2.1 I'm getting: qemu-system-x86_64: Length mismatch: /rom@etc/acpi/tables: 3000 in != 2 qemu-system-x86_64: Unknown ramblock "/table-loader", cannot accept migration qemu-system-x86_64: Ack, bad migration stream! qemu-system-x86_64: Illegal RAM offset f0e2d500f06000 qemu: warning: error while loading state for instance 0x0 of device 'ram' qemu-system-x86_64: load of migration failed: Invalid argument I was wondering if it was a bug or if I was supposed to do something to avoid this error. I saw the bug report for qemu1.7 but it's not my case. Regards, -- William
Re: [Qemu-devel] pidfile option in config file
On Thu, May 15, 2014 at 10:15 AM, Markus Armbruster wrote: > User interface bug: not all options are coded in a way that makes them > work with -readconfig. This includes -pidfile. Sorry! Thanks for the answer. Maybe I can try to send a patch one day or another. I wanted to make sure there was no reason for this current behavior. Regards, -- William
[Qemu-devel] pidfile option in config file
Hello, I'm using the `-pidfile` option in my qemu command line. Since I'm also using the `-readconfig` option I thought it was a good thing to include the pidfile option in my config file. Unfortunately I did not found any possibility to add such option in my config file. Is it something I could expect? Regards, -- William
Re: [Qemu-devel] [PATCH] Fix 'name' option to work with -readconfig
On Tue, May 6, 2014 at 1:15 PM, Dr. David Alan Gilbert (git) wrote: > From: "Dr. David Alan Gilbert" > > The 'name' option silently failed when used in config files > ( http://lists.gnu.org/archive/html/qemu-devel/2014-04/msg00378.html ) > > Signed-off-by: Dr. David Alan Gilbert > Reported-by: William Dauchy Please use: Reported-by: William Dauchy I have also successfully tested the patch Tested-by: William Dauchy Thanks, -- William
Re: [Qemu-devel] process naming not working when using a config file
Hello Dave, Thanks for your quick reply. On Wed, Apr 2, 2014 at 7:05 PM, Dr. David Alan Gilbert wrote: > You can add a launchpad entry if you like; however sicne I suspect > it's my rework of --name to use QemuOpts that broke it, I'll add it > to my list. If it's already on your todo list, that's ok for me. Thanks, -- William
[Qemu-devel] process naming not working when using a config file
Hello, I was using the qemu command line option: -name foo,process=foo in order to get a nice process naming on my linux box. and so I could do $ ps axco pid,command | grep 'foo' 4242 foo I switched to a config file with: [name] guest = "foo" process = "foo" but now the previous `ps` command is empty and the process name is qemu-system-x86 I guess these options are not taken in consideration. I am using the last git version of qemu. Should I write a bug report for this? Thanks, -- William
Re: [Qemu-devel] device_del id missing after blockdev-add
On Feb24 16:34, Stefan Hajnoczi wrote: > Also, it should probably be 'removable':true? oh true, did not mention this was a boolean > You forgot to give the device an ID. Could that be the problem here? yup I spotted that some days after and forgot to write an answer here. that's solved the issue. I was indeed confused with drive/id attributes. Thanks for you answer, I thought it my issue was drowned into the ML. -- William signature.asc Description: Digital signature
[Qemu-devel] device_del id missing after blockdev-add
Hello,
I'm starting qemu with the following config in order to test drive
hotremove and hotadd:
[drive "disk1"]
if = "none"
id = "disk1"
cache = "none"
aio = "native"
format = "raw"
file = "/dev/sda"
[device "disk1"]
driver = "scsi-hd"
drive = "disk1"
scsi-id = "1"
removable = "on"
vendor = "gandi.net"
dpofua = "off"
I'm now testing device removable without any problem:
(QEMU) device_del id=disk1
{ u'return': { }}
(QEMU)
{u'timestamp': {u'seconds': 1392645815, u'microseconds': 484557}, u'data':
{u'device': u'disk1', u'path': u'/machine/peripheral/disk1'}, u'event':
u'DEVICE_DELETED'}
then, I want to readd the disk, without anyproblem too (with the same
id):
{ "execute": "blockdev-add", "arguments": {'options' : {'driver': 'raw',
'id':'disk1', 'file': {'driver': 'file', 'filename': '/dev/sda'}}} }
{ "device_add", "arguments": {'driver':'scsi-hd', 'drive':'disk1', 'scsi-i':1,
'removable':on} }
The issue is when I want to hot remove the disk again:
(QEMU) device_del id=disk1
{ u'error': { u'class': u'DeviceNotFound',
u'desc': u"Device 'disk1' not found"}}
the output of query-block is the same everywhere:
{ u'device': u'disk1',
u'inserted': { u'backing_file_depth': 0,
u'bps': 0,
u'bps_rd': 0,
u'bps_wr': 0,
u'drv': u'raw',
u'encrypted': False,
u'encryption_key_missing': False,
u'file': u'/dev/sda',
u'image': { u'actual-size': 0,
u'dirty-flag': False,
u'filename': u'/dev/sda',
u'format': u'raw',
u'virtual-size':
3221225472},
u'iops': 0,
u'iops_rd': 0,
u'iops_wr': 0,
u'ro': False},
u'io-status': u'ok',
u'locked': False,
u'removable': True,
u'tray_open': False,
u'type': u'unknown'}]}
I guess blockdev-add is not storing the device details as it's done when
using the configuration file, i.e, id is not stored correctly when using
blockdev-add.
Should I consider this as a bug or I wait for the merge of blockdev-del
and ignore device_del command? In all cases I guess device_del should
work in this case too.
these tests were done using the last version available on the git repo
(using master branch)
Regards,
--
William
signature.asc
Description: Digital signature
Re: [Qemu-devel] [PATCH] ifname=xxx for -netdev bridge
On Mon, Jan 20, 2014 at 10:23 PM, Alexandre Kandalintsev wrote: > I was worried that the amount of changes would > turn the maintainers away from the patch. > > Another problem is that I think there is little demand > for this patch. > > But let's try to push it once again. Give me a week or > two and I'll submit a new version. ack; please cc me when re-submitting. Thanks, -- William
Re: [Qemu-devel] [PATCH] ifname=xxx for -netdev bridge
Hi Alexandre, On Mon, Mar 25, 2013 at 10:28 PM, Alexandre Kandalintsev wrote: > Ok, lets go this way. We will define patterns in bridge.conf like > ~~~ > allowifname vm* > ~~~ Do you have any news about this patch? Regards, -- William
Re: [Qemu-devel] [PATCH] tap: add the possibility to specify a tap prefix
On Jan14 19:24, Paolo Bonzini wrote: > See http://lists.gnu.org/archive/html/qemu-devel/2013-03/msg04279.html > and http://lists.gnu.org/archive/html/qemu-devel/2012-10/msg02149.html > for previous discussions on this topic. Thanks for pointing me this out, it's now clear. -- William signature.asc Description: Digital signature
Re: [Qemu-devel] [PATCH] tap: add the possibility to specify a tap prefix
Hello Paolo, Thanks for your quick reply. On Jan14 18:31, Paolo Bonzini wrote: > I think this was nacked already in the past. You would need to > implement some kind of ACL system like the one that is in place for > bridges. Without it, for example, you could hijack existing iptables rules. I don't get it; this does not change anything to the existing but permits to change the default "tap" string prefix. Am I missing something? -- William signature.asc Description: Digital signature
[Qemu-devel] [PATCH] tap: add the possibility to specify a tap prefix
this will permit to specify an interface prefix to the tap instead of the
default one ("tap")
this functionnality is useful when you need an easy way to find the
interfaces attached to a given virtual machine
example:
-net bridge,prefix=tapvmA. -net bridge,prefix=tapvmA.
will create `tapvmA.0` and `tapvmA.1`
`brctl show | grep vmA` will be an easy way to find the interfaces
attached to the vmA
Signed-off-by:
---
include/net/net.h| 1 +
net/tap.c| 18 --
qapi-schema.json | 3 ++-
qemu-bridge-helper.c | 9 +++--
qemu-options.hx | 3 ++-
5 files changed, 24 insertions(+), 10 deletions(-)
diff --git a/include/net/net.h b/include/net/net.h
index 11e1468..4cb0566 100644
--- a/include/net/net.h
+++ b/include/net/net.h
@@ -180,6 +180,7 @@ NetClientState *net_hub_port_find(int hub_id);
#define DEFAULT_NETWORK_DOWN_SCRIPT "/etc/qemu-ifdown"
#define DEFAULT_BRIDGE_HELPER CONFIG_QEMU_HELPERDIR "/qemu-bridge-helper"
#define DEFAULT_BRIDGE_INTERFACE "br0"
+#define DEFAULT_BRIDGE_PREFIX "tap"
void qdev_set_nic_properties(DeviceState *dev, NICInfo *nd);
diff --git a/net/tap.c b/net/tap.c
index 39c1cda..667cf17 100644
--- a/net/tap.c
+++ b/net/tap.c
@@ -419,7 +419,8 @@ static int recv_fd(int c)
return len;
}
-static int net_bridge_run_helper(const char *helper, const char *bridge)
+static int net_bridge_run_helper(const char *helper, const char *bridge,
+ const char *prefix)
{
sigset_t oldmask, mask;
int pid, status;
@@ -441,7 +442,8 @@ static int net_bridge_run_helper(const char *helper, const
char *bridge)
int open_max = sysconf(_SC_OPEN_MAX), i;
char fd_buf[6+10];
char br_buf[6+IFNAMSIZ] = {0};
-char helper_cmd[PATH_MAX + sizeof(fd_buf) + sizeof(br_buf) + 15];
+char pr_buf[6+IFNAMSIZ] = {0};
+char helper_cmd[PATH_MAX + sizeof(fd_buf) + sizeof(br_buf) +
sizeof(pr_buf) + 15];
for (i = 0; i < open_max; i++) {
if (i != STDIN_FILENO &&
@@ -453,6 +455,7 @@ static int net_bridge_run_helper(const char *helper, const
char *bridge)
}
snprintf(fd_buf, sizeof(fd_buf), "%s%d", "--fd=", sv[1]);
+snprintf(pr_buf, sizeof(br_buf), "%s%s", "--tap-prefix=", prefix);
if (strrchr(helper, ' ') || strrchr(helper, '\t')) {
/* assume helper is a command */
@@ -481,6 +484,7 @@ static int net_bridge_run_helper(const char *helper, const
char *bridge)
*parg++ = (char *)"--use-vnet";
*parg++ = fd_buf;
*parg++ = br_buf;
+*parg++ = pr_buf;
*parg++ = NULL;
execv(helper, args);
@@ -519,7 +523,7 @@ int net_init_bridge(const NetClientOptions *opts, const
char *name,
NetClientState *peer)
{
const NetdevBridgeOptions *bridge;
-const char *helper, *br;
+const char *helper, *br, *prefix;
TAPState *s;
int fd, vnet_hdr;
@@ -528,9 +532,10 @@ int net_init_bridge(const NetClientOptions *opts, const
char *name,
bridge = opts->bridge;
helper = bridge->has_helper ? bridge->helper : DEFAULT_BRIDGE_HELPER;
+prefix = bridge->has_prefix ? bridge->prefix : DEFAULT_BRIDGE_PREFIX;
br = bridge->has_br ? bridge->br : DEFAULT_BRIDGE_INTERFACE;
-fd = net_bridge_run_helper(helper, br);
+fd = net_bridge_run_helper(helper, br, prefix);
if (fd == -1) {
return -1;
}
@@ -728,7 +733,7 @@ int net_init_tap(const NetClientOptions *opts, const char
*name,
tap->has_vnet_hdr || tap->has_helper || tap->has_queues ||
tap->has_vhostfd) {
error_report("ifname=, script=, downscript=, vnet_hdr=, "
- "helper=, queues=, and vhostfd= "
+ "helper=, queues=, and vhostfd="
"are invalid with fds=");
return -1;
}
@@ -773,7 +778,8 @@ int net_init_tap(const NetClientOptions *opts, const char
*name,
return -1;
}
-fd = net_bridge_run_helper(tap->helper, DEFAULT_BRIDGE_INTERFACE);
+fd = net_bridge_run_helper(tap->helper, DEFAULT_BRIDGE_INTERFACE,
+ DEFAULT_BRIDGE_PREFIX);
if (fd == -1) {
return -1;
}
diff --git a/qapi-schema.json b/qapi-schema.json
index f27c48a..83d8895 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -3028,7 +3028,8 @@
{ 'type': 'NetdevBridgeOptions',
'data': {
'*br': 'str',
-'*helper': 'str' } }
+'*helper': 'str',
+'*prefix': 'str'} }
##
# @NetdevHubPortOptions
diff --git a/qemu-bridge-helper.c b/qemu-bridge-helper.c
index 6a0974e..6eef43b 100644
--- a/qemu-bridge-helper.c
+++ b/qemu-bridge-helper.c
@@ -67,7 +67,8 @@ typedef QSIMPLEQ_HEAD(ACLList, ACLRule) ACLList;
static void usage(void)
{
fprintf(stderr,
-"Usage: qemu-bridge-helper [--use-vnet] --br=bridge
--fd=unixfd\n");
+"Usage: qemu-brid
Re: [Qemu-devel] [PATCH] Add bios-256k.bin to BLOBS on Makefile
On Mon, Jan 6, 2014 at 2:13 PM, Peter Maydell wrote: > Ping -- who's going to take this patch? Maybe it should > go via -trivial? +1 still waiting for this merge -- William
Re: [Qemu-devel] [PATCH] Add bios-256k.bin to BLOBS on Makefile
On Tue, Dec 10, 2013 at 12:33 AM, Eduardo Habkost wrote: > The default machine-type (pc-i440fx-2.0) now requires bios-256k.bin, but > "make install" isn't installing it, so qemu-system-x86_64 won't run out > of the box. Add it to BLOBS so it gets installed. it does fix my issue on my qemu-system-x86_64 test platform Tested-by: William Dauchy Thanks, -- William
[Qemu-devel] Re: vcpu hotplug status
On Wed, Mar 16, 2011 at 11:17 AM, William Dauchy wrote: > I wanted to test vcpu hotplug. When adding a cpu I'm getting > "qdev_create_from_info: Assertion `bus->allow_hotplug' failed." > I went through a discussion about the subject here > http://lists.nongnu.org/archive/html/qemu-devel/2010-08/msg00999.html > To make sure whether it was working, I hard-coded "allow_hotplug = 1"; > the guest is now able to have more vpcus without any trouble (removing > vcpus did not seem to work though). > Since it definitively not a solution, I wanted to have a status about > the subject or if I was missing something in my configuration since it > works with a dirty workaround. > I would be also pleased to get some tips to fix the code. Any thoughts? Or perhaps my message was lost among patches... -- William
[Qemu-devel] vcpu hotplug status
Hi, I wanted to test vcpu hotplug. When adding a cpu I'm getting "qdev_create_from_info: Assertion `bus->allow_hotplug' failed." I went through a discussion about the subject here http://lists.nongnu.org/archive/html/qemu-devel/2010-08/msg00999.html To make sure whether it was working, I hard-coded "allow_hotplug = 1"; the guest is now able to have more vpcus without any trouble (removing vcpus did not seem to work though). Since it definitively not a solution, I wanted to have a status about the subject or if I was missing something in my configuration since it works with a dirty workaround. I would be also pleased to get some tips to fix the code. Regards, -- William
Re: [Qemu-devel] [PATCH] moving eeprom initialization
On Sun, Mar 6, 2011 at 9:38 PM, Gerhard Wiesinger wrote: > AMD fix is now upstream. Please merge it. oh sorry. did not see; will do. -- William
[Qemu-devel] [PATCH] moving eeprom initialization
The initialization should not be only on reset but also when initializing
the device.
It resolves a bug when hot plugging a pci network device: the mac address
was always null.
Signed-off-by: William Dauchy
Signed-off-by: Wen Congyang
---
hw/pcnet.c | 27 ++-
hw/rtl8139.c | 24
2 files changed, 26 insertions(+), 25 deletions(-)
diff --git a/hw/pcnet.c b/hw/pcnet.c
index db52dc5..4e30e9c 100644
--- a/hw/pcnet.c
+++ b/hw/pcnet.c
@@ -1557,19 +1557,6 @@ uint32_t pcnet_bcr_readw(PCNetState *s, uint32_t rap)
void pcnet_h_reset(void *opaque)
{
PCNetState *s = opaque;
-int i;
-uint16_t checksum;
-
-/* Initialize the PROM */
-
-memcpy(s->prom, s->conf.macaddr.a, 6);
-s->prom[12] = s->prom[13] = 0x00;
-s->prom[14] = s->prom[15] = 0x57;
-
-for (i = 0,checksum = 0; i < 16; i++)
-checksum += s->prom[i];
-*(uint16_t *)&s->prom[12] = cpu_to_le16(checksum);
-
s->bcr[BCR_MSRDA] = 0x0005;
s->bcr[BCR_MSWRA] = 0x0005;
@@ -1736,6 +1723,9 @@ void pcnet_common_cleanup(PCNetState *d)
int pcnet_common_init(DeviceState *dev, PCNetState *s, NetClientInfo *info)
{
+int i;
+uint16_t checksum;
+
s->poll_timer = qemu_new_timer(vm_clock, pcnet_poll_timer, s);
qemu_macaddr_default_if_unset(&s->conf.macaddr);
@@ -1744,5 +1734,16 @@ int pcnet_common_init(DeviceState *dev, PCNetState *s,
NetClientInfo *info)
add_boot_device_path(s->conf.bootindex, dev, "/ethernet-phy@0");
+/* Initialize the PROM */
+
+memcpy(s->prom, s->conf.macaddr.a, 6);
+s->prom[12] = s->prom[13] = 0x00;
+s->prom[14] = s->prom[15] = 0x57;
+
+for (i = 0, checksum = 0; i < 16; i++) {
+checksum += s->prom[i];
+}
+*(uint16_t *)&s->prom[12] = cpu_to_le16(checksum);
+
return 0;
}
diff --git a/hw/rtl8139.c b/hw/rtl8139.c
index a22530c..8356d5a 100644
--- a/hw/rtl8139.c
+++ b/hw/rtl8139.c
@@ -1189,18 +1189,6 @@ static void rtl8139_reset(DeviceState *d)
rtl8139_update_irq(s);
-/* prepare eeprom */
-s->eeprom.contents[0] = 0x8129;
-#if 1
-// PCI vendor and device ID should be mirrored here
-s->eeprom.contents[1] = PCI_VENDOR_ID_REALTEK;
-s->eeprom.contents[2] = PCI_DEVICE_ID_REALTEK_8139;
-#endif
-
-s->eeprom.contents[7] = s->conf.macaddr.a[0] | s->conf.macaddr.a[1] << 8;
-s->eeprom.contents[8] = s->conf.macaddr.a[2] | s->conf.macaddr.a[3] << 8;
-s->eeprom.contents[9] = s->conf.macaddr.a[4] | s->conf.macaddr.a[5] << 8;
-
/* mark all status registers as owned by host */
for (i = 0; i < 4; ++i)
{
@@ -3392,6 +3380,18 @@ static int pci_rtl8139_init(PCIDevice *dev)
qemu_macaddr_default_if_unset(&s->conf.macaddr);
+/* prepare eeprom */
+s->eeprom.contents[0] = 0x8129;
+#if 1
+/* PCI vendor and device ID should be mirrored here */
+s->eeprom.contents[1] = PCI_VENDOR_ID_REALTEK;
+s->eeprom.contents[2] = PCI_DEVICE_ID_REALTEK_8139;
+#endif
+
+s->eeprom.contents[7] = s->conf.macaddr.a[0] | s->conf.macaddr.a[1] << 8;
+s->eeprom.contents[8] = s->conf.macaddr.a[2] | s->conf.macaddr.a[3] << 8;
+s->eeprom.contents[9] = s->conf.macaddr.a[4] | s->conf.macaddr.a[5] << 8;
+
s->nic = qemu_new_nic(&net_rtl8139_info, &s->conf,
dev->qdev.info->name, dev->qdev.id, s);
qemu_format_nic_info_str(&s->nic->nc, s->conf.macaddr.a);
--
1.7.2.3
[Qemu-devel] [PATCH] moving eeprom initialization
The initialization should not be only on reset but also when initializing
the device.
It resolves a bug when hot plugging a pci network device: the mac address
was always null.
Signed-off-by: William Dauchy
Signed-off-by: Wen Congyang
---
hw/pcnet.c | 59 +
hw/rtl8139.c | 23 ++---
2 files changed, 41 insertions(+), 41 deletions(-)
diff --git a/hw/pcnet.c b/hw/pcnet.c
index 6dfdcc4..d3d5661 100644
--- a/hw/pcnet.c
+++ b/hw/pcnet.c
@@ -1557,35 +1557,6 @@ uint32_t pcnet_bcr_readw(PCNetState *s, uint32_t rap)
void pcnet_h_reset(void *opaque)
{
PCNetState *s = opaque;
-int i;
-uint16_t checksum;
-
-/* Initialize the PROM */
-
-/*
- Datasheet: http://pdfdata.datasheetsite.com/web/24528/AM79C970A.pdf
- page 95
-*/
-memcpy(s->prom, s->conf.macaddr.a, 6);
-/* Reserved Location: must be 00h */
-s->prom[6] = s->prom[7] = 0x00;
-/* Reserved Location: must be 00h */
-s->prom[8] = 0x00;
-/* Hardware ID: must be 11h if compatibility to AMD drivers is desired */
-s->prom[9] = 0x11;
-/* User programmable space, init with 0 */
-s->prom[10] = s->prom[11] = 0x00;
-/* LSByte of two-byte checksum, which is the sum of bytes 00h-0Bh
- and bytes 0Eh and 0Fh, must therefore be initialized with 0! */
-s->prom[12] = s->prom[13] = 0x00;
-/* Must be ASCII W (57h) if compatibility to AMD
- driver software is desired */
-s->prom[14] = s->prom[15] = 0x57;
-
-for (i = 0,checksum = 0; i < 16; i++)
-checksum += s->prom[i];
-*(uint16_t *)&s->prom[12] = cpu_to_le16(checksum);
-
s->bcr[BCR_MSRDA] = 0x0005;
s->bcr[BCR_MSWRA] = 0x0005;
@@ -1752,6 +1723,9 @@ void pcnet_common_cleanup(PCNetState *d)
int pcnet_common_init(DeviceState *dev, PCNetState *s, NetClientInfo *info)
{
+int i;
+uint16_t checksum;
+
s->poll_timer = qemu_new_timer(vm_clock, pcnet_poll_timer, s);
qemu_macaddr_default_if_unset(&s->conf.macaddr);
@@ -1760,5 +1734,32 @@ int pcnet_common_init(DeviceState *dev, PCNetState *s,
NetClientInfo *info)
add_boot_device_path(s->conf.bootindex, dev, "/ethernet-phy@0");
+/* Initialize the PROM */
+
+/*
+ Datasheet: http://pdfdata.datasheetsite.com/web/24528/AM79C970A.pdf
+ page 95
+*/
+memcpy(s->prom, s->conf.macaddr.a, 6);
+/* Reserved Location: must be 00h */
+s->prom[6] = s->prom[7] = 0x00;
+/* Reserved Location: must be 00h */
+s->prom[8] = 0x00;
+/* Hardware ID: must be 11h if compatibility to AMD drivers is desired */
+s->prom[9] = 0x11;
+/* User programmable space, init with 0 */
+s->prom[10] = s->prom[11] = 0x00;
+/* LSByte of two-byte checksum, which is the sum of bytes 00h-0Bh
+ and bytes 0Eh and 0Fh, must therefore be initialized with 0! */
+s->prom[12] = s->prom[13] = 0x00;
+/* Must be ASCII W (57h) if compatibility to AMD
+ driver software is desired */
+s->prom[14] = s->prom[15] = 0x57;
+
+for (i = 0, checksum = 0; i < 16; i++) {
+checksum += s->prom[i];
+}
+*(uint16_t *)&s->prom[12] = cpu_to_le16(checksum);
+
return 0;
}
diff --git a/hw/rtl8139.c b/hw/rtl8139.c
index a22530c..7a87522 100644
--- a/hw/rtl8139.c
+++ b/hw/rtl8139.c
@@ -1189,18 +1189,6 @@ static void rtl8139_reset(DeviceState *d)
rtl8139_update_irq(s);
-/* prepare eeprom */
-s->eeprom.contents[0] = 0x8129;
-#if 1
-// PCI vendor and device ID should be mirrored here
-s->eeprom.contents[1] = PCI_VENDOR_ID_REALTEK;
-s->eeprom.contents[2] = PCI_DEVICE_ID_REALTEK_8139;
-#endif
-
-s->eeprom.contents[7] = s->conf.macaddr.a[0] | s->conf.macaddr.a[1] << 8;
-s->eeprom.contents[8] = s->conf.macaddr.a[2] | s->conf.macaddr.a[3] << 8;
-s->eeprom.contents[9] = s->conf.macaddr.a[4] | s->conf.macaddr.a[5] << 8;
-
/* mark all status registers as owned by host */
for (i = 0; i < 4; ++i)
{
@@ -3392,6 +3380,17 @@ static int pci_rtl8139_init(PCIDevice *dev)
qemu_macaddr_default_if_unset(&s->conf.macaddr);
+/* prepare eeprom */
+s->eeprom.contents[0] = 0x8129;
+#if 1
+/* PCI vendor and device ID should be mirrored here */
+s->eeprom.contents[1] = PCI_VENDOR_ID_REALTEK;
+s->eeprom.contents[2] = PCI_DEVICE_ID_REALTEK_8139;
+#endif
+s->eeprom.contents[7] = s->conf.macaddr.a[0] | s->conf.macaddr.a[1] << 8;
+s->eeprom.contents[8] = s->conf.macaddr.a[2] | s->conf.macaddr.a[3] << 8;
+s->eeprom.contents[9] = s->conf.macaddr.a[4] | s->conf.macaddr.a[5] << 8;
+
s->nic = qemu_new_nic(&net_rtl8139_info, &s->conf,
dev->qdev.info->name, dev->qdev.id, s);
qemu_format_nic_info_str(&s->nic->nc, s->conf.macaddr.a);
--
1.7.2.3
Re: [Qemu-devel] Re: [PATCH] moving eeprom initialization
On Wed, Mar 2, 2011 at 7:28 PM, Gerhard Wiesinger wrote: > Your patch should be based on fixes for correct EEPROM initialization, see > for details: http://www.mail-archive.com/qemu-devel@nongnu.org/msg56414.html This patch is not yet integrated upstream. I will correct it if needed. -- William
[Qemu-devel] Re: [PATCH] moving eeprom initialization
On Wed, Mar 2, 2011 at 2:36 PM, William Dauchy wrote:
> The initialization should not be only on reset but also when initializing
> the device.
> It resolves a bug when hot plugging a pci network device: the mac address
> was always null.
> ---
> hw/pcnet.c | 27 ++-
> hw/rtl8139.c | 24
> 2 files changed, 26 insertions(+), 25 deletions(-)
>
> diff --git a/hw/pcnet.c b/hw/pcnet.c
> index db52dc5..4e30e9c 100644
> --- a/hw/pcnet.c
> +++ b/hw/pcnet.c
> @@ -1557,19 +1557,6 @@ uint32_t pcnet_bcr_readw(PCNetState *s, uint32_t rap)
> void pcnet_h_reset(void *opaque)
> {
> PCNetState *s = opaque;
> - int i;
> - uint16_t checksum;
> -
> - /* Initialize the PROM */
> -
> - memcpy(s->prom, s->conf.macaddr.a, 6);
> - s->prom[12] = s->prom[13] = 0x00;
> - s->prom[14] = s->prom[15] = 0x57;
> -
> - for (i = 0,checksum = 0; i < 16; i++)
> - checksum += s->prom[i];
> - *(uint16_t *)&s->prom[12] = cpu_to_le16(checksum);
> -
>
> s->bcr[BCR_MSRDA] = 0x0005;
> s->bcr[BCR_MSWRA] = 0x0005;
> @@ -1736,6 +1723,9 @@ void pcnet_common_cleanup(PCNetState *d)
>
> int pcnet_common_init(DeviceState *dev, PCNetState *s, NetClientInfo *info)
> {
> + int i;
> + uint16_t checksum;
> +
> s->poll_timer = qemu_new_timer(vm_clock, pcnet_poll_timer, s);
>
> qemu_macaddr_default_if_unset(&s->conf.macaddr);
> @@ -1744,5 +1734,16 @@ int pcnet_common_init(DeviceState *dev, PCNetState *s,
> NetClientInfo *info)
>
> add_boot_device_path(s->conf.bootindex, dev, "/ethernet-phy@0");
>
> + /* Initialize the PROM */
> +
> + memcpy(s->prom, s->conf.macaddr.a, 6);
> + s->prom[12] = s->prom[13] = 0x00;
> + s->prom[14] = s->prom[15] = 0x57;
> +
> + for (i = 0, checksum = 0; i < 16; i++) {
> + checksum += s->prom[i];
> + }
> + *(uint16_t *)&s->prom[12] = cpu_to_le16(checksum);
> +
> return 0;
> }
> diff --git a/hw/rtl8139.c b/hw/rtl8139.c
> index a22530c..8356d5a 100644
> --- a/hw/rtl8139.c
> +++ b/hw/rtl8139.c
> @@ -1189,18 +1189,6 @@ static void rtl8139_reset(DeviceState *d)
>
> rtl8139_update_irq(s);
>
> - /* prepare eeprom */
> - s->eeprom.contents[0] = 0x8129;
> -#if 1
> - // PCI vendor and device ID should be mirrored here
> - s->eeprom.contents[1] = PCI_VENDOR_ID_REALTEK;
> - s->eeprom.contents[2] = PCI_DEVICE_ID_REALTEK_8139;
> -#endif
> -
> - s->eeprom.contents[7] = s->conf.macaddr.a[0] | s->conf.macaddr.a[1] << 8;
> - s->eeprom.contents[8] = s->conf.macaddr.a[2] | s->conf.macaddr.a[3] << 8;
> - s->eeprom.contents[9] = s->conf.macaddr.a[4] | s->conf.macaddr.a[5] << 8;
> -
> /* mark all status registers as owned by host */
> for (i = 0; i < 4; ++i)
> {
> @@ -3392,6 +3380,18 @@ static int pci_rtl8139_init(PCIDevice *dev)
>
> qemu_macaddr_default_if_unset(&s->conf.macaddr);
>
> + /* prepare eeprom */
> + s->eeprom.contents[0] = 0x8129;
> +#if 1
> + /* PCI vendor and device ID should be mirrored here */
> + s->eeprom.contents[1] = PCI_VENDOR_ID_REALTEK;
> + s->eeprom.contents[2] = PCI_DEVICE_ID_REALTEK_8139;
> +#endif
> +
> + s->eeprom.contents[7] = s->conf.macaddr.a[0] | s->conf.macaddr.a[1] << 8;
> + s->eeprom.contents[8] = s->conf.macaddr.a[2] | s->conf.macaddr.a[3] << 8;
> + s->eeprom.contents[9] = s->conf.macaddr.a[4] | s->conf.macaddr.a[5] << 8;
> +
> s->nic = qemu_new_nic(&net_rtl8139_info, &s->conf,
> dev->qdev.info->name, dev->qdev.id, s);
> qemu_format_nic_info_str(&s->nic->nc, s->conf.macaddr.a);
> --
> William
hm I just noticed your correction here
http://lists.gnu.org/archive/html/qemu-devel/2011-02/msg03232.html ;
sorry
Anyway, I tested my version and it works fine.
Regards,
--
William
[Qemu-devel] [PATCH] moving eeprom initialization
The initialization should not be only on reset but also when initializing
the device.
It resolves a bug when hot plugging a pci network device: the mac address
was always null.
---
hw/pcnet.c | 27 ++-
hw/rtl8139.c | 24
2 files changed, 26 insertions(+), 25 deletions(-)
diff --git a/hw/pcnet.c b/hw/pcnet.c
index db52dc5..4e30e9c 100644
--- a/hw/pcnet.c
+++ b/hw/pcnet.c
@@ -1557,19 +1557,6 @@ uint32_t pcnet_bcr_readw(PCNetState *s, uint32_t rap)
void pcnet_h_reset(void *opaque)
{
PCNetState *s = opaque;
-int i;
-uint16_t checksum;
-
-/* Initialize the PROM */
-
-memcpy(s->prom, s->conf.macaddr.a, 6);
-s->prom[12] = s->prom[13] = 0x00;
-s->prom[14] = s->prom[15] = 0x57;
-
-for (i = 0,checksum = 0; i < 16; i++)
-checksum += s->prom[i];
-*(uint16_t *)&s->prom[12] = cpu_to_le16(checksum);
-
s->bcr[BCR_MSRDA] = 0x0005;
s->bcr[BCR_MSWRA] = 0x0005;
@@ -1736,6 +1723,9 @@ void pcnet_common_cleanup(PCNetState *d)
int pcnet_common_init(DeviceState *dev, PCNetState *s, NetClientInfo *info)
{
+int i;
+uint16_t checksum;
+
s->poll_timer = qemu_new_timer(vm_clock, pcnet_poll_timer, s);
qemu_macaddr_default_if_unset(&s->conf.macaddr);
@@ -1744,5 +1734,16 @@ int pcnet_common_init(DeviceState *dev, PCNetState *s,
NetClientInfo *info)
add_boot_device_path(s->conf.bootindex, dev, "/ethernet-phy@0");
+/* Initialize the PROM */
+
+memcpy(s->prom, s->conf.macaddr.a, 6);
+s->prom[12] = s->prom[13] = 0x00;
+s->prom[14] = s->prom[15] = 0x57;
+
+for (i = 0, checksum = 0; i < 16; i++) {
+checksum += s->prom[i];
+}
+*(uint16_t *)&s->prom[12] = cpu_to_le16(checksum);
+
return 0;
}
diff --git a/hw/rtl8139.c b/hw/rtl8139.c
index a22530c..8356d5a 100644
--- a/hw/rtl8139.c
+++ b/hw/rtl8139.c
@@ -1189,18 +1189,6 @@ static void rtl8139_reset(DeviceState *d)
rtl8139_update_irq(s);
-/* prepare eeprom */
-s->eeprom.contents[0] = 0x8129;
-#if 1
-// PCI vendor and device ID should be mirrored here
-s->eeprom.contents[1] = PCI_VENDOR_ID_REALTEK;
-s->eeprom.contents[2] = PCI_DEVICE_ID_REALTEK_8139;
-#endif
-
-s->eeprom.contents[7] = s->conf.macaddr.a[0] | s->conf.macaddr.a[1] << 8;
-s->eeprom.contents[8] = s->conf.macaddr.a[2] | s->conf.macaddr.a[3] << 8;
-s->eeprom.contents[9] = s->conf.macaddr.a[4] | s->conf.macaddr.a[5] << 8;
-
/* mark all status registers as owned by host */
for (i = 0; i < 4; ++i)
{
@@ -3392,6 +3380,18 @@ static int pci_rtl8139_init(PCIDevice *dev)
qemu_macaddr_default_if_unset(&s->conf.macaddr);
+/* prepare eeprom */
+s->eeprom.contents[0] = 0x8129;
+#if 1
+/* PCI vendor and device ID should be mirrored here */
+s->eeprom.contents[1] = PCI_VENDOR_ID_REALTEK;
+s->eeprom.contents[2] = PCI_DEVICE_ID_REALTEK_8139;
+#endif
+
+s->eeprom.contents[7] = s->conf.macaddr.a[0] | s->conf.macaddr.a[1] << 8;
+s->eeprom.contents[8] = s->conf.macaddr.a[2] | s->conf.macaddr.a[3] << 8;
+s->eeprom.contents[9] = s->conf.macaddr.a[4] | s->conf.macaddr.a[5] << 8;
+
s->nic = qemu_new_nic(&net_rtl8139_info, &s->conf,
dev->qdev.info->name, dev->qdev.id, s);
qemu_format_nic_info_str(&s->nic->nc, s->conf.macaddr.a);
--
William
[Qemu-devel] null mac address
Hi, I got some troubles hot plugging network pci devices. An attach works as expected but the mac address is still set to "00:00:00:00:00:00" on the guest machine. I have to reboot the guest to get the correct mac address. I first tried through libvirt with: # virsh attach-interface dom0 network default --mac 52:54:00:f6:84:ba and then through qemu monitor to make sure that it wasn't a libvirt issue: device_add rtl8139 or device_add rtl8139,mac=01:02:03:04:05:06 Always the same result on the guest. A device info on qemu give the correct result, that is to say, with a correct mac address. I went through rtl8139.c and saw that the mac address is set in `rtl8139_reset`. This function was called in `pci_rtl8139_init` but removed since c169998802505c244b8bcad562633f29de7d74a4 commit, because it doesn't make sense to call it when the virtual machine is shutdown. I'm now wondering where I am supposed to call this reset function when live attaching a pci device. I think it could fix the mac address issue. I will be very pleased to receive some tips to create a patch for this issue. Regards, -- William
Re: [Qemu-devel] [PATCH] Remove a detached device from qemu_device_opts.
Hi Minoru, On Tue, Feb 15, 2011 at 3:32 AM, Minoru Usui wrote: > I can reproduce, too. > But strangely, it don't occur in case of loading acpiphp driver > to the guest VM on below environment. > > Host : RHEL6.0 > Guest: RHEL5.5 > > Unfortunately, I'm not familiar with qemu-kvm. > I investigated below questions about this problem, but I couldn't resolve > them. > > - How to call qdev_free() asynchronously. (How should we fix this problem) > - Why it don't occur with acpiphp driver > > If anyone knows answer of above questions or its clue, please let me know. If fact this is not a bug. `qdev_free` is called when the acpi detach succeed in `pciej_write`. The virtual machine has to correctly support acpi signals. Please read the explanation from Markus Armbruster on http://lists.nongnu.org/archive/html/qemu-devel/2011-02/msg02637.html Regards, -- William
Re: [Qemu-devel] [PATCH] `qdev_free` when unplug a pci device
Hi Markus, On Wed, Feb 23, 2011 at 9:30 AM, Markus Armbruster wrote: > I don't think this patch is correct. Let me explain. > > Device hot unplug is *not* guaranteed to succeed. > > For some buses, such as USB, it always succeeds immediately, i.e. when > the device_del monitor command finishes, the device is gone. Live is > good. > > But for PCI, device_del merely initiates the ACPI unplug rain dance. It > doesn't wait for the dance to complete. Why? The dance can take an > unpredictable amount of time, including forever. > > Problem: Subsequent device_add can fail if it reuses the qdev ID or PCI > slot, and the unplug has not yet completed (race condition), or it > failed. Yes, Virginia, PCI hotplug *can* fail. > > When unplug succeeds, the qdev is automatically destroyed. > pciej_write() does that for PIIX4. Looks like pcie_cap_slot_event() > does it for PCIE. > > Your patch adds a *second* qdev_free(). No good. Thanks for the complete explanation. I now understand my mistake and find out why it wasn't working as expected. On a Linux virtual machine I forgot to load the `acpiphp` module which makes the pci device disappear when doing a detach. I thought that, even without this module the detach should have freed the corresponding device on qemu side, regardless if the virtual machine was supporting or not acpi signals. Please ignore my patch. Regards, -- William
[Qemu-devel] [PATCH] `qdev_free` when unplug a pci device
`qdev_free` when unplug a pci device
It resolves a bug when detaching/attaching a network device
# virsh detach-interface dom0 network --mac 52:54:00:f6:84:ba
Interface detached successfully
# virsh attach-interface dom0 network default --mac 52:54:00:f6:84:ba
error: Failed to attach interface
error: internal error unable to execute QEMU command 'device_add': Duplicate
ID 'net0' for device
A detached pci device was not freed of the list `qemu_device_opts`
---
hw/pci.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/hw/pci.c b/hw/pci.c
index 8b76cea..1e9a8f0 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -1671,13 +1671,16 @@ static int pci_unplug_device(DeviceState *qdev)
{
PCIDevice *dev = DO_UPCAST(PCIDevice, qdev, qdev);
PCIDeviceInfo *info = container_of(qdev->info, PCIDeviceInfo, qdev);
+int unplug;
if (info->no_hotplug) {
qerror_report(QERR_DEVICE_NO_HOTPLUG, info->qdev.name);
return -1;
}
-return dev->bus->hotplug(dev->bus->hotplug_qdev, dev,
+unplug = dev->bus->hotplug(dev->bus->hotplug_qdev, dev,
PCI_HOTPLUG_DISABLED);
+qdev_free(qdev);
+return unplug;
}
void pci_qdev_register(PCIDeviceInfo *info)
--
William
Re: [Qemu-devel] [PATCH] Remove a detached device from qemu_device_opts.
Hi, On Mon, Feb 7, 2011 at 3:40 PM, William Dauchy wrote: > On Thu, 2011-01-27 at 18:00 +0900, Ken'ichi Ohmichi wrote: >> Hi, >> >> When I tried to attach the interface after detaching the same interface, >> the virsh command output the following and it failed: >> >> # virsh detach-interface Domain01 network --mac 52:54:00:0d:78:92 >> Interface detached successfully >> >> # virsh attach-interface Domain01 network default --mac 52:54:00:0d:78:92 >> error: Failed to attach interface >> error: internal error unable to execute QEMU command 'device_add': >> Duplicate ID 'net0' for device >> # >> >> The reason is that a detached device is not removed from the list >> "qemu_device_opts", and this patch fixes it. >> Signed-off-by: Ken'ichi Ohmichi >> --- >> --- a/hw/qdev.c 2011-01-27 17:42:25.0 +0900 >> +++ b/hw/qdev.c 2011-01-27 17:43:46.0 +0900 >> @@ -905,6 +905,8 @@ int do_device_del(Monitor *mon, const QD >> qerror_report(QERR_DEVICE_NOT_FOUND, id); >> return -1; >> } >> + qemu_opts_del(qemu_opts_find(&qemu_device_opts, id)); >> + >> return qdev_unplug(dev); >> } > > I successfully applied and tested this patch. It resolves the attach > problem. > I was wondering if it was going to be merged upstream? Regards, -- William
Re: [Qemu-devel] [PATCH] Remove a detached device from qemu_device_opts.
On Thu, 2011-01-27 at 18:00 +0900, Ken'ichi Ohmichi wrote: > Hi, > > When I tried to attach the interface after detaching the same interface, > the virsh command output the following and it failed: > > # virsh detach-interface Domain01 network --mac 52:54:00:0d:78:92 > Interface detached successfully > > # virsh attach-interface Domain01 network default --mac 52:54:00:0d:78:92 > error: Failed to attach interface > error: internal error unable to execute QEMU command 'device_add': > Duplicate ID 'net0' for device > # > > The reason is that a detached device is not removed from the list > "qemu_device_opts", and this patch fixes it. > Signed-off-by: Ken'ichi Ohmichi > --- > --- a/hw/qdev.c 2011-01-27 17:42:25.0 +0900 > +++ b/hw/qdev.c 2011-01-27 17:43:46.0 +0900 > @@ -905,6 +905,8 @@ int do_device_del(Monitor *mon, const QD > qerror_report(QERR_DEVICE_NOT_FOUND, id); > return -1; > } > +qemu_opts_del(qemu_opts_find(&qemu_device_opts, id)); > + > return qdev_unplug(dev); > } I successfully applied and tested this patch. It resolves the attach problem. -- William
