Re: [Qemu-devel] SMM error in 2.4 changelog

[William Dauchy]

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

[William Dauchy]

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

[William Dauchy]

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

[William Dauchy]

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 will...@gandi.net
 Signed-off-by: Marcel Apfelbaum mar...@redhat.com
 ---
 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

[William Dauchy]

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

[William Dauchy]

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

Re: [Qemu-devel] migration from qemu2.1.2 to qemu2.2

[William Dauchy]

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

[William Dauchy]

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

[William Dauchy]

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] [Bug 1358287] Re: -readconfig file doesn't interpret memory size correctly

[William Dauchy]

No news about it in qemu2.2?

Thanks,
-- 
William

[Qemu-devel] readconfig with machine section and type option ignored

[William Dauchy]

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] migration from qemu2.1.2 to qemu2.2

[William Dauchy]

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

[William Dauchy]

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

[William Dauchy]

+ 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

[William Dauchy]

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

[Qemu-devel] migration from qemu2.1.2 to qemu2.0

[William Dauchy]

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] migration from qemu2.1.2 to qemu2.0

[William Dauchy]

(sorry bad subject, I meant qemu2.2)

-- 
William


signature.asc
Description: Digital signature

Re: [Qemu-devel] migration from qemu2.1.2 to qemu2.2

[William Dauchy]

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] hotremoving a disk qmp/hmp

[William Dauchy]

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

[Qemu-devel] hotremoving a disk qmp/hmp

[William Dauchy]

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] hotremoving a disk qmp/hmp

[William Dauchy]

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': [   {   

Re: [Qemu-devel] [PATCH v2] RFC: Add blockdev-del QMP command

[William Dauchy]

Hi,

On Wed, Feb 12, 2014 at 6:36 PM, Ian Main im...@redhat.com 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

[William Dauchy]

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

[William Dauchy]

On Sep02 18:07, Michael S. Tsirkin wrote:
 From: Jason Wang jasow...@redhat.com
 
 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) zhangji...@huawei.com
 Tested-by: William Dauchy wdau...@gmail.com

please use:

Tested-by: William Dauchy will...@gandi.net

 Signed-off-by: Michael S. Tsirkin m...@redhat.com
 Signed-off-by: Jason Wang jasow...@redhat.com
 Reviewed-by: Michael S. Tsirkin m...@redhat.com
 Signed-off-by: Michael S. Tsirkin m...@redhat.com

Thanks,
-- 
William


signature.asc
Description: Digital signature

[Qemu-devel] adding a parameter in qemu tap option

[William Dauchy]

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] [PATCH V3] vhost_net: start/stop guest notifiers properly

[William Dauchy]

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) zhangji...@huawei.com
 Cc: William Dauchy wdau...@gmail.com
 Signed-off-by: Michael S. Tsirkin m...@redhat.com
 Signed-off-by: Jason Wang jasow...@redhat.com
 
 --
 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

[William Dauchy]

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] vhost-net issue with multiples interfaces using MQ

[William Dauchy]

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

[Qemu-devel] vhost-net issue with multiples interfaces using MQ

[William Dauchy]

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] [PATCH] vhost_net: start/stop guest notifiers properly

[William Dauchy]

On Mon, Aug 18, 2014 at 11:51 AM, Jason Wang jasow...@redhat.com 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] using virtio-net multiqueues

[William Dauchy]

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] using virtio-net multiqueues

[William Dauchy]

On Wed, Aug 13, 2014 at 8:03 PM, William Dauchy wdau...@gmail.com 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

Re: [Qemu-devel] using virtio-net multiqueues

[William Dauchy]

On Wed, Aug 13, 2014 at 8:03 PM, William Dauchy wdau...@gmail.com 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] qemu live migration error from 2.0 to 2.1

[William Dauchy]

On Wed, Aug 6, 2014 at 9:47 AM, Paolo Bonzini pbonz...@redhat.com 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] qemu live migration error from 2.0 to 2.1

[William Dauchy]

On Wed, Aug 6, 2014 at 9:49 AM, Paolo Bonzini pbonz...@redhat.com 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

[William Dauchy]

On Wed, Aug 6, 2014 at 11:17 AM, Dr. David Alan Gilbert
dgilb...@redhat.com 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] [questions] about qemu log

[William Dauchy]

On Wed, Aug 6, 2014 at 12:40 AM, Peter Crosthwaite
peter.crosthwa...@xilinx.com 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] [questions] about qemu log

[William Dauchy]

On Wed, Aug 6, 2014 at 12:43 PM, William Dauchy wdau...@gmail.com 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 pwd.h
 #include grp.h
 #include libgen.h
