Re: [Qemu-devel] [edk2] OVMF hung on qemu 1.6.0 with KVM

2013-08-31 Thread Paolo Bonzini 
Il 30/08/2013 21:05, Jordan Justen ha scritto:
 I meant your proposed update to VTF0 is not quite what is needed
 within EDK II. The current ROM based tables need to stay because that
 is what real firmware would need to use to enable a 64-bit PEI.

Ok, understood.

 OVMF will just have to do something different to work around the KVM
 issue.

I don't think anything special is needed, we can just document that KVM
+ a new QEMU requires a new kernel.

Paolo

 I did some work on this, but ended up going with the simpler
 change of r14494 because it appeared to be enough to work around the
 issue.

Re: [Qemu-devel] [edk2] OVMF hung on qemu 1.6.0 with KVM

2013-08-31 Thread Jordan Justen 
On Thu, Aug 29, 2013 at 8:28 PM, Gary Ching-Pang Lin g...@suse.com wrote:
 On Fri, Aug 30, 2013 at 02:04:40AM +1000, Bruce Rogers wrote:
 I tried this out, and I get the black screen as well when ept=n, but it boots
 successfully to the efi shell when ept=y.

 Gary, what does 'cat /sys/module/kvm_intel/parameters/ept' report on your
 failing machine?

 I think this is the root cause. My machine doesn't support ept.

Gary, Bruce,

Can one of you try this OVMF branch to see if it boots when EPT is not enabled?

https://github.com/jljusten/edk2.git ovmf-vm-vtf0

Thanks for your time,

-Jordan

Re: [Qemu-devel] vm performance degradation after kvm live migration or save-restore with EPT enabled

2013-08-31 Thread Zhanghaoyu (A) 
I tested below combos of qemu and kernel,
++-+-+
|kernel  |  QEMU   |  migration  |
++-+-+
| SLES11SP2+kvm-kmod-3.6 |   qemu-1.6.0|GOOD |
++-+-+
| SLES11SP2+kvm-kmod-3.6 |   qemu-1.6.0*   |BAD  |
++-+-+
| SLES11SP2+kvm-kmod-3.6 |   qemu-1.5.1|BAD  |
++-+-+
| SLES11SP2+kvm-kmod-3.6*|   qemu-1.5.1|GOOD |
++-+-+
| SLES11SP2+kvm-kmod-3.6 |   qemu-1.5.1*   |GOOD |
++-+-+
| SLES11SP2+kvm-kmod-3.6 |   qemu-1.5.2|BAD  |
++-+-+
| kvm-3.11-2 |   qemu-1.5.1|BAD  |
++-+-+
NOTE:
1. kvm-3.11-2 : the whole tag kernel downloaded from 
https://git.kernel.org/pub/scm/virt/kvm/kvm.git
2. SLES11SP2+kvm-kmod-3.6 : our release kernel, replace the SLES11SP2's default 
kvm-kmod with kvm-kmod-3.6, SLES11SP2's kernel version is 3.0.13-0.27
3. qemu-1.6.0* : revert the commit 211ea74022f51164a7729030b28eec90b6c99a08 on 
qemu-1.6.0
4. kvm-kmod-3.6* : kvm-kmod-3.6 with EPT disabled
5. qemu-1.5.1* : apply below patch to qemu-1.5.1 to delete qemu_madvise() 
statement in ram_load() function

