Re: [Qemu-devel] Boot order problem and disable iPXE/gPXE
On Thu, 5 Jan 2012, Gerd Hoffmann wrote: On 01/04/12 19:02, Gerhard Wiesinger wrote: Hello, I'm having the following boot order problem using an SCSI option ROM: Still boots the cdrom instead of harddisk. So it is impossible to have a bootable CDROM in the VM without booting from it. -option-rom romfile=/root/roms/8xx_64.rom,bootindex=1 Ok, works well, but I think than "-boot order=c" is buggy, right? 2.) -device rtl8139,romfile=/dev/null Better use a empty string as romfile argument, that will make the ROM pci bar go away instead of creating one with an invalid rom. Thnx. Works well by specifying no romfile, that's the trick. I had the problem than otherwise devices were created. But I'm still getting the following iPXE rom message: iPXE v1.0.0-591-g7aee315 iPXE (http://ipxe.org) 00:03.0 CA00 PCI2.10 PnP PMM+0FFCA670+0FF8A670 CA00 How to disable it, too? What's this option ROM doing? Is it a general iPXE main loader? Thnx to all who replied. Ciao, Gerhard -- http://www.wiesinger.com/
Re: [Qemu-devel] Boot order problem and disable iPXE/gPXE
On Thu, Jan 05, 2012 at 09:23:02AM +0100, Gerhard Wiesinger wrote: > On Thu, 5 Jan 2012, Gerd Hoffmann wrote: > > >On 01/04/12 19:02, Gerhard Wiesinger wrote: > >>Hello, > >> > >>I'm having the following boot order problem using an SCSI option ROM: > >> > > > >>Still boots the cdrom instead of harddisk. So it is impossible to have a > >>bootable CDROM in the VM without booting from it. > > > >-option-rom romfile=/root/roms/8xx_64.rom,bootindex=1 > > Ok, works well, but I think than "-boot order=c" is buggy, right? > Wrong. "-boot order=c" tells seabios to boot from a HD, but for that Seabios needs to actually know what is HD and what is not. Since Seabios does not support scsi controller natively it only sees pci device and has no idea that you have scsi disk there. It uses pci option rom to boot from this unknown device. > >>2.) -device rtl8139,romfile=/dev/null > > > >Better use a empty string as romfile argument, that will make the ROM > >pci bar go away instead of creating one with an invalid rom. > > Thnx. Works well by specifying no romfile, that's the trick. I had > the problem than otherwise devices were created. But I'm still > getting the > following iPXE rom message: > iPXE v1.0.0-591-g7aee315 > iPXE (http://ipxe.org) 00:03.0 CA00 PCI2.10 PnP PMM+0FFCA670+0FF8A670 CA00 > > How to disable it, too? > What's this option ROM doing? Is it a general iPXE main loader? > > Thnx to all who replied. > > Ciao, > Gerhard > > -- > http://www.wiesinger.com/ -- Gleb.
Re: [Qemu-devel] [PATCH v8] arm: add dummy v7 cp15 registers
On 5 January 2012 00:54, Mark Langsdorf wrote: > On 01/04/2012 06:22 PM, Peter Maydell wrote: >> Can you drop the SCR code, please? This needs to be done properly >> as part of trustzone support, which is a different and rather larger >> kettle of fish. > > I found out that the Highbank SoC model depends on the scr code > through four days of tedious debugging. Would it possible to keep > it in as a stub? Regardless, it shouldn't be in this patch, because it's not related to the A9-specific c15 registers. I'll have a look at the docs and see if there's a sensible minimal implementation of the SCR that we could implement. > I'm still waiting on Kevin Wolf's review of the AHCI changes You should post those as a separate 2-patch AHCI set, I think. > and > review of the last two patches from this series. These are still on my todo list, I haven't forgotten them. (However I still have a huge patchset from Samsung to review which I should probably do first.) -- PMM
Re: [Qemu-devel] Boot order problem and disable iPXE/gPXE
Hi, >> Better use a empty string as romfile argument, that will make the ROM >> pci bar go away instead of creating one with an invalid rom. > > Thnx. Works well by specifying no romfile, that's the trick. I had the > problem than otherwise devices were created. But I'm still getting the > following iPXE rom message: > iPXE v1.0.0-591-g7aee315 > iPXE (http://ipxe.org) 00:03.0 CA00 PCI2.10 PnP PMM+0FFCA670+0FF8A670 CA00 > > How to disable it, too? It shouldn't be there. I guess you've trapped into automagic device creation logic in qemu. When neither -net nor -netdev is specified on the command line qemu creates a default network setup for you, which includes a nic, and that probably is the rom of the automagically created nic. Try "qemu -netdev user,id=mynet -device rtl8139,romfile=,netdev=mynet", then it should work as expected. HTH, Gerd
Re: [Qemu-devel] Boot order problem and disable iPXE/gPXE
On Thu, 5 Jan 2012, Gleb Natapov wrote: On Thu, Jan 05, 2012 at 09:23:02AM +0100, Gerhard Wiesinger wrote: On Thu, 5 Jan 2012, Gerd Hoffmann wrote: On 01/04/12 19:02, Gerhard Wiesinger wrote: Hello, I'm having the following boot order problem using an SCSI option ROM: Still boots the cdrom instead of harddisk. So it is impossible to have a bootable CDROM in the VM without booting from it. -option-rom romfile=/root/roms/8xx_64.rom,bootindex=1 Ok, works well, but I think than "-boot order=c" is buggy, right? Wrong. "-boot order=c" tells seabios to boot from a HD, but for that Seabios needs to actually know what is HD and what is not. Since Seabios does not support scsi controller natively it only sees pci device and has no idea that you have scsi disk there. It uses pci option rom to boot from this unknown device. But as far as I remember therefore the option ROM registers through BIOS for INT 19h booting. So Seabios should know it that this is a harddisk. I think this usecase is currently not supported. Ciao, Gerhard -- http://www.wiesinger.com/
Re: [Qemu-devel] Boot order problem and disable iPXE/gPXE
On Thu, Jan 05, 2012 at 10:09:44AM +0100, Gerhard Wiesinger wrote: > On Thu, 5 Jan 2012, Gleb Natapov wrote: > > >On Thu, Jan 05, 2012 at 09:23:02AM +0100, Gerhard Wiesinger wrote: > >>On Thu, 5 Jan 2012, Gerd Hoffmann wrote: > >> > >>>On 01/04/12 19:02, Gerhard Wiesinger wrote: > Hello, > > I'm having the following boot order problem using an SCSI option ROM: > > >>> > Still boots the cdrom instead of harddisk. So it is impossible to have a > bootable CDROM in the VM without booting from it. > >>> > >>>-option-rom romfile=/root/roms/8xx_64.rom,bootindex=1 > >> > >>Ok, works well, but I think than "-boot order=c" is buggy, right? > >> > >Wrong. "-boot order=c" tells seabios to boot from a HD, but for that > >Seabios needs to actually know what is HD and what is not. Since Seabios > >does not support scsi controller natively it only sees pci device and > >has no idea that you have scsi disk there. It uses pci option rom to > >boot from this unknown device. > > But as far as I remember therefore the option ROM registers through > BIOS for INT 19h booting. So Seabios should know it that this is a > harddisk. It registers BEV. Otherwise you wouldn't be able to boot at all. In fact it registers multiple BEVs (one for each attached scsi device). But BIOS knows nothing about the device behind the BEV. It just jumps to BEV address to boot from it when INT 19h is called. There may be scsi cdrom there or even tape. > I think this usecase is currently not supported. > > Ciao, > Gerhard > > -- > http://www.wiesinger.com/ -- Gleb.
Re: [Qemu-devel] Boot order problem and disable iPXE/gPXE
On Thu, 5 Jan 2012, Gerd Hoffmann wrote: Hi, Better use a empty string as romfile argument, that will make the ROM pci bar go away instead of creating one with an invalid rom. Thnx. Works well by specifying no romfile, that's the trick. I had the problem than otherwise devices were created. But I'm still getting the following iPXE rom message: iPXE v1.0.0-591-g7aee315 iPXE (http://ipxe.org) 00:03.0 CA00 PCI2.10 PnP PMM+0FFCA670+0FF8A670 CA00 How to disable it, too? It shouldn't be there. I guess you've trapped into automagic device creation logic in qemu. When neither -net nor -netdev is specified on the command line qemu creates a default network setup for you, which includes a nic, and that probably is the rom of the automagically created nic. Try "qemu -netdev user,id=mynet -device rtl8139,romfile=,netdev=mynet", then it should work as expected. Old command line (relevant parameters): -net nic,model=rtl8139,macaddr=1a:46:0b:ca:bc:7c,vlan=0 -net tap,ifname=tap0,script=no,downscript=no,vlan=0 -device rtl8139,romfile= -net nic,model=pcnet,macaddr=1a:46:0b:ca:bc:7e,vlan=1 -net tap,ifname=tap1,script=no,downscript=no,vlan=1 -device pcnet,romfile= So the net option is already there but it doesn't work. Tried command line: -netdev user,id=mynet -net nic,model=rtl8139,macaddr=1a:46:0b:ca:bc:7c,vlan=0 -net tap,ifname=tap0,script=no,downscript=no,vlan=0 -device rtl8139,romfile=,netdev=mynet -net nic,model=pcnet,macaddr=1a:46:0b:ca:bc:7e,vlan=1 -net tap,ifname=tap1,script=no,downscript=no,vlan=1 -device pcnet,romfile=,netdev=mynet qemu-system-x86_64: -device pcnet,romfile=,netdev=mynet: Property 'pcnet.netdev' can't take value 'mynet', it's in use I guess this might come from 2 NICs. Any further ideas? BTW: I had the problem with DUAL NICs that when vlan=x isn't specified whole network is dead. Is this the correct command line? br0: received packet on tap0 with own address as source address # http://lists.freebsd.org/pipermail/freebsd-emulation/2009-June/006222.html config with tun devices: brctl show bridge name bridge id STP enabled interfaces br0 8000.001fcff4d4ea no eth0 tap0 tap1 Thnx. Ciao, Gerhard -- http://www.wiesinger.com/
Re: [Qemu-devel] Boot order problem and disable iPXE/gPXE
On Thu, 5 Jan 2012, Gleb Natapov wrote: On Thu, Jan 05, 2012 at 10:09:44AM +0100, Gerhard Wiesinger wrote: On Thu, 5 Jan 2012, Gleb Natapov wrote: On Thu, Jan 05, 2012 at 09:23:02AM +0100, Gerhard Wiesinger wrote: On Thu, 5 Jan 2012, Gerd Hoffmann wrote: On 01/04/12 19:02, Gerhard Wiesinger wrote: Hello, I'm having the following boot order problem using an SCSI option ROM: Still boots the cdrom instead of harddisk. So it is impossible to have a bootable CDROM in the VM without booting from it. -option-rom romfile=/root/roms/8xx_64.rom,bootindex=1 Ok, works well, but I think than "-boot order=c" is buggy, right? Wrong. "-boot order=c" tells seabios to boot from a HD, but for that Seabios needs to actually know what is HD and what is not. Since Seabios does not support scsi controller natively it only sees pci device and has no idea that you have scsi disk there. It uses pci option rom to boot from this unknown device. But as far as I remember therefore the option ROM registers through BIOS for INT 19h booting. So Seabios should know it that this is a harddisk. It registers BEV. Otherwise you wouldn't be able to boot at all. In fact it registers multiple BEVs (one for each attached scsi device). But BIOS knows nothing about the device behind the BEV. It just jumps to BEV address to boot from it when INT 19h is called. There may be scsi cdrom there or even tape. But to get rid of this problem typical BIOSes have an option whether they prefer to BOOT from SCSI (with an option ROM) or from the other devices. Then the option ROM typically boots from the first registered device. I think this is a missing feature in Seabios. Ciao, Gerhard -- http://www.wiesinger.com/
Re: [Qemu-devel] Boot order problem and disable iPXE/gPXE
On Thu, Jan 05, 2012 at 10:27:44AM +0100, Gerhard Wiesinger wrote: > On Thu, 5 Jan 2012, Gleb Natapov wrote: > > >On Thu, Jan 05, 2012 at 10:09:44AM +0100, Gerhard Wiesinger wrote: > >>On Thu, 5 Jan 2012, Gleb Natapov wrote: > >> > >>>On Thu, Jan 05, 2012 at 09:23:02AM +0100, Gerhard Wiesinger wrote: > On Thu, 5 Jan 2012, Gerd Hoffmann wrote: > > >On 01/04/12 19:02, Gerhard Wiesinger wrote: > >>Hello, > >> > >>I'm having the following boot order problem using an SCSI option ROM: > >> > > > >>Still boots the cdrom instead of harddisk. So it is impossible to have a > >>bootable CDROM in the VM without booting from it. > > > >-option-rom romfile=/root/roms/8xx_64.rom,bootindex=1 > > Ok, works well, but I think than "-boot order=c" is buggy, right? > > >>>Wrong. "-boot order=c" tells seabios to boot from a HD, but for that > >>>Seabios needs to actually know what is HD and what is not. Since Seabios > >>>does not support scsi controller natively it only sees pci device and > >>>has no idea that you have scsi disk there. It uses pci option rom to > >>>boot from this unknown device. > >> > >>But as far as I remember therefore the option ROM registers through > >>BIOS for INT 19h booting. So Seabios should know it that this is a > >>harddisk. > >It registers BEV. Otherwise you wouldn't be able to boot at all. In fact > >it registers multiple BEVs (one for each attached scsi device). But BIOS > >knows nothing about the device behind the BEV. It just jumps to BEV > >address to boot from it when INT 19h is called. There may be scsi cdrom > >there or even tape. > > But to get rid of this problem typical BIOSes have an option whether > they prefer to BOOT from SCSI (with an option ROM) or > from the other devices. Then the option ROM typically boots from the > first registered device. > > I think this is a missing feature in Seabios. > How is it missing if you just used it and confirmed that it worked? -- Gleb.
Re: [Qemu-devel] Boot order problem and disable iPXE/gPXE
On Thu, 5 Jan 2012, Gleb Natapov wrote: On Thu, Jan 05, 2012 at 10:27:44AM +0100, Gerhard Wiesinger wrote: On Thu, 5 Jan 2012, Gleb Natapov wrote: On Thu, Jan 05, 2012 at 10:09:44AM +0100, Gerhard Wiesinger wrote: On Thu, 5 Jan 2012, Gleb Natapov wrote: On Thu, Jan 05, 2012 at 09:23:02AM +0100, Gerhard Wiesinger wrote: On Thu, 5 Jan 2012, Gerd Hoffmann wrote: On 01/04/12 19:02, Gerhard Wiesinger wrote: Hello, I'm having the following boot order problem using an SCSI option ROM: Still boots the cdrom instead of harddisk. So it is impossible to have a bootable CDROM in the VM without booting from it. -option-rom romfile=/root/roms/8xx_64.rom,bootindex=1 Ok, works well, but I think than "-boot order=c" is buggy, right? Wrong. "-boot order=c" tells seabios to boot from a HD, but for that Seabios needs to actually know what is HD and what is not. Since Seabios does not support scsi controller natively it only sees pci device and has no idea that you have scsi disk there. It uses pci option rom to boot from this unknown device. But as far as I remember therefore the option ROM registers through BIOS for INT 19h booting. So Seabios should know it that this is a harddisk. It registers BEV. Otherwise you wouldn't be able to boot at all. In fact it registers multiple BEVs (one for each attached scsi device). But BIOS knows nothing about the device behind the BEV. It just jumps to BEV address to boot from it when INT 19h is called. There may be scsi cdrom there or even tape. But to get rid of this problem typical BIOSes have an option whether they prefer to BOOT from SCSI (with an option ROM) or from the other devices. Then the option ROM typically boots from the first registered device. I think this is a missing feature in Seabios. How is it missing if you just used it and confirmed that it worked? It had to specify it on the option ROM itself. But I think a generic way would be e.g.: boot=SCSI,c,a Ciao, Gerhard -- http://www.wiesinger.com/
Re: [Qemu-devel] Boot order problem and disable iPXE/gPXE
On Thu, Jan 05, 2012 at 10:36:29AM +0100, Gerhard Wiesinger wrote: > On Thu, 5 Jan 2012, Gleb Natapov wrote: > > >On Thu, Jan 05, 2012 at 10:27:44AM +0100, Gerhard Wiesinger wrote: > >>On Thu, 5 Jan 2012, Gleb Natapov wrote: > >> > >>>On Thu, Jan 05, 2012 at 10:09:44AM +0100, Gerhard Wiesinger wrote: > On Thu, 5 Jan 2012, Gleb Natapov wrote: > > >On Thu, Jan 05, 2012 at 09:23:02AM +0100, Gerhard Wiesinger wrote: > >>On Thu, 5 Jan 2012, Gerd Hoffmann wrote: > >> > >>>On 01/04/12 19:02, Gerhard Wiesinger wrote: > Hello, > > I'm having the following boot order problem using an SCSI option ROM: > > >>> > Still boots the cdrom instead of harddisk. So it is impossible to > have a > bootable CDROM in the VM without booting from it. > >>> > >>>-option-rom romfile=/root/roms/8xx_64.rom,bootindex=1 > >> > >>Ok, works well, but I think than "-boot order=c" is buggy, right? > >> > >Wrong. "-boot order=c" tells seabios to boot from a HD, but for that > >Seabios needs to actually know what is HD and what is not. Since Seabios > >does not support scsi controller natively it only sees pci device and > >has no idea that you have scsi disk there. It uses pci option rom to > >boot from this unknown device. > > But as far as I remember therefore the option ROM registers through > BIOS for INT 19h booting. So Seabios should know it that this is a > harddisk. > >>>It registers BEV. Otherwise you wouldn't be able to boot at all. In fact > >>>it registers multiple BEVs (one for each attached scsi device). But BIOS > >>>knows nothing about the device behind the BEV. It just jumps to BEV > >>>address to boot from it when INT 19h is called. There may be scsi cdrom > >>>there or even tape. > >> > >>But to get rid of this problem typical BIOSes have an option whether > >>they prefer to BOOT from SCSI (with an option ROM) or > >>from the other devices. Then the option ROM typically boots from the > >>first registered device. > >> > >>I think this is a missing feature in Seabios. > >> > >How is it missing if you just used it and confirmed that it worked? > > It had to specify it on the option ROM itself. But I think a generic > way would be e.g.: > boot=SCSI,c,a > boot option is deprecated in favor of bootindex. The later has much more fine grained control of boot sequence. What if you have 5 SCSI controllers? Even boot=c does not tell you much if you have more then one disk. -- Gleb.
Re: [Qemu-devel] Boot order problem and disable iPXE/gPXE
Hi, > But to get rid of this problem typical BIOSes have an option whether > they prefer to BOOT from SCSI (with an option ROM) or > from the other devices. Then the option ROM typically boots from the > first registered device. qemu+seabios have bootindex to address that issue. It was created exactly because "boot from hard disk" isn't good enougth with multiple disks in the system ... cheers, gerd
Re: [Qemu-devel] Boot order problem and disable iPXE/gPXE
On 01/05/12 10:24, Gerhard Wiesinger wrote: > On Thu, 5 Jan 2012, Gerd Hoffmann wrote: >> Hi, >> Better use a empty string as romfile argument, that will make the ROM pci bar go away instead of creating one with an invalid rom. >>> >>> Thnx. Works well by specifying no romfile, that's the trick. I had the >>> problem than otherwise devices were created. But I'm still getting the >>> following iPXE rom message: >>> iPXE v1.0.0-591-g7aee315 >>> iPXE (http://ipxe.org) 00:03.0 CA00 PCI2.10 PnP PMM+0FFCA670+0FF8A670 >>> CA00 >>> >>> How to disable it, too? >> >> It shouldn't be there. I guess you've trapped into automagic device >> creation logic in qemu. When neither -net nor -netdev is specified on >> the command line qemu creates a default network setup for you, which >> includes a nic, and that probably is the rom of the automagically >> created nic. >> >> Try "qemu -netdev user,id=mynet -device rtl8139,romfile=,netdev=mynet", >> then it should work as expected. > > Old command line (relevant parameters): > -net nic,model=rtl8139,macaddr=1a:46:0b:ca:bc:7c,vlan=0 creates a nic (with rom). > -net tap,ifname=tap0,script=no,downscript=no,vlan=0 creates a tap device > -device rtl8139,romfile= creates a nic too (without rom), so you have two rtl8139 devices now ... You probably want this: -net tap,ifname=tap0,script=no,downscript=no,vlan=0 -device rtl8139,romfile=,macaddr=1a:46:0b:ca:bc:7c,vlan=0 Or when using netdevs instead of vlans: -netdev tap,ifname=tap0,script=no,downscript=no,id=net0 -device rtl8139,romfile=,macaddr=1a:46:0b:ca:bc:7c,netdev=net0 Likewise for the second nic, just with vlan=1 (or a different name for the netdev). HTH, Gerd
Re: [Qemu-devel] Boot order problem and disable iPXE/gPXE
On Thu, 5 Jan 2012, Gleb Natapov wrote: boot option is deprecated in favor of bootindex. The later has much more fine grained control of boot sequence. What if you have 5 SCSI controllers? Even boot=c does not tell you much if you have more then one disk. Ok, then this is a documentation issue (command line, etc.): 1.) boot should be documented as deprecated with "use bootindex instead" 2.) bootindex should be documented at all Thnx so far. Ciao, Gerhard -- http://www.wiesinger.com/
Re: [Qemu-devel] Boot order problem and disable iPXE/gPXE
On Thu, Jan 05, 2012 at 10:56:23AM +0100, Gerhard Wiesinger wrote: > On Thu, 5 Jan 2012, Gleb Natapov wrote: > >boot option is deprecated in favor of bootindex. The later has much more > >fine grained control of boot sequence. What if you have 5 SCSI > >controllers? Even boot=c does not tell you much if you have more then > >one disk. > > Ok, then this is a documentation issue (command line, etc.): > 1.) boot should be documented as deprecated with "use bootindex instead" > 2.) bootindex should be documented at all > Agree. Documentation is missing. bootindex is a device property (in QEMU terms) and those are not documented in qemu help screen. Don't know where is the proper place to add documentation for that. -- Gleb.
Re: [Qemu-devel] [PATCH] virtio-blk: refuse SG_IO requests with scsi=off
On 12/23/2011 03:39 PM, Paolo Bonzini wrote:
QEMU does have a "scsi" option (to be used like -device
virtio-blk-pci,drive=foo,scsi=off). However, it only
masks the feature bit, and does not reject the command
if a malicious guest disregards the feature bits and
issues a request.
Without this patch, using scsi=off does not protect you
from CVE-2011-4127.
Signed-off-by: Paolo Bonzini
---
hw/virtio-blk.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/hw/virtio-blk.c b/hw/virtio-blk.c
index b70d116..6cd3164 100644
--- a/hw/virtio-blk.c
+++ b/hw/virtio-blk.c
@@ -153,6 +153,12 @@ static void virtio_blk_handle_scsi(VirtIOBlockReq *req)
int status;
int i;
+if ((req->dev->vdev.guest_features& (1<< VIRTIO_BLK_F_SCSI)) == 0) {
+virtio_blk_req_complete(req, VIRTIO_BLK_S_UNSUPP);
+g_free(req);
+return;
+}
+
/*
* We require at least one output segment each for the virtio_blk_outhdr
* and the SCSI command block.
Ping.
Paolo
Re: [Qemu-devel] Boot order problem and disable iPXE/gPXE
On Thu, 5 Jan 2012, Gerd Hoffmann wrote: On 01/05/12 10:24, Gerhard Wiesinger wrote: On Thu, 5 Jan 2012, Gerd Hoffmann wrote: Hi, Better use a empty string as romfile argument, that will make the ROM pci bar go away instead of creating one with an invalid rom. Thnx. Works well by specifying no romfile, that's the trick. I had the problem than otherwise devices were created. But I'm still getting the following iPXE rom message: iPXE v1.0.0-591-g7aee315 iPXE (http://ipxe.org) 00:03.0 CA00 PCI2.10 PnP PMM+0FFCA670+0FF8A670 CA00 How to disable it, too? It shouldn't be there. I guess you've trapped into automagic device creation logic in qemu. When neither -net nor -netdev is specified on the command line qemu creates a default network setup for you, which includes a nic, and that probably is the rom of the automagically created nic. Try "qemu -netdev user,id=mynet -device rtl8139,romfile=,netdev=mynet", then it should work as expected. Old command line (relevant parameters): -net nic,model=rtl8139,macaddr=1a:46:0b:ca:bc:7c,vlan=0 creates a nic (with rom). -net tap,ifname=tap0,script=no,downscript=no,vlan=0 creates a tap device -device rtl8139,romfile= creates a nic too (without rom), so you have two rtl8139 devices now ... You probably want this: -net tap,ifname=tap0,script=no,downscript=no,vlan=0 -device rtl8139,romfile=,macaddr=1a:46:0b:ca:bc:7c,vlan=0 Or when using netdevs instead of vlans: -netdev tap,ifname=tap0,script=no,downscript=no,id=net0 -device rtl8139,romfile=,macaddr=1a:46:0b:ca:bc:7c,netdev=net0 Likewise for the second nic, just with vlan=1 (or a different name for the netdev). Tried: -device rtl8139,macaddr=1a:46:0b:ca:bc:7c,vlan=0,romfile= -net tap,ifname=tap0,script=no,downscript=no,vlan=0 -device pcnet,macaddr=1a:46:0b:ca:bc:7e,vlan=1,romfile= -net tap,ifname=tap1,script=no,downscript=no,vlan=1 qemu-system-x86_64: -device rtl8139,macaddr=1a:46:0b:ca:bc:7c,vlan=0,romfile=: Property 'rtl8139.macaddr' not found So therefore as I suggested in the first email the rom (or romfile) parameter in the "-net nic parameter" Any other ideas? Thnx for help. Ciao, Gerhard -- http://www.wiesinger.com/
Re: [Qemu-devel] Boot order problem and disable iPXE/gPXE
Hi, > qemu-system-x86_64: -device > rtl8139,macaddr=1a:46:0b:ca:bc:7c,vlan=0,romfile=: Property > 'rtl8139.macaddr' not found Oops. It is mac=..., not macaddr=... cheers, Gerd
Re: [Qemu-devel] [PATCH v4 0/2]: qemu-ga: Add the guest-suspend command
On Wed, Jan 04, 2012 at 05:45:11PM -0200, Luiz Capitulino wrote: > This version drops modes 'sleep' and 'hybrid' because they don't work > properly due to issues in qemu. Only the 'hibernate' mode is supported > for now. IMHO this is short-sighted. When the bugs QEMU in are fixed so that these modes work, you have needlessly put users in the situation where they have to now upgrade the guest agent everywhere to take advantage of the bugfix. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Re: [Qemu-devel] 回??: [PATCH 2/2] umem: chardevice for kvm postcopy
On Thu, Jan 05, 2012 at 12:08:50PM +0800, thfbjyddx wrote:
> hi,
> I've tried to use this patch,
Oh great! Can we share your results?
> but it doesn't work for compiling error on
>
> page = alloc_page_vma(GFP_HIGHUSER_MOVABLE, vma, vmf->address);//vmf->
> virtual_address?
>
> I guess it's for the wrong kernel version?
> can you give me some detail about this or any clue?
> 3x
Thank you for report. The following should fix.
It depends on kernel configuration. My config didn't catch it.
diff --git a/drivers/char/umem.c b/drivers/char/umem.c
index 4d031b5..853f1ce 100644
--- a/drivers/char/umem.c
+++ b/drivers/char/umem.c
@@ -129,7 +129,7 @@ static int umem_minor_fault(struct umem *umem,
* vmf->page = fake_vmf->page;
*/
- page = alloc_page_vma(GFP_HIGHUSER_MOVABLE, vma, vmf->address);
+ page = alloc_page_vma(GFP_HIGHUSER_MOVABLE, vma, vmf->virtual_address);
if (!page)
return VM_FAULT_OOM;
if (mem_cgroup_cache_charge(page, vma->vm_mm, GFP_KERNEL)) {
--
yamahata
[Qemu-devel] vhost broken?
Hi, current master seems to corrupt guest memory, I get guest errors like this one: swap_dup: Bad swap file entry 1999800080 BUG: Bad page map in process udevd pte:bec5f30054520100 pmd:1f6f4067 addr:7fc464a02000 vm_flags:00100073 anon_vma:88001f928ec0 mapping:(null) index:7fc464a02 Pid: 555, comm: udevd Not tainted 2.6.32-220.el6.x86_64 #1 bisecting points to this commit: commit 04097f7c5957273c578f72b9bd603ba6b1d69e33 Author: Avi Kivity Date: Sun Dec 18 14:06:05 2011 +0200 vhost: convert to MemoryListener API cheers, Gerd
Re: [Qemu-devel] 回??: [PATCH 2/2] umem: chardevice for kvm postcopy
After I use this series of patches, but the migration failed.
2, I start migrate -d -p -n tcp:xxx: on the outgoing node
2, on the incoming part, the qemu get stuck and migration failed
the destnation can not typing any more
today I found it's just at qemu_loadvm_state, just after the while loop ,maybe
in cpu_synchronize_all_post_init
I think there is some problems with qemu side for it doesn't get to the umem
part
I'm not sure about the problem
do you have some suggestion?
Tommy
From: Isaku Yamahata
Date: 2012-01-05 18:48
To: thfbjyddx
CC: t.hirofuchi; qemu-devel; kvm; satoshi.itoh
Subject: Re: [Qemu-devel]回??: [PATCH 2/2] umem: chardevice for kvm postcopy
On Thu, Jan 05, 2012 at 12:08:50PM +0800, thfbjyddx wrote:
> hi,
> I've tried to use this patch,
Oh great! Can we share your results?
> but it doesn't work for compiling error on
>
> page = alloc_page_vma(GFP_HIGHUSER_MOVABLE, vma, vmf->address);//vmf->
> virtual_address?
>
> I guess it's for the wrong kernel version?
> can you give me some detail about this or any clue?
> 3x
Thank you for report. The following should fix.
It depends on kernel configuration. My config didn't catch it.
diff --git a/drivers/char/umem.c b/drivers/char/umem.c
index 4d031b5..853f1ce 100644
--- a/drivers/char/umem.c
+++ b/drivers/char/umem.c
@@ -129,7 +129,7 @@ static int umem_minor_fault(struct umem *umem,
* vmf->page = fake_vmf->page;
*/
- page = alloc_page_vma(GFP_HIGHUSER_MOVABLE, vma, vmf->address);
+ page = alloc_page_vma(GFP_HIGHUSER_MOVABLE, vma, vmf->virtual_address);
if (!page)
return VM_FAULT_OOM;
if (mem_cgroup_cache_charge(page, vma->vm_mm, GFP_KERNEL)) {
--
yamahata
Re: [Qemu-devel] Boot order problem and disable iPXE/gPXE
On Thu, 5 Jan 2012, Gerd Hoffmann wrote: qemu-system-x86_64: -device rtl8139,macaddr=1a:46:0b:ca:bc:7c,vlan=0,romfile=: Property 'rtl8139.macaddr' not found Oops. It is mac=..., not macaddr=... Just for the records, working config looks like: /root/download/qemu/git/qemu-kvm/x86_64-softmmu/qemu-system-x86_64 -drive file=1.img,media=disk,if=scsi,bus=0,unit=0 -drive file=2.img,media=disk,if=scsi,bus=0,unit=1 -drive file=3.img,media=disk,if=scsi,bus=0,unit=2 -drive file=4.img,media=disk,if=scsi,bus=0,unit=3 -cdrom ISO/KNOPPIX_V6.2CD-2009-11-18-DE.iso -boot order=c -m 256 -k de -vga vmware -vnc :0 -bios /root/download/seabios/git/seabios/out/bios.bin -option-rom BIOS/8xx_64.rom,bootindex=1 -device rtl8139,mac=1a:46:0b:ca:bc:7c,vlan=0,romfile= -net tap,ifname=tap0,script=no,downscript=no,vlan=0 -device pcnet,mac=1a:46:0b:ca:bc:7e,vlan=1,romfile= -net tap,ifname=tap1,script=no,downscript=no,vlan=1 Boots from harddisk well. Last question: how will enabling the boot menu be enabled with bootindex option? Can someone add such a complex sample to documentation? Thnx to all. Ciao, Gerhard -- http://www.wiesinger.com/
Re: [Qemu-devel] vhost broken?
On 01/05/2012 01:05 PM, Gerd Hoffmann wrote: > Hi, > > current master seems to corrupt guest memory, I get guest errors like > this one: > > swap_dup: Bad swap file entry 1999800080 > BUG: Bad page map in process udevd pte:bec5f30054520100 pmd:1f6f4067 > addr:7fc464a02000 vm_flags:00100073 anon_vma:88001f928ec0 > mapping:(null) index:7fc464a02 > Pid: 555, comm: udevd Not tainted 2.6.32-220.el6.x86_64 #1 > > bisecting points to this commit: > > commit 04097f7c5957273c578f72b9bd603ba6b1d69e33 > Author: Avi Kivity > Date: Sun Dec 18 14:06:05 2011 +0200 > > vhost: convert to MemoryListener API > Very likely. Michael, can you help? I don't have a vhost setup, can you share your command line? -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] Boot order problem and disable iPXE/gPXE
On Thu, Jan 05, 2012 at 12:13:34PM +0100, Gerhard Wiesinger wrote: > On Thu, 5 Jan 2012, Gerd Hoffmann wrote: > >>qemu-system-x86_64: -device > >>rtl8139,macaddr=1a:46:0b:ca:bc:7c,vlan=0,romfile=: Property > >>'rtl8139.macaddr' not found > > > >Oops. It is mac=..., not macaddr=... > > Just for the records, working config looks like: > /root/download/qemu/git/qemu-kvm/x86_64-softmmu/qemu-system-x86_64 > -drive file=1.img,media=disk,if=scsi,bus=0,unit=0 > -drive file=2.img,media=disk,if=scsi,bus=0,unit=1 > -drive file=3.img,media=disk,if=scsi,bus=0,unit=2 > -drive file=4.img,media=disk,if=scsi,bus=0,unit=3 > -cdrom ISO/KNOPPIX_V6.2CD-2009-11-18-DE.iso > -boot order=c -m 256 -k de -vga vmware -vnc :0 > -bios /root/download/seabios/git/seabios/out/bios.bin -option-rom > BIOS/8xx_64.rom,bootindex=1 > -device rtl8139,mac=1a:46:0b:ca:bc:7c,vlan=0,romfile= > -net tap,ifname=tap0,script=no,downscript=no,vlan=0 > -device pcnet,mac=1a:46:0b:ca:bc:7e,vlan=1,romfile= > -net tap,ifname=tap1,script=no,downscript=no,vlan=1 > > Boots from harddisk well. > > Last question: how will enabling the boot menu be enabled with > bootindex option? > Well, you are doing it with good old -boot option :) Add "-boot menu=on" to your command line, but specify boot order using bootindex. > Can someone add such a complex sample to documentation? > > Thnx to all. > > Ciao, > Gerhard > > -- > http://www.wiesinger.com/ -- Gleb.
Re: [Qemu-devel] [PATCH] xen: Fix after recent change in dirty bitmap tracking.
On Wed, 4 Jan 2012, Anthony PERARD wrote:
> A recent patch set from Avi break the dirty bitmap support of Xen. But this is
> because the internal function will return an error for an unhandled memory
> region (a - b).
s/the internal function/xen_sync_dirty_bitmap
> But this is not an error. So the patch clarify the
> function from this point of view.
Please change the two lines above into
"However this is not a fatal error, so we should just continue instead
of aborting."
> There is now an error print when the Xen call failed.
printed
> Signed-off-by: Anthony PERARD
please send again with a fixed commit message
> ---
> xen-all.c | 38 ++
> 1 files changed, 18 insertions(+), 20 deletions(-)
>
> diff --git a/xen-all.c b/xen-all.c
> index dc23265..2aa8c03 100644
> --- a/xen-all.c
> +++ b/xen-all.c
> @@ -403,9 +403,9 @@ static void xen_region_del(MemoryListener *listener,
> xen_set_memory(listener, section, false);
> }
>
> -static int xen_sync_dirty_bitmap(XenIOState *state,
> - target_phys_addr_t start_addr,
> - ram_addr_t size)
> +static void xen_sync_dirty_bitmap(XenIOState *state,
> + target_phys_addr_t start_addr,
> + ram_addr_t size)
> {
> target_phys_addr_t npages = size >> TARGET_PAGE_BITS;
> target_phys_addr_t vram_offset = 0;
> @@ -417,21 +417,27 @@ static int xen_sync_dirty_bitmap(XenIOState *state,
> physmap = get_physmapping(state, start_addr, size);
> if (physmap == NULL) {
> /* not handled */
> -return -1;
> +return;
> }
>
> if (state->log_for_dirtybit == NULL) {
> state->log_for_dirtybit = physmap;
> } else if (state->log_for_dirtybit != physmap) {
> -return -1;
> +/* Only one range for dirty bitmap can be tracked. */
> +return;
> }
> vram_offset = physmap->phys_offset;
>
> rc = xc_hvm_track_dirty_vram(xen_xc, xen_domid,
> start_addr >> TARGET_PAGE_BITS, npages,
> bitmap);
> -if (rc) {
> -return rc;
> +if (rc < 0) {
> +if (rc != -ENODATA) {
> +fprintf(stderr, "xen: track_dirty_vram failed (0x" TARGET_FMT_plx
> +", 0x" TARGET_FMT_plx "): %s\n",
> +start_addr, start_addr + size, strerror(-rc));
> +}
> +return;
> }
>
> for (i = 0; i < ARRAY_SIZE(bitmap); i++) {
> @@ -442,40 +448,32 @@ static int xen_sync_dirty_bitmap(XenIOState *state,
> cpu_physical_memory_set_dirty(vram_offset + (i * width + j) *
> TARGET_PAGE_SIZE);
> };
> }
> -
> -return 0;
> }
>
> static void xen_log_start(MemoryListener *listener,
>MemoryRegionSection *section)
> {
> XenIOState *state = container_of(listener, XenIOState, memory_listener);
> -int r;
>
> -r = xen_sync_dirty_bitmap(state, section->offset_within_address_space,
> - section->size);
> -assert(r >= 0);
> +xen_sync_dirty_bitmap(state, section->offset_within_address_space,
> + section->size);
> }
>
> static void xen_log_stop(MemoryListener *listener, MemoryRegionSection
> *section)
> {
> XenIOState *state = container_of(listener, XenIOState, memory_listener);
> -int r;
>
> state->log_for_dirtybit = NULL;
> /* Disable dirty bit tracking */
> -r = xc_hvm_track_dirty_vram(xen_xc, xen_domid, 0, 0, NULL);
> -assert(r >= 0);
> +xc_hvm_track_dirty_vram(xen_xc, xen_domid, 0, 0, NULL);
> }
>
> static void xen_log_sync(MemoryListener *listener, MemoryRegionSection
> *section)
> {
> XenIOState *state = container_of(listener, XenIOState, memory_listener);
> -int r;
>
> -r = xen_sync_dirty_bitmap(state, section->offset_within_address_space,
> - section->size);
> -assert(r >= 0);
> +xen_sync_dirty_bitmap(state, section->offset_within_address_space,
> + section->size);
> }
>
> static void xen_log_global_start(MemoryListener *listener)
> --
> tg: (61ec004..) fix/sync-dirty-bitmap (depends on: master)
>
Re: [Qemu-devel] vhost broken?
Hi, > I don't have a vhost setup, can you share your command line? Just use libvirt which enables it automagically if possible ;) Command line from /var/log/libvirt/qemu/rhel6-org-scsi.lsi.log is below (but probably doesn't buy you that much as it wouldn't work without the vhost/tap fd setup libvirt is doing). cheers, Gerd LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin QEMU_AUDIO_DRV=spice /home/kraxel/bin/qemu-default -S -M pc-1.0 -enable-kvm -m 512 -smp 1,sockets=1,cores=1,threads=1 -name rhel6-org-scsi.lsi -uuid d67eb0e9-6a0d-faa0-308e-898692f8700d -nodefconfig -nodefaults -device sga -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/rhel6-org-scsi.lsi.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot order=c,menu=on -device lsi,id=scsi0,bus=pci.0,addr=0x5 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x9 -drive file=/vmdisk/guests/rhel6.img,if=none,id=drive-scsi0-0-0,format=qcow2,cache=none,aio=threads -device scsi-disk,bus=scsi0.0,scsi-id=0,drive=drive-scsi0-0-0,id=scsi0-0-0 -netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=27 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:c4:31:86,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -usb -device usb-tablet,id=input0 -spice port=5900,addr=127.0.0.1,disable-ticketing -vga qxl -global qxl-vga.vram_size=67108864 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 -bios /home/kraxel/rhel6/seabios/out/bios.bin -readconfig /home/kraxel/rhel6/qemu-kvm/docs/ich9-ehci-uhci.cfg -readconfig /root/libvirt/all-usbdrives.cfg -readconfig /root/libvirt/rhel6.cfg -trace events=/root/libvirt/usb-host.events -option-rom romfile=/root/roms/8xx_64.rom,bootindex=1
Re: [Qemu-devel] vhost broken?
On Thu, Jan 05, 2012 at 01:16:22PM +0200, Avi Kivity wrote: > On 01/05/2012 01:05 PM, Gerd Hoffmann wrote: > > Hi, > > > > current master seems to corrupt guest memory, I get guest errors like > > this one: > > > > swap_dup: Bad swap file entry 1999800080 > > BUG: Bad page map in process udevd pte:bec5f30054520100 pmd:1f6f4067 > > addr:7fc464a02000 vm_flags:00100073 anon_vma:88001f928ec0 > > mapping:(null) index:7fc464a02 > > Pid: 555, comm: udevd Not tainted 2.6.32-220.el6.x86_64 #1 > > > > bisecting points to this commit: > > > > commit 04097f7c5957273c578f72b9bd603ba6b1d69e33 > > Author: Avi Kivity > > Date: Sun Dec 18 14:06:05 2011 +0200 > > > > vhost: convert to MemoryListener API > > > > Very likely. Michael, can you help? > > I don't have a vhost setup, can you share your command line? All you need to do is take your existing -netdev command line, and add in the parameter: vhost=on Libvirt does some extra stuff like passing down a pre-opened vhost file descriptor, but you can ignore that for just testing the core functionality. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
[Qemu-devel] [PATCH V2] xen: Fix after recent change in dirty bitmap tracking.
A recent patch set from Avi break the dirty bitmap support of Xen. But this is
because xen_sync_dirty_bitmap will return an error for an unhandled memory
range (a - b). However this is not a fatal error, so we should just
continue instead of aborting.
There is now an error printed when the Xen call failed.
Signed-off-by: Anthony PERARD
---
xen-all.c | 38 ++
1 files changed, 18 insertions(+), 20 deletions(-)
diff --git a/xen-all.c b/xen-all.c
index dc23265..2aa8c03 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -403,9 +403,9 @@ static void xen_region_del(MemoryListener *listener,
xen_set_memory(listener, section, false);
}
-static int xen_sync_dirty_bitmap(XenIOState *state,
- target_phys_addr_t start_addr,
- ram_addr_t size)
+static void xen_sync_dirty_bitmap(XenIOState *state,
+ target_phys_addr_t start_addr,
+ ram_addr_t size)
{
target_phys_addr_t npages = size >> TARGET_PAGE_BITS;
target_phys_addr_t vram_offset = 0;
@@ -417,21 +417,27 @@ static int xen_sync_dirty_bitmap(XenIOState *state,
physmap = get_physmapping(state, start_addr, size);
if (physmap == NULL) {
/* not handled */
-return -1;
+return;
}
if (state->log_for_dirtybit == NULL) {
state->log_for_dirtybit = physmap;
} else if (state->log_for_dirtybit != physmap) {
-return -1;
+/* Only one range for dirty bitmap can be tracked. */
+return;
}
vram_offset = physmap->phys_offset;
rc = xc_hvm_track_dirty_vram(xen_xc, xen_domid,
start_addr >> TARGET_PAGE_BITS, npages,
bitmap);
-if (rc) {
-return rc;
+if (rc < 0) {
+if (rc != -ENODATA) {
+fprintf(stderr, "xen: track_dirty_vram failed (0x" TARGET_FMT_plx
+", 0x" TARGET_FMT_plx "): %s\n",
+start_addr, start_addr + size, strerror(-rc));
+}
+return;
}
for (i = 0; i < ARRAY_SIZE(bitmap); i++) {
@@ -442,40 +448,32 @@ static int xen_sync_dirty_bitmap(XenIOState *state,
cpu_physical_memory_set_dirty(vram_offset + (i * width + j) *
TARGET_PAGE_SIZE);
};
}
-
-return 0;
}
static void xen_log_start(MemoryListener *listener,
MemoryRegionSection *section)
{
XenIOState *state = container_of(listener, XenIOState, memory_listener);
-int r;
-r = xen_sync_dirty_bitmap(state, section->offset_within_address_space,
- section->size);
-assert(r >= 0);
+xen_sync_dirty_bitmap(state, section->offset_within_address_space,
+ section->size);
}
static void xen_log_stop(MemoryListener *listener, MemoryRegionSection
*section)
{
XenIOState *state = container_of(listener, XenIOState, memory_listener);
-int r;
state->log_for_dirtybit = NULL;
/* Disable dirty bit tracking */
-r = xc_hvm_track_dirty_vram(xen_xc, xen_domid, 0, 0, NULL);
-assert(r >= 0);
+xc_hvm_track_dirty_vram(xen_xc, xen_domid, 0, 0, NULL);
}
static void xen_log_sync(MemoryListener *listener, MemoryRegionSection
*section)
{
XenIOState *state = container_of(listener, XenIOState, memory_listener);
-int r;
-r = xen_sync_dirty_bitmap(state, section->offset_within_address_space,
- section->size);
-assert(r >= 0);
+xen_sync_dirty_bitmap(state, section->offset_within_address_space,
+ section->size);
}
static void xen_log_global_start(MemoryListener *listener)
--
tg: (61ec004..) fix/sync-dirty-bitmap (depends on: master)
Re: [Qemu-devel] [PATCH] PPC: Bump qemu-system-ppc to 64-bit physical address space
Dear Mr. ppc, Am 18.10.2011 01:52, schrieb Alexander Graf: > Some 32-bit PPC CPUs can use up to 36 bit of physicall address space. > Treat them accordingly in the qemu-system-ppc binary type. This change broke the prep machine. :( With -nographic I see: ERROR: BUG caught... BIOS execution exception nip=0x0580 msr=0x2000 dar=0x dsisr=0x Stopping execution > Signed-off-by: Alexander Graf > --- > configure|2 +- > target-ppc/cpu.h |2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/configure b/configure > index 9b4fe34..3bdb556 100755 > --- a/configure > +++ b/configure > @@ -3276,7 +3276,7 @@ case "$target_arch2" in >;; >ppc) > gdb_xml_files="power-core.xml power-fpu.xml power-altivec.xml > power-spe.xml" > -target_phys_bits=32 > +target_phys_bits=64 > target_nptl="yes" > target_libs_softmmu="$fdt_libs" >;; > diff --git a/target-ppc/cpu.h b/target-ppc/cpu.h > index 8e5c85c..f36f375 100644 > --- a/target-ppc/cpu.h > +++ b/target-ppc/cpu.h > @@ -66,7 +66,7 @@ > #define TARGET_PAGE_BITS 12 > #endif /* defined(TARGET_PPCEMB) */ > > -#define TARGET_PHYS_ADDR_SPACE_BITS 32 > +#define TARGET_PHYS_ADDR_SPACE_BITS 36 If I revert this part, previous behavior is restored. So it's not about libhw64 or target_phys_addr_t. Any idea? Is 6xx TLB maybe unable to cope with the larger address space? Or is this an OHW limitation? Still bisecting another regression... Andreas > #define TARGET_VIRT_ADDR_SPACE_BITS 32 > > #endif /* defined (TARGET_PPC64) */
[Qemu-devel] [Bug 912216] Re: ARM: QEMU crashes with segmentation fault on supervisor call
** Attachment added: "Elf file to be loaded by QEMU"
https://bugs.launchpad.net/bugs/912216/+attachment/2658327/+files/test1.elf
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/912216
Title:
ARM: QEMU crashes with segmentation fault on supervisor call
Status in QEMU:
New
Bug description:
I am working on some mixed C/ASM code for the ARM Cortex-M3 but when I try to
simulate it, QEMU crashes with a segmentation fault. The exact instruction it
crashes on is a supervisor call from the assembly file.
I am using the default Sourcery CodeBench Lite 2011.09-69 for ARM\EABI (Not
GNU\Linux). The build environment is mingw32 on a win7 x64 machine.
The following code is what I used to trigger the segmentation fault.
main.c:
extern void testFunc( void );
int main()
{
testFunc();
while(1);
}
test.s:
.syntax unified
.global testFunc
.global __cs3_isr_svcall
.text
.balign 4
__cs3_isr_svcall:
bx lr
.balign 4
testFunc:
svc #1
BX LR
.end
This is build in an MSYS shell with the command:
arm-none-eabi-gcc -o test1.elf main.c test.s -g -mcpu=cortex-m3
-march=armv7-m -mthumb -lc -lgcc -T generic-m-hosted.ld
The output elf file is also attached to this bug report.
To get information on the segmentation fault I start Qemu from GDB in a
debian-6 Virtual Machine (VMWare Player). This Qemu is configured with
--enable-debug and the output of this configure is:
Install prefix/usr/local
BIOS directory/usr/local/share/qemu
binary directory /usr/local/bin
library directory /usr/local/lib
include directory /usr/local/include
config directory /usr/local/etc
Manual directory /usr/local/share/man
ELF interp prefix /usr/gnemul/qemu-%M
Source path /home/testbox/Downloads/qemu-1.0
C compilergcc
Host C compiler gcc
CFLAGS-g
QEMU_CFLAGS -fPIE -DPIE -m64 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes
-Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes
-fno-strict-aliasing -fstack-protector-all -Wendif-labels
-Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security
-Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration
-Wold-style-definition -Wtype-limits -I/usr/include/libpng12
LDFLAGS -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -pie -m64 -g
make make
install install
pythonpython
smbd /usr/sbin/smbd
host CPU x86_64
host big endian no
target list i386-softmmu x86_64-softmmu alpha-softmmu arm-softmmu
cris-softmmu lm32-softmmu m68k-softmmu microblaze-softmmu microblazeel-softmmu
mips-softmmu mipsel-softmmu mips64-softmmu mips64el-softmmu ppc-softmmu
ppcemb-softmmu ppc64-softmmu sh4-softmmu sh4eb-softmmu sparc-softmmu
sparc64-softmmu s390x-softmmu xtensa-softmmu xtensaeb-softmmu i386-linux-user
x86_64-linux-user alpha-linux-user arm-linux-user armeb-linux-user
cris-linux-user m68k-linux-user microblaze-linux-user microblazeel-linux-user
mips-linux-user mipsel-linux-user ppc-linux-user ppc64-linux-user
ppc64abi32-linux-user sh4-linux-user sh4eb-linux-user sparc-linux-user
sparc64-linux-user sparc32plus-linux-user unicore32-linux-user s390x-linux-user
tcg debug enabled yes
Mon debug enabled yes
gprof enabled no
sparse enabledno
strip binariesno
profiler no
static build no
-Werror enabled no
SDL support no
curses supportyes
curl support no
check support no
mingw32 support no
Audio drivers oss
Extra audio cards ac97 es1370 sb16 hda
Block whitelist
Mixer emulation no
VNC support yes
VNC TLS support yes
VNC SASL support no
VNC JPEG support yes
VNC PNG support yes
VNC threadno
xen support no
brlapi supportno
bluez supportno
Documentation yes
NPTL support yes
GUEST_BASEyes
PIE yes
vde support no
Linux AIO support no
ATTR/XATTR support yes
Install blobs yes
KVM support yes
TCG interpreter no
fdt support no
preadv supportyes
fdatasync yes
madvise yes
posix_madvise yes
uuid support no
vhost-net support yes
Trace backend nop
Trace output file trace-
spice support no
rbd support no
xfsctl supportno
nss used no
usb net redir no
OpenGL supportyes
libiscsi support no
build guest agent yes
The result of the debug session of GDB (note the parameters to Qemu on the
command line):
testbox@debian-6-testbox:/mnt/build_test1$ gdb -args
/home/testbox/Downloads/qemu-1.0/arm-softmmu/qemu-system-arm -cpu co
[Qemu-devel] [Bug 912216] [NEW] ARM: QEMU crashes with segmentation fault on supervisor call
Public bug reported:
I am working on some mixed C/ASM code for the ARM Cortex-M3 but when I try to
simulate it, QEMU crashes with a segmentation fault. The exact instruction it
crashes on is a supervisor call from the assembly file.
I am using the default Sourcery CodeBench Lite 2011.09-69 for ARM\EABI (Not
GNU\Linux). The build environment is mingw32 on a win7 x64 machine.
The following code is what I used to trigger the segmentation fault.
main.c:
extern void testFunc( void );
int main()
{
testFunc();
while(1);
}
test.s:
.syntax unified
.global testFunc
.global __cs3_isr_svcall
.text
.balign 4
__cs3_isr_svcall:
bx lr
.balign 4
testFunc:
svc #1
BX LR
.end
This is build in an MSYS shell with the command:
arm-none-eabi-gcc -o test1.elf main.c test.s -g -mcpu=cortex-m3 -march=armv7-m
-mthumb -lc -lgcc -T generic-m-hosted.ld
The output elf file is also attached to this bug report.
To get information on the segmentation fault I start Qemu from GDB in a
debian-6 Virtual Machine (VMWare Player). This Qemu is configured with
--enable-debug and the output of this configure is:
Install prefix/usr/local
BIOS directory/usr/local/share/qemu
binary directory /usr/local/bin
library directory /usr/local/lib
include directory /usr/local/include
config directory /usr/local/etc
Manual directory /usr/local/share/man
ELF interp prefix /usr/gnemul/qemu-%M
Source path /home/testbox/Downloads/qemu-1.0
C compilergcc
Host C compiler gcc
CFLAGS-g
QEMU_CFLAGS -fPIE -DPIE -m64 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes
-Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes
-fno-strict-aliasing -fstack-protector-all -Wendif-labels
-Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security
-Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration
-Wold-style-definition -Wtype-limits -I/usr/include/libpng12
LDFLAGS -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -pie -m64 -g
make make
install install
pythonpython
smbd /usr/sbin/smbd
host CPU x86_64
host big endian no
target list i386-softmmu x86_64-softmmu alpha-softmmu arm-softmmu
cris-softmmu lm32-softmmu m68k-softmmu microblaze-softmmu microblazeel-softmmu
mips-softmmu mipsel-softmmu mips64-softmmu mips64el-softmmu ppc-softmmu
ppcemb-softmmu ppc64-softmmu sh4-softmmu sh4eb-softmmu sparc-softmmu
sparc64-softmmu s390x-softmmu xtensa-softmmu xtensaeb-softmmu i386-linux-user
x86_64-linux-user alpha-linux-user arm-linux-user armeb-linux-user
cris-linux-user m68k-linux-user microblaze-linux-user microblazeel-linux-user
mips-linux-user mipsel-linux-user ppc-linux-user ppc64-linux-user
ppc64abi32-linux-user sh4-linux-user sh4eb-linux-user sparc-linux-user
sparc64-linux-user sparc32plus-linux-user unicore32-linux-user s390x-linux-user
tcg debug enabled yes
Mon debug enabled yes
gprof enabled no
sparse enabledno
strip binariesno
profiler no
static build no
-Werror enabled no
SDL support no
curses supportyes
curl support no
check support no
mingw32 support no
Audio drivers oss
Extra audio cards ac97 es1370 sb16 hda
Block whitelist
Mixer emulation no
VNC support yes
VNC TLS support yes
VNC SASL support no
VNC JPEG support yes
VNC PNG support yes
VNC threadno
xen support no
brlapi supportno
bluez supportno
Documentation yes
NPTL support yes
GUEST_BASEyes
PIE yes
vde support no
Linux AIO support no
ATTR/XATTR support yes
Install blobs yes
KVM support yes
TCG interpreter no
fdt support no
preadv supportyes
fdatasync yes
madvise yes
posix_madvise yes
uuid support no
vhost-net support yes
Trace backend nop
Trace output file trace-
spice support no
rbd support no
xfsctl supportno
nss used no
usb net redir no
OpenGL supportyes
libiscsi support no
build guest agent yes
The result of the debug session of GDB (note the parameters to Qemu on the
command line):
testbox@debian-6-testbox:/mnt/build_test1$ gdb -args
/home/testbox/Downloads/qemu-1.0/arm-softmmu/qemu-system-arm -cpu cortex-m3
-nographic -monitor null -serial null -semihosting -kernel test1.elf -gdb
tcp::2200
GNU gdb (GDB) 7.3.1
Copyright (C) 2011 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-unknown-linux-gnu".
For bug reporting instructions, please see:
[Qemu-devel] [Bug 912216] Re: ARM: QEMU crashes with segmentation fault on supervisor call
This is user error (although we don't handle it very cleanly):
Starting program: /home/testbox/Downloads/qemu-1.0/arm-softmmu/qemu-
system-arm -cpu cortex-m3 -nographic -monitor null -serial null
-semihosting -kernel test1.elf -gdb tcp::2200
You're starting a model of the (default) "integratorcp" board. This
board doesn't support M profile cores, so trying to use -cpu cortex-m3
with it is doomed to failure.
You need to use one of the M3 based boards (ie pass "-M lm3s811evb" or
"-M lm3s6965evb" to QEMU).
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/912216
Title:
ARM: QEMU crashes with segmentation fault on supervisor call
Status in QEMU:
New
Bug description:
I am working on some mixed C/ASM code for the ARM Cortex-M3 but when I try to
simulate it, QEMU crashes with a segmentation fault. The exact instruction it
crashes on is a supervisor call from the assembly file.
I am using the default Sourcery CodeBench Lite 2011.09-69 for ARM\EABI (Not
GNU\Linux). The build environment is mingw32 on a win7 x64 machine.
The following code is what I used to trigger the segmentation fault.
main.c:
extern void testFunc( void );
int main()
{
testFunc();
while(1);
}
test.s:
.syntax unified
.global testFunc
.global __cs3_isr_svcall
.text
.balign 4
__cs3_isr_svcall:
bx lr
.balign 4
testFunc:
svc #1
BX LR
.end
This is build in an MSYS shell with the command:
arm-none-eabi-gcc -o test1.elf main.c test.s -g -mcpu=cortex-m3
-march=armv7-m -mthumb -lc -lgcc -T generic-m-hosted.ld
The output elf file is also attached to this bug report.
To get information on the segmentation fault I start Qemu from GDB in a
debian-6 Virtual Machine (VMWare Player). This Qemu is configured with
--enable-debug and the output of this configure is:
Install prefix/usr/local
BIOS directory/usr/local/share/qemu
binary directory /usr/local/bin
library directory /usr/local/lib
include directory /usr/local/include
config directory /usr/local/etc
Manual directory /usr/local/share/man
ELF interp prefix /usr/gnemul/qemu-%M
Source path /home/testbox/Downloads/qemu-1.0
C compilergcc
Host C compiler gcc
CFLAGS-g
QEMU_CFLAGS -fPIE -DPIE -m64 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes
-Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes
-fno-strict-aliasing -fstack-protector-all -Wendif-labels
-Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security
-Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration
-Wold-style-definition -Wtype-limits -I/usr/include/libpng12
LDFLAGS -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -pie -m64 -g
make make
install install
pythonpython
smbd /usr/sbin/smbd
host CPU x86_64
host big endian no
target list i386-softmmu x86_64-softmmu alpha-softmmu arm-softmmu
cris-softmmu lm32-softmmu m68k-softmmu microblaze-softmmu microblazeel-softmmu
mips-softmmu mipsel-softmmu mips64-softmmu mips64el-softmmu ppc-softmmu
ppcemb-softmmu ppc64-softmmu sh4-softmmu sh4eb-softmmu sparc-softmmu
sparc64-softmmu s390x-softmmu xtensa-softmmu xtensaeb-softmmu i386-linux-user
x86_64-linux-user alpha-linux-user arm-linux-user armeb-linux-user
cris-linux-user m68k-linux-user microblaze-linux-user microblazeel-linux-user
mips-linux-user mipsel-linux-user ppc-linux-user ppc64-linux-user
ppc64abi32-linux-user sh4-linux-user sh4eb-linux-user sparc-linux-user
sparc64-linux-user sparc32plus-linux-user unicore32-linux-user s390x-linux-user
tcg debug enabled yes
Mon debug enabled yes
gprof enabled no
sparse enabledno
strip binariesno
profiler no
static build no
-Werror enabled no
SDL support no
curses supportyes
curl support no
check support no
mingw32 support no
Audio drivers oss
Extra audio cards ac97 es1370 sb16 hda
Block whitelist
Mixer emulation no
VNC support yes
VNC TLS support yes
VNC SASL support no
VNC JPEG support yes
VNC PNG support yes
VNC threadno
xen support no
brlapi supportno
bluez supportno
Documentation yes
NPTL support yes
GUEST_BASEyes
PIE yes
vde support no
Linux AIO support no
ATTR/XATTR support yes
Install blobs yes
KVM support yes
TCG interpreter no
fdt support no
preadv supportyes
fdatasync yes
madvise yes
posix_madvise yes
uuid support no
vhost-net support yes
Trace backend nop
Trace output file trace-
spice support no
rbd
Re: [Qemu-devel] 回??: [PATCH 2/2] umem: chardevice for kvm postcopy
Hmm, this sounds like you haven't specified -postcopy option at the
incoming qemu.
How did you start incoming qemu?
On Thu, Jan 05, 2012 at 07:10:42PM +0800, Tommy wrote:
> After I use this series of patches, but the migration failed.
> 2, I start migrate -d -p -n tcp:xxx: on the outgoing node
> 2, on the incoming part, the qemu get stuck and migration failed
> the destnation can not typing any more
>
> today I found it's just at qemu_loadvm_state, just after the while loop ,maybe
> in cpu_synchronize_all_post_init
> I think there is some problems with qemu side for it doesn't get to the umem
> part
> I'm not sure about the problem
> do you have some suggestion?
> ━━━
> Tommy
>
> From: Isaku Yamahata
> Date: 2012-01-05 18:48
> To: thfbjyddx
> CC: t.hirofuchi; qemu-devel; kvm; satoshi.itoh
> Subject: Re: [Qemu-devel] ??: [PATCH 2/2] umem: chardevice for kvm postcopy
> On Thu, Jan 05, 2012 at 12:08:50PM +0800, thfbjyddx wrote:
> > hi,
> > I've tried to use this patch,
>
> Oh great! Can we share your results?
>
>
> > but it doesn't work for compiling error on
> >
> > page = alloc_page_vma(GFP_HIGHUSER_MOVABLE, vma, vmf->address);//vmf->
> > virtual_address?
> >
> > I guess it's for the wrong kernel version?
> > can you give me some detail about this or any clue?
> > 3x
>
> Thank you for report. The following should fix.
> It depends on kernel configuration. My config didn't catch it.
>
> diff --git a/drivers/char/umem.c b/drivers/char/umem.c
> index 4d031b5..853f1ce 100644
> --- a/drivers/char/umem.c
> +++ b/drivers/char/umem.c
> @@ -129,7 +129,7 @@ static int umem_minor_fault(struct umem *umem,
>* vmf->page = fake_vmf->page;
>*/
>
> - page = alloc_page_vma(GFP_HIGHUSER_MOVABLE, vma, vmf->address);
> + page = alloc_page_vma(GFP_HIGHUSER_MOVABLE, vma, vmf->virtual_address);
> if (!page)
> return VM_FAULT_OOM;
> if (mem_cgroup_cache_charge(page, vma->vm_mm, GFP_KERNEL)) {
>
>
>
> --
> yamahata
>
>
--
yamahata
Re: [Qemu-devel] [PATCH V2 3/5] Introduce premigrate RunState.
On Tue, Jan 3, 2012 at 19:05, Luiz Capitulino wrote: > On Mon, 19 Dec 2011 17:27:55 + > Anthony PERARD wrote: > >> On Thu, 15 Dec 2011, Luiz Capitulino wrote: >> >> > On Thu, 15 Dec 2011 09:14:00 -0600 >> > Anthony Liguori wrote: >> > >> > > On 12/09/2011 03:54 PM, Anthony PERARD wrote: >> > > > This new state will be used by Xen functions to know QEMU will wait >> > > > for a >> > > > migration. This is important to know for memory related function >> > > > because the >> > > > memory is already allocated and reallocated them will not works. >> > >> > How is premigrate different from inmigrate? It looks like the same thing >> > to me. >> >> The inmigrate state is used during machine initilisation. So this state >> replace the prelauch state (during machine.init) when a migration will be >> done. >> >> inmigrate is set only when the initilisation of the machine is over. > > Do you need both? What about setting inmigrate when initializing the > machine and using it instead? I suppose I can use it, by setting INMIGRATE earlier. I was afraid to change the meaning of inmigrate, but this seems fine in the QEMU point of view. > PS: sorry for the delay, I was on vacation. This is fine, me too :). -- Anthony PERARD
Re: [Qemu-devel] [PATCH 2/2] qemu-ga: Add the guest-suspend command
On Wed, 04 Jan 2012 13:03:26 -0700
Eric Blake wrote:
> On 01/04/2012 12:45 PM, Luiz Capitulino wrote:
> > +if (pid == 0) {
> > +/* child */
> > +int fd;
> > +
> > +setsid();
> > +fclose(stdin);
> > +fclose(stdout);
> > +fclose(stderr);
> > +
> > +execlp(pmutils_bin, pmutils_bin, NULL);
>
> It's generally a bad idea to exec a child process without fd 0, 1, and 2
> open on something, even if that something is /dev/null. POSIX says that
> the system may, but not must, reopen fds on your behalf, and that the
> child without open std descriptors is then executing in a non-conforming
> environment and may misbehave in unexpected manners.
You're right. I just copied what we do in qmp_guest_shutdown()... I think we
have to open /dev/null then, do you agree Michael?
I think I'm doing to use dup2(), like dup2(dev_null_fd, 0). Any better
recommendation?
>
> > +
> > +/*
> > + * The exec call should not return, if it does something went
> > wrong.
> > + * In this case we try to suspend manually if 'mode' is 'hibernate'
> > + */
> > +slog("could not execute %s: %s\n", pmutils_bin, strerror(errno));
> > +slog("trying to suspend using the manual method...\n");
> > +
> > +fd = open(LINUX_SYS_STATE_FILE, O_WRONLY);
>
> Worse, since you _just_ closed stdin above, fd here will most likely be
> 0, but a O_WRONLY stdin is asking for problems.
>
> > +if (fd < 0) {
> > +slog("can't open file %s: %s\n", LINUX_SYS_STATE_FILE,
> > +strerror(errno));
>
> Also, I have no idea where slog() writes to, but since you closed
> stderr, if slog() is trying to use stderr, your error messages would be
> invisible.
>
Re: [Qemu-devel] [PATCH V2 5/5] vga-cirrus: Workaround during restore when using Xen.
On Wed, 4 Jan 2012, Avi Kivity wrote: > On 01/04/2012 06:38 PM, Stefano Stabellini wrote: > > > > > I suggest doing the following: > > > > > > 1. keep cirrus code unchanged > > > 2. when the framebuffer is first mapped into physical memory (as known > > > by your CPUPhysMemoryClient), copy it into a temporary buffer, map the > > > guest memory into memory_region_get_ram_ptr(), and copy the temporary > > > buffer into memory_region_get_ram_ptr() > > > 3. when the framebuffer is unmapped, do the reverse: copy the > > > framebuffer out, mmap() some anonymous memory into > > > memory_region_get_ram_ptr(), and copy the temporary buffer into > > > memory_region_get_ram_ptr() > > > > I cannot see how this is going to fix the save/restore issue we are > > trying to solve. > > The problem, unfortunately very complex, is that at restore time the > > videoram is already allocated at the physical address it was mapped > > before the save operation. If it was not mapped, it is at the end of the > > physical memory of the guest (where qemu_ram_alloc_from_ptr decides to > > allocate it). > > Sorry, I don't follow, please be specific as to which type of address > you're referring to: > > ram_addr? > physical address (as seen by guest - but if it is not mapped, what does > your last sentence mean?) > something else? ram_addr_t as returned by qemu_ram_alloc_from_ptr. In fact on xen qemu_ram_alloc_from_ptr asks the hypervisor to add the specified amount of memory to the guest physmap at new_block->offset. So in a way the videoram is always visible by the guest, initially at new_block->offset, chosen by find_ram_offset, then at cirrus_bank_base, when map_linear_vram_bank is called. > > So the issue is that the videoram appears to qemu as part of the > > physical memory of the guest at an unknown address. > > > > The proposal of introducing early_savevm would easily solve this last > > problem: letting us know where the videoram is. The other problem, the > > fact that under Xen the videoram would be already allocated while under > > native it would not, remains unsolved. > > We cannot simply allocate the videoram twice because the operation > > would fail (Xen would realize that we are trying to allocate more memory > > than it we are supposed to, returning an error). > > However, once we know where the videoram is, we could probably figure out > > a smart (see hacky) way to avoid allocating it twice without changes to > > the cirrus code. > > I'm missing some context. Can you please explain in more detail? > Note that with the memory API changes, ram addresses are going away. > There will not be a linear space for guest RAM. We'll have > (MemoryRegion *, offset) pairs that will be mapped into discontiguous > guest physical address ranges (perhaps with overlaps). This is how memory is currently allocated and mapped in qemu on xen: - qemu_ram_alloc_from_ptr asks the hypervisor to allocate memory for the guest, the memory is added to the guest p2m (physical to machine translation table) at the given guest physical address (new_block->offset, as chosen by find_ram_offset); - qemu_get_ram_ptr uses the xen mapcache to map guest physical address ranges into qemu's address space, so that qemu can read/write guest memory; - xen_set_memory, called by the memory_listener interface, effectively moves a guest physical memory address range from one address to another. So the memory that was initially allocated at new_block->offset, as chosen by find_ram_offset, is going to be moved to a new destination, section->offset_within_address_space. So the videoram lifecycle is the following: - qemu_ram_alloc_from_ptr allocates the videoram and adds it to the end of the physmap; - qemu_get_ram_ptr maps the videoram into qemu's address space; - xen_set_memory moves the videoram to cirrus_bank_base; Now let's introduce save/restore into the picture: the videoram is part of the guest's memory from the hypervisor POV, so xen will take care of saving and restoring it as part of the normal guest memory, out of qemu's control. At restore time, we know that the videoram is already allocated and mapped somewhere in the guest physical address space: it could be cirrus_bank_base, which we don't know yet, or the initial new_block->offset. A second videoram allocation by qemu_ram_alloc_from_ptr will fail because of memory constraints enforced by the hypervisor. Trying to map the already allocated videoram into qemu's address space is not easy because we don't know where it is yet (keep in mind that machine->init is called before the machine restore functions). The "solution" I am proposing is introducing an early_savevm set of save/restore functions so that at restore time we can get to know at what address the videoram is mapped into the guest address space. Once we know the address we can remap it into qemu's address space and/or move it to another guest physical address. The problem of avoiding a second allocation remains, but c
[Qemu-devel] [Bug 912216] Re: ARM: QEMU crashes with segmentation fault on supervisor call
Thanks for pointing this out. This indeed solves my issue.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/912216
Title:
ARM: QEMU crashes with segmentation fault on supervisor call
Status in QEMU:
New
Bug description:
I am working on some mixed C/ASM code for the ARM Cortex-M3 but when I try to
simulate it, QEMU crashes with a segmentation fault. The exact instruction it
crashes on is a supervisor call from the assembly file.
I am using the default Sourcery CodeBench Lite 2011.09-69 for ARM\EABI (Not
GNU\Linux). The build environment is mingw32 on a win7 x64 machine.
The following code is what I used to trigger the segmentation fault.
main.c:
extern void testFunc( void );
int main()
{
testFunc();
while(1);
}
test.s:
.syntax unified
.global testFunc
.global __cs3_isr_svcall
.text
.balign 4
__cs3_isr_svcall:
bx lr
.balign 4
testFunc:
svc #1
BX LR
.end
This is build in an MSYS shell with the command:
arm-none-eabi-gcc -o test1.elf main.c test.s -g -mcpu=cortex-m3
-march=armv7-m -mthumb -lc -lgcc -T generic-m-hosted.ld
The output elf file is also attached to this bug report.
To get information on the segmentation fault I start Qemu from GDB in a
debian-6 Virtual Machine (VMWare Player). This Qemu is configured with
--enable-debug and the output of this configure is:
Install prefix/usr/local
BIOS directory/usr/local/share/qemu
binary directory /usr/local/bin
library directory /usr/local/lib
include directory /usr/local/include
config directory /usr/local/etc
Manual directory /usr/local/share/man
ELF interp prefix /usr/gnemul/qemu-%M
Source path /home/testbox/Downloads/qemu-1.0
C compilergcc
Host C compiler gcc
CFLAGS-g
QEMU_CFLAGS -fPIE -DPIE -m64 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes
-Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes
-fno-strict-aliasing -fstack-protector-all -Wendif-labels
-Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security
-Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration
-Wold-style-definition -Wtype-limits -I/usr/include/libpng12
LDFLAGS -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -pie -m64 -g
make make
install install
pythonpython
smbd /usr/sbin/smbd
host CPU x86_64
host big endian no
target list i386-softmmu x86_64-softmmu alpha-softmmu arm-softmmu
cris-softmmu lm32-softmmu m68k-softmmu microblaze-softmmu microblazeel-softmmu
mips-softmmu mipsel-softmmu mips64-softmmu mips64el-softmmu ppc-softmmu
ppcemb-softmmu ppc64-softmmu sh4-softmmu sh4eb-softmmu sparc-softmmu
sparc64-softmmu s390x-softmmu xtensa-softmmu xtensaeb-softmmu i386-linux-user
x86_64-linux-user alpha-linux-user arm-linux-user armeb-linux-user
cris-linux-user m68k-linux-user microblaze-linux-user microblazeel-linux-user
mips-linux-user mipsel-linux-user ppc-linux-user ppc64-linux-user
ppc64abi32-linux-user sh4-linux-user sh4eb-linux-user sparc-linux-user
sparc64-linux-user sparc32plus-linux-user unicore32-linux-user s390x-linux-user
tcg debug enabled yes
Mon debug enabled yes
gprof enabled no
sparse enabledno
strip binariesno
profiler no
static build no
-Werror enabled no
SDL support no
curses supportyes
curl support no
check support no
mingw32 support no
Audio drivers oss
Extra audio cards ac97 es1370 sb16 hda
Block whitelist
Mixer emulation no
VNC support yes
VNC TLS support yes
VNC SASL support no
VNC JPEG support yes
VNC PNG support yes
VNC threadno
xen support no
brlapi supportno
bluez supportno
Documentation yes
NPTL support yes
GUEST_BASEyes
PIE yes
vde support no
Linux AIO support no
ATTR/XATTR support yes
Install blobs yes
KVM support yes
TCG interpreter no
fdt support no
preadv supportyes
fdatasync yes
madvise yes
posix_madvise yes
uuid support no
vhost-net support yes
Trace backend nop
Trace output file trace-
spice support no
rbd support no
xfsctl supportno
nss used no
usb net redir no
OpenGL supportyes
libiscsi support no
build guest agent yes
The result of the debug session of GDB (note the parameters to Qemu on the
command line):
testbox@debian-6-testbox:/mnt/build_test1$ gdb -args
/home/testbox/Downloads/qemu-1.0/arm-softmmu/qemu-system-arm -cpu cortex-m3
-nographic -monitor null -serial null -semihosting -kernel test1
Re: [Qemu-devel] [PATCH v4 0/2]: qemu-ga: Add the guest-suspend command
On Thu, 5 Jan 2012 10:16:30 + "Daniel P. Berrange" wrote: > On Wed, Jan 04, 2012 at 05:45:11PM -0200, Luiz Capitulino wrote: > > This version drops modes 'sleep' and 'hybrid' because they don't work > > properly due to issues in qemu. Only the 'hibernate' mode is supported > > for now. > > IMHO this is short-sighted. When the bugs QEMU in are fixed so that > these modes work, you have needlessly put users in the situation where > they have to now upgrade the guest agent everywhere to take advantage > of the bugfix. That was my thinking until v4. But after discussing with Michael the issues we have with S3 I concluded that it doesn't make sense to offer an API to something that doesn't work, this will just generate bug reports. Also, updating to get new features is normal and expected. I'm willing to change my mind if I'm the only one thinking like this though.
[Qemu-devel] [Bug 912216] Re: ARM: QEMU crashes with segmentation fault on supervisor call
Cool. (There is some internal restructuring of QEMU's device/object
model in progress which may let us diagnose this error better by
effectively making it impossible to instantiate a "bare" M3 CPU without
its obligatory internal peripherals. But for now I'm going to close this
bug report.)
** Changed in: qemu
Status: New => Invalid
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/912216
Title:
ARM: QEMU crashes with segmentation fault on supervisor call
Status in QEMU:
Invalid
Bug description:
I am working on some mixed C/ASM code for the ARM Cortex-M3 but when I try to
simulate it, QEMU crashes with a segmentation fault. The exact instruction it
crashes on is a supervisor call from the assembly file.
I am using the default Sourcery CodeBench Lite 2011.09-69 for ARM\EABI (Not
GNU\Linux). The build environment is mingw32 on a win7 x64 machine.
The following code is what I used to trigger the segmentation fault.
main.c:
extern void testFunc( void );
int main()
{
testFunc();
while(1);
}
test.s:
.syntax unified
.global testFunc
.global __cs3_isr_svcall
.text
.balign 4
__cs3_isr_svcall:
bx lr
.balign 4
testFunc:
svc #1
BX LR
.end
This is build in an MSYS shell with the command:
arm-none-eabi-gcc -o test1.elf main.c test.s -g -mcpu=cortex-m3
-march=armv7-m -mthumb -lc -lgcc -T generic-m-hosted.ld
The output elf file is also attached to this bug report.
To get information on the segmentation fault I start Qemu from GDB in a
debian-6 Virtual Machine (VMWare Player). This Qemu is configured with
--enable-debug and the output of this configure is:
Install prefix/usr/local
BIOS directory/usr/local/share/qemu
binary directory /usr/local/bin
library directory /usr/local/lib
include directory /usr/local/include
config directory /usr/local/etc
Manual directory /usr/local/share/man
ELF interp prefix /usr/gnemul/qemu-%M
Source path /home/testbox/Downloads/qemu-1.0
C compilergcc
Host C compiler gcc
CFLAGS-g
QEMU_CFLAGS -fPIE -DPIE -m64 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes
-Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes
-fno-strict-aliasing -fstack-protector-all -Wendif-labels
-Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security
-Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration
-Wold-style-definition -Wtype-limits -I/usr/include/libpng12
LDFLAGS -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -pie -m64 -g
make make
install install
pythonpython
smbd /usr/sbin/smbd
host CPU x86_64
host big endian no
target list i386-softmmu x86_64-softmmu alpha-softmmu arm-softmmu
cris-softmmu lm32-softmmu m68k-softmmu microblaze-softmmu microblazeel-softmmu
mips-softmmu mipsel-softmmu mips64-softmmu mips64el-softmmu ppc-softmmu
ppcemb-softmmu ppc64-softmmu sh4-softmmu sh4eb-softmmu sparc-softmmu
sparc64-softmmu s390x-softmmu xtensa-softmmu xtensaeb-softmmu i386-linux-user
x86_64-linux-user alpha-linux-user arm-linux-user armeb-linux-user
cris-linux-user m68k-linux-user microblaze-linux-user microblazeel-linux-user
mips-linux-user mipsel-linux-user ppc-linux-user ppc64-linux-user
ppc64abi32-linux-user sh4-linux-user sh4eb-linux-user sparc-linux-user
sparc64-linux-user sparc32plus-linux-user unicore32-linux-user s390x-linux-user
tcg debug enabled yes
Mon debug enabled yes
gprof enabled no
sparse enabledno
strip binariesno
profiler no
static build no
-Werror enabled no
SDL support no
curses supportyes
curl support no
check support no
mingw32 support no
Audio drivers oss
Extra audio cards ac97 es1370 sb16 hda
Block whitelist
Mixer emulation no
VNC support yes
VNC TLS support yes
VNC SASL support no
VNC JPEG support yes
VNC PNG support yes
VNC threadno
xen support no
brlapi supportno
bluez supportno
Documentation yes
NPTL support yes
GUEST_BASEyes
PIE yes
vde support no
Linux AIO support no
ATTR/XATTR support yes
Install blobs yes
KVM support yes
TCG interpreter no
fdt support no
preadv supportyes
fdatasync yes
madvise yes
posix_madvise yes
uuid support no
vhost-net support yes
Trace backend nop
Trace output file trace-
spice support no
rbd support no
xfsctl supportno
nss used no
usb net redir no
OpenGL supportyes
libiscsi support no
build guest agent yes
T
Re: [Qemu-devel] [PATCH 2/2] qemu-ga: Add the guest-suspend command
On Wed, Jan 04, 2012 at 05:45:13PM -0200, Luiz Capitulino wrote:
> diff --git a/qga/guest-agent-commands.c b/qga/guest-agent-commands.c
> index a09c8ca..19f29c6 100644
> --- a/qga/guest-agent-commands.c
> +++ b/qga/guest-agent-commands.c
> @@ -574,6 +574,61 @@ int64_t qmp_guest_fsfreeze_thaw(Error **err)
> }
> #endif
>
> +#define LINUX_SYS_STATE_FILE "/sys/power/state"
> +
> +void qmp_guest_suspend(const char *mode, Error **err)
> +{
> +pid_t pid;
> +const char *pmutils_bin;
> +
> +/* TODO implement 'sleep' and 'hybrid' modes once qemu is fixed to
> + support them */
> +if (strcmp(mode, "hibernate") == 0) {
> +pmutils_bin = "pm-hibernate";
> +} else {
> +error_set(err, QERR_INVALID_PARAMETER, "mode");
> +return;
> +}
> +
> +pid = fork();
> +if (pid == 0) {
> +/* child */
> +int fd;
> +
> +setsid();
> +fclose(stdin);
> +fclose(stdout);
> +fclose(stderr);
> +
> +execlp(pmutils_bin, pmutils_bin, NULL);
Strictly speaking, in multi-threaded programs, between fork() and
exec() you are restricted to calling functions which are marked as
async-signal safe in POSIX spec - fclose() is not.
Also, if there was unflushed buffered output on stdout, calling
fclose() in the child will flush that output, but then the parent
process will also flush it some time later, causing duplicated
stdout data.
NB, you might not think qemu-ga is multi-threaded, but depending on
which GLib APIs you're calling, you might find you are in fact using
threads behind the scenes without realizing, so I think it is wise
to be conservative here & assume threads are possible.
Thus you really want to use a plain old 'close()' call, and then
re-open to /dev/null as Eric suggests, leaving stdin/out/err FILE*
alone.
> +
> +/*
> + * The exec call should not return, if it does something went wrong.
> + * In this case we try to suspend manually if 'mode' is 'hibernate'
> + */
> +slog("could not execute %s: %s\n", pmutils_bin, strerror(errno));
> +slog("trying to suspend using the manual method...\n");
> +
> +fd = open(LINUX_SYS_STATE_FILE, O_WRONLY);
> +if (fd < 0) {
> +slog("can't open file %s: %s\n", LINUX_SYS_STATE_FILE,
> +strerror(errno));
> +exit(1);
> +}
> +
> +if (write(fd, "disk", 4) < 0) {
> +slog("can't write to %s: %s\n", LINUX_SYS_STATE_FILE,
> +strerror(errno));
> +exit(1);
> +}
> +
> +exit(0);
exit() is also not async-signal safe, because it calls into stdio
to flush buffers. So you want to use _exit() instead for these.
The impl of slog() doesn't look too safe to me either.
Regards,
Daniel
--
|: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Re: [Qemu-devel] [PATCH V2] xen: Fix after recent change in dirty bitmap tracking.
On Thu, 5 Jan 2012, Anthony PERARD wrote: > A recent patch set from Avi break the dirty bitmap support of Xen. But this is > because xen_sync_dirty_bitmap will return an error for an unhandled memory > range (a - b). However this is not a fatal error, so we should just > continue instead of aborting. > > There is now an error printed when the Xen call failed. > > Signed-off-by: Anthony PERARD acked, however it needs rebasing. I'll send a pull request with the rebased version to AnthonyL
Re: [Qemu-devel] [PATCH V2 5/5] vga-cirrus: Workaround during restore when using Xen.
On 01/05/2012 02:30 PM, Stefano Stabellini wrote: > > > > > > I cannot see how this is going to fix the save/restore issue we are > > > trying to solve. > > > The problem, unfortunately very complex, is that at restore time the > > > videoram is already allocated at the physical address it was mapped > > > before the save operation. If it was not mapped, it is at the end of the > > > physical memory of the guest (where qemu_ram_alloc_from_ptr decides to > > > allocate it). > > > > Sorry, I don't follow, please be specific as to which type of address > > you're referring to: > > > > ram_addr? > > physical address (as seen by guest - but if it is not mapped, what does > > your last sentence mean?) > > something else? > > ram_addr_t as returned by qemu_ram_alloc_from_ptr. > > In fact on xen qemu_ram_alloc_from_ptr asks the hypervisor to add > the specified amount of memory to the guest physmap at > new_block->offset. So in a way the videoram is always visible by the > guest, initially at new_block->offset, chosen by find_ram_offset, then > at cirrus_bank_base, when map_linear_vram_bank is called. Okay. So we will need to hook this differently from the memory API. There are two places we can hook: - memory_region_init_ram() - similar to qemu_ram_alloc() - at region construction time - MemoryListener::region_add() - called the first time the region is made visible, probably not what we want > > > So the issue is that the videoram appears to qemu as part of the > > > physical memory of the guest at an unknown address. > > > > > > The proposal of introducing early_savevm would easily solve this last > > > problem: letting us know where the videoram is. The other problem, the > > > fact that under Xen the videoram would be already allocated while under > > > native it would not, remains unsolved. > > > We cannot simply allocate the videoram twice because the operation > > > would fail (Xen would realize that we are trying to allocate more memory > > > than it we are supposed to, returning an error). > > > However, once we know where the videoram is, we could probably figure out > > > a smart (see hacky) way to avoid allocating it twice without changes to > > > the cirrus code. > > > > I'm missing some context. Can you please explain in more detail? > > Note that with the memory API changes, ram addresses are going away. > > There will not be a linear space for guest RAM. We'll have > > (MemoryRegion *, offset) pairs that will be mapped into discontiguous > > guest physical address ranges (perhaps with overlaps). > > > This is how memory is currently allocated and mapped in qemu on xen: > > - qemu_ram_alloc_from_ptr asks the hypervisor to allocate memory for > the guest, the memory is added to the guest p2m (physical to machine > translation table) at the given guest physical address > (new_block->offset, as chosen by find_ram_offset); > > - qemu_get_ram_ptr uses the xen mapcache to map guest physical address > ranges into qemu's address space, so that qemu can read/write guest > memory; > > - xen_set_memory, called by the memory_listener interface, effectively > moves a guest physical memory address range from one address to another. > So the memory that was initially allocated at new_block->offset, as > chosen by find_ram_offset, is going to be moved to a new destination, > section->offset_within_address_space. So, where qemu has two different address spaces (ram_addr_t and guest physical addresses), Xen has just one, and any time the translation between the two changes, you have to move memory around. > So the videoram lifecycle is the following: > > - qemu_ram_alloc_from_ptr allocates the videoram and adds it to the end > of the physmap; > > - qemu_get_ram_ptr maps the videoram into qemu's address space; > > - xen_set_memory moves the videoram to cirrus_bank_base; > > > > Now let's introduce save/restore into the picture: the videoram is part > of the guest's memory from the hypervisor POV, so xen will take care of > saving and restoring it as part of the normal guest memory, out of > qemu's control. > At restore time, we know that the videoram is already allocated and > mapped somewhere in the guest physical address space: it could be > cirrus_bank_base, which we don't know yet, or the initial > new_block->offset. > A second videoram allocation by qemu_ram_alloc_from_ptr will fail > because of memory constraints enforced by the hypervisor. Trying to map > the already allocated videoram into qemu's address space is not easy > because we don't know where it is yet (keep in mind that machine->init > is called before the machine restore functions). > > The "solution" I am proposing is introducing an early_savevm set of > save/restore functions so that at restore time we can get to know at > what address the videoram is mapped into the guest address space. Once we > know the address we can remap it into qemu's address space and/or move it > to another guest physical address. Why can we not simply t
Re: [Qemu-devel] [PATCH 2/2] qemu-ga: Add the guest-suspend command
On Thu, 5 Jan 2012 12:46:56 +
"Daniel P. Berrange" wrote:
> On Wed, Jan 04, 2012 at 05:45:13PM -0200, Luiz Capitulino wrote:
> > diff --git a/qga/guest-agent-commands.c b/qga/guest-agent-commands.c
> > index a09c8ca..19f29c6 100644
> > --- a/qga/guest-agent-commands.c
> > +++ b/qga/guest-agent-commands.c
> > @@ -574,6 +574,61 @@ int64_t qmp_guest_fsfreeze_thaw(Error **err)
> > }
> > #endif
> >
> > +#define LINUX_SYS_STATE_FILE "/sys/power/state"
> > +
> > +void qmp_guest_suspend(const char *mode, Error **err)
> > +{
> > +pid_t pid;
> > +const char *pmutils_bin;
> > +
> > +/* TODO implement 'sleep' and 'hybrid' modes once qemu is fixed to
> > + support them */
> > +if (strcmp(mode, "hibernate") == 0) {
> > +pmutils_bin = "pm-hibernate";
> > +} else {
> > +error_set(err, QERR_INVALID_PARAMETER, "mode");
> > +return;
> > +}
> > +
> > +pid = fork();
> > +if (pid == 0) {
> > +/* child */
> > +int fd;
> > +
> > +setsid();
> > +fclose(stdin);
> > +fclose(stdout);
> > +fclose(stderr);
> > +
> > +execlp(pmutils_bin, pmutils_bin, NULL);
>
> Strictly speaking, in multi-threaded programs, between fork() and
> exec() you are restricted to calling functions which are marked as
> async-signal safe in POSIX spec - fclose() is not.
>
> Also, if there was unflushed buffered output on stdout, calling
> fclose() in the child will flush that output, but then the parent
> process will also flush it some time later, causing duplicated
> stdout data.
>
> NB, you might not think qemu-ga is multi-threaded, but depending on
> which GLib APIs you're calling, you might find you are in fact using
> threads behind the scenes without realizing, so I think it is wise
> to be conservative here & assume threads are possible.
All good points.
> Thus you really want to use a plain old 'close()' call, and then
> re-open to /dev/null as Eric suggests, leaving stdin/out/err FILE*
> alone.
I'm going to use dup2(), which seems to be ok in that regard.
>
> > +
> > +/*
> > + * The exec call should not return, if it does something went
> > wrong.
> > + * In this case we try to suspend manually if 'mode' is 'hibernate'
> > + */
> > +slog("could not execute %s: %s\n", pmutils_bin, strerror(errno));
> > +slog("trying to suspend using the manual method...\n");
> > +
> > +fd = open(LINUX_SYS_STATE_FILE, O_WRONLY);
> > +if (fd < 0) {
> > +slog("can't open file %s: %s\n", LINUX_SYS_STATE_FILE,
> > +strerror(errno));
> > +exit(1);
> > +}
> > +
> > +if (write(fd, "disk", 4) < 0) {
> > +slog("can't write to %s: %s\n", LINUX_SYS_STATE_FILE,
> > +strerror(errno));
> > +exit(1);
> > +}
> > +
> > +exit(0);
>
> exit() is also not async-signal safe, because it calls into stdio
> to flush buffers. So you want to use _exit() instead for these.
Ok, I'll change and will fix qmp_guest_shutdown() in a different patch.
>
> The impl of slog() doesn't look too safe to me either.
>
> Regards,
> Daniel
Re: [Qemu-devel] [PATCH v4 0/2]: qemu-ga: Add the guest-suspend command
On Thu, Jan 05, 2012 at 10:37:14AM -0200, Luiz Capitulino wrote: > On Thu, 5 Jan 2012 10:16:30 + > "Daniel P. Berrange" wrote: > > > On Wed, Jan 04, 2012 at 05:45:11PM -0200, Luiz Capitulino wrote: > > > This version drops modes 'sleep' and 'hybrid' because they don't work > > > properly due to issues in qemu. Only the 'hibernate' mode is supported > > > for now. > > > > IMHO this is short-sighted. When the bugs QEMU in are fixed so that > > these modes work, you have needlessly put users in the situation where > > they have to now upgrade the guest agent everywhere to take advantage > > of the bugfix. > > That was my thinking until v4. But after discussing with Michael the issues > we have with S3 I concluded that it doesn't make sense to offer an API to > something that doesn't work, this will just generate bug reports. Also, > updating to get new features is normal and expected. This is assuming that users will always upgrade their VMs & hosts in lock step, which I rather doubt they will in practice. eg imagine a deployment might have a mixture of hosts, running QEMU 1.1 (broken S3) and QEMU 1.2 (working S3). If they build VM disk images they will likely use the QEMU GA from 1.2 for all their builds, even if many of them will only run on QEMU 1.1 hosts. So you'll end up having 'sleep' and 'hybrid' commands available in the guest agent, even though the host QEMU doesn't work properly. So you *will* ultimately need to make sure that QEMU GA from 1.2, has sensible behaviour when run on a QEMU 1.1 host. If you don't address this during 1.1, you may well find yourself in an un-winnable situation for 1.2, where it is impossible to provide good behaviour on old hosts. So IMHO we are better off in the long run, if we include all commands right now, even though some don't work yet, and work to ensure we have good error reporting behaviour for those that don't work. As an example, if S3 is broken in current QEMU, then we should not be advertizing S3 to the guest OS. This would allow 'pm-is-supported --suspend' to return false, at which point the guest agent can send back a nice error message 'Suspend is not supported on this host', instead of just having the guest try to suspend & hang or worse. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
[Qemu-devel] [PULL] xen memory fix
Hi Anthony,
I have a single fix (also appended) for Xen by Anthony Perard, to remove
a bug recently introduced by the memory api changes:
Anthony PERARD (1):
xen: Fix after recent change in dirty bitmap tracking.
xen-all.c | 38 ++
1 files changed, 18 insertions(+), 20 deletions(-)
Could you please pull the following branch, based on
c47f3223658119219bbe0b8d09da733d1c06e76f:
git://xenbits.xen.org/people/sstabellini/qemu-dm.git xen_mem_fix
Cheers,
Stefano
---
>From b18620cf760d283b044543c831db5c88e2c66dcd Mon Sep 17 00:00:00 2001
From: Anthony PERARD
Date: Thu, 5 Jan 2012 12:47:08 +
Subject: [PATCH] xen: Fix after recent change in dirty bitmap tracking.
A recent patch set from Avi break the dirty bitmap support of Xen. But
this is because xen_sync_dirty_bitmap will return an error for an
unhandled memory range (a - b). However this is not a fatal
error, so we should just continue instead of aborting.
There is now an error printed when the Xen call failed.
Signed-off-by: Anthony PERARD
Acked-by: Stefano Stabellini
---
diff --git a/xen-all.c b/xen-all.c
index d58d461..c86ebf4 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -404,9 +404,9 @@ static void xen_region_del(MemoryListener *listener,
xen_set_memory(listener, section, false);
}
-static int xen_sync_dirty_bitmap(XenIOState *state,
- target_phys_addr_t start_addr,
- ram_addr_t size)
+static void xen_sync_dirty_bitmap(XenIOState *state,
+ target_phys_addr_t start_addr,
+ ram_addr_t size)
{
target_phys_addr_t npages = size >> TARGET_PAGE_BITS;
const int width = sizeof(unsigned long) * 8;
@@ -417,20 +417,26 @@ static int xen_sync_dirty_bitmap(XenIOState *state,
physmap = get_physmapping(state, start_addr, size);
if (physmap == NULL) {
/* not handled */
-return -1;
+return;
}
if (state->log_for_dirtybit == NULL) {
state->log_for_dirtybit = physmap;
} else if (state->log_for_dirtybit != physmap) {
-return -1;
+/* Only one range for dirty bitmap can be tracked. */
+return;
}
rc = xc_hvm_track_dirty_vram(xen_xc, xen_domid,
start_addr >> TARGET_PAGE_BITS, npages,
bitmap);
-if (rc) {
-return rc;
+if (rc < 0) {
+if (rc != -ENODATA) {
+fprintf(stderr, "xen: track_dirty_vram failed (0x" TARGET_FMT_plx
+", 0x" TARGET_FMT_plx "): %s\n",
+start_addr, start_addr + size, strerror(-rc));
+}
+return;
}
for (i = 0; i < ARRAY_SIZE(bitmap); i++) {
@@ -442,40 +448,32 @@ static int xen_sync_dirty_bitmap(XenIOState *state,
(i * width + j) * TARGET_PAGE_SIZE);
};
}
-
-return 0;
}
static void xen_log_start(MemoryListener *listener,
MemoryRegionSection *section)
{
XenIOState *state = container_of(listener, XenIOState, memory_listener);
-int r;
-r = xen_sync_dirty_bitmap(state, section->offset_within_address_space,
- section->size);
-assert(r >= 0);
+xen_sync_dirty_bitmap(state, section->offset_within_address_space,
+ section->size);
}
static void xen_log_stop(MemoryListener *listener, MemoryRegionSection
*section)
{
XenIOState *state = container_of(listener, XenIOState, memory_listener);
-int r;
state->log_for_dirtybit = NULL;
/* Disable dirty bit tracking */
-r = xc_hvm_track_dirty_vram(xen_xc, xen_domid, 0, 0, NULL);
-assert(r >= 0);
+xc_hvm_track_dirty_vram(xen_xc, xen_domid, 0, 0, NULL);
}
static void xen_log_sync(MemoryListener *listener, MemoryRegionSection
*section)
{
XenIOState *state = container_of(listener, XenIOState, memory_listener);
-int r;
-r = xen_sync_dirty_bitmap(state, section->offset_within_address_space,
- section->size);
-assert(r >= 0);
+xen_sync_dirty_bitmap(state, section->offset_within_address_space,
+ section->size);
}
static void xen_log_global_start(MemoryListener *listener)
--
1.7.2.5
[Qemu-devel] [PATCH v9] arm: add dummy v7 cp15 registers
Add dummy register support for the cp15, CRn=c15 registers.
config_base_register and power_control_register currently
default to 0, but may have improved support after the QOM
CPU patches are finished.
Signed-off-by: Mark Langsdorf
---
Changes from v8
Removed c1_scr
Changes from v7
Formatted improved
c1_scr added
CPU_SAVE_VERSION increased
Changes from v6
Added the diagnostic registers
Added save/load support
Changes from v5
Added handling for all c15 registers
Changes from v3, v4
None
Changes from v2
Added test against op2
Changes from v1
renamed the register
added comments about how it will change when QOM CPUs are added
target-arm/cpu.h |6 +-
target-arm/helper.c | 48
target-arm/machine.c |6 ++
3 files changed, 59 insertions(+), 1 deletions(-)
diff --git a/target-arm/cpu.h b/target-arm/cpu.h
index c4d742f..26b4981 100644
--- a/target-arm/cpu.h
+++ b/target-arm/cpu.h
@@ -149,6 +149,10 @@ typedef struct CPUARMState {
uint32_t c15_i_max; /* Maximum D-cache dirty line index. */
uint32_t c15_i_min; /* Minimum D-cache dirty line index. */
uint32_t c15_threadid; /* TI debugger thread-ID. */
+uint32_t c15_config_base_address; /* SCU base address. */
+uint32_t c15_diagnostic; /* diagnostic register */
+uint32_t c15_power_diagnostic;
+uint32_t c15_power_control; /* power control */
} cp15;
struct {
@@ -448,7 +452,7 @@ void cpu_arm_set_cp_io(CPUARMState *env, int cpnum,
#define cpu_signal_handler cpu_arm_signal_handler
#define cpu_list arm_cpu_list
-#define CPU_SAVE_VERSION 4
+#define CPU_SAVE_VERSION 5
/* MMU modes definitions */
#define MMU_MODE0_SUFFIX _kernel
diff --git a/target-arm/helper.c b/target-arm/helper.c
index 65f4fbf..4cfda17 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -1768,6 +1768,20 @@ void HELPER(set_cp15)(CPUState *env, uint32_t insn,
uint32_t val)
goto bad_reg;
}
}
+if (ARM_CPUID(env) == ARM_CPUID_CORTEXA9) {
+switch (crm) {
+case 0:
+if ((op1 == 0) && (op2 == 0)) {
+env->cp15.c15_power_control = val;
+} else if ((op1 == 0) && (op2 == 1)) {
+env->cp15.c15_diagnostic = val;
+} else if ((op1 == 0) && (op2 == 2)) {
+env->cp15.c15_power_diagnostic = val;
+}
+default:
+break;
+}
+}
break;
}
return;
@@ -2111,6 +2125,40 @@ uint32_t HELPER(get_cp15)(CPUState *env, uint32_t insn)
* 0x200 << ($rn & 0xfff), when MMU is off. */
goto bad_reg;
}
+if (ARM_CPUID(env) == ARM_CPUID_CORTEXA9) {
+switch (crm) {
+case 0:
+if ((op1 == 4) && (op2 == 0)) {
+/* The config_base_address should hold the value of
+ * the peripheral base. ARM should get this from a CPU
+ * object property, but that support isn't available in
+ * December 2011. Default to 0 for now and board models
+ * that care can set it by a private hook */
+return env->cp15.c15_config_base_address;
+} else if ((op1 == 0) && (op2 == 0)) {
+/* power_control should be set to maximum latency. Again,
+ default to 0 and set by private hook */
+return env->cp15.c15_power_control;
+} else if ((op1 == 0) && (op2 == 1)) {
+return env->cp15.c15_diagnostic;
+} else if ((op1 == 0) && (op2 == 2)) {
+return env->cp15.c15_power_diagnostic;
+}
+break;
+case 1: /* NEON Busy */
+return 0;
+case 5: /* tlb lockdown */
+case 6:
+case 7:
+if ((op1 == 5) && (op2 == 2)) {
+return 0;
+}
+break;
+default:
+break;
+}
+goto bad_reg;
+}
return 0;
}
bad_reg:
diff --git a/target-arm/machine.c b/target-arm/machine.c
index aaee9b9..8984775 100644
--- a/target-arm/machine.c
+++ b/target-arm/machine.c
@@ -56,6 +56,9 @@ void cpu_save(QEMUFile *f, void *opaque)
qemu_put_be32(f, env->cp15.c13_tls2);
qemu_put_be32(f, env->cp15.c13_tls3);
qemu_put_be32(f, env->cp15.c15_cpar);
+qemu_put_be32(f, env->cp15.c15_power_control);
+qemu_put_be32(f, env->cp15.c15_diagnostic);
+qemu_put_be32(f, env->cp15.c15_power_diagnostic);
qemu_put_be32(f, env->features);
@@ -170,6 +173,9 @@ int cpu_load(QEMUFile *f, void *opaque, int version_id)
env->cp15.c13_tls2 = qemu
[Qemu-devel] [PATCH] qemu-nbd: drop loop which can never loop
For some reason nbd_client_thread() has a do..while loop which can never
loop, the condition is bogus because we would take a goto instead. Drop
the loop.
Reported-by: Dr David Alan Gilbert
Signed-off-by: Stefan Hajnoczi
---
qemu-nbd.c | 10 --
1 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/qemu-nbd.c b/qemu-nbd.c
index 155b058..eb61c33 100644
--- a/qemu-nbd.c
+++ b/qemu-nbd.c
@@ -202,12 +202,10 @@ static void *nbd_client_thread(void *arg)
int ret;
pthread_t show_parts_thread;
-do {
-sock = unix_socket_outgoing(sockpath);
-if (sock == -1) {
-goto out;
-}
-} while (sock == -1);
+sock = unix_socket_outgoing(sockpath);
+if (sock == -1) {
+goto out;
+}
ret = nbd_receive_negotiate(sock, NULL, &nbdflags,
&size, &blocksize);
--
1.7.7.3
Re: [Qemu-devel] [PATCH V2 5/5] vga-cirrus: Workaround during restore when using Xen.
On Thu, 5 Jan 2012, Avi Kivity wrote: > On 01/05/2012 02:30 PM, Stefano Stabellini wrote: > > > > > > > > I cannot see how this is going to fix the save/restore issue we are > > > > trying to solve. > > > > The problem, unfortunately very complex, is that at restore time the > > > > videoram is already allocated at the physical address it was mapped > > > > before the save operation. If it was not mapped, it is at the end of the > > > > physical memory of the guest (where qemu_ram_alloc_from_ptr decides to > > > > allocate it). > > > > > > Sorry, I don't follow, please be specific as to which type of address > > > you're referring to: > > > > > > ram_addr? > > > physical address (as seen by guest - but if it is not mapped, what does > > > your last sentence mean?) > > > something else? > > > > ram_addr_t as returned by qemu_ram_alloc_from_ptr. > > > > In fact on xen qemu_ram_alloc_from_ptr asks the hypervisor to add > > the specified amount of memory to the guest physmap at > > new_block->offset. So in a way the videoram is always visible by the > > guest, initially at new_block->offset, chosen by find_ram_offset, then > > at cirrus_bank_base, when map_linear_vram_bank is called. > > Okay. So we will need to hook this differently from the memory API. > > There are two places we can hook: > - memory_region_init_ram() - similar to qemu_ram_alloc() - at region > construction time > - MemoryListener::region_add() - called the first time the region is > made visible, probably not what we want memory_region_init_ram seems to be the right place to me > > > > So the issue is that the videoram appears to qemu as part of the > > > > physical memory of the guest at an unknown address. > > > > > > > > The proposal of introducing early_savevm would easily solve this last > > > > problem: letting us know where the videoram is. The other problem, the > > > > fact that under Xen the videoram would be already allocated while under > > > > native it would not, remains unsolved. > > > > We cannot simply allocate the videoram twice because the operation > > > > would fail (Xen would realize that we are trying to allocate more memory > > > > than it we are supposed to, returning an error). > > > > However, once we know where the videoram is, we could probably figure > > > > out > > > > a smart (see hacky) way to avoid allocating it twice without changes to > > > > the cirrus code. > > > > > > I'm missing some context. Can you please explain in more detail? > > > Note that with the memory API changes, ram addresses are going away. > > > There will not be a linear space for guest RAM. We'll have > > > (MemoryRegion *, offset) pairs that will be mapped into discontiguous > > > guest physical address ranges (perhaps with overlaps). > > > > > > This is how memory is currently allocated and mapped in qemu on xen: > > > > - qemu_ram_alloc_from_ptr asks the hypervisor to allocate memory for > > the guest, the memory is added to the guest p2m (physical to machine > > translation table) at the given guest physical address > > (new_block->offset, as chosen by find_ram_offset); > > > > - qemu_get_ram_ptr uses the xen mapcache to map guest physical address > > ranges into qemu's address space, so that qemu can read/write guest > > memory; > > > > - xen_set_memory, called by the memory_listener interface, effectively > > moves a guest physical memory address range from one address to another. > > So the memory that was initially allocated at new_block->offset, as > > chosen by find_ram_offset, is going to be moved to a new destination, > > section->offset_within_address_space. > > So, where qemu has two different address spaces (ram_addr_t and guest > physical addresses), Xen has just one, and any time the translation > between the two changes, you have to move memory around. Yes > > So the videoram lifecycle is the following: > > > > - qemu_ram_alloc_from_ptr allocates the videoram and adds it to the end > > of the physmap; > > > > - qemu_get_ram_ptr maps the videoram into qemu's address space; > > > > - xen_set_memory moves the videoram to cirrus_bank_base; > > > > > > > > Now let's introduce save/restore into the picture: the videoram is part > > of the guest's memory from the hypervisor POV, so xen will take care of > > saving and restoring it as part of the normal guest memory, out of > > qemu's control. > > At restore time, we know that the videoram is already allocated and > > mapped somewhere in the guest physical address space: it could be > > cirrus_bank_base, which we don't know yet, or the initial > > new_block->offset. > > A second videoram allocation by qemu_ram_alloc_from_ptr will fail > > because of memory constraints enforced by the hypervisor. Trying to map > > the already allocated videoram into qemu's address space is not easy > > because we don't know where it is yet (keep in mind that machine->init > > is called before the machine restore functions). > > > > The "solution" I am proposing is introduc
[Qemu-devel] [Bug 502107] Re: qemu-kvm 0.12.1.2 crashes booting Ubuntu 9.10 with "-vga std"
It turns out that my previous attempt to reproduce the vga crash using an image generated by grub-mkrescue (which is easier to work with than dealing with a full Ubuntu image) is invalid due to bad instrumentation in the "normal" module init and a stack overflow produced similar results including the boot loop and internal emulation error. It suggests, however, that the vga problem and other grub-related crashes are also caused by memory corruption in guest. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/502107 Title: qemu-kvm 0.12.1.2 crashes booting Ubuntu 9.10 with "-vga std" Status in QEMU: Confirmed Bug description: I have an Ubuntu VM that works fine without "-vga std" but crashes if I add "-vga std". This is the full command line: qemu-system-x86_64 -vga std -drive cache=writeback,index=0,media=disk,file=ubuntu.img -k en-us -m 2048 -smp 2 -vnc :3102 -usbdevice tablet -enable-kvm & I get this error: KVM internal error. Suberror: 1 rax 7f789177e000 rbx rcx rdx rsi rdi 7f789177e000 rsp 7fff361775e8 rbp 7fff36177600 r8 ff80 r9 0020 r10 r11 7f789100a3f0 r12 004017c0 r13 7fff36178cf0 r14 r15 rip 7f789100aa7b rflags 00013206 cs 0033 (/ p 1 dpl 3 db 0 s 1 type b l 1 g 1 avl 0) ds (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) es (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) ss 002b (/ p 1 dpl 3 db 1 s 1 type 3 l 0 g 1 avl 0) fs (7f78917906f0/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) gs (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) tr 0040 (880001a09440/2087 p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) ldt (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) gdt 8800019fa000/7f idt 818fd000/fff cr0 80050033 cr2 2408000 cr3 379d4000 cr4 6f0 cr8 0 efer d01 emulation failure, check dmesg for details I'm running kernel 2.6.32, and I have the kvm stuff compiled directly into the kernel. There's nothing in dmesg about kvm at all. Note that in the VM grub comes up, but the VM dies when I boot the kernel. This command line works: qemu-system-x86_64 -drive cache=writeback,index=0,media=disk,file=ubuntu.img -k en-us -m 2048 -smp 2 -vnc :3102 -usbdevice tablet -enable-kvm & That is, removing "-vga std" fixes the problem. I recently added this option to both my Ubuntu and Windows XP VMs. The Windows VM still works fine. If Windows can detect that the graphics card has changed, then Ubuntu should also have no problem. That being said, I added the std option when using 0.12.1.1, so there may be a qemu regression. I have reported this bug elsewhere: http://bugs.gentoo.org/show_bug.cgi?id=299211 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/502107/+subscriptions
Re: [Qemu-devel] [PATCH] qemu-nbd: drop loop which can never loop
On 01/05/2012 02:16 PM, Stefan Hajnoczi wrote:
For some reason nbd_client_thread() has a do..while loop which can never
loop, the condition is bogus because we would take a goto instead. Drop
the loop.
Reported-by: Dr David Alan Gilbert
Signed-off-by: Stefan Hajnoczi
---
qemu-nbd.c | 10 --
1 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/qemu-nbd.c b/qemu-nbd.c
index 155b058..eb61c33 100644
--- a/qemu-nbd.c
+++ b/qemu-nbd.c
@@ -202,12 +202,10 @@ static void *nbd_client_thread(void *arg)
int ret;
pthread_t show_parts_thread;
-do {
-sock = unix_socket_outgoing(sockpath);
-if (sock == -1) {
-goto out;
-}
-} while (sock == -1);
+sock = unix_socket_outgoing(sockpath);
+if (sock == -1) {
+goto out;
+}
ret = nbd_receive_negotiate(sock, NULL,&nbdflags,
&size,&blocksize);
Reviewed-by: Paolo Bonzini
It used to loop until commit f1ef555. When I simplified the loop I
failed to actually remove it.
I suppose it will get in through your trivial patches tree, won't it?
Paolo
Re: [Qemu-devel] [PATCH V2 5/5] vga-cirrus: Workaround during restore when using Xen.
On 01/05/2012 03:17 PM, Stefano Stabellini wrote: > > > The "solution" I am proposing is introducing an early_savevm set of > > > save/restore functions so that at restore time we can get to know at > > > what address the videoram is mapped into the guest address space. Once we > > > know the address we can remap it into qemu's address space and/or move it > > > to another guest physical address. > > > > Why can we not simply track it? For every MemoryRegion, have a field > > called xen_address which tracks its location in the Xen address space > > (as determined by the last call to xen_set_memory or qemu_ram_alloc). > > xen_address would be maintained by callbacks called from the memory API > > into xen-all.c. > > Nice and simple, I like it. > However we would still need an early_savevm mechanism to save and restore the > MemoryRegions, unless they already gets saved and restored somehow? MemoryRegions are instantiated by the devices, so they should be there (creating a MemoryRegion == calling qemu_ram_alloc() in the old days) > Maybe saving and restoring the list of MemoryRegions could be useful for > the generic case too? Unneeded, since they're an integral part of the devices. However, it would be good to have a list of the devices so we could send that over instead of relying on invoking qemu with the same command-line arguments on both sides - but that's something that qom is already tackling. > > > The problem of avoiding a second allocation remains, but could be > > > solved by passing the "name" parameter from qemu_ram_alloc_from_ptr to > > > xen_ram_alloc: xen_ram_alloc could avoid doing any work for anything > > > called "vga.vram" at restore time, and use the reference to the already > > > allocated videoram instead. > > > > Hacky > > Yes :/ xen_register_framebuffer() is slightly less hacky. > > The allocation is not driven by qemu then? > > At restore time, it is not. > > > > For the long term I suggest making qemu control the allocations (perhaps > > by rpcing dom0); otherwise how can you do memory hotplug or PCI cards > > with RAM (like ivshmem)? > > It is only the videoram (well, everything allocated with > qemu_ram_alloc_from_ptr actually) and only at restore time, because > the memory in question is being considered normal guest memory and > therefore it is saved and restored by the hypervisor. > Otherwise Qemu is the one that triggers these allocations, so there are > no issues with memory hotplug and pci passthrough. Okay. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH v3 5/9] qmp: add block_stream command
On Wed, Jan 4, 2012 at 12:59 PM, Luiz Capitulino wrote:
> On Tue, 13 Dec 2011 13:52:27 +
> Stefan Hajnoczi wrote:
>
>> Add the block_stream command, which starts copy backing file contents
>> into the image file. Later patches add control over the background copy
>> speed, cancelation, and querying running streaming operations.
>
> Please also mention that you're adding an event, otherwise it comes as a
> surprise to the reviewer.
Ok.
> When we talked about this implementation (ie. having events, cancellation etc)
> I thought you were going to do something very specific to the streaming api,
> like migration. However, you ended up adding async QMP support to the block
> layer.
>
> I have the impression this could be generalized a bit more and be moved to
> QMP instead (and I strongly feel that's what we should do).
>
> There's only one problem: we are waiting for the new QMP server to work on
> that. I hope to have it integrated by the end of this month, but it might
> be possible to add async support to the current server if waiting is not
> an option.
I'm not sure what you'd like here, could you be more specific? I have
introduced the concept of a block job - a long-running operation on
block devices - and the completion event when the job finishes. I
guess you're thinking of a generic QMP job concept with a completion
event? Or something else?
What I'd like to avoid at this stage is changing the QMP API as seen
by clients because we already have at least one client which relies on
this API. I know that sucks and that this is my fault because I've
been dragging out this patch series for too long. But in a situation
like this I think it's better to live with an API that doesn't meet
the current philosophy on nice APIs but works flawlessly with both new
and existing clients. But it depends on the specifics, what changes
do you suggest?
>> + /* Base device not supported */
>> + if (base) {
>> + error_set(errp, QERR_NOT_SUPPORTED);
>> + return;
>> + }
>
> Is this a future feature? In this case I'd rather drop the argument for
> now and add it later. The only detail is that we haven't reached consensus
> if it will be required to add a new command for that or if we'll be able
> to just extend existing commands.
Marcelo sent out patches for this features. I think this series and
Marcelo's series can/will be merged one after another so that this
resolves itself without us needing to do anything.
http://www.mail-archive.com/qemu-devel@nongnu.org/msg91742.html
>> + qmp_block_stream(device, base != NULL, base, &error);
>> +
>> + if (error) {
>> + monitor_printf(mon, "%s\n", error_get_pretty(error));
>> + error_free(error);
>> + }
>
> There's a hmp_handle_error() helper recently merged that does exactly that.
Ok.
>> diff --git a/qapi-schema.json b/qapi-schema.json
>> index fbbdbe0..65308d2 100644
>> --- a/qapi-schema.json
>> +++ b/qapi-schema.json
>> @@ -901,3 +901,56 @@
>> # Notes: Do not use this command.
>> ##
>> { 'command': 'cpu', 'data': {'index': 'int'} }
>> +
>> +##
>> +# @block_stream:
>
> Command names should be verbs and please use an hyphen.
These commands have been in the Image Streaming API spec from the beginning:
http://wiki.qemu.org/Features/LiveBlockMigration/ImageStreamingAPI
We cannot prettify the API at this stage. You, Anthony, and I
discussed QAPI command naming on IRC maybe two months ago and this
seemed to be the way to do it. These commands fit the existing
block_* commands and are already in use by libvirt - if we change
names now we break libvirt.
>> +# Errors:
>> +#
>> +# DeviceInUse: streaming is already active on this device
>> +# DeviceNotFound: device name is invalid
>> +# NotSupported: image streaming is not supported by this device
>
> The convention used in this file to document errors is different.
Ok.
>> +#
>> +# Events:
>> +#
>> +# On completion the BLOCK_JOB_COMPLETED event is raised with the following
>> +# fields:
>> +#
>> +# - type: job type ("stream" for image streaming, json-string)
>> +# - device: device name (json-string)
>> +# - len: maximum progress value (json-int)
>> +# - offset: current progress value (json-int)
>> +# - speed: rate limit, bytes per second (json-int)
>> +# - error: error message (json-string, only on error)
>> +#
>> +# The completion event is raised both on success and on failure. On
>> +# success offset is equal to len. On failure offset and len can be
>> +# used to indicate at which point the operation failed.
>> +#
>> +# On failure the error field contains a human-readable error message.
>> There are
>> +# no semantics other than that streaming has failed and clients should not
>> try
>> +# to interpret the error string.
>
> Events should be documented in QMP/qmp-events.txt.
Ok.
>> +#
>> +# Since: 1.1
>> +##
>> +{ 'command': 'block_stream', 'data': { 'device': 'str', '*base': 'str' } }
>> diff --git a/qerror.c b/qerror.c
>> index 14a1d
[Qemu-devel] [Bug 897771] Re: qemu 1.0-rc4 no longer able to boot NetBSD-current/i386
I verified the fix posted by Avi to qemu-devel:
http://thread.gmane.org/gmane.comp.emulators.qemu/130695
fixes the boot crash of the mentioned image (note that the provided
command-line is not sufficent, since the image directs all its output to
the serial port (serial console), so you have to configure a serial port
to see the messages). It also does not affect - seemingly - any other
functionality so far, this and a few other guests continues to work as
before. It does not fix all the issues with *BSD reported for 1.0 but it
is already a good start.
Thanks!
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/897771
Title:
qemu 1.0-rc4 no longer able to boot NetBSD-current/i386
Status in QEMU:
Confirmed
Bug description:
Booting a NetBSD-current/i386 install CD using qemu 1.0-rc4 fails. The
same CD does boot in earlier versions of qemu, for example, 0.11.0.
To reproduce, download the
http://www.gson.org/netbsd/bugs/qemu/boot-com-20270050Z.iso
and attempt to boot it with:
qemu -nographic -cdrom boot-com-20270050Z.iso
This fails with a guest kernel panic:
NetBSD 5.99.57 (GENERIC) #0: Sun Nov 27 07:41:56 UTC 2011
bui...@b8.netbsd.org:/home/builds/ab/HEAD/i386/20270050Z-obj/home/builds/ab/HEAD/src/sys/arch/i386/compile/GENERIC
total memory = 127 MB
avail memory = 112 MB
cprng kernel: WARNING insufficient entropy at creation.
mainbus0 (root)
cpu0 at mainbus0 apid 0: QEMU Virtual CPU version 0.15.93, id 0x633
ioapic0 at mainbus0 apid 1
acpi0 at mainbus0: Intel ACPICA 20110623
panic: pci_make_tag: bad request
fatal breakpoint trap in supervisor mode
trap type 1 code 0 eip c0269b04 cs 8 eflags 282 cr2 0 ilevel 8
Stopped in pid 0.1 (system) at netbsd:breakpoint+0x4: popl%ebp
db{0}> t
breakpoint(c0c04c75,c0cc2f80,c0bc91a4,c0e358e4,2,c11b70d6,c0e35908,c053999d,c0cdef20,0)
at netbsd:breakpoint+0x4
vpanic(c0bc91a4,c0e358e4,c117d068,f,c11e6fcc,0,c0e35918,c0665969,c0bc91a4,c0b1bf4c)
at netbsd:vpanic+0x1e2
printf_nolog(c0bc91a4,c0b1bf4c,c0e35908,c010d957,8,c0c1f2c0,0,0,c0d08e20,0)
at netbsd:printf_nolog
pci_decompose_tag(c0e3599c,0,0,10,0,ca675898,c0e35988,c0d08e20,c11b9200,0)
at netbsd:pci_decompose_tag
acpi_pci_link_add_reference(c12011c0,0,0,10,0,ca41eb90,0,3,0,4) at
netbsd:acpi_pci_link_add_reference+0xb2
mpacpi_find_interrupts(ca41eb90,c0116a4a,c0116a5e,0,ca41eb90,c0e35b50,c0e35aa8,c01180c7,c,c0116a4a)
at netbsd:mpacpi_find_interrupts+0x5ea
acpi_md_callback(c,c0116a4a,c0116a5e,0,1,ca3fd7cc,1,c078e2e4,c0cb6ce0,ca435ea0)
at netbsd:acpi_md_callback+0x1c
acpi_attach(ca660500,ca660d00,c0e35b50,0,c0e35b50,80,f,10,c0b5dcd9,c0e35b42) at
netbsd:acpi_attach+0x14a
config_attach_loc(ca660500,c0c1d7a0,0,c0e35b50,0,0,2589,58421301,4350,53445842)
at netbsd:config_attach_loc+0x176
config_found_ia(ca660500,c0b59f3c,c0e35b50,0,4f424101,20534843,80,f,c0c2bbe0,c0c2bc00)
at netbsd:config_found_ia+0x36
mainbus_rescan(ca660500,c0b59f3c,0,ca660500,c0cb6ce0,c0bd71ce,c0e35bd8,c093575c,ca437f28,c0b8e0a1)
at netbsd:mainbus_rescan+0x1c2
mainbus_attach(0,ca660500,0,c078f4b7,c0b59187,c0b59187,636f4200,7368,3001403,101)
at netbsd:mainbus_attach+0xb4
config_attach_loc(0,c0c1bbb0,0,0,0,7368,f10,0,c0b59187,e3b000) at
netbsd:config_attach_loc+0x176
config_attach(0,c0c1bbb0,0,0,1984,c0cc5680,c0e35cd8,c01f224e,c0b59187,0) at
netbsd:config_attach+0x2e
config_rootfound(c0b59187,0,0,8,1984,1984,c0e35d40,c04b78d8,c0ba59a1,6) at
netbsd:config_rootfound+0x42
cpu_configure(c0ba59a1,6,3,0,,f9b00,,f9300,0,0) at
netbsd:cpu_configure+0x2a
main(0,0,0,0,0,0,0,0,0,0) at netbsd:main+0x2ba
db{0}>
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/897771/+subscriptions
[Qemu-devel] [PATCH v3 2/2] ahci: add support for non-PCI based controllers
From: Rob Herring
Add support for ahci on sysbus.
Signed-off-by: Rob Herring
Signed-off-by: Mark Langsdorf
---
Changes from v1, v2
Corrected indentation of PlatAHCIState members
Made plat_ahci_info into a single structure, not a list
hw/ide/ahci.c | 31 +++
1 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c
index 135d0ee..f052e55 100644
--- a/hw/ide/ahci.c
+++ b/hw/ide/ahci.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include "monitor.h"
#include "dma.h"
@@ -1214,3 +1215,33 @@ void ahci_reset(void *opaque)
ahci_reset_port(s, i);
}
}
+
+typedef struct PlatAHCIState {
+SysBusDevice busdev;
+AHCIState ahci;
+} PlatAHCIState;
+
+static int plat_ahci_init(SysBusDevice *dev)
+{
+PlatAHCIState *s = FROM_SYSBUS(PlatAHCIState, dev);
+ahci_init(&s->ahci, &dev->qdev, 1);
+
+sysbus_init_mmio(dev, &s->ahci.mem);
+sysbus_init_irq(dev, &s->ahci.irq);
+
+qemu_register_reset(ahci_reset, &s->ahci);
+return 0;
+}
+
+static SysBusDeviceInfo plat_ahci_info = {
+.qdev.name= "plat-ahci",
+.qdev.size= sizeof(PlatAHCIState),
+.init = plat_ahci_init,
+};
+
+static void plat_ahci_register(void)
+{
+sysbus_register_withprop(&plat_ahci_info);
+}
+device_init(plat_ahci_register);
+
--
1.7.5.4
[Qemu-devel] [PATCH v3 1/2] ahci: convert ahci_reset to use AHCIState
From: Rob Herring
Use AHCIState instead of AHCIPCIState so the function can be used for
non-PCI based AHCI controllers.
Signed-off-by: Rob Herring
Signed-off-by: Mark Langsdorf
---
Changes from v1, v2
None
hw/ide/ahci.c | 14 +++---
hw/ide/ich.c |4 ++--
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c
index 0af201d..135d0ee 100644
--- a/hw/ide/ahci.c
+++ b/hw/ide/ahci.c
@@ -336,7 +336,7 @@ static void ahci_mem_write(void *opaque, target_phys_addr_t
addr,
case HOST_CTL: /* R/W */
if (val & HOST_CTL_RESET) {
DPRINTF(-1, "HBA Reset\n");
-ahci_reset(container_of(s, AHCIPCIState, ahci));
+ahci_reset(s);
} else {
s->control_regs.ghc = (val & 0x3) | HOST_CTL_AHCI_EN;
ahci_check_irq(s);
@@ -1199,18 +1199,18 @@ void ahci_uninit(AHCIState *s)
void ahci_reset(void *opaque)
{
-struct AHCIPCIState *d = opaque;
+struct AHCIState *s = opaque;
AHCIPortRegs *pr;
int i;
-d->ahci.control_regs.irqstatus = 0;
-d->ahci.control_regs.ghc = 0;
+s->control_regs.irqstatus = 0;
+s->control_regs.ghc = 0;
-for (i = 0; i < d->ahci.ports; i++) {
-pr = &d->ahci.dev[i].port_regs;
+for (i = 0; i < s->ports; i++) {
+pr = &s->dev[i].port_regs;
pr->irq_stat = 0;
pr->irq_mask = 0;
pr->scr_ctl = 0;
-ahci_reset_port(&d->ahci, i);
+ahci_reset_port(s, i);
}
}
diff --git a/hw/ide/ich.c b/hw/ide/ich.c
index 3f7510f..44363ec 100644
--- a/hw/ide/ich.c
+++ b/hw/ide/ich.c
@@ -102,7 +102,7 @@ static int pci_ich9_ahci_init(PCIDevice *dev)
/* XXX Software should program this register */
d->card.config[0x90] = 1 << 6; /* Address Map Register - AHCI mode */
-qemu_register_reset(ahci_reset, d);
+qemu_register_reset(ahci_reset, &d->ahci);
msi_init(dev, 0x50, 1, true, false);
d->ahci.irq = d->card.irq[0];
@@ -133,7 +133,7 @@ static int pci_ich9_uninit(PCIDevice *dev)
d = DO_UPCAST(struct AHCIPCIState, card, dev);
msi_uninit(dev);
-qemu_unregister_reset(ahci_reset, d);
+qemu_unregister_reset(ahci_reset, &d->ahci);
ahci_uninit(&d->ahci);
return 0;
--
1.7.5.4
Re: [Qemu-devel] [PATCH v3 1/2] ahci: convert ahci_reset to use AHCIState
Am 05.01.2012 14:52, schrieb Mark Langsdorf:
> From: Rob Herring
>
> Use AHCIState instead of AHCIPCIState so the function can be used for
> non-PCI based AHCI controllers.
>
> Signed-off-by: Rob Herring
> Signed-off-by: Mark Langsdorf
Reviewed-by: Andreas Färber
Andreas
> ---
> Changes from v1, v2
> None
>
> hw/ide/ahci.c | 14 +++---
> hw/ide/ich.c |4 ++--
> 2 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c
> index 0af201d..135d0ee 100644
> --- a/hw/ide/ahci.c
> +++ b/hw/ide/ahci.c
> @@ -336,7 +336,7 @@ static void ahci_mem_write(void *opaque,
> target_phys_addr_t addr,
> case HOST_CTL: /* R/W */
> if (val & HOST_CTL_RESET) {
> DPRINTF(-1, "HBA Reset\n");
> -ahci_reset(container_of(s, AHCIPCIState, ahci));
> +ahci_reset(s);
> } else {
> s->control_regs.ghc = (val & 0x3) | HOST_CTL_AHCI_EN;
> ahci_check_irq(s);
> @@ -1199,18 +1199,18 @@ void ahci_uninit(AHCIState *s)
>
> void ahci_reset(void *opaque)
> {
> -struct AHCIPCIState *d = opaque;
> +struct AHCIState *s = opaque;
> AHCIPortRegs *pr;
> int i;
>
> -d->ahci.control_regs.irqstatus = 0;
> -d->ahci.control_regs.ghc = 0;
> +s->control_regs.irqstatus = 0;
> +s->control_regs.ghc = 0;
>
> -for (i = 0; i < d->ahci.ports; i++) {
> -pr = &d->ahci.dev[i].port_regs;
> +for (i = 0; i < s->ports; i++) {
> +pr = &s->dev[i].port_regs;
> pr->irq_stat = 0;
> pr->irq_mask = 0;
> pr->scr_ctl = 0;
> -ahci_reset_port(&d->ahci, i);
> +ahci_reset_port(s, i);
> }
> }
> diff --git a/hw/ide/ich.c b/hw/ide/ich.c
> index 3f7510f..44363ec 100644
> --- a/hw/ide/ich.c
> +++ b/hw/ide/ich.c
> @@ -102,7 +102,7 @@ static int pci_ich9_ahci_init(PCIDevice *dev)
> /* XXX Software should program this register */
> d->card.config[0x90] = 1 << 6; /* Address Map Register - AHCI mode */
>
> -qemu_register_reset(ahci_reset, d);
> +qemu_register_reset(ahci_reset, &d->ahci);
>
> msi_init(dev, 0x50, 1, true, false);
> d->ahci.irq = d->card.irq[0];
> @@ -133,7 +133,7 @@ static int pci_ich9_uninit(PCIDevice *dev)
> d = DO_UPCAST(struct AHCIPCIState, card, dev);
>
> msi_uninit(dev);
> -qemu_unregister_reset(ahci_reset, d);
> +qemu_unregister_reset(ahci_reset, &d->ahci);
> ahci_uninit(&d->ahci);
>
> return 0;
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
[Qemu-devel] QMP: Supporting off tree APIs
On Thu, 5 Jan 2012 13:48:43 +
Stefan Hajnoczi wrote:
> On Wed, Jan 4, 2012 at 12:59 PM, Luiz Capitulino
> wrote:
> > On Tue, 13 Dec 2011 13:52:27 +
> > Stefan Hajnoczi wrote:
> >
> >> Add the block_stream command, which starts copy backing file contents
> >> into the image file. Later patches add control over the background copy
> >> speed, cancelation, and querying running streaming operations.
> >
> > Please also mention that you're adding an event, otherwise it comes as a
> > surprise to the reviewer.
>
> Ok.
>
> > When we talked about this implementation (ie. having events, cancellation
> > etc)
> > I thought you were going to do something very specific to the streaming api,
> > like migration. However, you ended up adding async QMP support to the block
> > layer.
> >
> > I have the impression this could be generalized a bit more and be moved to
> > QMP instead (and I strongly feel that's what we should do).
> >
> > There's only one problem: we are waiting for the new QMP server to work on
> > that. I hope to have it integrated by the end of this month, but it might
> > be possible to add async support to the current server if waiting is not
> > an option.
>
> I'm not sure what you'd like here, could you be more specific? I have
> introduced the concept of a block job - a long-running operation on
> block devices - and the completion event when the job finishes. I
> guess you're thinking of a generic QMP job concept with a completion
> event?
Exactly. We should have QMP_JOB_COMPLETED instead of BLOCK_JOB_COMPLETED,
for example.
> Or something else?
>
> What I'd like to avoid at this stage is changing the QMP API as seen
> by clients because we already have at least one client which relies on
> this API. I know that sucks and that this is my fault because I've
> been dragging out this patch series for too long. But in a situation
> like this I think it's better to live with an API that doesn't meet
> the current philosophy on nice APIs but works flawlessly with both new
> and existing clients. But it depends on the specifics, what changes
> do you suggest?
[...]
> >> diff --git a/qapi-schema.json b/qapi-schema.json
> >> index fbbdbe0..65308d2 100644
> >> --- a/qapi-schema.json
> >> +++ b/qapi-schema.json
> >> @@ -901,3 +901,56 @@
> >> # Notes: Do not use this command.
> >> ##
> >> { 'command': 'cpu', 'data': {'index': 'int'} }
> >> +
> >> +##
> >> +# @block_stream:
> >
> > Command names should be verbs and please use an hyphen.
>
> These commands have been in the Image Streaming API spec from the beginning:
>
> http://wiki.qemu.org/Features/LiveBlockMigration/ImageStreamingAPI
>
> We cannot prettify the API at this stage. You, Anthony, and I
> discussed QAPI command naming on IRC maybe two months ago and this
> seemed to be the way to do it. These commands fit the existing
> block_* commands and are already in use by libvirt - if we change
> names now we break libvirt.
[...]
> >> +#
> >> +# Since: 1.1
> >> +##
> >> +{ 'command': 'block_stream', 'data': { 'device': 'str', '*base': 'str' } }
> >> diff --git a/qerror.c b/qerror.c
> >> index 14a1d59..605381a 100644
> >> --- a/qerror.c
> >> +++ b/qerror.c
> >> @@ -174,6 +174,10 @@ static const QErrorStringTable qerror_table[] = {
> >> .desc = "No '%(bus)' bus found for device '%(device)'",
> >> },
> >> {
> >> + .error_fmt = QERR_NOT_SUPPORTED,
> >> + .desc = "Not supported",
> >
> > We have QERR_UNSUPPORTED already.
>
> I know. We're stuck in a hard place here again because NotSupported
> has been in the Image Streaming API spec and hence implemented in
> libvirt for a while now. If we change this then an old client which
> only understands NotSupported will not know what to do with the
> Unsupported error.
>
> (Unsupported was not in QEMU when the Image Streaming API was defined.)
Let me try to understand it: is libvirt relying on an off tree API and
we are now required to have stable guarantees to off tree APIs?
I can't even express how insane this looks to me, at least not without
being too harsh.
Re: [Qemu-devel] [PATCH v3 1/2] ahci: convert ahci_reset to use AHCIState
On 05.01.2012, at 14:52, Mark Langsdorf wrote: > From: Rob Herring > > Use AHCIState instead of AHCIPCIState so the function can be used for > non-PCI based AHCI controllers. > > Signed-off-by: Rob Herring > Signed-off-by: Mark Langsdorf Acked-by: Alexander Graf Alex
Re: [Qemu-devel] [PATCH v3 2/2] ahci: add support for non-PCI based controllers
Am 05.01.2012 14:52, schrieb Mark Langsdorf:
> From: Rob Herring
>
> Add support for ahci on sysbus.
>
> Signed-off-by: Rob Herring
> Signed-off-by: Mark Langsdorf
> ---
> Changes from v1, v2
> Corrected indentation of PlatAHCIState members
> Made plat_ahci_info into a single structure, not a list
>
> hw/ide/ahci.c | 31 +++
> 1 files changed, 31 insertions(+), 0 deletions(-)
>
> diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c
> index 135d0ee..f052e55 100644
> --- a/hw/ide/ahci.c
> +++ b/hw/ide/ahci.c
> @@ -25,6 +25,7 @@
> #include
> #include
> #include
> +#include
>
> #include "monitor.h"
> #include "dma.h"
> @@ -1214,3 +1215,33 @@ void ahci_reset(void *opaque)
> ahci_reset_port(s, i);
> }
> }
> +
> +typedef struct PlatAHCIState {
> +SysBusDevice busdev;
> +AHCIState ahci;
> +} PlatAHCIState;
> +
> +static int plat_ahci_init(SysBusDevice *dev)
> +{
> +PlatAHCIState *s = FROM_SYSBUS(PlatAHCIState, dev);
> +ahci_init(&s->ahci, &dev->qdev, 1);
> +
> +sysbus_init_mmio(dev, &s->ahci.mem);
> +sysbus_init_irq(dev, &s->ahci.irq);
> +
> +qemu_register_reset(ahci_reset, &s->ahci);
> +return 0;
> +}
> +
> +static SysBusDeviceInfo plat_ahci_info = {
> +.qdev.name= "plat-ahci",
The commit message does not given an indication where "plat" comes from
- is that an ARM device name?
> +.qdev.size= sizeof(PlatAHCIState),
> +.init = plat_ahci_init,
> +};
> +
> +static void plat_ahci_register(void)
> +{
> +sysbus_register_withprop(&plat_ahci_info);
> +}
> +device_init(plat_ahci_register);
> +
Please move the empty line to above the device_init().
Does this patch actually make something work? If yes, please state so,
including usage instructions. If not, then I would suggest to hold this
one back and to send it together with any follow-on patches that wire it
up on some machine.
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH v3 5/9] qmp: add block_stream command
On Thu, Jan 5, 2012 at 1:48 PM, Stefan Hajnoczi wrote:
>>> + /* Base device not supported */
>>> + if (base) {
>>> + error_set(errp, QERR_NOT_SUPPORTED);
>>> + return;
>>> + }
>>
>> Is this a future feature? In this case I'd rather drop the argument for
>> now and add it later. The only detail is that we haven't reached consensus
>> if it will be required to add a new command for that or if we'll be able
>> to just extend existing commands.
>
> Marcelo sent out patches for this features. I think this series and
> Marcelo's series can/will be merged one after another so that this
> resolves itself without us needing to do anything.
>
> http://www.mail-archive.com/qemu-devel@nongnu.org/msg91742.html
Just talked to Marcelo. We'll merge his series into this one so this
issue will be gone completely in v4.
Re: [Qemu-devel] [PATCH] qemu-nbd: drop loop which can never loop
On Thu, Jan 5, 2012 at 1:29 PM, Paolo Bonzini wrote: > I suppose it will get in through your trivial patches tree, won't it? Yes
[Qemu-devel] [Bug 502107] Re: qemu-kvm 0.12.1.2 crashes booting Ubuntu 9.10 with "-vga std"
See also LP#717445: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/717445 which is exactly the same issue but reported against grub. And I tend to think more and more it is a grub bug after all, not qemu/kvm/bios bug. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/502107 Title: qemu-kvm 0.12.1.2 crashes booting Ubuntu 9.10 with "-vga std" Status in QEMU: Confirmed Bug description: I have an Ubuntu VM that works fine without "-vga std" but crashes if I add "-vga std". This is the full command line: qemu-system-x86_64 -vga std -drive cache=writeback,index=0,media=disk,file=ubuntu.img -k en-us -m 2048 -smp 2 -vnc :3102 -usbdevice tablet -enable-kvm & I get this error: KVM internal error. Suberror: 1 rax 7f789177e000 rbx rcx rdx rsi rdi 7f789177e000 rsp 7fff361775e8 rbp 7fff36177600 r8 ff80 r9 0020 r10 r11 7f789100a3f0 r12 004017c0 r13 7fff36178cf0 r14 r15 rip 7f789100aa7b rflags 00013206 cs 0033 (/ p 1 dpl 3 db 0 s 1 type b l 1 g 1 avl 0) ds (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) es (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) ss 002b (/ p 1 dpl 3 db 1 s 1 type 3 l 0 g 1 avl 0) fs (7f78917906f0/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) gs (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) tr 0040 (880001a09440/2087 p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) ldt (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) gdt 8800019fa000/7f idt 818fd000/fff cr0 80050033 cr2 2408000 cr3 379d4000 cr4 6f0 cr8 0 efer d01 emulation failure, check dmesg for details I'm running kernel 2.6.32, and I have the kvm stuff compiled directly into the kernel. There's nothing in dmesg about kvm at all. Note that in the VM grub comes up, but the VM dies when I boot the kernel. This command line works: qemu-system-x86_64 -drive cache=writeback,index=0,media=disk,file=ubuntu.img -k en-us -m 2048 -smp 2 -vnc :3102 -usbdevice tablet -enable-kvm & That is, removing "-vga std" fixes the problem. I recently added this option to both my Ubuntu and Windows XP VMs. The Windows VM still works fine. If Windows can detect that the graphics card has changed, then Ubuntu should also have no problem. That being said, I added the std option when using 0.12.1.1, so there may be a qemu regression. I have reported this bug elsewhere: http://bugs.gentoo.org/show_bug.cgi?id=299211 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/502107/+subscriptions
Re: [Qemu-devel] [PATCH v3 2/2] ahci: add support for non-PCI based controllers
On 05.01.2012, at 15:16, Andreas Färber wrote:
> Am 05.01.2012 14:52, schrieb Mark Langsdorf:
>> From: Rob Herring
>>
>> Add support for ahci on sysbus.
>>
>> Signed-off-by: Rob Herring
>> Signed-off-by: Mark Langsdorf
>> ---
>> Changes from v1, v2
>> Corrected indentation of PlatAHCIState members
>> Made plat_ahci_info into a single structure, not a list
>>
>> hw/ide/ahci.c | 31 +++
>> 1 files changed, 31 insertions(+), 0 deletions(-)
>>
>> diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c
>> index 135d0ee..f052e55 100644
>> --- a/hw/ide/ahci.c
>> +++ b/hw/ide/ahci.c
>> @@ -25,6 +25,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include "monitor.h"
>> #include "dma.h"
>> @@ -1214,3 +1215,33 @@ void ahci_reset(void *opaque)
>> ahci_reset_port(s, i);
>> }
>> }
>> +
>> +typedef struct PlatAHCIState {
>> +SysBusDevice busdev;
>> +AHCIState ahci;
>> +} PlatAHCIState;
>> +
>> +static int plat_ahci_init(SysBusDevice *dev)
>> +{
>> +PlatAHCIState *s = FROM_SYSBUS(PlatAHCIState, dev);
>> +ahci_init(&s->ahci, &dev->qdev, 1);
>> +
>> +sysbus_init_mmio(dev, &s->ahci.mem);
>> +sysbus_init_irq(dev, &s->ahci.irq);
It's still unclear to me how you connect an irq line on the command line. How
do you instantiate this device?
>> +
>> +qemu_register_reset(ahci_reset, &s->ahci);
>> +return 0;
>> +}
>> +
>> +static SysBusDeviceInfo plat_ahci_info = {
>> +.qdev.name= "plat-ahci",
>
> The commit message does not given an indication where "plat" comes from
> - is that an ARM device name?
"plat" here means "platform device". I'm not sure I like the naming though.
Basically it's a sysbus version of AHCI, similar to how virtio-mmio is a sysbus
version of virtio.
How about "sysbus-ahci"?
>
>> +.qdev.size= sizeof(PlatAHCIState),
>> +.init = plat_ahci_init,
>> +};
>> +
>> +static void plat_ahci_register(void)
>> +{
>> +sysbus_register_withprop(&plat_ahci_info);
>> +}
>> +device_init(plat_ahci_register);
>> +
>
> Please move the empty line to above the device_init().
>
> Does this patch actually make something work? If yes, please state so,
> including usage instructions. If not, then I would suggest to hold this
> one back and to send it together with any follow-on patches that wire it
> up on some machine.
You can always just create the device manually with -device and hook it up in
the guest device tree or machine description manually.
However the question still stands: Have you verified this code works?
Alex
Re: [Qemu-devel] [PATCH v3 2/2] ahci: add support for non-PCI based controllers
Am 05.01.2012 15:26, schrieb Alexander Graf:
>
> On 05.01.2012, at 15:16, Andreas Färber wrote:
>
>> Am 05.01.2012 14:52, schrieb Mark Langsdorf:
>>> From: Rob Herring
>>>
>>> Add support for ahci on sysbus.
>>>
>>> Signed-off-by: Rob Herring
>>> Signed-off-by: Mark Langsdorf
>>> ---
>>> Changes from v1, v2
>>> Corrected indentation of PlatAHCIState members
>>> Made plat_ahci_info into a single structure, not a list
>>>
>>> hw/ide/ahci.c | 31 +++
>>> 1 files changed, 31 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c
>>> index 135d0ee..f052e55 100644
>>> --- a/hw/ide/ahci.c
>>> +++ b/hw/ide/ahci.c
>>> @@ -25,6 +25,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>>
>>> #include "monitor.h"
>>> #include "dma.h"
>>> @@ -1214,3 +1215,33 @@ void ahci_reset(void *opaque)
>>> ahci_reset_port(s, i);
>>> }
>>> }
>>> +
>>> +typedef struct PlatAHCIState {
>>> +SysBusDevice busdev;
>>> +AHCIState ahci;
>>> +} PlatAHCIState;
>>> +
>>> +static int plat_ahci_init(SysBusDevice *dev)
>>> +{
>>> +PlatAHCIState *s = FROM_SYSBUS(PlatAHCIState, dev);
>>> +ahci_init(&s->ahci, &dev->qdev, 1);
>>> +
>>> +sysbus_init_mmio(dev, &s->ahci.mem);
>>> +sysbus_init_irq(dev, &s->ahci.irq);
>
> It's still unclear to me how you connect an irq line on the command line. How
> do you instantiate this device?
I thought, with qdev that's not possible at all.
>>> +
>>> +qemu_register_reset(ahci_reset, &s->ahci);
>>> +return 0;
>>> +}
>>> +
>>> +static SysBusDeviceInfo plat_ahci_info = {
>>> +.qdev.name= "plat-ahci",
>>
>> The commit message does not given an indication where "plat" comes from
>> - is that an ARM device name?
>
> "plat" here means "platform device". I'm not sure I like the naming though.
> Basically it's a sysbus version of AHCI, similar to how virtio-mmio is a
> sysbus version of virtio.
>
> How about "sysbus-ahci"?
Yeah, sounds better to me.
> However the question still stands: Have you verified this code works?
I believe that one's addressed to Mark. ;)
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH v3 2/2] ahci: add support for non-PCI based controllers
On 01/05/2012 08:26 AM, Alexander Graf wrote:
>
> On 05.01.2012, at 15:16, Andreas Färber wrote:
>
>> Am 05.01.2012 14:52, schrieb Mark Langsdorf:
>>> From: Rob Herring
>>>
>>> Add support for ahci on sysbus.
>>>
>>> Signed-off-by: Rob Herring
>>> Signed-off-by: Mark Langsdorf
>>> ---
>>> Changes from v1, v2
>>> Corrected indentation of PlatAHCIState members
>>> Made plat_ahci_info into a single structure, not a list
>>>
>>> hw/ide/ahci.c | 31 +++
>>> 1 files changed, 31 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c
>>> index 135d0ee..f052e55 100644
>>> --- a/hw/ide/ahci.c
>>> +++ b/hw/ide/ahci.c
>>> @@ -25,6 +25,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>>
>>> #include "monitor.h"
>>> #include "dma.h"
>>> @@ -1214,3 +1215,33 @@ void ahci_reset(void *opaque)
>>> ahci_reset_port(s, i);
>>> }
>>> }
>>> +
>>> +typedef struct PlatAHCIState {
>>> +SysBusDevice busdev;
>>> +AHCIState ahci;
>>> +} PlatAHCIState;
>>> +
>>> +static int plat_ahci_init(SysBusDevice *dev)
>>> +{
>>> +PlatAHCIState *s = FROM_SYSBUS(PlatAHCIState, dev);
>>> +ahci_init(&s->ahci, &dev->qdev, 1);
>>> +
>>> +sysbus_init_mmio(dev, &s->ahci.mem);
>>> +sysbus_init_irq(dev, &s->ahci.irq);
>
> It's still unclear to me how you connect an irq line on the command line. How
> do you instantiate this device?
I'm not sure how it's done on the command line. In the SoC model that
this is intended for, I call sysbus_create_simple().
>>> +qemu_register_reset(ahci_reset, &s->ahci);
>>> +return 0;
>>> +}
>>> +
>>> +static SysBusDeviceInfo plat_ahci_info = {
>>> +.qdev.name= "plat-ahci",
>>
>> The commit message does not given an indication where "plat" comes from
>> - is that an ARM device name?
>
> "plat" here means "platform device". I'm not sure I like the naming though.
> Basically it's a sysbus version of AHCI, similar to how virtio-mmio is a
> sysbus version of virtio.
>
> How about "sysbus-ahci"?
Sure. I'll make that change.
>> Does this patch actually make something work? If yes, please state so,
>> including usage instructions. If not, then I would suggest to hold this
>> one back and to send it together with any follow-on patches that wire it
>> up on some machine.
>
> You can always just create the device manually with -device and hook it up in
> the guest device tree or machine description manually.
>
> However the question still stands: Have you verified this code works?
It's used in the Highbank SoC model, which hasn't been released yet. I'm
waiting on some other patches to make it upstream, mostly Trustzone
support now.
I can resubmit it with the Highbank SoC model when that goes out if
you would prefer.
--Mark Langsdorf
Calxeda, Inc.
Re: [Qemu-devel] [PATCH V2 5/5] vga-cirrus: Workaround during restore when using Xen.
On Thu, 5 Jan 2012, Avi Kivity wrote: > On 01/05/2012 03:17 PM, Stefano Stabellini wrote: > > > > The "solution" I am proposing is introducing an early_savevm set of > > > > save/restore functions so that at restore time we can get to know at > > > > what address the videoram is mapped into the guest address space. Once > > > > we > > > > know the address we can remap it into qemu's address space and/or move > > > > it > > > > to another guest physical address. > > > > > > Why can we not simply track it? For every MemoryRegion, have a field > > > called xen_address which tracks its location in the Xen address space > > > (as determined by the last call to xen_set_memory or qemu_ram_alloc). > > > xen_address would be maintained by callbacks called from the memory API > > > into xen-all.c. > > > > Nice and simple, I like it. > > However we would still need an early_savevm mechanism to save and restore > > the > > MemoryRegions, unless they already gets saved and restored somehow? > > MemoryRegions are instantiated by the devices, so they should be there > (creating a MemoryRegion == calling qemu_ram_alloc() in the old days) If the MemoryRegions are re-created by the devices, then we need another mechanism to find out where the videoram is. What I am saying is that the suggestion of having a xen_address field for every MemoryRegion would make the code cleaner but it would not solve the save/restore issue described in the previous email. > > Maybe saving and restoring the list of MemoryRegions could be useful for > > the generic case too? > > Unneeded, since they're an integral part of the devices. However, it > would be good to have a list of the devices so we could send that over > instead of relying on invoking qemu with the same command-line arguments > on both sides - but that's something that qom is already tackling. > > > > > The problem of avoiding a second allocation remains, but could be > > > > solved by passing the "name" parameter from qemu_ram_alloc_from_ptr to > > > > xen_ram_alloc: xen_ram_alloc could avoid doing any work for anything > > > > called "vga.vram" at restore time, and use the reference to the already > > > > allocated videoram instead. > > > > > > Hacky > > > > Yes :/ > > xen_register_framebuffer() is slightly less hacky. I agree, however xen_register_framebuffer is called after memory_region_init_ram, so the allocation would have been made already.
Re: [Qemu-devel] [PATCH v4 0/2]: qemu-ga: Add the guest-suspend command
On Thu, 5 Jan 2012 12:59:27 + "Daniel P. Berrange" wrote: > On Thu, Jan 05, 2012 at 10:37:14AM -0200, Luiz Capitulino wrote: > > On Thu, 5 Jan 2012 10:16:30 + > > "Daniel P. Berrange" wrote: > > > > > On Wed, Jan 04, 2012 at 05:45:11PM -0200, Luiz Capitulino wrote: > > > > This version drops modes 'sleep' and 'hybrid' because they don't work > > > > properly due to issues in qemu. Only the 'hibernate' mode is supported > > > > for now. > > > > > > IMHO this is short-sighted. When the bugs QEMU in are fixed so that > > > these modes work, you have needlessly put users in the situation where > > > they have to now upgrade the guest agent everywhere to take advantage > > > of the bugfix. > > > > That was my thinking until v4. But after discussing with Michael the issues > > we have with S3 I concluded that it doesn't make sense to offer an API to > > something that doesn't work, this will just generate bug reports. Also, > > updating to get new features is normal and expected. > > This is assuming that users will always upgrade their VMs & hosts in > lock step, which I rather doubt they will in practice. eg imagine a > deployment might have a mixture of hosts, running QEMU 1.1 (broken S3) > and QEMU 1.2 (working S3). If they build VM disk images they will likely > use the QEMU GA from 1.2 for all their builds, even if many of them > will only run on QEMU 1.1 hosts. So you'll end up having 'sleep' and > 'hybrid' commands available in the guest agent, even though the host > QEMU doesn't work properly. > > So you *will* ultimately need to make sure that QEMU GA from 1.2, has > sensible behaviour when run on a QEMU 1.1 host. If you don't address > this during 1.1, you may well find yourself in an un-winnable situation > for 1.2, where it is impossible to provide good behaviour on old hosts. > > So IMHO we are better off in the long run, if we include all commands > right now, even though some don't work yet, and work to ensure we have > good error reporting behaviour for those that don't work. Yes, I agree. As a side note: if we add error reporting it will only work on 1.1 and later. Ie, the problem you describe above will still happen with 1.0. But what you're suggesting seems to be the right thing to do. Do you agree Michael? > As an example, if S3 is broken in current QEMU, then we should not be > advertizing S3 to the guest OS. This would allow 'pm-is-supported --suspend' > to return false, at which point the guest agent can send back a nice error > message 'Suspend is not supported on this host', instead of just having the > guest try to suspend & hang or worse.
Re: [Qemu-devel] [PATCH 02/18] ppc_prep: convert to memory API
Am 17.10.2011 16:02, schrieb Avi Kivity:
> Signed-off-by: Avi Kivity
This one originally broke the prep machine:
0c90c52fab5ea92d7f12b29bfe26a7cd75d9efcb is the first bad commit
commit 0c90c52fab5ea92d7f12b29bfe26a7cd75d9efcb
Author: Avi Kivity
Date: Sun Sep 25 16:57:45 2011 +0300
ppc_prep: convert to memory API
Signed-off-by: Avi Kivity
:04 04 c550e1f7cd1a3c081dc60fb3fcb136de29213883
417e0110dae140498b6c4ba1532ce66dd99d80dc M hw
qemu: fatal: Trying to execute code outside RAM or ROM at 0xfff00700
NIP fff00700 LR fe7c CTR XER
MSR HID0 HF idx 1
TB 00111879 DECR 4294855468
GPR00 fff83e00
GPR04
GPR08 fe00
GPR12 0040 3dfc
GPR16
GPR20
GPR24
GPR28
CR [ - - - - - - - - ] RES
FPR00
FPR04
FPR08
FPR12
FPR16
FPR20
FPR24
FPR28
FPSCR
SRR0 SRR1 00080040PVR 00050100 VRSAVE
SPRG0 SPRG1 SPRG2 SPRG3
SPRG4 SPRG5 SPRG6 SPRG7
SDR1
There does seem to be a MemoryRegion for the BIOS, which seems okay on a
brief look.
Andreas
> ---
> hw/ppc_prep.c | 107
> ++---
> 1 files changed, 41 insertions(+), 66 deletions(-)
>
> diff --git a/hw/ppc_prep.c b/hw/ppc_prep.c
> index 6427baa..f22d5b9 100644
> --- a/hw/ppc_prep.c
> +++ b/hw/ppc_prep.c
> @@ -116,16 +116,17 @@ static uint32_t speaker_ioport_read (void *opaque,
> uint32_t addr)
>
> /* PCI intack register */
> /* Read-only register (?) */
> -static void _PPC_intack_write (void *opaque,
> - target_phys_addr_t addr, uint32_t value)
> +static void PPC_intack_write (void *opaque, target_phys_addr_t addr,
> + uint64_t value, unsigned size)
> {
> #if 0
> -printf("%s: 0x" TARGET_FMT_plx " => 0x%08" PRIx32 "\n", __func__, addr,
> +printf("%s: 0x" TARGET_FMT_plx " => 0x%08" PRIx64 "\n", __func__, addr,
> value);
> #endif
> }
>
> -static inline uint32_t _PPC_intack_read(target_phys_addr_t addr)
> +static uint64_t PPC_intack_read(void *opaque, target_phys_addr_t addr,
> +unsigned size)
> {
> uint32_t retval = 0;
>
> @@ -139,31 +140,10 @@ static inline uint32_t
> _PPC_intack_read(target_phys_addr_t addr)
> return retval;
> }
>
> -static uint32_t PPC_intack_readb (void *opaque, target_phys_addr_t addr)
> -{
> -return _PPC_intack_read(addr);
> -}
> -
> -static uint32_t PPC_intack_readw (void *opaque, target_phys_addr_t addr)
> -{
> -return _PPC_intack_read(addr);
> -}
> -
> -static uint32_t PPC_intack_readl (void *opaque, target_phys_addr_t addr)
> -{
> -return _PPC_intack_read(addr);
> -}
> -
> -static CPUWriteMemoryFunc * const PPC_intack_write[] = {
> -&_PPC_intack_write,
> -&_PPC_intack_write,
> -&_PPC_intack_write,
> -};
> -
> -static CPUReadMemoryFunc * const PPC_intack_read[] = {
> -&PPC_intack_readb,
> -&PPC_intack_readw,
> -&PPC_intack_readl,
> +static const MemoryRegionOps PPC_intack_ops = {
> +.read = PPC_intack_read,
> +.write = PPC_intack_write,
> +.endianness = DEVICE_LITTLE_ENDIAN,
> };
>
> /* PowerPC control and status registers */
> @@ -244,17 +224,14 @@ static uint32_t PPC_XCSR_readl (void *opaque,
> target_phys_addr_t addr)
> return retval;
> }
>
> -static CPUWriteMemoryFunc * const PPC_XCSR_write[] = {
> -&PPC_XCSR_writeb,
> -&PPC_XCSR_writew,
> -&PPC_XCSR_writel,
> +static const MemoryRegionOps PPC_XCSR_ops = {
> +.old_mmio = {
> +.read = { PPC_XCSR_readb, PPC_XCSR_readw, PPC_XCSR_readl, },
> +.write = { PPC_XCSR_writeb, PPC_XCSR_writew, PPC_XCSR_writel, },
> +},
> +.endianness = DEVICE_LITTLE_ENDIAN,
> };
>
> -static CPUReadMemoryFunc * const PPC_XCSR_read[] = {
> -&PPC_XCSR_readb,
> -
Re: [Qemu-devel] [PATCH 02/18] ppc_prep: convert to memory API
On 01/05/2012 04:45 PM, Andreas Färber wrote: > Am 17.10.2011 16:02, schrieb Avi Kivity: > > Signed-off-by: Avi Kivity > > This one originally broke the prep machine: > Instructions on how to reproduce, please. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] vhost broken?
On Thu, Jan 05, 2012 at 01:16:22PM +0200, Avi Kivity wrote: > On 01/05/2012 01:05 PM, Gerd Hoffmann wrote: > > Hi, > > > > current master seems to corrupt guest memory, I get guest errors like > > this one: > > > > swap_dup: Bad swap file entry 1999800080 > > BUG: Bad page map in process udevd pte:bec5f30054520100 pmd:1f6f4067 > > addr:7fc464a02000 vm_flags:00100073 anon_vma:88001f928ec0 > > mapping:(null) index:7fc464a02 > > Pid: 555, comm: udevd Not tainted 2.6.32-220.el6.x86_64 #1 > > > > bisecting points to this commit: > > > > commit 04097f7c5957273c578f72b9bd603ba6b1d69e33 > > Author: Avi Kivity > > Date: Sun Dec 18 14:06:05 2011 +0200 > > > > vhost: convert to MemoryListener API > > > > Very likely. Michael, can you help? > > I don't have a vhost setup, can you share your command line? Just chmod /dev/vhost-net to allow access, then add vhost=on to the tap device. Example -netdev tap,id=foo,ifname=msttap0,script=/home/mst/ifup,downscript=no,vhost=on -device virtio-net-pci,netdev=foo > -- > error compiling committee.c: too many arguments to function
[Qemu-devel] [Bug 897771] Re: qemu 1.0-rc4 no longer able to boot NetBSD-current/i386
> note that the provided command-line is not sufficent, since the image
directs all its output to the serial port (serial console), so you have
to configure a serial port to see the messages
That command line works as-is for me, and it's what I was told to use
back when "-serial stdio -nographic" stopped working some time around
qemu version 0.12.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/897771
Title:
qemu 1.0-rc4 no longer able to boot NetBSD-current/i386
Status in QEMU:
Confirmed
Bug description:
Booting a NetBSD-current/i386 install CD using qemu 1.0-rc4 fails. The
same CD does boot in earlier versions of qemu, for example, 0.11.0.
To reproduce, download the
http://www.gson.org/netbsd/bugs/qemu/boot-com-20270050Z.iso
and attempt to boot it with:
qemu -nographic -cdrom boot-com-20270050Z.iso
This fails with a guest kernel panic:
NetBSD 5.99.57 (GENERIC) #0: Sun Nov 27 07:41:56 UTC 2011
bui...@b8.netbsd.org:/home/builds/ab/HEAD/i386/20270050Z-obj/home/builds/ab/HEAD/src/sys/arch/i386/compile/GENERIC
total memory = 127 MB
avail memory = 112 MB
cprng kernel: WARNING insufficient entropy at creation.
mainbus0 (root)
cpu0 at mainbus0 apid 0: QEMU Virtual CPU version 0.15.93, id 0x633
ioapic0 at mainbus0 apid 1
acpi0 at mainbus0: Intel ACPICA 20110623
panic: pci_make_tag: bad request
fatal breakpoint trap in supervisor mode
trap type 1 code 0 eip c0269b04 cs 8 eflags 282 cr2 0 ilevel 8
Stopped in pid 0.1 (system) at netbsd:breakpoint+0x4: popl%ebp
db{0}> t
breakpoint(c0c04c75,c0cc2f80,c0bc91a4,c0e358e4,2,c11b70d6,c0e35908,c053999d,c0cdef20,0)
at netbsd:breakpoint+0x4
vpanic(c0bc91a4,c0e358e4,c117d068,f,c11e6fcc,0,c0e35918,c0665969,c0bc91a4,c0b1bf4c)
at netbsd:vpanic+0x1e2
printf_nolog(c0bc91a4,c0b1bf4c,c0e35908,c010d957,8,c0c1f2c0,0,0,c0d08e20,0)
at netbsd:printf_nolog
pci_decompose_tag(c0e3599c,0,0,10,0,ca675898,c0e35988,c0d08e20,c11b9200,0)
at netbsd:pci_decompose_tag
acpi_pci_link_add_reference(c12011c0,0,0,10,0,ca41eb90,0,3,0,4) at
netbsd:acpi_pci_link_add_reference+0xb2
mpacpi_find_interrupts(ca41eb90,c0116a4a,c0116a5e,0,ca41eb90,c0e35b50,c0e35aa8,c01180c7,c,c0116a4a)
at netbsd:mpacpi_find_interrupts+0x5ea
acpi_md_callback(c,c0116a4a,c0116a5e,0,1,ca3fd7cc,1,c078e2e4,c0cb6ce0,ca435ea0)
at netbsd:acpi_md_callback+0x1c
acpi_attach(ca660500,ca660d00,c0e35b50,0,c0e35b50,80,f,10,c0b5dcd9,c0e35b42) at
netbsd:acpi_attach+0x14a
config_attach_loc(ca660500,c0c1d7a0,0,c0e35b50,0,0,2589,58421301,4350,53445842)
at netbsd:config_attach_loc+0x176
config_found_ia(ca660500,c0b59f3c,c0e35b50,0,4f424101,20534843,80,f,c0c2bbe0,c0c2bc00)
at netbsd:config_found_ia+0x36
mainbus_rescan(ca660500,c0b59f3c,0,ca660500,c0cb6ce0,c0bd71ce,c0e35bd8,c093575c,ca437f28,c0b8e0a1)
at netbsd:mainbus_rescan+0x1c2
mainbus_attach(0,ca660500,0,c078f4b7,c0b59187,c0b59187,636f4200,7368,3001403,101)
at netbsd:mainbus_attach+0xb4
config_attach_loc(0,c0c1bbb0,0,0,0,7368,f10,0,c0b59187,e3b000) at
netbsd:config_attach_loc+0x176
config_attach(0,c0c1bbb0,0,0,1984,c0cc5680,c0e35cd8,c01f224e,c0b59187,0) at
netbsd:config_attach+0x2e
config_rootfound(c0b59187,0,0,8,1984,1984,c0e35d40,c04b78d8,c0ba59a1,6) at
netbsd:config_rootfound+0x42
cpu_configure(c0ba59a1,6,3,0,,f9b00,,f9300,0,0) at
netbsd:cpu_configure+0x2a
main(0,0,0,0,0,0,0,0,0,0) at netbsd:main+0x2ba
db{0}>
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/897771/+subscriptions
Re: [Qemu-devel] 回??: [PATCH 2/2] umem: chardevice for kvm postcopy
qemu -m 256 -hda xxx -monitor stdio -enable-kvm -postcopy -incoming
tcp:xxx: -vnc :1
I think it doesn't go wrong
于 2012/1/5 20:18, Isaku Yamahata 写道:
> Hmm, this sounds like you haven't specified -postcopy option at the
> incoming qemu.
> How did you start incoming qemu?
>
>
> On Thu, Jan 05, 2012 at 07:10:42PM +0800, Tommy wrote:
>> After I use this series of patches, but the migration failed.
>> 2, I start migrate -d -p -n tcp:xxx: on the outgoing node
>> 2, on the incoming part, the qemu get stuck and migration failed
>> the destnation can not typing any more
>>
>> today I found it's just at qemu_loadvm_state, just after the while loop
>> ,maybe
>> in cpu_synchronize_all_post_init
>> I think there is some problems with qemu side for it doesn't get to the umem
>> part
>> I'm not sure about the problem
>> do you have some suggestion?
>> ━━━
>> Tommy
>>
>> From: Isaku Yamahata
>> Date: 2012-01-05 18:48
>> To: thfbjyddx
>> CC: t.hirofuchi; qemu-devel; kvm; satoshi.itoh
>> Subject: Re: [Qemu-devel] ??: [PATCH 2/2] umem: chardevice for kvm postcopy
>> On Thu, Jan 05, 2012 at 12:08:50PM +0800, thfbjyddx wrote:
>>> hi,
>>> I've tried to use this patch,
>>
>> Oh great! Can we share your results?
>>
>>
>>> but it doesn't work for compiling error on
>>>
>>> page = alloc_page_vma(GFP_HIGHUSER_MOVABLE, vma, vmf->address);//vmf->
>>> virtual_address?
>>>
>>> I guess it's for the wrong kernel version?
>>> can you give me some detail about this or any clue?
>>> 3x
>>
>> Thank you for report. The following should fix.
>> It depends on kernel configuration. My config didn't catch it.
>>
>> diff --git a/drivers/char/umem.c b/drivers/char/umem.c
>> index 4d031b5..853f1ce 100644
>> --- a/drivers/char/umem.c
>> +++ b/drivers/char/umem.c
>> @@ -129,7 +129,7 @@ static int umem_minor_fault(struct umem *umem,
>>* vmf->page = fake_vmf->page;
>>*/
>>
>> - page = alloc_page_vma(GFP_HIGHUSER_MOVABLE, vma, vmf->address);
>> + page = alloc_page_vma(GFP_HIGHUSER_MOVABLE, vma, vmf->virtual_address);
>> if (!page)
>> return VM_FAULT_OOM;
>> if (mem_cgroup_cache_charge(page, vma->vm_mm, GFP_KERNEL)) {
>>
>>
>>
>> --
>> yamahata
>>
>>
Re: [Qemu-devel] 回??: [PATCH 2/2] umem: chardevice for kvm postcopy
sorry, it's:
qemu -m 256 -hda xxx -monitor stdio -enable-kvm -postcopy -incoming
tcp:0: -vnc :1
anything wrong?
于 2012/1/5 23:02, Tommy Tang 写道:
> qemu -m 256 -hda xxx -monitor stdio -enable-kvm -postcopy -incoming
> tcp:xxx: -vnc :1
> I think it doesn't go wrong
>
> 于 2012/1/5 20:18, Isaku Yamahata 写道:
>> Hmm, this sounds like you haven't specified -postcopy option at the
>> incoming qemu.
>> How did you start incoming qemu?
>>
>>
>> On Thu, Jan 05, 2012 at 07:10:42PM +0800, Tommy wrote:
>>> After I use this series of patches, but the migration failed.
>>> 2, I start migrate -d -p -n tcp:xxx: on the outgoing node
>>> 2, on the incoming part, the qemu get stuck and migration failed
>>> the destnation can not typing any more
>>>
>>> today I found it's just at qemu_loadvm_state, just after the while loop
>>> ,maybe
>>> in cpu_synchronize_all_post_init
>>> I think there is some problems with qemu side for it doesn't get to the umem
>>> part
>>> I'm not sure about the problem
>>> do you have some suggestion?
>>> ━━━
>>> Tommy
>>>
>>> From: Isaku Yamahata
>>> Date: 2012-01-05 18:48
>>> To: thfbjyddx
>>> CC: t.hirofuchi; qemu-devel; kvm; satoshi.itoh
>>> Subject: Re: [Qemu-devel] ??: [PATCH 2/2] umem: chardevice for kvm postcopy
>>> On Thu, Jan 05, 2012 at 12:08:50PM +0800, thfbjyddx wrote:
hi,
I've tried to use this patch,
>>>
>>> Oh great! Can we share your results?
>>>
>>>
but it doesn't work for compiling error on
page = alloc_page_vma(GFP_HIGHUSER_MOVABLE, vma, vmf->address);//vmf->
virtual_address?
I guess it's for the wrong kernel version?
can you give me some detail about this or any clue?
3x
>>>
>>> Thank you for report. The following should fix.
>>> It depends on kernel configuration. My config didn't catch it.
>>>
>>> diff --git a/drivers/char/umem.c b/drivers/char/umem.c
>>> index 4d031b5..853f1ce 100644
>>> --- a/drivers/char/umem.c
>>> +++ b/drivers/char/umem.c
>>> @@ -129,7 +129,7 @@ static int umem_minor_fault(struct umem *umem,
>>>* vmf->page = fake_vmf->page;
>>>*/
>>>
>>> - page = alloc_page_vma(GFP_HIGHUSER_MOVABLE, vma, vmf->address);
>>> + page = alloc_page_vma(GFP_HIGHUSER_MOVABLE, vma, vmf->virtual_address);
>>> if (!page)
>>> return VM_FAULT_OOM;
>>> if (mem_cgroup_cache_charge(page, vma->vm_mm, GFP_KERNEL)) {
>>>
>>>
>>>
>>> --
>>> yamahata
>>>
>>>
Re: [Qemu-devel] [PATCH v4 0/2]: qemu-ga: Add the guest-suspend command
On 01/05/2012 06:59 AM, Daniel P. Berrange wrote:
On Thu, Jan 05, 2012 at 10:37:14AM -0200, Luiz Capitulino wrote:
On Thu, 5 Jan 2012 10:16:30 +
"Daniel P. Berrange" wrote:
On Wed, Jan 04, 2012 at 05:45:11PM -0200, Luiz Capitulino wrote:
This version drops modes 'sleep' and 'hybrid' because they don't work
properly due to issues in qemu. Only the 'hibernate' mode is supported
for now.
IMHO this is short-sighted. When the bugs QEMU in are fixed so that
these modes work, you have needlessly put users in the situation where
they have to now upgrade the guest agent everywhere to take advantage
of the bugfix.
That was my thinking until v4. But after discussing with Michael the issues
we have with S3 I concluded that it doesn't make sense to offer an API to
something that doesn't work, this will just generate bug reports. Also,
updating to get new features is normal and expected.
This is assuming that users will always upgrade their VMs& hosts in
lock step, which I rather doubt they will in practice. eg imagine a
deployment might have a mixture of hosts, running QEMU 1.1 (broken S3)
and QEMU 1.2 (working S3). If they build VM disk images they will likely
use the QEMU GA from 1.2 for all their builds, even if many of them
will only run on QEMU 1.1 hosts. So you'll end up having 'sleep' and
'hybrid' commands available in the guest agent, even though the host
QEMU doesn't work properly.
So you *will* ultimately need to make sure that QEMU GA from 1.2, has
sensible behaviour when run on a QEMU 1.1 host. If you don't address
this during 1.1, you may well find yourself in an un-winnable situation
for 1.2, where it is impossible to provide good behaviour on old hosts.
So IMHO we are better off in the long run, if we include all commands
right now, even though some don't work yet, and work to ensure we have
good error reporting behaviour for those that don't work.
As an example, if S3 is broken in current QEMU, then we should not be
advertizing S3 to the guest OS. This would allow 'pm-is-supported --suspend'
to return false, at which point the guest agent can send back a nice error
message 'Suspend is not supported on this host', instead of just having the
guest try to suspend& hang or worse.
This still requires we're lockstep with host QEMU (ideally that would be
the case via push-deployment of the agent, exactly because of issues
like this. Or at least, it'd make the upgrade process painless). And
outside of that, I really cannot think of any nice way to check, from
the agent, that a host has required functionality for {this,an} RPC. Not
unless we forced a bi-directional capabilities negotiation sequence, and
I don't like the idea of injecting this kind of data into a guest.
libvirt could maybe filter the modes based on QEMU version, but that's
not the only consumer of the agent.
Really I think this is a case study for why push-deployment of agents is
the way to go. QEMU could query qemu-ga directly and generate an 'agent
update available' event that users/frontends can use to prompt an update
to the latest version. Then all the upgrade inertia involved with saving
code/features for subsequent agent versions is mostly gone, and we can
"do the right thing" with regard to broken functionality :)
Unfortunately that option isn't available yet. But it just seems wrong
to introduce something we know is broken, to the extent that even those
involved with it's development aren't currently capable of testing it
fully. I mean, we know what the user expectations are, and it's not
that, unfortunately for us :( I'd be more open to it if the bug wasn't
so bad, but nuking your guest's working state every time you make the
mistake of hitting the pretty "sleep" button in virt-manager or whatever
is pretty bad.
Daniel
[Qemu-devel] [Bug 907994] Re: converting VDI to IMG
I close this bug report because it is a Windows feature, not a QEMU bug. ** Changed in: qemu Status: Incomplete => Invalid ** Changed in: qemu Assignee: (unassigned) => Stefan Weil (ubuntu-weilnetz) -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/907994 Title: converting VDI to IMG Status in QEMU: Invalid Bug description: I'm so close to moving away from VrtualBox to using Qemu. However I've run into some issues converting my existing virtual machine from VirtualBox to Qemu. I'm running Qemu on Fedora 16. I took my windows_xp.vdi and tried to convert it to qemu. The conversion goes well without any errors but then when I import the converted file to Qemu, it won't start. Here is the info on the file that I'm trying to convert: INFO = $ qemu-img info windows_xp.vdi image: windows_xp.vdi file format: vdi virtual size: 21G (22020096000 bytes) disk size: 9.4G cluster_size: 1048576 CONVERT COMMAND == qemu-img convert windows_xp.vdi windows_xp.img I created a new virtual machine and used the converted machine created (from the above step). When I try to start the newly created virtual machine, it keeps failing. There is a blue screen of death that goes away too soon. and I'm stuck with the windows start menu "safe mode, start normally " etc.. but no matter what I do I can't seem to start the vm. Any help much appreciated. Thanks To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/907994/+subscriptions
Re: [Qemu-devel] [PATCH v4 0/2]: qemu-ga: Add the guest-suspend command
On 01/05/2012 08:42 AM, Luiz Capitulino wrote: On Thu, 5 Jan 2012 12:59:27 + "Daniel P. Berrange" wrote: On Thu, Jan 05, 2012 at 10:37:14AM -0200, Luiz Capitulino wrote: On Thu, 5 Jan 2012 10:16:30 + "Daniel P. Berrange" wrote: On Wed, Jan 04, 2012 at 05:45:11PM -0200, Luiz Capitulino wrote: This version drops modes 'sleep' and 'hybrid' because they don't work properly due to issues in qemu. Only the 'hibernate' mode is supported for now. IMHO this is short-sighted. When the bugs QEMU in are fixed so that these modes work, you have needlessly put users in the situation where they have to now upgrade the guest agent everywhere to take advantage of the bugfix. That was my thinking until v4. But after discussing with Michael the issues we have with S3 I concluded that it doesn't make sense to offer an API to something that doesn't work, this will just generate bug reports. Also, updating to get new features is normal and expected. This is assuming that users will always upgrade their VMs& hosts in lock step, which I rather doubt they will in practice. eg imagine a deployment might have a mixture of hosts, running QEMU 1.1 (broken S3) and QEMU 1.2 (working S3). If they build VM disk images they will likely use the QEMU GA from 1.2 for all their builds, even if many of them will only run on QEMU 1.1 hosts. So you'll end up having 'sleep' and 'hybrid' commands available in the guest agent, even though the host QEMU doesn't work properly. So you *will* ultimately need to make sure that QEMU GA from 1.2, has sensible behaviour when run on a QEMU 1.1 host. If you don't address this during 1.1, you may well find yourself in an un-winnable situation for 1.2, where it is impossible to provide good behaviour on old hosts. So IMHO we are better off in the long run, if we include all commands right now, even though some don't work yet, and work to ensure we have good error reporting behaviour for those that don't work. Yes, I agree. As a side note: if we add error reporting it will only work on 1.1 and later. Ie, the problem you describe above will still happen with 1.0. But what you're suggesting seems to be the right thing to do. Do you agree Michael? Agree, but unless we add an RPC that QEMU uses to advertise capabilities, I'm really not sure it's possible to detect whether or not the host will support it. And if we can't detect that reliably, we're better off leaving it out for now, because sleeping guests is not obscure functionality, and accidentally nuking guests when a user sleeps them (presumably because they want to retain their working state) is much worse than telling a user to upgrade their agent, or not supported or whatever. As an example, if S3 is broken in current QEMU, then we should not be advertizing S3 to the guest OS. This would allow 'pm-is-supported --suspend' to return false, at which point the guest agent can send back a nice error message 'Suspend is not supported on this host', instead of just having the guest try to suspend& hang or worse.
Re: [Qemu-devel] [PATCH v3 2/2] ahci: add support for non-PCI based controllers
On 01/05/2012 08:35 AM, Mark Langsdorf wrote:
> On 01/05/2012 08:26 AM, Alexander Graf wrote:
>>
>> On 05.01.2012, at 15:16, Andreas Färber wrote:
>>
>>> Am 05.01.2012 14:52, schrieb Mark Langsdorf:
From: Rob Herring
Add support for ahci on sysbus.
Signed-off-by: Rob Herring
Signed-off-by: Mark Langsdorf
---
Changes from v1, v2
Corrected indentation of PlatAHCIState members
Made plat_ahci_info into a single structure, not a list
hw/ide/ahci.c | 31 +++
1 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c
index 135d0ee..f052e55 100644
--- a/hw/ide/ahci.c
+++ b/hw/ide/ahci.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include "monitor.h"
#include "dma.h"
@@ -1214,3 +1215,33 @@ void ahci_reset(void *opaque)
ahci_reset_port(s, i);
}
}
+
+typedef struct PlatAHCIState {
+SysBusDevice busdev;
+AHCIState ahci;
+} PlatAHCIState;
+
+static int plat_ahci_init(SysBusDevice *dev)
+{
+PlatAHCIState *s = FROM_SYSBUS(PlatAHCIState, dev);
+ahci_init(&s->ahci, &dev->qdev, 1);
+
+sysbus_init_mmio(dev, &s->ahci.mem);
+sysbus_init_irq(dev, &s->ahci.irq);
>>
>> It's still unclear to me how you connect an irq line on the command line.
>> How do you instantiate this device?
>
> I'm not sure how it's done on the command line. In the SoC model that
> this is intended for, I call sysbus_create_simple().
>
+qemu_register_reset(ahci_reset, &s->ahci);
+return 0;
+}
+
+static SysBusDeviceInfo plat_ahci_info = {
+.qdev.name= "plat-ahci",
>>>
>>> The commit message does not given an indication where "plat" comes from
>>> - is that an ARM device name?
>>
>> "plat" here means "platform device". I'm not sure I like the naming though.
>> Basically it's a sysbus version of AHCI, similar to how virtio-mmio is a
>> sysbus version of virtio.
>>
>> How about "sysbus-ahci"?
>
> Sure. I'll make that change.
>
>>> Does this patch actually make something work? If yes, please state so,
>>> including usage instructions. If not, then I would suggest to hold this
>>> one back and to send it together with any follow-on patches that wire it
>>> up on some machine.
>>
>> You can always just create the device manually with -device and hook it up
>> in the guest device tree or machine description manually.
>>
>> However the question still stands: Have you verified this code works?
>
> It's used in the Highbank SoC model, which hasn't been released yet. I'm
> waiting on some other patches to make it upstream, mostly Trustzone
> support now.
>
Which has been extensively tested for some time with the Linux AHCI
platform driver. The only issue we've seen are guest "DMA timeouts" when
the disk image file is on an NFS share, but that should not be caused by
this change.
Mark, there is not a qemu code dependency on Trustzone support, so we
don't need to wait for that to add highbank support.
Rob
> I can resubmit it with the Highbank SoC model when that goes out if
> you would prefer.
>
> --Mark Langsdorf
> Calxeda, Inc.
Re: [Qemu-devel] [PATCH v4 0/2]: qemu-ga: Add the guest-suspend command
On Thu, Jan 05, 2012 at 09:04:57AM -0600, Michael Roth wrote:
> On 01/05/2012 06:59 AM, Daniel P. Berrange wrote:
> >On Thu, Jan 05, 2012 at 10:37:14AM -0200, Luiz Capitulino wrote:
> >>On Thu, 5 Jan 2012 10:16:30 +
> >>"Daniel P. Berrange" wrote:
> >>
> >>>On Wed, Jan 04, 2012 at 05:45:11PM -0200, Luiz Capitulino wrote:
> This version drops modes 'sleep' and 'hybrid' because they don't work
> properly due to issues in qemu. Only the 'hibernate' mode is supported
> for now.
> >>>
> >>>IMHO this is short-sighted. When the bugs QEMU in are fixed so that
> >>>these modes work, you have needlessly put users in the situation where
> >>>they have to now upgrade the guest agent everywhere to take advantage
> >>>of the bugfix.
> >>
> >>That was my thinking until v4. But after discussing with Michael the issues
> >>we have with S3 I concluded that it doesn't make sense to offer an API to
> >>something that doesn't work, this will just generate bug reports. Also,
> >>updating to get new features is normal and expected.
> >
> >This is assuming that users will always upgrade their VMs& hosts in
> >lock step, which I rather doubt they will in practice. eg imagine a
> >deployment might have a mixture of hosts, running QEMU 1.1 (broken S3)
> >and QEMU 1.2 (working S3). If they build VM disk images they will likely
> >use the QEMU GA from 1.2 for all their builds, even if many of them
> >will only run on QEMU 1.1 hosts. So you'll end up having 'sleep' and
> >'hybrid' commands available in the guest agent, even though the host
> >QEMU doesn't work properly.
> >
> >So you *will* ultimately need to make sure that QEMU GA from 1.2, has
> >sensible behaviour when run on a QEMU 1.1 host. If you don't address
> >this during 1.1, you may well find yourself in an un-winnable situation
> >for 1.2, where it is impossible to provide good behaviour on old hosts.
> >
> >So IMHO we are better off in the long run, if we include all commands
> >right now, even though some don't work yet, and work to ensure we have
> >good error reporting behaviour for those that don't work.
> >
> >As an example, if S3 is broken in current QEMU, then we should not be
> >advertizing S3 to the guest OS. This would allow 'pm-is-supported --suspend'
> >to return false, at which point the guest agent can send back a nice error
> >message 'Suspend is not supported on this host', instead of just having the
> >guest try to suspend& hang or worse.
>
> This still requires we're lockstep with host QEMU (ideally that
> would be the case via push-deployment of the agent, exactly because
> of issues like this. Or at least, it'd make the upgrade process
> painless). And outside of that, I really cannot think of any nice
> way to check, from the agent, that a host has required functionality
> for {this,an} RPC. Not unless we forced a bi-directional
> capabilities negotiation sequence, and I don't like the idea of
> injecting this kind of data into a guest. libvirt could maybe filter
> the modes based on QEMU version, but that's not the only consumer of
> the agent.
Err, the scenario I just described does not require lockstep
upgrade. Newer QEMU GA agent should be able to run on historical
QEMU hosts just fine. I'm also not trying to suggest we need a
general bi-directional capabilities negotiation here either.
The key is that in this particular case, QEMU should only
expose S3 to the guest if it is actually capable of working.
Then, the pm-is-supported command will 'just work'. No
host<->guest agent negoiation is required.
Daniel
--
|: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Re: [Qemu-devel] [PATCH v3 2/2] ahci: add support for non-PCI based controllers
On 05.01.2012, at 16:11, Rob Herring wrote:
> On 01/05/2012 08:35 AM, Mark Langsdorf wrote:
>> On 01/05/2012 08:26 AM, Alexander Graf wrote:
>>>
>>> On 05.01.2012, at 15:16, Andreas Färber wrote:
>>>
Am 05.01.2012 14:52, schrieb Mark Langsdorf:
> From: Rob Herring
>
> Add support for ahci on sysbus.
>
> Signed-off-by: Rob Herring
> Signed-off-by: Mark Langsdorf
> ---
> Changes from v1, v2
> Corrected indentation of PlatAHCIState members
> Made plat_ahci_info into a single structure, not a list
>
> hw/ide/ahci.c | 31 +++
> 1 files changed, 31 insertions(+), 0 deletions(-)
>
> diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c
> index 135d0ee..f052e55 100644
> --- a/hw/ide/ahci.c
> +++ b/hw/ide/ahci.c
> @@ -25,6 +25,7 @@
> #include
> #include
> #include
> +#include
>
> #include "monitor.h"
> #include "dma.h"
> @@ -1214,3 +1215,33 @@ void ahci_reset(void *opaque)
>ahci_reset_port(s, i);
>}
> }
> +
> +typedef struct PlatAHCIState {
> +SysBusDevice busdev;
> +AHCIState ahci;
> +} PlatAHCIState;
> +
> +static int plat_ahci_init(SysBusDevice *dev)
> +{
> +PlatAHCIState *s = FROM_SYSBUS(PlatAHCIState, dev);
> +ahci_init(&s->ahci, &dev->qdev, 1);
> +
> +sysbus_init_mmio(dev, &s->ahci.mem);
> +sysbus_init_irq(dev, &s->ahci.irq);
>>>
>>> It's still unclear to me how you connect an irq line on the command line.
>>> How do you instantiate this device?
>>
>> I'm not sure how it's done on the command line. In the SoC model that
>> this is intended for, I call sysbus_create_simple().
>>
> +qemu_register_reset(ahci_reset, &s->ahci);
> +return 0;
> +}
> +
> +static SysBusDeviceInfo plat_ahci_info = {
> +.qdev.name= "plat-ahci",
The commit message does not given an indication where "plat" comes from
- is that an ARM device name?
>>>
>>> "plat" here means "platform device". I'm not sure I like the naming though.
>>> Basically it's a sysbus version of AHCI, similar to how virtio-mmio is a
>>> sysbus version of virtio.
>>>
>>> How about "sysbus-ahci"?
>>
>> Sure. I'll make that change.
>>
Does this patch actually make something work? If yes, please state so,
including usage instructions. If not, then I would suggest to hold this
one back and to send it together with any follow-on patches that wire it
up on some machine.
>>>
>>> You can always just create the device manually with -device and hook it up
>>> in the guest device tree or machine description manually.
>>>
>>> However the question still stands: Have you verified this code works?
>>
>> It's used in the Highbank SoC model, which hasn't been released yet. I'm
>> waiting on some other patches to make it upstream, mostly Trustzone
>> support now.
>>
> Which has been extensively tested for some time with the Linux AHCI
> platform driver. The only issue we've seen are guest "DMA timeouts" when
> the disk image file is on an NFS share, but that should not be caused by
> this change.
>
> Mark, there is not a qemu code dependency on Trustzone support, so we
> don't need to wait for that to add highbank support.
I agree, the SoC model should still work without trustzone. Just post the whole
thing including this patch, so we make sure we don't have dead code in the
tree. If the other patches you're waiting on look like they're basically
accepted but need a bit to actually work their way through to upstream, just
post the SoC patches with a comment saying that they are based on the others.
Alex
Re: [Qemu-devel] [PATCH 03/30] ppc: remove ppc440 bamboo board support
Le -10/01/-28163 20:59, Anthony Liguori a écrit : > This board never worked with TCG. It hasn't been updated since 0.13.0. I'm > fairly sure hardware doesn't exist anymore that you can run the KVM support > with. > > So let's remove it. It can always be restored later if there is interest > again. I'd like to have a ppc440 board around still... I once pondered adding the sam440, but don't have the time. Anyone looking into it ? It'd be quite wow to have the latest Amiga X-1000 too but it has a very custom chipset. François.
Re: [Qemu-devel] [PATCH v4 0/2]: qemu-ga: Add the guest-suspend command
On 01/05/2012 09:11 AM, Daniel P. Berrange wrote:
On Thu, Jan 05, 2012 at 09:04:57AM -0600, Michael Roth wrote:
On 01/05/2012 06:59 AM, Daniel P. Berrange wrote:
On Thu, Jan 05, 2012 at 10:37:14AM -0200, Luiz Capitulino wrote:
On Thu, 5 Jan 2012 10:16:30 +
"Daniel P. Berrange" wrote:
On Wed, Jan 04, 2012 at 05:45:11PM -0200, Luiz Capitulino wrote:
This version drops modes 'sleep' and 'hybrid' because they don't work
properly due to issues in qemu. Only the 'hibernate' mode is supported
for now.
IMHO this is short-sighted. When the bugs QEMU in are fixed so that
these modes work, you have needlessly put users in the situation where
they have to now upgrade the guest agent everywhere to take advantage
of the bugfix.
That was my thinking until v4. But after discussing with Michael the issues
we have with S3 I concluded that it doesn't make sense to offer an API to
something that doesn't work, this will just generate bug reports. Also,
updating to get new features is normal and expected.
This is assuming that users will always upgrade their VMs& hosts in
lock step, which I rather doubt they will in practice. eg imagine a
deployment might have a mixture of hosts, running QEMU 1.1 (broken S3)
and QEMU 1.2 (working S3). If they build VM disk images they will likely
use the QEMU GA from 1.2 for all their builds, even if many of them
will only run on QEMU 1.1 hosts. So you'll end up having 'sleep' and
'hybrid' commands available in the guest agent, even though the host
QEMU doesn't work properly.
So you *will* ultimately need to make sure that QEMU GA from 1.2, has
sensible behaviour when run on a QEMU 1.1 host. If you don't address
this during 1.1, you may well find yourself in an un-winnable situation
for 1.2, where it is impossible to provide good behaviour on old hosts.
So IMHO we are better off in the long run, if we include all commands
right now, even though some don't work yet, and work to ensure we have
good error reporting behaviour for those that don't work.
As an example, if S3 is broken in current QEMU, then we should not be
advertizing S3 to the guest OS. This would allow 'pm-is-supported --suspend'
to return false, at which point the guest agent can send back a nice error
message 'Suspend is not supported on this host', instead of just having the
guest try to suspend& hang or worse.
This still requires we're lockstep with host QEMU (ideally that
would be the case via push-deployment of the agent, exactly because
of issues like this. Or at least, it'd make the upgrade process
painless). And outside of that, I really cannot think of any nice
way to check, from the agent, that a host has required functionality
for {this,an} RPC. Not unless we forced a bi-directional
capabilities negotiation sequence, and I don't like the idea of
injecting this kind of data into a guest. libvirt could maybe filter
the modes based on QEMU version, but that's not the only consumer of
the agent.
Err, the scenario I just described does not require lockstep
upgrade. Newer QEMU GA agent should be able to run on historical
QEMU hosts just fine. I'm also not trying to suggest we need a
Bad terminology on my part, what I mean is if qemu-ga error reporting
requires a newer qemu, we still execute the sleep on buggy hosts unless
the host-level is adequate.
general bi-directional capabilities negotiation here either.
The key is that in this particular case, QEMU should only
expose S3 to the guest if it is actually capable of working.
Then, the pm-is-supported command will 'just work'. No
host<->guest agent negoiation is required.
Daniel
Re: [Qemu-devel] [PATCH V2 5/5] vga-cirrus: Workaround during restore when using Xen.
On 01/05/2012 04:34 PM, Stefano Stabellini wrote:
> On Thu, 5 Jan 2012, Avi Kivity wrote:
> > On 01/05/2012 03:17 PM, Stefano Stabellini wrote:
> > > > > The "solution" I am proposing is introducing an early_savevm set of
> > > > > save/restore functions so that at restore time we can get to know at
> > > > > what address the videoram is mapped into the guest address space.
> > > > > Once we
> > > > > know the address we can remap it into qemu's address space and/or
> > > > > move it
> > > > > to another guest physical address.
> > > >
> > > > Why can we not simply track it? For every MemoryRegion, have a field
> > > > called xen_address which tracks its location in the Xen address space
> > > > (as determined by the last call to xen_set_memory or qemu_ram_alloc).
> > > > xen_address would be maintained by callbacks called from the memory API
> > > > into xen-all.c.
> > >
> > > Nice and simple, I like it.
> > > However we would still need an early_savevm mechanism to save and restore
> > > the
> > > MemoryRegions, unless they already gets saved and restored somehow?
> >
> > MemoryRegions are instantiated by the devices, so they should be there
> > (creating a MemoryRegion == calling qemu_ram_alloc() in the old days)
>
> If the MemoryRegions are re-created by the devices, then we need another
> mechanism to find out where the videoram is.
> What I am saying is that the suggestion of having a xen_address field
> for every MemoryRegion would make the code cleaner but it would not
> solve the save/restore issue described in the previous email.
Okay, I think I understand now.
You're not really allocating memory on restore, you're attaching to
already allocated memory, and you need a handle to it, passed from the
save side.
One way is to add early-save/restore like you suggest. Another is to
make the attach late. Can we defer it until after restore is complete
and we know everything?
This involves:
- adding vmstate to xen-all.c so it can migrate the xen vram address
- making sure the memory core doesn't do mappings during restore (can be
done by wrapping restore with
memory_region_transaction_begin()/memory_region_transaction_commit();
beneficial to normal qemu migrations as well)
- updating the mapped address during restore
I think this is cleaner than introducing a new migration stage, but the
implementation may prove otherwise.
> >
> > xen_register_framebuffer() is slightly less hacky.
>
> I agree, however xen_register_framebuffer is called after
> memory_region_init_ram, so the allocation would have been made already.
xen_ram_alloc(MemoryRegion *mr)
{
if (in_restore && mr == framebuffer && !framebuffer_addr_known) {
return;
}
}
xen_framebuffer_address_post_load()
{
framebuffer_addr_known = true;
if (framebuffer) {
framebuffer->xen_address = framebuffer_addr;
}
}
(ugly way of avoiding a dependency, but should work)
--
error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH v3 2/2] ahci: add support for non-PCI based controllers
On 5 January 2012 15:11, Rob Herring wrote: > Mark, there is not a qemu code dependency on Trustzone support, so we > don't need to wait for that to add highbank support. That's good, because Trustzone support is not going to land imminently I suspect, and it would be better not to have it as a dependency. (I'll consider minimal workarounds for lack-of-trustzone if we have to to get things booting.) -- PMM
Re: [Qemu-devel] [PATCH v9] arm: add dummy v7 cp15 registers
On 5 January 2012 13:16, Mark Langsdorf wrote: > Add dummy register support for the cp15, CRn=c15 registers. > > config_base_register and power_control_register currently > default to 0, but may have improved support after the QOM > CPU patches are finished. > > Signed-off-by: Mark Langsdorf Reviewed-by: Peter Maydell and put into target-arm.next. (I've taken the liberty of tweaking the patch summary -- these are A9-specific, not v7). -- PMM
Re: [Qemu-devel] [PATCH 02/18] ppc_prep: convert to memory API
Am 05.01.2012 15:57, schrieb Avi Kivity: > On 01/05/2012 04:45 PM, Andreas Färber wrote: >> Am 17.10.2011 16:02, schrieb Avi Kivity: >>> Signed-off-by: Avi Kivity >> >> This one originally broke the prep machine: >> > > Instructions on how to reproduce, please. ppc-softmmu/qemu-system-ppc -M prep plus by now: diff --git a/target-ppc/cpu.h b/target-ppc/cpu.h index 2d67d1f..e3fe023 100644 --- a/target-ppc/cpu.h +++ b/target-ppc/cpu.h @@ -66,7 +66,7 @@ #define TARGET_PAGE_BITS 12 #endif /* defined(TARGET_PPCEMB) */ -#define TARGET_PHYS_ADDR_SPACE_BITS 36 +#define TARGET_PHYS_ADDR_SPACE_BITS 32 #define TARGET_VIRT_ADDR_SPACE_BITS 32 #endif /* defined (TARGET_PPC64) */ My current theory is that bios_addr and bios_size are insufficient for the MemoryRegion - binary ppc_rom.bin is 524.3 KB only and may be trying to relocate parts of itself to the exception vectors, so we may need to use a fixed size of 1 MB and location 0xfff0 for the MemoryRegion. Checking... Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH v9] arm: add dummy v7 cp15 registers
On 01/05/2012 09:33 AM, Peter Maydell wrote: > On 5 January 2012 13:16, Mark Langsdorf wrote: >> Add dummy register support for the cp15, CRn=c15 registers. >> >> config_base_register and power_control_register currently >> default to 0, but may have improved support after the QOM >> CPU patches are finished. >> >> Signed-off-by: Mark Langsdorf > > Reviewed-by: Peter Maydell > and put into target-arm.next. > (I've taken the liberty of tweaking the patch summary -- these > are A9-specific, not v7). Ack. --Mark Langsdorf Calxeda, Inc.
Re: [Qemu-devel] [libvirt] QMP: Supporting off tree APIs
On 01/05/2012 07:16 AM, Luiz Capitulino wrote: >> I know. We're stuck in a hard place here again because NotSupported >> has been in the Image Streaming API spec and hence implemented in >> libvirt for a while now. If we change this then an old client which >> only understands NotSupported will not know what to do with the >> Unsupported error. >> >> (Unsupported was not in QEMU when the Image Streaming API was defined.) > > Let me try to understand it: is libvirt relying on an off tree API and > we are now required to have stable guarantees to off tree APIs? No. Libvirt recognizes the off-tree spelling, but does not rely on it - after all, the goal of libvirt is to provide the high level action, using whatever underlying mechanism(s) necessary to get to that action, even if it means using several different attempts until one actually works. If a user has the older libvirt, which only expects the off-tree spelling, then that user's setup will break if they upgrade qemu but not libvirt. But that's not a severe problem - they could have only been relying on the situation if they were using an off-tree build in the first place, so they should be aware that upgrading qemu is a potentially risky scenario, and that they may have to deal with the pieces. Newer libvirt can be easily taught to recognize both the off-tree and stable spellings of the error (checking the stable first, of course, since that will be more likely as the off-tree qemu builds filter out over time). At which point, using either the off-tree qemu or the stable qemu should both work with the newer libvirt. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH v3 2/2] ahci: add support for non-PCI based controllers
On 01/05/2012 09:32 AM, Peter Maydell wrote: > On 5 January 2012 15:11, Rob Herring wrote: >> Mark, there is not a qemu code dependency on Trustzone support, so we >> don't need to wait for that to add highbank support. > > That's good, because Trustzone support is not going to land imminently > I suspect, and it would be better not to have it as a dependency. > (I'll consider minimal workarounds for lack-of-trustzone if we have to > to get things booting.) I'll work with Rob today to resolve this. My experience is that the Highbank model requires c1_scr, which Peter says is part of Trustzone. I may have missed something, though. --Mark Langsdorf Calxeda, Inc.
Re: [Qemu-devel] [PATCH v3 2/2] ahci: add support for non-PCI based controllers
On 01/05/2012 09:32 AM, Peter Maydell wrote: > On 5 January 2012 15:11, Rob Herring wrote: >> Mark, there is not a qemu code dependency on Trustzone support, so we >> don't need to wait for that to add highbank support. > > That's good, because Trustzone support is not going to land imminently > I suspect, and it would be better not to have it as a dependency. > (I'll consider minimal workarounds for lack-of-trustzone if we have to > to get things booting.) We don't need the full Trustzone secure and non-secure states to work. We just need writes to the various secure config registers to be ignored and not error out. Rob
Re: [Qemu-devel] [PATCH v6] block:add-cow file format
On Thu, Dec 29, 2011 at 05:36:59PM +0800, Dong Xu Wang wrote:
> From: Dong Xu Wang
>
> Introduce a new file format: add-cow. The usage can be found in add-cow.txt of
> this patch.
>
> CC: Kevin Wolf
> CC: Stefan Hajnoczi
> Signed-off-by: Dong Xu Wang
> ---
> After applying this patch, qemu might can not compile, need apply this patch
> first:
> http://lists.gnu.org/archive/html/qemu-devel/2011-12/msg02527.html
>
> Makefile.objs |1 +
> block.c|2 +-
> block.h|1 +
> block/add-cow.c| 429
>
> block_int.h|1 +
> docs/specs/add-cow.txt | 72
> 6 files changed, 505 insertions(+), 1 deletions(-)
> create mode 100644 block/add-cow.c
> create mode 100644 docs/specs/add-cow.txt
>
> +s->bitmap_size = ((bs->total_sectors + 7) >> 3);
> +s->bitmap = qemu_blockalign(bs, s->bitmap_size);
> +
> +ret = bdrv_pread(bs->file, sizeof(header), s->bitmap,
> +s->bitmap_size);
> +if (ret != s->bitmap_size) {
> +goto fail;
> +}
As noted previously, it is not acceptable to read the entire bitmap in
memory since it might be very large. A cache, which limits the in-memory
size of the bitmap, must be created. In the qcow2-cache.c file you can
find an example (thats for qcow2 metadata cache). You can divide the
bitmap in chunks of say, 4k, and have:
int is_bit_set(int64_t bitnum, BlockDriverState *bs)
{
int64_t bitmap_entry = bitnum >> bits_per_entry;
if (!is_in_bitmap_cache(bs, bitmap_entry))
read_from_disk(bs, bitmap_entry);
return lookup_bitmap_cache(bs, bitnum);
}
And then limit the cache to a few megabytes.
Also when setting a bit you must update cache and write
to disk.
> +
> +if (s->image_file[0] == '\0') {
> +ret = -ENOENT;
> +goto fail;
> +}
> +
> +ret = bdrv_file_open(&backing_bs, bs->backing_file, 0);
> +if (ret < 0) {
> +return ret;
> +}
> +bdrv_delete(backing_bs);
> +
> +s->image_hd = bdrv_new("");
> +
> +if (path_has_protocol(s->image_file)) {
> +pstrcpy(image_filename, sizeof(image_filename),
> +s->image_file);
> +} else {
> +path_combine(image_filename, sizeof(image_filename),
> + bs->filename, s->image_file);
> +}
> +
> +image_drv = bdrv_find_format("raw");
> +ret = bdrv_open(s->image_hd, image_filename, flags, image_drv);
> +if (ret < 0) {
> +bdrv_delete(s->image_hd);
> +s->image_hd = NULL;
> +goto fail;
> +}
Please make sure it is possible to create a snapshot with the
snapshot_blkdev command, of a raw image. It is necessary for live block
copy, as described here:
http://patchwork.ozlabs.org/patch/134257/
Also please update that document, later, with raw examples.
Thanks
Re: [Qemu-devel] [PATCH] PPC: Bump qemu-system-ppc to 64-bit physical address space
On 05.01.2012, at 12:41, Andreas Färber wrote: > Dear Mr. ppc, > > Am 18.10.2011 01:52, schrieb Alexander Graf: >> Some 32-bit PPC CPUs can use up to 36 bit of physicall address space. >> Treat them accordingly in the qemu-system-ppc binary type. > > This change broke the prep machine. :( > > With -nographic I see: > > ERROR: BUG caught... > BIOS execution exception > nip=0x0580 msr=0x2000 dar=0x dsisr=0x > Stopping execution > >> Signed-off-by: Alexander Graf >> --- >> configure|2 +- >> target-ppc/cpu.h |2 +- >> 2 files changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/configure b/configure >> index 9b4fe34..3bdb556 100755 >> --- a/configure >> +++ b/configure >> @@ -3276,7 +3276,7 @@ case "$target_arch2" in >> ;; >> ppc) >> gdb_xml_files="power-core.xml power-fpu.xml power-altivec.xml >> power-spe.xml" >> -target_phys_bits=32 >> +target_phys_bits=64 >> target_nptl="yes" >> target_libs_softmmu="$fdt_libs" >> ;; > >> diff --git a/target-ppc/cpu.h b/target-ppc/cpu.h >> index 8e5c85c..f36f375 100644 >> --- a/target-ppc/cpu.h >> +++ b/target-ppc/cpu.h >> @@ -66,7 +66,7 @@ >> #define TARGET_PAGE_BITS 12 >> #endif /* defined(TARGET_PPCEMB) */ >> >> -#define TARGET_PHYS_ADDR_SPACE_BITS 32 >> +#define TARGET_PHYS_ADDR_SPACE_BITS 36 > > If I revert this part, previous behavior is restored. > > So it's not about libhw64 or target_phys_addr_t. > > Any idea? Is 6xx TLB maybe unable to cope with the larger address space? > Or is this an OHW limitation? That is very confusing tbh. Does qemu-system-ppc64 work with -M prep and -cpu ? The constant is only used for QEMU's internal TLB. Alex
Re: [Qemu-devel] [PATCH V2 5/5] vga-cirrus: Workaround during restore when using Xen.
On Thu, 5 Jan 2012, Avi Kivity wrote:
> > If the MemoryRegions are re-created by the devices, then we need another
> > mechanism to find out where the videoram is.
> > What I am saying is that the suggestion of having a xen_address field
> > for every MemoryRegion would make the code cleaner but it would not
> > solve the save/restore issue described in the previous email.
>
> Okay, I think I understand now.
>
> You're not really allocating memory on restore, you're attaching to
> already allocated memory, and you need a handle to it, passed from the
> save side.
Right
> One way is to add early-save/restore like you suggest. Another is to
> make the attach late. Can we defer it until after restore is complete
> and we know everything?
If it could be done, it would probably be a better solution, but I am
not so sure about the actual feasibility.
> This involves:
> - adding vmstate to xen-all.c so it can migrate the xen vram address
Easy so far.
> - making sure the memory core doesn't do mappings during restore (can be
> done by wrapping restore with
> memory_region_transaction_begin()/memory_region_transaction_commit();
> beneficial to normal qemu migrations as well)
Besides restore we would also need to wrap machine->init() with
memory_region_transaction_begin()/memory_region_transaction_commit(),
so that all the mappings are only done at the end of restore, when we do
know the videoram address.
This seems unfeasable to me: what about all the addresses set in the
meantime using memory_region_get_ram_ptr()?
For example s->vram_ptr set by vga_common_init during machine->init()?
If the actual memory is only allocated at the end of restore, vram_ptr
would be bogus at least until then and we would still need a way to
update it afterwards.
BTW what you are suggesting is not so different from what was done by
Anthony in the last patch series he sent. See the following (ugly) patch
to cirrus-vga.c to avoid accessing s->vga.vram_ptr before restore is
completed and then update the pointer:
http://marc.info/?l=qemu-devel&m=132346828427314&w=2
> - updating the mapped address during restore
>
> I think this is cleaner than introducing a new migration stage, but the
> implementation may prove otherwise.
see patch above, a good summary of the difficulties of this approach
> > > xen_register_framebuffer() is slightly less hacky.
> >
> > I agree, however xen_register_framebuffer is called after
> > memory_region_init_ram, so the allocation would have been made already.
>
> xen_ram_alloc(MemoryRegion *mr)
> {
> if (in_restore && mr == framebuffer && !framebuffer_addr_known) {
> return;
> }
> }
>
> xen_framebuffer_address_post_load()
> {
> framebuffer_addr_known = true;
> if (framebuffer) {
> framebuffer->xen_address = framebuffer_addr;
> }
> }
>
> (ugly way of avoiding a dependency, but should work)
The issue is that xen_ram_alloc is called by memory_region_init_ram
before xen_register_framebuffer is called (see the order of calls in
vga_common_init).
So when xen_ram_alloc is called framebuffer is still NULL: mr !=
framebuffer.
Re: [Qemu-devel] [libvirt] QMP: Supporting off tree APIs
On 01/05/2012 09:35 AM, Eric Blake wrote: On 01/05/2012 07:16 AM, Luiz Capitulino wrote: I know. We're stuck in a hard place here again because NotSupported has been in the Image Streaming API spec and hence implemented in libvirt for a while now. If we change this then an old client which only understands NotSupported will not know what to do with the Unsupported error. (Unsupported was not in QEMU when the Image Streaming API was defined.) Let me try to understand it: is libvirt relying on an off tree API and we are now required to have stable guarantees to off tree APIs? No. Libvirt recognizes the off-tree spelling, but does not rely on it - after all, the goal of libvirt is to provide the high level action, using whatever underlying mechanism(s) necessary to get to that action, even if it means using several different attempts until one actually works. If a user has the older libvirt, which only expects the off-tree spelling, then that user's setup will break if they upgrade qemu but not libvirt. But that's not a severe problem - they could have only been relying on the situation if they were using an off-tree build in the first place, so they should be aware that upgrading qemu is a potentially risky scenario, and that they may have to deal with the pieces. Right, this is the difference between ABI compatibility and strict backwards compatibility. To achieve ABI compatibility, we need to not overload BLOCK_JOB_COMPLETED to mean something other than libvirt what expects it to mean. We MUST provide ABI compatibility and SHOULD provide backwards compatibility whenever possible. In this case, I'd suggest that in the very least, we should add BLOCK_JOB_COMPLETED to qapi-schema.json with gen=False set. That way it's codified in the schema to ensure we maintain ABI compatibility. That said, I'm inclined to say that we should just use the BLOCK_JOB_COMPLETED name because I don't think we gain a lot by using QMP_JOB_COMPLETED (not that we shouldn't introduce it, but using it here isn't going to make or break anything). With respect to libvirt relying on interfaces before they exist in QEMU, we need to be a bit flexible here. We want to get better at co-development to help make libvirt support QEMU features as the bleeding edge. Forcing libvirt to wait until a feature is fully baked in QEMU will ensure there's always a feature gap in libvirt which is in none of our best interests. Now that we have gen=False support in qapi-schema.json, we can agree to an API and add it to QEMU before we fully implement it. This gives libvirt something to work off of that they can rely upon. Regards, Anthony Liguori Newer libvirt can be easily taught to recognize both the off-tree and stable spellings of the error (checking the stable first, of course, since that will be more likely as the off-tree qemu builds filter out over time). At which point, using either the off-tree qemu or the stable qemu should both work with the newer libvirt.
[Qemu-devel] [PATCH] usb-host: properly release port on unplug & exit
Factor out port release into a separate function. Call release function
in exit notifier too. Add explicit call the USBDEVFS_RELEASE_PORT
ioctl, just closing the hub file handle seems not to be enougth. Make
sure we release the port before resetting the device, otherwise host
drivers will not re-attach.
Signed-off-by: Gerd Hoffmann
---
usb-linux.c | 28
1 files changed, 20 insertions(+), 8 deletions(-)
diff --git a/usb-linux.c b/usb-linux.c
index db41104..c68e194 100644
--- a/usb-linux.c
+++ b/usb-linux.c
@@ -102,6 +102,7 @@ typedef struct USBHostDevice {
USBDevice dev;
int fd;
int hub_fd;
+int hub_port;
uint8_t descr[8192];
int descr_len;
@@ -445,7 +446,7 @@ static int usb_host_claim_port(USBHostDevice *s)
{
#ifdef USBDEVFS_CLAIM_PORT
char *h, hub_name[64], line[1024];
-int hub_addr, portnr, ret;
+int hub_addr, ret;
snprintf(hub_name, sizeof(hub_name), "%d-%s",
s->match.bus_num, s->match.port);
@@ -453,13 +454,13 @@ static int usb_host_claim_port(USBHostDevice *s)
/* try strip off last ".$portnr" to get hub */
h = strrchr(hub_name, '.');
if (h != NULL) {
-portnr = atoi(h+1);
+s->hub_port = atoi(h+1);
*h = '\0';
} else {
/* no dot in there -> it is the root hub */
snprintf(hub_name, sizeof(hub_name), "usb%d",
s->match.bus_num);
-portnr = atoi(s->match.port);
+s->hub_port = atoi(s->match.port);
}
if (!usb_host_read_file(line, sizeof(line), "devnum",
@@ -475,20 +476,32 @@ static int usb_host_claim_port(USBHostDevice *s)
return -1;
}
-ret = ioctl(s->hub_fd, USBDEVFS_CLAIM_PORT, &portnr);
+ret = ioctl(s->hub_fd, USBDEVFS_CLAIM_PORT, &s->hub_port);
if (ret < 0) {
close(s->hub_fd);
s->hub_fd = -1;
return -1;
}
-trace_usb_host_claim_port(s->match.bus_num, hub_addr, portnr);
+trace_usb_host_claim_port(s->match.bus_num, hub_addr, s->hub_port);
return 0;
#else
return -1;
#endif
}
+static void usb_host_release_port(USBHostDevice *s)
+{
+if (s->hub_fd == -1) {
+return;
+}
+#ifdef USBDEVFS_RELEASE_PORT
+ioctl(s->hub_fd, USBDEVFS_RELEASE_PORT, &s->hub_port);
+#endif
+close(s->hub_fd);
+s->hub_fd = -1;
+}
+
static int usb_host_disconnect_ifaces(USBHostDevice *dev, int nb_interfaces)
{
/* earlier Linux 2.4 do not support that */
@@ -637,10 +650,8 @@ static void usb_host_handle_destroy(USBDevice *dev)
{
USBHostDevice *s = (USBHostDevice *)dev;
+usb_host_release_port(s);
usb_host_close(s);
-if (s->hub_fd != -1) {
-close(s->hub_fd);
-}
QTAILQ_REMOVE(&hostdevs, s, next);
qemu_remove_exit_notifier(&s->exit);
}
@@ -1376,6 +1387,7 @@ static void usb_host_exit_notifier(struct Notifier *n,
void *data)
{
USBHostDevice *s = container_of(n, USBHostDevice, exit);
+usb_host_release_port(s);
if (s->fd != -1) {
usb_host_do_reset(s);;
}
--
1.7.1
[Qemu-devel] [PATCH] usb-storage: cancel I/O on reset
When resetting the usb-storage device we'll have to carefully cancel
and clear any requests which might be in flight, otherwise we'll confuse
the state machine.
Signed-off-by: Gerd Hoffmann
---
hw/usb-msd.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/hw/usb-msd.c b/hw/usb-msd.c
index 4c06950..3147131 100644
--- a/hw/usb-msd.c
+++ b/hw/usb-msd.c
@@ -278,6 +278,18 @@ static void usb_msd_handle_reset(USBDevice *dev)
MSDState *s = (MSDState *)dev;
DPRINTF("Reset\n");
+if (s->req) {
+scsi_req_cancel(s->req);
+}
+assert(s->req == NULL);
+
+if (s->packet) {
+USBPacket *p = s->packet;
+s->packet = NULL;
+p->result = USB_RET_STALL;
+usb_packet_complete(dev, p);
+}
+
s->mode = USB_MSDM_CBW;
}
--
1.7.1
Re: [Qemu-devel] [PATCH] PPC: Bump qemu-system-ppc to 64-bit physical address space
Am 05.01.2012 16:52, schrieb Alexander Graf: > > On 05.01.2012, at 12:41, Andreas Färber wrote: > >> Am 18.10.2011 01:52, schrieb Alexander Graf: >>> Some 32-bit PPC CPUs can use up to 36 bit of physicall address space. >>> Treat them accordingly in the qemu-system-ppc binary type. >> >> This change broke the prep machine. :( >> >> With -nographic I see: >> >> ERROR: BUG caught... >> BIOS execution exception >> nip=0x0580 msr=0x2000 dar=0x dsisr=0x >> Stopping execution >> >>> Signed-off-by: Alexander Graf >>> --- >>> configure|2 +- >>> target-ppc/cpu.h |2 +- >>> 2 files changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/configure b/configure >>> index 9b4fe34..3bdb556 100755 >>> --- a/configure >>> +++ b/configure >>> @@ -3276,7 +3276,7 @@ case "$target_arch2" in >>> ;; >>> ppc) >>> gdb_xml_files="power-core.xml power-fpu.xml power-altivec.xml >>> power-spe.xml" >>> -target_phys_bits=32 >>> +target_phys_bits=64 >>> target_nptl="yes" >>> target_libs_softmmu="$fdt_libs" >>> ;; >> >>> diff --git a/target-ppc/cpu.h b/target-ppc/cpu.h >>> index 8e5c85c..f36f375 100644 >>> --- a/target-ppc/cpu.h >>> +++ b/target-ppc/cpu.h >>> @@ -66,7 +66,7 @@ >>> #define TARGET_PAGE_BITS 12 >>> #endif /* defined(TARGET_PPCEMB) */ >>> >>> -#define TARGET_PHYS_ADDR_SPACE_BITS 32 >>> +#define TARGET_PHYS_ADDR_SPACE_BITS 36 >> >> If I revert this part, previous behavior is restored. >> >> So it's not about libhw64 or target_phys_addr_t. >> >> Any idea? Is 6xx TLB maybe unable to cope with the larger address space? >> Or is this an OHW limitation? > > That is very confusing tbh. It is... Having fixed Avi's Memory API conversion, despite reverting the phys addr space bits as above I get the same breakage again. Bisecting had clearly pointed out this change. I'll try if bisecting with the Memory API patch on top gives any new conclusions. Andreas
[Qemu-devel] [Bug 883133] Re: qemu on ARM hosts asserts due to code buffer/libc heap conflict
NB: this would typically only happen when the ARM host had address space randomization including brk randomization enabled (ie /proc/sys/kernel/randomize_va_space is 2). -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/883133 Title: qemu on ARM hosts asserts due to code buffer/libc heap conflict Status in QEMU: Fix Committed Status in Linaro QEMU: Fix Committed Bug description: On ARM hosts qemu (about half the time) asserts on startup: qemu-system-i386: malloc.c:3096: sYSMALLOc: Assertion `(old_top == (((mbinptr) (((char *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, fd && old_size == 0) || ((unsigned long) (old_size) >= (unsigned long)__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 * (sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t))) - 1))) && ((old_top)->size & 0x1) && ((unsigned long)old_end & pagemask) == 0)' failed. This turns out to be because code_gen_alloc() is using mmap(MAP_FIXED) to map the code buffer at address 0x0100UL, which is in the area glibc happens to be using for its heap. This tends to make the next malloc() abort, although occasionally the stars align and we pass that and fail weirdly later on. I suspect we need to drop the MAP_FIXED requirement and fix the TCG code to cope with emitting code for longer-range branches for calls to host fns etc (calls/branches within the generated code should be ok to keep using the short-range branch insn I think). There is already no guarantee that the generated code and the host C code are within short branch range of each other... To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/883133/+subscriptions
Re: [Qemu-devel] [PATCH V2 5/5] vga-cirrus: Workaround during restore when using Xen.
On 01/05/2012 05:53 PM, Stefano Stabellini wrote:
>
> > This involves:
> > - adding vmstate to xen-all.c so it can migrate the xen vram address
>
> Easy so far.
>
>
> > - making sure the memory core doesn't do mappings during restore (can be
> > done by wrapping restore with
> > memory_region_transaction_begin()/memory_region_transaction_commit();
> > beneficial to normal qemu migrations as well)
>
> Besides restore we would also need to wrap machine->init() with
> memory_region_transaction_begin()/memory_region_transaction_commit(),
> so that all the mappings are only done at the end of restore, when we do
> know the videoram address.
>
> This seems unfeasable to me: what about all the addresses set in the
> meantime using memory_region_get_ram_ptr()?
> For example s->vram_ptr set by vga_common_init during machine->init()?
> If the actual memory is only allocated at the end of restore, vram_ptr
> would be bogus at least until then and we would still need a way to
> update it afterwards.
One way is to only call it on demand when we actually need to draw or
read the framebuffer. Currently this will be slow since we'll search
the RAMBlock list, but soon it will be dereference of MemoryRegion.
> BTW what you are suggesting is not so different from what was done by
> Anthony in the last patch series he sent. See the following (ugly) patch
> to cirrus-vga.c to avoid accessing s->vga.vram_ptr before restore is
> completed and then update the pointer:
>
> http://marc.info/?l=qemu-devel&m=132346828427314&w=2
I see.
Maybe we can put the xen_address in the cirrus vmstate? That way there
is no ordering issue at all. Of course we have to make sure it isn't
saved/restored for non-xen, but that's doable with a predicate attached
to the field.
>
> > - updating the mapped address during restore
> >
> > I think this is cleaner than introducing a new migration stage, but the
> > implementation may prove otherwise.
>
> see patch above, a good summary of the difficulties of this approach
>
>
> > > > xen_register_framebuffer() is slightly less hacky.
> > >
> > > I agree, however xen_register_framebuffer is called after
> > > memory_region_init_ram, so the allocation would have been made already.
> >
> > xen_ram_alloc(MemoryRegion *mr)
> > {
> > if (in_restore && mr == framebuffer && !framebuffer_addr_known) {
> > return;
> > }
> > }
> >
> > xen_framebuffer_address_post_load()
> > {
> > framebuffer_addr_known = true;
> > if (framebuffer) {
> > framebuffer->xen_address = framebuffer_addr;
> > }
> > }
> >
> > (ugly way of avoiding a dependency, but should work)
>
> The issue is that xen_ram_alloc is called by memory_region_init_ram
> before xen_register_framebuffer is called (see the order of calls in
> vga_common_init).
> So when xen_ram_alloc is called framebuffer is still NULL: mr !=
> framebuffer.
Yup. We could invert the order. It's really ugly though to pass the
address of an uninitialized structure.
--
error compiling committee.c: too many arguments to function
Re: [Qemu-devel] Performance of USB2.0
Hello. Am 01.11.2011 10:37, schrieb Gerd Hoffmann: I think the main issue here is that we don't do buffering / pipelining for bulk transfers at the moment. We grab a single transfer request from the guest, pass it to the kernel, when it is done pass it back to the guest, then look look for the next one. Instead we could queue up all transfer requests from the guest to the kernel, which would give a noticable better throughput. The qemu usb subsystem can't handle that (yet). Fixing that is one the TODO list though. Any news about this topic? Regards Til
