Re: [Qemu-devel] [PATCH - V3] Port codes from qemu-kvm to support booting from SCSI disk image

[Gerd Hoffmann]

On 08/18/10 17:16, Alexander Graf wrote:



This has been discussed several times before. The proper solution
is to teach the bios how to boot off SCSI devices. IIRC support for
virtio devices already exists, implementing support for the SCSI
controller shouldn't be that much harder.


Couldn't we just have an option rom for the SCSI controller? The same
way the VGABIOS is a rewrite of a VGA BIOS for the Cirrus Logic...


There already is one.  Needs qemu 0.12.4 or newer.  Unfortunaly it isn't 
redistributable, so we can't easily integrate it.  Thus seabios support 
or a free option rom would still be nice to have.


Fetch 
http://www.lsi.com/DistributionSystem/AssetDocument/files/support/ssp/sdms/Bios/lsi_bios.zip 
- unzip - boot with -option-rom 8xx_64.rom


cheers,
  Gerd

RE: [Qemu-devel] qemu 0.12.5 sparc64 debian 505

[Laurikainen, Tuukka]

2010/8/19 Blue Swirl blauwir...@gmail.com:
 Hi,

 As the Sparc64 support is not complete, I thought I'd ask here before
 reporting a bug.

 Trying to boot a Debian netboot cd image for Sparc with Qemu 0.12.5:

 # qemu-system-sparc64 -boot d -cdrom debian-505-sparc-businesscard.iso
 -nographic -hda sparc.img
 OpenBIOS for Sparc64
 Configuration device id QEMU version 1 machine id 0
 CPUs: 1 x SUNW,UltraSPARC-II
 UUID: ----
 Welcome to OpenBIOS v1.0 built on Dec 6 2009 11:16
  Type 'help' for detailed information

 [sparc64] Booting file 'cdrom' with parameters ''
 Not a bootable ELF image
 Not a Linux kernel image
 Loading a.out image...
 Loaded 7680 bytes
 entry point is 0x4000
 Jumping to entry point...
 switching to new context: entry point 0x4000 stack 0xffe02a71
 SILO Version 1.4.13
 \

                  Welcome to Debian GNU/Linux lenny!

 This is a Debian installation CDROM, built on 20100627-10:50.
 Keep it once you have installed your system, as you can boot from it
 to repair the system on your hard disk if that ever becomes necessary.

 WARNING: You should completely back up all of your hard disks before
  proceeding. The installation procedure can completely and irreversibly
  erase them! If you haven't made backups yet, remove the rescue CD from
  the drive and press L1-A to get back to the OpenBoot prompt.

 Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
 permitted
 by applicable law.

 [ ENTER - Boot install ]   [ Type expert - Boot into expert mode ]
                           [ Type rescue - Boot into rescue mode ]
 boot:
 Allocated 8 Megs of memory at 0x4000 for kernel
 Loaded kernel version 2.6.26
 Loading initial ramdisk (4310561 bytes at 0xC0 phys, 0x40C0
 virt)...
 qemu: unsupported keyboard cmd=0x02
 FLOPPY ERROR: fdctrl_unimplemented: unimplemented command 0xfe
 Pqemu: unsupported keyboard cmd=0xb1
 FLOPPY ERROR: fdctrl_unimplemented: unimplemented command 0xc4

This is about how far Sparc64 boot gets now. With a custom kernel I
get much further (IDE probe) but there are still a few unimplemented
features.

 And then halt. The host is a x86 Debian 5.
 Can't find any similar open bug, should I open one?

I don't think it would help much.

OK, thanks for the clarification.

Cheers,

Tuukka

[Qemu-devel] Re: [PATCH v2 0/7] APIC/IOAPIC cleanup

[Paolo Bonzini]

On 08/19/2010 11:51 PM, Anthony Liguori wrote:

Neither approach maps well to real hardware. An x86 CPU cannot exist
without a local APIC and a local APIC cannot exist without an x86
CPU. The
two are fundamentally tied together.


What about 486? Or 82489?


Don't confuse the local APIC with the PIC or the I/O APIC.

The local APIC has always existed in the CPU core. There is also an I/O
APIC which exists outside of the CPU core. The local APIC was introduced
with SMP support.


In theory it's possible to have a discrete local APIC on the 486 or the 
Pentium.  See figure 5-1 in the Intel multiprocessor specification.



When you look at the local APIC (apic.c) however, you see that it's the
only device in the tree that actually interacts with a CPUState.