--- qemu-1.5.1/arch_init.c  2013-06-27 05:47:29.0 +0800
+++ qemu-1.5.1_fix3/arch_init.c 2013-08-28 19:43:42.0 +0800
@@ -842,7 +842,6 @@ static int ram_load(QEMUFile *f, void *o
 if (ch == 0 
 (!kvm_enabled() || kvm_has_sync_mmu()) 
 getpagesize() = TARGET_PAGE_SIZE) {
-qemu_madvise(host, TARGET_PAGE_SIZE, QEMU_MADV_DONTNEED);
 }
 #endif
 } else if (flags  RAM_SAVE_FLAG_PAGE) {

If I apply above patch to qemu-1.5.1 to delete the qemu_madvise() statement, 
the test result of the combos of SLES11SP2+kvm-kmod-3.6 and qemu-1.5.1 is good.
Why do we perform the qemu_madvise(QEMU_MADV_DONTNEED) for those zero pages?
Does the qemu_madvise() have sustained effect on the range of virtual address?  
In other words, does qemu_madvise() have sustained effect on the VM performance?
If later frequently read/write the range of virtual address which have been 
advised to DONTNEED, could performance degradation happen?

The reason why the combos of SLES11SP2+kvm-kmod-3.6 and qemu-1.6.0 is good, is 
because of commit 211ea74022f51164a7729030b28eec90b6c99a08,
if I revert the commit 211ea74022f51164a7729030b28eec90b6c99a08 on qemu-1.6.0, 
the test result of combos of SLES11SP2+kvm-kmod-3.6 and qemu-1.6.0 is bad, 
performance degradation happened, too.

Thanks,
Zhang Haoyu

  The QEMU command line (/var/log/libvirt/qemu/[domain name].log), 
  LC_ALL=C PATH=/bin:/sbin:/usr/bin:/usr/sbin HOME=/ 
  QEMU_AUDIO_DRV=none
  /usr/local/bin/qemu-system-x86_64 -name ATS1 -S -M pc-0.12 -cpu
  qemu32 -enable-kvm -m 12288 -smp 4,sockets=4,cores=1,threads=1 
  -uuid
  0505ec91-382d-800e-2c79-e5b286eb60b5 -no-user-config -nodefaults 
  -chardev 
  socket,id=charmonitor,path=/var/lib/libvirt/qemu/ATS1.monitor,serv
  er, n owait -mon chardev=charmonitor,id=monitor,mode=control -rtc 
  base=localtime -no-shutdown -device
  piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive 
  file=/opt/ne/vm/ATS1.img,if=none,id=drive-virtio-disk0,format=raw,
  cac
  h
  e=none -device
  virtio-blk-pci,scsi=off,bus=pci.0,addr=0x8,drive=drive-virtio-disk
  0,i
  d
  =virtio-disk0,bootindex=1 -netdev
  tap,fd=20,id=hostnet0,vhost=on,vhostfd=21 -device 
  virtio-net-pci,netdev=hostnet0,id=net0,mac=00:e0:fc:00:0f:00,bus=pci.
  0
  ,addr=0x3,bootindex=2 -netdev
  tap,fd=22,id=hostnet1,vhost=on,vhostfd=23 -device 
  virtio-net-pci,netdev=hostnet1,id=net1,mac=00:e0:fc:01:0f:00,bus=pci.
  0
  ,addr=0x4 -netdev tap,fd=24,id=hostnet2,vhost=on,vhostfd=25 
  -device 
  virtio-net-pci,netdev=hostnet2,id=net2,mac=00:e0:fc:02:0f:00,bus=pci.
  0
  ,addr=0x5 -netdev tap,fd=26,id=hostnet3,vhost=on,vhostfd=27 
  -device 
  virtio-net-pci,netdev=hostnet3,id=net3,mac=00:e0:fc:03:0f:00,bus=pci.
  0
  ,addr=0x6 -netdev tap,fd=28,id=hostnet4,vhost=on,vhostfd=29 
  -device 
  virtio-net-pci,netdev=hostnet4,id=net4,mac=00:e0:fc:0a:0f:00,bus=pci.
  0
  ,addr=0x7 -netdev tap,fd=30,id=hostnet5,vhost=on,vhostfd=31 
  -device 
  virtio-net-pci,netdev=hostnet5,id=net5,mac=00:e0:fc:0b:0f:00,bus=pci.
  0
  ,addr=0x9 -chardev pty,id=charserial0 -device 
  isa-serial,chardev=charserial0,id=serial0 -vnc *:0 -k en-us -vga 
  cirrus -device i6300esb,id=watchdog0,bus=pci.0,addr=0xb
  -watchdog-action poweroff -device
  virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0xa
  
 Which QEMU version is this? Can you try with e1000 NICs instead of virtio?
 
 This QEMU version is 1.0.0, but

[Qemu-devel] [Bug 1219207] [NEW] QMP (32 bit only) segfaults in query-tpm-types when compiled with --enable-tpm

2013-08-31 Thread Richard Jones 
Public bug reported:

NB: This bug ONLY happens on i686.  When qemu is compiled for x86-64,
the bug does NOT happen.

$ ./configure --enable-tpm
$ make
$ (sleep 5; printf 
'{execute:qmp_capabilities}\n{execute:query-tpm-types}\n') | 
./i386-softmmu/qemu-system-i386 -S -nodefaults -nographic -M none -qmp stdio
{QMP: {version: {qemu: {micro: 50, minor: 6, major: 1}, package: 
}, capabilities: []}}
{return: {}}
Segmentation fault (core dumped)

The stack trace is:

#0  output_type_enum (v=0xb9938228, obj=0x5, 
strings=0xb77f0320 TpmType_lookup, kind=0xb767f1d4 TpmType, name=0x0, 
errp=0xbfec4628) at qapi/qapi-visit-core.c:306
#1  0xb762b3b5 in visit_type_enum (v=v@entry=0xb9938228, obj=0x5, 
strings=0xb77f0320 TpmType_lookup, kind=kind@entry=0xb767f1d4 TpmType, 
name=name@entry=0x0, errp=errp@entry=0xbfec4628)
at qapi/qapi-visit-core.c:114
#2  0xb74a9ef4 in visit_type_TpmType (errp=0xbfec4628, name=0x0, 
obj=optimized out, m=0xb9938228) at qapi-visit.c:5220
#3  visit_type_TpmTypeList (m=0xb9938228, obj=obj@entry=0xbfec4678, 
name=name@entry=0xb76545a6 unused, errp=errp@entry=0xbfec4674)
at qapi-visit.c:5206
#4  0xb74c403e in qmp_marshal_output_query_tpm_types (errp=0xbfec4674, 
ret_out=0xbfec46d8, ret_in=0xb993f490) at qmp-marshal.c:3795
#5  qmp_marshal_input_query_tpm_types (mon=0xb9937098, qdict=0xb99379a0, 
ret=0xbfec46d8) at qmp-marshal.c:3817
#6  0xb7581d7a in qmp_call_cmd (cmd=optimized out, params=0xb99379a0, 
mon=0xb9937098) at /home/rjones/d/qemu/monitor.c:4644
#7  handle_qmp_command (parser=0xb99370ec, tokens=0xb9941438)
at /home/rjones/d/qemu/monitor.c:4710
#8  0xb7631d8f in json_message_process_token (lexer=0xb99370f0, 
token=0xb993f3a8, type=JSON_OPERATOR, x=29, y=1)
at qobject/json-streamer.c:87
#9  0xb764579b in json_lexer_feed_char (lexer=lexer@entry=0xb99370f0, 
ch=optimized out, flush=flush@entry=false) at qobject/json-lexer.c:303
#10 0xb76458c8 in json_lexer_feed (lexer=lexer@entry=0xb99370f0, 
buffer=buffer@entry=0xbfec486c }\243\353S\351\364b\267/\327ⵀ\025}\267 
\367b\267\315\372\223\271\065\023j\267\002, size=size@entry=1)
at qobject/json-lexer.c:356
#11 0xb7631fab in json_message_parser_feed (parser=0xb99370ec, 
buffer=buffer@entry=0xbfec486c }\243\353S\351\364b\267/\327ⵀ\025}\267 
\367b\267\315\372\223\271\065\023j\267\002, size=size@entry=1)
at qobject/json-streamer.c:110
#12 0xb75803eb in monitor_control_read (opaque=0xb9937098, 
buf=0xbfec486c }\243\353S\351\364b\267/\327ⵀ\025}\267 
\367b\267\315\372\223\271\065\023j\267\002, size=1) at 
/home/rjones/d/qemu/monitor.c:4731
#13 0xb74b191e in qemu_chr_be_write (len=optimized out, 
buf=0xbfec486c }\243\353S\351\364b\267/\327ⵀ\025}\267 
\367b\267\315\372\223\271\065\023j\267\002, s=0xb9935800) at qemu-char.c:165
#14 fd_chr_read (chan=0xb9935870, cond=(G_IO_IN | G_IO_HUP), opaque=0xb9935800)
at qemu-char.c:841
#15 0xb71f6876 in g_io_unix_dispatch () from /usr/lib/libglib-2.0.so.0
#16 0xb71b0286 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#17 0xb747a13e in glib_pollfds_poll () at main-loop.c:189
#18 os_host_main_loop_wait (timeout=optimized out) at main-loop.c:234
#19 main_loop_wait (nonblocking=1) at main-loop.c:484
#20 0xb7309f11 in main_loop () at vl.c:2090
#21 main (argc=8, argv=0xbfec5c14, envp=0xbfec5c38) at vl.c:4435

