[Qemu-devel] [Bug 584153] Re: no useful error message when tap device open fails

[Joel Schopp]

Please send this patch with a signed-off-by: to the linux kernel mailing
list and netdev mailing lists, see
http://www.kernel.org/pub/linux/docs/lkml/#s3-3

** Changed in: qemu
   Status: New => Incomplete

-- 
no useful error message when tap device open fails
https://bugs.launchpad.net/bugs/584153
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: Incomplete
Status in “qemu-kvm” package in Debian: Fix Released

Bug description:
When using tap network devices and it fails, qemu gives no information about 
what the problem is (permission denied, device busy or other), making debugging 
of such situations, especially for newbies, very difficult.  The proposed patch 
just adds strerror() around the place, making it more friendly.

See also Debian bug#578154, 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=578154 and a discussion on 
qemu-devel at http://marc.info/?t=12719287523 .

[Qemu-devel] Invitation to my XING network

[Christina Mckay]

Hi,

Hunting for network marketing prospects leaves you exhausted, discouraged and 
worn out.Interested in CEO, CFO, Director, VP 

Contacts? 

I realize there could be potential win-win between our organizations. Let us 
know if you're looking for specific industry 

focused contacts with emails.

I'd like to invite you to join my business network on XING so we can stay in 
touch and share news.

Kind regards,
Christina Mckay
Business Development Manager
IT Data 
512-904-8229
christina.mc...@mailsid.com

---

Christina Mckay invites you to her network on the platform XING:
http://www.xing.com/go/inv/29094936.8c4bc7?reagent=systemmail/invite



I no longer wish to receive invitations to XING:  
http://www.xing.com/go/opt_out_invite/U2FsdGVkX1-zAlUgfI9qxSBNinYBtTmBOZlB-Q88x8oP_7PtEoVRAF5gt5E44hHd

[Qemu-devel] [Bug 546458] Re: kernel NULL pointer in -virtual (-server) kernel

[Anthony Liguori]

I see no indication that this is actually a qemu issue.  If there's any
evidence that it is, please reopen.

** Changed in: qemu
   Status: New => Invalid

-- 
kernel NULL pointer in -virtual (-server) kernel
https://bugs.launchpad.net/bugs/546458
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: Invalid
Status in “linux” package in Ubuntu: Triaged
Status in “qemu-kvm” package in Ubuntu: Confirmed
Status in “linux” package in Fedora: Unknown