+#include stdio.h
+#include syslog.h

 /* 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

[Qemu-devel] qemu live migration error from 2.0 to 2.1

[William Dauchy]

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] qemu live migration error from 2.0 to 2.1

[William Dauchy]

On Tue, Aug 5, 2014 at 8:57 PM, Dr. David Alan Gilbert
dgilb...@redhat.com 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

Re: [Qemu-devel] [questions] about qemu log

[William Dauchy]

On Tue, Jul 29, 2014 at 9:51 PM, Eric Blake ebl...@redhat.com 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

[Qemu-devel] pidfile option in config file

[William Dauchy]

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] pidfile option in config file

[William Dauchy]

On Thu, May 15, 2014 at 10:15 AM, Markus Armbruster arm...@redhat.com 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

Re: [Qemu-devel] [PATCH] Fix 'name' option to work with -readconfig

[William Dauchy]

On Tue, May 6, 2014 at 1:15 PM, Dr. David Alan Gilbert (git)
dgilb...@redhat.com wrote:
 From: Dr. David Alan Gilbert dgilb...@redhat.com

 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 dgilb...@redhat.com
 Reported-by: William Dauchy wdau...@gmail.com

Please use:

Reported-by: William Dauchy will...@gandi.net

I have also successfully tested the patch
Tested-by: William Dauchy will...@gandi.net

Thanks,
-- 
William

[Qemu-devel] process naming not working when using a config file

[William Dauchy]

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] process naming not working when using a config file

[William Dauchy]

Hello Dave,

Thanks for your quick reply.

On Wed, Apr 2, 2014 at 7:05 PM, Dr. David Alan Gilbert
dgilb...@redhat.com 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

Re: [Qemu-devel] device_del id missing after blockdev-add

[William Dauchy]

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

[William Dauchy]

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': uDevice '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

[William Dauchy]

On Mon, Jan 20, 2014 at 10:23 PM, Alexandre Kandalintsev
s...@messir.net 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] Add bios-256k.bin to BLOBS on Makefile

[William Dauchy]

On Mon, Jan 6, 2014 at 2:13 PM, Peter Maydell peter.mayd...@linaro.org wrote:
 Ping -- who's going to take this patch? Maybe it should
 go via -trivial?

+1 still waiting for this merge

-- 
William

[Qemu-devel] [PATCH] tap: add the possibility to specify a tap prefix

[William Dauchy]

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: will...@gandi.net
---
 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-bridge-helper [--use-vnet] 

Re: [Qemu-devel] [PATCH] tap: add the possibility to specify a tap prefix

[William Dauchy]

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

Re: [Qemu-devel] [PATCH] tap: add the possibility to specify a tap prefix

[William Dauchy]

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] ifname=xxx for -netdev bridge

[William Dauchy]

Hi Alexandre,

On Mon, Mar 25, 2013 at 10:28 PM, Alexandre Kandalintsev
s...@messir.net 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] Add bios-256k.bin to BLOBS on Makefile

[William Dauchy]

On Tue, Dec 10, 2013 at 12:33 AM, Eduardo Habkost ehabk...@redhat.com 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 will...@gandi.net

Thanks,
-- 
William

[Qemu-devel] Re: vcpu hotplug status

[William Dauchy]

On Wed, Mar 16, 2011 at 11:17 AM, William Dauchy wdau...@gmail.com 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

[William Dauchy]

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

[Qemu-devel] [PATCH] moving eeprom initialization

[William Dauchy]

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 wdau...@gmail.com
Signed-off-by: Wen Congyang we...@cn.fujitsu.com
---
 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

[Qemu-devel] [PATCH] moving eeprom initialization

[William Dauchy]

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 wdau...@gmail.com
Signed-off-by: Wen Congyang we...@cn.fujitsu.com
---
 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

Re: [Qemu-devel] [PATCH] moving eeprom initialization

[William Dauchy]

On Sun, Mar 6, 2011 at 9:38 PM, Gerhard Wiesinger li...@wiesinger.com wrote:
 AMD fix is now upstream. Please merge it.

oh sorry. did not see; will do.

-- 
William

[Qemu-devel] [PATCH] moving eeprom initialization

[William Dauchy]

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] Re: [PATCH] moving eeprom initialization

[William Dauchy]

On Wed, Mar 2, 2011 at 2:36 PM, William Dauchy wdau...@gmail.com 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

Re: [Qemu-devel] Re: [PATCH] moving eeprom initialization

[William Dauchy]

On Wed, Mar 2, 2011 at 7:28 PM, Gerhard Wiesinger li...@wiesinger.com 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] null mac address

[William Dauchy]

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] `qdev_free` when unplug a pci device

[William Dauchy]

Hi Markus,

On Wed, Feb 23, 2011 at 9:30 AM, Markus Armbruster arm...@redhat.com 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

Re: [Qemu-devel] [PATCH] Remove a detached device from qemu_device_opts.

[William Dauchy]

Hi Minoru,

On Tue, Feb 15, 2011 at 3:32 AM, Minoru Usui u...@mxm.nes.nec.co.jp 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

[Qemu-devel] [PATCH] `qdev_free` when unplug a pci device

[William Dauchy]

 `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.

[William Dauchy]

Hi,

On Mon, Feb 7, 2011 at 3:40 PM, William Dauchy wdau...@gmail.com 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 oomi...@mxs.nes.nec.co.jp
 ---
 --- 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.

[William Dauchy]

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 oomi...@mxs.nes.nec.co.jp
 ---
 --- 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