** Affects: qemu
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1219207

Title:
  QMP (32 bit only) segfaults in query-tpm-types when compiled with
  --enable-tpm

Status in QEMU:
  New

Bug description:
  NB: This bug ONLY happens on i686.  When qemu is compiled for x86-64,
  the bug does NOT happen.

  $ ./configure --enable-tpm
  $ make
  $ (sleep 5; printf 
'{execute:qmp_capabilities}\n{execute:query-tpm-types}\n') | 
./i386-softmmu/qemu-system-i386 -S -nodefaults -nographic -M none -qmp stdio
  {QMP: {version: {qemu: {micro: 50, minor: 6, major: 1}, 
package: }, capabilities: []}}
  {return: {}}
  Segmentation fault (core dumped)

  The stack trace is:

  #0  output_type_enum (v=0xb9938228, obj=0x5, 
  strings=0xb77f0320 TpmType_lookup, kind=0xb767f1d4 TpmType, name=0x0, 
  errp=0xbfec4628) at qapi/qapi-visit-core.c:306
  #1  0xb762b3b5 in visit_type_enum (v=v@entry=0xb9938228, obj=0x5, 
  strings=0xb77f0320 TpmType_lookup, kind=kind@entry=0xb767f1d4 
TpmType, 
  name=name@entry=0x0, errp=errp@entry=0xbfec4628)
  at qapi/qapi-visit-core.c:114
  #2  0xb74a9ef4 in visit_type_TpmType (errp=0xbfec4628, name=0x0, 
  obj=optimized out, m=0xb9938228) at qapi-visit.c:5220
  #3  visit_type_TpmTypeList (m=0xb9938228, obj=obj@entry=0xbfec4678, 
  name=name@entry=0xb76545a6 unused, errp=errp@entry=0xbfec4674)
  at qapi-visit.c:5206
  #4  0xb74c403e in qmp_marshal_output_query_tpm_types (errp=0xbfec4674, 
  ret_out=0xbfec46d8,