Bug description:
When stress testing eucalyptus we have run into this oops inside VMs
[   82.907577] BUG: unable to handle kernel NULL pointer dereference at 
0358^M
[   82.908842] IP: [] sym_int_sir+0x2a8/0x750^M
[   82.909773] PGD 0 ^M
[   82.910110] Thread overran stack, or stack corrupted^M
[   82.910870] Oops:  [#1] SMP ^M
[   82.911407] last sysfs file: /sys/devices/virtual/block/ram9/uevent^M

We launched 18 instances, 2 of them failed this way.  The instances run with 
192M of memory.  With 6 VM launches on a single node all at the same time the 
host is under heavy load.

This occurred in 20100323 lucid x86_64 uec-image instance.

ProblemType: Bug
AlsaDevices: Error: command ['ls', '-l', '/dev/snd/'] failed with exit code 2: 
ls: cannot access /dev/snd/: No such file or directory
AplayDevices: Error: [Errno 2] No such file or directory
Architecture: amd64
ArecordDevices: Error: [Errno 2] No such file or directory
CurrentDmesg:
 
Date: Wed Mar 24 22:06:32 2010
DistroRelease: Ubuntu 10.04
Frequency: Once a day.
Lsusb: Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
MachineType: Bochs Bochs
Package: linux-image-2.6.32-16-virtual 2.6.32-16.25
PciMultimedia:
 
ProcCmdLine: root=/dev/sda1 console=ttyS0
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: User Name 2.6.32-16.25-server
Regression: No
Reproducible: No
SourcePackage: linux
TestedUpstream: No
Uname: Linux 2.6.32-16-server x86_64
dmi.bios.date: 01/01/2007
dmi.bios.vendor: Bochs
dmi.bios.version: Bochs
dmi.chassis.type: 1
dmi.chassis.vendor: Bochs
dmi.modalias: 
dmi:bvnBochs:bvrBochs:bd01/01/2007:svnBochs:pnBochs:pvr:cvnBochs:ct1:cvr:
dmi.product.name: Bochs
dmi.sys.vendor: Bochs

[Qemu-devel] Unposted reserved_va patch

[Richard Henderson]

Re: 68a1c816868b3e35a1da698af412b29e61b1948a

In general, I like the idea (especially since I've proposed it before.  ;-)

However:

+if (have_guest_base) {
+flags |= MAP_FIXED;
+}

I think this is broken.  If the user specifies -G n -R m they're hoping
or guessing that the range [n,n+m) is free.  What they're not expecting
is for the qemu application or any of the required shared libraries to
get forcibly unmapped.

I think instead you should simply adjust the error reporting after the
mmap attempt without MAP_FIXED.



r~

[Qemu-devel] Re: [PATCH] pc: push setting default cpu_model down a level

[Marcelo Tosatti]

On Tue, Jun 01, 2010 at 05:03:00PM -0600, Alex Williamson wrote:
> Not that CPU hotplug currently works, but if you make the mistake of
> trying it on a VM started without specifying a -cpu value, you hit
> a segfault from trying to strdup(NULL) in cpu_x86_find_by_name().
> 
> Signed-off-by: Alex Williamson 

Applied, thanks.

[Qemu-devel] [Bug 450522] Re: Unable to set fullscreen anymore

[Luiz Capitulino]

Works for me, I believe this is already fixed.

** Changed in: qemu
   Status: New => Fix Committed

** Changed in: qemu
   Status: Fix Committed => New

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

Status in QEMU: New

Bug description:
Description: When pressing Ctrl-Alt-f over the QEmu window, it won't go 
fullscreen anymore.


Additional info:
* package version: 0.11.0
* window managers: xfwm, metacity


Steps to reproduce:
Start QEmu with a command similar to this:
/usr/bin/qemu-system-x86_64 -boot d -m 2047 -hda 'linux.qemu' -cdrom 
'linux.iso' -net nic,vlan=0 -net user,vlan=0 -localtime -enable-kvm

Hold Ctrl+Alt keys and press the "f" key with the QEmu window focused.

What was expected:
It should go fullscreen. If I press the combo and later maximize the window 
from the window button at some point it will go fullscreen but I can't go back, 
it behaves pretty strange and I can't reproduce the rest on request.

[Qemu-devel] [Bug 391879] Re: migrate exec ignores exit status

[Luiz Capitulino]

** Changed in: qemu
   Status: New => Confirmed

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

Status in QEMU: Confirmed
Status in “qemu-kvm” package in Ubuntu: Won't Fix

Bug description:
Binary package hint: kvm

Using

  migrate "exec:cat > foo; false"

in the monitor results in the state of the VM being written to foo, as 
expected, and the VM then being stopped. This is surprising, as I think it 
stands to reason that in case of a failed migrate-exec process, which is what a 
non-zero exit status implies to me, the VM should continue.

== Version information

$ lsb_release -rd
Description:Ubuntu 9.04
Release:9.04

$ apt-cache policy kvm
kvm:
  Installed: 1:84+dfsg-0ubuntu11
  Candidate: 1:84+dfsg-0ubuntu11
  Version table:
 *** 1:84+dfsg-0ubuntu11 0
500 http://gb.archive.ubuntu.com jaunty/main Packages
100 /var/lib/dpkg/status

[Qemu-devel] [Bug 318824] Re: DHCP/NAT: Vista fails to get IP from DHCP engine

[Joel Schopp]

** Tags added: windows

-- 
DHCP/NAT: Vista fails to get IP from DHCP engine
https://bugs.launchpad.net/bugs/318824
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: New

Bug description:

Problem: When I use userspace networking - i.e. Qemu NAT engine with DHCP -
Vista 32-bit VM guest fails to recognize it.

The only way for Vista VM to work is to manually set IP address:
IP: 10.0.2.2
Gateway: 10.0.2.15
DNS: 10.0.2.3

This problem does not happen with Windows XP VM.

./qemu -hda WindowsVista-32-mypc.qcow2 -m 512 -snapshot -name Vista-32-mypc

btw: NAT itself works - after IPs are manually configured. Emulated NIC is
Realtek RTL8139. Same problem also exists with Intel E1000 NIC.

-Alexey, 19.1.2009.

[Qemu-devel] [PATCH 02/13] block: Decouple block device "commit all" from DriveInfo

[Markus Armbruster]

do_commit() and mux_proc_byte() iterate over the list of drives
defined with drive_init().  This misses host block devices defined by
other means.  Such means don't exist now, but will be introduced later
in this series.

Change them to use new bdrv_commit_all(), which iterates over all host
block devices.

Signed-off-by: Markus Armbruster 
---
 block.c |9 +
 block.h |1 +
 blockdev.c  |   16 
 qemu-char.c |7 +--
 4 files changed, 19 insertions(+), 14 deletions(-)

diff --git a/block.c b/block.c
index 5c2f3d9..1bef649 100644
--- a/block.c
+++ b/block.c
@@ -788,6 +788,15 @@ ro_cleanup:
 return ret;
 }
 
+void bdrv_commit_all(void)
+{
+BlockDriverState *bs;
+
+QTAILQ_FOREACH(bs, &bdrv_states, list) {
+bdrv_commit(bs);
+}
+}
+
 /*
  * Return values:
  * 0- success
diff --git a/block.h b/block.h
index 9ceb64d..49e3dcf 100644
--- a/block.h
+++ b/block.h
@@ -85,6 +85,7 @@ int64_t bdrv_getlength(BlockDriverState *bs);
 void bdrv_get_geometry(BlockDriverState *bs, uint64_t *nb_sectors_ptr);
 void bdrv_guess_geometry(BlockDriverState *bs, int *pcyls, int *pheads, int 
*psecs);
 int bdrv_commit(BlockDriverState *bs);
+void bdrv_commit_all(void);
 int bdrv_change_backing_file(BlockDriverState *bs,
 const char *backing_file, const char *backing_fmt);
 void bdrv_register(BlockDriver *bdrv);
diff --git a/blockdev.c b/blockdev.c
index 0df16c7..60c9211 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -486,16 +486,16 @@ DriveInfo *drive_init(QemuOpts *opts, int 
default_to_scsi, int *fatal_error)
 
 void do_commit(Monitor *mon, const QDict *qdict)
 {
-int all_devices;
-DriveInfo *dinfo;
 const char *device = qdict_get_str(qdict, "device");
+BlockDriverState *bs;
 
-all_devices = !strcmp(device, "all");
-QTAILQ_FOREACH(dinfo, &drives, next) {
-if (!all_devices)
-if (strcmp(bdrv_get_device_name(dinfo->bdrv), device))
-continue;
-bdrv_commit(dinfo->bdrv);
+if (!strcmp(device, "all")) {
+bdrv_commit_all();
+} else {
+bs = bdrv_find(device);
+if (bs) {
+bdrv_commit(bs);
+}
 }
 }
 
diff --git a/qemu-char.c b/qemu-char.c
index 87628ea..9b69d92 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -351,12 +351,7 @@ static int mux_proc_byte(CharDriverState *chr, MuxDriver 
*d, int ch)
  break;
 }
 case 's':
-{
-DriveInfo *dinfo;
-QTAILQ_FOREACH(dinfo, &drives, next) {
-bdrv_commit(dinfo->bdrv);
-}
-}
+bdrv_commit_all();
 break;
 case 'b':
 qemu_chr_event(chr, CHR_EVENT_BREAK);
-- 
1.6.6.1

[Qemu-devel] [PATCH 08/13] qdev: Decouple qdev_prop_drive from DriveInfo

[Markus Armbruster]

Make the property point to BlockDriverState, cutting out the DriveInfo
middleman.

Signed-off-by: Markus Armbruster 
---
 block_int.h  |6 ++
 hw/fdc.c |   22 ++
 hw/ide/core.c|   14 +++---
 hw/ide/internal.h|2 +-
 hw/ide/qdev.c|8 
 hw/pci-hotplug.c |4 ++--
 hw/qdev-properties.c |   39 ---
 hw/qdev.h|6 +++---
 hw/s390-virtio.c |2 +-
 hw/scsi-bus.c|8 
 hw/scsi-disk.c   |   16 
 hw/scsi-generic.c|5 ++---
 hw/scsi.h|2 +-
 hw/usb-msd.c |   10 +-
 hw/virtio-blk.c  |2 +-
 hw/virtio-pci.c  |   12 ++--
 16 files changed, 85 insertions(+), 73 deletions(-)

diff --git a/block_int.h b/block_int.h
index e3bfd19..545b494 100644
--- a/block_int.h
+++ b/block_int.h
@@ -210,10 +210,8 @@ void *qemu_blockalign(BlockDriverState *bs, size_t size);
 int is_windows_drive(const char *filename);
 #endif
 
-struct DriveInfo;
-
 typedef struct BlockConf {
-struct DriveInfo *dinfo;
+BlockDriverState *bs;
 uint16_t physical_block_size;
 uint16_t logical_block_size;
 uint16_t min_io_size;
@@ -232,7 +230,7 @@ static inline unsigned int get_physical_block_exp(BlockConf 
*conf)
 }
 
 #define DEFINE_BLOCK_PROPERTIES(_state, _conf)  \
-DEFINE_PROP_DRIVE("drive", _state, _conf.dinfo),\
+DEFINE_PROP_DRIVE("drive", _state, _conf.bs),   \
 DEFINE_PROP_UINT16("logical_block_size", _state,\
_conf.logical_block_size, 512),  \
 DEFINE_PROP_UINT16("physical_block_size", _state,   \
diff --git a/hw/fdc.c b/hw/fdc.c
index b978957..2b3cbb9 100644
--- a/hw/fdc.c
+++ b/hw/fdc.c
@@ -80,7 +80,6 @@ typedef enum FDiskFlags {
 } FDiskFlags;
 
 typedef struct FDrive {
-DriveInfo *dinfo;
 BlockDriverState *bs;
 /* Drive status */
 FDriveType drive;
@@ -100,7 +99,6 @@ typedef struct FDrive {
 static void fd_init(FDrive *drv)
 {
 /* Drive */
-drv->bs = drv->dinfo ? drv->dinfo->bdrv : NULL;
 drv->drive = FDRIVE_DRV_NONE;
 drv->perpendicular = 0;
 /* Disk */
@@ -1862,10 +1860,10 @@ FDCtrl *fdctrl_init_isa(DriveInfo **fds)
 
 dev = isa_create("isa-fdc");
 if (fds[0]) {
-qdev_prop_set_drive(&dev->qdev, "driveA", fds[0]);
+qdev_prop_set_drive(&dev->qdev, "driveA", fds[0]->bdrv);
 }
 if (fds[1]) {
-qdev_prop_set_drive(&dev->qdev, "driveB", fds[1]);
+qdev_prop_set_drive(&dev->qdev, "driveB", fds[1]->bdrv);
 }
 if (qdev_init(&dev->qdev) < 0)
 return NULL;
@@ -1884,10 +1882,10 @@ FDCtrl *fdctrl_init_sysbus(qemu_irq irq, int dma_chann,
 fdctrl = &sys->state;
 fdctrl->dma_chann = dma_chann; /* FIXME */
 if (fds[0]) {
-qdev_prop_set_drive(dev, "driveA", fds[0]);
+qdev_prop_set_drive(dev, "driveA", fds[0]->bdrv);
 }
 if (fds[1]) {
-qdev_prop_set_drive(dev, "driveB", fds[1]);
+qdev_prop_set_drive(dev, "driveB", fds[1]->bdrv);
 }
 qdev_init_nofail(dev);
 sysbus_connect_irq(&sys->busdev, 0, irq);
@@ -1905,7 +1903,7 @@ FDCtrl *sun4m_fdctrl_init(qemu_irq irq, 
target_phys_addr_t io_base,
 
 dev = qdev_create(NULL, "SUNW,fdtwo");
 if (fds[0]) {
-qdev_prop_set_drive(dev, "drive", fds[0]);
+qdev_prop_set_drive(dev, "drive", fds[0]->bdrv);
 }
 qdev_init_nofail(dev);
 sys = DO_UPCAST(FDCtrlSysBus, busdev.qdev, dev);
@@ -2030,8 +2028,8 @@ static ISADeviceInfo isa_fdc_info = {
 .qdev.vmsd  = &vmstate_isa_fdc,
 .qdev.reset = fdctrl_external_reset_isa,
 .qdev.props = (Property[]) {
-DEFINE_PROP_DRIVE("driveA", FDCtrlISABus, state.drives[0].dinfo),
-DEFINE_PROP_DRIVE("driveB", FDCtrlISABus, state.drives[1].dinfo),
+DEFINE_PROP_DRIVE("driveA", FDCtrlISABus, state.drives[0].bs),
+DEFINE_PROP_DRIVE("driveB", FDCtrlISABus, state.drives[1].bs),
 DEFINE_PROP_END_OF_LIST(),
 },
 };
@@ -2053,8 +2051,8 @@ static SysBusDeviceInfo sysbus_fdc_info = {
 .qdev.vmsd  = &vmstate_sysbus_fdc,
 .qdev.reset = fdctrl_external_reset_sysbus,
 .qdev.props = (Property[]) {
-DEFINE_PROP_DRIVE("driveA", FDCtrlSysBus, state.drives[0].dinfo),
-DEFINE_PROP_DRIVE("driveB", FDCtrlSysBus, state.drives[1].dinfo),
+DEFINE_PROP_DRIVE("driveA", FDCtrlSysBus, state.drives[0].bs),
+DEFINE_PROP_DRIVE("driveB", FDCtrlSysBus, state.drives[1].bs),
 DEFINE_PROP_END_OF_LIST(),
 },
 };
@@ -2066,7 +2064,7 @@ static SysBusDeviceInfo sun4m_fdc_info = {
 .qdev.vmsd  = &vmstate_sysbus_fdc,
 .qdev.reset = fdctrl_external_reset_sysbus,
 .qdev.props = (Property[]) {
-DEFINE_PROP_DRIVE("drive", FDCtrlSysBus, state.drives[0].dinfo),
+DEFINE_PROP_DRIVE("drive", FDCtrlSysBus, state.driv

[Qemu-devel] [PATCH] acpi_piix4: save gpe and pci hotplug slot status

[Alex Williamson]

PCI hotplug currently doesn't work after a migration because
we don't migrate the enable bits of the GPE state.  Pull hotplug
structs into vmstate.

Signed-off-by: Alex Williamson 
---

 hw/acpi_piix4.c |   29 -
 1 files changed, 28 insertions(+), 1 deletions(-)

diff --git a/hw/acpi_piix4.c b/hw/acpi_piix4.c
index 0fce958..091cdcd 100644
--- a/hw/acpi_piix4.c
+++ b/hw/acpi_piix4.c
@@ -282,9 +282,33 @@ static int vmstate_acpi_post_load(void *opaque, int 
version_id)
 return 0;
 }
 
+static const VMStateDescription vmstate_gpe = {
+.name = "gpe",
+.version_id = 1,
+.minimum_version_id = 1,
+.minimum_version_id_old = 1,
+.fields  = (VMStateField []) {
+VMSTATE_UINT16(sts, struct gpe_regs),
+VMSTATE_UINT16(en, struct gpe_regs),
+VMSTATE_END_OF_LIST()
+}
+};
+
+static const VMStateDescription vmstate_pci_status = {
+.name = "pci_status",
+.version_id = 1,
+.minimum_version_id = 1,
+.minimum_version_id_old = 1,
+.fields  = (VMStateField []) {
+VMSTATE_UINT32(up, struct pci_status),
+VMSTATE_UINT32(down, struct pci_status),
+VMSTATE_END_OF_LIST()
+}
+};
+
 static const VMStateDescription vmstate_acpi = {
 .name = "piix4_pm",
-.version_id = 1,
+.version_id = 2,
 .minimum_version_id = 1,
 .minimum_version_id_old = 1,
 .post_load = vmstate_acpi_post_load,
@@ -296,6 +320,9 @@ static const VMStateDescription vmstate_acpi = {
 VMSTATE_STRUCT(apm, PIIX4PMState, 0, vmstate_apm, APMState),
 VMSTATE_TIMER(tmr_timer, PIIX4PMState),
 VMSTATE_INT64(tmr_overflow_time, PIIX4PMState),
+VMSTATE_STRUCT(gpe, PIIX4PMState, 2, vmstate_gpe, struct gpe_regs),
+VMSTATE_STRUCT(pci0_status, PIIX4PMState, 2, vmstate_pci_status,
+   struct pci_status),
 VMSTATE_END_OF_LIST()
 }
 };

[Qemu-devel] [Bug 485258] Re: 64-bit win2003r2 with sp2 64-bit with network type rtl8139 generates blue screen after running network test

[Joel Schopp]

** Tags added: windows

-- 
64-bit win2003r2 with sp2 64-bit with network type rtl8139 generates blue 
screen after running network test
https://bugs.launchpad.net/bugs/485258
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: New

Bug description:
64-bit win2003r2 with sp2 64-bit with network type rtl8139 generates blue 
screen after running network test

Steps to recreate:
1) install qemu frm git clone git://git.savannah.nongnu.org/qemu.git

2)Download Soap Stone Benchmark(http://soap-stone.sourceforge.net/) and IBM 
java 1.4 for windows

3)use  win2k3r2sp2 64-bit as the server and win2k3r2sp2 32-bit as client (this 
bug does not occur when win2k3r2sp2 64-bit is the client)

4) Running the test will reset the  network interface on the 
server(win2k3r2sp264bit).

5)Then shutdown the server(win2k3r2sp2 64bit), which will generate a blue 
screen.


Qemu cmd line used:
/usr/local/bin/qemu-system-x86_e 'vm1'  -drive file=win2003r2-64.raw,boot=on 
-net nic,vlan=0,macaddr=20:20:20:00:00:01,model=rtl8139  -net 
tap,vlan=0,script=/home/yogi/qemu-ifup  -m 10240   -usbdevice tablet -vnc :0 
-enable-kvm

uname -a
Linux bc1cn9 2.6.30.9-96.fc11.x86_64 #1 SMP Wed Nov 4 00:02:04 EST 2009 x86_64 
x86_64 x86_64 GNU/Linux

Distro: fedora 11

I have attached the generated Blue Screen..

Thx
yogi

[Qemu-devel] [PATCH 13/13] blockdev: New -blockdev to define a host block device

[Markus Armbruster]

Existing -drive defines both host and guest part.  To make it work
with -device, we created if=none.  But all this does is peel off guest
device selection.  The other guest properties such as geometry,
removable vs. fixed media, and serial number are still in the wrong
place.

Instead of overloading -drive even further, create a new, clean option
to define a host block device.  -drive stays around unchanged for
command line convenience and backwards compatibility.

This is just a first step.  Future work includes:

* A set of monitor commands to go with it.

* Let device model declare media removable.  -drive has that in the
  host part, as media=(cdrom|floppy), but it really belongs to the
  guest part.

* Turn geometry into device properties.  This will also ensure proper
  range checking.  The existing range checking for -drive can't work
  with if=none.

* Make device models reject error actions they don't support.  The
  existing check for -drive can't work with if=none.

* Like -drive, -blockdev ignores cache= silently when snapshot=on.  Do
  we really want that?

Signed-off-by: Markus Armbruster 
---
 blockdev.c  |  141 ++
 blockdev.h  |2 +
 qemu-config.c   |   38 +++
 qemu-config.h   |1 +
 qemu-options.hx |   49 +++
 vl.c|   29 ++-
 6 files changed, 246 insertions(+), 14 deletions(-)

diff --git a/blockdev.c b/blockdev.c
index a1e6394..e03ecfc 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -98,6 +98,132 @@ static int parse_block_aio(const char *val)
 }
 }
 
+static int blockdev_insert(BlockDriverState *bs, QemuOpts *opts)
+{
+int snapshot = qemu_opt_get_bool(opts, "snapshot", 0);
+const char *file = qemu_opt_get(opts, "file");
+const char *cache = qemu_opt_get(opts, "cache");
+const char *aio = qemu_opt_get(opts, "aio");
+const char *format = qemu_opt_get(opts, "format");
+const char *rerror = qemu_opt_get(opts, "rerror");
+const char *werror = qemu_opt_get(opts, "werror");
+int readonly = qemu_opt_get_bool(opts, "readonly", 0);
+BlockDriver *drv;
+int res, flags;
+BlockErrorAction on_read_error, on_write_error;
+
+if (!file) {
+qerror_report(QERR_MISSING_PARAMETER, "file");
+return -1;
+}
+
+drv = NULL;
+if (format) {
+drv = parse_block_format(format);
+if (!drv) {
+return -1;
+}
+}
+
+res = parse_block_error_action(rerror, 1);
+if (on_read_error < 0) {
+return -1;
+}
+on_read_error = res;
+res = parse_block_error_action(werror, 0);
+if (res < 0) {
+return -1;
+}
+on_write_error = res;
+
+flags = 0;
+res = parse_block_cache(cache);
+if (res < 0) {
+return -1;
+}
+flags |= res;
+if (snapshot) {
+/* always use write-back with snapshot */
+/* FIXME ignores explicit cache= *silently*; really want that? */
+flags &= ~BDRV_O_CACHE_MASK;
+flags |= (BDRV_O_SNAPSHOT | BDRV_O_CACHE_WB);
+flags |= BDRV_O_SNAPSHOT;
+}
+res = parse_block_aio(aio);
+if (res < 0) {
+return -1;
+}
+flags |= res;
+flags |= readonly ? 0 : BDRV_O_RDWR;
+
+bdrv_set_on_error(bs, on_read_error, on_write_error);
+res = bdrv_open(bs, file, flags, drv);
+if (res < 0) {
+qerror_report(QERR_OPEN_FILE_FAILED, file);
+bdrv_close(bs);
+return -1;
+}
+return 0;
+}
+
+BlockDriverState *blockdev_open(QemuOpts *opts)
+{
+const char *id = qemu_opts_id(opts);
+const char *file = qemu_opt_get(opts, "file");
+BlockDriverState *bs;
+QemuOpt *opt;
+const char *name;
+
+if (!id) {
+qerror_report(QERR_MISSING_PARAMETER, "id");
+return NULL;
+}
+
+bs = bdrv_find(id);
+if (bs) {
+qerror_report(QERR_DUPLICATE_ID, id, "blockdev");
+return NULL;
+}
+bs = bdrv_new(id);
+
+if (!file) {
+/* file is optional only if no other options are present; check */
+opt = NULL;
+while ((opt = qemu_opt_next(opts, opt))) {
+name = qemu_opt_name(opt);
+if (strcmp(name, "file")) {
+qerror_report(QERR_MISSING_PARAMETER, "file");
+return NULL;
+}
+}
+/* block device without media wanted */
+return bs;
+}
+
+if (blockdev_insert(bs, opts) < 0) {
+return NULL;
+}
+return bs;
+}
+
+static void blockdev_format_help_iter(void *opaque, const char *name)
+{
+error_printf(" %s", name);
+}
+
+int blockdev_format_help(QemuOpts *opts)
+{
+const char *format = qemu_opt_get(opts, "format");
+
+if (format && !strcmp(format, "?")) {
+error_printf("Supported block device formats:");
+bdrv_iterate_format(blockdev_format_help_iter, NULL);
+error_printf("\n");
+return 1;
+}
+return 0;
+}
+
 static int blockdev_de

[Qemu-devel] [PATCH 10/13] qemu-option: New qemu_opts_reset()

[Markus Armbruster]

Signed-off-by: Markus Armbruster 
---
 qemu-option.c |9 +
 qemu-option.h |1 +
 2 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/qemu-option.c b/qemu-option.c
index acd74f9..87e324c 100644
--- a/qemu-option.c
+++ b/qemu-option.c
@@ -698,6 +698,15 @@ QemuOpts *qemu_opts_create(QemuOptsList *list, const char 
*id, int fail_if_exist
 return opts;
 }
 
+void qemu_opts_reset(QemuOptsList *list)
+{
+QemuOpts *opts, *next_opts;
+
+QTAILQ_FOREACH_SAFE(opts, &list->head, next, next_opts) {
+qemu_opts_del(opts);
+}
+}
+
 int qemu_opts_set(QemuOptsList *list, const char *id,
   const char *name, const char *value)
 {
diff --git a/qemu-option.h b/qemu-option.h
index 4823219..9e2406c 100644
--- a/qemu-option.h
+++ b/qemu-option.h
@@ -115,6 +115,7 @@ int qemu_opt_foreach(QemuOpts *opts, qemu_opt_loopfunc 
func, void *opaque,
 
 QemuOpts *qemu_opts_find(QemuOptsList *list, const char *id);
 QemuOpts *qemu_opts_create(QemuOptsList *list, const char *id, int 
fail_if_exists);
+void qemu_opts_reset(QemuOptsList *list);
 int qemu_opts_set(QemuOptsList *list, const char *id,
   const char *name, const char *value);
 const char *qemu_opts_id(QemuOpts *opts);
-- 
1.6.6.1

[Qemu-devel] [PATCH 06/13] blockdev: Give drives internal linkage

[Markus Armbruster]

This is the list of drives defined with drive_init().  Hide it, so it
doesn't get abused.

Signed-off-by: Markus Armbruster 
---
 blockdev.c |2 +-
 blockdev.h |2 --
 2 files changed, 1 insertions(+), 3 deletions(-)

diff --git a/blockdev.c b/blockdev.c
index 53a0e9c..ace74e4 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -15,7 +15,7 @@
 #include "qemu-config.h"
 #include "sysemu.h"
 
-struct drivelist drives = QTAILQ_HEAD_INITIALIZER(drives);
+static QTAILQ_HEAD(drivelist, DriveInfo) drives = 
QTAILQ_HEAD_INITIALIZER(drives);
 
 QemuOpts *drive_add(const char *file, const char *fmt, ...)
 {
diff --git a/blockdev.h b/blockdev.h
index 9e8a7fc..23ea576 100644
--- a/blockdev.h
+++ b/blockdev.h
@@ -36,8 +36,6 @@ typedef struct DriveInfo {
 #define MAX_IDE_DEVS   2
 #define MAX_SCSI_DEVS  7
 
-extern QTAILQ_HEAD(drivelist, DriveInfo) drives;
-
 extern DriveInfo *drive_get(BlockInterfaceType type, int bus, int unit);
 extern DriveInfo *drive_get_by_id(const char *id);
 extern int drive_get_max_bus(BlockInterfaceType type);
-- 
1.6.6.1

[Qemu-devel] [PATCH 05/13] block: Decouple savevm from DriveInfo

[Markus Armbruster]

We find snapshots by iterating over the list of drives defined with
drive_init().  This misses host block devices defined by other means.
Such means don't exist now, but will be introduced later in this
series.

Iterate over all host block devices instead, with bdrv_next().

Signed-off-by: Markus Armbruster 
---
 savevm.c |   32 ++--
 1 files changed, 14 insertions(+), 18 deletions(-)

diff --git a/savevm.c b/savevm.c
index 18852cd..12a8ba5 100644
--- a/savevm.c
+++ b/savevm.c
@@ -1593,12 +1593,13 @@ static int bdrv_has_snapshot(BlockDriverState *bs)
 static BlockDriverState *get_bs_snapshots(void)
 {
 BlockDriverState *bs;
-DriveInfo *dinfo;
 
 if (bs_snapshots)
 return bs_snapshots;
-QTAILQ_FOREACH(dinfo, &drives, next) {
-bs = dinfo->bdrv;
+/* FIXME what if bs_snapshots gets hot-unplugged? */
+
+bs = NULL;
+while ((bs = bdrv_next(bs))) {
 if (bdrv_can_snapshot(bs))
 goto ok;
 }
@@ -1636,12 +1637,11 @@ static int bdrv_snapshot_find(BlockDriverState *bs, 
QEMUSnapshotInfo *sn_info,
 static int del_existing_snapshots(Monitor *mon, const char *name)
 {
 BlockDriverState *bs;
-DriveInfo *dinfo;
 QEMUSnapshotInfo sn1, *snapshot = &sn1;
 int ret;
 
-QTAILQ_FOREACH(dinfo, &drives, next) {
-bs = dinfo->bdrv;
+bs = NULL;
+while ((bs = bdrv_next(bs))) {
 if (bdrv_can_snapshot(bs) &&
 bdrv_snapshot_find(bs, snapshot, name) >= 0)
 {
@@ -1660,7 +1660,6 @@ static int del_existing_snapshots(Monitor *mon, const 
char *name)
 
 void do_savevm(Monitor *mon, const QDict *qdict)
 {
-DriveInfo *dinfo;
 BlockDriverState *bs, *bs1;
 QEMUSnapshotInfo sn1, *sn = &sn1, old_sn1, *old_sn = &old_sn1;
 int ret;
@@ -1730,8 +1729,8 @@ void do_savevm(Monitor *mon, const QDict *qdict)
 
 /* create the snapshots */
 
-QTAILQ_FOREACH(dinfo, &drives, next) {
-bs1 = dinfo->bdrv;
+bs1 = NULL;
+while ((bs1 = bdrv_next(bs1))) {
 if (bdrv_has_snapshot(bs1)) {
 /* Write VM state size only to the image that contains the state */
 sn->vm_state_size = (bs == bs1 ? vm_state_size : 0);
@@ -1750,7 +1749,6 @@ void do_savevm(Monitor *mon, const QDict *qdict)
 
 int load_vmstate(const char *name)
 {
-DriveInfo *dinfo;
 BlockDriverState *bs, *bs1;
 QEMUSnapshotInfo sn;
 QEMUFile *f;
@@ -1765,8 +1763,8 @@ int load_vmstate(const char *name)
 /* Flush all IO requests so they don't interfere with the new state.  */
 qemu_aio_flush();
 
-QTAILQ_FOREACH(dinfo, &drives, next) {
-bs1 = dinfo->bdrv;
+bs1 = NULL;
+while ((bs1 = bdrv_next(bs1))) {
 if (bdrv_has_snapshot(bs1)) {
 ret = bdrv_snapshot_goto(bs1, name);
 if (ret < 0) {
@@ -1816,7 +1814,6 @@ int load_vmstate(const char *name)
 
 void do_delvm(Monitor *mon, const QDict *qdict)
 {
-DriveInfo *dinfo;
 BlockDriverState *bs, *bs1;
 int ret;
 const char *name = qdict_get_str(qdict, "name");
@@ -1827,8 +1824,8 @@ void do_delvm(Monitor *mon, const QDict *qdict)
 return;
 }
 
-QTAILQ_FOREACH(dinfo, &drives, next) {
-bs1 = dinfo->bdrv;
+bs1 = NULL;
+while ((bs1 = bdrv_next(bs1))) {
 if (bdrv_has_snapshot(bs1)) {
 ret = bdrv_snapshot_delete(bs1, name);
 if (ret < 0) {
@@ -1846,7 +1843,6 @@ void do_delvm(Monitor *mon, const QDict *qdict)
 
 void do_info_snapshots(Monitor *mon)
 {
-DriveInfo *dinfo;
 BlockDriverState *bs, *bs1;
 QEMUSnapshotInfo *sn_tab, *sn;
 int nb_sns, i;
@@ -1858,8 +1854,8 @@ void do_info_snapshots(Monitor *mon)
 return;
 }
 monitor_printf(mon, "Snapshot devices:");
-QTAILQ_FOREACH(dinfo, &drives, next) {
-bs1 = dinfo->bdrv;
+bs1 = NULL;
+while ((bs1 = bdrv_next(bs1))) {
 if (bdrv_has_snapshot(bs1)) {
 if (bs == bs1)
 monitor_printf(mon, " %s", bdrv_get_device_name(bs1));
-- 
1.6.6.1

[Qemu-devel] [PATCH 09/13] blockdev: drive_get_by_id() is no longer used, remove

[Markus Armbruster]

Signed-off-by: Markus Armbruster 
---
 blockdev.c |   12 
 blockdev.h |1 -
 2 files changed, 0 insertions(+), 13 deletions(-)

diff --git a/blockdev.c b/blockdev.c
index f90d4fc..8c51e6e 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -87,18 +87,6 @@ DriveInfo *drive_get(BlockInterfaceType type, int bus, int 
unit)
 return NULL;
 }
 
-DriveInfo *drive_get_by_id(const char *id)
-{
-DriveInfo *dinfo;
-
-QTAILQ_FOREACH(dinfo, &drives, next) {
-if (strcmp(id, dinfo->id))
-continue;
-return dinfo;
-}
-return NULL;
-}
-
 int drive_get_max_bus(BlockInterfaceType type)
 {
 int max_bus;
diff --git a/blockdev.h b/blockdev.h
index 8607086..bb89bfa 100644
--- a/blockdev.h
+++ b/blockdev.h
@@ -44,7 +44,6 @@ typedef struct DriveInfo {
 #define MAX_SCSI_DEVS  7
 
 extern DriveInfo *drive_get(BlockInterfaceType type, int bus, int unit);
-extern DriveInfo *drive_get_by_id(const char *id);
 extern int drive_get_max_bus(BlockInterfaceType type);
 extern void drive_uninit(DriveInfo *dinfo);
 extern const char *drive_get_serial(BlockDriverState *bdrv);
-- 
1.6.6.1

[Qemu-devel] [PATCH 07/13] blockdev: Means to destroy blockdev only if made with drive_init()

[Markus Armbruster]

All drives are still made that way.  They get destroyed along with
their device.  That's inappropriate for the alternative way to make
blockdevs that will appear later in this series.  These won't have a
DriveInfo.

blockdev_detach() destroys the blockdev only if it has a DriveInfo.

blockdev_attach() does nothing for now.  It'll be fleshed out later.

Signed-off-by: Markus Armbruster 
---
 blockdev.c |   35 +++
 blockdev.h |7 +++
 2 files changed, 42 insertions(+), 0 deletions(-)

diff --git a/blockdev.c b/blockdev.c
index ace74e4..f90d4fc 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -1,8 +1,12 @@
 /*
  * QEMU host block devices
  *
+ * Copyright (C) 2010 Red Hat Inc.
  * Copyright (c) 2003-2008 Fabrice Bellard
  *
+ * Authors:
+ *  Markus Armbruster ,
+ *
  * This work is licensed under the terms of the GNU GPL, version 2 or
  * later.  See the COPYING file in the top-level directory.
  */
@@ -17,6 +21,37 @@
 
 static QTAILQ_HEAD(drivelist, DriveInfo) drives = 
QTAILQ_HEAD_INITIALIZER(drives);
 
+static int blockdev_del_dinfo(BlockDriverState *bs)
+{
+DriveInfo *dinfo, *next_dinfo;
+int res = 0;
+
+QTAILQ_FOREACH_SAFE(dinfo, &drives, next, next_dinfo) {
+if (dinfo->bdrv == bs) {
+qemu_opts_del(dinfo->opts);
+QTAILQ_REMOVE(&drives, dinfo, next);
+qemu_free(dinfo);
+res = 1;
+}
+}
+
+return res;
+}
+
+int blockdev_attach(BlockDriverState *bs, DeviceState *qdev)
+{
+return 0;
+}
+
+void blockdev_detach(BlockDriverState *bs, DeviceState *qdev)
+{
+/* Backward compatibility: auto-destroy block device made with
+ * drive_init() when its guest device detaches */
+if (blockdev_del_dinfo(bs)) {
+bdrv_delete(bs);
+}
+}
+
 QemuOpts *drive_add(const char *file, const char *fmt, ...)
 {
 va_list ap;
diff --git a/blockdev.h b/blockdev.h
index 23ea576..8607086 100644
--- a/blockdev.h
+++ b/blockdev.h
@@ -1,8 +1,12 @@
 /*
  * QEMU host block devices
  *
+ * Copyright (C) 2010 Red Hat Inc.
  * Copyright (c) 2003-2008 Fabrice Bellard
  *
+ * Authors:
+ *  Markus Armbruster ,
+ *
  * This work is licensed under the terms of the GNU GPL, version 2 or
  * later.  See the COPYING file in the top-level directory.
  */
@@ -13,6 +17,9 @@
 #include "block.h"
 #include "qemu-queue.h"
 
+int blockdev_attach(BlockDriverState *, DeviceState *);
+void blockdev_detach(BlockDriverState *, DeviceState *);
+
 typedef enum {
 IF_NONE,
 IF_IDE, IF_SCSI, IF_FLOPPY, IF_PFLASH, IF_MTD, IF_SD, IF_VIRTIO, IF_XEN,
-- 
1.6.6.1

[Qemu-devel] [Bug 491345] Re: remote migration fails with message "load of migration failed"

[Joel Schopp]

** Tags added: windows

-- 
remote migration fails with message "load of migration failed"
https://bugs.launchpad.net/bugs/491345
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: New

Bug description:
Remote migration fails with message  "load of migration failed" on the 
destination after migration


Steps to recreate:
1) install qemu frm git clone git://git.savannah.nongnu.org/qemu.git
2)The VM image was shared using nfs
3)qemu cmdline used:
 Source:
/usr/local/bin/qemu-system-x86_64 -name 'vm1'   -drive file=win2k3sp2-32.qcow2  
 -m 6144 --enable-kvm-usbdevice tablet -vnc :0 -monitor stdio 
 Destination:
/usr/local/bin/qemu-system-x86_64 -name 'vm1'   -drive file=win2k3sp2-32.qcow2  
 -m 6144 --enable-kvm-usbdevice tablet -vnc :0 -monitor stdio --incoming 
tcp:0:
5)migrate tcp:destination:

uname -a
Linux  2.6.30.9-96.fc11.x86_64 #1 SMP Wed Nov 4 00:02:04 EST 2009 x86_64 x86_64 
x86_64 GNU/Linux

Distro: fedora 11

Thx
yogi

[Qemu-devel] [Bug 497273] Re: winxp.64 fails to install in -rc2 with kvm

[Joel Schopp]

** Tags added: windows

-- 
winxp.64 fails to install in -rc2 with kvm
https://bugs.launchpad.net/bugs/497273
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: New

Bug description:
Host: Fedora11, 64-bit
Kernel: 2.6.30.9-96.fc11.x86_64
KVM modules:

# modinfo kvm
filename:   /lib/modules/2.6.30.9-96.fc11.x86_64/kernel/arch/x86/kvm/kvm.ko
license:GPL
author: Qumranet
srcversion: 23A53503602E48217AC12F1
depends:
vermagic:   2.6.30.9-96.fc11.x86_64 SMP mod_unload 
parm:   oos_shadow:bool
parm:   msi2intx:bool

]# modinfo kvm-intel
filename:   
/lib/modules/2.6.30.9-96.fc11.x86_64/kernel/arch/x86/kvm/kvm-intel.ko
license:GPL
author: Qumranet
srcversion: 5DD68E0B8497DC4518A8797
depends:kvm
vermagic:   2.6.30.9-96.fc11.x86_64 SMP mod_unload 
parm:   bypass_guest_pf:bool
parm:   enable_vpid:bool
parm:   flexpriority_enabled:bool
parm:   enable_ept:bool
parm:   emulate_invalid_guest_state:bool

Host CPU: Intel(R) Xeon(R) CPU   X5550  @ 2.67GHz

Guest commandline: 
sudo ./x86_64-softmmu/qemu-system-x86_64 -L pc-bios -name 'vm1' -monitor stdio 
-drive file=~/work/images/winXP-64.qcow2,if=ide,cache=writeback -net 
nic,vlan=0,model=rtl8139,macaddr=52:54:00:12:34:56 -net user,vlan=0 -m 512 
-cdrom ~/work/isos/en_windows_xp_professional_x64.iso -enable-kvm -redir 
tcp:5000::22

Steps to reproduce:

1. git checkout -b 12rc2 v0.12.0-rc2
2. ./configure --target-list=x86_64-softmmu
3. make
4. qemu-img create -f qcow2 ~/work/images/winXP-64.qcow2 20G
5. sudo ./x86_64-softmmu/qemu-system-x86_64 -L pc-bios -name 'vm1' -monitor 
stdio -drive file=~/work/images/winXP-64.qcow2,if=ide,cache=writeback -net 
nic,vlan=0,model=rtl8139,macaddr=52:54:00:12:34:56 -net user,vlan=0 -m 512 
-cdrom ~/work/isos/en_windows_xp_professional_x64.iso -enable-kvm -redir 
tcp:5000::22

Guest boots XP.64 installer, loads some files and then hangs at "Starting 
Windows XP"

Reverting to -rc1 and XP installs just fine.  Git bisect points to:

commit 066263f37701687c64af9d8825e3376d069ebfd4
Author: Andre Przywara 
Date:   Mon Dec 7 11:58:02 2009 +0100

cpuid: Fix multicore setup on Intel


Reverting this fixes the problem.

Different kvm modules seem to affect this install as well.  Switching 
to different kvm-kmod packages:

2.6.32 modules work fine with 0.12.0-rc2, no issues at all

2.6.30 modules fail, reverting the above commit doesn't help, seems to 
be in the same boat as 2.6.28 modules

2.6.31.5 (roughly equivalent to Fedora11 modules) work on -rc1, fail on
rc2, reverting above commit fixes -rc2.

[Qemu-devel] [PATCH 01/13] block: Move error actions from DriveInfo to BlockDriverState

[Markus Armbruster]

That's where they belong semantically (block device host part), even
though the actions are actually executed by guest device code.

Signed-off-by: Markus Armbruster 
---
 block.c |   12 
 block.h |8 
 block_int.h |1 +
 blockdev.c  |   17 ++---
 blockdev.h  |   10 --
 hw/ide/core.c   |2 +-
 hw/scsi-disk.c  |2 +-
 hw/virtio-blk.c |3 +--
 8 files changed, 26 insertions(+), 29 deletions(-)

diff --git a/block.c b/block.c
index cacf11b..5c2f3d9 100644
--- a/block.c
+++ b/block.c
@@ -1206,6 +1206,18 @@ int bdrv_get_translation_hint(BlockDriverState *bs)
 return bs->translation;
 }
 
+void bdrv_set_on_error(BlockDriverState *bs, BlockErrorAction on_read_error,
+   BlockErrorAction on_write_error)
+{
+bs->on_read_error = on_read_error;
+bs->on_write_error = on_write_error;
+}
+
+BlockErrorAction bdrv_get_on_error(BlockDriverState *bs, int is_read)
+{
+return is_read ? bs->on_read_error : bs->on_write_error;
+}
+
 int bdrv_is_removable(BlockDriverState *bs)
 {
 return bs->removable;
diff --git a/block.h b/block.h
index 25744b1..9ceb64d 100644
--- a/block.h
+++ b/block.h
@@ -42,6 +42,11 @@ typedef struct QEMUSnapshotInfo {
 #define BDRV_SECTOR_MASK   ~(BDRV_SECTOR_SIZE - 1)
 
 typedef enum {
+BLOCK_ERR_REPORT, BLOCK_ERR_IGNORE, BLOCK_ERR_STOP_ENOSPC,
+BLOCK_ERR_STOP_ANY
+} BlockErrorAction;
+
+typedef enum {
 BDRV_ACTION_REPORT, BDRV_ACTION_IGNORE, BDRV_ACTION_STOP
 } BlockMonEventAction;
 
@@ -146,6 +151,9 @@ void bdrv_get_geometry_hint(BlockDriverState *bs,
 int *pcyls, int *pheads, int *psecs);
 int bdrv_get_type_hint(BlockDriverState *bs);
 int bdrv_get_translation_hint(BlockDriverState *bs);
+void bdrv_set_on_error(BlockDriverState *bs, BlockErrorAction on_read_error,
+   BlockErrorAction on_write_error);
+BlockErrorAction bdrv_get_on_error(BlockDriverState *bs, int is_read);
 int bdrv_is_removable(BlockDriverState *bs);
 int bdrv_is_read_only(BlockDriverState *bs);
 int bdrv_is_sg(BlockDriverState *bs);
diff --git a/block_int.h b/block_int.h
index 1a7240c..e3bfd19 100644
--- a/block_int.h
+++ b/block_int.h
@@ -182,6 +182,7 @@ struct BlockDriverState {
drivers. They are not used by the block driver */
 int cyls, heads, secs, translation;
 int type;
+BlockErrorAction on_read_error, on_write_error;
 char device_name[32];
 unsigned long *dirty_bitmap;
 int64_t dirty_count;
diff --git a/blockdev.c b/blockdev.c
index bd9783a..0df16c7 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -90,19 +90,6 @@ const char *drive_get_serial(BlockDriverState *bdrv)
 return "\0";
 }
 
-BlockInterfaceErrorAction drive_get_on_error(
-BlockDriverState *bdrv, int is_read)
-{
-DriveInfo *dinfo;
-
-QTAILQ_FOREACH(dinfo, &drives, next) {
-if (dinfo->bdrv == bdrv)
-return is_read ? dinfo->on_read_error : dinfo->on_write_error;
-}
-
-return is_read ? BLOCK_ERR_REPORT : BLOCK_ERR_STOP_ENOSPC;
-}
-
 static void bdrv_format_print(void *opaque, const char *name)
 {
 fprintf(stderr, " %s", name);
@@ -418,13 +405,13 @@ DriveInfo *drive_init(QemuOpts *opts, int 
default_to_scsi, int *fatal_error)
 dinfo->type = type;
 dinfo->bus = bus_id;
 dinfo->unit = unit_id;
-dinfo->on_read_error = on_read_error;
-dinfo->on_write_error = on_write_error;
 dinfo->opts = opts;
 if (serial)
 strncpy(dinfo->serial, serial, sizeof(serial));
 QTAILQ_INSERT_TAIL(&drives, dinfo, next);
 
+bdrv_set_on_error(dinfo->bdrv, on_read_error, on_write_error);
+
 switch(type) {
 case IF_IDE:
 case IF_SCSI:
diff --git a/blockdev.h b/blockdev.h
index dfc9de1..9e8a7fc 100644
--- a/blockdev.h
+++ b/blockdev.h
@@ -19,11 +19,6 @@ typedef enum {
 IF_COUNT
 } BlockInterfaceType;
 
-typedef enum {
-BLOCK_ERR_REPORT, BLOCK_ERR_IGNORE, BLOCK_ERR_STOP_ENOSPC,
-BLOCK_ERR_STOP_ANY
-} BlockInterfaceErrorAction;
-
 #define BLOCK_SERIAL_STRLEN 20
 
 typedef struct DriveInfo {
@@ -34,8 +29,6 @@ typedef struct DriveInfo {
 int bus;
 int unit;
 QemuOpts *opts;
-BlockInterfaceErrorAction on_read_error;
-BlockInterfaceErrorAction on_write_error;
 char serial[BLOCK_SERIAL_STRLEN + 1];
 QTAILQ_ENTRY(DriveInfo) next;
 } DriveInfo;
@@ -51,9 +44,6 @@ extern int drive_get_max_bus(BlockInterfaceType type);
 extern void drive_uninit(DriveInfo *dinfo);
 extern const char *drive_get_serial(BlockDriverState *bdrv);
 
-extern BlockInterfaceErrorAction drive_get_on_error(
-BlockDriverState *bdrv, int is_read);
-
 extern QemuOpts *drive_add(const char *file, const char *fmt, ...);
 extern DriveInfo *drive_init(QemuOpts *arg, int default_to_scsi,
  int *fatal_error);
diff --git a/hw/ide/core.c b/hw/ide/core.c
index 045d18d..0b3b7c2 100644
--- a/hw/ide/core.c
+++ b/hw/ide/core.c
@@ -481,7 +481,7 @@ void ide_dma_error(IDEState *s)
 s

[Qemu-devel] [Bug 504368] Re: sdl window intermittently scales instead of resizing

[Anthony Liguori]

You can disable scaling by hitting ctrl-alt-u.

What's probably happening is that the window manager is generating an
extraneous scaling event.  I'm going to move this to wishlist as we
should provide better user controls of this behavior.

** Changed in: qemu
   Importance: Undecided => Wishlist

** Changed in: qemu
   Status: New => Triaged

-- 
sdl window intermittently scales instead of resizing
https://bugs.launchpad.net/bugs/504368
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: Triaged
Status in “qemu-kvm” package in Ubuntu: Incomplete

Bug description:
Binary package hint: qemu-kvm

Normally, the SDL output window for a VM resizes to match the VM's resolution.  
However, intermittently the output is instead scaled within the window.  I 
can't seem to find any pattern to when the output is scaled versus when the 
window is resized.  I would prefer that the window be resized as needed to 
display the VM in a 1:1 manner.

ProblemType: Bug
Architecture: amd64
Date: Thu Jan  7 10:30:10 2010
DistroRelease: Ubuntu 9.10
InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release amd64 (20091027)
KvmCmdLine:
 UIDPID  PPID  CSZ   RSS PSR STIME TTY  TIME CMD
 root 27618 1 38 241752 804668 1 10:05 ?00:09:39 /usr/bin/kvm 
-S -M pc-0.11 -cpu qemu32 -m 768 -smp 1 -name win2k3 -uuid 
da414aa0-f18a-7a02-3d1b-1dbf13137bc9 -monitor 
unix:/var/run/libvirt/qemu/win2k3.monitor,server,nowait -localtime -boot c 
-drive file=/media/qpc-devel/testing/win2k3/testing.ovl,if=ide,index=0,boot=on 
-drive 
file=/media/qpc-devel/testing/win2k3/../../isos/en_win_srv_2003_r2_standard_cd1.iso,if=ide,media=cdrom,index=2
 -net nic,macaddr=00:16:3e:d6:f5:60,vlan=0,model=ne2k_pci,name=ne2k_pci.0 -net 
tap,fd=18,vlan=0,name=tap.0 -serial pty -parallel none -usb -usbdevice tablet 
-vga cirrus
 root 28306 1 54 177732 545520 1 10:28 ?00:00:49 /usr/bin/kvm 
-S -M pc-0.11 -cpu qemu32 -m 512 -smp 1 -name win2k -uuid 
153d6125-acb5-70bc-c7d2-bcbf87c5be86 -monitor 
unix:/var/run/libvirt/qemu/win2k.monitor,server,nowait -localtime -boot c 
-drive file=/media/qpc-devel/testing/win2k/testing.ovl,if=ide,index=0,boot=on 
-drive 
file=/media/qpc-devel/testing/win2k/../../isos/windows_2000.iso,if=ide,media=cdrom,index=2
 -net nic,macaddr=68:29:6b:13:50:c6,vlan=0,model=ne2k_pci,name=ne2k_pci.0 -net 
tap,fd=19,vlan=0,name=tap.0 -serial pty -parallel none -usb -usbdevice tablet 
-vga cirrus
NonfreeKernelModules: nvidia
Package: kvm 1:84+dfsg-0ubuntu16+0.11.0+0ubuntu6.3
PccardctlIdent:
 Socket 0:
   no product info available
PccardctlStatus:
 Socket 0:
   no card
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.31-16-generic 
root=UUID=30218f9a-6f90-4eab-9ba5-f54897e842cb ro quiet splash
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-16.53-generic
SourcePackage: qemu-kvm
Uname: Linux 2.6.31-16-generic x86_64
dmi.bios.date: 02/20/2008
dmi.bios.vendor: LENOVO
dmi.bios.version: 7LETB2WW (2.12 )
dmi.board.vendor: LENOVO
dmi.board.version: Not Available
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias: 
dmi:bvnLENOVO:bvr7LETB2WW(2.12):bd02/20/2008:svnLENOVO:pn:pvrThinkPadT61p:rvnLENOVO:rn:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.version: ThinkPad T61p
dmi.sys.vendor: LENOVO

[Qemu-devel] [PATCH 12/13] blockdev: Factor option value parsers out of drive_init()

[Markus Armbruster]

The new functions use qerror_report() to make them usable from
QMP-enabled monitor commands.  They'll appear in a future patch
series.

Signed-off-by: Markus Armbruster 
---
 blockdev.c |  130 +++
 1 files changed, 86 insertions(+), 44 deletions(-)

diff --git a/blockdev.c b/blockdev.c
index 8c51e6e..a1e6394 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -21,6 +21,83 @@
 
 static QTAILQ_HEAD(drivelist, DriveInfo) drives = 
QTAILQ_HEAD_INITIALIZER(drives);
 
+static BlockDriver *parse_block_format(const char *val)
+{
+BlockDriver *drv = bdrv_find_whitelisted_format(val);
+if (!drv) {
+qerror_report(QERR_INVALID_PARAMETER_VALUE,
+  "format", "a block driver name");
+return NULL;
+}
+return drv;
+}
+
+static int parse_block_error_action(const char *val, int is_read)
+{
+if (!val) {
+return is_read ? BLOCK_ERR_REPORT : BLOCK_ERR_STOP_ENOSPC;
+} else if (!strcmp(val, "ignore")) {
+return BLOCK_ERR_IGNORE;
+} else if (!is_read && !strcmp(val, "enospc")) {
+return BLOCK_ERR_STOP_ENOSPC;
+} else if (!strcmp(val, "stop")) {
+return BLOCK_ERR_STOP_ANY;
+} else if (!strcmp(val, "report")) {
+return BLOCK_ERR_REPORT;
+} else {
+if (is_read) {
+qerror_report(QERR_INVALID_PARAMETER_VALUE, "rerror",
+  "ignore, report, stop");
+} else {
+qerror_report(QERR_INVALID_PARAMETER_VALUE, "werror",
+  "enospc, ignore, stop or report");
+}
+return -1;
+}
+}
+
+static int parse_block_cache(const char *val)
+{
+if (!val) {
+return 0;
+} else if (!strcmp(val, "off") || !strcmp(val, "none")) {
+return BDRV_O_NOCACHE;
+} else if (!strcmp(val, "writeback")) {
+return BDRV_O_CACHE_WB;
+} else if (!strcmp(val, "unsafe")) {
+return BDRV_O_CACHE_WB;
+return BDRV_O_NO_FLUSH;
+} else if (!strcmp(val, "writethrough")) {
+return 0;
+} else {
+qerror_report(QERR_INVALID_PARAMETER_VALUE, "cache",
+"none, unsafe, writeback or writethrough");
+return -1;
+}
+}
+
+static int parse_block_aio(const char *val)
+{
+if (!val) {
+return 0;
+#ifdef CONFIG_LINUX_AIO
+} else if (!strcmp(val, "native")) {
+return BDRV_O_NATIVE_AIO;
+#endif
+} else if (!strcmp(val, "threads")) {
+return 0;
+} else {
+qerror_report(QERR_INVALID_PARAMETER_VALUE, "aio",
+#ifdef CONFIG_LINUX_AIO
+  "native or threads"
+#else
+  "threads"
+#endif
+);
+return -1;
+}
+}
+
 static int blockdev_del_dinfo(BlockDriverState *bs)
 {
 DriveInfo *dinfo, *next_dinfo;
@@ -126,23 +203,6 @@ void drive_uninit(DriveInfo *dinfo)
 qemu_free(dinfo);
 }
 
-static int parse_block_error_action(const char *buf, int is_read)
-{
-if (!strcmp(buf, "ignore")) {
-return BLOCK_ERR_IGNORE;
-} else if (!is_read && !strcmp(buf, "enospc")) {
-return BLOCK_ERR_STOP_ENOSPC;
-} else if (!strcmp(buf, "stop")) {
-return BLOCK_ERR_STOP_ANY;
-} else if (!strcmp(buf, "report")) {
-return BLOCK_ERR_REPORT;
-} else {
-fprintf(stderr, "qemu: '%s' invalid %s error action\n",
-buf, is_read ? "read" : "write");
-return -1;
-}
-}
-
 DriveInfo *drive_init(QemuOpts *opts, int default_to_scsi, int *fatal_error)
 {
 const char *buf;
@@ -280,34 +340,17 @@ DriveInfo *drive_init(QemuOpts *opts, int 
default_to_scsi, int *fatal_error)
}
 }
 
-if ((buf = qemu_opt_get(opts, "cache")) != NULL) {
-if (!strcmp(buf, "off") || !strcmp(buf, "none")) {
-bdrv_flags |= BDRV_O_NOCACHE;
-} else if (!strcmp(buf, "writeback")) {
-bdrv_flags |= BDRV_O_CACHE_WB;
-} else if (!strcmp(buf, "unsafe")) {
-bdrv_flags |= BDRV_O_CACHE_WB;
-bdrv_flags |= BDRV_O_NO_FLUSH;
-} else if (!strcmp(buf, "writethrough")) {
-/* this is the default */
-} else {
-   fprintf(stderr, "qemu: invalid cache option\n");
-   return NULL;
-}
+ret = parse_block_cache(qemu_opt_get(opts, "cache"));
+if (ret < 0) {
+return NULL;
 }
+bdrv_flags |= ret;
 
-#ifdef CONFIG_LINUX_AIO
-if ((buf = qemu_opt_get(opts, "aio")) != NULL) {
-if (!strcmp(buf, "native")) {
-bdrv_flags |= BDRV_O_NATIVE_AIO;
-} else if (!strcmp(buf, "threads")) {
-/* this is the default */
-} else {
-   fprintf(stderr, "qemu: invalid aio option\n");
-   return NULL;
-}
+ret = parse_block_aio(qemu_opt_get(opts, "aio"));
+if (ret < 0) {
+return NULL;
 }
-#endif
+bdrv_flags |= ret;
 
 if ((buf = qemu_opt_get(opts, "format")) != NULL) {
if (strcmp(buf, "?") == 0) {
@@ -316,9

[Qemu-devel] [PATCH 03/13] monitor: Make "commit FOO" complain when FOO doesn't exist

[Markus Armbruster]

Signed-off-by: Markus Armbruster 
---
 blockdev.c |6 --
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/blockdev.c b/blockdev.c
index 60c9211..53a0e9c 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -493,9 +493,11 @@ void do_commit(Monitor *mon, const QDict *qdict)
 bdrv_commit_all();
 } else {
 bs = bdrv_find(device);
-if (bs) {
-bdrv_commit(bs);
+if (!bs) {
+qerror_report(QERR_DEVICE_NOT_FOUND, device);
+return;
 }
+bdrv_commit(bs);
 }
 }
 
-- 
1.6.6.1

[Qemu-devel] [PATCH 11/13] qemu-option: New qemu_opt_next(), qemu_opt_name()

[Markus Armbruster]

This is a more flexible alternative to qemu_opt_foreach().

Signed-off-by: Markus Armbruster 
---
 qemu-option.c |   13 +
 qemu-option.h |4 
 2 files changed, 17 insertions(+), 0 deletions(-)

diff --git a/qemu-option.c b/qemu-option.c
index 87e324c..c9f8be4 100644
--- a/qemu-option.c
+++ b/qemu-option.c
@@ -642,6 +642,19 @@ int qemu_opt_set(QemuOpts *opts, const char *name, const 
char *value)
 return 0;
 }
 
+QemuOpt *qemu_opt_next(QemuOpts *opts, QemuOpt *opt)
+{
+if (!opt) {
+return QTAILQ_FIRST(&opts->head);
+}
+return QTAILQ_NEXT(opt, next);
+}
+
+const char *qemu_opt_name(QemuOpt *opt)
+{
+return opt->name;
+}
+
 int qemu_opt_foreach(QemuOpts *opts, qemu_opt_loopfunc func, void *opaque,
  int abort_on_failure)
 {
diff --git a/qemu-option.h b/qemu-option.h
index 9e2406c..13c6a9d 100644
--- a/qemu-option.h
+++ b/qemu-option.h
@@ -109,6 +109,10 @@ int qemu_opt_get_bool(QemuOpts *opts, const char *name, 
int defval);
 uint64_t qemu_opt_get_number(QemuOpts *opts, const char *name, uint64_t 
defval);
 uint64_t qemu_opt_get_size(QemuOpts *opts, const char *name, uint64_t defval);
 int qemu_opt_set(QemuOpts *opts, const char *name, const char *value);
+
+QemuOpt *qemu_opt_next(QemuOpts *opts, QemuOpt *opt);
+const char *qemu_opt_name(QemuOpt *opt);
+
 typedef int (*qemu_opt_loopfunc)(const char *name, const char *value, void 
*opaque);
 int qemu_opt_foreach(QemuOpts *opts, qemu_opt_loopfunc func, void *opaque,
  int abort_on_failure);
-- 
1.6.6.1

[Qemu-devel] [Bug 485243] Re: qemu-system-x86_64 fails to install 32-bit vista and windows 2008

[Joel Schopp]

** Tags added: windows

-- 
qemu-system-x86_64 fails to install 32-bit vista and windows 2008
https://bugs.launchpad.net/bugs/485243
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: New

Bug description:
Hello everyone

qemu-system-x86_64 fails to install 32-bit vista and windows 2008, installation 
stops at initial install screen

steps to reproduce:
1) install qemu frm git clone git://git.savannah.nongnu.org/qemu.git
2) install vista or windows 2008 using it

cmdline used:
/usr/local/bin/qemu-system-x86_64 -drive file=vista.qcow -net 
nic,vlan=0,macaddr=20:20:20:00:00:04,model=rtl8139  -net 
tap,vlan=0,script=/home/yogi/qemu-ifup  -m 6144  --usbdevice tablet -vnc :0 
-enable-kvm  --boot d  --cdrom en_windows_vista_x86_dvd_X12-34293.iso

uname -a
Linux bc1cn9 2.6.30.9-96.fc11.x86_64 #1 SMP Wed Nov 4 00:02:04 EST 2009 x86_64 
x86_64 x86_64 GNU/Linux

Distro: fedora 11

Thx
yogi

[Qemu-devel] [Bug 393531] Re: broken qemu linux-user build on ppc

[Joel Schopp]

** Tags added: powerpc

-- 
broken qemu linux-user build on ppc
https://bugs.launchpad.net/bugs/393531
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: New

Bug description:
kvm-87 build fails on ppc, kvm-86 builds fine.

  https://koji.fedoraproject.org/koji/getfile?taskID=1441042&name=build.log

  gcc -I. -I.. -I/builddir/build/BUILD/qemu-kvm-devel-87/target-i386
  -I/builddir/build/BUILD/qemu-kvm-devel-87 -MMD -MT elfload.o -MP
  -DNEED_CPU_H -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
  -D__user= -I/builddir/build/BUILD/qemu-kvm-devel-87/tcg
  -I/builddir/build/BUILD/qemu-kvm-devel-87/tcg/ppc64
  -I/builddir/build/BUILD/qemu-kvm-devel-87/fpu
  -I/builddir/build/BUILD/qemu-kvm-devel-87/linux-user
  -I/builddir/build/BUILD/qemu-kvm-devel-87/linux-user/i386 -O2 -g -pipe
  -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
  --param=ssp-buffer-size=4 -m64 -mminimal-toc -g -fno-strict-aliasing
  -O2 -Wall -Wundef -Wendif-labels -Wwrite-strings -Wmissing-prototypes
  -Wstrict-prototypes -Wredundant-decls-c -o elfload.o
  /builddir/build/BUILD/qemu-kvm-devel-87/linux-user/elfload.c
  /builddir/build/BUILD/qemu-kvm-devel-87/linux-user/elfload.c:214: error: 
conflicting types for 'elf_greg_t'
  /usr/include/asm/elf.h:123: note: previous declaration of 'elf_greg_t' was 
here
  /builddir/build/BUILD/qemu-kvm-devel-87/linux-user/elfload.c:220: error: 
conflicting types for 'elf_gregset_t'
  /usr/include/asm/elf.h:124: note: previous declaration of 'elf_gregset_t' was 
here
  In file included from 
/builddir/build/BUILD/qemu-kvm-devel-87/linux-user/elfload.c:697:
  ../elf.h:457:1: warning: "R_PPC_NUM" redefined
  In file included from /usr/include/asm/sigcontext.h:13,
   from /usr/include/bits/sigcontext.h:28,
   from /usr/include/signal.h:339,
   from 
/builddir/build/BUILD/qemu-kvm-devel-87/linux-user/qemu.h:4,
   from 
/builddir/build/BUILD/qemu-kvm-devel-87/linux-user/elfload.c:16:
  /usr/include/asm/elf.h:81:1: warning: this is the location of the previous 
definition

also this:

  /builddir/build/BUILD/qemu-kvm-devel-87/linux-user/elfload.c:433: error: 
expected identifier before numeric constant

Problem seems to be that signal.h is pulling in a bunch of ppc kernel headers 
which expose elf_greg_t, R_PPC_* and PPC_FEATURE_*.

I think this what malc may be talking about in this commit:

  http://git.savannah.gnu.org/cgit/qemu.git/commit/?id=a6cc84f49

[Qemu-devel] [PATCH 00/13] New -blockdev to define a host block device

[Markus Armbruster]

I'm working on cleanly separating block device host and guest parts.
I'd like to route all this work through Kevin's block tree.  This is
the first part: new option -blockdev.  Description of 13/13 lists
future work.

Series is based on my "Collect block device code in new blockdev.c",
as amended in v2 3/3.

Markus Armbruster (13):
  block: Move error actions from DriveInfo to BlockDriverState
  block: Decouple block device "commit all" from DriveInfo
  monitor: Make "commit FOO" complain when FOO doesn't exist
  block: New bdrv_next()
  block: Decouple savevm from DriveInfo
  blockdev: Give drives internal linkage
  blockdev: Means to destroy blockdev only if made with drive_init()
  qdev: Decouple qdev_prop_drive from DriveInfo
  blockdev: drive_get_by_id() is no longer used, remove
  qemu-option: New qemu_opts_reset()
  qemu-option: New qemu_opt_next(), qemu_opt_name()
  blockdev: Factor option value parsers out of drive_init()
  blockdev: New -blockdev to define a host block device

 block.c  |   29 
 block.h  |   10 ++
 block_int.h  |7 +-
 blockdev.c   |  355 +-
 blockdev.h   |   22 ++--
 hw/fdc.c |   22 ++--
 hw/ide/core.c|   16 +-
 hw/ide/internal.h|2 +-
 hw/ide/qdev.c|8 +-
 hw/pci-hotplug.c |4 +-
 hw/qdev-properties.c |   39 +-
 hw/qdev.h|6 +-
 hw/s390-virtio.c |2 +-
 hw/scsi-bus.c|8 +-
 hw/scsi-disk.c   |   18 ++--
 hw/scsi-generic.c|5 +-
 hw/scsi.h|2 +-
 hw/usb-msd.c |   10 +-
 hw/virtio-blk.c  |5 +-
 hw/virtio-pci.c  |   12 +--
 qemu-char.c  |7 +-
 qemu-config.c|   38 ++
 qemu-config.h|1 +
 qemu-option.c|   22 +++
 qemu-option.h|5 +
 qemu-options.hx  |   49 +++
 savevm.c |   32 ++---
 vl.c |   29 -
 28 files changed, 557 insertions(+), 208 deletions(-)

[Qemu-devel] [Bug 556424] Re: KVM guest O.S not booting properly when shutdown or restarting Host machine

[Anthony Liguori]

qemu does provide life cycle management of a non-running guest.

For that, I'd recommend a tool such as libvirt.

** Changed in: qemu
   Status: New => Invalid

-- 
KVM guest O.S not booting properly when shutdown or restarting Host machine
https://bugs.launchpad.net/bugs/556424
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: Invalid

Bug description:
Hi ,

I used fedora 12 as a host O.S and created VM using qemu-kvm package.

My guest O.S is ubuntu-server 9.04..

But when i restart host OS then VM does not start automatically ...

So is there any problem with KVM or is it a bug..

My installed Packages are : 

qemu-common-0.11.0-13.fc12.i686
qemu-kvm-0.11.0-13.fc12.i686
qemu-img-0.11.0-13.fc12.i686
gpxe-roms-qemu-0.9.9-1.20091018git.fc12.noarch
qemu-system-x86-0.11.0-13.fc12.i686
qemu-kvm-0.11.0-13.fc12.i686

Plz suggest some solution ASAP.

[Qemu-devel] [Bug 485250] Re: nic e1000 network interface does not work with 32-bit windows 2003r2 with sp2

[Joel Schopp]

** Tags added: windows

-- 
nic e1000 network interface does not work with 32-bit windows 2003r2 with  sp2
https://bugs.launchpad.net/bugs/485250
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: New

Bug description:
nic e1000 network interface does not work with win2k3r2 32bit

e1000 driver in win2k3r2 32bit seems to be broken. The interface is able to
receive ip from the dhcp server, but not able to ping it from any linux guest or
host, but was able to ping it from windows guest.

Running network test, netperf, between the windows guest fails with the message 
"netperf: receive_response: no response received. errno 104 counter 0"

cmdline used:
/usr/local/bin/qemu-system-x86_64 -drive file=win2003r2sp2-32.raw,boot=on -net 
nic,vlan=0,macaddr=20:20:20:00:00:04,model=e1000  -net 
tap,vlan=0,script=/home/yogi/qemu-ifup  -m 2048 -enable-kvm  -usbdevice tablet 
-vnc :1

uname -a
Linux bc1cn9 2.6.30.9-96.fc11.x86_64 #1 SMP Wed Nov 4 00:02:04 EST 2009 x86_64 
x86_64 x86_64 GNU/Linux

Distro: fedora 11

Thx
yogi

[Qemu-devel] [Bug 501141] Re: qemu powerpc target crashes on "hello world"

[Joel Schopp]

** Tags added: powerpc

-- 
qemu powerpc target crashes on "hello world" 
https://bugs.launchpad.net/bugs/501141
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: New

Bug description:
Downloaded qemu and associated PowerPc target support from Fedora repositories 
and it crashed on a simple hello world program (that runs fine on an actual 
PowerPC development board).  So, I downloaded the source to qemu, built it, and 
produced the same crash.  Here is the gdb trace -

[...@localhost POWERPC_TEST]$ gdb qemu-ppc
GNU gdb (GDB) Fedora (7.0-13.fc12)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-redhat-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /usr/local/bin/qemu-ppc...done.
(gdb) set args ./hello
(gdb) run
Starting program: /usr/local/bin/qemu-ppc ./hello

Program received signal SIGSEGV, Segmentation fault.
0x00711c9b in static_code_gen_buffer ()
(gdb) where
#0  0x00711c9b in static_code_gen_buffer ()
#1  0x in ?? ()

Some more information:

Kernel Linux 2.6.31.9-174.fc12.i686
[...@localhost POWERPC_TEST]$ qemu-ppc
qemu-ppc version 0.10.91, Copyright (c) 2003-2008 Fabrice Bellard

[Qemu-devel] [PATCH 04/13] block: New bdrv_next()

[Markus Armbruster]

This is a more flexible alternative to bdrv_iterate().

Signed-off-by: Markus Armbruster 
---
 block.c |8 
 block.h |1 +
 2 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/block.c b/block.c
index 1bef649..f42960c 100644
--- a/block.c
+++ b/block.c
@@ -1330,6 +1330,14 @@ BlockDriverState *bdrv_find(const char *name)
 return NULL;
 }
 
+BlockDriverState *bdrv_next(BlockDriverState *bs)
+{
+if (!bs) {
+return QTAILQ_FIRST(&bdrv_states);
+}
+return QTAILQ_NEXT(bs, list);
+}
+
 void bdrv_iterate(void (*it)(void *opaque, BlockDriverState *bs), void *opaque)
 {
 BlockDriverState *bs;
diff --git a/block.h b/block.h
index 49e3dcf..29993d1 100644
--- a/block.h
+++ b/block.h
@@ -168,6 +168,7 @@ void bdrv_set_change_cb(BlockDriverState *bs,
 void (*change_cb)(void *opaque), void *opaque);
 void bdrv_get_format(BlockDriverState *bs, char *buf, int buf_size);
 BlockDriverState *bdrv_find(const char *name);
+BlockDriverState *bdrv_next(BlockDriverState *bs);
 void bdrv_iterate(void (*it)(void *opaque, BlockDriverState *bs),
   void *opaque);
 int bdrv_is_encrypted(BlockDriverState *bs);
-- 
1.6.6.1

[Qemu-devel] [PATCH v2 3/3] blockdev: Collect block device code in new blockdev.c

[Markus Armbruster]

Anything that moves hundreds of lines out of vl.c can't be all bad.

Signed-off-by: Markus Armbruster 
---
v2: Licence boilerplate

 Makefile.objs|2 +-
 blockdev.c   |  600 ++
 blockdev.h   |   71 ++
 hw/acpi_piix4.c  |1 +
 hw/apb_pci.c |1 +
 hw/device-hotplug.c  |2 -
 hw/fdc.c |1 -
 hw/fdc.h |2 +-
 hw/ide/core.c|2 -
 hw/ide/qdev.c|1 -
 hw/lan9118.c |1 +
 hw/nand.c|3 +-
 hw/omap2.c   |2 +
 hw/onenand.c |3 +-
 hw/parallel.c|1 +
 hw/pc.c  |1 +
 hw/pc_piix.c |1 +
 hw/pci-hotplug.c |2 -
 hw/pcmcia.h  |2 +-
 hw/qdev-properties.c |1 -
 hw/qdev.h|2 +-
 hw/scsi-bus.c|1 -
 hw/scsi-disk.c   |2 +-
 hw/scsi-generic.c|1 -
 hw/serial.c  |1 +
 hw/usb-hid.c |1 +
 hw/usb-msd.c |2 +-
 hw/virtio-blk.c  |2 -
 hw/virtio-pci.c  |1 -
 monitor.c|  104 +-
 qemu-char.c  |1 -
 savevm.c |2 +-
 sysemu.h |   49 
 vl.c |  483 +
 34 files changed, 692 insertions(+), 660 deletions(-)
 create mode 100644 blockdev.c
 create mode 100644 blockdev.h

diff --git a/Makefile.objs b/Makefile.objs
index 9796dcb..54dec26 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -44,7 +44,7 @@ fsdev-obj-$(CONFIG_LINUX) += $(addprefix fsdev/, 
$(fsdev-nested-y))
 # system emulation, i.e. a single QEMU executable should support all
 # CPUs and machines.
 
-common-obj-y = $(block-obj-y)
+common-obj-y = $(block-obj-y) blockdev.o
 common-obj-y += $(net-obj-y)
 common-obj-y += $(qobject-obj-y)
 common-obj-$(CONFIG_LINUX) += $(fsdev-obj-$(CONFIG_LINUX))
diff --git a/blockdev.c b/blockdev.c
new file mode 100644
index 000..bd9783a
--- /dev/null
+++ b/blockdev.c
@@ -0,0 +1,600 @@
+/*
+ * QEMU host block devices
+ *
+ * Copyright (c) 2003-2008 Fabrice Bellard
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or
+ * later.  See the COPYING file in the top-level directory.
+ */
+
+#include "block.h"
+#include "blockdev.h"
+#include "monitor.h"
+#include "qerror.h"
+#include "qemu-option.h"
+#include "qemu-config.h"
+#include "sysemu.h"
+
+struct drivelist drives = QTAILQ_HEAD_INITIALIZER(drives);
+
+QemuOpts *drive_add(const char *file, const char *fmt, ...)
+{
+va_list ap;
+char optstr[1024];
+QemuOpts *opts;
+
+va_start(ap, fmt);
+vsnprintf(optstr, sizeof(optstr), fmt, ap);
+va_end(ap);
+
+opts = qemu_opts_parse(&qemu_drive_opts, optstr, 0);
+if (!opts) {
+return NULL;
+}
+if (file)
+qemu_opt_set(opts, "file", file);
+return opts;
+}
+
+DriveInfo *drive_get(BlockInterfaceType type, int bus, int unit)
+{
+DriveInfo *dinfo;
+
+/* seek interface, bus and unit */
+
+QTAILQ_FOREACH(dinfo, &drives, next) {
+if (dinfo->type == type &&
+   dinfo->bus == bus &&
+   dinfo->unit == unit)
+return dinfo;
+}
+
+return NULL;
+}
+
+DriveInfo *drive_get_by_id(const char *id)
+{
+DriveInfo *dinfo;
+
+QTAILQ_FOREACH(dinfo, &drives, next) {
+if (strcmp(id, dinfo->id))
+continue;
+return dinfo;
+}
+return NULL;
+}
+
+int drive_get_max_bus(BlockInterfaceType type)
+{
+int max_bus;
+DriveInfo *dinfo;
+
+max_bus = -1;
+QTAILQ_FOREACH(dinfo, &drives, next) {
+if(dinfo->type == type &&
+   dinfo->bus > max_bus)
+max_bus = dinfo->bus;
+}
+return max_bus;
+}
+
+const char *drive_get_serial(BlockDriverState *bdrv)
+{
+DriveInfo *dinfo;
+
+QTAILQ_FOREACH(dinfo, &drives, next) {
+if (dinfo->bdrv == bdrv)
+return dinfo->serial;
+}
+
+return "\0";
+}
+
+BlockInterfaceErrorAction drive_get_on_error(
+BlockDriverState *bdrv, int is_read)
+{
+DriveInfo *dinfo;
+
+QTAILQ_FOREACH(dinfo, &drives, next) {
+if (dinfo->bdrv == bdrv)
+return is_read ? dinfo->on_read_error : dinfo->on_write_error;
+}
+
+return is_read ? BLOCK_ERR_REPORT : BLOCK_ERR_STOP_ENOSPC;
+}
+
+static void bdrv_format_print(void *opaque, const char *name)
+{
+fprintf(stderr, " %s", name);
+}
+
+void drive_uninit(DriveInfo *dinfo)
+{
+qemu_opts_del(dinfo->opts);
+bdrv_delete(dinfo->bdrv);
+QTAILQ_REMOVE(&drives, dinfo, next);
+qemu_free(dinfo);
+}
+
+static int parse_block_error_action(const char *buf, int is_read)
+{
+if (!strcmp(buf, "ignore")) {
+return BLOCK_ERR_IGNORE;
+} else if (!is_read && !strcmp(buf, "enospc")) {
+return BLOCK_ERR_STOP_ENOSPC;
+} else if (!strcmp(buf, "stop")) {
+return BLOCK_ERR_STOP_ANY;
+} else if (!strcmp(buf, "report")) {
+return BLOCK_ERR_REPORT;
+   

[Qemu-devel] [Bug 441672] Re: Windos XP BSOD with HP Photosmart usb device attached

[Joel Schopp]

** Tags added: windows

-- 
Windos XP BSOD with HP Photosmart usb device attached
https://bugs.launchpad.net/bugs/441672
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: New

Bug description:
https://bugzilla.redhat.com/show_bug.cgi?id=524723 has all the details of the 
problem.

I was just testing attaching a USB device to see if it really worked, and tried 
my HP Photosmart C5580 All-in-One
printer/scanner, and the Windows XP box then started getting bluescreens and 
crashing at random
(fairly short :-) intervals.

My latest attempt was on a fedora rawhide system with pretty up to date software
(qemu-kvm-0.11.0-2.fc12.x86_64), and the crashes still happen.

A reply to that bugzilla recommended adding this upstream bug, so here it is.

[Qemu-devel] [Bug 524447] Re: virsh save is very slow

[Cole Robinson]

I filed an upstream libvirt bug for the dd block size issue:

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

** Bug watch added: Red Hat Bugzilla #599091
   https://bugzilla.redhat.com/show_bug.cgi?id=599091

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

Status in QEMU: Invalid
Status in “qemu-kvm” package in Ubuntu: Confirmed

Bug description:
As reported here: 
http://www.redhat.com/archives/libvir-list/2009-December/msg00203.html

"virsh save" is very slow - it writes the image at around 1MB/sec on my test 
system.

(I think I saw a bug report for this issue on Fedora's bugzilla, but I can't 
find it now...)

Confirmed under Karmic.

[Qemu-devel] [Bug 485239] Re: Windows 2008 datacenter- 64 bit , installation fails with qemu-system-x86_64 0.11.50

[Joel Schopp]

** Tags added: windows

-- 
Windows 2008 datacenter- 64 bit , installation fails with qemu-system-x86_64 
0.11.50
https://bugs.launchpad.net/bugs/485239
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: New

Bug description:
Installation of Windows 2008 datacenter- 64 bit fails with qemu-system-x86_64. 
Version of qemu-system-x86_64 is 0.11.50. 
The installation source is dvd iso. Just after booting for installation of the 
Windows guest, it hangs for sometime and then the installation crashes with the 
error:

"A problem has been detected and windows has been shut down to prevent damage 
to your computer".

Below is the command used for creating the guest.
/usr/local/bin/qemu-system-x86_64 -cdrom 
/home/en_windows_server_2008_datacenter_enterprise_standard_x64_dvd_X14-26714.iso
 -hda /var/lib/libvirt/images/win2008_dc_64.qcow2 -m 3000 -smp 3 -net nic -net 
tap,script=/home/qemu-ifup-latest -name win2008_dc_64 -vnc :1 &

Disk info of the guest image is as below:
/usr/local/bin/qemu-img info /var/lib/libvirt/images/win2008_dc_64.qcow2
image: /var/lib/libvirt/images/win2008_dc_64.qcow2
file format: qcow2
virtual size: 15G (16106127360 bytes)
disk size: 136K
cluster_size: 65536

This issue is also reproducible with raw image format.

Re: [Qemu-devel] [PATCH 2/8] sparc64: fix missing address masking

[Andreas Färber]

Am 02.06.2010 um 18:10 schrieb Blue Swirl:

On Wed, Jun 2, 2010 at 1:47 PM, Richard Henderson   
wrote:

On 06/01/2010 09:29 PM, Igor Kovalenko wrote:
On Wed, Jun 2, 2010 at 12:44 AM, Richard Henderson  
 wrote:

On 06/01/2010 01:12 PM, Igor V. Kovalenko wrote:

+if ((env->pstate & PS_AM) && is_translating_asi(asi)) {
+addr &= 0xULL;
+}


I suggest that these be written instead as

 if (is_translating_asi(asi)) {
   addr = address_mask(addr);
 }

That should allow you to remove some of the ifdefs.



I think it's better to do debug printf macro trick ...


... with no evidence.  The compiler is happy to optimize away
the entire if statement without having to resort to macros.


... then but I see no real benefit at the moment.


Avoiding ifdefs isn't a benefit?


I agree macros would make the code more tidy, perhaps it could swallow
both the check and the masking. The macro can be empty for Sparc32.


I usually prefer static inline functions over multi-line macros.  
Probably a matter of taste.

[Qemu-devel] [Bug 551220] Re: qemu 0.12.3 stalls under load

[Anthony Liguori]

This has been fixed in 0.12.4.

** Changed in: qemu
   Status: New => Fix Released

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

Status in QEMU: Fix Released

Bug description:
Under load quemu 0.12.3 stalls. The load is created with stress software 
http://weather.ou.edu/~apw/projects/stress/
with this command line:
stress --cpu 32 --io 32 --vm 31 --vm-bytes 64M --hdd 32 --timeout 28800s -v
the guest random stalling, my tests are on 45 qemu virtual machine on
many kind of hardware hosts.
I have two kind of qemu vm with kvm support, theese are the command
lines. First kind:
qemu-system-x86_64 \
-enable-kvm  -cpu qemu32  \
-net nic,model=e1000,macaddr=02:00:00:00:00:01 \
-net tap,ifname=tap0,script=no,downscript=no \
-m 2048 \
-hda /usr/local/data/virtual/vm000/hda.img \
-hdb /usr/local/data/virtual/vm000/hdb.img \
 -vnc :0 \
-monitor unix:/usr/local/data/virtual/vm000/vm000.sock,server,nowait \
-pidfile /usr/local/data/virtual/vm000/vm000.pid \
-no-reboot
Second kind:
qemu-system-x86_64 \
-enable-kvm  -cpu core2duo  \
-net nic,model=e1000,macaddr=02:00:00:00:00:02 \
-net tap,ifname=tap1,script=no,downscript=no \
-m 5120 \
-hda /usr/local/data/virtual/vm001/hda.img \
-hdb /usr/local/data/virtual/vm001/hdb.img \
 -vnc :1 \
-monitor unix:/usr/local/data/virtual/vm001/vm001.sock,server,nowait \
-pidfile /usr/local/data/virtual/vm001/vm001.pid \
-no-reboot

When qemu i stalled keybord, nic and vnc do not answer but 
the qemu process remains active. No logs are generated.
Hosts and guests have Vanilla kernel.

Attached:
cfghost = .config for the hosts
cfgg32  = .config for the guest of type one
cfgg64  = .config for the guest of type two

[Qemu-devel] [Bug 547227] Re: qemu-system-m68k does not accept "notw %d" instruction

[Andreas Färber]

See `qemu-system-m68k -cpu ?`.

QEMU is not targeting it yet, but there's a project:
http://www.gitorious.org/qemu-m68k

-- 
qemu-system-m68k does not accept "notw %d" instruction
https://bugs.launchpad.net/bugs/547227
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: Invalid

Bug description:
The notw and notb instructions does not work with latest version of 
qemu-system-m68k. I've tried both 0.12.3 and the latest git version compiled 
about an hour ago, both running on Arch Linux. The executable fails with the 
following output:
> qemu-system-m68k -nographic -M an5206 -kernel test.elf
qemu: fatal: Illegal instruction: 4640 @ 0006
D0 =    A0 =    F0 =  (   0)
D1 =    A1 =    F1 =  (   0)
D2 =    A2 =    F2 =  (   0)
D3 =    A3 =    F3 =  (   0)
D4 =    A4 =    F4 =  (   0)
D5 =    A5 =    F5 =  (   0)
D6 =    A6 =    F6 =  (   0)
D7 =    A7 =    F7 =  (   0)
PC =    SR = 2700 - FPRESULT =0
zsh: abort  qemu-system-m68k -nographic -M an5206 -kernel test.elf

I've attached the test.elf file, which produces the bug. It contains the 
following:
> m68k-elf-objdump -m 68000 -D test.elf  
test.elf: file format elf32-m68k
Disassembly of section .text:
 :
   0:   4e71nop
   2:   4e71nop
   4:   4e71nop
   6:   4640notw %d0
0008 :
   8:   6000 fffe   braw 8 

It works when removing the not instruction. There might be other non-working 
instructions, I've only tested a few.
Hope you'll get the bug fixed. Thanks.

[Qemu-devel] [Bug 510612] Re: sound broken in qemu 0.12.x

[Joel Schopp]

** Tags added: windows

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

Status in QEMU: New

Bug description:
In qemu 0.12.x there is a jitter when sound is played by guest Windows XP SP2. 
Also there are warnings on console:

alsa: Unexpected state 1
alsa: Unexpected state 1

and qemu tries to eat 100% cpu. According to strace it polls alsa device 
continuously:

futex(0x849e60, FUTEX_WAKE_PRIVATE, 1)  = 1
select(23, [6 10 12 20 22], [18], [], {1, 0}) = 1 (out [18], left {0, 97})
poll([{fd=18, events=POLLOUT|POLLERR|POLLNVAL}], 1, 0) = 1 ([{fd=18, 
revents=POLLOUT|POLLERR}])
write(2, "alsa: "..., 6)= 6
write(2, "Unexpected state 1\n"..., 19) = 19

The bug appears with ac97 and es1370 guest sound devices (i didn't test others).

With OSS host sound driver there are no warnings and consumption of cpu by qemu 
is normal, but jitter in the sound is still there.

[Qemu-devel] [Bug 397572] Re: Resizing the screen crashes QEMU

[Anthony Liguori]

This is fixed in the latest git.

** Changed in: qemu
   Status: New => Fix Released

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

Status in QEMU: Fix Released

Bug description:
Reproducible with today's QEMU tree (HEAD 
d88a76d1d359c1e97fb8921288af87f14247c999).

Steps to reproduce:

1. Start QEMU in pause mode, for example:

$ qemu-system-x86_64 -hda fedora11.img -boot c -S

2. Switch to the Monitor

Ctrl+Alt+2

3. Type 'help'

(qemu) help

4. Using the mouse, try to resize the screen. QEMU will crash (100% 
reproducible)

[Qemu-devel] [Bug 556560] Re: -S doesn't freeze CPU as expected

[Anthony Liguori]

Your command line includes '-boot -s' which appears invalid since boot
requires an argument.  Can you confirm that the problem still occurs
with a proper command line.

** Changed in: qemu
   Status: New => Incomplete

-- 
-S doesn't freeze CPU as expected
https://bugs.launchpad.net/bugs/556560
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: Incomplete

Bug description:
The command used:
qemu-system-arm -nographic -m 256 -M versatileab -kernel 
~/Embedded/working/versatilepb/u
-boot -s -S

Qemu version:
QEMU PC emulator version 0.12.3, Copyright (c) 2003-2008 Fabrice Bellard

Problem description; the version I previously used (0.11.0-rc2) used to freeze 
the CPU upon startup, allowing me to connect with GDB and start debugging and 
loading different images
Here is just starts execution as soon as I hit enter like so...
r...@sameh-laptop:~/# qemu-system-arm -nographic -m 256 -M versatileab -kernel 
~/Embedded/working/versatilepb/u
-boot -s -S


U-Boot 2009.11.1 (Mar 28 2010 - 18:37:25)

DRAM:   0 kB
## Unknown FLASH on Bank 1 - Size = 0x = 0 MB
Flash:  0 kB
*** Warning - bad CRC, using default environment

In:serial
Out:   serial
Err:   serial
Net:   SMC9-0
VersatilePB # 
VersatilePB # 
VersatilePB # QEMU: Terminated

[Qemu-devel] [Bug 586175] Re: Windows XP/2003 doesn't boot

[Joel Schopp]

** Tags added: windows

-- 
Windows XP/2003 doesn't boot
https://bugs.launchpad.net/bugs/586175
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: New
Status in Fedora: Unknown

Bug description:
Hello everyone,

my qemu doesn't boot any Windows XP/2003 installations if I try to boot the 
image.
If I boot the install cd first, it's boot manager counts down and triggers the 
boot on it's own. That's kinda stupid.

I'm using libvirt, but even by a simple
> qemu-kvm -drive file=image.img,media=disk,if=ide,boot=on
it won't boot. Qemu hangs at the message "Booting from Hard Disk..."

I'm using qemu-kvm-0.12.4 with SeaBIOS 0.5.1 on Gentoo (No-Multilib and AMD64). 
It's a server, that means I'm using VNC as the primary graphic output but i 
don't think it should be an issue.

[Qemu-devel] [Bug 529008] Re: Should emulate /proc/cpuinfo

[DaveHansen]

If you're chroot'ing anyway, then you should have privileged access.
You could probably do this entirely in userspace, without even specially
intercepting the syscalls.  When you set up the chroot, just get a copy
of how you want cpuinfo to look, and bind mount it on top of the
existing cpuinfo file:

r...@nimitz:~# egrep cache.size\|^processor /proc/cpuinfo 
processor   : 0
cache size  : 4096 KB
processor   : 1
cache size  : 4096 KB
r...@nimitz:~# cat /proc/cpuinfo | perl -pe 's/4096 KB/8192 KB/g' > cpuinfo.lie
r...@nimitz:~# mount --bind cpuinfo.lie /proc/cpuinfo 
r...@nimitz:~# egrep cache.size\|^processor /proc/cpuinfo 
processor   : 0
cache size  : 8192 KB
processor   : 1
cache size  : 8192 KB

Would that work?

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

Status in QEMU: New
Status in “qemu-kvm” package in Ubuntu: Confirmed

Bug description:
Binary package hint: qemu-kvm

qemu should emulate /proc/cpuinfo contents as some apps parse it to find out 
which CPU they are running on.

[Qemu-devel] [Bug 485251] Re: qemu 0.11.50: Guest boot failed when the drive interface is scsi

[Anthony Liguori]

QEMU does not support booting from SCSI.  0.13.0 will add support for
booting from virtio in addition to IDE.

** Changed in: qemu
   Status: New => Invalid

-- 
qemu 0.11.50: Guest boot failed when the drive interface is scsi
https://bugs.launchpad.net/bugs/485251
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in Kernel Virtual Machine: New
Status in QEMU: Invalid

Bug description:
When tried to boot the rhel5.4 guest with the below mentioned options,

/usr/local/bin/qemu-system-x86_64 -drive file=test_rhel5.4.raw,if=scsi -m 512 
-enable-kvm

Boot failed with following error,
-
Booting from Hard Disk...
Boot failed: could not read the boot disk

Booting from Floppy...
Boot failed: could not read the boot disk

Booting from CD-Rom...
Boot failed: could not read from CDROM (code 0003)
No bootable device.
--

This guest was installed with  following options,
# /usr/local/bin/qemu-system-x86_64 -drive file=test_rhel5.4.raw,if=scsi -net 
nic,model=rtl8139 -cdrom /var/RHEL5.4-Server-20090819.0-i386-DVD.iso -m 512 
-enable-kvm
Warning: vlan 0 is not connected to host network
lsi_scsi: error: ORDERED queue not implemented
lsi_scsi: error: ORDERED queue not implemented
lsi_scsi: error: ORDERED queue not implemented
lsi_scsi: error: ORDERED queue not implemented
lsi_scsi: error: ORDERED queue not implemented
lsi_scsi: error: ORDERED queue not implemented
lsi_scsi: error: ORDERED queue not implemented
lsi_scsi: error: ORDERED queue not implemented

# uname -a
Linux mx3650b.in.ibm.com 2.6.31.5-127.fc12.x86_64 #1 SMP Sat Nov 7 21:11:14 EST 
2009 x86_64 x86_64 x86_64 GNU/Linux

Machine: x3650

Steps to reproduce:
1. Install a guest with scsi drive interface
2. After the install boot the guest with scsi interface. We can see the above 
mentioned boot failure.

[Qemu-devel] [Bug 524447] Re: virsh save is very slow

[Anthony Liguori]

This actually turns out to be related to dd's default block size.  By
default, dd uses a block size of 512.  The effect of this is that qemu
fills the pipe buffer very quickly because dd just is submitting very
small requests (that will require a RMW).

If you set an explict block size with dd (via bs=1M), you'll notice a
significant improvement in throughput.

So I think this turns out to be a libvirt issue, not a qemu issue.

** Changed in: qemu
   Status: Confirmed => Invalid

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

Status in QEMU: Invalid
Status in “qemu-kvm” package in Ubuntu: Confirmed

Bug description:
As reported here: 
http://www.redhat.com/archives/libvir-list/2009-December/msg00203.html

"virsh save" is very slow - it writes the image at around 1MB/sec on my test 
system.

(I think I saw a bug report for this issue on Fedora's bugzilla, but I can't 
find it now...)

Confirmed under Karmic.

[Qemu-devel] [Bug 449958] Re: qemu is unable to boot from virtio drives

[Anthony Liguori]

The latest git has a version of SeaBIOS that supports booting from
virtio.  This will be included in the 0.13 release.

** Changed in: qemu
   Status: Confirmed => Fix Committed

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

Status in QEMU: Fix Committed

Bug description:
This makes the virtio drives feature essentially useless for me ...
I don't think I have to provide any more information here, right?

[Qemu-devel] Re: [PATCH 3/3] blockdev: Collect block device code in new blockdev.c

[Markus Armbruster]

Kevin Wolf  writes:

> Am 02.06.2010 13:31, schrieb Markus Armbruster:
>> Anything that moves hundreds of lines out of vl.c can't be all bad.
>> 
>> Signed-off-by: Markus Armbruster 
>
> New files need a license header, otherwise it looks ok.
>
> I have applied this patch (and the other ones, too) to the block branch
> anyway to avoid conflicts with other people basing their patches on that
> branch. However, it requires a v2 before I can propose this to be merged
> into master.

vl.c has "Copyright (c) 2003-2008 Fabrice Bellard".  monitor.c has
"Copyright (c) 2003-2004 Fabrice Bellard".  Would the following header
do?

/*
 * QEMU host block devices
 *
 * Copyright (c) 2003-2008 Fabrice Bellard
 *
 * This work is licensed under the terms of the GNU GPL, version 2 or
 * later.  See the COPYING file in the top-level directory.
 */

Re: [Qemu-devel] [PATCH 5/8] sparc64: use symbolic name for MMU index

[Blue Swirl]

On Tue, Jun 1, 2010 at 8:12 PM, Igor V. Kovalenko
 wrote:
> From: Igor V. Kovalenko 
>
> Signed-off-by: Igor V. Kovalenko 
> ---
>  target-sparc/op_helper.c |   28 
>  1 files changed, 16 insertions(+), 12 deletions(-)
>
> diff --git a/target-sparc/op_helper.c b/target-sparc/op_helper.c
> index f5e153d..b9af52b 100644
> --- a/target-sparc/op_helper.c
> +++ b/target-sparc/op_helper.c
> @@ -3322,18 +3322,19 @@ void helper_stdf(target_ulong addr, int mem_idx)
>     helper_check_align(addr, 7);
>  #if !defined(CONFIG_USER_ONLY)
>     switch (mem_idx) {
> -    case 0:
> +    case MMU_USER_IDX:
>         stfq_user(addr, DT0);
>         break;
> -    case 1:
> +    case MMU_KERNEL_IDX:
>         stfq_kernel(addr, DT0);
>         break;
>  #ifdef TARGET_SPARC64
> -    case 2:
> +    case MMU_HYPV_IDX:
>         stfq_hypv(addr, DT0);
>         break;
>  #endif
>     default:
> +        printf("helper_stdf: need to check MMU idx %d\n", mem_idx);

Are these going to be useful or just leftover debugging?

>         break;
>     }
>  #else
> @@ -3346,18 +3347,19 @@ void helper_lddf(target_ulong addr, int mem_idx)
>     helper_check_align(addr, 7);
>  #if !defined(CONFIG_USER_ONLY)
>     switch (mem_idx) {
> -    case 0:
> +    case MMU_USER_IDX:
>         DT0 = ldfq_user(addr);
>         break;
> -    case 1:
> +    case MMU_KERNEL_IDX:
>         DT0 = ldfq_kernel(addr);
>         break;
>  #ifdef TARGET_SPARC64
> -    case 2:
> +    case MMU_HYPV_IDX:
>         DT0 = ldfq_hypv(addr);
>         break;
>  #endif
>     default:
> +        printf("helper_stdf: need to check MMU idx %d\n", mem_idx);

The function name is not correct for this and other cases below.

>         break;
>     }
>  #else
> @@ -3373,24 +3375,25 @@ void helper_ldqf(target_ulong addr, int mem_idx)
>     helper_check_align(addr, 7);
>  #if !defined(CONFIG_USER_ONLY)
>     switch (mem_idx) {
> -    case 0:
> +    case MMU_USER_IDX:
>         u.ll.upper = ldq_user(addr);
>         u.ll.lower = ldq_user(addr + 8);
>         QT0 = u.q;
>         break;
> -    case 1:
> +    case MMU_KERNEL_IDX:
>         u.ll.upper = ldq_kernel(addr);
>         u.ll.lower = ldq_kernel(addr + 8);
>         QT0 = u.q;
>         break;
>  #ifdef TARGET_SPARC64
> -    case 2:
> +    case MMU_HYPV_IDX:
>         u.ll.upper = ldq_hypv(addr);
>         u.ll.lower = ldq_hypv(addr + 8);
>         QT0 = u.q;
>         break;
>  #endif
>     default:
> +        printf("helper_stdf: need to check MMU idx %d\n", mem_idx);
>         break;
>     }
>  #else
> @@ -3408,24 +3411,25 @@ void helper_stqf(target_ulong addr, int mem_idx)
>     helper_check_align(addr, 7);
>  #if !defined(CONFIG_USER_ONLY)
>     switch (mem_idx) {
> -    case 0:
> +    case MMU_USER_IDX:
>         u.q = QT0;
>         stq_user(addr, u.ll.upper);
>         stq_user(addr + 8, u.ll.lower);
>         break;
> -    case 1:
> +    case MMU_KERNEL_IDX:
>         u.q = QT0;
>         stq_kernel(addr, u.ll.upper);
>         stq_kernel(addr + 8, u.ll.lower);
>         break;
>  #ifdef TARGET_SPARC64
> -    case 2:
> +    case MMU_HYPV_IDX:
>         u.q = QT0;
>         stq_hypv(addr, u.ll.upper);
>         stq_hypv(addr + 8, u.ll.lower);
>         break;
>  #endif
>     default:
> +        printf("helper_stdf: need to check MMU idx %d\n", mem_idx);
>         break;
>     }
>  #else
>
>
>

Re: [Qemu-devel] [PATCH 2/8] sparc64: fix missing address masking

[Blue Swirl]

On Wed, Jun 2, 2010 at 1:47 PM, Richard Henderson  wrote:
> On 06/01/2010 09:29 PM, Igor Kovalenko wrote:
>> On Wed, Jun 2, 2010 at 12:44 AM, Richard Henderson  wrote:
>>> On 06/01/2010 01:12 PM, Igor V. Kovalenko wrote:
 +    if ((env->pstate & PS_AM) && is_translating_asi(asi)) {
 +        addr &= 0xULL;
 +    }
>>>
>>> I suggest that these be written instead as
>>>
>>>  if (is_translating_asi(asi)) {
>>>    addr = address_mask(addr);
>>>  }
>>>
>>> That should allow you to remove some of the ifdefs.
>>
>> All address masking is done for sparc64 target only, sparc32 does not
>> have the notion of translating asi.
>
> Of course I know that.
>
>> I think it's better to do debug printf macro trick ...
>
> ... with no evidence.  The compiler is happy to optimize away
> the entire if statement without having to resort to macros.
>
>> ... then but I see no real benefit at the moment.
>
> Avoiding ifdefs isn't a benefit?

I agree macros would make the code more tidy, perhaps it could swallow
both the check and the masking. The macro can be empty for Sparc32.

Re: [Qemu-devel] [RFC] [PATCH 0/5] Add horizontal wheel support to mice, where possible

[Brad Jorsch]

On Wed, Jun 02, 2010 at 08:30:11AM -0500, Anthony Liguori wrote:
> 
> I think instead of adding an additional parameter for horizontal
> wheel, we should look at making the API capable of
> accepting/generating arbitrary button presses.
> 
> Really, we should just drop dz and treat vertical wheel as two
> button presses within button_state.  Likewise, horizontal wheel
> should just be two additional bits within button_state.

Wheel handling in cocoa.m and in monitor.c may supply a delta greater
than 1 for the mouse wheels. Those front-ends would have to translate
those deltas into a series of press+release events. Then the emulated
devices (at least the PS/2 and USB devices) would have to sum the
designated button presses for outputting again as wheel data.

If that's the way we want to go, I can rework the patch easily enough.

[Qemu-devel] Re: [PATCH 00/14] Block-related fixes and cleanups

[Kevin Wolf]

Am 01.06.2010 20:32, schrieb Markus Armbruster:
> I'm working on cleanly separating block device host and guest parts.
> I'd like to route all this work through Kevin's block tree.  This is
> just preliminaries.
> 
> v2: Don't break IDE serial
> 
> Markus Armbruster (14):
>   blockdev: Belatedly remove MAX_DRIVES
>   blockdev: Belatedly remove driveopts
>   usb: Remove unused usb_device_add() parameter is_hotplug
>   ide: Remove useless IDEDeviceInfo members unit, drive
>   ide: Remove redundant IDEState member conf
>   ide: Split ide_init1() off ide_init2()
>   ide: Change ide_init_drive() to require valid dinfo argument
>   ide: Split non-qdev code off ide_init2()
>   qdev: New qdev_prop_set_string()
>   qdev: Don't leak string property value on hot unplug
>   ide: Turn drive serial into a qdev property ide-drive.serial
>   ide: Fix info qtree for ide-drive.ver
>   scsi: Turn drive serial into a qdev property scsi-disk.serial
>   scsi: Fix info qtree for scsi-disk.ver

Thanks, applied all to the block branch.

Kevin

[Qemu-devel] Re: [PATCH 3/3] blockdev: Collect block device code in new blockdev.c

[Kevin Wolf]

Am 02.06.2010 13:31, schrieb Markus Armbruster:
> Anything that moves hundreds of lines out of vl.c can't be all bad.
> 
> Signed-off-by: Markus Armbruster 

New files need a license header, otherwise it looks ok.

I have applied this patch (and the other ones, too) to the block branch
anyway to avoid conflicts with other people basing their patches on that
branch. However, it requires a v2 before I can propose this to be merged
into master.

Kevin

Re: [Qemu-devel] [Bug 534973] Re: qemu-system-ppc segfaults when booting from Debian lenny netinst image

[Aurelien Jarno]

Natalia Portillo a écrit :
> I confirm this is happening in QEMU 0.12.4.

Are you sure about that? While this bug is clearly present in 0.12.3 as
reported, it has been fixed in 0.12.4, in commit
18a21890ff2b24bc7f0cdc3807e2fb65e014522b

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net

[Qemu-devel] [PATCH-V2] [virtio-9p] Flush the debug message out to the log file.

[Venkateswararao Jujjuri (JV)]

This patch fluesh the debug messages to the log file  at the end of each
debug message.

Changes from V1:
Used fflush instead fseek for the flush.

Signed-off-by: Venkateswararao Jujjuri 
---
 hw/virtio-9p-debug.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/hw/virtio-9p-debug.c b/hw/virtio-9p-debug.c
index 2fb2673..e4ab4bc 100644
--- a/hw/virtio-9p-debug.c
+++ b/hw/virtio-9p-debug.c
@@ -481,4 +481,6 @@ void pprint_pdu(V9fsPDU *pdu)
 }
 
 fprintf(llogfile, ")\n");
+/* Flush the log message out */
+fflush(llogfile);
 }
-- 
1.6.5.2

[Qemu-devel] [Bug 588731] Re: PXE boot not working

[Jan Smets]

using latest git

dhcp-3.0.1-58.EL4

with configuration:

 host   { filename "boot.pxe"; hardware ethernet
02:5A:3B:27:00:A1; fixed-address 10.201.1.161; }

#
## server config
#
server-identifier   a.b.c.d;
server-name "some-name";
default-lease-time  600;
max-lease-time  1200;
ddns-update-style   ad-hoc;
#log-facilitylocal6;

allow booting;
allow bootp;


Latest GIT -> git clone http://git.kernel.org/pub/scm/virt/kvm/qemu-
kvm.git

configured with options


./configure --target-list=x86_64-softmmu --enable-gprof --enable-debug  
--enable-linux-aio  --enable-profiler --with-kvm-trace 

Install prefix/usr/local
BIOS directory/usr/local/share/qemu
binary directory  /usr/local/bin
Manual directory  /usr/local/share/man
ELF interp prefix /usr/gnemul/qemu-%M
Source path   /root/qemu-test/qemu-kvm
C compilergcc
Host C compiler   gcc
CFLAGS-g
QEMU_CFLAGS   -Werror -m64 -fstack-protector-all -Wold-style-definition 
-Wold-style-declaration -I. -I$(SRC_PATH) -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE 
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -W
strict-prototypes -Wredundant-decls -Wall -Wundef -Wendif-labels 
-Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing
LDFLAGS   -Wl,--warn-common -m64 -g
make  make
install   install
host CPU  x86_64
host big endian   no
target list   x86_64-softmmu
tcg debug enabled yes
Mon debug enabled yes
gprof enabled yes
sparse enabledno
strip binariesno
profiler  yes
static build  no
-Werror enabled   yes
SDL support   yes
curses supportyes
curl support  yes
check support no
mingw32 support   no
Audio drivers oss
Extra audio cards ac97 es1370 sb16
Block whitelist
Mixer emulation   no
VNC TLS support   yes
VNC SASL support  yes
xen support   no
CPU emulation yes
brlapi supportno
bluez  supportno
Documentation yes
NPTL support  yes
GUEST_BASEyes
PIE user targets  no
vde support   no
IO thread no
Linux AIO support yes
Install blobs yes
KVM support   yes
KVM PIT support   yes
KVM device assig. yes
KVM trace support yes
fdt support   no
preadv supportyes
fdatasync yes
uuid support  yes
vhost-net support yes

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

Status in QEMU: Incomplete

Bug description:
/root/qemu-test/qemu-kvm/x86_64-softmmu/qemu-system-x86_64 -net 
tap,vlan=0,name=tap.0 -boot n -net 
nic,macaddr=$MAC,vlan=0,model=e1000,name=e1000.0 -chardev 
socket,id=monitor,host=0.0.0.0,port=$MONITORPORT,telnet,server,nowait -monitor 
chardev:monitor



net0: 02:5a:3b:27:00:a1 on PCI00:03.0 (open)
   
 [Link:up, TX:0 TXE:0 RX:0 RXE:0]   
  
 DHCP (net0 02:5a:3b:27:00:a1) Connection timed out 
(0x4c106035)
 No more network devices



 
No bootable device. 



After doing a system_reset 

net0: 02:5a:3b:27:00:a1 on PCI00:03.0 (open)
   
 [Link:up, TX:0 TXE:0 RX:0 RXE:0]   
  
DHCP (net0 02:5a:3b:27:00:a1) ok
   
net0: 10.201.1.161/255.0.0.0 gw 10.0.0.1
   
Booting from filename "boot.pxe"
  
tftp://x.x.x./boot.pxe.. ok  


And it magaically works.

using HEAD.

[Qemu-devel] [Bug 524447] Re: virsh save is very slow

[Anthony Liguori]

I can reproduce with:

x86_64-softmmu/qemu-system-x86_64 -hda ~/images/linux.img -snapshot -m 4G 
-monitor stdio -enable-kvm
QEMU 0.12.50 monitor - type 'help' for more information
(qemu) migrate_set_speed 1G
(qemu) migrate -d "exec:dd of=foo.img"

On:

commit d9b73e47a3d596c5b33802597ec5bd91ef3348e2
Author: Corentin Chary 
Date:   Tue Jun 1 23:05:44 2010 +0200

vnc: add missing target for vnc-encodings-*.o


Even though the rate limit is set at 1G, we're not getting more than 1-2MB/s of 
migration traffic.

** Changed in: qemu
   Status: New => Confirmed

** Changed in: qemu
 Assignee: (unassigned) => Anthony Liguori (anthony-codemonkey)

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

Status in QEMU: Confirmed
Status in “qemu-kvm” package in Ubuntu: Confirmed

Bug description:
As reported here: 
http://www.redhat.com/archives/libvir-list/2009-December/msg00203.html

"virsh save" is very slow - it writes the image at around 1MB/sec on my test 
system.

(I think I saw a bug report for this issue on Fedora's bugzilla, but I can't 
find it now...)

Confirmed under Karmic.

Re: [Qemu-devel] [PATCH] Name the default PCI bus "pci.0" on all architectures

[Paul Brook]

> Paul Brook  writes:
> >> The system emulators for each arch are using inconsistent
> >> naming for the default PCI bus "pci" vs "pci.0". Since it
> >> is conceivable we'll have multiple PCI buses in the future
> >> standardize on "pci.0" for all architectures. This ensures
> >> mgmt apps can rely on a name when assigning PCI devices an
> >> address on the bus using eg '-device e1000,bus=pci.0,addr=3'
> > 
> > No. Bus names are local to the parent device.  None of the host bridges
> > support multiple bridges, so the ".0" suffix makes no sense.  The parent
> > device has no idea whether it owns the "default" pci bus or not.
> > If you have multiple PCI busses then you can identify them by the device
> > path.
> 
> From qbus_create_inplace():
> 
> if (name) {
> /* use supplied name */
> bus->name = qemu_strdup(name);
> } else if (parent && parent->id) {
> /* parent device has id -> use it for bus name */
> len = strlen(parent->id) + 16;
> buf = qemu_malloc(len);
> snprintf(buf, len, "%s.%d", parent->id, parent->num_child_bus);
> bus->name = buf;
> } else {
> /* no id -> use lowercase bus type for bus name */
> len = strlen(info->name) + 16;
> buf = qemu_malloc(len);
> len = snprintf(buf, len, "%s.%d", info->name,
>parent ? parent->num_child_bus : 0);
> for (i = 0; i < len; i++)
> buf[i] = qemu_tolower(buf[i]);
> bus->name = buf;
> }
> 
> If appending ".0" really makes no sense when the device has just one
> bus, then we shouldn't append it in cases 2 & 3.

IMO the code you quote is completely bogus.  All devices should specify names 
for their child busses, failure to do so is a bug.

These bus names are local to the parent device. Trying to use them as global 
identifiers is just plain wrong.  A given device [type] should always have the 
same set of properties/child busses regardless of where it occurs in the 
device tree.
Using a single counter for all busses is also wrong. The order of bus creation 
is a device implementation detail, under no circumstances should it be part of 
the user visible API.  Consider a device that has both a PCI and I2C bus. It 
makes no sense to call there pci.0 and i2c.1.

Paul

Re: [Qemu-devel] [PATCH] Name the default PCI bus "pci.0" on all architectures

[Paul Brook]

> The problem is that the ID names of default devices in machines are ABI
> sensitive. Management apps need to know what the ID of these default
> devices are. The x86 machines have already used 'pci.0' as their name
> in the previous 0.12 release and libvirt is using this naming. We later
> discovered many non-x86 archs have a name of just 'pci'. We need a single
> consistent naming across all arches, hence this patch whcih standardizes
> on 'pci.0'. 

I think you'll find x86 qdev conversion is both incomplete and incorrect.  
Specifically i440fx_int breaks several abstraction boundaries.  I raised this 
issue at the time, but was told this was only temporary, and would be fixed. 
x86 should be made to match the arches that have been converted properly.

> The '.N' convention is used extensively in QEMU and is more
> futureproof as & when QEMU supports multiple buses, without requiring
> apps to use the more verbose device paths to ensure uniquness.

I disagree.  Anything that depends on device creation order is fundamentally 
broken. If you want to create globally unique user-friendly tags for devices 
or busses then that is a completely different problem, and should be done via 
explicit aliases. qemu currently has no concept of a "default bus".

Paul

[Qemu-devel] [Bug 588735] Re: Quit command not working

[Anthony Liguori]

I tried this exact syntax and could not reproduce.  What version of qemu
are you using?

** Changed in: qemu
   Status: New => Incomplete

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

Status in QEMU: Incomplete

Bug description:
Qemu strace



rt_sigreturn(0x1b)  = 56
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, 
child_tidptr=0x7f6fddecbad0) = ? ERESTARTNOINTR (To be restarted)
--- SIGPROF (Profiling timer expired) @ 0 (0) ---
rt_sigreturn(0x1b)  = 56


started with :

[r...@virtual-test ~]# 
/root/qemu-test/qemu-kvm/x86_64-softmmu/qemu-system-x86_64 -net 
tap,vlan=0,name=tap.0 -chardev 
socket,id=serial0,host=0.0.0.0,port=$CONSOLEPORT,telnet,server,nowait -serial 
chardev:serial0 -hda hda -hdb hdb -hdc hdc -hdd hdd -fda fd0 -fdb fd1 -chardev 
socket,id=monitor,host=0.0.0.0,port=$MONITORPORT,telnet,server,nowait -monitor 
chardev:monitor -net nic,macaddr=$MAC,vlan=0,model=e1000,name=e1000.0 -M pc -m 
4096

when removing -m 4096, the quit command works.

but I think its a combination of different args that causes the problem.

[Qemu-devel] [Bug 588735] Re: Quit command not working

[Anthony Liguori]

how much memory do you have in the host?

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

Status in QEMU: Incomplete

Bug description:
Qemu strace



rt_sigreturn(0x1b)  = 56
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, 
child_tidptr=0x7f6fddecbad0) = ? ERESTARTNOINTR (To be restarted)
--- SIGPROF (Profiling timer expired) @ 0 (0) ---
rt_sigreturn(0x1b)  = 56


started with :

[r...@virtual-test ~]# 
/root/qemu-test/qemu-kvm/x86_64-softmmu/qemu-system-x86_64 -net 
tap,vlan=0,name=tap.0 -chardev 
socket,id=serial0,host=0.0.0.0,port=$CONSOLEPORT,telnet,server,nowait -serial 
chardev:serial0 -hda hda -hdb hdb -hdc hdc -hdd hdd -fda fd0 -fdb fd1 -chardev 
socket,id=monitor,host=0.0.0.0,port=$MONITORPORT,telnet,server,nowait -monitor 
chardev:monitor -net nic,macaddr=$MAC,vlan=0,model=e1000,name=e1000.0 -M pc -m 
4096

when removing -m 4096, the quit command works.

but I think its a combination of different args that causes the problem.

Re: [Qemu-devel] [PATCH] qbus: fix memory leak in qbus_free()

[Markus Armbruster]

Isaku Yamahata  writes:

> BusState::name is allocated in qbus_create_inplace().
> So it should be freed by qbus_free().

Correct.

> Signed-off-by: Isaku Yamahata 
> ---
>  hw/qdev.c |1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/hw/qdev.c b/hw/qdev.c
> index af17486..2845af5 100644
> --- a/hw/qdev.c
> +++ b/hw/qdev.c
> @@ -700,6 +700,7 @@ void qbus_free(BusState *bus)
>  QLIST_REMOVE(bus, sibling);
>  bus->parent->num_child_bus--;
>  }
> +qemu_free((void*)bus->name);
>  if (bus->qdev_allocated) {
>  qemu_free(bus);
>  }

Ugly, superfluous cast to void *.

Thanks!

[Qemu-devel] [Bug 588731] Re: PXE boot not working

[Anthony Liguori]

I can't reproduce this.  I'm using:

commit d9b73e47a3d596c5b33802597ec5bd91ef3348e2
Author: Corentin Chary 
Date:   Tue Jun 1 23:05:44 2010 +0200

vnc: add missing target for vnc-encodings-*.o

I'm using the command:

sudo x86_64-softmmu/qemu-system-x86_64 -net tap,vlan=0,name=tap.0 -boot
n -net nic,vlan=0,model=e1000,name=e1000.0 -chardev
socket,id=monitor,host=0.0.0.0,port=1024,telnet,server,nowait -monitor
chardev:monitor

The DHCP server I'm using is dnsmasq and it pxe boots as expected.  I've
also confirmed that pxe boot is still functional after a system_reset.

Please include information about the exact version of qemu that you are
using and the DHCP server that is configured on your network.  Please
also try to reproduce with the latest git.

** Changed in: qemu
   Status: New => Incomplete

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

Status in QEMU: Incomplete

Bug description:
/root/qemu-test/qemu-kvm/x86_64-softmmu/qemu-system-x86_64 -net 
tap,vlan=0,name=tap.0 -boot n -net 
nic,macaddr=$MAC,vlan=0,model=e1000,name=e1000.0 -chardev 
socket,id=monitor,host=0.0.0.0,port=$MONITORPORT,telnet,server,nowait -monitor 
chardev:monitor



net0: 02:5a:3b:27:00:a1 on PCI00:03.0 (open)
   
 [Link:up, TX:0 TXE:0 RX:0 RXE:0]   
  
 DHCP (net0 02:5a:3b:27:00:a1) Connection timed out 
(0x4c106035)
 No more network devices



 
No bootable device. 



After doing a system_reset 

net0: 02:5a:3b:27:00:a1 on PCI00:03.0 (open)
   
 [Link:up, TX:0 TXE:0 RX:0 RXE:0]   
  
DHCP (net0 02:5a:3b:27:00:a1) ok
   
net0: 10.201.1.161/255.0.0.0 gw 10.0.0.1
   
Booting from filename "boot.pxe"
  
tftp://x.x.x./boot.pxe.. ok  


And it magaically works.

using HEAD.

Re: [Qemu-devel] [PATCH 3/9] QMP: First half of the new argument checking code

[Markus Armbruster]

Luiz Capitulino  writes:

> On Wed, 02 Jun 2010 09:22:40 +0200
> Markus Armbruster  wrote:
[...]
>> Higher order functions rock.  But C is too static and limited for
>> elegant use of higher order functions.  Means to construct loops are
>> usually more convenient to use, and yield more readable code.
>> 
>> I find the use of qdict_iter() here quite tortuous: you define a
>> separate iterator function, which you can't put next to its use.  You
>> need to jump back and forth between the two places to understand what
>> the loop does.  You define a special data structure just to pass
>> arguments and results through qdict_iter().
>> 
>> Let me try to sketch the alternative:
>> 
>> static int qmp_check_client_args(const mon_cmd_t *cmd, QDict *client_args)
>> {
>> QDict *cmd_args;
>> int res = 0, skip = 0;
>> QDictEntry *ent;
>> 
>> cmd_args = qdict_from_args_type(cmd->args_type);
>> 
>> for (ent = qdict_first_entry(cmd_args); ent; ent = qdict_next_entry(ent) 
>> {
>
>  I thought about doing something similar a while ago, but I dislike it for
> two reasons:
>
>   1. I don't think the notion of 'first' and 'next' apply for dicts. One may
>  argue that the iterator has the same issue, but it's implicit

Does the dirt under the carpet exist when nobody looks?

Iterating over an unordered collection necessarily creates an order
where none was before.  It's the nature of iteration.  Dressing it up as
iterator + function argument doesn't change the basic fact[*].

>   2. QDictEntry shouldn't be part of the public interface, we should be
>  using forward declaration there

No problem, just add qdict_ent_key() and qdict_ent_value(), and use them
instead of operator ->.

>  (although I'm not sure whether this is
>  possible with a typedef)

In qdict.h: typedef struct QDictEntry QDictEntry;

In qdict.c: struct QDictEntry { ... };

>  I think having qdict_foreach() will improve things already.

I doubt it, but try and see :)


[*] Unless the iterator gets fancy and calls the function argument
concurrently.  Hardly an option in primitive old C.

[Qemu-devel] [Bug 588748] Re: QEMU fails to boot DR DOS Plus since 0.6.1

[Roy Tam]

** Patch added: "Following patch partially reverts that commit and makes 
DOSPlus booting in QEMU again."
   http://launchpadlibrarian.net/49557998/serial-ier-fix.patch

-- 
QEMU fails to boot DR DOS Plus since 0.6.1
https://bugs.launchpad.net/bugs/588748
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: New

Bug description:
The commit in r1049 (serial interrupt fix (Hampa Hug)) prevents booting Digital 
Research DOS Plus.

[Qemu-devel] [Bug 588748] [NEW] QEMU fails to boot DR DOS Plus since 0.6.1

[Roy Tam]

Public bug reported:

The commit in r1049 (serial interrupt fix (Hampa Hug)) prevents booting
Digital Research DOS Plus.

** Affects: qemu
 Importance: Undecided
 Status: New

-- 
QEMU fails to boot DR DOS Plus since 0.6.1
https://bugs.launchpad.net/bugs/588748
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: New

Bug description:
The commit in r1049 (serial interrupt fix (Hampa Hug)) prevents booting Digital 
Research DOS Plus.

Re: [Qemu-devel] [PATCH 8/9] QMP: Introduce qmp_check_input_obj()

[Markus Armbruster]

Luiz Capitulino  writes:

> On Wed, 02 Jun 2010 09:39:26 +0200
> Markus Armbruster  wrote:
>
>> Luiz Capitulino  writes:
>> 
>> > This is similar to qmp_check_client_args(), but checks if
>> > the input object follows the specification (QMP/qmp-spec.txt
>> > section 2.3).
>> >
>> > As we're limited to three keys, the work here is quite simple:
>> > we iterate over the input object, each time checking if the
>> > given argument complies to the specification.
>> >
>> > Signed-off-by: Luiz Capitulino 
>> > ---
>> >  monitor.c |   45 +
>> >  1 files changed, 45 insertions(+), 0 deletions(-)
>> >
>> > diff --git a/monitor.c b/monitor.c
>> > index 1875731..654b193 100644
>> > --- a/monitor.c
>> > +++ b/monitor.c
>> > @@ -4271,6 +4271,45 @@ static int qmp_check_client_args(const mon_cmd_t 
>> > *cmd, QDict *client_args)
>> >  return res.result;
>> >  }
>> >  
>> > +/*
>> > + * Input object checking rules
>> > + *
>> > + * 1. "execute" key must exist (not checked here)
>> > + * 2. "execute" key must be a string
>> > + * 3. "arguments" key must be a dict
>> > + * 4. "id" key can be anything (ie. json-value)
>> 
>> Really?  Checking qmp-spec.txt... yes, really.  Is it a good idea to
>> permit objects and arrays?
>
>  It was Avi's suggestion to allow anything, maybe arrays don't make sense
> but objects do.

If we permit objects, we can just as well permit anything.

Re: [Qemu-devel] [PATCH 4/9] QMP: Second half of the new argument checking code

[Markus Armbruster]

Luiz Capitulino  writes:

> On Wed, 02 Jun 2010 09:31:24 +0200
> Markus Armbruster  wrote:
>
>> Luiz Capitulino  writes:
>> 
>> > This commit introduces check_client_args_type(), which is
>> > called by qmp_check_client_args() and complements the
>> > previous commit.
>> >
>> > Now the new client's argument checker code is capable of
>> > doing type checking and detecting unknown arguments.
>> >
>> > It works this way: we iterate over the client's arguments
>> > qdict and for each argument we check if it exists and if
>> > its type is correct.
>> >
>> > Signed-off-by: Luiz Capitulino 
>> > ---
>> >  monitor.c |   77 
>> > -
>> >  1 files changed, 76 insertions(+), 1 deletions(-)
>> >
>> > diff --git a/monitor.c b/monitor.c
>> > index 47a0da8..14790e6 100644
>> > --- a/monitor.c
>> > +++ b/monitor.c
>> > @@ -4266,6 +4266,75 @@ typedef struct QMPArgCheckRes {
>> >  } QMPArgCheckRes;
>> >  
>> >  /*
>> > + * Check if client's argument exists and type is correct
>> > + */
>> > +static void check_client_args_type(const char *client_arg_name,
>> > +   QObject *client_arg, void *opaque)
>> > +{
>> > +QObject *obj;
>> > +QString *arg_type;
>> > +QMPArgCheckRes *res = opaque;
>> > +
>> > +if (res->result < 0) {
>> > +/* report only the first error */
>> > +return;
>> > +}
>> > +
>> > +obj = qdict_get(res->qdict, client_arg_name);
>> > +if (!obj) {
>> > +/* client arg doesn't exist */
>> > +res->result = -1;
>> > +qerror_report(QERR_INVALID_PARAMETER, client_arg_name);
>> > +return;
>> > +}
>> > +
>> > +arg_type = qobject_to_qstring(obj);
>> > +assert(arg_type != NULL);
>> > +
>> > +/* check if argument's type is correct */
>> > +switch (qstring_get_str(arg_type)[0]) {
>> > +case 'F':
>> > +case 'B':
>> > +case 's':
>> > +if (qobject_type(client_arg) != QTYPE_QSTRING) {
>> > +qerror_report(QERR_INVALID_PARAMETER_TYPE, client_arg_name,
>> > +  "string");
>> > +res->result = -1;
>> > +}
>> > +break;
>> > +case 'i':
>> > +case 'l':
>> > +case 'M':
>> > +if (qobject_type(client_arg) != QTYPE_QINT) {
>> > +qerror_report(QERR_INVALID_PARAMETER_TYPE, client_arg_name, 
>> > "int");
>> > +res->result = -1;
>> > +}
>> > +break;
>> > +case 'f':
>> > +case 'T':
>> > +if (qobject_type(client_arg) != QTYPE_QINT &&
>> > +qobject_type(client_arg) != QTYPE_QFLOAT) {
>> > +qerror_report(QERR_INVALID_PARAMETER_TYPE, client_arg_name,
>> > +  "number");
>> > +res->result = -1;
>> > +}
>> > +break;
>> > +case 'b':
>> > +case '-':
>> > +if (qobject_type(client_arg) != QTYPE_QBOOL) {
>> > +qerror_report(QERR_INVALID_PARAMETER_TYPE, client_arg_name, 
>> > "bool");
>> > +res->result = -1;
>> > +}
>> > +break;
>> > +case 'O':
>> > +/* Not checked here */
>> > +break;
>> 
>> What about case '/'?  I guess it doesn't make much sense for QMP, but
>> the old checker handles it.  If we drop it from QMP, we should document
>> the restriction in the source.
>
>  Yes, there're two args_type we don't handle in QMP because we don't have
> any of those handlers converted: '/' and '.'.
>
>  I think it's unlikely to get them converted in this form, so the current
> implementation contains dead-code. I explained this in one commit log, but
> maybe it's the wrong place.

I read that commit message after I sent my comment :)

The commit message is fine; I'd like a comment in the code in addition,
not instead of the commit message.

[...]

[Qemu-devel] [Bug 588735] [NEW] Quit command not working

[Jan Smets]

Public bug reported:

Qemu strace


rt_sigreturn(0x1b)  = 56
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, 
child_tidptr=0x7f6fddecbad0) = ? ERESTARTNOINTR (To be restarted)
--- SIGPROF (Profiling timer expired) @ 0 (0) ---
rt_sigreturn(0x1b)  = 56


started with :

[r...@virtual-test ~]# /root/qemu-test/qemu-kvm/x86_64-softmmu/qemu-
system-x86_64 -net tap,vlan=0,name=tap.0 -chardev
socket,id=serial0,host=0.0.0.0,port=$CONSOLEPORT,telnet,server,nowait
-serial chardev:serial0 -hda hda -hdb hdb -hdc hdc -hdd hdd -fda fd0
-fdb fd1 -chardev
socket,id=monitor,host=0.0.0.0,port=$MONITORPORT,telnet,server,nowait
-monitor chardev:monitor -net
nic,macaddr=$MAC,vlan=0,model=e1000,name=e1000.0 -M pc -m 4096

when removing -m 4096, the quit command works.

but I think its a combination of different args that causes the problem.

** Affects: qemu
 Importance: Undecided
 Status: New

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

Status in QEMU: New

Bug description:
Qemu strace



rt_sigreturn(0x1b)  = 56
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, 
child_tidptr=0x7f6fddecbad0) = ? ERESTARTNOINTR (To be restarted)
--- SIGPROF (Profiling timer expired) @ 0 (0) ---
rt_sigreturn(0x1b)  = 56


started with :

[r...@virtual-test ~]# 
/root/qemu-test/qemu-kvm/x86_64-softmmu/qemu-system-x86_64 -net 
tap,vlan=0,name=tap.0 -chardev 
socket,id=serial0,host=0.0.0.0,port=$CONSOLEPORT,telnet,server,nowait -serial 
chardev:serial0 -hda hda -hdb hdb -hdc hdc -hdd hdd -fda fd0 -fdb fd1 -chardev 
socket,id=monitor,host=0.0.0.0,port=$MONITORPORT,telnet,server,nowait -monitor 
chardev:monitor -net nic,macaddr=$MAC,vlan=0,model=e1000,name=e1000.0 -M pc -m 
4096

when removing -m 4096, the quit command works.

but I think its a combination of different args that causes the problem.

Re: [Qemu-devel] Re: [Bug 267542] Re: MINIX 3 won't boot in qemu 0.9.1

[Erik van der Kouwe]

Hi,


As of last March, the bug was found to be in SeaBIOS:

http://www.seabios.org/pipermail/seabios/2010-March/000419.html

Since Bochs BIOS didn't have the problem in this thread, it is 
reasonable to assume that any QEMU issues that existed in 0.9.1 are 
fixed by now.


This has also been fixed in recent versions of MINIX, so upgrading 
either your SeaBIOS or your MINIX should work. Please note that both 
QEMU 0.9.1 and MINIX 3.1.2a are absolutely ancient.


With kind regards,
Erik

Re: [Qemu-devel] Re: [V9fs-developer] [PATCH] [virtio-9p] Flush the debug message out to the log file.

[Venkateswararao Jujjuri (JV)]

Aneesh Kumar K. V wrote:
> On Tue,  1 Jun 2010 13:23:09 -0700, "Venkateswararao Jujjuri (JV)" 
>  wrote:
>> This patch fluesh the debug messages to the log file  at the end of each
>> debug message.
>>
>> Signed-off-by: Venkateswararao Jujjuri 
>> ---
>>  hw/virtio-9p-debug.c |2 ++
>>  1 files changed, 2 insertions(+), 0 deletions(-)
>>
>> diff --git a/hw/virtio-9p-debug.c b/hw/virtio-9p-debug.c
>> index 2fb2673..5bfa689 100644
>> --- a/hw/virtio-9p-debug.c
>> +++ b/hw/virtio-9p-debug.c
>> @@ -481,4 +481,6 @@ void pprint_pdu(V9fsPDU *pdu)
>>  }
>>
>>  fprintf(llogfile, ")\n");
>> +/* Flush the log message out */
>> +fseek(llogfile, 0L, SEEK_CUR);
>>  }
> 
> 
> Why do one use fseek to flush ? why not fflush(3)

Good question. :) 
Even though functionally both are same, I will send a patch with fflush() as it 
is more straightforward. 

- JV

> 
> -aneesh
> 

[Qemu-devel] [Bug 534973] Re: qemu-system-ppc segfaults when booting from Debian lenny netinst image

[Natalia Portillo]

I confirm this is happening in QEMU 0.12.4.

** Changed in: qemu
   Status: New => Confirmed

-- 
qemu-system-ppc segfaults when booting from Debian lenny netinst image
https://bugs.launchpad.net/bugs/534973
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: Confirmed

Bug description:
I get a segfault from qemu-system-ppc when booting from the Debian lenny 
netinst image. I'm using QEMU 0.12.3. The host machine (on which QEMU was 
compiled) is:

[ianse...@zebra]~$ uname -a
Linux zebra 2.6.31-20-generic #57-Ubuntu SMP Mon Feb 8 09:02:26 UTC 2010 x86_64 
GNU/Linux

A gdb trace is below. Any other info I can provide?

[ianse...@zebra]~$ gdb --args ~/packages/qemu/bin/qemu-system-ppc -hda 
debian-lenny-powerpc.img -cdrom debian-504-powerpc-netinst.iso -boot d
GNU gdb (GDB) 7.0-ubuntu
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from 
/home/iansealy/packages/qemu-0.12.3/bin/qemu-system-ppc...done.
(gdb) run
Starting program: /home/iansealy/packages/qemu-0.12.3/bin/qemu-system-ppc -hda 
debian-lenny-powerpc.img -cdrom debian-504-powerpc-netinst.iso -boot d
[Thread debugging using libthread_db enabled]
[New Thread 0x7fffe77e2910 (LWP 9230)]

Program received signal SIGUSR2, User defined signal 2.
0x00553c81 in check_regs (s=0xcb6f40) at 
/home/iansealy/src/qemu-0.12.3/tcg/tcg.c:1296
1296if (ts->val_type == TEMP_VAL_REG &&
(gdb) bt
#0  0x00553c81 in check_regs (s=0xcb6f40) at 
/home/iansealy/src/qemu-0.12.3/tcg/tcg.c:1296
#1  0x00555aee in tcg_gen_code_common (s=0xcb6f40, 
gen_code_buf=0x417f4db0 "A\213ntH\213݁ü\005", search_pc=-1)
at /home/iansealy/src/qemu-0.12.3/tcg/tcg.c:1994
#2  0x00555b2a in tcg_gen_code (s=0xcb6f40, gen_code_buf=0x417f4db0 
"A\213ntH\213݁ü\005") at /home/iansealy/src/qemu-0.12.3/tcg/tcg.c:2017
#3  0x00513f09 in cpu_ppc_gen_code (env=0xcf81d0, tb=0x71afdd00, 
gen_code_size_ptr=0x7fffdd80)
at /home/iansealy/src/qemu-0.12.3/translate-all.c:120
#4  0x0050e011 in tb_gen_code (env=0xcf81d0, pc=3223273620, cs_base=0, 
flags=0, cflags=0) at /home/iansealy/src/qemu-0.12.3/exec.c:899
#5  0x005147c2 in tb_find_slow (pc=3223273620, cs_base=0, flags=0) at 
/home/iansealy/src/qemu-0.12.3/cpu-exec.c:164
#6  0x005148c8 in tb_find_fast () at 
/home/iansealy/src/qemu-0.12.3/cpu-exec.c:185
#7  0x00514c0f in cpu_ppc_exec (env1=0xcf81d0) at 
/home/iansealy/src/qemu-0.12.3/cpu-exec.c:582
#8  0x0040c7ce in qemu_cpu_exec (env=0xcf81d0) at 
/home/iansealy/src/qemu-0.12.3/vl.c:4021
#9  0x0040c8b3 in tcg_cpu_exec () at 
/home/iansealy/src/qemu-0.12.3/vl.c:4050
#10 0x0040cb81 in main_loop () at 
/home/iansealy/src/qemu-0.12.3/vl.c:4168
#11 0x004107de in main (argc=7, argv=0x7fffe2c8, 
envp=0x7fffe308) at /home/iansealy/src/qemu-0.12.3/vl.c:6125
(gdb) c
Continuing.
[Thread 0x7fffe77e2910 (LWP 9230) exited]

Program received signal SIGSEGV, Segmentation fault.
0x00442961 in bmdma_readb (opaque=0xd278c8, addr=1793) at 
/home/iansealy/src/qemu-0.12.3/hw/ide/cmd646.c:91
91  val = pci_dev->dev.config[MRDMODE];
(gdb) bt
#0  0x00442961 in bmdma_readb (opaque=0xd278c8, addr=1793) at 
/home/iansealy/src/qemu-0.12.3/hw/ide/cmd646.c:91
#1  0x004a87b4 in ioport_read (index=0, address=1793) at ioport.c:67
#2  0x004a8c15 in cpu_inb (addr=1793) at ioport.c:216
#3  0x004261b2 in isa_mmio_readb (opaque=0x0, addr=1793) at 
/home/iansealy/src/qemu-0.12.3/hw/isa_mmio.c:56
#4  0x005728f8 in io_readb (physaddr=1793, addr=4276688641, 
retaddr=0x40ded3dd) at /home/iansealy/src/qemu-0.12.3/softmmu_template.h:68
#5  0x005729b4 in __ldb_mmu (addr=4276688641, mmu_idx=1) at 
/home/iansealy/src/qemu-0.12.3/softmmu_template.h:103
#6  0x40ded3de in ?? ()
#7  0x7fffddf0 in ?? ()
#8  0x005147d9 in tb_find_slow (pc=Cannot access memory at address 
0xfee90fbd
) at /home/iansealy/src/qemu-0.12.3/cpu-exec.c:168
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) c
Continuing.

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.

[Qemu-devel] [Bug 588731] [NEW] PXE boot not working

[Jan Smets]

Public bug reported:

/root/qemu-test/qemu-kvm/x86_64-softmmu/qemu-system-x86_64 -net
tap,vlan=0,name=tap.0 -boot n -net
nic,macaddr=$MAC,vlan=0,model=e1000,name=e1000.0 -chardev
socket,id=monitor,host=0.0.0.0,port=$MONITORPORT,telnet,server,nowait
-monitor chardev:monitor


net0: 02:5a:3b:27:00:a1 on PCI00:03.0 (open)
   
 [Link:up, TX:0 TXE:0 RX:0 RXE:0]   
  
 DHCP (net0 02:5a:3b:27:00:a1) Connection timed out 
(0x4c106035)
 No more network devices



 
No bootable device. 


After doing a system_reset 

net0: 02:5a:3b:27:00:a1 on PCI00:03.0 (open)
   
 [Link:up, TX:0 TXE:0 RX:0 RXE:0]   
  
DHCP (net0 02:5a:3b:27:00:a1) ok
   
net0: 10.201.1.161/255.0.0.0 gw 10.0.0.1
   
Booting from filename "boot.pxe"
  
tftp://x.x.x./boot.pxe.. ok  


And it magaically works.

using HEAD.

** Affects: qemu
 Importance: Undecided
 Status: New

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

Status in QEMU: New

Bug description:
/root/qemu-test/qemu-kvm/x86_64-softmmu/qemu-system-x86_64 -net 
tap,vlan=0,name=tap.0 -boot n -net 
nic,macaddr=$MAC,vlan=0,model=e1000,name=e1000.0 -chardev 
socket,id=monitor,host=0.0.0.0,port=$MONITORPORT,telnet,server,nowait -monitor 
chardev:monitor



net0: 02:5a:3b:27:00:a1 on PCI00:03.0 (open)
   
 [Link:up, TX:0 TXE:0 RX:0 RXE:0]   
  
 DHCP (net0 02:5a:3b:27:00:a1) Connection timed out 
(0x4c106035)
 No more network devices



 
No bootable device. 



After doing a system_reset 

net0: 02:5a:3b:27:00:a1 on PCI00:03.0 (open)
   
 [Link:up, TX:0 TXE:0 RX:0 RXE:0]   
  
DHCP (net0 02:5a:3b:27:00:a1) ok
   
net0: 10.201.1.161/255.0.0.0 gw 10.0.0.1
   
Booting from filename "boot.pxe"
  
tftp://x.x.x./boot.pxe.. ok  


And it magaically works.

using HEAD.

[Qemu-devel] [Bug 547227] Re: qemu-system-m68k does not accept "notw %d" instruction

[Peter B . Jørgensen]

Didn't know you are not targeting the original M68000. Must have missed
that somewhere.

-- 
qemu-system-m68k does not accept "notw %d" instruction
https://bugs.launchpad.net/bugs/547227
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: Invalid

Bug description:
The notw and notb instructions does not work with latest version of 
qemu-system-m68k. I've tried both 0.12.3 and the latest git version compiled 
about an hour ago, both running on Arch Linux. The executable fails with the 
following output:
> qemu-system-m68k -nographic -M an5206 -kernel test.elf
qemu: fatal: Illegal instruction: 4640 @ 0006
D0 =    A0 =    F0 =  (   0)
D1 =    A1 =    F1 =  (   0)
D2 =    A2 =    F2 =  (   0)
D3 =    A3 =    F3 =  (   0)
D4 =    A4 =    F4 =  (   0)
D5 =    A5 =    F5 =  (   0)
D6 =    A6 =    F6 =  (   0)
D7 =    A7 =    F7 =  (   0)
PC =    SR = 2700 - FPRESULT =0
zsh: abort  qemu-system-m68k -nographic -M an5206 -kernel test.elf

I've attached the test.elf file, which produces the bug. It contains the 
following:
> m68k-elf-objdump -m 68000 -D test.elf  
test.elf: file format elf32-m68k
Disassembly of section .text:
 :
   0:   4e71nop
   2:   4e71nop
   4:   4e71nop
   6:   4640notw %d0
0008 :
   8:   6000 fffe   braw 8 

It works when removing the not instruction. There might be other non-working 
instructions, I've only tested a few.
Hope you'll get the bug fixed. Thanks.

[Qemu-devel] Re: [V9fs-developer] [PATCH] virtio-9p: getattr server implementation for 9P2000.L protocol.

[Aneesh Kumar K. V]

On Fri, 28 May 2010 16:08:43 +0530, Sripathi Kodi  wrote:
> From: M. Mohan Kumar 
> 
> SYNOPSIS
> 
>   size[4] Tgetattr tag[2] fid[4]
> 
>   size[4] Rgetattr tag[2] lstat[n]
> 
>DESCRIPTION
> 
>   The getattr transaction inquires about the file identified by fid.
>   The reply will contain a machine-independent directory entry,
>   laid out as follows:
> 
>  qid.type[1]
> the type of the file (directory, etc.), represented as a bit
> vector corresponding to the high 8 bits of the file's mode
> word.
> 
>  qid.vers[4]
> version number for given path
> 
>  qid.path[8]
> the file server's unique identification for the file
> 
>  st_mode[4]
> Permission and flags
> 
>  st_nlink[8]
> Number of hard links
> 
>  st_uid[4]
> User id of owner
> 
>  st_gid[4]
> Group ID of owner
> 
>  st_rdev[8]
> Device ID (if special file)
> 
>  st_size[8]
> Size, in bytes
> 
>  st_blksize[8]
> Block size for file system IO


So it should be scaled by iounit right ? If we say 9p block size is iounit.


> 
>  st_blocks[8]
> Number of file system blocks allocated

same here. 

> 
>  st_atime_sec[8]
> Time of last access, seconds
> 
>  st_atime_nsec[8]
> Time of last access, nanoseconds
> 
>  st_mtime_sec[8]
> Time of last modification, seconds
> 
>  st_mtime_nsec[8]
> Time of last modification, nanoseconds
> 
>  st_ctime_sec[8]
> Time of last status change, seconds
> 
>  st_ctime_nsec[8]
> Time of last status change, nanoseconds
> 
> 
> This patch implements the client side of getattr implementation for 9P2000.L.
> It introduces a new structure p9_stat_dotl for getting Linux stat information
> along with QID. The data layout is similar to stat structure in Linux user
> space with the following major differences:
> 
> inode (st_ino) is not part of data. Instead qid is.
> 
> device (st_dev) is not part of data because this doesn't make sense on the
> client.
> 
> All time variables are 64 bit wide on the wire. The kernel seems to use
> 32 bit variables for these variables. However, some of the architectures
> have used 64 bit variables and glibc exposes 64 bit variables to user
> space on some architectures. Hence to be on the safer side we have made
> these 64 bit in the protocol. Refer to the comments in
> include/asm-generic/stat.h
> 
> 
> Signed-off-by: M. Mohan Kumar 
> Signed-off-by: Sripathi Kodi 
> ---
> 
>  hw/virtio-9p-debug.c |   32 
>  hw/virtio-9p.c   |   82 
> ++
>  hw/virtio-9p.h   |   28 +
>  3 files changed, 142 insertions(+), 0 deletions(-)
> 
> diff --git a/hw/virtio-9p-debug.c b/hw/virtio-9p-debug.c
> index a82b771..8bb817d 100644
> --- a/hw/virtio-9p-debug.c
> +++ b/hw/virtio-9p-debug.c
> @@ -178,6 +178,30 @@ static void pprint_stat(V9fsPDU *pdu, int rx, size_t 
> *offsetp, const char *name)
>  fprintf(llogfile, "}");
>  }
> 
> +static void pprint_stat_dotl(V9fsPDU *pdu, int rx, size_t *offsetp,
> +  const char *name)
> +{
> +fprintf(llogfile, "%s={", name);
> +pprint_qid(pdu, rx, offsetp, "qid");
> +pprint_int32(pdu, rx, offsetp, ", st_mode");
> +pprint_int64(pdu, rx, offsetp, ", st_nlink");
> +pprint_int32(pdu, rx, offsetp, ", st_uid");
> +pprint_int32(pdu, rx, offsetp, ", st_gid");
> +pprint_int64(pdu, rx, offsetp, ", st_rdev");
> +pprint_int64(pdu, rx, offsetp, ", st_size");
> +pprint_int64(pdu, rx, offsetp, ", st_blksize");
> +pprint_int64(pdu, rx, offsetp, ", st_blocks");
> +pprint_int64(pdu, rx, offsetp, ", atime");
> +pprint_int64(pdu, rx, offsetp, ", atime_nsec");
> +pprint_int64(pdu, rx, offsetp, ", mtime");
> +pprint_int64(pdu, rx, offsetp, ", mtime_nsec");
> +pprint_int64(pdu, rx, offsetp, ", ctime");
> +pprint_int64(pdu, rx, offsetp, ", ctime_nsec");
> +fprintf(llogfile, "}");
> +}
> +
> +
> +
>  static void pprint_strs(V9fsPDU *pdu, int rx, size_t *offsetp, const char 
> *name)
>  {
>  int sg_count = get_sg_count(pdu, rx);
> @@ -351,6 +375,14 @@ void pprint_pdu(V9fsPDU *pdu)
>  pprint_int32(pdu, 1, &offset, "msize");
>  pprint_str(pdu, 1, &offset, ", version");
>  break;
> +case P9_TGETATTR:
> +fprintf(llogfile, "TGETATTR: (");
> +pprint_int32(pdu, 0, &offset, "fid");
> +break;
> +case P9_RGETATTR:
> +fprintf(llogfile, "RGETATTR: (");
> +pprint_stat_dotl(pdu, 1, &offset, "getattr");
> +break;
>  case P9_TAUTH:
>  fprintf(llogfile, "TAUTH: (");
>  pprint_int32(pdu, 0, &offset, "afid");
> diff --git a/hw/virtio-

Re: [Qemu-devel] [PATCH] Name the default PCI bus "pci.0" on all architectures

[Daniel P. Berrange]

On Fri, May 28, 2010 at 08:39:53PM +0100, Paul Brook wrote:
> > The system emulators for each arch are using inconsistent
> > naming for the default PCI bus "pci" vs "pci.0". Since it
> > is conceivable we'll have multiple PCI buses in the future
> > standardize on "pci.0" for all architectures. This ensures
> > mgmt apps can rely on a name when assigning PCI devices an
> > address on the bus using eg '-device e1000,bus=pci.0,addr=3'
> 
> No. Bus names are local to the parent device.  None of the host bridges 
> support multiple bridges, so the ".0" suffix makes no sense.  The parent 
> device has no idea whether it owns the "default" pci bus or not.
> If you have multiple PCI busses then you can identify them by the device 
> path.

The problem is that the ID names of default devices in machines are ABI
sensitive. Management apps need to know what the ID of these default
devices are. The x86 machines have already used 'pci.0' as their name
in the previous 0.12 release and libvirt is using this naming. We later
discovered many non-x86 archs have a name of just 'pci'. We need a single
consistent naming across all arches, hence this patch whcih standardizes
on 'pci.0'. The '.N' convention is used extensively in QEMU and is more 
futureproof as & when QEMU supports multiple buses, without requiring 
apps to use the more verbose device paths to ensure uniquness.

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] [Bug 563883] Re: typo, easy fix

[Gerard Alquézar]

Fixed by Riccardo Magliocchetti in
3c05613a6a51da833105c1bf3db4917d917f5a3a commit

** Changed in: qemu
   Status: New => Fix Committed

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

Status in QEMU: Fix Committed

Bug description:
Spot the typo:

(qemu) help balloon
balloon target -- request VM to change it's memory allocation (in MB)

Hint: possessives take no apostrophe.

[Qemu-devel] Re: [PATCH v2 2/2] basic machine opts framework

[Glauber Costa]

On Wed, Jun 02, 2010 at 09:15:10AM +0200, Jan Kiszka wrote:
> >  
> > +QemuOptsList qemu_machine_opts = {
> > +.name = "M",
> > +.head = QTAILQ_HEAD_INITIALIZER(qemu_machine_opts.head),
> > +.desc = {
> > +{
> > +.name = "mach",
> > +.type = QEMU_OPT_STRING,
> > +},{
> > +.name = "irqchip",
> > +.type = QEMU_OPT_STRING,
> > +},
> 
> Can't we make the concrete machine define what options it needs? Pushing
> this into the generic code may soon end up in a bunch of very special
> switches that are unused on most machines or even have no meaning for them.
> 
> Also, I would suggest to introduce the generic part first, and then add
> first users like the x86 irqchip.
Yeah, in general, I do agree with you.

Me and anthony talked about it for a while some time ago, and more or less
concluded that it could be possible to avoid that, putting a little think
which options to add.

the "irqchip" option, if you note, is not x86-specific, in any case.
Any machine has an irqchip. The first idea was to use something like
"apic=in_kernel|userspace" which would be, that, very x86-centric.

So, since letting machines define their own options adds complexity,
my take would be to add those common options, and add infrastructure
for machine-specific options when we see something that makes it
unavoidable.

What do you think? 

[Qemu-devel] Re: [Bug 267542] Re: MINIX 3 won't boot in qemu 0.9.1

[Paolo Bonzini]

On 06/02/2010 03:03 PM, Andre Przywara wrote:

Can you give more hints on how to reproduce this?
$ qemu-system-x86_64 -cdrom minix_R3.1.6-r6084.iso
works fine for me (I get to the prompt), both with --enable-kvm and without and 
also with qemu-kvm. My qemu version is 0.12.4.
Do I need to install it and run it from the harddisk?


As of last March, the bug was found to be in SeaBIOS:

http://www.seabios.org/pipermail/seabios/2010-March/000419.html

Since Bochs BIOS didn't have the problem in this thread, it is 
reasonable to assume that any QEMU issues that existed in 0.9.1 are 
fixed by now.


Paolo

[Qemu-devel] Re: [RFC PATCH v4 3/3] block: add sheepdog driver for distributed storage support

[Kevin Wolf]

Am 28.05.2010 04:44, schrieb MORITA Kazutaka:
> Sheepdog is a distributed storage system for QEMU. It provides highly
> available block level storage volumes to VMs like Amazon EBS.  This
> patch adds a qemu block driver for Sheepdog.
> 
> Sheepdog features are:
> - No node in the cluster is special (no metadata node, no control
>   node, etc)
> - Linear scalability in performance and capacity
> - No single point of failure
> - Autonomous management (zero configuration)
> - Useful volume management support such as snapshot and cloning
> - Thin provisioning
> - Autonomous load balancing
> 
> The more details are available at the project site:
> http://www.osrg.net/sheepdog/
> 
> Signed-off-by: MORITA Kazutaka 
> ---
>  Makefile.objs|2 +-
>  block/sheepdog.c | 1835 
> ++
>  2 files changed, 1836 insertions(+), 1 deletions(-)
>  create mode 100644 block/sheepdog.c

One general thing: The code uses some mix of spaces and tabs for
indentation, with the greatest part using tabs. According to
CODING_STYLE it should consistently use four spaces instead.

> diff --git a/Makefile.objs b/Makefile.objs
> index 1a942e5..527a754 100644
> --- a/Makefile.objs
> +++ b/Makefile.objs
> @@ -14,7 +14,7 @@ block-obj-$(CONFIG_LINUX_AIO) += linux-aio.o
>  
>  block-nested-y += raw.o cow.o qcow.o vdi.o vmdk.o cloop.o dmg.o bochs.o 
> vpc.o vvfat.o
>  block-nested-y += qcow2.o qcow2-refcount.o qcow2-cluster.o qcow2-snapshot.o
> -block-nested-y += parallels.o nbd.o blkdebug.o
> +block-nested-y += parallels.o nbd.o blkdebug.o sheepdog.o
>  block-nested-$(CONFIG_WIN32) += raw-win32.o
>  block-nested-$(CONFIG_POSIX) += raw-posix.o
>  block-nested-$(CONFIG_CURL) += curl.o
> diff --git a/block/sheepdog.c b/block/sheepdog.c
> new file mode 100644
> index 000..68545e8
> --- /dev/null
> +++ b/block/sheepdog.c
> @@ -0,0 +1,1835 @@
> +/*
> + * Copyright (C) 2009-2010 Nippon Telegraph and Telephone Corporation.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License version
> + * 2 as published by the Free Software Foundation.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see .
> + */
> +#include 
> +#include 
> +
> +#include "qemu-common.h"
> +#include "qemu-error.h"
> +#include "block_int.h"
> +
> +#define SD_PROTO_VER 0x01
> +
> +#define SD_DEFAULT_ADDR "localhost:7000"
> +
> +#define SD_OP_CREATE_AND_WRITE_OBJ  0x01
> +#define SD_OP_READ_OBJ   0x02
> +#define SD_OP_WRITE_OBJ  0x03
> +
> +#define SD_OP_NEW_VDI0x11
> +#define SD_OP_LOCK_VDI   0x12
> +#define SD_OP_RELEASE_VDI0x13
> +#define SD_OP_GET_VDI_INFO   0x14
> +#define SD_OP_READ_VDIS  0x15
> +
> +#define SD_FLAG_CMD_WRITE0x01
> +#define SD_FLAG_CMD_COW  0x02
> +
> +#define SD_RES_SUCCESS   0x00 /* Success */
> +#define SD_RES_UNKNOWN   0x01 /* Unknown error */
> +#define SD_RES_NO_OBJ0x02 /* No object found */
> +#define SD_RES_EIO   0x03 /* I/O error */
> +#define SD_RES_VDI_EXIST 0x04 /* Vdi exists already */
> +#define SD_RES_INVALID_PARMS 0x05 /* Invalid parameters */
> +#define SD_RES_SYSTEM_ERROR  0x06 /* System error */
> +#define SD_RES_VDI_LOCKED0x07 /* Vdi is locked */
> +#define SD_RES_NO_VDI0x08 /* No vdi found */
> +#define SD_RES_NO_BASE_VDI   0x09 /* No base vdi found */
> +#define SD_RES_VDI_READ  0x0A /* Cannot read requested vdi */
> +#define SD_RES_VDI_WRITE 0x0B /* Cannot write requested vdi */
> +#define SD_RES_BASE_VDI_READ 0x0C /* Cannot read base vdi */
> +#define SD_RES_BASE_VDI_WRITE   0x0D /* Cannot write base vdi */
> +#define SD_RES_NO_TAG0x0E /* Requested tag is not found */
> +#define SD_RES_STARTUP   0x0F /* Sheepdog is on starting up */
> +#define SD_RES_VDI_NOT_LOCKED   0x10 /* Vdi is not locked */
> +#define SD_RES_SHUTDOWN  0x11 /* Sheepdog is shutting down */
> +#define SD_RES_NO_MEM0x12 /* Cannot allocate memory */
> +#define SD_RES_FULL_VDI  0x13 /* we already have the maximum vdis */
> +#define SD_RES_VER_MISMATCH  0x14 /* Protocol version mismatch */
> +#define SD_RES_NO_SPACE  0x15 /* Server has no room for new objects */
> +#define SD_RES_WAIT_FOR_FORMAT  0x16 /* Sheepdog is waiting for a format 
> operation */
> +#define SD_RES_WAIT_FOR_JOIN0x17 /* Sheepdog is waiting for other nodes 
> joining */
> +#define SD_RES_JOIN_FAILED   0x18 /* Target node had failed to join sheepdog 
> */
> +
> +/*
> + * Object ID rules
> + *
> + *  0 - 19 (20 bits): data object space
> + * 20 - 31 (12 bits): reserved data object space
> + * 32 - 55 (24 bits): vdi object space
> + * 56 - 59 ( 4 bits): reserved vdi object space
> + * 60 - 63 ( 4 bits): object type indentifier space
> + */
> +
> +#define VDI_SPACE_SHIFT   32
> +#define VDI_BIT (UINT64_C(1) << 63)
> +#define VMSTATE_BIT (UINT64_C(1) 

Re: [Qemu-devel] [PATCH 4/9] QMP: Second half of the new argument checking code

[Luiz Capitulino]

On Wed, 02 Jun 2010 09:31:24 +0200
Markus Armbruster  wrote:

> Luiz Capitulino  writes:
> 
> > This commit introduces check_client_args_type(), which is
> > called by qmp_check_client_args() and complements the
> > previous commit.
> >
> > Now the new client's argument checker code is capable of
> > doing type checking and detecting unknown arguments.
> >
> > It works this way: we iterate over the client's arguments
> > qdict and for each argument we check if it exists and if
> > its type is correct.
> >
> > Signed-off-by: Luiz Capitulino 
> > ---
> >  monitor.c |   77 
> > -
> >  1 files changed, 76 insertions(+), 1 deletions(-)
> >
> > diff --git a/monitor.c b/monitor.c
> > index 47a0da8..14790e6 100644
> > --- a/monitor.c
> > +++ b/monitor.c
> > @@ -4266,6 +4266,75 @@ typedef struct QMPArgCheckRes {
> >  } QMPArgCheckRes;
> >  
> >  /*
> > + * Check if client's argument exists and type is correct
> > + */
> > +static void check_client_args_type(const char *client_arg_name,
> > +   QObject *client_arg, void *opaque)
> > +{
> > +QObject *obj;
> > +QString *arg_type;
> > +QMPArgCheckRes *res = opaque;
> > +
> > +if (res->result < 0) {
> > +/* report only the first error */
> > +return;
> > +}
> > +
> > +obj = qdict_get(res->qdict, client_arg_name);
> > +if (!obj) {
> > +/* client arg doesn't exist */
> > +res->result = -1;
> > +qerror_report(QERR_INVALID_PARAMETER, client_arg_name);
> > +return;
> > +}
> > +
> > +arg_type = qobject_to_qstring(obj);
> > +assert(arg_type != NULL);
> > +
> > +/* check if argument's type is correct */
> > +switch (qstring_get_str(arg_type)[0]) {
> > +case 'F':
> > +case 'B':
> > +case 's':
> > +if (qobject_type(client_arg) != QTYPE_QSTRING) {
> > +qerror_report(QERR_INVALID_PARAMETER_TYPE, client_arg_name,
> > +  "string");
> > +res->result = -1;
> > +}
> > +break;
> > +case 'i':
> > +case 'l':
> > +case 'M':
> > +if (qobject_type(client_arg) != QTYPE_QINT) {
> > +qerror_report(QERR_INVALID_PARAMETER_TYPE, client_arg_name, 
> > "int");
> > +res->result = -1;
> > +}
> > +break;
> > +case 'f':
> > +case 'T':
> > +if (qobject_type(client_arg) != QTYPE_QINT &&
> > +qobject_type(client_arg) != QTYPE_QFLOAT) {
> > +qerror_report(QERR_INVALID_PARAMETER_TYPE, client_arg_name,
> > +  "number");
> > +res->result = -1;
> > +}
> > +break;
> > +case 'b':
> > +case '-':
> > +if (qobject_type(client_arg) != QTYPE_QBOOL) {
> > +qerror_report(QERR_INVALID_PARAMETER_TYPE, client_arg_name, 
> > "bool");
> > +res->result = -1;
> > +}
> > +break;
> > +case 'O':
> > +/* Not checked here */
> > +break;
> 
> What about case '/'?  I guess it doesn't make much sense for QMP, but
> the old checker handles it.  If we drop it from QMP, we should document
> the restriction in the source.

 Yes, there're two args_type we don't handle in QMP because we don't have
any of those handlers converted: '/' and '.'.

 I think it's unlikely to get them converted in this form, so the current
implementation contains dead-code. I explained this in one commit log, but
maybe it's the wrong place.

> 
> > +default:
> > +abort();
> > +}
> > +}
> > +
> > +/*
> >   * Check if client passed all mandatory args
> >   */
> >  static void check_mandatory_args(const char *cmd_arg_name,
> > @@ -4344,6 +4413,9 @@ out:
> >   * Client argument checking rules:
> >   *
> >   * 1. Client must provide all mandatory arguments
> > + * 2. Each argument provided by the client must be valid
> > + * 3. Each argument provided by the client must have the type expected
> > + *by the command
> >   */
> >  static int qmp_check_client_args(const mon_cmd_t *cmd, QDict *client_args)
> >  {
> > @@ -4355,7 +4427,10 @@ static int qmp_check_client_args(const mon_cmd_t 
> > *cmd, QDict *client_args)
> >  res.qdict = client_args;
> >  qdict_iter(cmd_args, check_mandatory_args, &res);
> >  
> > -/* TODO: Check client args type */
> > +if (!res.result && !res.skip) {
> > +res.qdict = cmd_args;
> > +qdict_iter(client_args, check_client_args_type, &res);
> > +}
> 
> What if we have both an O-type argument and other arguments?  Then the
> 'O' makes check_client_args_type() set res.skip, and we duly skip
> checking the other arguments here.

 Oh, good catch. I thought that that was what the current code does,
but looks like I misread it.

> Again, the iterator makes for tortuous code.
> 
> >  
> >  QDECREF(cmd_args);
> >  return res.result;
> 

Re: [Qemu-devel] [PATCH 8/9] QMP: Introduce qmp_check_input_obj()

[Luiz Capitulino]

On Wed, 02 Jun 2010 09:39:26 +0200
Markus Armbruster  wrote:

> Luiz Capitulino  writes:
> 
> > This is similar to qmp_check_client_args(), but checks if
> > the input object follows the specification (QMP/qmp-spec.txt
> > section 2.3).
> >
> > As we're limited to three keys, the work here is quite simple:
> > we iterate over the input object, each time checking if the
> > given argument complies to the specification.
> >
> > Signed-off-by: Luiz Capitulino 
> > ---
> >  monitor.c |   45 +
> >  1 files changed, 45 insertions(+), 0 deletions(-)
> >
> > diff --git a/monitor.c b/monitor.c
> > index 1875731..654b193 100644
> > --- a/monitor.c
> > +++ b/monitor.c
> > @@ -4271,6 +4271,45 @@ static int qmp_check_client_args(const mon_cmd_t 
> > *cmd, QDict *client_args)
> >  return res.result;
> >  }
> >  
> > +/*
> > + * Input object checking rules
> > + *
> > + * 1. "execute" key must exist (not checked here)
> > + * 2. "execute" key must be a string
> > + * 3. "arguments" key must be a dict
> > + * 4. "id" key can be anything (ie. json-value)
> 
> Really?  Checking qmp-spec.txt... yes, really.  Is it a good idea to
> permit objects and arrays?

 It was Avi's suggestion to allow anything, maybe arrays don't make sense
but objects do.

Re: [Qemu-devel] [PATCH 3/9] QMP: First half of the new argument checking code

[Luiz Capitulino]

On Wed, 02 Jun 2010 09:22:40 +0200
Markus Armbruster  wrote:

> There's more...

 Good!

> Luiz Capitulino  writes:

[...]

> > +static void check_mandatory_args(const char *cmd_arg_name,
> > + QObject *obj, void *opaque)
> > +{
> > +QString *type;
> > +QMPArgCheckRes *res = opaque;
> > +
> > +if (res->result < 0) {
> > +/* report only the first error */
> > +return;
> > +}
> > +
> > +type = qobject_to_qstring(obj);
> > +assert(type != NULL);
> > +
> > +if (qstring_get_str(type)[0] == 'O') {
> > +QemuOptsList *opts_list = qemu_find_opts(cmd_arg_name);
> > +assert(opts_list);
> > +res->result = check_opts(opts_list, res->qdict);
> > +res->skip = 1;
> > +} else if (qstring_get_str(type)[0] != '-' &&
> > +   qstring_get_str(type)[1] != '?' &&
> > +   !qdict_haskey(res->qdict, cmd_arg_name)) {
> > +res->result = -1;
> 
> This is a sign that the iterator needs a way to return a value.
> 
> Check out qemu_opts_foreach(), it can break and return a value.

 Ah, that's good, I was wondering how I could do that but couldn't
find a good way.

[...]

> Higher order functions rock.  But C is too static and limited for
> elegant use of higher order functions.  Means to construct loops are
> usually more convenient to use, and yield more readable code.
> 
> I find the use of qdict_iter() here quite tortuous: you define a
> separate iterator function, which you can't put next to its use.  You
> need to jump back and forth between the two places to understand what
> the loop does.  You define a special data structure just to pass
> arguments and results through qdict_iter().
> 
> Let me try to sketch the alternative:
> 
> static int qmp_check_client_args(const mon_cmd_t *cmd, QDict *client_args)
> {
> QDict *cmd_args;
> int res = 0, skip = 0;
> QDictEntry *ent;
> 
> cmd_args = qdict_from_args_type(cmd->args_type);
> 
> for (ent = qdict_first_entry(cmd_args); ent; ent = qdict_next_entry(ent) {

 I thought about doing something similar a while ago, but I dislike it for
two reasons:

  1. I don't think the notion of 'first' and 'next' apply for dicts. One may
 argue that the iterator has the same issue, but it's implicit

  2. QDictEntry shouldn't be part of the public interface, we should be
 using forward declaration there (although I'm not sure whether this is
 possible with a typedef)

 I think having qdict_foreach() will improve things already.

Re: [Qemu-devel] [PATCH 3/9] QMP: First half of the new argument checking code

[Luiz Capitulino]

On Wed, 02 Jun 2010 08:59:11 +0200
Markus Armbruster  wrote:

> Luiz Capitulino  writes:

[...]

> > +
> > +type = qobject_to_qstring(obj);
> > +assert(type != NULL);
> > +
> > +if (qstring_get_str(type)[0] == 'O') {
> > +QemuOptsList *opts_list = qemu_find_opts(cmd_arg_name);
> > +assert(opts_list);
> > +res->result = check_opts(opts_list, res->qdict);
> 
> I doubt this is the right place for calling check_opts.

 Can you suggest the right place?

Re: [Qemu-devel] [PATCH 1/9] QDict: Introduce qdict_get_try_bool()

[Luiz Capitulino]

On Wed, 02 Jun 2010 08:35:16 +0200
Markus Armbruster  wrote:

> Luiz Capitulino  writes:
> 
> > Signed-off-by: Luiz Capitulino 
> > ---
> >  qdict.c |   18 ++
> >  qdict.h |1 +
> >  2 files changed, 19 insertions(+), 0 deletions(-)
> >
> > diff --git a/qdict.c b/qdict.c
> > index 175bc17..ca3c3b1 100644
> > --- a/qdict.c
> > +++ b/qdict.c
> > @@ -287,6 +287,24 @@ int64_t qdict_get_try_int(const QDict *qdict, const 
> > char *key,
> >  }
> >  
> >  /**
> > + * qdict_get_try_bool(): Try to get a bool mapped by 'key'
> > + *
> > + * Return bool mapped by 'key', if it is not present in the
> > + * dictionary or if the stored object is not of QBool type
> > + * 'err_value' will be returned.
> > + */
> > +int qdict_get_try_bool(const QDict *qdict, const char *key, int err_value)
> > +{
> > +QObject *obj;
> > +
> > +obj = qdict_get(qdict, key);
> > +if (!obj || qobject_type(obj) != QTYPE_QBOOL)
> > +return err_value;
> > +
> > +return qbool_get_int(qobject_to_qbool(obj));
> > +}
> > +
> > +/**
> >   * qdict_get_try_str(): Try to get a pointer to the stored string
> >   * mapped by 'key'
> >   *
> > diff --git a/qdict.h b/qdict.h
> > index 5e5902c..5cca816 100644
> > --- a/qdict.h
> > +++ b/qdict.h
> > @@ -57,6 +57,7 @@ QDict *qdict_get_qdict(const QDict *qdict, const char 
> > *key);
> >  const char *qdict_get_str(const QDict *qdict, const char *key);
> >  int64_t qdict_get_try_int(const QDict *qdict, const char *key,
> >int64_t err_value);
> > +int qdict_get_try_bool(const QDict *qdict, const char *key, int err_value);
> >  const char *qdict_get_try_str(const QDict *qdict, const char *key);
> >  
> >  #endif /* QDICT_H */
> 
> Nitpick: there's precedence for parameter name "err_value" in qdict.c,
> but it's a misleading name all the same.  The parameter is a default
> value.  Missing key is *not* an error.

 Good point.

[Qemu-devel] [Bug 588691] Re: QEMU is not correctly detecting host CDs

[Cole Robinson]

The linux /dev/sr0 issue should be fixed upstream:

http://git.savannah.gnu.org/cgit/qemu.git/commit/?id=3baf720e6b920d583ce2834d05e5a4e9603a1d56

Maybe it's worth a backport to stable

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

Status in QEMU: In Progress

Bug description:
QEMU's block layer contains code for detecting and using ioctls when real 
CD-ROM host devices are attached.

This detection is not working in some host OSes while bad implemented on 
anothers.

E.g., in Linux host qemu -cdrom /dev/sr0 is not detecting it as a CD-ROM
E.g., in Mac OS X host qemu asks the kernel to enumerate optical devices and 
the compares it to the constant string "/dev/cdrom". This is useless, that 
enumeration is just enough, and "/dev/cdrom" will NEVER exist in Mac OS X 
unless manually created by the user.

Re: [Qemu-devel] [PATCH 2/8] sparc64: fix missing address masking

[Richard Henderson]

On 06/01/2010 09:29 PM, Igor Kovalenko wrote:
> On Wed, Jun 2, 2010 at 12:44 AM, Richard Henderson  wrote:
>> On 06/01/2010 01:12 PM, Igor V. Kovalenko wrote:
>>> +if ((env->pstate & PS_AM) && is_translating_asi(asi)) {
>>> +addr &= 0xULL;
>>> +}
>>
>> I suggest that these be written instead as
>>
>>  if (is_translating_asi(asi)) {
>>addr = address_mask(addr);
>>  }
>>
>> That should allow you to remove some of the ifdefs.
> 
> All address masking is done for sparc64 target only, sparc32 does not
> have the notion of translating asi.

Of course I know that.

> I think it's better to do debug printf macro trick ...

... with no evidence.  The compiler is happy to optimize away
the entire if statement without having to resort to macros.

> ... then but I see no real benefit at the moment.

Avoiding ifdefs isn't a benefit?


r~

[Qemu-devel] [Bug 566882] Re: better sparc64 support

[raymond]

Maybe change it to feature/enhancement request ?

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

Status in QEMU: Invalid

Bug description:
Need better sparc64 platform support. Currently booting debian 5.0.4 sparc is 
not possible.

On http://wiki.qemu.org/Main_Page there is no donation site available. Is it 
possible to vote for a specific purpose for donation, like purchase a cheap 
machine which help you for porting purposes?
Possible machines are sparc64 (ultra 5 and 10 and sun blade are currently cheap 
on ebay), alpha and powerpc.

[Qemu-devel] [Bug 588688] Re: Hard disk images are supporting ATAPI commands. They should fail.

[Natalia Portillo]

** Changed in: qemu
 Assignee: (unassigned) => Natalia Portillo (claunia)

** Changed in: qemu
   Status: New => In Progress

-- 
Hard disk images are supporting ATAPI commands. They should fail.
https://bugs.launchpad.net/bugs/588688
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: In Progress

Bug description:
When using a hard disk image (qcow, qcow2, vdi, vmdk, bochs), the emulated 
device can be a CD-ROM and support ATAPI commands.

These commands fails in real hard disks and these images are not prepared to 
handle optical disk formats, they should fail also.

Only images able to handle that formats (dmg, raw, host) should work with ATAPI 
commands and CD-ROM devices.

[Qemu-devel] [Bug 267542] Re: MINIX 3 won't boot in qemu 0.9.1

[Andre Przywara]

Can you give more hints on how to reproduce this?
$ qemu-system-x86_64 -cdrom minix_R3.1.6-r6084.iso
works fine for me (I get to the prompt), both with --enable-kvm and without and 
also with qemu-kvm. My qemu version is 0.12.4.
Do I need to install it and run it from the harddisk?

-- 
MINIX 3 won't boot in qemu 0.9.1
https://bugs.launchpad.net/bugs/267542
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: Incomplete

Bug description:
CD Image 3.1.2a was downloaded from http://www.minix3.org/download/

It booted with previous version of qemu but hangs at startup with 0.9.1.

Hardware acceleration is disabled.

Please ask if there is other information I can give you.

[Qemu-devel] [Bug 584155] Re: support horisontal mouse wheel

[Anthony Liguori]

** Changed in: qemu
   Importance: Undecided => Wishlist

** Changed in: qemu
   Status: New => Confirmed

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

Status in QEMU: Confirmed
Status in “qemu-kvm” package in Debian: Confirmed

Bug description:
Brad Jorsch provided a series of patches to support horisontal mouse scrolling 
in qemu-emulated mouse.
See Debian bug#579968 -- 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=579968 and submission to 
qemu-devel list at 
http://www.mail-archive.com/qemu-devel@nongnu.org/msg30991.html .

[Qemu-devel] [Bug 477946] Re: XP guest install fails with NTFS format error

[Natalia Portillo]

QEMU 0.12.3 does not present this bug.

Tested quick and full format, KVM and SOFTMMU, with Windows XP
Professional SP0.

Closing bug.

** Changed in: qemu
   Status: New => Fix Committed

-- 
XP guest install fails with NTFS format error
https://bugs.launchpad.net/bugs/477946
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: Fix Committed

Bug description:
Ubuntu 9.10 on AMD6400X2, 2G RAM, all updates applied as of date of bug report
Latest qemu-kvm installed (0.11)
XP guest  install (XP Pro SP2) fails when attempting to format the install 
partition (10G) as NTFS with the error "Setup was unable to format the 
partition. The disk may be damaged". 512M memory allocated to VM, one processor 
allocated. No additional qemu options specified.

However, can successfully format partition as FAT and complete install. 
However, after so doing, scheduled an NTFS convert on next reboot of guest. 
When the virtual machine was shut down and restarted, it immediately failed 
with a 'missing NTLDR' error. This occurred before the NTFS conversion took 
place.

Deleted all VMs and associated files and rebooted. Recreated the VM and retried 
the install. Failed on format exactly as before. Disk subsystem scanned, no 
errors found, no hardware problems have occurred previously, this is a highly 
stable testbed machine which has been in use for years.

[Qemu-devel] Re: [V9fs-developer] [PATCH] [virtio-9p] Server side implementation for TLINK

[Aneesh Kumar K. V]

On Sun, 30 May 2010 09:40:38 -0700, "Venkateswararao Jujjuri (JV)" 
 wrote:
> Create a link.
> 
> SYNOPSIS
> 
> size[4] Tlink tag[2] dfid[4] oldpath[s] newpath[s]
> 
> size[4] Rlink tag[2]
> 
> DESCRIPTION
> 
> Create a link 'newpath' in directory pointed by dfid linking to oldpath.
> 
> Signed-off-by: Venkateswararao Jujjuri 
> ---
>  hw/file-op-9p.h  |2 +-
>  hw/virtio-9p-debug.c |9 +
>  hw/virtio-9p-local.c |2 +-
>  hw/virtio-9p.c   |   40 
>  hw/virtio-9p.h   |2 ++
>  5 files changed, 45 insertions(+), 10 deletions(-)
> 
> diff --git a/hw/file-op-9p.h b/hw/file-op-9p.h
> index b3a320c..6744d69 100644
> --- a/hw/file-op-9p.h
> +++ b/hw/file-op-9p.h
> @@ -55,7 +55,7 @@ typedef struct FileOperations
>  int (*utime)(FsContext *, const char *, const struct utimbuf *);
>  int (*remove)(FsContext *, const char *);
>  int (*symlink)(FsContext *, const char *, const char *, FsCred *);
> -int (*link)(FsContext *, const char *, const char *, FsCred *);
> +int (*link)(FsContext *, const char *, const char *);
>  int (*setuid)(FsContext *, uid_t);
>  int (*close)(FsContext *, int);
>  int (*closedir)(FsContext *, DIR *);
> diff --git a/hw/virtio-9p-debug.c b/hw/virtio-9p-debug.c
> index a82b771..a870b97 100644
> --- a/hw/virtio-9p-debug.c
> +++ b/hw/virtio-9p-debug.c
> @@ -463,6 +463,15 @@ void pprint_pdu(V9fsPDU *pdu)
>  case P9_RCLUNK:
>  fprintf(llogfile, "RCLUNK: (");
>  break;
> +case P9_TLINK:
> +fprintf(llogfile, "TLINK: (");
> +pprint_int32(pdu, 0, &offset, "fid");
> +pprint_str(pdu, 0, &offset, ", name");
> +pprint_str(pdu, 0, &offset, ", linkname");
> +break;
> +case P9_RLINK:
> +fprintf(llogfile, "RLINK: (");
> +break;
>  case P9_TREMOVE:
>  fprintf(llogfile, "TREMOVE: (");
>  pprint_int32(pdu, 0, &offset, "fid");
> diff --git a/hw/virtio-9p-local.c b/hw/virtio-9p-local.c
> index c5678ae..fa8d05c 100644
> --- a/hw/virtio-9p-local.c
> +++ b/hw/virtio-9p-local.c
> @@ -375,7 +375,7 @@ err_end:
>  }
> 
>  static int local_link(FsContext *fs_ctx, const char *oldpath,
> -const char *newpath, FsCred *credp)
> +const char *newpath)
>  {
>  char *tmp = qemu_strdup(rpath(fs_ctx, oldpath));
>  int err;


I guess it would be good to make sure local_link use linkat with
flags = 0 to ensure that we won't follow symlinks. But that can be
seperate patch.



> diff --git a/hw/virtio-9p.c b/hw/virtio-9p.c
> index 097dce8..d36d206 100644
> --- a/hw/virtio-9p.c
> +++ b/hw/virtio-9p.c
> @@ -212,14 +212,9 @@ static int v9fs_do_symlink(V9fsState *s, V9fsCreateState 
> *vs)
>  &cred);
>  }
> 
> -static int v9fs_do_link(V9fsState *s, V9fsFidState *nfidp, V9fsCreateState 
> *vs)
> +static int v9fs_do_link(V9fsState *s, char *oldpath, char *fullname)
>  {
> -FsCred cred;
> -cred_init(&cred);
> -cred.fc_uid = nfidp->uid;
> -cred.fc_mode = vs->perm & 0777;
> -
> -return s->ops->link(&s->ctx, nfidp->path.data, vs->fullname.data, &cred);
> +return s->ops->link(&s->ctx, oldpath, fullname);
>  }
> 
>  static int v9fs_do_truncate(V9fsState *s, V9fsString *path, off_t size)
> @@ -1919,7 +1914,7 @@ static void v9fs_create_post_lstat(V9fsState *s, 
> V9fsCreateState *vs, int err)
>  err = -errno;
>  v9fs_post_create(s, vs, err);
>  }
> -err = v9fs_do_link(s, nfidp, vs);
> +err = v9fs_do_link(s, nfidp->path.data, vs->fullname.data);
>  v9fs_create_post_perms(s, vs, err);
>  } else if (vs->perm & P9_STAT_MODE_DEVICE) {
>  char ctype;
> @@ -1999,6 +1994,34 @@ out:
>  qemu_free(vs);
>  }
> 
> +static void v9fs_link(V9fsState *s, V9fsPDU *pdu)
> +{
> +int32_t dfid;
> +V9fsFidState *dfidp;
> +V9fsString name, fullname, oldname;
> +size_t offset = 7;
> +int err = 0;
> +
> +v9fs_string_init(&fullname);
> +
> +pdu_unmarshal(pdu, offset, "dss", &dfid, &oldname, &name);
> +
> +dfidp = lookup_fid(s, dfid);
> +if (dfidp == NULL) {
> +err = -errno;
> +goto out;
> +}
> +
> +v9fs_string_sprintf(&fullname, "%s/%s", dfidp->path.data, name.data);
> +err = v9fs_do_link(s, oldname.data, fullname.data);
> +v9fs_string_free(&fullname);
> +
> +out:
> +v9fs_string_free(&name);
> +v9fs_string_free(&oldname);
> +complete_pdu(s, pdu, err);
> +}
> +
>  static void v9fs_flush(V9fsState *s, V9fsPDU *pdu)
>  {
>  /* A nop call with no return */
> @@ -2354,6 +2377,7 @@ static pdu_handler_t *pdu_handlers[] = {
>  [P9_TAUTH] = v9fs_auth,
>  #endif
>  [P9_TFLUSH] = v9fs_flush,
> +[P9_TLINK] = v9fs_link,
>  [P9_TCREATE] = v9fs_create,
>  [P9_TWRITE] = v9fs_write,
>  [P9_TWSTAT] = v9fs_wstat,
> diff --git a/hw/virtio-9p.h b/hw/virtio-9p.h
> index 9773659..6b3d4a4 100644
> --- a/hw/virtio-9p.h
> +++ b/hw/virtio-9p.h
> @@ -17,6 +17,8 @@

Re: [Qemu-devel] [RFC] [PATCH 0/5] Add horizontal wheel support to mice, where possible

[Anthony Liguori]

On 05/04/2010 11:56 AM, Brad Jorsch wrote:

The emulated mice should emulate a horizontal wheel when possible. This
patch series does that for the USB mouse and tablet and the ExPS/2
mouse. As far as I can tell the vmmouse protocol doesn't handle a
horizontal wheel, and I have no idea if emulating a wheel might make
sense for any of the other mouse types.
   


At this point, are we just talking about adding additional mouse buttons?

I think instead of adding an additional parameter for horizontal wheel, 
we should look at making the API capable of accepting/generating 
arbitrary button presses.


Really, we should just drop dz and treat vertical wheel as two button 
presses within button_state.  Likewise, horizontal wheel should just be 
two additional bits within button_state.


Regards,

Anthony Liguori


I've tested this using the SDL interface and an Ububtu 10.04 cd image;
xev reports the correct events for all three devices, and a gedit window
with sufficient text to create scrollbars scrolls correctly with both
mice (didn't test the tablet). More testing would be good.

See also Debian bug #579968.[1]

[1] http://bugs.debian.org/579968



   

[Qemu-devel] [Bug 557546] Re: no sound device found in ipc 10.5.6 image

[Natalia Portillo]

iPC 10.5.6 is a hacked version of Mac OS X 10.5.6.

QEMU does not emulate any Apple sound card right now, and that's the
expected behaviour.

** Changed in: qemu
   Status: New => Invalid

-- 
no sound device found in ipc 10.5.6 image
https://bugs.launchpad.net/bugs/557546
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: Invalid

Bug description:
i have windows 7 installed on physical computer my computer configuration is 
good for install any operating system ,i success for installing windows xp 
,windows 7 and linux inside vmware 7.0.1 as virtual os  and when i heard about 
hakintosh i download ipc 10.5.6 and when installing on host computer it success 
and it work very good but when trying install it inside qemu happend what is 
not expected first it take very long time to install about 5 hours second it 
work very slow third is the important the sound is not work and no sound device 
installed in mac guest  i try many times with the same result i cant use vmware 
to install mac because vt is not enabled in bios of mb and no update avilable 
for it the question is how can i make qemu manger 6 v 0.10.2 to install sound 
device in ipc 10.5.6 virtual image although i select sound driver when creating 
vm configuration and how can i accelerate it although acceleration is installed

[Qemu-devel] [Bug 566882] Re: better sparc64 support

[Natalia Portillo]

This is not a bug.

** Changed in: qemu
   Status: New => Invalid

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

Status in QEMU: Invalid

Bug description:
Need better sparc64 platform support. Currently booting debian 5.0.4 sparc is 
not possible.

On http://wiki.qemu.org/Main_Page there is no donation site available. Is it 
possible to vote for a specific purpose for donation, like purchase a cheap 
machine which help you for porting purposes?
Possible machines are sparc64 (ultra 5 and 10 and sun blade are currently cheap 
on ebay), alpha and powerpc.

[Qemu-devel] [CFP] Bug Day 2010

[Anthony Liguori]

Hi everyone,

Today is our first QEMU Bug Day.  The goal of Bug Day is to spread some 
bug love and make a dent in the various bug trackers.  We've setup a 
special channel, #qemu-bugday on OFTC that folks can use to coordinate 
bug hunting effort.


Here's some ways you can participate in the Bug Day:

- Fixing bugs
- Marking bugs that require more information as Incomplete
- Trying to reproduce existing bugs and marking them as Confirmed
- Reporting bugs that haven't yet been reported
- Migrating bugs from the SourceForge tracker to Launchpad

More information can be found at http://wiki.qemu.org/BugDay/June2010

Happy bug hunting!

Regards,

Anthony Liguori

[Qemu-devel] [Bug 547227] Re: qemu-system-m68k does not accept "notw %d" instruction

[Natalia Portillo]

As of QEMU 0.12.3, it only emulates ColdFire processors.

Coldfire no longer implement notw, only notl instruction, so this
behaviour is expected.

** Changed in: qemu
   Status: New => Invalid

-- 
qemu-system-m68k does not accept "notw %d" instruction
https://bugs.launchpad.net/bugs/547227
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: Invalid

Bug description:
The notw and notb instructions does not work with latest version of 
qemu-system-m68k. I've tried both 0.12.3 and the latest git version compiled 
about an hour ago, both running on Arch Linux. The executable fails with the 
following output:
> qemu-system-m68k -nographic -M an5206 -kernel test.elf
qemu: fatal: Illegal instruction: 4640 @ 0006
D0 =    A0 =    F0 =  (   0)
D1 =    A1 =    F1 =  (   0)
D2 =    A2 =    F2 =  (   0)
D3 =    A3 =    F3 =  (   0)
D4 =    A4 =    F4 =  (   0)
D5 =    A5 =    F5 =  (   0)
D6 =    A6 =    F6 =  (   0)
D7 =    A7 =    F7 =  (   0)
PC =    SR = 2700 - FPRESULT =0
zsh: abort  qemu-system-m68k -nographic -M an5206 -kernel test.elf

I've attached the test.elf file, which produces the bug. It contains the 
following:
> m68k-elf-objdump -m 68000 -D test.elf  
test.elf: file format elf32-m68k
Disassembly of section .text:
 :
   0:   4e71nop
   2:   4e71nop
   4:   4e71nop
   6:   4640notw %d0
0008 :
   8:   6000 fffe   braw 8 

It works when removing the not instruction. There might be other non-working 
instructions, I've only tested a few.
Hope you'll get the bug fixed. Thanks.

[Qemu-devel] [Bug 588693] Re: CD-ROM devices always return a one session, one track TOC

[Natalia Portillo]

(P.S.: This bug prevents BeOS boot)

** Changed in: qemu
   Status: New => In Progress

-- 
CD-ROM devices always return a one session, one track TOC
https://bugs.launchpad.net/bugs/588693
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: In Progress

Bug description:
CD-ROM devices always return a one session, one track TOC, no matter if it is 
using ioctl's with the host or DMG images (both able of having multi track, 
multi session discs).

[Qemu-devel] [Bug 588691] [NEW] QEMU is not correctly detecting host CDs

[Natalia Portillo]

Public bug reported:

QEMU's block layer contains code for detecting and using ioctls when
real CD-ROM host devices are attached.

This detection is not working in some host OSes while bad implemented on
anothers.

E.g., in Linux host qemu -cdrom /dev/sr0 is not detecting it as a CD-ROM
E.g., in Mac OS X host qemu asks the kernel to enumerate optical devices and 
the compares it to the constant string "/dev/cdrom". This is useless, that 
enumeration is just enough, and "/dev/cdrom" will NEVER exist in Mac OS X 
unless manually created by the user.

** Affects: qemu
 Importance: Undecided
 Assignee: Natalia Portillo (claunia)
 Status: In Progress

** Changed in: qemu
 Assignee: (unassigned) => Natalia Portillo (claunia)

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

Status in QEMU: In Progress

Bug description:
QEMU's block layer contains code for detecting and using ioctls when real 
CD-ROM host devices are attached.

This detection is not working in some host OSes while bad implemented on 
anothers.

E.g., in Linux host qemu -cdrom /dev/sr0 is not detecting it as a CD-ROM
E.g., in Mac OS X host qemu asks the kernel to enumerate optical devices and 
the compares it to the constant string "/dev/cdrom". This is useless, that 
enumeration is just enough, and "/dev/cdrom" will NEVER exist in Mac OS X 
unless manually created by the user.