Even worse, it does it through an opaque pointer even though the only 
CPUState that makes sense there is the i386 CPUState.  (BTW, there is 
exactly one other example of a CPUState property, and it's in the CRIS PIC).


Paolo

Re: [Qemu-devel] [PATCH] qemu-option: Include name of invalid parameter in error message

[Markus Armbruster]

Stefan Weil w...@mail.berlios.de writes:

 Am 02.08.2010 10:40, schrieb Markus Armbruster:
 Stefan Weil w...@mail.berlios.de writes:

 All other error messages in qemu-option.c display the name
 of the invalid parameter. This seems to be reasonable for
 invalid identifiers, too. Without it, a debugger is needed
 to find the name.

 Cc: Markus Armbruster arm...@redhat.com
 Cc: Anthony Liguori aligu...@us.ibm.com
 Signed-off-by: Stefan Weil w...@mail.berlios.de
 ---
 qemu-option.c | 2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

 diff --git a/qemu-option.c b/qemu-option.c
 index 1f8f41a..ccea267 100644
 --- a/qemu-option.c
 +++ b/qemu-option.c
 @@ -694,7 +694,7 @@ QemuOpts *qemu_opts_create(QemuOptsList *list,
 const char *id, int fail_if_exist

 if (id) {
 if (!id_wellformed(id)) {
 - qerror_report(QERR_INVALID_PARAMETER_VALUE, id, an identifier);
 + qerror_report(QERR_INVALID_PARAMETER_VALUE, id, an identifier);
 error_printf_unless_qmp(Identifiers consist of letters, digits,
 -', '.', '_', starting with a letter.\n);
 return NULL;
 }

 No.

 QERR_INVALID_PARAMETER_VALUE's first argument is the parameter *name*,
 not the parameter *value*.

 In this case, the parameter name is id. The variable id contains the
 parameter value.

 If you need a debugger to find the offending id=, then location
 information is lacking. Could you give an example where it's hard to
 find the offending parameter?

 Here's an example where it's easy to find:

 $ qemu-system-x86_64 -device e1000,id=.
 qemu-system-x86_64: -device e1000,id=.: Parameter 'id' expects an
 identifier
 Identifiers consist of letters, digits, '-', '.', '_', starting with
 a letter.

 I had a call of qemu_chr_open with an id containing a space
 (which looks better in the console display where the id is shown)
 in my ar7 emulation. You can test this scenario using this patch:

 --- a/vl.c
 +++ b/vl.c
 @@ -1700,7 +1700,7 @@ static int serial_parse(const char *devname)
  fprintf(stderr, qemu: too many serial ports\n);
  exit(1);
  }
 -snprintf(label, sizeof(label), serial%d, index);
 +snprintf(label, sizeof(label), serial %d, index);
  serial_hds[index] = qemu_chr_open(label, devname, NULL);
  if (!serial_hds[index]) {
  fprintf(stderr, qemu: could not open serial device '%s': %s\n,

 It results in these error messages:

 qemu: Parameter 'id' expects an identifier
 Identifiers consist of letters, digits, '-', '.', '_', starting with a
 letter.
 qemu: could not open serial device 'vc:80Cx24C': No such file or directory

 The location information is indeed missing. For this kind of error,
 an assertion would be better than an error message.

I agree that programming errors should not be reported as user errors.

Down where the error is detected, the code doesn't know whether it's
processing hardcoded arguments (programming error), or whether it's
processing user arguments (user error).

The best we can do with relative ease is report the error assuming it's
a user error, and return failure up the call chain.  When we reach
hardcoded-land, report the programming error.

Re: [Qemu-devel] [PATCH] qdev: Reset hotplugged devices

[Markus Armbruster]

Alex Williamson alex.william...@redhat.com writes:

 Several devices rely on their reset() function being called to
 initialize device state, e1000 and rtl8139 in particular.  When
 the device is hot added, the reset doesn't occur, often leaving
 the device in an unusable state.  Adding a call to reset() after
 init() for hotplugged devices puts the device in the expected
 state for the guest.

 Signed-off-by: Alex Williamson alex.william...@redhat.com
 ---

  0.13 candidate?

  hw/qdev.c |3 +++
  1 files changed, 3 insertions(+), 0 deletions(-)

 diff --git a/hw/qdev.c b/hw/qdev.c
 index e99c73f..b156272 100644
 --- a/hw/qdev.c
 +++ b/hw/qdev.c
 @@ -278,6 +278,9 @@ int qdev_init(DeviceState *dev)
  qdev_free(dev);
  return rc;
  }
 +if (dev-hotplugged) {
 +qdev_reset(dev);
 +}
  qemu_register_reset(qdev_reset, dev);
  if (dev-info-vmsd) {
  vmstate_register_with_alias_id(dev, -1, dev-info-vmsd, dev,

qdev_reset() isn't necessary when !dev-hotplugged, because then
qemu_system_reset() will run shortly, which will call qdev_reset().
Correct?

Re: [Qemu-devel] [PATCH v2 0/7] APIC/IOAPIC cleanup

[malc]

On Thu, 19 Aug 2010, Anthony Liguori wrote:

 On 08/19/2010 05:52 PM, malc wrote:
   Yes, but the programming model was different.
   
   Look at the PIC compared to the lapic.  The PIC is programmed via pio at a
   fixed location.  There is only one PIC and it interacts with the system
   just
   like all other devices.  IOW, there is no reference to CPUState.

  There are two PICs actually there's a cascade..
 
 
 Technically speaking, originally there was just one and then more IRQs were
 supported by cascading and reserving an IRQ line for supporting cascading.  I
 think you can technical cascade with any IRQ and have more than one slave but
 the historic PC architecture only had one slave AFAIK.

One master + one slave = 2 PICs, i guess you've meant that originally
there was no slave.

[..snip..]

-- 
mailto:av1...@comtv.ru

[Qemu-devel] [PATCH] vnc: check fd before calling qemu_set_fd_handler2() in vnc_client_write()

[Yoshiaki Tamura]

Setting fd = -1 to qemu_set_fd_handler2() causes bus error at FD_SET
in main_loop_wait().

Signed-off-by: Yoshiaki Tamura tamura.yoshi...@lab.ntt.co.jp
---
 ui/vnc.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/ui/vnc.c b/ui/vnc.c
index 7fc40ac..c7a1831 100644
--- a/ui/vnc.c
+++ b/ui/vnc.c
@@ -1184,7 +1184,7 @@ void vnc_client_write(void *opaque)
 vnc_lock_output(vs);
 if (vs-output.offset) {
 vnc_client_write_locked(opaque);
-} else {
+} else if (vs-csock != -1) {
 qemu_set_fd_handler2(vs-csock, NULL, vnc_client_read, NULL, vs);
 }
 vnc_unlock_output(vs);
-- 
1.7.1.1

[Qemu-devel] Re: [PATCH V2] balloon: Don't try fetching info if machine is stopped

[Paolo Bonzini]

On 08/20/2010 02:48 AM, Amit Shah wrote:

If the machine is stopped and 'info balloon' is invoked, the monitor
process just hangs waiting for info from the guest. Return the most
recent balloon data in that case.

See https://bugzilla.redhat.com/show_bug.cgi?id=623903

Reported-by:lihu...@redhat.com
Signed-off-by: Amit Shahamit.s...@redhat.com
---
v2: simplify call to qemu_balloon_status - Paulo

  balloon.c   |   11 +++
  balloon.h   |6 --
  hw/virtio-balloon.c |9 +++--
  3 files changed, 18 insertions(+), 8 deletions(-)

diff --git a/balloon.c b/balloon.c
index 8e0b7f1..8b05d20 100644
--- a/balloon.c
+++ b/balloon.c
@@ -43,17 +43,20 @@ void qemu_add_balloon_handler(QEMUBalloonEvent *func, void 
*opaque)
  int qemu_balloon(ram_addr_t target, MonitorCompletion cb, void *opaque)
  {
  if (qemu_balloon_event) {
-qemu_balloon_event(qemu_balloon_event_opaque, target, cb, opaque);
+qemu_balloon_event(qemu_balloon_event_opaque, target, cb, opaque,
+   false);
  return 1;
  } else {
  return 0;
  }
  }

-int qemu_balloon_status(MonitorCompletion cb, void *opaque)
+int qemu_balloon_status(MonitorCompletion cb, void *opaque,
+bool get_cached_data)
  {
  if (qemu_balloon_event) {
-qemu_balloon_event(qemu_balloon_event_opaque, 0, cb, opaque);
+qemu_balloon_event(qemu_balloon_event_opaque, 0, cb, opaque,
+   get_cached_data);
  return 1;
  } else {
  return 0;
@@ -113,7 +116,7 @@ int do_info_balloon(Monitor *mon, MonitorCompletion cb, 
void *opaque)
  return -1;
  }

-ret = qemu_balloon_status(cb, opaque);
+ret = qemu_balloon_status(cb, opaque, !vm_running);
  if (!ret) {
  qerror_report(QERR_DEVICE_NOT_ACTIVE, balloon);
  return -1;
diff --git a/balloon.h b/balloon.h
index d478e28..729631c 100644
--- a/balloon.h
+++ b/balloon.h
@@ -17,13 +17,15 @@
  #include monitor.h

  typedef void (QEMUBalloonEvent)(void *opaque, ram_addr_t target,
-MonitorCompletion cb, void *cb_data);
+MonitorCompletion cb, void *cb_data,
+bool get_cached_data);

  void qemu_add_balloon_handler(QEMUBalloonEvent *func, void *opaque);

  int qemu_balloon(ram_addr_t target, MonitorCompletion cb, void *opaque);

-int qemu_balloon_status(MonitorCompletion cb, void *opaque);
+int qemu_balloon_status(MonitorCompletion cb, void *opaque,
+bool get_cached_data);

  void monitor_print_balloon(Monitor *mon, const QObject *data);
  int do_info_balloon(Monitor *mon, MonitorCompletion cb, void *opaque);
diff --git a/hw/virtio-balloon.c b/hw/virtio-balloon.c
index 9fe3886..68df891 100644
--- a/hw/virtio-balloon.c
+++ b/hw/virtio-balloon.c
@@ -195,7 +195,8 @@ static uint32_t virtio_balloon_get_features(VirtIODevice 
*vdev, uint32_t f)
  }

  static void virtio_balloon_to_target(void *opaque, ram_addr_t target,
- MonitorCompletion cb, void *cb_data)
+ MonitorCompletion cb, void *cb_data,
+ bool get_cached_data)
  {
  VirtIOBalloon *dev = opaque;

@@ -213,8 +214,12 @@ static void virtio_balloon_to_target(void *opaque, 
ram_addr_t target,
  return;
  }
  dev-stats_callback = cb;
-dev-stats_opaque_callback_data = cb_data;
+dev-stats_opaque_callback_data = cb_data;
  if (dev-vdev.guest_features  (1  VIRTIO_BALLOON_F_STATS_VQ)) {
+if (get_cached_data) {
+complete_stats_request(dev);
+return;
+}
  virtqueue_push(dev-svq,dev-stats_vq_elem, 
dev-stats_vq_offset);
  virtio_notify(dev-vdev, dev-svq);
  } else {


Acked-By: Paolo Bonzini pbonz...@redhat.com

Paolo

[Qemu-devel] [PATCH] virtio-9p: Change handling of flags in open() path for 9P2000.L

[Sripathi Kodi]

This patch applies on top of 9P2000.L patches that we have on the list.
I took a look at how 9P server is handling open() flags in 9P2000.L path.
I think we can do away with the valid_flags() function and simplify the
code. The reasoning is as follows:

O_NOCTTY: (If the file is a terminal, don't make it the controlling
terminal of the process even though the process does not have a controlling
terminal) By the time the control reaches 9P client it is clear that what
we have is not a terminal device. Hence it does not matter what we do with
this flag. In any case 9P server can filter this flag out before making the
syscall.

O_NONBLOCK: (Don't block if i) Can't read/write to the file ii) Can't get
locks) This has an impact on FIFOs, but also on file locks. Hence we can
pass it down to the system call.

O_ASYNC: From the manpage:

   O_ASYNC
  Enable signal-driven I/O: generate a signal (SIGIO by default,  but
  this  can be changed via fcntl(2)) when input or output becomes pos-
  sible on this file descriptor.  This feature is only available  for
  terminals,  pseudo-terminals,  sockets,  and (since Linux 2.6) pipes
  and FIFOs.  See fcntl(2) for further details.

Again, this does not make any impact on regular files handled by 9P. Also,
we don't want 9P server to receive SIGIO. Hence I think 9P server can
filter this flag out before making the syscall.

O_CLOEXEC: This flag makes sense only on the client. If guest user space
sets this flag the guest VFS will take care of calling close() on the fd if
an exec() happens. Hence 9P client need not be bothered with this flag.
Also I think QEMU will not do an exec, but if it does, it makes sense to
close these fds. Hence we can pass this flag down to the syscall.

O_CREAT: Since we are in open() path it means we have confirmed that the file
exists. Hence there is no need to pass O_CREAT flag down to the system. In fact
on some versions of glibc this causes problems, because we pass O_CREAT flag,
but don't have permission bits. Hence we can just mask this flag out.

So in summary:

Mask out:
O_NOCTTY
O_ASYNC
O_CREAT

Pass-through:
O_NONBLOCK
O_CLOEXEC

Signed-off-by: Sripathi Kodi sripat...@in.ibm.com
---

 hw/virtio-9p.c |   14 +-
 1 files changed, 1 insertions(+), 13 deletions(-)

diff --git a/hw/virtio-9p.c b/hw/virtio-9p.c
index 29fc648..7f659b8 100644
--- a/hw/virtio-9p.c
+++ b/hw/virtio-9p.c
@@ -1672,15 +1672,6 @@ out:
 qemu_free(vs);
 }
 
-static inline int valid_flags(int flag)
-{
-if (flag  O_NOCTTY || flag  O_NONBLOCK || flag  O_ASYNC ||
-flag  O_CLOEXEC)
-return 0;
-else
-return 1;
-}
-
 static void v9fs_open_post_lstat(V9fsState *s, V9fsOpenState *vs, int err)
 {
 int flags;
@@ -1697,11 +1688,8 @@ static void v9fs_open_post_lstat(V9fsState *s, 
V9fsOpenState *vs, int err)
 v9fs_open_post_opendir(s, vs, err);
 } else {
 if (s-proto_version == V9FS_PROTO_2000L) {
-if (!valid_flags(vs-mode)) {
-err = -EINVAL;
-goto out;
-}
 flags = vs-mode;
+flags = ~(O_NOCTTY | O_ASYNC | O_CREAT);
 } else {
 flags = omode_to_uflags(vs-mode);
 }

Re: [Qemu-devel] [PATCH 1/9] add pflib: PixelFormat conversion library.

[Gerd Hoffmann]

  Hi,


You can see the rest of the plumbing in the tree.


Hmm, make test (and trying to build anything in tests/) fails with 
separate source/build dirs.  But it isn't obvious to me why it does. 
The Makefile takes care to set vpath, so I think it should have picked 
up the source files just fine ...


Ideas anyone?

cheers,
  Gerd

RE: [Qemu-devel] qemu 0.12.5 sparc64 debian 505

[Laurikainen, Tuukka]

From: Blue Swirl [mailto:blauwir...@gmail.com]
 On Thu, Aug 19, 2010 at 8:44 PM, Artyom Tarasenko
 atar4q...@googlemail.com wrote:
  2010/8/19 Blue Swirl blauwir...@gmail.com:
  On Thu, Aug 19, 2010 at 10:15 AM, Laurikainen, Tuukka
  t.laurikai...@ibermatica.com wrote:
  Hi,
 
  As the Sparc64 support is not complete, I thought I'd ask here before
  reporting a bug.
 
  Trying to boot a Debian netboot cd image for Sparc with Qemu 0.12.5:
 
  # qemu-system-sparc64 -boot d -cdrom debian-505-sparc-businesscard.iso
  -nographic -hda sparc.img
  OpenBIOS for Sparc64
  Configuration device id QEMU version 1 machine id 0
  CPUs: 1 x SUNW,UltraSPARC-II
  UUID: ----
  Welcome to OpenBIOS v1.0 built on Dec 6 2009 11:16
   Type 'help' for detailed information
 
  [sparc64] Booting file 'cdrom' with parameters ''
  Not a bootable ELF image
  Not a Linux kernel image
  Loading a.out image...
  Loaded 7680 bytes
  entry point is 0x4000
  Jumping to entry point...
  switching to new context: entry point 0x4000 stack 0xffe02a71
  SILO Version 1.4.13
  \
 
                   Welcome to Debian GNU/Linux lenny!
 
  This is a Debian installation CDROM, built on 20100627-10:50.
  Keep it once you have installed your system, as you can boot from it
  to repair the system on your hard disk if that ever becomes necessary.
 
  WARNING: You should completely back up all of your hard disks before
   proceeding. The installation procedure can completely and
 irreversibly
   erase them! If you haven't made backups yet, remove the rescue CD
 from
   the drive and press L1-A to get back to the OpenBoot prompt.
 
  Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
  permitted
  by applicable law.
 
  [ ENTER - Boot install ]   [ Type expert - Boot into expert mode ]
                            [ Type rescue - Boot into rescue mode ]
  boot:
  Allocated 8 Megs of memory at 0x4000 for kernel
  Loaded kernel version 2.6.26
  Loading initial ramdisk (4310561 bytes at 0xC0 phys, 0x40C0
  virt)...
  qemu: unsupported keyboard cmd=0x02
  FLOPPY ERROR: fdctrl_unimplemented: unimplemented command 0xfe
  Pqemu: unsupported keyboard cmd=0xb1
  FLOPPY ERROR: fdctrl_unimplemented: unimplemented command 0xc4
 
  This is about how far Sparc64 boot gets now. With a custom kernel I
  get much further (IDE probe) but there are still a few unimplemented
  features.
 
  Is there a list of what is missing? You mentioned the pci bridges
  before. What else?
  Shall we maintain the TODO file for everything we find? Including
  things we may fix within a few days after finding?
 
 Actually, we have a TODO file, see under target-sparc. Thanks for
 reminding me. ;-)

Just to mention, I tried to boot this Debian image with the current git source, 
and it gets further:

...
[   93.369315] NET: Registered protocol family 17
[   93.528550] registered taskstats version 1
[   93.679537] drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
[   93.903757] su: Cannot register IRQ 0
[   94.452512] Kernel panic - not syncing: Attempted to kill init!
[   94.631524] Press Stop-A (L1-A) to return to the boot prom

Cheers,

Tuukka

[Qemu-devel] [PATCH 1/3] QemuOpts: allow new option groups be registered at runtime.

[Gerd Hoffmann]

Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
 qemu-config.c |   18 +-
 qemu-config.h |1 +
 2 files changed, 18 insertions(+), 1 deletions(-)

diff --git a/qemu-config.c b/qemu-config.c
index 95abe61..68880c2 100644
--- a/qemu-config.c
+++ b/qemu-config.c
@@ -342,7 +342,7 @@ QemuOptsList qemu_cpudef_opts = {
 },
 };
 
-static QemuOptsList *vm_config_groups[] = {
+static QemuOptsList *vm_config_groups[32] = {
 qemu_drive_opts,
 qemu_chardev_opts,
 qemu_device_opts,
@@ -374,6 +374,22 @@ QemuOptsList *qemu_find_opts(const char *group)
 return find_list(vm_config_groups, group);
 }
 
+void qemu_add_opts(QemuOptsList *list)
+{
+int entries, i;
+
+entries = ARRAY_SIZE(vm_config_groups);
+entries--; /* keep list NULL terminated */
+for (i = 0; i  entries; i++) {
+if (vm_config_groups[i] == NULL) {
+vm_config_groups[i] = list;
+return;
+}
+}
+fprintf(stderr, ran out of space in vm_config_groups);
+abort();
+}
+
 int qemu_set_option(const char *str)
 {
 char group[64], id[64], arg[64];
diff --git a/qemu-config.h b/qemu-config.h
index dca69d4..bf9bcc2 100644
--- a/qemu-config.h
+++ b/qemu-config.h
@@ -16,6 +16,7 @@ extern QemuOptsList qemu_mon_opts;
 extern QemuOptsList qemu_cpudef_opts;
 
 QemuOptsList *qemu_find_opts(const char *group);
+void qemu_add_opts(QemuOptsList *list);
 int qemu_set_option(const char *str);
 int qemu_global_option(const char *str);
 void qemu_add_globals(void);
-- 
1.7.1

[Qemu-devel] [PATCH 3/3] compile -fsdev and -virtfs cmd line options unconditionally.

[Gerd Hoffmann]

Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
 qemu-options.hx |4 
 vl.c|   17 +
 2 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/qemu-options.hx b/qemu-options.hx
index db86feb..453f129 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -482,7 +482,6 @@ possible drivers and properties, use @code{-device ?} and
 @code{-device @var{driver},?}.
 ETEXI
 
-#ifdef CONFIG_LINUX
 DEFHEADING(File system options:)
 
 DEF(fsdev, HAS_ARG, QEMU_OPTION_fsdev,
@@ -515,9 +514,7 @@ Create a file-system-device for local-filesystem.
 
 @end table
 ETEXI
-#endif
 
-#ifdef CONFIG_LINUX
 DEFHEADING(Virtual File system pass-through options:)
 
 DEF(virtfs, HAS_ARG, QEMU_OPTION_virtfs,
@@ -554,7 +551,6 @@ Create a Virtual file-system-pass through for 
local-filesystem.
 
 @end table
 ETEXI
-#endif
 
 DEFHEADING()
 
diff --git a/vl.c b/vl.c
index 158aeaf..1d102e6 100644
--- a/vl.c
+++ b/vl.c
@@ -1811,6 +1811,7 @@ int main(int argc, char **argv, char **envp)
 DisplayChangeListener *dcl;
 int cyls, heads, secs, translation;
 QemuOpts *hda_opts = NULL, *opts;
+QemuOptsList *olist;
 int optind;
 const char *optarg;
 const char *loadvm = NULL;
@@ -2286,9 +2287,13 @@ int main(int argc, char **argv, char **envp)
 exit(1);
 }
 break;
-#ifdef CONFIG_VIRTFS
 case QEMU_OPTION_fsdev:
-opts = qemu_opts_parse(qemu_find_opts(fsdev), optarg, 1);
+olist = qemu_find_opts(fsdev);
+if (!olist) {
+fprintf(stderr, fsdev is not supported by this qemu 
build.\n);
+exit(1);
+}
+opts = qemu_opts_parse(olist, optarg, 1);
 if (!opts) {
 fprintf(stderr, parse error: %s\n, optarg);
 exit(1);
@@ -2299,7 +2304,12 @@ int main(int argc, char **argv, char **envp)
 char *arg_9p = NULL;
 int len = 0;
 
-opts = qemu_opts_parse(qemu_find_opts(virtfs), optarg, 1);
+olist = qemu_find_opts(virtfs);
+if (!olist) {
+fprintf(stderr, virtfs is not supported by this qemu 
build.\n);
+exit(1);
+}
+opts = qemu_opts_parse(olist, optarg, 1);
 if (!opts) {
 fprintf(stderr, parse error: %s\n, optarg);
 exit(1);
@@ -2362,7 +2372,6 @@ int main(int argc, char **argv, char **envp)
 qemu_free(arg_9p);
 break;
 }
-#endif
 case QEMU_OPTION_serial:
 add_device_config(DEV_SERIAL, optarg);
 default_serial = 0;
-- 
1.7.1

Re: [Qemu-devel] [PATCH 5/9] spice: core bits

[Gerd Hoffmann]

+#ifdef CONFIG_SPICE


Now's probably a good time to make vm_config_groups a list that can be
dynamically added to so that you can register the option group from
within spice.c.

This would require a new qemu_opts_parse() that took a name of an
QemuOptsList instead of the pointer to it but then you can return
failure if spice is unsupported.


Ah, you want me fix virtfs too ;)

Patches are on the list.  Well, at least a start.  For further cleanups 
we'll need some more *_init() magic for the non-devices stuff.


cheers,
  Gerd

Re: [Qemu-devel] [PATCH] virtio-serial: Cleanup on device hot-unplug

[Amit Shah]

On (Thu) Aug 19 2010 [06:51:04], Amit Shah wrote:
 Free malloc'ed memory, unregister from savevm and clean up virtio-common
 bits on device hot-unplug.
 
 This was found performing a migration after device hot-unplug.
 
 Reported-by: lihu...@redhat.com
 Signed-off-by: Amit Shah amit.s...@redhat.com
 ---
  hw/virtio-pci.c|   10 +-
  hw/virtio-serial-bus.c |   17 +
  hw/virtio.h|1 +
  3 files changed, 27 insertions(+), 1 deletions(-)

Please pick this for 0.13 as well.

Thanks,

Amit

Re: [Qemu-devel] [PATCH V2] balloon: Don't try fetching info if machine is stopped

[Amit Shah]

On (Fri) Aug 20 2010 [06:18:11], Amit Shah wrote:
 If the machine is stopped and 'info balloon' is invoked, the monitor
 process just hangs waiting for info from the guest. Return the most
 recent balloon data in that case.
 
 See https://bugzilla.redhat.com/show_bug.cgi?id=623903
 
 Reported-by: lihu...@redhat.com
 Signed-off-by: Amit Shah amit.s...@redhat.com
 ---
 v2: simplify call to qemu_balloon_status - Paulo
 
  balloon.c   |   11 +++
  balloon.h   |6 --
  hw/virtio-balloon.c |9 +++--
  3 files changed, 18 insertions(+), 8 deletions(-)

Please pick this for 0.13 as well.

Thanks,

Amit

Re: [Qemu-devel] [PATCH 6/9] spice: add keyboard

[Gerd Hoffmann]

+static const SpiceKbdInterface kbd_interface = {
+ .base.type = SPICE_INTERFACE_KEYBOARD,
+ .base.description = qemu keyboard,
+ .base.major_version = SPICE_INTERFACE_KEYBOARD_MAJOR,
+ .base.minor_version = SPICE_INTERFACE_KEYBOARD_MINOR,
+ .push_scan_freg = kbd_push_key,
+ .get_leds = kbd_get_leds,
+};
+
+static void kbd_push_key(SpiceKbdInstance *sin, uint8_t frag)
+{
+ kbd_put_keycode(frag);
+}


Instead of using this interface which includes multi-byte sequences, it
would probably make sense to use the same compressed encoding that VNC
uses and introduce a new function that takes this encoding type. The
advantage is that one call == one keycode so it's far less prone to
goofiness.


Hmm?  Not sure what you want here ...

kbd_push_key is called by libspice which feeds us with a ps/2 data 
stream for the keyboard.  Yes, one of those x86-isms in spice.  Yes, the 
ps/2 data stream also travels over the wire, i.e. the spice client has 
to hop through loops to convert whatever it gets into a ps/2 data stream 
for us.


Luckily ps/2 data is exactly what qemu expects to get via 
kbd_put_keycode, so I can simply pass on what I get, and it is IMHO 
pretty pointless to do something else ...



It's probably more robust in the long term to explicitly convert the
ledstate to from the QEMU format to the libspice format even if they
both happen to be the same.


Ok.

cheers,
  Gerd

Re: [Qemu-devel] [PATCH 7/9] spice: add mouse

[Gerd Hoffmann]

  Hi,


+static void mouse_motion(SpiceMouseInstance *sin, int dx, int dy, int
dz,
+ uint32_t buttons_state)
+{
+ kbd_mouse_event(dx, dy, dz, buttons_state);


dz is an odd interface. We use it to represent additional buttons which
really makes no sense. If you still can, I'd suggest moving dz into
buttons_state.


Again this is libspice interface (and I think also wire protocol), so I 
can't change it.  I can convert dz into some button_mask bits before 
calling kbd_mouse_event, but looking at the vnc code it seems qemu 
expects the mouse wheel events being passed via dz not button_state.



Previous comment still applies though, you should explicitly convert the
button_states from QEMU format to Spice format to future proof.


Ok.

cheers,
  Gerd

Re: [Qemu-devel] [PATCH 6/9] spice: add keyboard

[Anthony Liguori]

On 08/20/2010 07:34 AM, Gerd Hoffmann wrote:



+static const SpiceKbdInterface kbd_interface = {
+ .base.type = SPICE_INTERFACE_KEYBOARD,
+ .base.description = qemu keyboard,
+ .base.major_version = SPICE_INTERFACE_KEYBOARD_MAJOR,
+ .base.minor_version = SPICE_INTERFACE_KEYBOARD_MINOR,
+ .push_scan_freg = kbd_push_key,
+ .get_leds = kbd_get_leds,
+};
+
+static void kbd_push_key(SpiceKbdInstance *sin, uint8_t frag)
+{
+ kbd_put_keycode(frag);
+}


Instead of using this interface which includes multi-byte sequences, it
would probably make sense to use the same compressed encoding that VNC
uses and introduce a new function that takes this encoding type. The
advantage is that one call == one keycode so it's far less prone to
goofiness.


Hmm?  Not sure what you want here ...

kbd_push_key is called by libspice which feeds us with a ps/2 data 
stream for the keyboard.  Yes, one of those x86-isms in spice.  Yes, 
the ps/2 data stream also travels over the wire, i.e. the spice client 
has to hop through loops to convert whatever it gets into a ps/2 data 
stream for us.


Luckily ps/2 data is exactly what qemu expects to get via 
kbd_put_keycode, so I can simply pass on what I get, and it is IMHO 
pretty pointless to do something else ...


It's not actually ps/2 data.  It's AT scan codes plus an internal 
encoding to indicate press vs. release using the high bit.  
Additionally, some special keys are encoded with two calls to 
kbd_put_keycode using the 0xe0 prefix (the grey code).


That gets converted to ps/2 data by decoding the high bit and generating 
a special PS/2 keyboard sequence if necessary.  The grey sequence just 
happens to work because the logic in ps2_put_keycode is simple.  IOW, 
the ps/2 protocol looks like:


[0xe0,][0xf0,]raw_keycode

0xe0 indicates that the keycode is a grey code and 0xf0 indicates it's 
a key release event.  raw_keycode is a PS/2 raw keycode that has a 1-1 
mapping from AT scan codes.


To generate the possible sequences, we would do:

// normal key press; PS/2: at2raw(at_keycode)
kbd_put_keycode(at_keycode);

// grey key press; PS/2 0xe0, at2raw(at_keycode)
kbd_put_keycode(0xe0);
kbd_put_keycode(at_keycode);

// normal key release; PS/2 0xf0, at2raw(at_keycode)
kbd_put_keycode(at_keycode | 0x80);

// grey key release; PS/2 0xe0, 0xf0, at2raw(at_keycode)
kbd_put_keycode(0xe0);
kbd_put_keycode(at_keycode | 0x80);

In the VNC encoding, instead of using the high bit to represent the key 
down vs. key up event, we use separate messages for key down vs. key 
up.  We then use the high bit to encode whether the grey code is needed 
which let's us send keycodes in a single message with a fixed keycode 
size of 8 bits.


So what I'm proposing is that we modify kbd_put_keycode to also reflect 
this:


// normal keys
kbd_keycode_press(at_keycode);  // PS/2 at2raw(at_keycode)
kbd_keycode_release(at_keycode);   // PS/2 0xf0, at2raw(at_keycode)

// grey keys; PS/2 0xe0, at2raw(at_keycode)
kbd_keycode_press(0x80 | at_keycode);  // PS/2 0xe0, 0xf0, 
at2raw(at_keycode)
kbd_keycode_release(0x80 | at_keycode);   // PS/2 0xe0, 0xf0, 
at2raw(at_keycode)


If it's not already too late, I'd suggest making this the Spice protocol 
interface.  The current kbd_put_keycode interface is just a QEMU 
implementation detail and having different size byte sequences is a very 
awkward interface.


Regards,

Anthony Liguori


It's probably more robust in the long term to explicitly convert the
ledstate to from the QEMU format to the libspice format even if they
both happen to be the same.


Ok.

cheers,
  Gerd

Re: [Qemu-devel] [PATCH 7/9] spice: add mouse

[Anthony Liguori]

On 08/20/2010 07:42 AM, Gerd Hoffmann wrote:

  Hi,


+static void mouse_motion(SpiceMouseInstance *sin, int dx, int dy, int
dz,
+ uint32_t buttons_state)
+{
+ kbd_mouse_event(dx, dy, dz, buttons_state);


dz is an odd interface. We use it to represent additional buttons which
really makes no sense. If you still can, I'd suggest moving dz into
buttons_state.


Again this is libspice interface (and I think also wire protocol), so 
I can't change it.  I can convert dz into some button_mask bits before 
calling kbd_mouse_event, but looking at the vnc code it seems qemu 
expects the mouse wheel events being passed via dz not button_state.


That's unfortunate but understood.  Is Spice considered a stable 
API/wire protocol at this point?


Regards,

Anthony Liguori




Previous comment still applies though, you should explicitly convert the
button_states from QEMU format to Spice format to future proof.


Ok.

cheers,
  Gerd

Re: [Qemu-devel] [PATCH - V3] Port codes from qemu-kvm to support booting from SCSI disk image

[Anthony Liguori]

On 08/20/2010 02:44 AM, Gerd Hoffmann wrote:

On 08/18/10 17:16, Alexander Graf wrote:



This has been discussed several times before. The proper solution
is to teach the bios how to boot off SCSI devices. IIRC support for
virtio devices already exists, implementing support for the SCSI
controller shouldn't be that much harder.


Couldn't we just have an option rom for the SCSI controller? The same
way the VGABIOS is a rewrite of a VGA BIOS for the Cirrus Logic...


There already is one.  Needs qemu 0.12.4 or newer.  Unfortunaly it 
isn't redistributable, so we can't easily integrate it.  Thus seabios 
support or a free option rom would still be nice to have.


Fetch 
http://www.lsi.com/DistributionSystem/AssetDocument/files/support/ssp/sdms/Bios/lsi_bios.zip 
- unzip - boot with -option-rom 8xx_64.rom


Maybe we could switch PCIDevice to default romfile to try to 
devicename.rom if none is specified.  Since qdev names are unique, 
this should work well.


That way, users could install the lsi rom if they really wanted to 
SCSI boot until someone writes proper SCSI boot support.


Regards,

Anthony Liguori


cheers,
  Gerd

Re: [Qemu-devel] [PATCH 0/5] CODING_STYLE amendments

[Markus Armbruster]

Anthony Liguori anth...@codemonkey.ws writes:

 On 08/17/2010 03:04 AM, Jes Sorensen wrote:
 On 08/13/10 20:02, Blue Swirl wrote:

 On Fri, Aug 13, 2010 at 3:22 PM, Miguel Di Ciurcio Filho
 miguel.fi...@gmail.com  wrote:
  
 The existing code that I have touched don't follow the current coding
 style guidance, much less all the new recommendations being suggested.

 Although, I do believe that this situation needs to change. If we
 agree in a coding style, I would volunteer to be a some kind of
 observer to fix and alert people about coding styles mistakes.

 I fully agree on the need of change and support your excellent idea.
 There are other ways to solve the problem, but I believe we need more
 order than more chaos. Perhaps we the QEMU developers should appoint
 you the Guardian of the CODING_STYLE, and add a rule that no patch
 shall be committed without your CS-Acked-by line?
  
 I don't think this would ever work, it is begging for trouble relying on
 one person to review all patches for this.

 While I agree coding style is good since it enforces consistency, there
 are plenty problems with the old rules

 To be perfectly honest, we have enough hard problems to solve in QEMU.
 We're spending a lot more time on coding style than we probably need
 to :-)

In my not so humble opinion, that's because the current CODING_STYLE is
idiosyncratic, widely disliked (follows from idiosyncratic pretty much
inevitably), widely violated by existing code, and only haphazardly
enforced for new code.

I'd support switching to Linux kernel style.  Then we can point people
complaining about it to Linux (good luck getting it changed there), use
Linux's tools to check for compliance (beats building our own), and move
on to more productive issues.

Re: [Qemu-devel] [PATCH 6/9] spice: add keyboard

[Gerd Hoffmann]

  Hi,


It's not actually ps/2 data. It's AT scan codes plus an internal
encoding to indicate press vs. release using the high bit. Additionally,
some special keys are encoded with two calls to kbd_put_keycode using
the 0xe0 prefix (the grey code).


Wheee.  From a brief look at the code it seems this *is* the spice wire 
protocol.  One more place where spice uses knowledge about qemu 
internals.  Unfortunaly this one escaped my attention until now, so it 
didn't got fixed :-(



So what I'm proposing is that we modify kbd_put_keycode to also reflect
this:

// normal keys
kbd_keycode_press(at_keycode); // PS/2 at2raw(at_keycode)
kbd_keycode_release(at_keycode); // PS/2 0xf0, at2raw(at_keycode)

// grey keys; PS/2 0xe0, at2raw(at_keycode)
kbd_keycode_press(0x80 | at_keycode); // PS/2 0xe0, 0xf0,
at2raw(at_keycode)
kbd_keycode_release(0x80 | at_keycode); // PS/2 0xe0, 0xf0,
at2raw(at_keycode)

If it's not already too late, I'd suggest making this the Spice protocol
interface.


No.  I think for now I have to deal with the mess in case qemu decides 
to change the internal interface.  And when ever touching the spice wire 
protocol to fixup this mess I will *not* use AT keycodes.  Handling 
anything with extra internet / multimedia / whatever keys in a sane way 
is simply impossible with AT keycodes.  linux input layer key codes 
should do.  maybe usb hid is usable too, need to check.


cheers,
  Gerd

Re: [Qemu-devel] [PATCH 7/9] spice: add mouse

[Gerd Hoffmann]

  Hi,


Again this is libspice interface (and I think also wire protocol), so
I can't change it. I can convert dz into some button_mask bits before
calling kbd_mouse_event, but looking at the vnc code it seems qemu
expects the mouse wheel events being passed via dz not button_state.


That's unfortunate but understood. Is Spice considered a stable API/wire
protocol at this point?


Yes.  There are version numbers though, so we can add new messages and 
use them in case both server and client are new enough.  Unfortunaly 
this makes the keyboard f*ckup only slightly less messy as we'll have to 
support both old+new way for compatibility reasons.  Oh well.


cheers,
  Gerd

Re: [Qemu-devel] [PATCH - V3] Port codes from qemu-kvm to support booting from SCSI disk image

[Gerd Hoffmann]

  Hi,


Fetch
http://www.lsi.com/DistributionSystem/AssetDocument/files/support/ssp/sdms/Bios/lsi_bios.zip
- unzip - boot with -option-rom 8xx_64.rom


Maybe we could switch PCIDevice to default romfile to try to
devicename.rom if none is specified. Since qdev names are unique, this
should work well.


Been there, tried that.  It isn't *that* easy.  The PCI ID in the option 
rom header doesn't match the PCI ID of the emulated lsi, so seabios 
refuses to load it from the rom bar.


cheers,
  Gerd

Re: [Qemu-devel] [PATCH 6/9] spice: add keyboard

[Daniel P. Berrange]

On Fri, Aug 20, 2010 at 03:56:52PM +0200, Gerd Hoffmann wrote:
   Hi,
 
 It's not actually ps/2 data. It's AT scan codes plus an internal
 encoding to indicate press vs. release using the high bit. Additionally,
 some special keys are encoded with two calls to kbd_put_keycode using
 the 0xe0 prefix (the grey code).
 
 Wheee.  From a brief look at the code it seems this *is* the spice wire 
 protocol.  One more place where spice uses knowledge about qemu 
 internals.  Unfortunaly this one escaped my attention until now, so it 
 didn't got fixed :-(
 
 So what I'm proposing is that we modify kbd_put_keycode to also reflect
 this:
 
 // normal keys
 kbd_keycode_press(at_keycode); // PS/2 at2raw(at_keycode)
 kbd_keycode_release(at_keycode); // PS/2 0xf0, at2raw(at_keycode)
 
 // grey keys; PS/2 0xe0, at2raw(at_keycode)
 kbd_keycode_press(0x80 | at_keycode); // PS/2 0xe0, 0xf0,
 at2raw(at_keycode)
 kbd_keycode_release(0x80 | at_keycode); // PS/2 0xe0, 0xf0,
 at2raw(at_keycode)
 
 If it's not already too late, I'd suggest making this the Spice protocol
 interface.
 
 No.  I think for now I have to deal with the mess in case qemu decides 
 to change the internal interface.  And when ever touching the spice wire 
 protocol to fixup this mess I will *not* use AT keycodes.  Handling 
 anything with extra internet / multimedia / whatever keys in a sane way 
 is simply impossible with AT keycodes.  linux input layer key codes 
 should do.  maybe usb hid is usable too, need to check.

AT (well XT) keycodes aren't that bad a choice, at least if you go for the
extended mapping used by the Linux keyboard driver. This supports pretty
much all of the internet/multimedia keys, AFAICT, more than USB hid
does (at least in the Linux USB HID driver). In order to properly support
the VNC keycode extension with GTK-VNC under  Xorg + Win32, OS-X and Linux,
as well as native OS-X  Win32, I've created a giant CSV mapping file for
all keycode sets that I've encountered so far.

The master mapping is from Linux keycodes to other sets:

  http://git.gnome.org/browse/gtk-vnc/tree/src/keymaps.csv

And a tool that can then create you C arrays for mapping between
arbitrary keycode sets in any direction (potentially lossy
of course, depending on choice of keycode sets):

  http://git.gnome.org/browse/gtk-vnc/tree/src/keymap-gen.pl

Regards,
Daniel
-- 
|: Red Hat, Engineering, London-o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org-o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

[Qemu-devel] Re: [PATCH] vnc: check fd before calling qemu_set_fd_handler2() in vnc_client_write()

[Corentin Chary]

On Fri, Aug 20, 2010 at 12:10 PM, Yoshiaki Tamura
tamura.yoshi...@lab.ntt.co.jp wrote:
 Setting fd = -1 to qemu_set_fd_handler2() causes bus error at FD_SET
 in main_loop_wait().

 Signed-off-by: Yoshiaki Tamura tamura.yoshi...@lab.ntt.co.jp
 ---
  ui/vnc.c |    2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

 diff --git a/ui/vnc.c b/ui/vnc.c
 index 7fc40ac..c7a1831 100644
 --- a/ui/vnc.c
 +++ b/ui/vnc.c
 @@ -1184,7 +1184,7 @@ void vnc_client_write(void *opaque)
     vnc_lock_output(vs);
     if (vs-output.offset) {
         vnc_client_write_locked(opaque);
 -    } else {
 +    } else if (vs-csock != -1) {
         qemu_set_fd_handler2(vs-csock, NULL, vnc_client_read, NULL, vs);
     }
     vnc_unlock_output(vs);
 --
 1.7.1.1



Acked-By: Corentin Chary corenti...@iksaif.net

-- 
Corentin Chary
http://xf.iksaif.net

Re: [Qemu-devel] [PATCH 7/9] spice: add mouse

[Anthony Liguori]

On 08/20/2010 09:03 AM, Gerd Hoffmann wrote:

  Hi,


Again this is libspice interface (and I think also wire protocol), so
I can't change it. I can convert dz into some button_mask bits before
calling kbd_mouse_event, but looking at the vnc code it seems qemu
expects the mouse wheel events being passed via dz not button_state.


That's unfortunate but understood. Is Spice considered a stable API/wire
protocol at this point?


Yes.  There are version numbers though, so we can add new messages and 
use them in case both server and client are new enough.  Unfortunaly 
this makes the keyboard f*ckup only slightly less messy as we'll have 
to support both old+new way for compatibility reasons.  Oh well.


One of the things to consider is that we only emulate a 2-axis 5 button 
mouse.  Buttons one through three are bits in button_state and buttons 
4/5 are represented through dz.  My mouse IRL is actually a 9 button mouse.


We encode buttons 4/5 as a -1, 0, 1 in dz which corresponds to 10, 00, 
and 11.  We cannot represent 11 with dz which corresponds to having 
buttons 4 and 5 pressed simultaneously.  Most mice have a scroll wheel 
for 4/5 but there's no strict requirement that that's the case.


So in terms of building a long term stable wire protocol, you'd be much 
better off using button_mask to encode buttons 4/5 because it's just a 
matter of time before we drop the dz hack in qemu.


Regards,

Anthony Liguori


cheers,
  Gerd

Re: [Qemu-devel] [PATCH - V3] Port codes from qemu-kvm to support booting from SCSI disk image

[Anthony Liguori]

On 08/20/2010 09:09 AM, Gerd Hoffmann wrote:

  Hi,


Fetch
http://www.lsi.com/DistributionSystem/AssetDocument/files/support/ssp/sdms/Bios/lsi_bios.zip 


- unzip - boot with -option-rom 8xx_64.rom


Maybe we could switch PCIDevice to default romfile to try to
devicename.rom if none is specified. Since qdev names are unique, this
should work well.


Been there, tried that.  It isn't *that* easy.  The PCI ID in the 
option rom header doesn't match the PCI ID of the emulated lsi, so 
seabios refuses to load it from the rom bar.


Heh, I was wondering why it didn't work unless I put rombar=0 :-)

Is this fixable in a reasonable way or does PCI ID in the option rom 
represent a much newer device that would trigger issues with guest drivers?


Regards,

Anthony Liguori


cheers,
  Gerd

Re: [Qemu-devel] [PATCH 6/9] spice: add keyboard

[Gerd Hoffmann]

  Hi,


AT (well XT) keycodes aren't that bad a choice, at least if you go for the
extended mapping used by the Linux keyboard driver.


Hmm, as far I know those extended mappings are not standardized.  Uses 
linux this just as internal representation?  Or can you actually feed a 
linux guest with them and expect it to work?  How about non-linux guests?


When using it as wire protocol guest compatibility doesn't matter that 
much though ...



The master mapping is from Linux keycodes to other sets:

   http://git.gnome.org/browse/gtk-vnc/tree/src/keymaps.csv

And a tool that can then create you C arrays for mapping between
arbitrary keycode sets in any direction (potentially lossy
of course, depending on choice of keycode sets):

   http://git.gnome.org/browse/gtk-vnc/tree/src/keymap-gen.pl


Nice.

cheers,
  Gerd

Re: [Qemu-devel] [PATCH] qdev: Reset hotplugged devices

[Markus Armbruster]

Alex Williamson alex.william...@redhat.com writes:

 On Fri, 2010-08-20 at 11:00 +0200, Markus Armbruster wrote:
 Alex Williamson alex.william...@redhat.com writes:
 
  Several devices rely on their reset() function being called to
  initialize device state, e1000 and rtl8139 in particular.  When
  the device is hot added, the reset doesn't occur, often leaving
  the device in an unusable state.  Adding a call to reset() after
  init() for hotplugged devices puts the device in the expected
  state for the guest.
 
  Signed-off-by: Alex Williamson alex.william...@redhat.com
  ---
 
   0.13 candidate?
 
   hw/qdev.c |3 +++
   1 files changed, 3 insertions(+), 0 deletions(-)
 
  diff --git a/hw/qdev.c b/hw/qdev.c
  index e99c73f..b156272 100644
  --- a/hw/qdev.c
  +++ b/hw/qdev.c
  @@ -278,6 +278,9 @@ int qdev_init(DeviceState *dev)
   qdev_free(dev);
   return rc;
   }
  +if (dev-hotplugged) {
  +qdev_reset(dev);
  +}
   qemu_register_reset(qdev_reset, dev);
   if (dev-info-vmsd) {
   vmstate_register_with_alias_id(dev, -1, dev-info-vmsd, dev,
 
 qdev_reset() isn't necessary when !dev-hotplugged, because then
 qemu_system_reset() will run shortly, which will call qdev_reset().
 Correct?

 Yes, exactly.

Hmm.  qdev_init() automatically calls qdev_reset() if hotplug feels
needlessly complicated.  I'd prefer qdev_init() to call it always or
never.

If always, we reset twice for cold-plug.  Is that bad?

If never, we need to reset somewhere else for hot-plug.  What about
do_device_add()?

Re: [Qemu-devel] [PATCH 4/4] QMP: Update README file

[Markus Armbruster]

Luiz Capitulino lcapitul...@redhat.com writes:

 A number of changes I prefer to do in one shot:

 - Fix example
 - Small clarifications
 - Add multiple monitors example
 - Add 'Development Process' section

 Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
 ---
  QMP/README |   71 ---
  1 files changed, 48 insertions(+), 23 deletions(-)

 diff --git a/QMP/README b/QMP/README
 index 35a80c7..b23f186 100644
 --- a/QMP/README
 +++ b/QMP/README
 @@ -7,60 +7,85 @@ Introduction
  The QEMU Monitor Protocol (QMP) allows applications to communicate with
  QEMU's Monitor.
  
 -QMP is JSON[1] based and has the following features:
 +QMP is JSON[1] based and currently has the following features:
  
  - Lightweight, text-based, easy to parse data format
 -- Asynchronous events support 
 -- Stability
 +- Asynchronous messages support (ie. events)
 +- Capabilities Negotiation
  
 -For more information, please, refer to the following files:
 +For detailed information on QMP's usage, please, refer to the following 
 files:
  
  o qmp-spec.txt  QEMU Monitor Protocol current specification
 -o qmp-commands.txt  QMP supported commands
 +o qmp-commands.txt  QMP supported commands (auto-generated at build-time)
  o qmp-events.txtList of available asynchronous events
  
  There are also two simple Python scripts available:
  
 -o qmp-shell   A shell
 -o vm-info Show some information about the Virtual Machine
 +o qmp-shell  A shell
 +o vm-infoShow some information about the Virtual Machine
 +
 +IMPORTANT: It's strongly recommended to read the 'Stability Considerations'
 +section in the qmp-commands.txt file before making any serious use of QMP.
 +
  
  [1] http://www.json.org
  
  Usage
  -
  
 -To enable QMP, QEMU has to be started in control mode. There are
 -two ways of doing this, the simplest one is using the the '-qmp'
 -command-line option.
 +To enable QMP, you need a QEMU monitor instance in control mode. There are
 +two ways of doing this.
 +
 +The simplest one is using the '-qmp' command-line option. The following
 +example makes QMP available on localhost port :
  
 -For example:
 +  $ qemu [...] -qmp tcp:localhost:,server
  
 -$ qemu [...] -qmp tcp:localhost:,server
 +However, in order to have more complex combinations, like multiple monitors,
 +the '-mon' command-line option should be used along with the '-chardev' one.
 +For instance, the following example creates one user monitor on stdio and one
 +QMP monitor on localhost port .
  
 -Will start QEMU in control mode, waiting for a client TCP connection
 -on localhost port .
 +   $ qemu [...] -chardev stdio,id=mon0 -mon chardev=mon0,mode=readline \
 +-chardev socket,id=mon1,host=localhost,port=,server \
 +-mon chardev=mon1,mode=control
  
 -It is also possible to use the '-mon' command-line option to have
 -more complex combinations. Please, refer to the QEMU's manpage for
 -more information.
 +Please, refer to QEMU's manpage for more information.
  
  Simple Testing
  --
  
 -To manually test QMP one can connect with telnet and issue commands:
 +To manually test QMP one can connect with telnet and issue commands by hand:
  
  $ telnet localhost 
  Trying 127.0.0.1...
  Connected to localhost.
  Escape character is '^]'.
 -{QMP: {version: {qemu: 0.12.50, package: }, capabilities: []}}
 +{QMP: {version: {qemu: {micro: 50, minor: 13, major: 0}, 
 package: }, capabilities: []}}

Doesn't this belong into 2/4?

  { execute: qmp_capabilities }
  {return: {}}
  { execute: query-version }
 -{return: {qemu: 0.12.50, package: }}
 +{return: {qemu: {micro: 50, minor: 13, major: 0}, package: }}

This too.

Doubt it's worth a respin, though.

 +
 +Development Process
 +---
 +
 +When changing QMP's interface (by adding new commands, events or modifying
 +existing ones) it's mandatory to update the relevant documentation, which is
 +one (or more) of the files listed in the 'Introduction' section*.
 +
 +Also, it's strongly recommended to send the documentation patch first, before
 +doing any code change. This is so because:
 +
 +  1. Avoids the code dictating the interface
 +
 +  2. It's very likely that the interface will change during review, updating
 + the code at the same time might be a big waste of time

Very likely sounds a bit discouraging, doesn't it?  What about

2. Review can improve your interface.  Letting that happen before
you implement it can save you work.

 +
 +* The qmp-commands.txt file is generated from the qemu-monitor.hx one, which
 +  is the file that should be edited.
  
 -Contact
 
 +Homepage
 +
  
  http://www.linux-kvm.org/page/MonitorProtocol
 -Luiz Fernando N. Capitulino lcapitul...@redhat.com

Re: [Qemu-devel] [PATCH] qdev: Reset hotplugged devices

[Markus Armbruster]

Anthony Liguori anth...@codemonkey.ws writes:

 On 08/20/2010 10:47 AM, Markus Armbruster wrote:
 Alex Williamsonalex.william...@redhat.com  writes:


 On Fri, 2010-08-20 at 11:00 +0200, Markus Armbruster wrote:
  
 Alex Williamsonalex.william...@redhat.com  writes:


 Several devices rely on their reset() function being called to
 initialize device state, e1000 and rtl8139 in particular.  When
 the device is hot added, the reset doesn't occur, often leaving
 the device in an unusable state.  Adding a call to reset() after
 init() for hotplugged devices puts the device in the expected
 state for the guest.

 Signed-off-by: Alex Williamsonalex.william...@redhat.com
 ---

   0.13 candidate?

   hw/qdev.c |3 +++
   1 files changed, 3 insertions(+), 0 deletions(-)

 diff --git a/hw/qdev.c b/hw/qdev.c
 index e99c73f..b156272 100644
 --- a/hw/qdev.c
 +++ b/hw/qdev.c
 @@ -278,6 +278,9 @@ int qdev_init(DeviceState *dev)
   qdev_free(dev);
   return rc;
   }
 +if (dev-hotplugged) {
 +qdev_reset(dev);
 +}
   qemu_register_reset(qdev_reset, dev);
   if (dev-info-vmsd) {
   vmstate_register_with_alias_id(dev, -1, dev-info-vmsd, dev,
  
 qdev_reset() isn't necessary when !dev-hotplugged, because then
 qemu_system_reset() will run shortly, which will call qdev_reset().
 Correct?

 Yes, exactly.
  
 Hmm.  qdev_init() automatically calls qdev_reset() if hotplug feels
 needlessly complicated.  I'd prefer qdev_init() to call it always or
 never.

 If always, we reset twice for cold-plug.  Is that bad?

 If never, we need to reset somewhere else for hot-plug.  What about
 do_device_add()?


 The real problem is how we do reset.  We shouldn't register a reset
 handler for every qdev device but rather register a single reset
 handler that walks the device tree and calls reset on every reachable
 device.

 Then we can always call reset in init() and there's no need to have a
 dev-hotplugged check.  The qdev device tree reset handler should not
 be registered until *after* we call qemu_system_reset() after creating
 the device model which will ensure that we don't do a double reset.

Fine with me.

But we need to merge something short term (pre 0.13) to fix hot plug of
e1000 et al.  Use Alex's patch as such a stop-gap?

Re: [Qemu-devel] [PATCH v2 0/7] APIC/IOAPIC cleanup

[Markus Armbruster]

Anthony Liguori anth...@codemonkey.ws writes:

 On 08/19/2010 04:21 PM, Blue Swirl wrote:
 Should CPUs appear in the QEMU device tree?
  
 They have several properties that should be user visible.


 Sure, but that's an argument for having some of the qdev features
 (like variant properties) be consumable outside of qdev.

While that might be useful, I don't quite see what makes CPUs so special
that they need to be kept out of qdev.  Could be just my ignorance, of
course.

 requirement to sit on a bus.  A UART16650A does not sit on bus.  It sits on
 a card and is wired to the ISA bus or is sometimes wired directly to pins on
 a CPU on a SoC.
  
 Or all buses should be unified, so all devices could be wired into any board.

 But that defeats the notion of having bus level interfaces.  You
 really want the virtio PCI layer to only use PCI functions and
 specifically to interact with PCI concepts that don't exist in other
 busses (like IO regions and config space).  However, you also want the
 ability to interact with a virtio device through a well defined
 interface that isn't PCI specific.

 The only way to do this right now is having a bus with a single
 device.  I've been working on the serial device, and what this
 requires is having an ISASerialDevice which is-a ISADevice.  The
 ISASerialDevice has-a 
 SerialBus and the SerialBus contain a single SerialDevice which is-a 
 DeviceState.

It needs to be a SerialBusDevice, not just a DeviceState, actually.

 But the ISASerialDevice has to assume that the SerialBus contains only
 a single child because it needs to connect the GPIO out from the
 SerialDevice to the ISA irq that's assigned.

 It would be a whole lot simpler to break the all devices sit on
 busses assumption that we have today and simply have the
 ISASerialDevice has-a 
 SerialDevice with no additional layers of bus indirection.

What's the *practical* benefit of splitting up ISASerialDevice into
UART-ISA adapter and the UART proper?

The bus sitting between the two would be trivial.  If we do that
everywhere, we'll end up with many different, trivial buses.

 IIRC I tried also that approach when I worked on this patch set but
 there were some problems. Maybe with header file conflicts, or
 qemu_irq was not available to CPU code.


 Okay, I'll queue it up for a future day.

 Because not all devices on the sysbus can be hot added so if you made the
 bus hotpluggable, it would basically defeat the point of even marking a bus
 as not supporting hot plug.

 IOW, the whole bus is either hot pluggable or not.  You cannot just say that
 device X can be hotplugged but nothing else.
  
 Perhaps the hotplugging system in QEMU needs some rethinking instead.
 Many real devices are not hot pluggable.


 That's probably fair.  I don't think hot plugging should exist at the
 qdev level.  Hot plugging is a very bus specific concept with very bus
 specific restrictions.  For instance, with PCI, you can only plug at
 slot granularities whereas today, we don't really model multi-function
 devices as anything more than a set of unrelated devices.  So there's
 really no way you could conceptually hot plug a multi-function virtio
 adapter although you can pretty trivially create one statically.

I think it's fair to say that qdev doesn't currently get hot-plugging
right.

 I think the options are to allow non-bus devices (like the APIC) or make
 the
 APIC a special case that's part of the CPU emulation.

  
 No. There could also be a new hotpluggable bus type, CPUBus, one
 instance between each CPU and APIC. Or SysBusWithHotPlug. But I don't
 see how that would be different from SysBus.


 Neither approach maps well to real hardware.  An x86 CPU cannot exist
 without a local APIC and a local APIC cannot exist without an x86 CPU.  The
 two are fundamentally tied together.

That's a pretty convincing argument for why a LAPIC should not be
separated from its CPU in qdev.  It should be part of the CPU qdev, or
maybe a child of it.

 What about 486? Or 82489?


 Don't confuse the local APIC with the PIC or the I/O APIC.

 The local APIC has always existed in the CPU core.  There is also an
 I/O APIC which exists outside of the CPU core.  The local APIC was
 introduced with SMP support.

 The PIC and IO APIC totally make sense to be modelled as qdev.

   It's like modelling a TLB as a
 separate device.
  
 That has surely happened in ancient times.


 Yes, but the programming model was different.

 Look at the PIC compared to the lapic.  The PIC is programmed via pio
 at a fixed location.  There is only one PIC and it interacts with the
 system just like all other devices.  IOW, there is no reference to
 CPUState.

 When you look at the local APIC (apic.c) however, you see that it's
 the only device in the tree that actually interacts with a CPUState.
 The notion of cpu_get_current_apic() is a good example of the tricks
 needed to make this work.

 The local APIC is a 

Re: [Qemu-devel] [PATCH] qdev: Reset hotplugged devices

[Anthony Liguori]

On 08/20/2010 11:14 AM, Markus Armbruster wrote:

The real problem is how we do reset.  We shouldn't register a reset
handler for every qdev device but rather register a single reset
handler that walks the device tree and calls reset on every reachable
device.

Then we can always call reset in init() and there's no need to have a
dev-hotplugged check.  The qdev device tree reset handler should not
be registered until *after* we call qemu_system_reset() after creating
the device model which will ensure that we don't do a double reset.
 

Fine with me.

But we need to merge something short term (pre 0.13) to fix hot plug of
e1000 et al.  Use Alex's patch as such a stop-gap?
   


No, we're accumulating crud in base qdev at an alarming rate.  It's 
important to fix these things now before it gets prohibitively hard to 
take care of.


Can you and Alex review/try the following patch?  It seems to work for 
me although I'm not sure how to trigger the original bug.


Regards,

Anthony Liguori

From df719f1cc6ae2cd430e1cc47896a13d25af81e67 Mon Sep 17 00:00:00 2001
From: Anthony Liguori aligu...@us.ibm.com
Date: Fri, 20 Aug 2010 13:06:22 -0500
Subject: [PATCH] qdev: fix reset with hotplug

Devices expect to be reset after being initialized.  Today, we achieve this by
registering a reset handler in each qdev device.  We then rely on this reset
handler getting called after device init but before CPU execution runs.

Since hot plug results in a device being initialized outside of the normal
system reset, things go badly today.

This patch changes the reset handling so that qdev has no knowledge of the
global system reset.  Instead, qdev devices are reset after initialization and
then a new bus level function is introduced that allows all devices on the bus
to be reset using a depth first transversal.

We still need to do a system_reset before CPU init to preserve behavior of
non-qdev devices so we make sure to register the qdev-based reset handler after
that reset.

N.B. we have to expose the implicit system bus because we have various hacks
that result in an implicit system bus existing.  Instead, we ought to have an
explicitly created system bus that we can trigger reset from.  That's a topic
for a future patch though.

Signed-off-by: Anthony Liguori aligu...@us.ibm.com

diff --git a/hw/qdev.c b/hw/qdev.c
index e99c73f..dfd91d7 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -256,13 +256,6 @@ DeviceState *qdev_device_add(QemuOpts *opts)
 return qdev;
 }
 
-static void qdev_reset(void *opaque)
-{
-DeviceState *dev = opaque;
-if (dev-info-reset)
-dev-info-reset(dev);
-}
-
 /* Initialize a device.  Device properties should be set before calling
this function.  IRQs and MMIO regions should be connected/mapped after
calling this function.
@@ -278,13 +271,15 @@ int qdev_init(DeviceState *dev)
 qdev_free(dev);
 return rc;
 }
-qemu_register_reset(qdev_reset, dev);
 if (dev-info-vmsd) {
 vmstate_register_with_alias_id(dev, -1, dev-info-vmsd, dev,
dev-instance_id_alias,
dev-alias_required_for_version);
 }
 dev-state = DEV_STATE_INITIALIZED;
+if (dev-info-reset) {
+dev-info-reset(dev);
+}
 return 0;
 }
 
@@ -307,6 +302,25 @@ int qdev_unplug(DeviceState *dev)
 return dev-info-unplug(dev);
 }
 
+static int qdev_reset_one(DeviceState *dev, void *opaque)
+{
+if (dev-info-reset) {
+dev-info-reset(dev);
+}
+
+return 1;
+}
+
+BusState *sysbus_get_default(void)
+{
+return main_system_bus;
+}
+
+void qbus_reset_all(BusState *bus)
+{
+qbus_walk_children(bus, qdev_reset_one, NULL);
+}
+
 /* can be used as -unplug() callback for the simple cases */
 int qdev_simple_unplug_cb(DeviceState *dev)
 {
@@ -350,7 +364,6 @@ void qdev_free(DeviceState *dev)
 if (dev-opts)
 qemu_opts_del(dev-opts);
 }
-qemu_unregister_reset(qdev_reset, dev);
 QLIST_REMOVE(dev, sibling);
 for (prop = dev-info-props; prop  prop-name; prop++) {
 if (prop-info-free) {
@@ -448,6 +461,27 @@ BusState *qdev_get_child_bus(DeviceState *dev, const char *name)
 return NULL;
 }
 
+int qbus_walk_children(BusState *bus, qdev_walkerfn *walker, void *opaque)
+{
+DeviceState *dev;
+
+QLIST_FOREACH(dev, bus-children, sibling) {
+BusState *child;
+
+if (!walker(dev, opaque)) {
+return 0;
+}
+
+QLIST_FOREACH(child, dev-child_bus, sibling) {
+if (!qbus_walk_children(child, walker, opaque)) {
+return 0;
+}
+}
+}
+
+return 1;
+}
+
 static BusState *qbus_find_recursive(BusState *bus, const char *name,
  const BusInfo *info)
 {
diff --git a/hw/qdev.h b/hw/qdev.h
index 678f8b7..1e5f983 100644
--- a/hw/qdev.h
+++ b/hw/qdev.h
@@ -174,13 +174,21 @@ BusState *qdev_get_parent_bus(DeviceState *dev);
 
 /*** 

Re: [Qemu-devel] [Bug 618533] Re: OpenSolaris guest fails to see the Solaris partitions of a physical disk in qemu-kvm-9999 (GIT)

[Blue Swirl]

On Fri, Aug 20, 2010 at 5:15 AM, devsk 618...@bugs.launchpad.net wrote:
 What's this bugdb for then? I now have to subscribe to a list, just to
 send the patch?

It's probably there to report bugs. But it's much easier to review
submitted code when it's sent to the list. I don't think you have to
be a subscriber.

Re: [Qemu-devel] [PATCH v2 0/7] APIC/IOAPIC cleanup

[Anthony Liguori]

On 08/20/2010 12:01 PM, Markus Armbruster wrote:

Anthony Liguorianth...@codemonkey.ws  writes:

   

On 08/19/2010 04:21 PM, Blue Swirl wrote:
 

Should CPUs appear in the QEMU device tree?

 

They have several properties that should be user visible.

   

Sure, but that's an argument for having some of the qdev features
(like variant properties) be consumable outside of qdev.
 

While that might be useful, I don't quite see what makes CPUs so special
that they need to be kept out of qdev.  Could be just my ignorance, of
course.
   


CPUs have special relationships with things like memory in QEMU.  You 
can argue that a device is anything with pins and that CPUs are just 
like any other chip.  But do we really want to model memory chipsets, a 
north and south bridge, and long with cache hierarchies?


It's the trade off between a functional simulator and a cycle accurate 
simulator.



The only way to do this right now is having a bus with a single
device.  I've been working on the serial device, and what this
requires is having an ISASerialDevice which is-a ISADevice.  The
ISASerialDevice has-a
SerialBus and the SerialBus contain a single SerialDevice which is-a
DeviceState.
 

It needs to be a SerialBusDevice, not just a DeviceState, actually.
   


It doesn't need to be actually.  Like it or not, we're still upcast 
from DeviceState so there's no practical reason to have a 
SerialBusDevice unless you're wrapping an interface behind function 
pointers.  But if you're only ever going to have one SerialDevice, 
what's the point?



But the ISASerialDevice has to assume that the SerialBus contains only
a single child because it needs to connect the GPIO out from the
SerialDevice to the ISA irq that's assigned.

It would be a whole lot simpler to break the all devices sit on
busses assumption that we have today and simply have the
ISASerialDevice has-a
SerialDevice with no additional layers of bus indirection.
 

What's the *practical* benefit of splitting up ISASerialDevice into
UART-ISA adapter and the UART proper?

The bus sitting between the two would be trivial.  If we do that
everywhere, we'll end up with many different, trivial buses.
   


If we wanted to add per-device locking based on putting a lock in 
DeviceState that was acquired and released whenever you executed a PIO, 
how would you do that today?


You would convert cpu_register_ioport_* to take a DeviceState in 
serial_init_core.  Sure, you could add a layer of indirection in 
ISASerialDevice, but what about timers?  We would want to implement 
device based timers to do the same thing but again, when we register the 
timers we don't have a DeviceState.


All device callbacks should be based on DeviceState * pointers which 
means if we want to share device code between multiple interfaces (be it 
ISA, PCI, or a SysBus device), we need to have a bus in between.



qdev level.  Hot plugging is a very bus specific concept with very bus
specific restrictions.  For instance, with PCI, you can only plug at
slot granularities whereas today, we don't really model multi-function
devices as anything more than a set of unrelated devices.  So there's
really no way you could conceptually hot plug a multi-function virtio
adapter although you can pretty trivially create one statically.
 

I think it's fair to say that qdev doesn't currently get hot-plugging
right.
   


I think we can fix it pretty reasonably though.  I think we can get 
pretty far by adding an interface whereas when creating a device, 
qdev_create calls into the parent Bus to plug it in which gives the 
parent bus an opportunity to reject the creation.


We need to indicate to the devices when they have been realized.  
Devices have (at least) three explicit states, constructing, 
initialized, and realized.  Realized is the point where it can expect 
I/O operations from the guest.  Each bus can then decide when it is 
willing to accept new devices and whether the devices can be hotplugged 
meaningfully.


For instance, sysbus would reject any devices added in the realized 
state whereas the PCI bus would accept devices in either the initialized 
state or the realized state but in the realized state, it would trigger 
a hotplug notification to the guest.  If the PCI address of the device 
didn't make sense (for instance, it was a function on a multi-function 
device), it would be rejected.



What about 486? Or 82489?

   

Don't confuse the local APIC with the PIC or the I/O APIC.

The local APIC has always existed in the CPU core.  There is also an
I/O APIC which exists outside of the CPU core.  The local APIC was
introduced with SMP support.

The PIC and IO APIC totally make sense to be modelled as qdev.

 

   It's like modelling a TLB as a
separate device.

 

That has surely happened in ancient times.

   

Yes, but the programming model was different.

Look at the PIC compared to the lapic.  The PIC is programmed via pio
at a 

Re: [Qemu-devel] [PATCH 0/5] CODING_STYLE amendments

[Blue Swirl]

On Fri, Aug 20, 2010 at 1:47 PM, Markus Armbruster arm...@redhat.com wrote:
 Anthony Liguori anth...@codemonkey.ws writes:

 On 08/17/2010 03:04 AM, Jes Sorensen wrote:
 On 08/13/10 20:02, Blue Swirl wrote:

 On Fri, Aug 13, 2010 at 3:22 PM, Miguel Di Ciurcio Filho
 miguel.fi...@gmail.com  wrote:

 The existing code that I have touched don't follow the current coding
 style guidance, much less all the new recommendations being suggested.

 Although, I do believe that this situation needs to change. If we
 agree in a coding style, I would volunteer to be a some kind of
 observer to fix and alert people about coding styles mistakes.

 I fully agree on the need of change and support your excellent idea.
 There are other ways to solve the problem, but I believe we need more
 order than more chaos. Perhaps we the QEMU developers should appoint
 you the Guardian of the CODING_STYLE, and add a rule that no patch
 shall be committed without your CS-Acked-by line?

 I don't think this would ever work, it is begging for trouble relying on
 one person to review all patches for this.

 While I agree coding style is good since it enforces consistency, there
 are plenty problems with the old rules

 To be perfectly honest, we have enough hard problems to solve in QEMU.
 We're spending a lot more time on coding style than we probably need
 to :-)

 In my not so humble opinion, that's because the current CODING_STYLE is
 idiosyncratic, widely disliked (follows from idiosyncratic pretty much
 inevitably), widely violated by existing code, and only haphazardly
 enforced for new code.

I think Coccinelle could help us here, it can check for some of the
CODING_STYLE issues. We only need to include it to our build system
and add git hooks if possible. It can also perform mechanical
conversions (if desired).

 I'd support switching to Linux kernel style.  Then we can point people
 complaining about it to Linux (good luck getting it changed there), use
 Linux's tools to check for compliance (beats building our own), and move
 on to more productive issues.

Not again:
http://lists.nongnu.org/archive/html/qemu-devel/2009-12/msg00484.html

Re: [Qemu-devel] [PATCH] multiboot: Prevent loading of x86_64 images

[Rene Rebe]

Hi,

On Aug 19, 2010, at 2:49 PM, Adam Lackorzynski wrote:

 
 On Thu Aug 19, 2010 at 14:34:10 +0200, Alexander Graf wrote:
 
 On 19.08.2010, at 14:32, Adam Lackorzynski wrote:
 
 
 On Thu Aug 19, 2010 at 13:40:54 +0200, Alexander Graf wrote:
 
 On 19.08.2010, at 13:36, Adam Lackorzynski wrote:
 
 
 On Thu Aug 19, 2010 at 13:27:32 +0200, Alexander Graf wrote:
 
 On 19.08.2010, at 13:24, Adam Lackorzynski wrote:
 
 A via -kernel supplied x86_64 ELF image is being started in 32bit mode.
 Detect and exit if a 64bit image has been supplied.
 
 According to the multiboot spec, this is the expected behavior, no? At 
 least Xen does it that way...
 
 Yes, but then the supplied ELF-image should say it's a 32bit one and
 switch to 64bit mode itself. That's at least how we do load a 64bit
 kernel.
 
 Hrm - maybe you're right:
 
 busu:~ # readelf -a /boot/xen
 ELF Header:
 Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
 Class: ELF32
 
 What does the spec say here? What does grub do?
 
 Grub starts the (multiboot-)OS in 32bit mode. Starting directly in 64bit
 mode would require to setup page-tables etc. which is not done.
 The Spec doesn't mention 64bit OS at all, and says that 32bit OSs are
 fine (An OS image may be an ordinary 32-bit executable file in the
 standard format for that particular operating system, except that it may
 be linked at a non-default load address to avoid loading on top of the
 ...);
 
 I think we should do the same grub does here. If grub loads 64-bit elf
 binaries and runs them in 32-bit mode, we should too. If it refuses to
 load them, we should too.
 
 grub1:
 
 grub kernel (nd)/tftpboot/adam/bootstrap.elf 
  
 
 Error 13: Invalid or unsupported executable format
 
 grub
 
 
 grub2 loads it but then it crashes and reboots. Looks like a bug to me.

I once added some x86_64 patch to our grub at T2. I forgot for what, L4, 
Luvally? At that time it worked, ...

http://svn.exactcode.de/t2/trunk/package/x86/grub/grub-0.97-x86_64.patch

René

-- 
  René Rebe, ExactCODE GmbH, Jaegerstr. 67, DE-10117 Berlin
  http://exactcode.com | http://t2-project.org | http://rene.rebe.de

Re: [Qemu-devel] [PATCH 4/4] QMP: Update README file

[Luiz Capitulino]

On Fri, 20 Aug 2010 18:04:57 +0200
Markus Armbruster arm...@redhat.com wrote:

 Luiz Capitulino lcapitul...@redhat.com writes:
 
  A number of changes I prefer to do in one shot:
 
  - Fix example
  - Small clarifications
  - Add multiple monitors example
  - Add 'Development Process' section
 
  Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
  ---
   QMP/README |   71 
  ---
   1 files changed, 48 insertions(+), 23 deletions(-)
 
  diff --git a/QMP/README b/QMP/README
  index 35a80c7..b23f186 100644
  --- a/QMP/README
  +++ b/QMP/README
  @@ -7,60 +7,85 @@ Introduction
   The QEMU Monitor Protocol (QMP) allows applications to communicate with
   QEMU's Monitor.
   
  -QMP is JSON[1] based and has the following features:
  +QMP is JSON[1] based and currently has the following features:
   
   - Lightweight, text-based, easy to parse data format
  -- Asynchronous events support 
  -- Stability
  +- Asynchronous messages support (ie. events)
  +- Capabilities Negotiation
   
  -For more information, please, refer to the following files:
  +For detailed information on QMP's usage, please, refer to the following 
  files:
   
   o qmp-spec.txt  QEMU Monitor Protocol current specification
  -o qmp-commands.txt  QMP supported commands
  +o qmp-commands.txt  QMP supported commands (auto-generated at build-time)
   o qmp-events.txtList of available asynchronous events
   
   There are also two simple Python scripts available:
   
  -o qmp-shell   A shell
  -o vm-info Show some information about the Virtual Machine
  +o qmp-shell  A shell
  +o vm-infoShow some information about the Virtual Machine
  +
  +IMPORTANT: It's strongly recommended to read the 'Stability Considerations'
  +section in the qmp-commands.txt file before making any serious use of QMP.
  +
   
   [1] http://www.json.org
   
   Usage
   -
   
  -To enable QMP, QEMU has to be started in control mode. There are
  -two ways of doing this, the simplest one is using the the '-qmp'
  -command-line option.
  +To enable QMP, you need a QEMU monitor instance in control mode. There 
  are
  +two ways of doing this.
  +
  +The simplest one is using the '-qmp' command-line option. The following
  +example makes QMP available on localhost port :
   
  -For example:
  +  $ qemu [...] -qmp tcp:localhost:,server
   
  -$ qemu [...] -qmp tcp:localhost:,server
  +However, in order to have more complex combinations, like multiple 
  monitors,
  +the '-mon' command-line option should be used along with the '-chardev' 
  one.
  +For instance, the following example creates one user monitor on stdio and 
  one
  +QMP monitor on localhost port .
   
  -Will start QEMU in control mode, waiting for a client TCP connection
  -on localhost port .
  +   $ qemu [...] -chardev stdio,id=mon0 -mon chardev=mon0,mode=readline \
  +-chardev socket,id=mon1,host=localhost,port=,server \
  +-mon chardev=mon1,mode=control
   
  -It is also possible to use the '-mon' command-line option to have
  -more complex combinations. Please, refer to the QEMU's manpage for
  -more information.
  +Please, refer to QEMU's manpage for more information.
   
   Simple Testing
   --
   
  -To manually test QMP one can connect with telnet and issue commands:
  +To manually test QMP one can connect with telnet and issue commands by 
  hand:
   
   $ telnet localhost 
   Trying 127.0.0.1...
   Connected to localhost.
   Escape character is '^]'.
  -{QMP: {version: {qemu: 0.12.50, package: }, capabilities: 
  []}}
  +{QMP: {version: {qemu: {micro: 50, minor: 13, major: 0}, 
  package: }, capabilities: []}}
 
 Doesn't this belong into 2/4?
 
   { execute: qmp_capabilities }
   {return: {}}
   { execute: query-version }
  -{return: {qemu: 0.12.50, package: }}
  +{return: {qemu: {micro: 50, minor: 13, major: 0}, package: }}
 
 This too.
 
 Doubt it's worth a respin, though.
 
  +
  +Development Process
  +---
  +
  +When changing QMP's interface (by adding new commands, events or modifying
  +existing ones) it's mandatory to update the relevant documentation, which 
  is
  +one (or more) of the files listed in the 'Introduction' section*.
  +
  +Also, it's strongly recommended to send the documentation patch first, 
  before
  +doing any code change. This is so because:
  +
  +  1. Avoids the code dictating the interface
  +
  +  2. It's very likely that the interface will change during review, 
  updating
  + the code at the same time might be a big waste of time
 
 Very likely sounds a bit discouraging, doesn't it?  What about
 
 2. Review can improve your interface.  Letting that happen before
 you implement it can save you work.

Yeah, looks better. Will resend.

Re: [Qemu-devel] [PATCH v2 0/7] APIC/IOAPIC cleanup

[Blue Swirl]

On Thu, Aug 19, 2010 at 9:51 PM, Anthony Liguori anth...@codemonkey.ws wrote:
 On 08/19/2010 04:21 PM, Blue Swirl wrote:

 Should CPUs appear in the QEMU device tree?


 They have several properties that should be user visible.


 Sure, but that's an argument for having some of the qdev features (like
 variant properties) be consumable outside of qdev.

Or rather, separate qdev from SysBus. I don't think either makes much sense.

 requirement to sit on a bus.  A UART16650A does not sit on bus.  It sits
 on
 a card and is wired to the ISA bus or is sometimes wired directly to pins
 on
 a CPU on a SoC.


 Or all buses should be unified, so all devices could be wired into any
 board.


 But that defeats the notion of having bus level interfaces.  You really want
 the virtio PCI layer to only use PCI functions and specifically to interact
 with PCI concepts that don't exist in other busses (like IO regions and
 config space).  However, you also want the ability to interact with a virtio
 device through a well defined interface that isn't PCI specific.

True, but if a device uses dedicated bus interfaces, it can't be used
on other buses. It might be possible to construct the devices so that
most of the code is bus agnostic and only a shim interfaces with the
bus of the day, which should be close to what you proposed in the
earlier serial example.

One way to model pure devices could be something like chip select
line, address bus (possibly truncated) and data bus (also possibly
narrowed).

Any way, I think the current model is pretty much fine as is.

 The only way to do this right now is having a bus with a single device.
  I've been working on the serial device, and what this requires is having an
 ISASerialDevice which is-a ISADevice.  The ISASerialDevice has-a SerialBus
 and the SerialBus contain a single SerialDevice which is-a DeviceState.

 But the ISASerialDevice has to assume that the SerialBus contains only a
 single child because it needs to connect the GPIO out from the SerialDevice
 to the ISA irq that's assigned.

 It would be a whole lot simpler to break the all devices sit on busses
 assumption that we have today and simply have the ISASerialDevice has-a
 SerialDevice with no additional layers of bus indirection.

 IIRC I tried also that approach when I worked on this patch set but
 there were some problems. Maybe with header file conflicts, or
 qemu_irq was not available to CPU code.


 Okay, I'll queue it up for a future day.

 Because not all devices on the sysbus can be hot added so if you made the
 bus hotpluggable, it would basically defeat the point of even marking a
 bus
 as not supporting hot plug.

 IOW, the whole bus is either hot pluggable or not.  You cannot just say
 that
 device X can be hotplugged but nothing else.


 Perhaps the hotplugging system in QEMU needs some rethinking instead.
 Many real devices are not hot pluggable.


 That's probably fair.  I don't think hot plugging should exist at the qdev
 level.  Hot plugging is a very bus specific concept with very bus specific
 restrictions.  For instance, with PCI, you can only plug at slot
 granularities whereas today, we don't really model multi-function devices as
 anything more than a set of unrelated devices.  So there's really no way you
 could conceptually hot plug a multi-function virtio adapter although you can
 pretty trivially create one statically.

Maybe PCI could introduce an indirection: cards. They could contain
any number of qdev devices.

 I think the options are to allow non-bus devices (like the APIC) or
 make
 the
 APIC a special case that's part of the CPU emulation.



 No. There could also be a new hotpluggable bus type, CPUBus, one
 instance between each CPU and APIC. Or SysBusWithHotPlug. But I don't
 see how that would be different from SysBus.



 Neither approach maps well to real hardware.  An x86 CPU cannot exist
 without a local APIC and a local APIC cannot exist without an x86 CPU.
  The
 two are fundamentally tied together.


 What about 486? Or 82489?


 Don't confuse the local APIC with the PIC or the I/O APIC.

 The local APIC has always existed in the CPU core.  There is also an I/O
 APIC which exists outside of the CPU core.  The local APIC was introduced
 with SMP support.

No, 82489 was an external local APIC for 486DX. See for example Intel
Multiprocessor Specification, page 3-5.

 The PIC and IO APIC totally make sense to be modelled as qdev.

  It's like modelling a TLB as a
 separate device.


 That has surely happened in ancient times.


 Yes, but the programming model was different.

 Look at the PIC compared to the lapic.  The PIC is programmed via pio at a
 fixed location.  There is only one PIC and it interacts with the system just
 like all other devices.  IOW, there is no reference to CPUState.

 When you look at the local APIC (apic.c) however, you see that it's the only
 device in the tree that actually interacts with a CPUState.  The notion of
 cpu_get_current_apic() is a 

[Qemu-devel] [PATCH 2/4] QMP/monitor: update do_info_version() to output broken down version string

[Luiz Capitulino]

From: Miguel Di Ciurcio Filho miguel.fi...@gmail.com

This code was originally developed by Daniel P. Berrange berra...@redhat.com

Signed-off-by: Miguel Di Ciurcio Filho miguel.fi...@gmail.com
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
---
 monitor.c |   23 +++
 1 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/monitor.c b/monitor.c
index c313d5a..e27f8d8 100644
--- a/monitor.c
+++ b/monitor.c
@@ -669,17 +669,32 @@ help:
 static void do_info_version_print(Monitor *mon, const QObject *data)
 {
 QDict *qdict;
+QDict *qemu;
 
 qdict = qobject_to_qdict(data);
+qemu = qdict_get_qdict(qdict, qemu);
 
-monitor_printf(mon, %s%s\n, qdict_get_str(qdict, qemu),
-  qdict_get_str(qdict, package));
+monitor_printf(mon, % PRId64 .% PRId64 .% PRId64 %s\n,
+  qdict_get_int(qemu, major),
+  qdict_get_int(qemu, minor),
+  qdict_get_int(qemu, micro),
+  qdict_get_str(qdict, package));
 }
 
 static void do_info_version(Monitor *mon, QObject **ret_data)
 {
-*ret_data = qobject_from_jsonf({ 'qemu': %s, 'package': %s },
-   QEMU_VERSION, QEMU_PKGVERSION);
+const char *version = QEMU_VERSION;
+int major = 0, minor = 0, micro = 0;
+char *tmp;
+
+major = strtol(version, tmp, 10);
+tmp++;
+minor = strtol(tmp, tmp, 10);
+tmp++;
+micro = strtol(tmp, tmp, 10);
+
+*ret_data = qobject_from_jsonf({ 'qemu': { 'major': %d, 'minor': %d, \
+'micro': %d }, 'package': %s }, major, minor, micro, QEMU_PKGVERSION);
 }
 
 static void do_info_name_print(Monitor *mon, const QObject *data)
-- 
1.7.2.1.97.g3235b

[Qemu-devel] [PATCH 3/4] QMP doc: Add 'Stability Considerations' section

[Luiz Capitulino]

Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
---
 qemu-monitor.hx |   26 --
 1 files changed, 24 insertions(+), 2 deletions(-)

diff --git a/qemu-monitor.hx b/qemu-monitor.hx
index 9c27b31..5c1da33 100644
--- a/qemu-monitor.hx
+++ b/qemu-monitor.hx
@@ -35,7 +35,29 @@ information on the Server command and response formats.
 
 NOTE: This document is temporary and will be replaced soon.
 
-1. Regular Commands
+1. Stability Considerations
+===
+
+The current QMP command set (described in this file) may be useful for a
+number of use cases, however it's limited and several commands have bad
+defined semantics, specially with regard to command completion.
+
+These problems are going to be solved incrementally in the next QEMU releases
+and we're going to establish a deprecation policy for badly defined commands.
+
+If you're planning to adopt QMP, please observe the following:
+
+1. The deprecation policy will take efect and be documented soon, please
+   check the documentation of each used command as soon as a new release of
+   QEMU is available
+
+2. DO NOT rely on anything which is not explicit documented
+
+3. Errors, in special, are not documented. Applications should NOT check
+   for specific errors classes or data (it's strongly recommended to only
+   check for the error key)
+
+2. Regular Commands
 ===
 
 Server's responses in the examples below are always a success response, please
@@ -1592,7 +1614,7 @@ HXCOMM This is required for the QMP documentation layout.
 
 SQMP
 
-2. Query Commands
+3. Query Commands
 =
 
 EQMP
-- 
1.7.2.1.97.g3235b

[Qemu-devel] [PATCH 1/4] QMP: update 'query-version' documentation

[Luiz Capitulino]

From: Miguel Di Ciurcio Filho miguel.fi...@gmail.com

Update the documentation of 'query-version' to output the string version broken
down.

Signed-off-by: Miguel Di Ciurcio Filho miguel.fi...@gmail.com
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
---
 qemu-monitor.hx |   16 ++--
 1 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/qemu-monitor.hx b/qemu-monitor.hx
index 2af3de6..9c27b31 100644
--- a/qemu-monitor.hx
+++ b/qemu-monitor.hx
@@ -1623,13 +1623,25 @@ Show QEMU version.
 
 Return a json-object with the following information:
 
-- qemu: QEMU's version (json-string)
+- qemu: A json-object containing three integer values:
+- major: QEMU's major version (json-int)
+- minor: QEMU's minor version (json-int)
+- micro: QEMU's micro version (json-int)
 - package: package's version (json-string)
 
 Example:
 
 - { execute: query-version }
-- { return: { qemu: 0.11.50, package:  } }
+- {
+  return:{
+ qemu:{
+major:0,
+minor:11,
+micro:5
+ },
+ package:
+  }
+   }
 
 EQMP
 
-- 
1.7.2.1.97.g3235b

[Qemu-devel] [PATCH 4/4] QMP: Update README file

[Luiz Capitulino]

A number of changes I prefer to do in one shot:

- Fix example
- Small clarifications
- Add multiple monitors example
- Add 'Development Process' section

Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
---
 QMP/README |   71 ---
 1 files changed, 48 insertions(+), 23 deletions(-)

diff --git a/QMP/README b/QMP/README
index 35a80c7..948d445 100644
--- a/QMP/README
+++ b/QMP/README
@@ -7,60 +7,85 @@ Introduction
 The QEMU Monitor Protocol (QMP) allows applications to communicate with
 QEMU's Monitor.
 
-QMP is JSON[1] based and has the following features:
+QMP is JSON[1] based and currently has the following features:
 
 - Lightweight, text-based, easy to parse data format
-- Asynchronous events support 
-- Stability
+- Asynchronous messages support (ie. events)
+- Capabilities Negotiation
 
-For more information, please, refer to the following files:
+For detailed information on QMP's usage, please, refer to the following files:
 
 o qmp-spec.txt  QEMU Monitor Protocol current specification
-o qmp-commands.txt  QMP supported commands
+o qmp-commands.txt  QMP supported commands (auto-generated at build-time)
 o qmp-events.txtList of available asynchronous events
 
 There are also two simple Python scripts available:
 
-o qmp-shell   A shell
-o vm-info Show some information about the Virtual Machine
+o qmp-shell  A shell
+o vm-infoShow some information about the Virtual Machine
+
+IMPORTANT: It's strongly recommended to read the 'Stability Considerations'
+section in the qmp-commands.txt file before making any serious use of QMP.
+
 
 [1] http://www.json.org
 
 Usage
 -
 
-To enable QMP, QEMU has to be started in control mode. There are
-two ways of doing this, the simplest one is using the the '-qmp'
-command-line option.
+To enable QMP, you need a QEMU monitor instance in control mode. There are
+two ways of doing this.
+
+The simplest one is using the '-qmp' command-line option. The following
+example makes QMP available on localhost port :
 
-For example:
+  $ qemu [...] -qmp tcp:localhost:,server
 
-$ qemu [...] -qmp tcp:localhost:,server
+However, in order to have more complex combinations, like multiple monitors,
+the '-mon' command-line option should be used along with the '-chardev' one.
+For instance, the following example creates one user monitor on stdio and one
+QMP monitor on localhost port .
 
-Will start QEMU in control mode, waiting for a client TCP connection
-on localhost port .
+   $ qemu [...] -chardev stdio,id=mon0 -mon chardev=mon0,mode=readline \
+-chardev socket,id=mon1,host=localhost,port=,server \
+-mon chardev=mon1,mode=control
 
-It is also possible to use the '-mon' command-line option to have
-more complex combinations. Please, refer to the QEMU's manpage for
-more information.
+Please, refer to QEMU's manpage for more information.
 
 Simple Testing
 --
 
-To manually test QMP one can connect with telnet and issue commands:
+To manually test QMP one can connect with telnet and issue commands by hand:
 
 $ telnet localhost 
 Trying 127.0.0.1...
 Connected to localhost.
 Escape character is '^]'.
-{QMP: {version: {qemu: 0.12.50, package: }, capabilities: []}}
+{QMP: {version: {qemu: {micro: 50, minor: 13, major: 0}, 
package: }, capabilities: []}}
 { execute: qmp_capabilities }
 {return: {}}
 { execute: query-version }
-{return: {qemu: 0.12.50, package: }}
+{return: {qemu: {micro: 50, minor: 13, major: 0}, package: }}
+
+Development Process
+---
+
+When changing QMP's interface (by adding new commands, events or modifying
+existing ones) it's mandatory to update the relevant documentation, which is
+one (or more) of the files listed in the 'Introduction' section*.
+
+Also, it's strongly recommended to send the documentation patch first, before
+doing any code change. This is so because:
+
+  1. Avoids the code dictating the interface
+
+  2. Review can improve your interface.  Letting that happen before
+ you implement it can save you work.
+
+* The qmp-commands.txt file is generated from the qemu-monitor.hx one, which
+  is the file that should be edited.
 
-Contact

+Homepage
+
 
 http://www.linux-kvm.org/page/MonitorProtocol
-Luiz Fernando N. Capitulino lcapitul...@redhat.com
-- 
1.7.2.1.97.g3235b

[Qemu-devel] [master/0.13 v2 0/4]: QMP: Stability related fixes

[Luiz Capitulino]

In the KVM Forum we talked about making the current QMP's interface stable
and deprecating it as soon as the right one is available.

This series updates some QMP docs to reflect that and also has a small fix
for the greeting message which would harder to change later.

changelog
-

v1 - v2: Improve wording in README file

Thanks.

[Qemu-devel] target-sparc/TODO

[Artyom Tarasenko]

2010/8/19 Blue Swirl blauwir...@gmail.com:

 Is there a list of what is missing? You mentioned the pci bridges
 before. What else?
 Shall we maintain the TODO file for everything we find? Including
 things we may fix within a few days after finding?

 Actually, we have a TODO file, see under target-sparc. Thanks for
 reminding me. ;-)

I know that we have it. I asked you about a year ago whether the
things in it were up to date. ;-)
What I mean is that we should update it really every time we find or
fix missing things. For example my current list of sun4m
features/fixes which may or may not be implemented in the near or far
future:

- esp: improve Select with Attention / Select without Attention,
so that it's compatible with NetBSD 1.6-3.0.
- mxcc: implement missing registers so that SS-10/SS-20 OBPs would
work with the default CPU model
- le: improve for passing OBP loopback test. This would allow the
network boot (which is the default option for OBP when running under
qemu because NVRAM contents is invalid).
- nvram: add possibility to back it up with a file.
- add option rom file load for graphic card or for any SBus slot (the
second variant is preferable because it can be used to provide SS-20
OBP with fake or real dbri rom).
- slavio_timer: make it closer to the real HW than to specification.
NeXTStep OS relies on register contents after the mode change although
the documentation states it to be undefined.
- fix Solaris 2.2-2.5.1 boot hanging if the day of month is 20 (am
currently at it).

the list is unsorted. The option rom file point is already in the
TODO file but without reasoning.

I think one point in the current TODO is resolved:

- Interrupt routing does not match real HW

I think we are pretty good there at least for the single CPU machines.

-- 
Regards,
Artyom Tarasenko

solaris/sparc under qemu blog: http://tyom.blogspot.com/

Re: [Qemu-devel] Template for developing a Qe mu device with PCIe?and MSI-X

[Adnan Khaleel]

I'm not sure what the problem was but I had checked out the code on a windows 
machine and then copied it over to a linux box. That was causing problems 
somehow.

I've managed to compile qemu and seabios but vgabios is taking forever to 
compile. The problem seems to be bcc. I've tried a simple helloworld program 
and even that seems to be taking forever to compile. Not sure if there is 
something wrong with my bcc install.

AK
  _  

From: Isaku Yamahata [mailto:yamah...@valinux.co.jp]
To: Adnan Khaleel [mailto:ad...@khaleel.us]
Cc: qemu-devel@nongnu.org
Sent: Fri, 20 Aug 2010 00:22:03 -0500
Subject: Re: [Qemu-devel] Template for developing a Qemu device with PCIe?and 
MSI-X

On Thu, Aug 19, 2010 at 01:32:42PM -0500, Adnan Khaleel wrote:
   Isaku,
   
   I'm having some difficulties building the sources, I get the following 
message
   
   *akhal...@yar95 qemu-q35 $ ./configure --help
   : bad interpreter: No such file or directory
   
   And I get a similar error while compiling seabios as well.
  
   What shell are you using or am I missing something? I'm compiling from a
   typical bash shell and using gcc v4.4.0.
  
  I'm not sure. configure script isn't modified.
  Can you compile normal qemu?
  The first line of the script is #!/bin/sh. I suppose you have /bin/sh.
  
  
   In vgabios, there is a requirement for bcc. Is that borland C compiler?
  
  No. Most Linux destro has bcc package. Just you need to install it like
  yum install bcc or something.
  
  Thanks,
  
  
   
   Thanks
   
   Adnan
   
   ━
   From: Isaku Yamahata [mailto:yamah...@valinux.co.jp]
   To: Adnan Khaleel [mailto:ad...@khaleel.us]
   Cc: qemu-devel@nongnu.org
   Sent: Wed, 18 Aug 2010 22:19:04 -0500
   Subject: Re: [Qemu-devel] Template for developing a Qemu device with 
PCIe
   and MSI-X
   
   On Wed, Aug 18, 2010 at 02:10:10PM -0500, Adnan Khaleel wrote:
Hello Qemu developers,
   
I'm interested in developing a device model that plugs into Qemu that 
is
   based
on a PCIe interface and uses MSI-X. My goal is to ultimately attach a 
GPU
simulator to this PCIe interface and use the entire platfom (Qemu + 
GPU
simulator) for studying cpu, gpu interactions.
   
I'm not terribly familiar with the Qemu device model and I'm looking 
for
   some
assistance, perhaps a starting template for pcie and msi-x that would
   offer the
basic functionality that I could then build upon.
   
I have looked at the various devices that already modelled that are
   included
with Qemu (v0.12.5 at least) and I've noticed several a few pci 
devices,
   eg;
ne2k and cirrus-pci etc, however only one device truly seems to 
utilize
   both
the technologies that I'm interested in and that is the virtio-pci.c
   
I'm not sure what virtio-pci does so I'm not sure if that is a 
suitable
starting point for me.
   
Any help, suggestions etc would be extremely helpful and much
   appreciated.
   
   Qemu doesn't support pcie at the moment.
   Only partial patches have been merged, still more patches have to
   be merged for pcie to fully work. The following repo is available.
   
   git clone http://people.valinux.co.jp/~yamahata/qemu/q35/qemu
   git clone http://people.valinux.co.jp/~yamahata/qemu/q35/seabios
   git clone http://people.valinux.co.jp/~yamahata/qemu/q35/vgabios
   
   Note: patched seabios and vgabios are needed, you have to pass ACPI DSDT
   for q35.
   example:
   qemu-system-x86_64 -M pc_q35 -acpitable 
load_header,data=roms/seabios/src/
   q35-acpi-dsdt.aml
   
   This repo is for those who want to try/develop pcie support,
   not for upstream merge. So they include patches unsuitable for upstream.
   The repo includes pcie port switch emulator which utilize pcie and
   MSI(not MSI-X).
   
   The difference between PCI device and PCIe device is configuration
   space size.
   By setting PCIDeviceInfo::is_express = 1, you'll get 4K configuration
   space. Helper functions for pcie are found in qemu/hw/pcie.c
   For msi-x, see qemu/hw/msix.c.
   
   Thanks,
   --
   yamahata
   
  
  -- 
  yamahata

[Qemu-devel] Re: target-sparc/TODO

[Blue Swirl]

On Fri, Aug 20, 2010 at 7:59 PM, Artyom Tarasenko
atar4q...@googlemail.com wrote:
 2010/8/19 Blue Swirl blauwir...@gmail.com:

 Is there a list of what is missing? You mentioned the pci bridges
 before. What else?
 Shall we maintain the TODO file for everything we find? Including
 things we may fix within a few days after finding?

 Actually, we have a TODO file, see under target-sparc. Thanks for
 reminding me. ;-)

 I know that we have it. I asked you about a year ago whether the
 things in it were up to date. ;-)

Yes, but I had sort of forgotten.

 What I mean is that we should update it really every time we find or
 fix missing things. For example my current list of sun4m
 features/fixes which may or may not be implemented in the near or far
 future:

 - esp: improve Select with Attention / Select without Attention,
 so that it's compatible with NetBSD 1.6-3.0.

bug

 - mxcc: implement missing registers so that SS-10/SS-20 OBPs would
 work with the default CPU model

bug?

 - le: improve for passing OBP loopback test. This would allow the
 network boot (which is the default option for OBP when running under
 qemu because NVRAM contents is invalid).

bug or feature, I don't know

 - nvram: add possibility to back it up with a file.

feature

 - add option rom file load for graphic card or for any SBus slot (the
 second variant is preferable because it can be used to provide SS-20
 OBP with fake or real dbri rom).

feature

 - slavio_timer: make it closer to the real HW than to specification.
 NeXTStep OS relies on register contents after the mode change although
 the documentation states it to be undefined.

bug

 - fix Solaris 2.2-2.5.1 boot hanging if the day of month is 20 (am
 currently at it).

bug?


 the list is unsorted. The option rom file point is already in the
 TODO file but without reasoning.

I think small bugs could be reported to the bugzilla and only new
features (and maybe bugs that need a big fix) should be added to TODO.

 I think one point in the current TODO is resolved:

 - Interrupt routing does not match real HW

 I think we are pretty good there at least for the single CPU machines.

This was probably from the time that CPU timer interrupts were
delivered with the IRQ bit (0x80 in the master register) that Linux
used to clear the interrupt which was not correct.

Level 15 handling may still be incorrect and as you reported, IOMMU
probably is too trigger happy with NMI which may not even be the
correct IRQ. Likewise with unassigned_mem.

Re: [Qemu-devel] [PATCH 0/5] CODING_STYLE amendments

[Blue Swirl]

On Fri, Aug 20, 2010 at 6:44 PM, Blue Swirl blauwir...@gmail.com wrote:
 On Fri, Aug 20, 2010 at 1:47 PM, Markus Armbruster arm...@redhat.com wrote:
 Anthony Liguori anth...@codemonkey.ws writes:

 On 08/17/2010 03:04 AM, Jes Sorensen wrote:
 On 08/13/10 20:02, Blue Swirl wrote:

 On Fri, Aug 13, 2010 at 3:22 PM, Miguel Di Ciurcio Filho
 miguel.fi...@gmail.com  wrote:

 The existing code that I have touched don't follow the current coding
 style guidance, much less all the new recommendations being suggested.

 Although, I do believe that this situation needs to change. If we
 agree in a coding style, I would volunteer to be a some kind of
 observer to fix and alert people about coding styles mistakes.

 I fully agree on the need of change and support your excellent idea.
 There are other ways to solve the problem, but I believe we need more
 order than more chaos. Perhaps we the QEMU developers should appoint
 you the Guardian of the CODING_STYLE, and add a rule that no patch
 shall be committed without your CS-Acked-by line?

 I don't think this would ever work, it is begging for trouble relying on
 one person to review all patches for this.

 While I agree coding style is good since it enforces consistency, there
 are plenty problems with the old rules

 To be perfectly honest, we have enough hard problems to solve in QEMU.
 We're spending a lot more time on coding style than we probably need
 to :-)

 In my not so humble opinion, that's because the current CODING_STYLE is
 idiosyncratic, widely disliked (follows from idiosyncratic pretty much
 inevitably), widely violated by existing code, and only haphazardly
 enforced for new code.

 I think Coccinelle could help us here, it can check for some of the
 CODING_STYLE issues. We only need to include it to our build system
 and add git hooks if possible. It can also perform mechanical
 conversions (if desired).

This Coccinelle script seems to do the job:
@curly_if@
position p;
@@

i...@p (...) { ... }

@simple_if@
position p != curly_if.p;
statement S;
expression E;
@@

- i...@p (E) S
+ if (E) {
+S
+ }

@curly_for@
position q;
@@

f...@q (...;...;...) { ... }

@simple_for@
position q != curly_for.q;
statement S;
expression E1, E2, E3;
@@

- f...@q (E1; E2; E3) S
+ for (E1; E2; E3) {
+S
+ }

@curly_while@
position r;
@@

wh...@r (...) { ... }

@simple_while@
position r != curly_while.r;
statement S;
expression E;
@@

- wh...@r (E) S
+ while (E) {
+S
+ }

There are some formatting issues though, I get changes like:
-for (i=0; i5; i++)
+for(i = 0;i  5;i++) {

Reformatting the expressions with more spaces is nice, but removing
the spaces between 'for' and '(' and especially after ';' is not.

[Qemu-devel] [PATCH] VGA: Don't register deprecated VBE range

[Alex Williamson]

Old versions of the BOCHs VGA BIOS (cira 2003) made use of VBE
registers at 0xff80/81.  In VBE API version 0xb0c2 these were
moved to 0x1ce/cf.  Unfortunately, QEMU still registers handlers
for the old range.  If a guest attempts to assign an I/O device
overlapping this region, QEMU exits with a hw_error.  Windows
guests seem to like to assign I/O devices to the high end of
the address space, so it's pretty easy to hot add an rtl8139
to a Win2k8 guest and trigger the bug.  I can't find any reason
to register these handlers, so let's remove the cruft.

Signed-off-by: Alex Williamson alex.william...@redhat.com
---

 hw/vga.c |7 ---
 1 files changed, 0 insertions(+), 7 deletions(-)

diff --git a/hw/vga.c b/hw/vga.c
index b5c7ee7..966185e 100644
--- a/hw/vga.c
+++ b/hw/vga.c
@@ -2313,13 +2313,6 @@ void vga_init(VGACommonState *s)
 
 register_ioport_write(0x1ce, 1, 2, vbe_ioport_write_index, s);
 register_ioport_write(0x1cf, 1, 2, vbe_ioport_write_data, s);
-
-/* old Bochs IO ports */
-register_ioport_read(0xff80, 1, 2, vbe_ioport_read_index, s);
-register_ioport_read(0xff81, 1, 2, vbe_ioport_read_data, s);
-
-register_ioport_write(0xff80, 1, 2, vbe_ioport_write_index, s);
-register_ioport_write(0xff81, 1, 2, vbe_ioport_write_data, s);
 #else
 register_ioport_read(0x1ce, 1, 2, vbe_ioport_read_index, s);
 register_ioport_read(0x1d0, 1, 2, vbe_ioport_read_data, s);

Re: [Qemu-devel] [PATCH] qdev: Reset hotplugged devices

[Alex Williamson]

On Fri, 2010-08-20 at 13:12 -0500, Anthony Liguori wrote:
 On 08/20/2010 11:14 AM, Markus Armbruster wrote:
  The real problem is how we do reset.  We shouldn't register a reset
  handler for every qdev device but rather register a single reset
  handler that walks the device tree and calls reset on every reachable
  device.
 
  Then we can always call reset in init() and there's no need to have a
  dev-hotplugged check.  The qdev device tree reset handler should not
  be registered until *after* we call qemu_system_reset() after creating
  the device model which will ensure that we don't do a double reset.
   
  Fine with me.
 
  But we need to merge something short term (pre 0.13) to fix hot plug of
  e1000 et al.  Use Alex's patch as such a stop-gap?
 
 
 No, we're accumulating crud in base qdev at an alarming rate.  It's 
 important to fix these things now before it gets prohibitively hard to 
 take care of.
 
 Can you and Alex review/try the following patch?  It seems to work for 
 me although I'm not sure how to trigger the original bug.

Yep, that works.  The test is simply to hot add an e1000, much of the
register state is setup in the reset function so the guest won't be able
to make use of the device unless reset is called somewhere along the
way.

Acked-by: Alex Williamson alex.william...@redhat.com

Re: [Qemu-devel] Template for developing a Qe mu device with PCIe?and MSI-X

[Adnan Khaleel]

After messing around with bcc, as86 and ld86 I finally got the vgabios to 
compile.

Everything works as it should I'm guessing. I've attached the output from lspci 
from the guest. I'll spend sometime looking at the device models and see how I 
can implement a model of what I'm interested in.

Is the overall architecture of any qemu device still similar to how a typical 
qemu pci device is or is there anything I should be aware of?

Thanks again Isaku.

AK
  _  

From: Isaku Yamahata [mailto:yamah...@valinux.co.jp]
To: Adnan Khaleel [mailto:ad...@khaleel.us]
Cc: qemu-devel@nongnu.org
Sent: Fri, 20 Aug 2010 00:22:03 -0500
Subject: Re: [Qemu-devel] Template for developing a Qemu device with PCIe?and 
MSI-X

On Thu, Aug 19, 2010 at 01:32:42PM -0500, Adnan Khaleel wrote:
   Isaku,
   
   I'm having some difficulties building the sources, I get the following 
message
   
   *akhal...@yar95 qemu-q35 $ ./configure --help
   : bad interpreter: No such file or directory
   
   And I get a similar error while compiling seabios as well.
  
   What shell are you using or am I missing something? I'm compiling from a
   typical bash shell and using gcc v4.4.0.
  
  I'm not sure. configure script isn't modified.
  Can you compile normal qemu?
  The first line of the script is #!/bin/sh. I suppose you have /bin/sh.
  
  
   In vgabios, there is a requirement for bcc. Is that borland C compiler?
  
  No. Most Linux destro has bcc package. Just you need to install it like
  yum install bcc or something.
  
  Thanks,
  
  
   
   Thanks
   
   Adnan
   
   ━
   From: Isaku Yamahata [mailto:yamah...@valinux.co.jp]
   To: Adnan Khaleel [mailto:ad...@khaleel.us]
   Cc: qemu-devel@nongnu.org
   Sent: Wed, 18 Aug 2010 22:19:04 -0500
   Subject: Re: [Qemu-devel] Template for developing a Qemu device with 
PCIe
   and MSI-X
   
   On Wed, Aug 18, 2010 at 02:10:10PM -0500, Adnan Khaleel wrote:
Hello Qemu developers,
   
I'm interested in developing a device model that plugs into Qemu that 
is
   based
on a PCIe interface and uses MSI-X. My goal is to ultimately attach a 
GPU
simulator to this PCIe interface and use the entire platfom (Qemu + 
GPU
simulator) for studying cpu, gpu interactions.
   
I'm not terribly familiar with the Qemu device model and I'm looking 
for
   some
assistance, perhaps a starting template for pcie and msi-x that would
   offer the
basic functionality that I could then build upon.
   
I have looked at the various devices that already modelled that are
   included
with Qemu (v0.12.5 at least) and I've noticed several a few pci 
devices,
   eg;
ne2k and cirrus-pci etc, however only one device truly seems to 
utilize
   both
the technologies that I'm interested in and that is the virtio-pci.c
   
I'm not sure what virtio-pci does so I'm not sure if that is a 
suitable
starting point for me.
   
Any help, suggestions etc would be extremely helpful and much
   appreciated.
   
   Qemu doesn't support pcie at the moment.
   Only partial patches have been merged, still more patches have to
   be merged for pcie to fully work. The following repo is available.
   
   git clone http://people.valinux.co.jp/~yamahata/qemu/q35/qemu
   git clone http://people.valinux.co.jp/~yamahata/qemu/q35/seabios
   git clone http://people.valinux.co.jp/~yamahata/qemu/q35/vgabios
   
   Note: patched seabios and vgabios are needed, you have to pass ACPI DSDT
   for q35.
   example:
   qemu-system-x86_64 -M pc_q35 -acpitable 
load_header,data=roms/seabios/src/
   q35-acpi-dsdt.aml
   
   This repo is for those who want to try/develop pcie support,
   not for upstream merge. So they include patches unsuitable for upstream.
   The repo includes pcie port switch emulator which utilize pcie and
   MSI(not MSI-X).
   
   The difference between PCI device and PCIe device is configuration
   space size.
   By setting PCIDeviceInfo::is_express = 1, you'll get 4K configuration
   space. Helper functions for pcie are found in qemu/hw/pcie.c
   For msi-x, see qemu/hw/msix.c.
   
   Thanks,
   --
   yamahata
   
  
  -- 
  yamahata
00:00.0 Host bridge: Intel Corporation 82G33/G31/P35/P31 Express DRAM Controller
00:01.0 VGA compatible controller: Cirrus Logic GD 5446
00:04.0 PCI bridge: Intel Corporation X58 I/O Hub PCI Express Root Port 0 (rev 
02)
00:18.0 PCI bridge: Intel Corporation X58 I/O Hub PCI Express Root Port 0 (rev 
02)
00:18.1 PCI bridge: Intel Corporation X58 I/O Hub PCI Express Root Port 0 (rev 
02)
00:18.2 PCI bridge: Intel Corporation X58 I/O Hub PCI Express Root Port 0 (rev 
02)
00:18.3 PCI bridge: Intel Corporation X58 I/O Hub PCI Express Root Port 0 (rev 
02)
00:18.4 PCI bridge: Intel Corporation 

[Qemu-devel] qemu-system-arm aborted

[S W]

Hi there

I made an ARM Linux2.6.10 image(zImage) and I tried to run it on QEMU using the 
following command.

qemu-system-arm -kernel zImage -nographic

I got an error message like:

CPU #0:
R00= R01=0113 R02=0100 R03=
R04= R05= R06= R07=
R08=cb80 R09= R10= R11=
R12= R13= R14=00010088 R15=0001
PSR=81db N--- A und32

Is it an Edian problem? I checked my Linux configuration file.
The setting is Big Endian.

Would you please give me any ideas?

Thanks!
Terry


  

[Qemu-devel] RE: qemu-system-arm aborted

[S W]

The exac error message is like the following. 
Sorry for missing some of the error message in my last email.


qemu: hardware error: icp_control_write: Bad offset 7fffe8

CPU #0:
R00= R01=0113 R02=0100 R03=
R04= R05= R06= R07=
R08=cb80 R09= R10= R11=
R12= R13= R14=00010088 R15=0001
PSR=81db N--- A und32
Aborted (core dumped)


Terry


From: s...@hotmail.co.jp
To: qemu-devel@nongnu.org
Subject: qemu-system-arm aborted
Date: Sat, 21 Aug 2010 08:36:44 +0900








Hi there

I made an ARM Linux2.6.10 image(zImage) and I tried to run it on QEMU using the 
following command.

qemu-system-arm -kernel zImage -nographic

I got an error message like:

CPU #0:
R00= R01=0113 R02=0100 R03=
R04= R05= R06= R07=
R08=cb80 R09= R10= R11=
R12= R13= R14=00010088 R15=0001
PSR=81db N--- A und32

Is it an Edian problem? I checked my Linux configuration file.
The setting is Big Endian.

Would you please give me any ideas?

Thanks!
Terry