Re: [Qemu-devel] [PATCH 2/2] milkymist-uart: use Device::realize instead of SysBusDevice::init

2013-08-31 Thread Andreas Färber 
Am 31.08.2013 07:33, schrieb Antony Pavlov:
 quote author=Peter Crosthwaite
  url=http://lists.nongnu.org/archive/html/qemu-devel/2013-08/msg04748.html;
   Use of SysBusDevice::init is deprecated. Please use
   Device::realize instead of SysBusDevice::init.
   Check dma/pl330.c for an example of the pattern.
 /quote
 
 Signed-off-by: Antony Pavlov antonynpav...@gmail.com
 CC: Peter Crosthwaite peter.crosthwa...@xilinx.com
 CC: Michael Walle mich...@walle.cc
 ---
  hw/char/milkymist-uart.c | 11 ---
  1 file changed, 4 insertions(+), 7 deletions(-)

Thanks for looking into this! Some small issues...

Please replace the XML quote above with a proper textual description,
such as Use of SysBusDevice::init is deprecated, use Device::realize
instead. You can add a line
Reported-by: Peter Crosthwaite peter.crosthwa...@xilinx.com
before your Sob to attribute that to him. (Subject is perfect, thanks.)

 diff --git a/hw/char/milkymist-uart.c b/hw/char/milkymist-uart.c
 index 6e4bc20..66fba82 100644
 --- a/hw/char/milkymist-uart.c
 +++ b/hw/char/milkymist-uart.c
 @@ -195,22 +195,20 @@ static void milkymist_uart_reset(DeviceState *d)
  s-regs[R_STAT] = STAT_THRE;
  }
  
 -static int milkymist_uart_init(SysBusDevice *dev)
 +static void milkymist_uart_realize(DeviceState *dev, Error **errp)
  {
  MilkymistUartState *s = MILKYMIST_UART(dev);
  
 -sysbus_init_irq(dev, s-irq);
 +sysbus_init_irq(SYS_BUS_DEVICE(dev), s-irq);
  
  memory_region_init_io(s-regs_region, OBJECT(s), uart_mmio_ops, s,
milkymist-uart, R_MAX * 4);
 -sysbus_init_mmio(dev, s-regs_region);
 +sysbus_init_mmio(SYS_BUS_DEVICE(dev), s-regs_region);

Please avoid repeated casts by using a local sbd variable, ordered from
most abstract to concrete. However, since s-irq and R_MAX don't seem to
depend on user-settable properties, please move all of the above -
sysbus_init_irq(), memory_region_init_io() and sysbus_init_mmio() - into
a TypeInfo::instance_init function named milkymist_uart_init(Object
*obj) above or below ..._realize.

Otherwise patch looks good. Please CC me on v2 and I'll queue this one
on the qom-next tree.

Regards,
Andreas

  
  s-chr = qemu_char_get_next_serial();
  if (s-chr) {
  qemu_chr_add_handlers(s-chr, uart_can_rx, uart_rx, uart_event, s);
  }
 -
 -return 0;
  }
  
  static const VMStateDescription vmstate_milkymist_uart = {
 @@ -227,9 +225,8 @@ static const VMStateDescription vmstate_milkymist_uart = {
  static void milkymist_uart_class_init(ObjectClass *klass, void *data)
  {
  DeviceClass *dc = DEVICE_CLASS(klass);
 -SysBusDeviceClass *k = SYS_BUS_DEVICE_CLASS(klass);
  
 -k-init = milkymist_uart_init;
 +dc-realize = milkymist_uart_realize;
  dc-reset = milkymist_uart_reset;
  dc-vmsd = vmstate_milkymist_uart;
  }

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

[Qemu-devel] How to emulate an i2c device on QEMU x86?

2013-08-31 Thread Honghe Wu 
Hi there,

Our team want to emulate a multi-touchscreen device controller/device based
on x86 arch, and encounter some problems.

We have created a virtual multi-touchscreen controller demo, and registered
it on i2c bus, but it doesn't seem to work.
We register the controller on i2c bus, cause:

   1. We found lots of touchscreen drivers on Linux kernel are registered
   on i2c bus, such as egalax_ts.c driver.
   2. We create the multi-touchscreen controller by referring
   the virtual smbus_eeprom.c device controller/device.

But, it seems the virtual multi-touchsreen controller we created isn't
probed by guest Linux which running on QEMU, and we have some douts:

   1. Creating a multi-touchscreen controller registered on i2c bus, is
   that ok?
   2. If that's ok, how to add an interrupt into the controller, cause the
   virtual smbus_eeprom.c controller we referring has not any interrupt.
   3. When QEMU is star up, we can find the multi-touchscreen controller
   registered on i2c bus through `info qtree` command, why can't we find the
   controller on guest Linux `/sys/bus/i2c/devices` derictory?
   4. Can the virtual controller probed by guest Linux through generating
   an interrupt?
   5. And is there any source code we can reference?

Thanks!

-- 
Honghe

[Qemu-devel] [Bug 1219234] [NEW] -device ide-hd will assign bus with with no free units

2013-08-31 Thread Cole Robinson 
Public bug reported:

Originally filed here:
https://bugzilla.redhat.com/show_bug.cgi?id=1000118

./x86_64-softmmu/qemu-system-x86_64 -device ahci -drive 
id=aa,file=/tmp/foo,if=none -drive id=bb,file=/tmp/foo,if=none -device 
ide-hd,drive=aa -device ide-hd,drive=bb
qemu-system-x86_64: -device ide-hd,drive=bb: Can't create IDE unit 1, bus 
supports only 1 units
qemu-system-x86_64: -device ide-hd,drive=bb: Device initialization failed.
qemu-system-x86_64: -device ide-hd,drive=bb: Device 'ide-hd' could not be 
initialized

If a bus isn't specified for -device ide-hd, it just uses the first bus
it finds, not taking into account if that bus was already assigned for
another device. So users are forced to do -device ide-hd,bus=ide.0
-device ide-hd,bus=ide.1, etc.

This isn't specific to -device ahci, but it's worse there since there
isn't any -drive if=IDE or -hda convenience option, which both seem to
get the logic correct.

I know -device is the 'build it yourself' approach so I understand if
this is WONTFIX.

This is affects qemu.git as of today (8-31-2013)

** Affects: qemu
 Importance: Undecided
 Status: New

** Description changed:

  Originally filed here:
  https://bugzilla.redhat.com/show_bug.cgi?id=1000118
  
  ./x86_64-softmmu/qemu-system-x86_64 -device ahci -drive 
id=aa,file=/tmp/foo,if=none -drive id=bb,file=/tmp/foo,if=none -device 
ide-hd,drive=aa -device ide-hd,drive=bb
  qemu-system-x86_64: -device ide-hd,drive=bb: Can't create IDE unit 1, bus 
supports only 1 units
  qemu-system-x86_64: -device ide-hd,drive=bb: Device initialization failed.
  qemu-system-x86_64: -device ide-hd,drive=bb: Device 'ide-hd' could not be 
initialized
  
  If a bus isn't specified for -device ide-hd, it just uses the first bus
  it finds, not taking into account if that bus was already assigned for
  another device. So users are forced to do -device ide-hd,bus=ide.0
  -device ide-hd,bus=ide.1, etc.
  
  This isn't specific to -device ahci, but it's worse there since there
  isn't any -drive if=IDE or -hda convenience option, which both seem to
  get the logic correct.
  
  I know -device is the 'build it yourself' approach so I understand if
  this is WONTFIX.
+ 
+ This is affects qemu.git as of today (8-31-2013)

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1219234

Title:
  -device ide-hd will assign bus with with no free units

Status in QEMU:
  New

Bug description:
  Originally filed here:
  https://bugzilla.redhat.com/show_bug.cgi?id=1000118

  ./x86_64-softmmu/qemu-system-x86_64 -device ahci -drive 
id=aa,file=/tmp/foo,if=none -drive id=bb,file=/tmp/foo,if=none -device 
ide-hd,drive=aa -device ide-hd,drive=bb
  qemu-system-x86_64: -device ide-hd,drive=bb: Can't create IDE unit 1, bus 
supports only 1 units
  qemu-system-x86_64: -device ide-hd,drive=bb: Device initialization failed.
  qemu-system-x86_64: -device ide-hd,drive=bb: Device 'ide-hd' could not be 
initialized

  If a bus isn't specified for -device ide-hd, it just uses the first
  bus it finds, not taking into account if that bus was already assigned
  for another device. So users are forced to do -device ide-hd,bus=ide.0
  -device ide-hd,bus=ide.1, etc.

  This isn't specific to -device ahci, but it's worse there since there
  isn't any -drive if=IDE or -hda convenience option, which both seem to
  get the logic correct.

  I know -device is the 'build it yourself' approach so I understand if
  this is WONTFIX.

  This is affects qemu.git as of today (8-31-2013)

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1219234/+subscriptions

[Qemu-devel] [PATCH v2 0/2] milkymist-uart fixes

2013-08-31 Thread Antony Pavlov 
This patch series based on DIGIC support adding comments:
  http://lists.nongnu.org/archive/html/qemu-devel/2013-08/msg04748.html

[PATCH v2 1/2] milkymist-uart: use qemu_chr_fe_write_all() instead of 
qemu_chr_fe_write()
[PATCH v2 2/2] milkymist-uart: use Device::realize instead of SysBusDevice::init

Changes since v1:
 * remove xml-styled quotes from patch comments;
 * introduce TypeInfo::instance_init milkymist_uart_init().

[Qemu-devel] [PATCH v2 1/2] milkymist-uart: use qemu_chr_fe_write_all() instead of qemu_chr_fe_write()

2013-08-31 Thread Antony Pavlov 
qemu_chr_fe_write() is capable of returning 0
to indicate EAGAIN (and friends) and we don't
handle this.

Just change it to qemu_chr_fe_write_all() to fix.

Reported-by: Peter Crosthwaite peter.crosthwa...@xilinx.com
Signed-off-by: Antony Pavlov antonynpav...@gmail.com
CC: Peter Crosthwaite peter.crosthwa...@xilinx.com
CC: Michael Walle mich...@walle.cc
CC: Andreas Färber afaer...@suse.de
---
 hw/char/milkymist-uart.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/char/milkymist-uart.c b/hw/char/milkymist-uart.c
index 2e4b5c5..6e4bc20 100644
--- a/hw/char/milkymist-uart.c
+++ b/hw/char/milkymist-uart.c
@@ -124,7 +124,7 @@ static void uart_write(void *opaque, hwaddr addr, uint64_t 
value,
 switch (addr) {
 case R_RXTX:
 if (s-chr) {
-qemu_chr_fe_write(s-chr, ch, 1);
+qemu_chr_fe_write_all(s-chr, ch, 1);
 }
 s-regs[R_STAT] |= STAT_TX_EVT;
 break;
-- 
1.8.4.rc3

[Qemu-devel] [PATCH v2 2/2] milkymist-uart: use Device::realize instead of SysBusDevice::init

2013-08-31 Thread Antony Pavlov 
Use of SysBusDevice::init is deprecated.
Use Device::realize instead of SysBusDevice::init.
Check dma/pl330.c for an example of the pattern.

Also introduce TypeInfo::instance_init milkymist_uart_init()
as char/pl011.c does.

Reported-by: Peter Crosthwaite peter.crosthwa...@xilinx.com
Signed-off-by: Antony Pavlov antonynpav...@gmail.com
CC: Peter Crosthwaite peter.crosthwa...@xilinx.com
CC: Michael Walle mich...@walle.cc
CC: Andreas Färber afaer...@suse.de
---
 hw/char/milkymist-uart.c | 24 ++--
 1 file changed, 14 insertions(+), 10 deletions(-)

diff --git a/hw/char/milkymist-uart.c b/hw/char/milkymist-uart.c
index 6e4bc20..da51f82 100644
--- a/hw/char/milkymist-uart.c
+++ b/hw/char/milkymist-uart.c
@@ -195,22 +195,26 @@ static void milkymist_uart_reset(DeviceState *d)
 s-regs[R_STAT] = STAT_THRE;
 }
 
-static int milkymist_uart_init(SysBusDevice *dev)
+static void milkymist_uart_realize(DeviceState *dev, Error **errp)
 {
 MilkymistUartState *s = MILKYMIST_UART(dev);
 
-sysbus_init_irq(dev, s-irq);
-
-memory_region_init_io(s-regs_region, OBJECT(s), uart_mmio_ops, s,
-  milkymist-uart, R_MAX * 4);
-sysbus_init_mmio(dev, s-regs_region);
-
 s-chr = qemu_char_get_next_serial();
 if (s-chr) {
 qemu_chr_add_handlers(s-chr, uart_can_rx, uart_rx, uart_event, s);
 }
+}
 
-return 0;
+static void milkymist_uart_init(Object *obj)
+{
+SysBusDevice *sbd = SYS_BUS_DEVICE(obj);
+MilkymistUartState *s = MILKYMIST_UART(obj);
+
+sysbus_init_irq(sbd, s-irq);
+
+memory_region_init_io(s-regs_region, OBJECT(s), uart_mmio_ops, s,
+  milkymist-uart, R_MAX * 4);
+sysbus_init_mmio(sbd, s-regs_region);
 }
 
 static const VMStateDescription vmstate_milkymist_uart = {
@@ -227,9 +231,8 @@ static const VMStateDescription vmstate_milkymist_uart = {
 static void milkymist_uart_class_init(ObjectClass *klass, void *data)
 {
 DeviceClass *dc = DEVICE_CLASS(klass);
-SysBusDeviceClass *k = SYS_BUS_DEVICE_CLASS(klass);
 
-k-init = milkymist_uart_init;
+dc-realize = milkymist_uart_realize;
 dc-reset = milkymist_uart_reset;
 dc-vmsd = vmstate_milkymist_uart;
 }
@@ -238,6 +241,7 @@ static const TypeInfo milkymist_uart_info = {
 .name  = TYPE_MILKYMIST_UART,
 .parent= TYPE_SYS_BUS_DEVICE,
 .instance_size = sizeof(MilkymistUartState),
+.instance_init = milkymist_uart_init,
 .class_init= milkymist_uart_class_init,
 };
 
-- 
1.8.4.rc3

Re: [Qemu-devel] [PATCH v2 2/2] milkymist-uart: use Device::realize instead of SysBusDevice::init

2013-08-31 Thread Andreas Färber 
Am 31.08.2013 19:22, schrieb Antony Pavlov:
 Use of SysBusDevice::init is deprecated.
 Use Device::realize instead of SysBusDevice::init.
 Check dma/pl330.c for an example of the pattern.
 
 Also introduce TypeInfo::instance_init milkymist_uart_init()
 as char/pl011.c does.
 
 Reported-by: Peter Crosthwaite peter.crosthwa...@xilinx.com
 Signed-off-by: Antony Pavlov antonynpav...@gmail.com
 CC: Peter Crosthwaite peter.crosthwa...@xilinx.com
 CC: Michael Walle mich...@walle.cc
 CC: Andreas Färber afaer...@suse.de
 ---
  hw/char/milkymist-uart.c | 24 ++--
  1 file changed, 14 insertions(+), 10 deletions(-)

Thanks, applied to qom-next (with shortened commit message):
https://github.com/afaerber/qemu-cpu/commits/qom-next

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

[Qemu-devel] [PATCH] qapi-types.py: Fix enum struct sizes on i686

2013-08-31 Thread Cole Robinson 
Unlike other list types, enum wasn't adding any padding, which caused
a mismatch between the generated struct size and GenericList struct
size. More details in a678e26cbe89f7a27cbce794c2c2784571ee9d21

This crashed qemu if calling qmp query-tpm-types for example, which
upsets libvirt capabilities probing. Reproducer on i686:

(sleep 5; printf 
'{execute:qmp_capabilities}\n{execute:query-tpm-types}\n') | 
./i386-softmmu/qemu-system-i386 -S -nodefaults -nographic -M none -qmp stdio

https://bugs.launchpad.net/qemu/+bug/1219207

Cc: qemu-sta...@nongnu.org
Signed-off-by: Cole Robinson crobi...@redhat.com
---
 scripts/qapi-types.py | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/scripts/qapi-types.py b/scripts/qapi-types.py
index 5ee46ea..5d31b06 100644
--- a/scripts/qapi-types.py
+++ b/scripts/qapi-types.py
@@ -51,7 +51,10 @@ def generate_fwd_enum_struct(name, members):
 return mcgen('''
 typedef struct %(name)sList
 {
-%(name)s value;
+union {
+%(name)s value;
+uint64_t padding;
+};
 struct %(name)sList *next;
 } %(name)sList;
 ''',
-- 
1.8.3.1

[Qemu-devel] Fwd: Max7310: confused about the method of reading output port register

2013-08-31 Thread Yang Ning 

Dear  Zaborowski:

Firstly,I'm writing to express my thanks to you for the source
code of Max7310 which have helped me so much.
 But I'm still confused about the method of reading output port register.
code:

   case 0x01:   /* Output port */
   return s-level  ~s-direction;
   break;


I found some instruction of output port register in the datasheet.

 Reads from the output port register reflect the value that is in the flip-flop
controlling the output selection, not the actual I/O value, which may differ if
the out-put is overloaded.


So,in my opinion,in the defination of MAX7310State,whether the property
of outputport_reg should be added?
And does the method of reading/writing output port should be modified as
follows.

[reading]
case 0x01:  /* Output port */
return s-outputport_reg;
break;
[writing]
case 0x01:  /* Output port */

   for (diff = (data ^ s-level)  ~s-direction; diff;
   diff = ~(1  line)) {
  line = ffs(diff) - 1;
   if (s-handler[line])
   qemu_set_irq(s-handler[line], (data  line)  1);
   }
   s-level = (s-level  s-direction) | (data  ~s-direction);

s-outputport_reg =  data;
break;

Re: [Qemu-devel] [PATCH] qapi-types.py: Fix enum struct sizes on i686

2013-08-31 Thread Eric Blake 
On 08/31/2013 04:36 PM, Cole Robinson wrote:
 Unlike other list types, enum wasn't adding any padding, which caused
 a mismatch between the generated struct size and GenericList struct
 size. More details in a678e26cbe89f7a27cbce794c2c2784571ee9d21
 
 This crashed qemu if calling qmp query-tpm-types for example, which
 upsets libvirt capabilities probing. Reproducer on i686:
 
 (sleep 5; printf 
 '{execute:qmp_capabilities}\n{execute:query-tpm-types}\n') | 
 ./i386-softmmu/qemu-system-i386 -S -nodefaults -nographic -M none -qmp stdio
 
 https://bugs.launchpad.net/qemu/+bug/1219207
 
 Cc: qemu-sta...@nongnu.org
 Signed-off-by: Cole Robinson crobi...@redhat.com
 ---
  scripts/qapi-types.py | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)
 

Reviewed-by: Eric Blake ebl...@redhat.com

 -%(name)s value;
 +union {
 +%(name)s value;
 +uint64_t padding;
 +};

Am I right that anonymous unions are only a C11 feature (not C99)?  But
you are just copying and pasting from the other uses in this file, so
it's not a problem.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature