Re: [Qemu-devel] [PATCH] virtio-pci: Clear IRQ at reset
On Thu, 03/12 08:22, Michael S. Tsirkin wrote:
On Thu, Mar 12, 2015 at 02:40:55PM +0800, Fam Zheng wrote:
Currently we could leave PCI IRQ asserted even after reset, it is safer
to clear it.
In the case that a buggy driver has disabled MSI-X unintentially, we may
have already injected IRQ in previous virtio_pci_notify, which will not
be cleared by guest because it doesn't expect it (i.e. no irq handler).
However the driver may eventually notice the unresponsiveness and reset
the device, at that point, clearing the irq is meaningful.
Signed-off-by: Fam Zheng f...@redhat.com
I don't get it. interrupts are de-asserted
in pci core:
static void pci_do_device_reset(PCIDevice *dev)
{
int r;
pci_device_deassert_intx(dev);
...
}
why isn't this sufficient?
Becuase it's not called by virtio_pci_reset.
Fam
Re: [Qemu-devel] E5-2620v2 - emulation stop error
On 10/03/2015 19:16, Dr. David Alan Gilbert wrote: KVM internal error. Suberror: 1 emulation failure EAX= EBX= ECX= EDX=000fd2bc ESI= EDI= EBP= ESP= EIP=000fd2c5 EFL=00010007 [-PC] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0010 00c09300 DPL=0 DS [-WA] CS =0008 00c09b00 DPL=0 CS32 [-RA] SS =0010 00c09300 DPL=0 DS [-WA] DS =0010 00c09300 DPL=0 DS [-WA] FS =0010 00c09300 DPL=0 DS [-WA] GS =0010 00c09300 DPL=0 DS [-WA] LDT= 8200 DPL=0 LDT TR = 8b00 DPL=0 TSS32-busy GDT= 000f6a80 0037 IDT= 000f6abe CR0=6011 CR2= CR3= CR4= DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 EFER= Code=66 ba bc d2 0f 00 e9 a2 fe f3 90 f0 0f ba 2d 04 ff fb bf 00 72 f3 8b 25 00 ff fb bf e8 44 66 ff ff c7 05 04 ff fb bf 00 00 00 00 f4 eb fd fa fc 66 b8 KVM internal error. Suberror: 1 emulation failure This is exactly the same as mine. I'm using upstream QEMU right now, but I can try to reproduce using RHEL7's too. Paolo
[Qemu-devel] [PATCH v2] hmp: add info iothreads command
Make info iothreads available on the HMP monitor.
The results are as follows:
id1: thread_id1
id2: thread_id2
Signed-off-by: Ting Wang kathy.wangt...@huawei.com
---
v2: add braces for if
---
hmp-commands.hx | 2 ++
hmp.c | 22 ++
hmp.h | 1 +
monitor.c | 7 +++
4 files changed, 32 insertions(+)
diff --git a/hmp-commands.hx b/hmp-commands.hx
index d5022d8..67d76ed 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -1746,6 +1746,8 @@ show roms
show the TPM device
@item info memory-devices
show the memory devices
+@item info iothreads
+show iothreads
@end table
ETEXI
diff --git a/hmp.c b/hmp.c
index 71c28bc..e87cb14 100644
--- a/hmp.c
+++ b/hmp.c
@@ -821,6 +821,28 @@ void hmp_info_tpm(Monitor *mon, const QDict *qdict)
qapi_free_TPMInfoList(info_list);
}
+void hmp_info_iothreads(Monitor *mon, const QDict *qdict)
+{
+IOThreadInfoList *head = NULL, *elem = NULL;
+
+head = qmp_query_iothreads(NULL);
+if (!head) {
+monitor_printf(mon, No iothread has been added\n);
+return;
+}
+
+elem = head;
+while (elem) {
+if (elem-value) {
+monitor_printf(mon, %s: thread_id=%ld\n, elem-value-id,
+elem-value-thread_id);
+}
+elem = elem-next;
+}
+
+qapi_free_IOThreadInfoList(head);
+}
+
void hmp_quit(Monitor *mon, const QDict *qdict)
{
monitor_suspend(mon);
diff --git a/hmp.h b/hmp.h
index 81177b2..d99090e 100644
--- a/hmp.h
+++ b/hmp.h
@@ -38,6 +38,7 @@ void hmp_info_balloon(Monitor *mon, const QDict *qdict);
void hmp_info_pci(Monitor *mon, const QDict *qdict);
void hmp_info_block_jobs(Monitor *mon, const QDict *qdict);
void hmp_info_tpm(Monitor *mon, const QDict *qdict);
+void hmp_info_iothreads(Monitor *mon, const QDict *qdict);
void hmp_quit(Monitor *mon, const QDict *qdict);
void hmp_stop(Monitor *mon, const QDict *qdict);
void hmp_system_reset(Monitor *mon, const QDict *qdict);
diff --git a/monitor.c b/monitor.c
index c86a89e..076a306 100644
--- a/monitor.c
+++ b/monitor.c
@@ -2924,6 +2924,13 @@ static mon_cmd_t info_cmds[] = {
.mhandler.cmd = hmp_info_memory_devices,
},
{
+.name = iothreads,
+.args_type = ,
+.params = ,
+.help = show iothreads,
+.mhandler.cmd = hmp_info_iothreads,
+},
+{
.name = NULL,
},
};
--
1.8.5
[Qemu-devel] [PULL v2 3/5] configure: opengl overhaul
Rename config option from glx to opengl, glx will not be the only
option for opengl in near future. Also switch over to pkg-config for
opengl support detection.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
Reviewed-by: Max Reitz mre...@redhat.com
---
configure| 39 +--
default-configs/lm32-softmmu.mak | 2 +-
hw/display/Makefile.objs | 2 +-
hw/lm32/milkymist-hw.h | 4 ++--
include/sysemu/sysemu.h | 1 +
vl.c | 1 +
6 files changed, 23 insertions(+), 26 deletions(-)
diff --git a/configure b/configure
index 7ba4bcb..ecd7893 100755
--- a/configure
+++ b/configure
@@ -309,7 +309,7 @@ rbd=
smartcard_nss=
libusb=
usb_redir=
-glx=
+opengl=
zlib=yes
lzo=
snappy=
@@ -1027,9 +1027,9 @@ for opt do
;;
--enable-vhost-scsi) vhost_scsi=yes
;;
- --disable-glx) glx=no
+ --disable-opengl) opengl=no
;;
- --enable-glx) glx=yes
+ --enable-opengl) opengl=yes
;;
--disable-rbd) rbd=no
;;
@@ -3107,23 +3107,18 @@ fi
libs_softmmu=$libs_softmmu $fdt_libs
##
-# GLX probe, used by milkymist-tmu2
-if test $glx != no ; then
- glx_libs=-lGL -lX11
- cat $TMPC EOF
-#include X11/Xlib.h
-#include GL/gl.h
-#include GL/glx.h
-int main(void) { glBegin(0); glXQueryVersion(0,0,0); return 0; }
-EOF
- if compile_prog -lGL -lX11 ; then
-glx=yes
+# opengl probe (for sdl2, milkymist-tmu2)
+if test $opengl != no ; then
+ opengl_pkgs=gl
+ if $pkg_config $opengl_pkgs; then
+opengl_libs=$($pkg_config --libs $opengl_pkgs) -lX11
+opengl=yes
else
-if test $glx = yes ; then
- feature_not_found glx Install GL devel (e.g. MESA)
+if test $opengl = yes ; then
+ feature_not_found opengl Install GL devel (e.g. MESA)
fi
-glx_libs=
-glx=no
+opengl_libs=
+opengl=no
fi
fi
@@ -4390,7 +4385,7 @@ echo xfsctl support$xfs
echo nss used $smartcard_nss
echo libusb$libusb
echo usb net redir $usb_redir
-echo GLX support $glx
+echo OpenGL support$opengl
echo libiscsi support $libiscsi
echo libnfs support$libnfs
echo build guest agent $guest_agent
@@ -4756,9 +4751,9 @@ if test $usb_redir = yes ; then
echo CONFIG_USB_REDIR=y $config_host_mak
fi
-if test $glx = yes ; then
- echo CONFIG_GLX=y $config_host_mak
- echo GLX_LIBS=$glx_libs $config_host_mak
+if test $opengl = yes ; then
+ echo CONFIG_OPENGL=y $config_host_mak
+ echo OPENGL_LIBS=$opengl_libs $config_host_mak
fi
if test $lzo = yes ; then
diff --git a/default-configs/lm32-softmmu.mak b/default-configs/lm32-softmmu.mak
index 7df58c8..4889348 100644
--- a/default-configs/lm32-softmmu.mak
+++ b/default-configs/lm32-softmmu.mak
@@ -2,7 +2,7 @@
CONFIG_LM32=y
CONFIG_MILKYMIST=y
-CONFIG_MILKYMIST_TMU2=$(CONFIG_GLX)
+CONFIG_MILKYMIST_TMU2=$(CONFIG_OPENGL)
CONFIG_FRAMEBUFFER=y
CONFIG_PTIMER=y
CONFIG_PFLASH_CFI01=y
diff --git a/hw/display/Makefile.objs b/hw/display/Makefile.objs
index 7ed76a9..e18ea57 100644
--- a/hw/display/Makefile.objs
+++ b/hw/display/Makefile.objs
@@ -20,7 +20,7 @@ common-obj-$(CONFIG_ZAURUS) += tc6393xb.o
ifeq ($(CONFIG_MILKYMIST_TMU2),y)
common-obj-y += milkymist-tmu2.o
-libs_softmmu += $(GLX_LIBS)
+libs_softmmu += $(OPENGL_LIBS)
endif
obj-$(CONFIG_OMAP) += omap_dss.o
diff --git a/hw/lm32/milkymist-hw.h b/hw/lm32/milkymist-hw.h
index 5317ce6..8d20cac 100644
--- a/hw/lm32/milkymist-hw.h
+++ b/hw/lm32/milkymist-hw.h
@@ -86,7 +86,7 @@ static inline DeviceState *milkymist_pfpu_create(hwaddr base,
return dev;
}
-#ifdef CONFIG_GLX
+#ifdef CONFIG_OPENGL
#include X11/Xlib.h
#include GL/glx.h
static const int glx_fbconfig_attr[] = {
@@ -100,7 +100,7 @@ static const int glx_fbconfig_attr[] = {
static inline DeviceState *milkymist_tmu2_create(hwaddr base,
qemu_irq irq)
{
-#ifdef CONFIG_GLX
+#ifdef CONFIG_OPENGL
DeviceState *dev;
Display *d;
GLXFBConfig *configs;
diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index 6e85097..8a52934 100644
--- a/include/sysemu/sysemu.h
+++ b/include/sysemu/sysemu.h
@@ -114,6 +114,7 @@ extern int graphic_width;
extern int graphic_height;
extern int graphic_depth;
extern DisplayType display_type;
+extern int display_opengl;
extern const char *keyboard_layout;
extern int win2k_install_hack;
extern int alt_grab;
diff --git a/vl.c b/vl.c
index eba5d4c..694deb4 100644
--- a/vl.c
+++ b/vl.c
@@ -130,6 +130,7 @@ static int data_dir_idx;
const char *bios_name = NULL;
enum vga_retrace_method vga_retrace_method = VGA_RETRACE_DUMB;
DisplayType display_type = DT_DEFAULT;
+int display_opengl;
static int display_remote;
const char* keyboard_layout = NULL;
ram_addr_t ram_size;
--
1.8.3.1
Re: [Qemu-devel] KVM emulation failure with recent kernel and QEMU Seabios
On Do, 2015-03-12 at 09:09 +0100, Jan Kiszka wrote: Hi, apparently since the latest QEMU updates I'm getting this once in a while: http://www.seabios.org/pipermail/seabios/2015-March/008897.html cheers, Gerd
[Qemu-devel] [vhost-net kernel module]: file.fd = -1 does nothing ?
Why do vhost init/start functions put out with the work of using a vhost_call(VHOST_NET_SET_BACKEND) with file.fd = -1 in qemu vhost-net sources? From what I see in vhost-net kernel module it just returns NULL from get_socket(), and that's it. It doesn't set anything.
Re: [Qemu-devel] KVM emulation failure with recent kernel and QEMU Seabios
On Do, 2015-03-12 at 09:14 +0100, Jan Kiszka wrote: Am 2015-03-12 um 09:11 schrieb Gerd Hoffmann: On Do, 2015-03-12 at 09:09 +0100, Jan Kiszka wrote: Hi, apparently since the latest QEMU updates I'm getting this once in a while: http://www.seabios.org/pipermail/seabios/2015-March/008897.html OK... So we are waiting on a stable release to pull in new binaries with this fix? A matter of days? My plan is to have a seabios 1.8.1 release ready in time for -rc0 (planned for 2014-03-17 atm). cheers, Gerd
Re: [Qemu-devel] [PATCH v2] vnc: fix segmentation fault when invalid vnc parameters are specified
On Do, 2015-03-12 at 15:33 +0800, arei.gong...@huawei.com wrote: From: Gonglei arei.gong...@huawei.com Reproducer: #./qemu-system-x86_64 -vnc :0,ip qemu-system-x86_64: -vnc :1,ip: Invalid parameter 'ip' Segmentation fault (core dumped) Added to vnc patch queue. thanks, Gerd
Re: [Qemu-devel] [Qemu-block] [PATCH] block/dmg: make it modular if using additional library
On Tue, Mar 10, 2015 at 05:01:38PM +0300, Michael Tokarev wrote: 10.03.2015 16:58, Stefan Hajnoczi пишет: On Tue, Mar 10, 2015 at 10:09 AM, Kevin Wolf kw...@redhat.com wrote: Am 10.03.2015 um 10:17 hat Fam Zheng geschrieben: On Tue, 03/10 09:50, Kevin Wolf wrote: Am 10.03.2015 um 08:06 hat Michael Tokarev geschrieben: Also, should we consider making some more rarely used image formats modules even if they don't pull in external dependencies? Sounds reasonable to me. Is the intention to reduce binary size? Yes, that and also that it allows compiling out some drivers without having to mess with the Makefiles. You just don't install all of them. Related to that, Peter also mentioned that you (the user, not developer or packager) could simply disable a single driver, for example as a temporary hotfix in the case of security problems in a block driver. That would actually be an argument for making _all_ drivers modules. I am for making all block drivers built as modules. That might be useful if module loading will be modified a bit, like by loadin modules on demand only. Something like this, search a foo block driver in the registered list, found - use it, if not, try to open block-foo.so (maybe after looking in the available internal list before that) and look up in the registered list again. That will make it more useful. Even if all modules are automatically loaded, it gives packagers the ability to ship individual packages for Ceph, GlusterFS, etc to reduce library dependencies. Dynamic loading has advantages but there is no reason to wait for it. Stefan pgpSuMjezz4fW.pgp Description: PGP signature
Re: [Qemu-devel] [PATCH v5 for-2.3 00/28] hw/pc: implement multiple primary busses for pc machines
On Di, 2015-03-10 at 17:31 +0200, Marcel Apfelbaum wrote: v4-v5: - Rebased on pci branch, tree: git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git - Added PXB documentation (patch 28/28) - Addressed Gerd Hoffmann's review: - fix PXB behaviour if used with unsupported BIOS (patch 27/28) - Addressed Michael S. Tsirkin's review: - Removed assert in aml_index (patch 5/28) - Renamed pci_ functions to crs_ (patch 12/28) - used uint64_t variables instead of signed ones (patch 12/28) - Emit MEM/IO AML only for PXBs and i440fx (patch 26/28) - Addressed Shannon Zhao's review: - Changed build_append_int to build_append_byte in aml_or (patch 2/25) - Thanks to Igor and Kevin for reviews Tested-by: Gerd Hoffmann kra...@gmail.com Possible improvement: When you figure the devices behind the pxb are not initialized by the firmware (i.e. unmapped), you can try grab some address space not used by devices under root bus 0 and assign it to the pxb. Then the linux kernel can initialize the devices even if the firmware did not. [ Surely should be done incremental like hotplug support to not delay this series even more ] cheers, Gerd
[Qemu-devel] [PATCH 0/2] virtio-ccw: be accesses
OK, here's what I have for the virtio-ccw be stuff. Patch 1 will go via s390-next with my next pull request, patch 2 is on top of your current virtio-1.0 branch and should possibly be merged into the patch introducing set-revision. Cornelia Huck (2): virtio-ccw: assure BE accesses virtio-ccw: assure be accesses for set-revision hw/s390x/virtio-ccw.c | 37 ++--- 1 file changed, 26 insertions(+), 11 deletions(-) -- 2.1.4
[Qemu-devel] [PULLv2] s390x/kvm: Features and fixes for 2.3
Peter, here is the 2nd version (only one patch changed) that hopefully compiles fine on 32 bit hosts. I only added that patch as followup mail. The following changes since commit 277263e1b320d759a760ba6c5ea75ec268f929e5: Merge remote-tracking branch 'remotes/agraf/tags/signed-ppc-for-upstream' into staging (2015-03-09 14:04:14 +) are available in the git repository at: git://github.com/borntraeger/qemu.git tags/s390x-20150310 for you to fetch changes up to 2d5eeef1c0be68c30ccd60fd7267690d523f702a: s390-ccw: rebuild BIOS (2015-03-11 11:15:45 +0100) s390x/kvm: Features and fixes for 2.3 - an extension to the elf loader to allow relocations - make the ccw bios relocatable. This allows for bigger ramdisks or smaller guests - Handle all slow SIGPs in QEMU (instead of kernel) for better compliance and correctness - tell the KVM module the maximum guest size. This allows KVM to reduce the number or page table levels - Several fixes/cleanups Christian Borntraeger (4): synchronize Linux headers to 4.0-rc3 s390-ccw.img: Allow bigger ramdisk sizes or offsets s390-ccw.img: Reinitialize guessing on reboot s390-ccw: rebuild BIOS David Hildenbrand (10): s390x: introduce defines for SIGP condition codes s390x/kvm: more details for SIGP handler with one destination vcpu s390x/kvm: pass the SIGP instruction parameter to the SIGP handler s390x/kvm: helper to set the SIGP status in SigpInfo s390x/kvm: trace all SIGP orders s390x/kvm: implement handling of new SIGP orders s390x/kvm: SIGP START is only applicable when STOPPED s390x: add function to deliver restart irqs s390x/kvm: deliver SIGP RESTART directly if stopped s390x/kvm: enable the new SIGP handling in user space Dominik Dingel (1): s390x/kvm: passing max memory size to accelerator Markus Armbruster (3): virtio-s390: s390_virtio_device_init() can't fail, simplify virtio-s390: Convert to realize() virtio-ccw: Convert to realize() Thomas Huth (2): elf-loader: Provide the possibility to relocate s390 ELF files s390/bios: Make the s390-ccw.img relocatable hw/core/loader.c| 2 + hw/s390x/ipl.c | 24 +- hw/s390x/s390-virtio-bus.c | 97 --- hw/s390x/s390-virtio-bus.h | 2 +- hw/s390x/s390-virtio-ccw.c | 10 + hw/s390x/virtio-ccw.c | 134 + hw/s390x/virtio-ccw.h | 2 +- include/elf.h | 2 + include/hw/elf_ops.h| 78 ++ include/standard-headers/linux/virtio_net.h | 54 ++-- linux-headers/asm-arm/kvm.h | 2 + linux-headers/asm-arm64/kvm.h | 9 + linux-headers/asm-s390/kvm.h| 37 +++ linux-headers/asm-x86/hyperv.h | 11 + linux-headers/linux/kvm.h | 20 +- pc-bios/s390-ccw.img| Bin 17752 - 13616 bytes pc-bios/s390-ccw/Makefile | 11 +- pc-bios/s390-ccw/main.c | 1 + pc-bios/s390-ccw/s390-ccw.h | 1 + pc-bios/s390-ccw/virtio.c | 5 +- target-s390x/cpu.c | 2 + target-s390x/cpu.h | 40 ++- target-s390x/helper.c | 35 ++- target-s390x/kvm.c | 416 target-s390x/machine.c | 5 +- target-s390x/misc_helper.c | 4 +- trace-events| 1 + 27 files changed, 780 insertions(+), 225 deletions(-)
Re: [Qemu-devel] KVM emulation failure with recent kernel and QEMU Seabios
Am 2015-03-12 um 09:11 schrieb Gerd Hoffmann: On Do, 2015-03-12 at 09:09 +0100, Jan Kiszka wrote: Hi, apparently since the latest QEMU updates I'm getting this once in a while: http://www.seabios.org/pipermail/seabios/2015-March/008897.html OK... So we are waiting on a stable release to pull in new binaries with this fix? A matter of days? Jan -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH 7/8] machine: query dump-guest-core machine property rather than qemu opts
On 03/11/2015 01:06 PM, Andreas Färber wrote: Am 11.03.2015 um 09:56 schrieb Michael S. Tsirkin: On Tue, Mar 10, 2015 at 10:36:56PM +0100, Andreas Färber wrote: Am 10.03.2015 um 22:24 schrieb Michael S. Tsirkin: On Tue, Mar 10, 2015 at 06:50:24PM +0100, Andreas Färber wrote: Hi, Am 04.02.2015 um 16:43 schrieb Marcel Apfelbaum: Fixes a QEMU crash when passing dump_guest_core parameter in command line. Explain that, please? Pls note the submission date. It's 1 month late to ask for basic clarifications. I've merged the patches, I'll fix up issues such as prettifying includes by adding patches on top. No, since the patch is not in qemu.git (it builds!) it is not too late to fix it, nor too late to ask why a patch that introduces a breakage does what it does. I tried to say that I'm not holding this patch set up because there are some basic questions. Paolo reviewed it and gave an ack. If others want to re-start review 1 month afterwards, that's fine, but I don't want to defer pull request with this any longer. If someone can quickly spot a serious non-cosmetic problem there, that's another matter, and would make me defer the pull request. (Moving the info from the cover letter into the commit message would've been a good idea, Marcel.) I can tweak commit messages, sure, since that does not require re-testing it all. All QEMU patches are supposed to be bisectable. It's our job as maintainers to build-test each. If you do that 1 month later, that's not my fault. Regards, Andreas I have this patch in my tree and there's no bisect issue, just test-built before and after this patch. That's because I had the ifdefs in boards.h which you and Peter objected to, but that is about cosmetics, I fixed that with a patch on top to hopefully make you both happy. All I was asking for is, please squash the patch(es) that fix(es) the build issue. In particular if you applied the patch just yesterday when we complained. We've been required to, so I expect the same rules to apply to everyone. In order to propose a better fix I tried to understand what the patch is fixing, that's all. If an improvement of the commit message comes out of that, good, but that was not the main purpose. Thanks, Andreas P.S. I was sick most of February and my Chromebook has a broken DRM driver, not allowing for much bedside-hacking. ;) Hi Andreas, I hope you are feeling better now! The main issue I see here (and believe me is not the reviews, they are always welcomed!) is that more than a month ago several developers complained about these crashes. I stopped what I was doing and posted a series ASAP that was almost immediately reviewed by Paolo. I pinged twice already and nobody did anything about it. Michael took it because nobody else did and now we have a situation: No good deed goes unpunished Now, we need a way to not let this happen. I am afraid that next time I will not get lucky and nobody will take the patches :(. Thanks, Marcel Don't take my word for it, you can check out my tree and verify, that would be very wellcome. -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton; HRB 21284 (AG Nürnberg)
Re: [Qemu-devel] [PATCH RFC 0/2] Limit support for encrypted images to qemu-img
Am 11.03.2015 um 10:59 hat Daniel P. Berrange geschrieben: On Wed, Mar 11, 2015 at 09:55:16AM +0100, Markus Armbruster wrote: Daniel P. Berrange berra...@redhat.com writes: FWIW, I could see an improved interaction scheme working as follows First, introduce a new monitor command for setting named passwords, add_key mykey1 SECRETDATA Now, extend the blockdev_add so that you can provide key names by adding 'keyname': 'mykey1' as a parameter in the json args. Can you explain why that's better than sticking 'key': SECRETDATA right into blockdev-add's arguments? Just have a small preference to keep passwords separated from the rest of the data, so when logging the stuff for debug purposes we don't compromise people's passwords quite so readily. Indeed, it would be very easy for a password to end up in error messages, or in json: filenames that might be used in query-block replies or in a backing file path. BDS options should be considered more or less public. It is more straightforward for us to mask out the passwords if we can just match on the command name, and not have to try to grok the specific field in a large set of args. Also in terms of cold startup, it is not desirable to have the password directly included in the args to -drive or equiv, as that's visible in process listings. Right, that too. Kevin
Re: [Qemu-devel] E5-2620v2 - emulation stop error
* Andrey Korolyov (and...@xdel.ru) wrote: On Sat, Mar 7, 2015 at 3:00 AM, Andrey Korolyov and...@xdel.ru wrote: On Fri, Mar 6, 2015 at 7:57 PM, Bandan Das b...@redhat.com wrote: Andrey Korolyov and...@xdel.ru writes: On Fri, Mar 6, 2015 at 1:14 AM, Andrey Korolyov and...@xdel.ru wrote: Hello, recently I`ve got a couple of shiny new Intel 2620v2s for future replacement of the E5-2620v1, but I experienced relatively many events with emulation errors, all traces looks simular to the one below. I am running qemu-2.1 on x86 on top of 3.10 branch for testing purposes but can switch to some other versions if necessary. Most of crashes happened during reboot cycle or at the end of ACPI-based shutdown action, if this can help. I have zero clues of what can introduce such a mess inside same processor family using identical software, as 2620v1 has no simular problem ever. Please let me know if there can be some side measures for making entire story more clear. Thanks! KVM internal error. Suberror: 2 extra data[0]: 80d1 extra data[1]: 8b0d EAX=0003 EBX= ECX= EDX= ESI= EDI= EBP= ESP=6cd4 EIP=d3f9 EFL=00010202 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES = 9300 CS =f000 000f 9b00 SS = 9300 DS = 9300 FS = 9300 GS = 9300 LDT= 8200 TR = 8b00 GDT= 000f6e98 0037 IDT= 03ff CR0=0010 CR2= CR3= CR4= DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 EFER= Code=48 18 67 8c 00 8c d1 8e d9 66 5a 66 58 66 5d 66 c3 cd 02 cb cd 10 cb cd 13 cb cd 15 cb cd 16 cb cd 18 cb cd 19 cb cd 1c cb fa fc 66 b8 00 e0 00 00 8e It turns out that those errors are introduced by APICv, which gets enabled due to different feature set. If anyone is interested in reproducing/fixing this exactly on 3.10, it takes about one hundred of migrations/power state changes for an issue to appear, guest OS can be Linux or Win. Are you able to reproduce this on a more recent upstream kernel as well ? Bandan I`ll go through test cycle with 3.18 and 2603v2 around tomorrow and follow up with any reproduceable results. Heh.. issue is not triggered on 2603v2 at all, at least I am not able to hit this. The only difference with 2620v2 except lower frequency is an Intel Dynamic Acceleration feature. I`d appreciate any testing with higher CPU models with same or richer feature set. The testing itself can be done on both generic 3.10 or RH7 kernels, as both of them are experiencing this issue. I conducted all tests with disabled cstates so I advise to do the same for a first reproduction step. Thanks! model name : Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz stepping: 4 microcode : 0x416 cpu MHz : 2100.039 cache size : 15360 KB siblings: 12 apicid : 43 initial apicid : 43 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms I'm seeing something similar; it's very intermittent and generally happening right at boot of the guest; I'm running this on qemu head+my postcopy world (but it's happening right at boot before postcopy gets a chance), and I'm using a 3.19ish kernel. Xeon E5-2407 in my case but hey maybe I'm seeing a different bug. Dave -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
[Qemu-devel] [PULL 10/10] bitops.h: sextract64() return type should be int64_t, not uint64_t
The documentation for sextract64() claims that the return type is
an int64_t, but the code itself disagrees. Fix the return type to
conform to the documentation and to bring it into line with
sextract32(), which returns int32_t.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
Reviewed-by: Richard Henderson r...@twiddle.net
Message-id: 1423231328-15662-1-git-send-email-peter.mayd...@linaro.org
---
include/qemu/bitops.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/qemu/bitops.h b/include/qemu/bitops.h
index 181bd46..90ca8df 100644
--- a/include/qemu/bitops.h
+++ b/include/qemu/bitops.h
@@ -354,7 +354,7 @@ static inline int32_t sextract32(uint32_t value, int start,
int length)
* Returns: the sign extended value of the bit field extracted from the
* input value.
*/
-static inline uint64_t sextract64(uint64_t value, int start, int length)
+static inline int64_t sextract64(uint64_t value, int start, int length)
{
assert(start = 0 length 0 length = 64 - start);
/* Note that this implementation relies on right shift of signed
--
1.9.1
Re: [Qemu-devel] [PATCH] hw/boards: make it safe to include for linux-user
On Tue, Mar 10, 2015 at 06:34:44PM +0100, Andreas Färber wrote:
Am 10.03.2015 um 18:33 schrieb Michael S. Tsirkin:
Make it safe to include hw/boards.h in exec.c
for linux-user configurations.
We don't need any of its contents though.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
Already on my tree as Marcel's patches needed this.
Why? Which patches?
Andreas
This one:
machine: query dump-guest-core machine property rather than qemu opts
include/hw/boards.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/hw/boards.h b/include/hw/boards.h
index 1f21bdf..0bf00f7 100644
--- a/include/hw/boards.h
+++ b/include/hw/boards.h
@@ -3,6 +3,8 @@
#ifndef HW_BOARDS_H
#define HW_BOARDS_H
+#if !defined(CONFIG_USER_ONLY)
+
#include qemu/typedefs.h
#include sysemu/blockdev.h
#include sysemu/accel.h
@@ -154,3 +156,5 @@ struct MachineState {
};
#endif
+
+#endif
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu,
Graham Norton; HRB 21284 (AG Nürnberg)
Re: [Qemu-devel] [PATCH] configure: bump glib version to 2.16
Adding in Michael Tokarev, I fat-fingered his email address. On 03/10/2015 01:37 PM, John Snow wrote: Our qtest suite relies on many functions available only in glib 2.16+. Even though our base QEMU binary may only require 2.12+, it is confusing to have two separate version requirements. Thus, this is an attempt to re-establish a sane baseline for the entire project at 2.16+. Signed-off-by: John Snow js...@redhat.com --- configure | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure b/configure index 7ba4bcb..c38506c 100755 --- a/configure +++ b/configure @@ -2748,7 +2748,7 @@ if test $mingw32 = yes; then # g_poll is required in order to integrate with the glib main loop. glib_req_ver=2.20 else -glib_req_ver=2.12 +glib_req_ver=2.16 fi glib_modules=gthread-2.0 if test $modules = yes; then
Re: [Qemu-devel] [PATCH] configure: bump glib version to 2.16
On 10 March 2015 at 17:43, John Snow js...@redhat.com wrote: Wasn't aware we were actually going through with that; it had looked like we were going to refrain from fiddling with it because we found a workaround that sufficed for glib 2.12. Well, we're not doing anything before QEMU 2.3 is released. But if we bump the version requirement at all, then we might as well move it to 2.22, because once you drop the support RHEL5 requirement then that's the newest version we can shift to without breaking compilation on some other distro we care about (SUSE, in this case). -- PMM
Re: [Qemu-devel] fw_cfg specification ?
Hi, I won't say better, but it is committed: check Documentation/devicetree/bindings/arm/fw-cfg.txt in the kernel tree. It is intentionally vague on the set of keys and fw_cfg files that qemu provides, because that's a moving target. You can only rely on the qemu source for those. The fw_cfg interface from the guest's perspective is pretty straightforward: select something on the control port, read a blob from the data port. I think just commiting Jordan's patch as-is would be a good start. Then we can go from there adding missing bits. It's also easier to refuse patches without doc updates if there actually is documentation in the first place ;) For instance, I get there's a total of 0x30 entries (FWCfgEntry entries), the last 0x10 of which have file names and are referenced from the FWCfgFiles *files structure. That's basically referencing stuff by name rather than magic numbers. It's used for all new stuff. There is a simliar interface named 'cbfs' between coreboot and seabios. No. Please see the fw_cfg_write() function. Only the same size can be written, and the write callback runs when that's completed. In any case, I'm unaware of *any* instance when an fw_cfg blob is rewritten by the guest. In fact, such *write* callbacks are registered in qemu with fw_cfg_add_callback(), and I can't see any calls to that function. It's dead code, apparently. Guess we should just drop the code then. There is though a bit more to the story: the (recent) read callbacks. Qemu sometimes decides to re-generate a bunch of stuff in the fw_cfg blobs. See the commit message here: That is used for acpi. acpi initialization goes like this: (1) firmware initializes the hardware as it pleases. (2) firmware fetches acpi tables from qemu, and the read callback is used to update the addresses in the acpi tables according to the initialization done by the firmware (acpi pci device, mmconfig xbar, ...) Main reason to do it this way is we don't need paravirtual interfaces to pass around those addresses. Once I start getting what's going on (e.g., w.r.t. the questions above) I wouldn't mind just adding *comments* to the source, for the next guy who, like me, is trying to get the lay of the land, but I'm not there yet... I'd suggest to update the doc file created by the old patch instead. cheers, Gerd
Re: [Qemu-devel] [PATCH] hw/boards: make it safe to include for linux-user
Am 10.03.2015 um 18:41 schrieb Michael S. Tsirkin: On Tue, Mar 10, 2015 at 06:34:44PM +0100, Andreas Färber wrote: Am 10.03.2015 um 18:33 schrieb Michael S. Tsirkin: Make it safe to include hw/boards.h in exec.c for linux-user configurations. We don't need any of its contents though. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- Already on my tree as Marcel's patches needed this. Why? Which patches? Andreas This one: machine: query dump-guest-core machine property rather than qemu opts Let's please find a better way to fix that. hw/boards.h shouldn't be used outside softmmu code. Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton; HRB 21284 (AG Nürnberg)
Re: [Qemu-devel] [PULL 0/7] X86 patches
On Tue, Mar 10, 2015 at 11:16:36AM -0300, Eduardo Habkost wrote:
On Tue, Mar 10, 2015 at 11:44:22AM +, Peter Maydell wrote:
On 9 March 2015 at 20:40, Eduardo Habkost ehabk...@redhat.com wrote:
The following changes since commit
277263e1b320d759a760ba6c5ea75ec268f929e5:
Merge remote-tracking branch
'remotes/agraf/tags/signed-ppc-for-upstream' into staging (2015-03-09
14:04:14 +)
are available in the git repository at:
https://github.com/ehabkost/qemu.git tags/x86-pull-request
for you to fetch changes up to 9886e834f47adabdbfd54ab606788ce7326e6779:
target-i386: Require APIC ID to be explicitly set before CPU realize
(2015-03-09 16:30:03 -0300)
X86 patches queued in the last few weeks. Mostly code cleanup and changes
on
code assigning APIC ID.
'make check' fails for the i386 targets, apparently because qemu-system-i386
segfaults on startup:
Ouch.
But I couldn't reproduce it on my system using the tree at the tag
above. Was it a merge containing other changes that are not on qemu.git
yet?
So, as I can't reproduce it I will try to understand what's happening
below:
e104462:trusty:qemu-for-merges$ gdb --args
./build/all/i386-softmmu/qemu-system-i386 -display none
[...]
(gdb) r
Starting program:
/home/petmay01/linaro/qemu-for-merges/build/all/i386-softmmu/qemu-system-i386
-display none
[...]
Program received signal SIGSEGV, Segmentation fault.
object_get_class (obj=obj@entry=0x0) at
/home/petmay01/linaro/qemu-for-merges/qom/object.c:589
589 return obj-class;
So, obj is NULL here...
(gdb) bt
#0 object_get_class (obj=obj@entry=0x0) at
/home/petmay01/linaro/qemu-for-merges/qom/object.c:589
#1 0x556668c2 in apic_enable_tpr_access_reporting
(dev=optimized out, enable=optimized out)
at /home/petmay01/linaro/qemu-for-merges/hw/intc/apic_common.c:86
That means cpu-apic_state is NULL at:
static void vapic_enable_tpr_reporting(bool enable)
{
VAPICEnableTPRReporting info = {
.enable = enable,
};
CPUState *cs;
X86CPU *cpu;
CPU_FOREACH(cs) {
cpu = X86_CPU(cs);
info.apic = cpu-apic_state;
run_on_cpu(cs, vapic_do_enable_tpr_reporting, info);
}
}
vapic_enable_tpr_reporting() is called at:
* vapic_prepare(), which is called at:
* vapic_write()
* Which is vapic_ops.write, so it should be triggered by guest code only
* vapic_post_load()
* Which should run only for loadvm/migration
* vapic_reset()
* Which is DeviceClass::reset for TYPE_VAPIC
X86CPU::apic_state is set by x86_cpu_apic_create() (which checks for NULL and
reports an error in that case), which is called by x86_cpu_realizefn(), but
only if the CPU has CPUID_APIC set or smp_cpus 1. CPUID_APIC is set on the
default CPU model (qemu64), so it should be always called.
Also, the TYPE_VAPIC object is created by apic_common_realize(), so no
TYPE_VAPIC object should exist until a TYPE_*_APIC object is created and
realized. So it looks like x86_cpu_apic_create() is really being called.
Maybe what's happening here is that the reset handler for TYPE_VAPIC is being
called too soon, even before x86_cpu_apic_create() returns? But why?
This is not making a lot of sense to me, and the fact that I can't reproduce
the error makes it more difficult.
#2 0x5562f881 in flush_queued_work (cpu=0x562c6b00)
at /home/petmay01/linaro/qemu-for-merges/cpus.c:871
#3 qemu_wait_io_event_common (cpu=cpu@entry=0x562c6b00)
at /home/petmay01/linaro/qemu-for-merges/cpus.c:888
#4 0x55630a27 in qemu_tcg_cpu_thread_fn (arg=optimized out)
at /home/petmay01/linaro/qemu-for-merges/cpus.c:1024
#5 0x70865182 in start_thread (arg=0x7fffdf99e700) at
pthread_create.c:312
#6 0x7059200d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111
(gdb)
thanks
-- PMM
--
Eduardo
--
Eduardo
Re: [Qemu-devel] [PULLv2] qemu-sparc update
On 10 March 2015 at 14:01, Mark Cave-Ayland mark.cave-ayl...@ilande.co.uk wrote: Hi Peter, Here are the updates from my qemu-sparc tree. Please pull. ATB, Mark. v2: update OpenBIOS git submodule and all binaries The following changes since commit 277263e1b320d759a760ba6c5ea75ec268f929e5: Merge remote-tracking branch 'remotes/agraf/tags/signed-ppc-for-upstream' into staging (2015-03-09 14:04:14 +) are available in the git repository at: https://github.com/mcayland/qemu.git tags/qemu-sparc-signed for you to fetch changes up to f3b18f35a23c60edbda6420cd4bd30b8bb11ea80: sun4u: switch m48t59 NVRAM to MMIO access (2015-03-10 09:36:19 +) qemu-sparc update Applied, thanks. -- PMM
Re: [Qemu-devel] [PATCH RFC 0/2] Limit support for encrypted images to qemu-img
On Wed, Mar 11, 2015 at 09:55:16AM +0100, Markus Armbruster wrote: Daniel P. Berrange berra...@redhat.com writes: On Tue, Mar 10, 2015 at 06:26:38PM +0100, Markus Armbruster wrote: RFC because the series only covers open [PATCH 1], but not create. Also missing: make qemu-img print a warning when it creates an encrypted image. Finally, some of the material in the cover letter should be worked into the commit messages. We've steered users away from QCOW/QCOW2 encryption for a while, because it's a flawed design (commit 136cd19 Describe flaws in qcow/qcow2 encryption in the docs). In addition to flawed crypto, we have comically bad usability, and plain old bugs. Let me show you. = Usability issues = == Confusing startup == == Incorrect passwords not caught == == Need to stop the guest to add an encrypted image == == Use without key is not always caught == == QMP device_add of usb-storage fails when it shouldn't == So there's really two separate root cuase problems we're facing here. One of the usability issues is inherant artifact of the qcow design. The other 4 issues are all due to the badly designed block driver / monitor key management approach. Yup. The latter is fixable, but not worth fixing as long as the underlying crypto isn't worth using. If people become sufficiently interested in encrypted images to contribute a cryptographically sane implementation for QCOW2 (or whatever other format), then rewriting the necessary support around it from scratch will likely be easier and yield better results than fixing up the existing mess. Let's drop the mess and move on. Keep qemu-img convert working, of course, to let users rescue their data. Once I've got through the current work i'm doing on TLS support for migrate/nbd/chardev/etc, my intention is to work on adding support for the LUKS format to QEMU. We really need this natively in OpenStack since we're increasingly using the QEMU native client for nbd, iscsi, nfs, etc but at the same time don't want to sacrifice encryption which we currently do via LUKS. It is probably a good 4-6 months though before I get on to working on this. Great! I agree with all your points about the usability being fubar. This clearly needs to be fixed for encryption support to be viable in QEMU, regardless of the actual encryption format used. I guess my question is whether it is worth trying to fix the blockdev integration part of things now, or to rip it out now and reimplement it from scratch later ? I think I probably agree with killing it now, since it might actually make doing a sensible impl easier later on. In your shoes, I'd certainly prefer to drop the current mess and start over. Not just because I think it'll make the work easier, but also because I'd want to break out of the back-compat strait-jacket, to be free to create the best user interface I can. And lets assume we do eventually have a fixed blockdev layer and a sane LUKS encryption driver, would we still want to kill off qcow2 encryption ? Given the way subpar encryption is being actively attacked by everyone their dog, I think mandatory retirement of qcow2 encryption is a good idea sooner rather than later. I strongly believe retiring it is a public service. Except for qemu-img. I'm prepared to keep it there for a long time, maybe forever. My only concern here is whether we've given users enough prior warning. While we added that doc change a year ago, what are the odds that anyone has actually read those docs noticed the warning. Should we have one major release where we log a deprecation warning on stderr, informing users of an explicit timeframe for its removal, before we actually use the big hammer of disabling it permanently ? I'm fine with that. In fact, I could agree to pretty much any deprecation schedule, as long as we start it *now*. IIUC, the 2.3.0 major branch is targetted for end of this month, so we could put in code that issues a deprecation warning on stderr for 2.3.0, and then delete all this stuff when GIT master opens for 2.4.0 development ? FWIW, I could see an improved interaction scheme working as follows First, introduce a new monitor command for setting named passwords, add_key mykey1 SECRETDATA Now, extend the blockdev_add so that you can provide key names by adding 'keyname': 'mykey1' as a parameter in the json args. Can you explain why that's better than sticking 'key': SECRETDATA right into blockdev-add's arguments? Just have a small preference to keep passwords separated from the rest of the data, so when logging the stuff for debug purposes we don't compromise people's passwords quite so readily. It is more straightforward for us to mask out the passwords if we can just match on the command name, and not have to try to grok the specific field in a large set of args.
Re: [Qemu-devel] [PATCH 0/2] ui: two small fixes
On Mi, 2015-03-11 at 16:20 +0800, arei.gong...@huawei.com wrote: Gonglei (2): ui/console: fix OVERFLOW_BEFORE_WIDEN vnc: avoid possible file handler leak added to vnc patch queue. thanks, Gerd
Re: [Qemu-devel] [PATCH v2 1/1] target-i386: Remove icc_bridge parameter from cpu_x86_create()
On Tue, 10 Mar 2015 18:57:35 -0300
Eduardo Habkost ehabk...@redhat.com wrote:
Instead of passing icc_bridge from the PC initialization code to
cpu_x86_create(), make the PC initialization code attach the CPU to
icc_bridge.
The only difference here is that icc_bridge attachment will now be done
after x86_cpu_parse_featurestr() is called. But this shouldn't make any
difference, as property setters shouldn't depend on icc_bridge.
Signed-off-by: Eduardo Habkost ehabk...@redhat.com
With comment below fixed
Reviewed-by: Igor Mammedov imamm...@redhat.com
---
Changes v1 - v2:
* Keep existing check for NULL icc_bridge and error reporting, instead
of assing assert(icc_bridge)
---
hw/i386/pc.c | 13 +++--
target-i386/cpu.c | 14 ++
target-i386/cpu.h | 3 +--
3 files changed, 14 insertions(+), 16 deletions(-)
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index b5b2aad..a26e0ec 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -992,18 +992,27 @@ void pc_acpi_smi_interrupt(void *opaque, int irq, int
level)
static X86CPU *pc_new_cpu(const char *cpu_model, int64_t apic_id,
DeviceState *icc_bridge, Error **errp)
{
-X86CPU *cpu;
+X86CPU *cpu = NULL;
Error *local_err = NULL;
-cpu = cpu_x86_create(cpu_model, icc_bridge, local_err);
+if (icc_bridge == NULL) {
turn it into assert(icc_bridge != NULL)
that should never be NULL or we have a codding error somewhere in code.
+error_setg(local_err, Invalid icc-bridge value);
+goto out;
+}
+
+cpu = cpu_x86_create(cpu_model, local_err);
if (local_err != NULL) {
error_propagate(errp, local_err);
return NULL;
}
+qdev_set_parent_bus(DEVICE(cpu), qdev_get_child_bus(icc_bridge, icc));
+object_unref(OBJECT(cpu));
+
object_property_set_int(OBJECT(cpu), apic_id, apic-id, local_err);
object_property_set_bool(OBJECT(cpu), true, realized, local_err);
+out:
if (local_err) {
error_propagate(errp, local_err);
object_unref(OBJECT(cpu));
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 50907d0..097924c 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -2076,8 +2076,7 @@ static void x86_cpu_load_def(X86CPU *cpu,
X86CPUDefinition *def, Error **errp)
}
-X86CPU *cpu_x86_create(const char *cpu_model, DeviceState *icc_bridge,
- Error **errp)
+X86CPU *cpu_x86_create(const char *cpu_model, Error **errp)
{
X86CPU *cpu = NULL;
X86CPUClass *xcc;
@@ -2108,15 +2107,6 @@ X86CPU *cpu_x86_create(const char *cpu_model,
DeviceState *icc_bridge,
cpu = X86_CPU(object_new(object_class_get_name(oc)));
-#ifndef CONFIG_USER_ONLY
-if (icc_bridge == NULL) {
-error_setg(error, Invalid icc-bridge value);
-goto out;
-}
-qdev_set_parent_bus(DEVICE(cpu), qdev_get_child_bus(icc_bridge, icc));
-object_unref(OBJECT(cpu));
-#endif
-
x86_cpu_parse_featurestr(CPU(cpu), features, error);
if (error) {
goto out;
@@ -2139,7 +2129,7 @@ X86CPU *cpu_x86_init(const char *cpu_model)
Error *error = NULL;
X86CPU *cpu;
-cpu = cpu_x86_create(cpu_model, NULL, error);
+cpu = cpu_x86_create(cpu_model, error);
if (error) {
goto out;
}
diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index 0638d24..8d748bd 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -982,8 +982,7 @@ typedef struct CPUX86State {
#include cpu-qom.h
X86CPU *cpu_x86_init(const char *cpu_model);
-X86CPU *cpu_x86_create(const char *cpu_model, DeviceState *icc_bridge,
- Error **errp);
+X86CPU *cpu_x86_create(const char *cpu_model, Error **errp);
int cpu_x86_exec(CPUX86State *s);
void x86_cpu_list(FILE *f, fprintf_function cpu_fprintf);
void x86_cpudef_setup(void);
Re: [Qemu-devel] [PATCH] hmp: add info iothreads command
On 2015-3-12 15:20, Fam Zheng wrote: On Thu, 03/12 15:00, Ting Wang wrote: +if (elem-value) +monitor_printf(mon, %s: thread_id=%ld\n, elem-value-id, +elem-value-thread_id); Braces are required for if. Fam Okay, will fix in v2, thanks. Ting
Re: [Qemu-devel] configure: enable kvm on x32
12.03.2015 10:16, Peter Maydell wrote: On 12 March 2015 at 06:13, Michael Tokarev m...@tls.msk.ru wrote: Here's a trivial change to enable kvm on x32 architecture. I'm not 100% sure the result works correctly in all cases, but this is a good start and in theory everything should work. Given the pessimism expressed in this comment, perhaps we should delay this to 2.4 and when it's had more testing? There's no pessimism really. It is a new arch for kvm, so _something_ might not work. In practice it works fairy well, see https://bugs.debian.org/778737 -- at least debian can be installed in x32 kvm. And we don't lose anything really because it is a new arch. That's why it was Cc'd -trivial. Thanks, /mjt
[Qemu-devel] KVM emulation failure with recent kernel and QEMU Seabios
Hi, apparently since the latest QEMU updates I'm getting this once in a while: KVM internal error. Suberror: 1 emulation failure EAX= EBX= ECX= EDX=000fd2bc ESI= EDI= EBP= ESP= EIP=000fd2c5 EFL=00010007 [-PC] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0010 00c09300 DPL=0 DS [-WA] CS =0008 00c09b00 DPL=0 CS32 [-RA] SS =0010 00c09300 DPL=0 DS [-WA] DS =0010 00c09300 DPL=0 DS [-WA] FS =0010 00c09300 DPL=0 DS [-WA] GS =0010 00c09300 DPL=0 DS [-WA] LDT= 8200 DPL=0 LDT TR = 8b00 DPL=0 TSS32-busy GDT= 000f6a80 0037 IDT= 000f6abe CR0=6011 CR2= CR3= CR4= DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 EFER= Code=66 ba bc d2 0f 00 e9 a2 fe f3 90 f0 0f ba 2d 04 ff fb 3f 00 72 f3 8b 25 00 ff fb 3f e8 44 66 ff ff c7 05 04 ff fb 3f 00 00 00 00 f4 eb fd fa fc 66 b8 KVM internal error. Suberror: 1 emulation failure EAX= EBX= ECX= EDX=000fd2bc ESI= EDI= EBP= ESP= EIP=000fd2bc EFL=00010007 [-PC] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0010 00c09300 DPL=0 DS [-WA] CS =0008 00c09b00 DPL=0 CS32 [-RA] SS =0010 00c09300 DPL=0 DS [-WA] DS =0010 00c09300 DPL=0 DS [-WA] FS =0010 00c09300 DPL=0 DS [-WA] GS =0010 00c09300 DPL=0 DS [-WA] LDT= 8200 DPL=0 LDT TR = 8b00 DPL=0 TSS32-busy GDT= 000f6a80 0037 IDT= 000f6abe CR0=6011 CR2= CR3= CR4= DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 EFER= Code=0a 00 e8 a0 64 ff ff 0f aa 66 ba bc d2 0f 00 e9 a2 fe f3 90 f0 0f ba 2d 04 ff fb 3f 00 72 f3 8b 25 00 ff fb 3f e8 44 66 ff ff c7 05 04 ff fb 3f 00 00 KVM internal error. Suberror: 1 emulation failure EAX= EBX= ECX= EDX=000fd2bc ESI= EDI= EBP= ESP= EIP=000fd2c5 EFL=00010007 [-PC] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0010 00c09300 DPL=0 DS [-WA] CS =0008 00c09b00 DPL=0 CS32 [-RA] SS =0010 00c09300 DPL=0 DS [-WA] DS =0010 00c09300 DPL=0 DS [-WA] FS =0010 00c09300 DPL=0 DS [-WA] GS =0010 00c09300 DPL=0 DS [-WA] LDT= 8200 DPL=0 LDT TR = 8b00 DPL=0 TSS32-busy GDT= 000f6a80 0037 IDT= 000f6abe CR0=6011 CR2= CR3= CR4= DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 EFER= Code=66 ba bc d2 0f 00 e9 a2 fe f3 90 f0 0f ba 2d 04 ff fb 3f 00 72 f3 8b 25 00 ff fb 3f e8 44 66 ff ff c7 05 04 ff fb 3f 00 00 00 00 f4 eb fd fa fc 66 b8 The command line to trigger it: qemu-system-x86_64 -m 1G -enable-kvm -s -cpu kvm64 -smp 4 -no-kvm-irqchip The issue did not yet show up when using in-kernel irqchips or when doing git checkout 11d39a13 pc-bios, i.e. reverting the recent BIOS updates. I'm on QEMU master (with 04f56432 reverted) and either kernel 4.0.0-rc3 or kvm.git next. Jan
[Qemu-devel] [PULL v2 1/5] sdl: Refresh debug statements
From: Benjamin Herrenschmidt b...@kernel.crashing.org
Put them under a #define similar to the VGA model and make them
actually compile. Add a couple too.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
ui/sdl.c | 24 ++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/ui/sdl.c b/ui/sdl.c
index 138ca73..b89182a 100644
--- a/ui/sdl.c
+++ b/ui/sdl.c
@@ -61,16 +61,24 @@ static SDL_PixelFormat host_format;
static int scaling_active = 0;
static Notifier mouse_mode_notifier;
+#if 0
+#define DEBUG_SDL
+#endif
+
static void sdl_update(DisplayChangeListener *dcl,
int x, int y, int w, int h)
{
-//printf(updating x=%d y=%d w=%d h=%d\n, x, y, w, h);
SDL_Rect rec;
rec.x = x;
rec.y = y;
rec.w = w;
rec.h = h;
+#ifdef DEBUG_SDL
+printf(SDL: Updating x=%d y=%d w=%d h=%d (scaling: %d)\n,
+ x, y, w, h, scaling_active);
+#endif
+
if (guest_screen) {
if (!scaling_active) {
SDL_BlitSurface(guest_screen, rec, real_screen, rec);
@@ -89,7 +97,9 @@ static void do_sdl_resize(int width, int height, int bpp)
int flags;
SDL_Surface *tmp_screen;
-//printf(resizing to %d %d\n, w, h);
+#ifdef DEBUG_SDL
+printf(SDL: Resizing to %dx%d bpp %d\n, width, height, bpp);
+#endif
flags = SDL_HWSURFACE | SDL_ASYNCBLIT | SDL_HWACCEL;
if (gui_fullscreen) {
@@ -143,6 +153,12 @@ static void sdl_switch(DisplayChangeListener *dcl,
if (guest_screen != NULL) {
SDL_FreeSurface(guest_screen);
}
+
+#ifdef DEBUG_SDL
+printf(SDL: Creating surface with masks: %08x %08x %08x %08x\n,
+ pf.rmask, pf.gmask, pf.bmask, pf.amask);
+#endif
+
guest_screen = SDL_CreateRGBSurfaceFrom
(surface_data(surface),
surface_width(surface), surface_height(surface),
@@ -486,6 +502,10 @@ static void sdl_scale(int width, int height)
{
int bpp = real_screen-format-BitsPerPixel;
+#ifdef DEBUG_SDL
+printf(SDL: Scaling to %dx%d bpp %d\n, width, height, bpp);
+#endif
+
if (bpp != 16 bpp != 32) {
bpp = 32;
}
--
1.8.3.1
[Qemu-devel] [PULL v2 0/5] sdl patch queue.
Hi, Misc stuff in the basket: sdl bugfixes, some preparing patches for the upcoming opengl support in sdl2, x11 build improvement. v2 fixes the clang build failure. please pull, Gerd The following changes since commit d598911b6f5e7bf7bafb63b8e1d074729e94aca7: Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20150311' into staging (2015-03-11 16:30:33 +) are available in the git repository at: git://git.kraxel.org/qemu tags/pull-sdl-20150312-1 for you to fetch changes up to ecdc9a53acd7a5d0cf48f1b77b83c70e513e81da: pixman: add a bunch of PIXMAN_BE_* defines for 32bpp (2015-03-12 09:20:42 +0100) misc ui patches, mostly sdl related. Benjamin Herrenschmidt (2): sdl: Refresh debug statements sdl: Fix crash when calling sdl_switch() with NULL surface Gerd Hoffmann (2): configure: opengl overhaul pixman: add a bunch of PIXMAN_BE_* defines for 32bpp Jeremy White (1): Allow the use of X11 from a non standard location. configure| 59 +++- default-configs/lm32-softmmu.mak | 2 +- hw/display/Makefile.objs | 3 +- hw/lm32/milkymist-hw.h | 4 +-- include/sysemu/sysemu.h | 1 + include/ui/qemu-pixman.h | 16 +++ ui/sdl.c | 27 -- vl.c | 1 + 8 files changed, 81 insertions(+), 32 deletions(-)
[Qemu-devel] [PULL v2 2/5] sdl: Fix crash when calling sdl_switch() with NULL surface
From: Benjamin Herrenschmidt b...@kernel.crashing.org
This happens for example when doing ctrl-alt-u and segfaults
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
ui/sdl.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/ui/sdl.c b/ui/sdl.c
index b89182a..8bdbf52 100644
--- a/ui/sdl.c
+++ b/ui/sdl.c
@@ -135,12 +135,13 @@ static void do_sdl_resize(int width, int height, int bpp)
static void sdl_switch(DisplayChangeListener *dcl,
DisplaySurface *new_surface)
{
-PixelFormat pf = qemu_pixelformat_from_pixman(new_surface-format);
+PixelFormat pf;
/* temporary hack: allows to call sdl_switch to handle scaling changes */
if (new_surface) {
surface = new_surface;
}
+pf = qemu_pixelformat_from_pixman(surface-format);
if (!scaling_active) {
do_sdl_resize(surface_width(surface), surface_height(surface), 0);
--
1.8.3.1
[Qemu-devel] qemu-system-ppc TCG assert with git master
Hi all, Whilst testing git master in preparation for some OpenBIOS updates, I'm seeing the following TCG assert in one of my older test images: $ gdb --args ./qemu-system-ppc -cdrom /home/build/src/qemu/image/ppc/ubuntu-5.10-live-powerpc.iso -boot d -g 800x600x8 GNU gdb (GDB) 7.4.1-debian Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /home/build/rel-qemu-git/bin/qemu-system-ppc...done. (gdb) r Starting program: /home/build/rel-qemu-git/bin/qemu-system-ppc -cdrom /home/build/src/qemu/image/ppc/ubuntu-5.10-live-powerpc.iso -boot d -g 800x600x8 [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. [New Thread 0x7fffe9ef3700 (LWP 11437)] [New Thread 0x7fffe5bf1700 (LWP 11438)] [New Thread 0x7fffe53f0700 (LWP 11439)] [Thread 0x7fffe5bf1700 (LWP 11438) exited] [New Thread 0x7fffe5bf1700 (LWP 11443)] [Thread 0x7fffe5bf1700 (LWP 11443) exited] qemu-system-ppc: /home/build/src/qemu/git/qemu/tcg/optimize.c:212: tcg_opt_gen_mov: Assertion `temps[src].state != TCG_TEMP_CONST' failed. Program received signal SIGABRT, Aborted. [Switching to Thread 0x7fffe53f0700 (LWP 11439)] 0x722ec165 in *__GI_raise (sig=optimized out) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 0x722ec165 in *__GI_raise (sig=optimized out) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x722ef3e0 in *__GI_abort () at abort.c:92 #2 0x722e5311 in *__GI___assert_fail (assertion=0x55a819e0 temps[src].state != TCG_TEMP_CONST, file=optimized out, line=212, function=0x55a82460 tcg_opt_gen_mov) at assert.c:81 #3 0x55632701 in tcg_opt_gen_mov (s=0x55f3bc80, op=0x55f82f00, args=0x55f84350, old_op=INDEX_op_or_i32, dst=9, src=189) at /home/build/src/qemu/git/qemu/tcg/optimize.c:212 #4 0x55634e5c in tcg_constant_folding (s=0x55f3bc80) at /home/build/src/qemu/git/qemu/tcg/optimize.c:984 #5 0x55636295 in tcg_optimize (s=0x55f3bc80) at /home/build/src/qemu/git/qemu/tcg/optimize.c:1356 #6 0x5562c30c in tcg_gen_code_common (s=0x55f3bc80, gen_code_buf=0x7fffe8840770 , search_pc=-1) at /home/build/src/qemu/git/qemu/tcg/tcg.c:2277 #7 0x5562c67a in tcg_gen_code (s=0x55f3bc80, gen_code_buf=0x7fffe8840770 ) at /home/build/src/qemu/git/qemu/tcg/tcg.c:2385 #8 0x5561e068 in cpu_ppc_gen_code (env=0x77fdf260, tb=0x7fffe65ead30, gen_code_size_ptr=0x7fffe53ef890) at /home/build/src/qemu/git/qemu/translate-all.c:182 #9 0x5561f49c in tb_gen_code (cpu=0x77fd7010, pc=3373291568, cs_base=0, flags=0, cflags=0) at /home/build/src/qemu/git/qemu/translate-all.c:1064 #10 0x55621403 in tb_find_slow (env=0x77fdf260, pc=3373291568, cs_base=0, flags=0) at /home/build/src/qemu/git/qemu/cpu-exec.c:299 #11 0x5562158c in tb_find_fast (env=0x77fdf260) at /home/build/src/qemu/git/qemu/cpu-exec.c:327 #12 0x556219dd in cpu_ppc_exec (env=0x77fdf260) at /home/build/src/qemu/git/qemu/cpu-exec.c:485 #13 0x556684e9 in tcg_cpu_exec (env=0x77fdf260) at /home/build/src/qemu/git/qemu/cpus.c:1354 #14 0x55668600 in tcg_exec_all () at /home/build/src/qemu/git/qemu/cpus.c:1387 #15 0x55667929 in qemu_tcg_cpu_thread_fn (arg=0x77fd7010) at /home/build/src/qemu/git/qemu/cpus.c:1032 #16 0x7264bb50 in start_thread (arg=optimized out) at pthread_create.c:304 #17 0x7239595d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #18 0x in ?? () (gdb) Any ideas? I can easily reproduce here if any further information is required. ATB, Mark.
[Qemu-devel] [PULL v2 4/5] Allow the use of X11 from a non standard location.
From: Jeremy White jwh...@codeweavers.com
Signed-off-by: Jeremy White jwh...@codeweavers.com
[ kraxel: solve opengl patch conflicts ]
Signed-off-by: Gerd Hoffmann kra...@redhat.com
Reviewed-by: Max Reitz mre...@redhat.com
---
configure| 24 +++-
hw/display/Makefile.objs | 1 +
2 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/configure b/configure
index ecd7893..fef9c95 100755
--- a/configure
+++ b/configure
@@ -2085,6 +2085,15 @@ if test $sparse != no ; then
fi
##
+# X11 probe
+x11_cflags=
+x11_libs=-lX11
+if $pkg_config --exists x11; then
+x11_cflags=`$pkg_config --cflags x11`
+x11_libs=`$pkg_config --libs x11`
+fi
+
+##
# GTK probe
if test $gtkabi = ; then
@@ -2111,7 +2120,8 @@ if test $gtk != no; then
gtk_cflags=`$pkg_config --cflags $gtkpackage`
gtk_libs=`$pkg_config --libs $gtkpackage`
if $pkg_config --exists $gtkx11package = $gtkversion; then
-gtk_libs=$gtk_libs -lX11
+gtk_cflags=$gtk_cflags $x11_cflags
+gtk_libs=$gtk_libs $x11_libs
fi
libs_softmmu=$gtk_libs $libs_softmmu
gtk=yes
@@ -2236,8 +2246,9 @@ if test $sdl = yes ; then
#endif
int main(void) { return 0; }
EOF
- if compile_prog $sdl_cflags $sdl_libs ; then
-sdl_libs=$sdl_libs -lX11
+ if compile_prog $sdl_cflags $x11_cflags $sdl_libs $x11_libs ; then
+sdl_cflags=$sdl_cflags $x11_cflags
+sdl_libs=$sdl_libs $x11_libs
fi
libs_softmmu=$sdl_libs $libs_softmmu
fi
@@ -3110,13 +3121,15 @@ libs_softmmu=$libs_softmmu $fdt_libs
# opengl probe (for sdl2, milkymist-tmu2)
if test $opengl != no ; then
opengl_pkgs=gl
- if $pkg_config $opengl_pkgs; then
-opengl_libs=$($pkg_config --libs $opengl_pkgs) -lX11
+ if $pkg_config $opengl_pkgs x11; then
+opengl_cflags=$($pkg_config --cflags $opengl_pkgs) $x11_cflags
+opengl_libs=$($pkg_config --libs $opengl_pkgs) $x11_libs
opengl=yes
else
if test $opengl = yes ; then
feature_not_found opengl Install GL devel (e.g. MESA)
fi
+opengl_cflags=
opengl_libs=
opengl=no
fi
@@ -4753,6 +4766,7 @@ fi
if test $opengl = yes ; then
echo CONFIG_OPENGL=y $config_host_mak
+ echo OPENGL_CFLAGS=$opengl_cflags $config_host_mak
echo OPENGL_LIBS=$opengl_libs $config_host_mak
fi
diff --git a/hw/display/Makefile.objs b/hw/display/Makefile.objs
index e18ea57..e73cb7d 100644
--- a/hw/display/Makefile.objs
+++ b/hw/display/Makefile.objs
@@ -20,6 +20,7 @@ common-obj-$(CONFIG_ZAURUS) += tc6393xb.o
ifeq ($(CONFIG_MILKYMIST_TMU2),y)
common-obj-y += milkymist-tmu2.o
+milkymist-tmu2.o-cflags := $(OPENGL_CFLAGS)
libs_softmmu += $(OPENGL_LIBS)
endif
--
1.8.3.1
[Qemu-devel] [PULL 2/7] vnc: remove dead code
If vs-ws_enabled is set ws_display is non-NULL.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
Reviewed-by: Gonglei arei.gong...@huawei.com
---
ui/vnc.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/ui/vnc.c b/ui/vnc.c
index 65ba1c0..bac44ce 100644
--- a/ui/vnc.c
+++ b/ui/vnc.c
@@ -3627,13 +3627,8 @@ void vnc_display_open(const char *id, Error **errp)
}
#ifdef CONFIG_VNC_WS
if (vs-ws_enabled) {
-if (ws_display) {
-vs-lwebsock = inet_listen(ws_display, NULL, 0,
-SOCK_STREAM, 0, errp);
-} else {
-vs-lwebsock = inet_listen(display, NULL, 0,
-SOCK_STREAM, 5700, errp);
-}
+vs-lwebsock = inet_listen(ws_display, NULL, 0,
+ SOCK_STREAM, 0, errp);
if (vs-lwebsock 0) {
if (vs-lsock) {
close(vs-lsock);
--
1.8.3.1
[Qemu-devel] [PULL 6/7] vnc: avoid possible file handler leak
From: Gonglei arei.gong...@huawei.com
vs-lsock may equal to 0, modify the check condition,
avoid possible vs-lsock leak.
Signed-off-by: Gonglei arei.gong...@huawei.com
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
ui/vnc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ui/vnc.c b/ui/vnc.c
index b514777..1e95445 100644
--- a/ui/vnc.c
+++ b/ui/vnc.c
@@ -3644,7 +3644,7 @@ void vnc_display_open(const char *id, Error **errp)
if (vs-ws_enabled) {
vs-lwebsock = inet_listen_opts(wsopts, 0, errp);
if (vs-lwebsock 0) {
-if (vs-lsock) {
+if (vs-lsock != -1) {
close(vs-lsock);
vs-lsock = -1;
}
--
1.8.3.1
[Qemu-devel] [PULL 7/7] vnc: fix segmentation fault when invalid vnc parameters are specified
From: Gonglei arei.gong...@huawei.com
Reproducer:
#./qemu-system-x86_64 -vnc :0,ip
qemu-system-x86_64: -vnc :1,ip: Invalid parameter 'ip'
Segmentation fault (core dumped)
Signed-off-by: Gonglei arei.gong...@huawei.com
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
ui/vnc.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/ui/vnc.c b/ui/vnc.c
index 1e95445..6f9b718 100644
--- a/ui/vnc.c
+++ b/ui/vnc.c
@@ -3703,8 +3703,13 @@ QemuOpts *vnc_parse_func(const char *str)
{
QemuOptsList *olist = qemu_find_opts(vnc);
QemuOpts *opts = qemu_opts_parse(olist, str, 1);
-const char *id = qemu_opts_id(opts);
+const char *id;
+if (!opts) {
+return NULL;
+}
+
+id = qemu_opts_id(opts);
if (!id) {
/* auto-assign id if not present */
vnc_auto_assign_id(olist, opts);
--
1.8.3.1
[Qemu-devel] [PULL v2 5/5] pixman: add a bunch of PIXMAN_BE_* defines for 32bpp
Signed-off-by: Gerd Hoffmann kra...@redhat.com Reviewed-by: Max Reitz mre...@redhat.com --- include/ui/qemu-pixman.h | 16 1 file changed, 16 insertions(+) diff --git a/include/ui/qemu-pixman.h b/include/ui/qemu-pixman.h index 3dee576..5d7a9ac 100644 --- a/include/ui/qemu-pixman.h +++ b/include/ui/qemu-pixman.h @@ -27,8 +27,24 @@ #ifdef HOST_WORDS_BIGENDIAN # define PIXMAN_BE_r8g8b8 PIXMAN_r8g8b8 +# define PIXMAN_BE_x8r8g8b8 PIXMAN_x8r8g8b8 +# define PIXMAN_BE_a8r8g8b8 PIXMAN_a8r8g8b8 +# define PIXMAN_BE_b8g8r8x8 PIXMAN_b8g8r8x8 +# define PIXMAN_BE_b8g8r8a8 PIXMAN_b8g8r8a8 +# define PIXMAN_BE_r8g8b8x8 PIXMAN_r8g8b8x8 +# define PIXMAN_BE_r8g8b8a8 PIXMAN_r8g8b8a8 +# define PIXMAN_BE_x8b8g8r8 PIXMAN_x8b8g8r8 +# define PIXMAN_BE_a8b8g8r8 PIXMAN_a8b8g8r8 #else # define PIXMAN_BE_r8g8b8 PIXMAN_b8g8r8 +# define PIXMAN_BE_x8r8g8b8 PIXMAN_b8g8r8x8 +# define PIXMAN_BE_a8r8g8b8 PIXMAN_b8g8r8a8 +# define PIXMAN_BE_b8g8r8x8 PIXMAN_x8r8g8b8 +# define PIXMAN_BE_b8g8r8a8 PIXMAN_a8r8g8b8 +# define PIXMAN_BE_r8g8b8x8 PIXMAN_x8b8g8r8 +# define PIXMAN_BE_r8g8b8a8 PIXMAN_a8b8g8r8 +# define PIXMAN_BE_x8b8g8r8 PIXMAN_r8g8b8x8 +# define PIXMAN_BE_a8b8g8r8 PIXMAN_r8g8b8a8 #endif /* */ -- 1.8.3.1
Re: [Qemu-devel] [PATCH v2] hmp: add info iothreads command
On 2015-3-12 17:05, Fam Zheng wrote:
On Thu, 03/12 16:35, Ting Wang wrote:
Make info iothreads available on the HMP monitor.
The results are as follows:
id1: thread_id1
id2: thread_id2
Does this match the actual output format? I think you're missing a =.
Oh, sorry. I will fix it.
Ting
Signed-off-by: Ting Wang kathy.wangt...@huawei.com
---
v2: add braces for if
---
hmp-commands.hx | 2 ++
hmp.c | 22 ++
hmp.h | 1 +
monitor.c | 7 +++
4 files changed, 32 insertions(+)
diff --git a/hmp-commands.hx b/hmp-commands.hx
index d5022d8..67d76ed 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -1746,6 +1746,8 @@ show roms
show the TPM device
@item info memory-devices
show the memory devices
+@item info iothreads
+show iothreads
@end table
ETEXI
diff --git a/hmp.c b/hmp.c
index 71c28bc..e87cb14 100644
--- a/hmp.c
+++ b/hmp.c
@@ -821,6 +821,28 @@ void hmp_info_tpm(Monitor *mon, const QDict *qdict)
qapi_free_TPMInfoList(info_list);
}
+void hmp_info_iothreads(Monitor *mon, const QDict *qdict)
+{
+IOThreadInfoList *head = NULL, *elem = NULL;
+
+head = qmp_query_iothreads(NULL);
+if (!head) {
+monitor_printf(mon, No iothread has been added\n);
+return;
+}
+
+elem = head;
+while (elem) {
+if (elem-value) {
+monitor_printf(mon, %s: thread_id=%ld\n, elem-value-id,
Please remove the trailing whitespace. You can use scripts/checkpatch.pl to
catch the coding style issues your self.
You should also add documentation in hmp-commands.hx.
Fam
+elem-value-thread_id);
+}
+elem = elem-next;
+}
+
+qapi_free_IOThreadInfoList(head);
+}
+
void hmp_quit(Monitor *mon, const QDict *qdict)
{
monitor_suspend(mon);
diff --git a/hmp.h b/hmp.h
index 81177b2..d99090e 100644
--- a/hmp.h
+++ b/hmp.h
@@ -38,6 +38,7 @@ void hmp_info_balloon(Monitor *mon, const QDict *qdict);
void hmp_info_pci(Monitor *mon, const QDict *qdict);
void hmp_info_block_jobs(Monitor *mon, const QDict *qdict);
void hmp_info_tpm(Monitor *mon, const QDict *qdict);
+void hmp_info_iothreads(Monitor *mon, const QDict *qdict);
void hmp_quit(Monitor *mon, const QDict *qdict);
void hmp_stop(Monitor *mon, const QDict *qdict);
void hmp_system_reset(Monitor *mon, const QDict *qdict);
diff --git a/monitor.c b/monitor.c
index c86a89e..076a306 100644
--- a/monitor.c
+++ b/monitor.c
@@ -2924,6 +2924,13 @@ static mon_cmd_t info_cmds[] = {
.mhandler.cmd = hmp_info_memory_devices,
},
{
+.name = iothreads,
+.args_type = ,
+.params = ,
+.help = show iothreads,
+.mhandler.cmd = hmp_info_iothreads,
+},
+{
.name = NULL,
},
};
--
1.8.5
.
Re: [Qemu-devel] [PATCH v2 14/17] block: Resize bitmaps on bdrv_truncate
On 03/11/2015 12:18 PM, Stefan Hajnoczi wrote:
On Mon, Mar 02, 2015 at 06:20:00PM -0500, John Snow wrote:
+static void dirty_bitmap_truncate(BdrvDirtyBitmap *bitmap, uint64_t size)
+{
+/* Should only be frozen during a block backup job, which should have
+ * blocked any resize actions. */
+assert(!bdrv_dirty_bitmap_frozen(bitmap));
+hbitmap_truncate(bitmap-bitmap, size);
+}
+
+void bdrv_dirty_bitmap_truncate(BlockDriverState *bs)
+{
+BdrvDirtyBitmap *bitmap;
+uint64_t size = bdrv_nb_sectors(bs);
+
+QLIST_FOREACH(bitmap, bs-dirty_bitmaps, list) {
+if (bdrv_dirty_bitmap_frozen(bitmap)) {
+continue;
+}
+dirty_bitmap_truncate(bitmap, size);
If you inline this function here then the discussion about assert() vs
skipping frozen bitmaps goes away. Why is dirty_bitmap_truncate() a
function?
Symmetry with other bitmap functions.
+}
+}
Why is bdrv_dirty_bitmap_truncate() a public API? I expected this code
to be inline or called as a static function by bdrv_truncate().
OK, fixing that.
/**
+ * hbitmap_truncate:
+ * @hb: The bitmap to change the size of.
+ * @size: The number of elements to change the bitmap to accommodate.
+ *
+ * truncate or grow an existing bitmap to accommodate a new number of elements.
+ * This may invalidate existing HBitmapIterators.
+ */
+void hbitmap_truncate(HBitmap *hb, uint64_t size);
Please include a tests/test-hbitmap.c test case.
Interesting cases:
1. New size equals old size (odd but possible)
2. Growing less than sizeof(unsigned long)
3. Growing more than sizeof(unsigned long)
4. Shrinking less than sizeof(unsigned long)
5. Shrinking more than sizeof(unsigned long)
;_; OK, you're right...
+void hbitmap_truncate(HBitmap *hb, uint64_t size)
+{
+bool truncate;
+unsigned i;
+uint64_t num_elements = size;
+uint64_t old;
+
+/* Size comes in as logical elements, adjust for granularity. */
+size = (size + (1ULL hb-granularity) - 1) hb-granularity;
+assert(size = ((uint64_t)1 HBITMAP_LOG_MAX_SIZE));
+truncate = size hb-size;
Here truncate means shrink.
shrink is a clearer name since the function name is already truncate
but that concept includes both increasing or decreasing size.
Yes, fair enough. Was relying on what I consider the colloquial
definition of truncate.
+
+if (size == hb-size) {
+/* A hard day's work */
+return;
+}
+
+hb-size = size;
+for (i = HBITMAP_LEVELS; i-- 0; ) {
+size = MAX((size + BITS_PER_LONG - 1) BITS_PER_LEVEL, 1);
+if (hb-sizes[i] == size) {
+continue;
+}
+old = hb-sizes[i];
+hb-sizes[i] = size;
I was wondering what sizes[] is used for. Not a very useful struct
field since it's only needed by this rarely called function.
In future patches, we tend to recalculate the size of each array a lot.
I decided I wanted to cache it so we could stop duplicating that code
over and over.
It comes up in migration and persistence a lot. It's easier to just add
it now instead of allow the duplication to sneak in and then patch it
out everywhere.
It would be clearer to calculate 'old' alongside 'size' each loop
iteration. The size[] field can be dropped, 'old' becomes 'old_size',
and 'size' becomes 'new_size':
old_size = hb-size;
for (i = HBITMAP_LEVELS; i-- 0; ) {
old_size = MAX((old_size + BITS_PER_LONG - 1) BITS_PER_LEVEL, 1);
new_size = MAX((new_size + BITS_PER_LONG - 1) BITS_PER_LEVEL, 1);
+hb-levels[i] = g_realloc_n(hb-levels[i], size, sizeof(unsigned
long));
+if (!truncate) {
+memset(hb-levels[i][old], 0x00,
+ (size - old) * sizeof(*hb-levels[i]));
+}
+}
+assert(size == 1);
+
+/* Clear out any extra space we may have that the user didn't request:
+ * It may have garbage data in it, now. */
+if (truncate) {
+/* Due to granularity fuzziness, we may accidentally reset some of
+ * the last bits that are actually valid. So, record the current value,
+ * reset the dead range, then re-set the one element we care about.
*/
+uint64_t fix_count = (hb-size hb-granularity) - num_elements;
+if (fix_count) {
+bool set = hbitmap_get(hb, num_elements - 1);
+hbitmap_reset(hb, num_elements, fix_count);
+if (set) {
+hbitmap_set(hb, num_elements - 1, 1);
+}
+}
Calling hbitmap_reset() with an out-of-bounds index seems hacky to me.
It's the simplest way to re-use the existing code to recursively clear
out any bits that are set that shouldn't be.
Why doesn't the for loop's if (!truncate) have an else statement to mask
no longer visible bits? Maybe I'm missing why that's hard to do.
I just didn't see a reason to replicate the logic of what hbitmap_reset
already does, so I didn't bother to try.
[Qemu-devel] [PULL 0/7] vnc patch queue.
Hi, Some vnc cleanups, more QemuOpts conversion fallout fixes. please pull, Gerd The following changes since commit 9159eb9abc31e02797dc55998e71f12c06846d55: Merge remote-tracking branch 'remotes/amit/tags/vser-for-2.3-1' into staging (2015-03-11 14:27:13 +) are available in the git repository at: git://git.kraxel.org/qemu tags/pull-vnc-20150312-1 for you to fetch changes up to 81607cbfa433272d1f09bd0f0ae6c3b14f818972: vnc: fix segmentation fault when invalid vnc parameters are specified (2015-03-12 09:09:10 +0100) vnc: bugfixes and cleanups. Daniel P. Berrange (1): ui: fix regression in x509verify parameter for VNC server Gerd Hoffmann (3): vnc: drop display+ws_display from VncDisplay vnc: remove dead code vnc: switch to inet_listen_opts Gonglei (3): ui/console: fix OVERFLOW_BEFORE_WIDEN vnc: avoid possible file handler leak vnc: fix segmentation fault when invalid vnc parameters are specified ui/console.c | 4 +- ui/vnc-auth-sasl.c | 2 +- ui/vnc.c | 128 +++-- ui/vnc.h | 6 +-- 4 files changed, 72 insertions(+), 68 deletions(-)
Re: [Qemu-devel] [PATCH v5 17/45] Add wrappers and handlers for sending/receiving the postcopy-ram migration messages.
On Wed, Feb 25, 2015 at 04:51:40PM +, Dr. David Alan Gilbert (git) wrote:
From: Dr. David Alan Gilbert dgilb...@redhat.com
The state of the postcopy process is managed via a series of messages;
* Add wrappers and handlers for sending/receiving these messages
* Add state variable that track the current state of postcopy
Signed-off-by: Dr. David Alan Gilbert dgilb...@redhat.com
---
include/migration/migration.h | 15 ++
include/sysemu/sysemu.h | 23 +++
migration/migration.c | 13 ++
savevm.c | 325
++
trace-events | 11 ++
5 files changed, 387 insertions(+)
diff --git a/include/migration/migration.h b/include/migration/migration.h
index f94af5b..81cd1f2 100644
--- a/include/migration/migration.h
+++ b/include/migration/migration.h
@@ -52,6 +52,14 @@ typedef struct MigrationState MigrationState;
typedef QLIST_HEAD(, LoadStateEntry) LoadStateEntry_Head;
+typedef enum {
+POSTCOPY_INCOMING_NONE = 0, /* Initial state - no postcopy */
+POSTCOPY_INCOMING_ADVISE,
+POSTCOPY_INCOMING_LISTENING,
+POSTCOPY_INCOMING_RUNNING,
+POSTCOPY_INCOMING_END
+} PostcopyState;
+
/* State for the incoming migration */
struct MigrationIncomingState {
QEMUFile *file;
@@ -59,6 +67,8 @@ struct MigrationIncomingState {
/* See savevm.c */
LoadStateEntry_Head loadvm_handlers;
+PostcopyState postcopy_state;
+
QEMUFile *return_path;
QemuMutex rp_mutex;/* We send replies from multiple threads */
};
@@ -219,4 +229,9 @@ size_t ram_control_save_page(QEMUFile *f, ram_addr_t
block_offset,
ram_addr_t offset, size_t size,
int *bytes_sent);
+PostcopyState postcopy_state_get(MigrationIncomingState *mis);
+
+/* Set the state and return the old state */
+PostcopyState postcopy_state_set(MigrationIncomingState *mis,
+ PostcopyState new_state);
#endif
diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index 8da879f..d6a6d51 100644
--- a/include/sysemu/sysemu.h
+++ b/include/sysemu/sysemu.h
@@ -87,6 +87,18 @@ enum qemu_vm_cmd {
MIG_CMD_INVALID = 0, /* Must be 0 */
MIG_CMD_OPEN_RETURN_PATH, /* Tell the dest to open the Return path */
MIG_CMD_PING, /* Request a PONG on the RP */
+
+MIG_CMD_POSTCOPY_ADVISE = 20, /* Prior to any page transfers, just
+ warn we might want to do PC */
+MIG_CMD_POSTCOPY_LISTEN, /* Start listening for incoming
+ pages as it's running. */
+MIG_CMD_POSTCOPY_RUN, /* Start execution */
+MIG_CMD_POSTCOPY_END, /* Postcopy is finished. */
+
+MIG_CMD_POSTCOPY_RAM_DISCARD, /* A list of pages to discard that
+ were previously sent during
+ precopy but are dirty. */
+
};
bool qemu_savevm_state_blocked(Error **errp);
@@ -101,6 +113,17 @@ void qemu_savevm_command_send(QEMUFile *f, enum
qemu_vm_cmd command,
uint16_t len, uint8_t *data);
void qemu_savevm_send_ping(QEMUFile *f, uint32_t value);
void qemu_savevm_send_open_return_path(QEMUFile *f);
+void qemu_savevm_send_postcopy_advise(QEMUFile *f);
+void qemu_savevm_send_postcopy_listen(QEMUFile *f);
+void qemu_savevm_send_postcopy_run(QEMUFile *f);
+void qemu_savevm_send_postcopy_end(QEMUFile *f, uint8_t status);
+
+void qemu_savevm_send_postcopy_ram_discard(QEMUFile *f, const char *name,
+ uint16_t len, uint8_t offset,
+ uint64_t *addrlist,
+ uint32_t *masklist);
+
+
int qemu_loadvm_state(QEMUFile *f);
/* SLIRP */
diff --git a/migration/migration.c b/migration/migration.c
index 434864a..957115a 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -971,3 +971,16 @@ void migrate_fd_connect(MigrationState *s)
qemu_thread_create(s-thread, migration, migration_thread, s,
QEMU_THREAD_JOINABLE);
}
+
+PostcopyState postcopy_state_get(MigrationIncomingState *mis)
+{
+return atomic_fetch_add(mis-postcopy_state, 0);
+}
+
+/* Set the state and return the old state */
+PostcopyState postcopy_state_set(MigrationIncomingState *mis,
+ PostcopyState new_state)
+{
+return atomic_xchg(mis-postcopy_state, new_state);
Is there anything explaining what the overall atomicity requirements
are for this state variable? It's a bit hard to tell if an atomic
xchg is necessary or sufficient without a description of what the
overall concurrency scheme is with regards to this variable.
+}
+
diff --git a/savevm.c b/savevm.c
index 4b619da..e31ccb0
Re: [Qemu-devel] [PATCH v5 16/45] Add migration-capability boolean for postcopy-ram.
On Wed, Feb 25, 2015 at 04:51:39PM +, Dr. David Alan Gilbert (git) wrote:
From: Dr. David Alan Gilbert dgilb...@redhat.com
This absolutely needs a commit message. I shouldn't have to look at
the code to find out what the presence of this capability asserts, and
from where to where it's communicating that information.
Signed-off-by: Dr. David Alan Gilbert dgilb...@redhat.com
Reviewed-by: Eric Blake ebl...@redhat.com
---
include/migration/migration.h | 1 +
migration/migration.c | 9 +
qapi-schema.json | 7 ++-
3 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/include/migration/migration.h b/include/migration/migration.h
index 751caa0..f94af5b 100644
--- a/include/migration/migration.h
+++ b/include/migration/migration.h
@@ -177,6 +177,7 @@ void migrate_add_blocker(Error *reason);
*/
void migrate_del_blocker(Error *reason);
+bool migrate_postcopy_ram(void);
bool migrate_rdma_pin_all(void);
bool migrate_zero_blocks(void);
diff --git a/migration/migration.c b/migration/migration.c
index 4592060..434864a 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -663,6 +663,15 @@ bool migrate_rdma_pin_all(void)
return s-enabled_capabilities[MIGRATION_CAPABILITY_RDMA_PIN_ALL];
}
+bool migrate_postcopy_ram(void)
+{
+MigrationState *s;
+
+s = migrate_get_current();
+
+return s-enabled_capabilities[MIGRATION_CAPABILITY_X_POSTCOPY_RAM];
As an asside, I'm assuming you'll get rid of these x- prefixes
before you post a series intended for final inclusion?
+}
+
bool migrate_auto_converge(void)
{
MigrationState *s;
diff --git a/qapi-schema.json b/qapi-schema.json
index e16f8eb..a8af1cb 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -494,10 +494,15 @@
# @auto-converge: If enabled, QEMU will automatically throttle down the guest
# to speed up convergence of RAM migration. (since 1.6)
#
+# @x-postcopy-ram: Start executing on the migration target before all of RAM
has
+# been migrated, pulling the remaining pages along as needed. NOTE:
If
+# the migration fails during postcopy the VM will fail. (since 2.3)
+#
# Since: 1.2
##
{ 'enum': 'MigrationCapability',
- 'data': ['xbzrle', 'rdma-pin-all', 'auto-converge', 'zero-blocks'] }
+ 'data': ['xbzrle', 'rdma-pin-all', 'auto-converge', 'zero-blocks',
+ 'x-postcopy-ram'] }
##
# @MigrationCapabilityStatus
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
pgpRh1iYN58Wj.pgp
Description: PGP signature
Re: [Qemu-devel] [PATCH v5 15/45] Rework loadvm path for subloops
On Wed, Feb 25, 2015 at 04:51:38PM +, Dr. David Alan Gilbert (git) wrote:
From: Dr. David Alan Gilbert dgilb...@redhat.com
Postcopy needs to have two migration streams loading concurrently;
one from memory (with the device state) and the other from the fd
with the memory transactions.
Split the core of qemu_loadvm_state out so we can use it for both.
Allow the inner loadvm loop to quit and signal whether the parent
should.
Signed-off-by: Dr. David Alan Gilbert dgilb...@redhat.com
---
savevm.c | 106
---
trace-events | 4 +++
2 files changed, 69 insertions(+), 41 deletions(-)
diff --git a/savevm.c b/savevm.c
index f42713d..4b619da 100644
--- a/savevm.c
+++ b/savevm.c
@@ -951,6 +951,16 @@ static SaveStateEntry *find_se(const char *idstr, int
instance_id)
return NULL;
}
+/* ORable flags that control the (potentially nested) loadvm_state loops */
+enum LoadVMExitCodes {
+/* Quit the loop level that received this command */
+LOADVM_QUIT_LOOP = 1,
+/* Quit this loop and our parent */
+LOADVM_QUIT_PARENT = 2,
+};
The semantics of all the exit code stuff is doing my head in; I'm not
sure how to make it more comprehensible.
+static int qemu_loadvm_state_main(QEMUFile *f, MigrationIncomingState *mis);
+
static int loadvm_process_command_simple_lencheck(const char *name,
unsigned int actual,
unsigned int expected)
@@ -967,6 +977,8 @@ static int loadvm_process_command_simple_lencheck(const
char *name,
/*
* Process an incoming 'QEMU_VM_COMMAND'
* negative return on error (will issue error message)
+ * 0 just a normal return
+ * 1 All good, but exit the loop
This should probably also mention the possibility of negative returns
for errors.
Am I correct in thinking that at this point the function never returns
1? I'm assuming later patches in the series change that.
Maybe I'm missing something in my mental model here, but tying the
duration of the containing loop to execution of specific commands
seems problematic. What's the circumstance in which it makes sense
for a command to indicate that the rest of the packaged data should be
essentially ignored
*/
static int loadvm_process_command(QEMUFile *f)
{
@@ -1036,36 +1048,13 @@ void loadvm_free_handlers(MigrationIncomingState *mis)
}
}
-int qemu_loadvm_state(QEMUFile *f)
+static int qemu_loadvm_state_main(QEMUFile *f, MigrationIncomingState *mis)
{
-MigrationIncomingState *mis = migration_incoming_get_current();
-Error *local_err = NULL;
uint8_t section_type;
-unsigned int v;
int ret;
+int exitcode = 0;
-if (qemu_savevm_state_blocked(local_err)) {
-error_report(%s, error_get_pretty(local_err));
-error_free(local_err);
-return -EINVAL;
-}
-
-v = qemu_get_be32(f);
-if (v != QEMU_VM_FILE_MAGIC) {
-error_report(Not a migration stream);
-return -EINVAL;
-}
-
-v = qemu_get_be32(f);
-if (v == QEMU_VM_FILE_VERSION_COMPAT) {
-error_report(SaveVM v2 format is obsolete and don't work anymore);
-return -ENOTSUP;
-}
-if (v != QEMU_VM_FILE_VERSION) {
-error_report(Unsupported migration stream version);
-return -ENOTSUP;
-}
-
+trace_qemu_loadvm_state_main();
while ((section_type = qemu_get_byte(f)) != QEMU_VM_EOF) {
uint32_t instance_id, version_id, section_id;
SaveStateEntry *se;
@@ -1093,16 +1082,14 @@ int qemu_loadvm_state(QEMUFile *f)
if (se == NULL) {
error_report(Unknown savevm section or instance '%s' %d,
idstr, instance_id);
-ret = -EINVAL;
-goto out;
+return -EINVAL;
}
/* Validate version */
if (version_id se-version_id) {
error_report(savevm: unsupported version %d for '%s' v%d,
version_id, idstr, se-version_id);
-ret = -EINVAL;
-goto out;
+return -EINVAL;
}
/* Add entry */
@@ -1117,7 +1104,7 @@ int qemu_loadvm_state(QEMUFile *f)
if (ret 0) {
error_report(error while loading state for instance 0x%x of
device '%s', instance_id, idstr);
-goto out;
+return ret;
}
break;
case QEMU_VM_SECTION_PART:
@@ -1132,36 +1119,73 @@ int qemu_loadvm_state(QEMUFile *f)
}
if (le == NULL) {
error_report(Unknown savevm section %d, section_id);
-ret = -EINVAL;
-goto out;
+return -EINVAL;
Re: [Qemu-devel] [PATCH 2/2 RFC] s390x/pci: rework pci infrastructure modeling
On Wed, Mar 11, 2015 at 03:57:05PM +0100, Michael S. Tsirkin wrote: On Wed, Mar 11, 2015 at 03:38:44PM +0100, Frank Blaschka wrote: I like Alex's idea because: 1) It reflects pretty well the actual nature of the pci system in real s390 hw why do you say this? does real hw has this one device per bridge limit? Actually we don't know. HW does not expose this information. All we know is each pci function is completely separated. So it is a good assumption to have a separate bridge/bus for each pci function. By the way the Linux kernel for s390 makes the same assumption by creating a new pci domain for each function. You may want to read the cover letter again to get more technical details on this.
Re: [Qemu-devel] [PATCH 0/1] Get the list of arguments from a QMP command
On Wed, Mar 11, 2015 at 11:21:43AM +0100, Markus Armbruster wrote: I can actually try to implement full introspection support, but I would like to know what API you would like. Something like this? 'query-commands' 'query-enums' 'query-events' 'query-types' 'query-unions' You propose a separate query-FOO for each kind of thing in the schema: command, event, the various types. Not fundamentally different to a single query-schema. We can discuss which of the two approaches is easier to use. I don't think it makes much difference in terms of complexity from the QEMU side. I proposed those because query-commands and query-events already exist, so adding the missing ones seemed the most straightforward solution to me. But if query-schema is more convenient I don't have any problem with that. Here's how I'd try to do that. Treat the schema as a graph, its nodes are the definitions of types, commands and events are nodes, and a use of a type adds an edge from the node containing the use to the type. The external interface is exactly the sub-graph reachable QMP command and event nodes. Makes sense. Berto
Re: [Qemu-devel] [Qemu-Dev-QUERY] Related to Live Migration source Code or API for NUMA Node specific
Hi Team, Can anyone please provide their point of views related to my below query. Thanks Regards Arkajit Ghosh -Arkajit Ghosh/DEL/TCS wrote: - To: qemu-devel@nongnu.org From: Arkajit Ghosh/DEL/TCS Date: 03/12/2015 09:59AM Subject: Re: [Qemu-Dev-QUERY] Related to Live Migration source Code or API for NUMA Node specific Hi Team, Can anyone please provide their point of views related to my below query. Thanks Regards Arkajit Ghosh -Arkajit Ghosh/DEL/TCS wrote: - To: qemu-devel@nongnu.org From: Arkajit Ghosh/DEL/TCS Date: 03/11/2015 09:49PM Subject: Re: [Qemu-Dev] Related to Live Migration source Code or API for NUMA Node specific Hi, Can anyone please provide their point of views related to my below query. Thanks Regards Arkajit Ghosh -Arkajit Ghosh/DEL/TCS wrote: - To: qemu-devel@nongnu.org From: Arkajit Ghosh/DEL/TCS Date: 03/11/2015 05:03PM Cc: Arkajit Ghosh/DEL/TCS@TCS Subject: [Qemu-Dev] Related to Live Migration source Code or API for NUMA Node specific Hi Team, I was went through Live Migration source code in Qemu. I didn't find any specific API for NUMA which can able to copy the dirty pages for Local and Remote memory corresponding to individual CPU core. As I understood, in NUMA aware Intel CPU Processor has one Local memory which is attached to dedicated CPU core (individual) and also can able to access remote memory. So during Live migration, dirty pages can be created in local memory and as well as can create in remote memory also. My query is, is there any source code or API exposed in Qemu which can able to access that offset addresses of Local memory and Remote memory and then able to copy the dirty pages? If yes can you please let me know how it will work? If No then I need to think different approaches. Please let me know if my query is not clear to you. I hope this is the right place to put this query. Thanks Regards Arkajit Ghosh =-=-= Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you
[Qemu-devel] [PULL 1/7] vnc: drop display+ws_display from VncDisplay
Nobody cares about those strings, they are only used to check whenever
the vnc server / websocket support is enabled or not. Add bools for
this and drop the strings.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
Reviewed-by: Gonglei arei.gong...@huawei.com
---
ui/vnc-auth-sasl.c | 2 +-
ui/vnc.c | 54 +++---
ui/vnc.h | 6 +++---
3 files changed, 27 insertions(+), 35 deletions(-)
diff --git a/ui/vnc-auth-sasl.c b/ui/vnc-auth-sasl.c
index f3ad75d..2ddd259 100644
--- a/ui/vnc-auth-sasl.c
+++ b/ui/vnc-auth-sasl.c
@@ -555,7 +555,7 @@ void start_auth_sasl(VncState *vs)
memset (secprops, 0, sizeof secprops);
/* Inform SASL that we've got an external SSF layer from TLS */
-if (strncmp(vs-vd-display, unix:, 5) == 0
+if (vs-vd-is_unix
#ifdef CONFIG_VNC_TLS
/* Disable SSF, if using TLS+x509+SASL only. TLS without x509
is not sufficiently strong */
diff --git a/ui/vnc.c b/ui/vnc.c
index ff0b5bd..65ba1c0 100644
--- a/ui/vnc.c
+++ b/ui/vnc.c
@@ -407,7 +407,7 @@ VncInfo *qmp_query_vnc(Error **errp)
VncInfo *info = g_malloc0(sizeof(*info));
VncDisplay *vd = vnc_display_find(NULL);
-if (vd == NULL || vd-display == NULL) {
+if (vd == NULL || !vd-enabled) {
info-enabled = false;
} else {
struct sockaddr_storage sa;
@@ -3190,16 +3190,15 @@ static void vnc_display_close(VncDisplay *vs)
{
if (!vs)
return;
-g_free(vs-display);
-vs-display = NULL;
+vs-enabled = false;
+vs-is_unix = false;
if (vs-lsock != -1) {
qemu_set_fd_handler2(vs-lsock, NULL, NULL, NULL, NULL);
close(vs-lsock);
vs-lsock = -1;
}
#ifdef CONFIG_VNC_WS
-g_free(vs-ws_display);
-vs-ws_display = NULL;
+vs-ws_enabled = false;
if (vs-lwebsock != -1) {
qemu_set_fd_handler2(vs-lwebsock, NULL, NULL, NULL, NULL);
close(vs-lwebsock);
@@ -3329,7 +3328,7 @@ void vnc_display_open(const char *id, Error **errp)
bool reverse = false;
const char *vnc;
const char *has_to;
-char *display, *to = NULL;
+char *display, *ws_display = NULL, *to = NULL;
bool has_ipv4 = false;
bool has_ipv6 = false;
#ifdef CONFIG_VNC_WS
@@ -3369,10 +3368,9 @@ void vnc_display_open(const char *id, Error **errp)
has_ipv4 = qemu_opt_get_bool(opts, ipv4, false);
has_ipv6 = qemu_opt_get_bool(opts, ipv6, false);
display = g_strdup_printf(%s%s%s%s, vnc,
- has_to ? to : ,
- has_ipv4 ? ,ipv4 : ,
- has_ipv6 ? ,ipv6 : );
-vs-display = g_strdup(display);
+ has_to ? to : ,
+ has_ipv4 ? ,ipv4 : ,
+ has_ipv6 ? ,ipv6 : );
password = qemu_opt_get_bool(opts, password, false);
if (password fips_get_state()) {
@@ -3427,7 +3425,7 @@ void vnc_display_open(const char *id, Error **errp)
if (websocket) {
/* extract the host specification from display */
char *host = NULL, *host_end = NULL;
-vs-websocket = 1;
+vs-ws_enabled = true;
/* ipv6 hosts have colons */
host_end = strrchr(display, ':');
@@ -3436,7 +3434,7 @@ void vnc_display_open(const char *id, Error **errp)
} else {
host = g_strdup(:);
}
-vs-ws_display = g_strconcat(host, websocket, NULL);
+ws_display = g_strconcat(host, websocket, NULL);
g_free(host);
}
#endif /* CONFIG_VNC_WS */
@@ -3618,34 +3616,29 @@ void vnc_display_open(const char *id, Error **errp)
vnc_connect(vs, csock, false, false);
} else {
/* listen for connects */
-char *dpy;
-dpy = g_malloc(256);
if (strncmp(display, unix:, 5) == 0) {
-pstrcpy(dpy, 256, unix:);
-vs-lsock = unix_listen(display+5, dpy+5, 256-5, errp);
+vs-lsock = unix_listen(display+5, NULL, 0, errp);
+vs-is_unix = true;
} else {
-vs-lsock = inet_listen(display, dpy, 256,
+vs-lsock = inet_listen(display, NULL, 0,
SOCK_STREAM, 5900, errp);
if (vs-lsock 0) {
-g_free(dpy);
goto fail;
}
#ifdef CONFIG_VNC_WS
-if (vs-websocket) {
-if (vs-ws_display) {
-vs-lwebsock = inet_listen(vs-ws_display, NULL, 256,
+if (vs-ws_enabled) {
+if (ws_display) {
+vs-lwebsock = inet_listen(ws_display, NULL, 0,
SOCK_STREAM, 0, errp);
} else {
-vs-lwebsock = inet_listen(vs-display, NULL, 256,
+vs-lwebsock = inet_listen(display, NULL, 0,
SOCK_STREAM, 5700, errp);
}
-
if (vs-lwebsock 0) {
Re: [Qemu-devel] [PULLv2] s390x/kvm: Features and fixes for 2.3
On 11 March 2015 at 10:21, Christian Borntraeger borntrae...@de.ibm.com wrote: Peter, here is the 2nd version (only one patch changed) that hopefully compiles fine on 32 bit hosts. I only added that patch as followup mail. Applied, thanks. -- PMM
[Qemu-devel] [PULL 5/7] ui/console: fix OVERFLOW_BEFORE_WIDEN
From: Gonglei arei.gong...@huawei.com
Signed-off-by: Gonglei arei.gong...@huawei.com
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
ui/console.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/ui/console.c b/ui/console.c
index 87af6b5..b15ca87 100644
--- a/ui/console.c
+++ b/ui/console.c
@@ -1285,9 +1285,9 @@ DisplaySurface *qemu_create_displaysurface_guestmem(int
width, int height,
linesize = width * PIXMAN_FORMAT_BPP(format) / 8;
}
-size = linesize * height;
+size = (hwaddr)linesize * height;
data = cpu_physical_memory_map(addr, size, 0);
-if (size != linesize * height) {
+if (size != (hwaddr)linesize * height) {
cpu_physical_memory_unmap(data, size, 0, 0);
return NULL;
}
--
1.8.3.1
[Qemu-devel] [PULL 3/7] vnc: switch to inet_listen_opts
Use inet_listen_opts instead of inet_listen. Allows us to drop some
pointless indirection: Format strings just to parse them again later on.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
Tested-by: Gonglei arei.gong...@huawei.com
Reviewed-by: Gonglei arei.gong...@huawei.com
---
ui/vnc.c | 75 +++-
1 file changed, 41 insertions(+), 34 deletions(-)
diff --git a/ui/vnc.c b/ui/vnc.c
index bac44ce..db8409b 100644
--- a/ui/vnc.c
+++ b/ui/vnc.c
@@ -3322,13 +3322,14 @@ void vnc_display_open(const char *id, Error **errp)
{
VncDisplay *vs = vnc_display_find(id);
QemuOpts *opts = qemu_opts_find(qemu_vnc_opts, id);
+QemuOpts *sopts, *wsopts;
const char *share, *device_id;
QemuConsole *con;
bool password = false;
bool reverse = false;
const char *vnc;
const char *has_to;
-char *display, *ws_display = NULL, *to = NULL;
+char *h;
bool has_ipv4 = false;
bool has_ipv6 = false;
#ifdef CONFIG_VNC_WS
@@ -3361,16 +3362,36 @@ void vnc_display_open(const char *id, Error **errp)
return;
}
-has_to = qemu_opt_get(opts, to);
-if (has_to) {
-to = g_strdup_printf(,to=%s, has_to);
+sopts = qemu_opts_create(socket_optslist, NULL, 0, error_abort);
+wsopts = qemu_opts_create(socket_optslist, NULL, 0, error_abort);
+
+h = strrchr(vnc, ':');
+if (h) {
+char *host = g_strndup(vnc, h - vnc);
+qemu_opt_set(sopts, host, host, error_abort);
+qemu_opt_set(wsopts, host, host, error_abort);
+qemu_opt_set(sopts, port, h+1, error_abort);
+g_free(host);
+} else {
+error_setg(errp, no vnc port specified);
+goto fail;
}
+
+has_to = qemu_opt_get(opts, to);
has_ipv4 = qemu_opt_get_bool(opts, ipv4, false);
has_ipv6 = qemu_opt_get_bool(opts, ipv6, false);
-display = g_strdup_printf(%s%s%s%s, vnc,
- has_to ? to : ,
- has_ipv4 ? ,ipv4 : ,
- has_ipv6 ? ,ipv6 : );
+if (has_to) {
+qemu_opt_set(sopts, to, has_to, error_abort);
+qemu_opt_set(wsopts, to, has_to, error_abort);
+}
+if (has_ipv4) {
+qemu_opt_set(sopts, ipv4, on, error_abort);
+qemu_opt_set(wsopts, ipv4, on, error_abort);
+}
+if (has_ipv6) {
+qemu_opt_set(sopts, ipv6, on, error_abort);
+qemu_opt_set(wsopts, ipv6, on, error_abort);
+}
password = qemu_opt_get_bool(opts, password, false);
if (password fips_get_state()) {
@@ -3423,19 +3444,9 @@ void vnc_display_open(const char *id, Error **errp)
#ifdef CONFIG_VNC_WS
websocket = qemu_opt_get(opts, websocket);
if (websocket) {
-/* extract the host specification from display */
-char *host = NULL, *host_end = NULL;
vs-ws_enabled = true;
+qemu_opt_set(wsopts, port, websocket, error_abort);
-/* ipv6 hosts have colons */
-host_end = strrchr(display, ':');
-if (host_end) {
-host = g_strndup(display, host_end - display + 1);
-} else {
-host = g_strdup(:);
-}
-ws_display = g_strconcat(host, websocket, NULL);
-g_free(host);
}
#endif /* CONFIG_VNC_WS */
@@ -3605,10 +3616,10 @@ void vnc_display_open(const char *id, Error **errp)
#ifdef CONFIG_VNC_WS
vs-lwebsock = -1;
#endif
-if (strncmp(display, unix:, 5) == 0) {
-csock = unix_connect(display+5, errp);
+if (strncmp(vnc, unix:, 5) == 0) {
+csock = unix_connect(vnc+5, errp);
} else {
-csock = inet_connect(display, errp);
+csock = inet_connect(vnc, errp);
}
if (csock 0) {
goto fail;
@@ -3616,19 +3627,17 @@ void vnc_display_open(const char *id, Error **errp)
vnc_connect(vs, csock, false, false);
} else {
/* listen for connects */
-if (strncmp(display, unix:, 5) == 0) {
-vs-lsock = unix_listen(display+5, NULL, 0, errp);
+if (strncmp(vnc, unix:, 5) == 0) {
+vs-lsock = unix_listen(vnc+5, NULL, 0, errp);
vs-is_unix = true;
} else {
-vs-lsock = inet_listen(display, NULL, 0,
-SOCK_STREAM, 5900, errp);
+vs-lsock = inet_listen_opts(sopts, 5900, errp);
if (vs-lsock 0) {
goto fail;
}
#ifdef CONFIG_VNC_WS
if (vs-ws_enabled) {
-vs-lwebsock = inet_listen(ws_display, NULL, 0,
- SOCK_STREAM, 0, errp);
+vs-lwebsock = inet_listen_opts(wsopts, 0, errp);
if (vs-lwebsock 0) {
if (vs-lsock) {
close(vs-lsock);
@@ -3639,27 +3648,25 @@ void vnc_display_open(const char *id, Error **errp)
}
#endif /* CONFIG_VNC_WS */
[Qemu-devel] [Bug 1297218] Re: guest hangs after live migration due to tsc jump
Ping. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1297218 Title: guest hangs after live migration due to tsc jump Status in QEMU: New Status in glusterfs package in Ubuntu: Invalid Status in qemu package in Ubuntu: Triaged Status in glusterfs source package in Trusty: New Status in qemu source package in Trusty: Confirmed Bug description: We have two identical Ubuntu servers running libvirt/kvm/qemu, sharing a Gluster filesystem. Guests can be live migrated between them. However, live migration often leads to the guest being stuck at 100% for a while. In that case, the dmesg output for such a guest will show (once it recovers): Clocksource tsc unstable (delta = 662463064082 ns). In this particular example, a guest was migrated and only after 11 minutes (662 seconds) did it become responsive again. It seems that newly booted guests doe not suffer from this problem, these can be migrated back and forth at will. After a day or so, the problem becomes apparent. It also seems that migrating from server A to server B causes much more problems than going from B back to A. If necessary, I can do more measurements to qualify these observations. The VM servers run Ubuntu 13.04 with these packages: Kernel: 3.8.0-35-generic x86_64 Libvirt: 1.0.2 Qemu: 1.4.0 Gluster-fs: 3.4.2 (libvirt access the images via the filesystem, not using libgfapi yet as the Ubuntu libvirt is not linked against libgfapi). The interconnect between both machines (both for migration and gluster) is 10GbE. Both servers are synced to NTP and well within 1ms form one another. Guests are either Ubuntu 13.04 or 13.10. On the guests, the current_clocksource is kvm-clock. The XML definition of the guests only contains: clock offset='utc'/ Now as far as I've read in the documentation of kvm-clock, it specifically supports live migrations, so I'm a bit surprised at these problems. There isn't all that much information to find on these issue, although I have found postings by others that seem to have run into the same issues, but without a solution. --- ApportVersion: 2.14.1-0ubuntu3 Architecture: amd64 DistroRelease: Ubuntu 14.04 Package: libvirt (not installed) ProcCmdline: BOOT_IMAGE=/boot/vmlinuz-3.13.0-24-generic root=UUID=1b0c3c6d-a9b8-4e84-b076-117ae267d178 ro console=ttyS1,115200n8 BOOTIF=01-00-25-90-75-b5-c8 ProcVersionSignature: Ubuntu 3.13.0-24.47-generic 3.13.9 Tags: trusty apparmor apparmor apparmor apparmor apparmor Uname: Linux 3.13.0-24-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: _MarkForUpload: True modified.conffile..etc.default.libvirt.bin: [modified] modified.conffile..etc.libvirt.libvirtd.conf: [modified] modified.conffile..etc.libvirt.qemu.conf: [modified] modified.conffile..etc.libvirt.qemu.networks.default.xml: [deleted] mtime.conffile..etc.default.libvirt.bin: 2014-05-12T19:07:40.020662 mtime.conffile..etc.libvirt.libvirtd.conf: 2014-05-13T14:40:25.894837 mtime.conffile..etc.libvirt.qemu.conf: 2014-05-12T18:58:27.885506 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1297218/+subscriptions
[Qemu-devel] [PULL 4/7] ui: fix regression in x509verify parameter for VNC server
From: Daniel P. Berrange berra...@redhat.com
The 'x509verify' parameter is documented as taking a path to the
x509 certificates, ie the same syntax as the 'x509' parameter.
commit 4db14629c38611061fc19ec6927405923de84f08
Author: Gerd Hoffmann kra...@redhat.com
Date: Tue Sep 16 12:33:03 2014 +0200
vnc: switch to QemuOpts, allow multiple servers
caused a regression by turning 'x509verify' into a boolean
parameter instead. This breaks setup from libvirt and is not
consistent with the docs.
Signed-off-by: Daniel P. Berrange berra...@redhat.com
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
ui/vnc.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/ui/vnc.c b/ui/vnc.c
index db8409b..b514777 100644
--- a/ui/vnc.c
+++ b/ui/vnc.c
@@ -3303,7 +3303,7 @@ static QemuOptsList qemu_vnc_opts = {
.type = QEMU_OPT_BOOL,
},{
.name = x509verify,
-.type = QEMU_OPT_BOOL,
+.type = QEMU_OPT_STRING,
},{
.name = acl,
.type = QEMU_OPT_BOOL,
@@ -3410,9 +3410,14 @@ void vnc_display_open(const char *id, Error **errp)
#ifdef CONFIG_VNC_TLS
tls = qemu_opt_get_bool(opts, tls, false);
path = qemu_opt_get(opts, x509);
+if (!path) {
+path = qemu_opt_get(opts, x509verify);
+if (path) {
+vs-tls.x509verify = true;
+}
+}
if (path) {
x509 = true;
-vs-tls.x509verify = qemu_opt_get_bool(opts, x509verify, false);
if (vnc_tls_set_x509_creds_dir(vs, path) 0) {
error_setg(errp, Failed to find x509 certificates/keys in %s,
path);
--
1.8.3.1
[Qemu-devel] [PATCH] smbios: add max speed comdline option for type-17 (meory device) structure
Signed-off-by: Gabriel Somlo so...@cmu.edu
---
hw/i386/smbios.c | 10 --
qemu-options.hx | 4 ++--
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/hw/i386/smbios.c b/hw/i386/smbios.c
index f2e9ab6..1341e02 100644
--- a/hw/i386/smbios.c
+++ b/hw/i386/smbios.c
@@ -91,6 +91,7 @@ static struct {
static struct {
const char *loc_pfx, *bank, *manufacturer, *serial, *asset, *part;
+uint16_t speed;
} type17;
static QemuOptsList qemu_smbios_opts = {
@@ -304,6 +305,10 @@ static const QemuOptDesc qemu_smbios_type17_opts[] = {
.name = part,
.type = QEMU_OPT_STRING,
.help = part number,
+},{
+.name = speed,
+.type = QEMU_OPT_NUMBER,
+.help = maximum capable speed,
},
{ /* end of list */ }
};
@@ -697,13 +702,13 @@ static void smbios_build_type_17_table(unsigned instance,
uint64_t size)
SMBIOS_TABLE_SET_STR(17, bank_locator_str, type17.bank);
t-memory_type = 0x07; /* RAM */
t-type_detail = cpu_to_le16(0x02); /* Other */
-t-speed = cpu_to_le16(0); /* Unknown */
+t-speed = cpu_to_le16(type17.speed);
SMBIOS_TABLE_SET_STR(17, manufacturer_str, type17.manufacturer);
SMBIOS_TABLE_SET_STR(17, serial_number_str, type17.serial);
SMBIOS_TABLE_SET_STR(17, asset_tag_number_str, type17.asset);
SMBIOS_TABLE_SET_STR(17, part_number_str, type17.part);
t-attributes = 0; /* Unknown */
-t-configured_clock_speed = cpu_to_le16(0); /* Unknown */
+t-configured_clock_speed = t-speed; /* reuse value for max speed */
t-minimum_voltage = cpu_to_le16(0); /* Unknown */
t-maximum_voltage = cpu_to_le16(0); /* Unknown */
t-configured_voltage = cpu_to_le16(0); /* Unknown */
@@ -1083,6 +1088,7 @@ void smbios_entry_add(QemuOpts *opts)
save_opt(type17.serial, opts, serial);
save_opt(type17.asset, opts, asset);
save_opt(type17.part, opts, part);
+type17.speed = qemu_opt_get_number(opts, speed, 0);
return;
default:
error_report(Don't know how to build fields for SMBIOS type %ld,
diff --git a/qemu-options.hx b/qemu-options.hx
index 837624d..c4f7946 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1392,7 +1392,7 @@ DEF(smbios, HAS_ARG, QEMU_OPTION_smbios,
[,asset=str][,part=str]\n
specify SMBIOS type 4 fields\n
-smbios
type=17[,loc_pfx=str][,bank=str][,manufacturer=str][,serial=str]\n
- [,asset=str][,part=str]\n
+ [,asset=str][,part=str][,speed=%d]\n
specify SMBIOS type 17 fields\n,
QEMU_ARCH_I386)
STEXI
@@ -1415,7 +1415,7 @@ Specify SMBIOS type 3 fields
@item -smbios
type=4[,sock_pfx=@var{str}][,manufacturer=@var{str}][,version=@var{str}][,serial=@var{str}][,asset=@var{str}][,part=@var{str}]
Specify SMBIOS type 4 fields
-@item -smbios
type=17[,loc_pfx=@var{str}][,bank=@var{str}][,manufacturer=@var{str}][,serial=@var{str}][,asset=@var{str}][,part=@var{str}]
+@item -smbios
type=17[,loc_pfx=@var{str}][,bank=@var{str}][,manufacturer=@var{str}][,serial=@var{str}][,asset=@var{str}][,part=@var{str}][,speed=@var{%d}]
Specify SMBIOS type 17 fields
ETEXI
--
2.1.0
Re: [Qemu-devel] [PATCH] virtio-pci: Clear IRQ at reset
On Thu, Mar 12, 2015 at 02:40:55PM +0800, Fam Zheng wrote:
Currently we could leave PCI IRQ asserted even after reset, it is safer
to clear it.
In the case that a buggy driver has disabled MSI-X unintentially, we may
have already injected IRQ in previous virtio_pci_notify, which will not
be cleared by guest because it doesn't expect it (i.e. no irq handler).
However the driver may eventually notice the unresponsiveness and reset
the device, at that point, clearing the irq is meaningful.
Signed-off-by: Fam Zheng f...@redhat.com
I don't think we care about buggy drivers being able to recover, but the
same would apply to e.g. kdump when using virtio blk/scsi after a crash,
correct?
---
hw/virtio/virtio-pci.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index e7baf7b..2600f1e 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio/virtio-pci.c
@@ -988,6 +988,7 @@ static void virtio_pci_reset(DeviceState *qdev)
virtio_pci_stop_ioeventfd(proxy);
virtio_bus_reset(bus);
msix_unuse_all_vectors(proxy-pci_dev);
+pci_irq_deassert(proxy-pci_dev);
}
static Property virtio_pci_properties[] = {
--
1.9.3
Re: [Qemu-devel] [PATCH RFC v3 13/27] COLO RAM: Flush cached RAM into SVM's memory
* zhanghailiang (zhang.zhanghaili...@huawei.com) wrote:
We only need to flush RAM that is both dirty on PVM and SVM since
last checkpoint. Besides, we must ensure flush RAM cache before load
device state.
Signed-off-by: zhanghailiang zhang.zhanghaili...@huawei.coma
Signed-off-by: Lai Jiangshan la...@cn.fujitsu.com
Signed-off-by: Li Zhijian lizhij...@cn.fujitsu.com
Signed-off-by: Yang Hongyang yan...@cn.fujitsu.com
Signed-off-by: Gonglei arei.gong...@huawei.com
This could do with some more comments; colo_flush_ram_cache is quite complex.
See below.
---
arch_init.c| 91
+-
include/migration/migration-colo.h | 1 +
migration/colo.c | 1 -
3 files changed, 91 insertions(+), 2 deletions(-)
diff --git a/arch_init.c b/arch_init.c
index 4a1d825..f70de23 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -1100,6 +1100,7 @@ static int ram_load(QEMUFile *f, void *opaque, int
version_id)
{
int flags = 0, ret = 0;
static uint64_t seq_iter;
+bool need_flush = false;
seq_iter++;
@@ -1163,6 +1164,7 @@ static int ram_load(QEMUFile *f, void *opaque, int
version_id)
break;
}
+need_flush = true;
ch = qemu_get_byte(f);
ram_handle_compressed(host, ch, TARGET_PAGE_SIZE);
break;
@@ -1174,6 +1176,7 @@ static int ram_load(QEMUFile *f, void *opaque, int
version_id)
break;
}
+need_flush = true;
qemu_get_buffer(f, host, TARGET_PAGE_SIZE);
break;
case RAM_SAVE_FLAG_XBZRLE:
@@ -1190,6 +1193,7 @@ static int ram_load(QEMUFile *f, void *opaque, int
version_id)
ret = -EINVAL;
break;
}
+need_flush = true;
break;
case RAM_SAVE_FLAG_EOS:
/* normal exit */
@@ -1207,7 +1211,10 @@ static int ram_load(QEMUFile *f, void *opaque, int
version_id)
ret = qemu_file_get_error(f);
}
}
-
+if (!ret ram_cache_enable need_flush) {
+DPRINTF(Flush ram_cache\n);
+colo_flush_ram_cache();
+}
DPRINTF(Completed load of VM with exit code %d seq iteration
% PRIu64 \n, ret, seq_iter);
return ret;
@@ -1220,6 +1227,7 @@ static int ram_load(QEMUFile *f, void *opaque, int
version_id)
void create_and_init_ram_cache(void)
{
RAMBlock *block;
+int64_t ram_cache_pages = last_ram_offset() TARGET_PAGE_BITS;
QTAILQ_FOREACH(block, ram_list.blocks, next) {
block-host_cache = g_malloc(block-used_length);
@@ -1227,6 +1235,14 @@ void create_and_init_ram_cache(void)
}
ram_cache_enable = true;
+/*
+* Start dirty log for slave VM, we will use this dirty bitmap together
with
+* VM's cache RAM dirty bitmap to decide which page in cache should be
+* flushed into VM's RAM.
+*/
+migration_bitmap = bitmap_new(ram_cache_pages);
+migration_dirty_pages = 0;
+memory_global_dirty_log_start();
}
void release_ram_cache(void)
@@ -1261,6 +1277,79 @@ static void
*memory_region_get_ram_cache_ptr(MemoryRegion *mr, RAMBlock *block)
return block-host_cache + (addr - block-offset);
}
+static inline
+ram_addr_t host_bitmap_find_and_reset_dirty(MemoryRegion *mr,
+ram_addr_t start)
+{
+unsigned long base = mr-ram_addr TARGET_PAGE_BITS;
+unsigned long nr = base + (start TARGET_PAGE_BITS);
+unsigned long size = base + (int128_get64(mr-size) TARGET_PAGE_BITS);
+
+unsigned long next;
+
+next = find_next_bit(ram_list.dirty_memory[DIRTY_MEMORY_MIGRATION],
+ size, nr);
+if (next size) {
+clear_bit(next, ram_list.dirty_memory[DIRTY_MEMORY_MIGRATION]);
+}
+return (next - base) TARGET_PAGE_BITS;
+}
+
+void colo_flush_ram_cache(void)
+{
+RAMBlock *block = NULL;
+void *dst_host;
+void *src_host;
+ram_addr_t ca = 0, ha = 0;
+bool got_ca = 0, got_ha = 0;
+int64_t host_dirty = 0, both_dirty = 0;
+
+address_space_sync_dirty_bitmap(address_space_memory);
+
+block = QTAILQ_FIRST(ram_list.blocks);
+while (true) {
+if (ca block-used_length ca = ha) {
+ca = migration_bitmap_find_and_reset_dirty(block-mr, ca);
+if (ca block-used_length) {
+got_ca = 1;
+}
+}
+if (ha block-used_length ha = ca) {
+ha = host_bitmap_find_and_reset_dirty(block-mr, ha);
+if (ha block-used_length ha != ca) {
+got_ha = 1;
+}
+host_dirty += (ha block-used_length ? 1 : 0);
+both_dirty += (ha block-used_length ha == ca ? 1 : 0);
+}
+if (ca = block-used_length ha =
Re: [Qemu-devel] [PATCH v2] hmp: add info iothreads command
On Thu, 03/12 16:35, Ting Wang wrote:
Make info iothreads available on the HMP monitor.
The results are as follows:
id1: thread_id1
id2: thread_id2
Does this match the actual output format? I think you're missing a =.
Signed-off-by: Ting Wang kathy.wangt...@huawei.com
---
v2: add braces for if
---
hmp-commands.hx | 2 ++
hmp.c | 22 ++
hmp.h | 1 +
monitor.c | 7 +++
4 files changed, 32 insertions(+)
diff --git a/hmp-commands.hx b/hmp-commands.hx
index d5022d8..67d76ed 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -1746,6 +1746,8 @@ show roms
show the TPM device
@item info memory-devices
show the memory devices
+@item info iothreads
+show iothreads
@end table
ETEXI
diff --git a/hmp.c b/hmp.c
index 71c28bc..e87cb14 100644
--- a/hmp.c
+++ b/hmp.c
@@ -821,6 +821,28 @@ void hmp_info_tpm(Monitor *mon, const QDict *qdict)
qapi_free_TPMInfoList(info_list);
}
+void hmp_info_iothreads(Monitor *mon, const QDict *qdict)
+{
+IOThreadInfoList *head = NULL, *elem = NULL;
+
+head = qmp_query_iothreads(NULL);
+if (!head) {
+monitor_printf(mon, No iothread has been added\n);
+return;
+}
+
+elem = head;
+while (elem) {
+if (elem-value) {
+monitor_printf(mon, %s: thread_id=%ld\n, elem-value-id,
Please remove the trailing whitespace. You can use scripts/checkpatch.pl to
catch the coding style issues your self.
You should also add documentation in hmp-commands.hx.
Fam
+elem-value-thread_id);
+}
+elem = elem-next;
+}
+
+qapi_free_IOThreadInfoList(head);
+}
+
void hmp_quit(Monitor *mon, const QDict *qdict)
{
monitor_suspend(mon);
diff --git a/hmp.h b/hmp.h
index 81177b2..d99090e 100644
--- a/hmp.h
+++ b/hmp.h
@@ -38,6 +38,7 @@ void hmp_info_balloon(Monitor *mon, const QDict *qdict);
void hmp_info_pci(Monitor *mon, const QDict *qdict);
void hmp_info_block_jobs(Monitor *mon, const QDict *qdict);
void hmp_info_tpm(Monitor *mon, const QDict *qdict);
+void hmp_info_iothreads(Monitor *mon, const QDict *qdict);
void hmp_quit(Monitor *mon, const QDict *qdict);
void hmp_stop(Monitor *mon, const QDict *qdict);
void hmp_system_reset(Monitor *mon, const QDict *qdict);
diff --git a/monitor.c b/monitor.c
index c86a89e..076a306 100644
--- a/monitor.c
+++ b/monitor.c
@@ -2924,6 +2924,13 @@ static mon_cmd_t info_cmds[] = {
.mhandler.cmd = hmp_info_memory_devices,
},
{
+.name = iothreads,
+.args_type = ,
+.params = ,
+.help = show iothreads,
+.mhandler.cmd = hmp_info_iothreads,
+},
+{
.name = NULL,
},
};
--
1.8.5
Re: [Qemu-devel] [PATCH 0/4] virtio-scsi: fix up cdb mess
On 03/12/2015 12:42 AM, Michael S. Tsirkin wrote: Fam Zheng f...@redhat.com, Alexey Kardashevskiy a...@ozlabs.ru, Nikunj A Dadhania nik...@linux.vnet.ibm.com all reported that importing linux headers breaks cdb/sense in virtio scsi in qemu. This imports a linux patch fixing that, and does some related cleanups. Lightly tested. Testing would be very much appreciated. Works for me. Tested-by: Alexey Kardashevskiy a...@ozlabs.ru Michael S. Tsirkin (4): virtio-scsi: drop duplicate CDB/SENSE SIZE uapi/virtio_scsi: allow overriding CDB/SENSE size virtio-scsi: fix cdb/sense size virtio-scsi: clean out duplicate cdb field include/hw/virtio/virtio-scsi.h | 12 include/standard-headers/linux/virtio_scsi.h | 12 ++-- hw/scsi/virtio-scsi.c| 12 ++-- 3 files changed, 20 insertions(+), 16 deletions(-) -- Alexey
Re: [Qemu-devel] [PATCH V3 00/14] Support more virtio queues
On Thu, Mar 05, 2015 at 01:48:37PM +0800, Jason Wang wrote: We current limit the max virtio queues to 64. This is not sufficient to support multiqueue deivces (e.g recent Linux support up to 256 tap queues). So this series try to let virtio to support more queues. For some reason I was Cc'd only on some patches. If you want me to apply series, pls Cc on all of them. No much works need to be done except: - Patch 1 add a check to validate the queues supported by backend against the virtio queue limitation - Patch 2 fixes a bug in virtio_del_queue() - Patch 3 introdues a bus specific queue limitation - Patch 4 - Patch 8 let each transport to use bus specific queue limitation instead of VIRTIO_PCI_QUEUE_MAX - Patch 9 introduces a map from vector to queues that use this vector - Patch 10 introduces a helpr for get the queue index - Patch 11 speedups the MSI-X masking and unmasking through the vector to queues mapping that introduced by Patch 9 - Patch 12 increase the maximum number of queues supported by virtio-pci from 64 to 513, and deal with the migration compatibility with the changes. - Patch 13 tries to remove the hard coded MSI-X bar size (4096) and allow up to 2048 MSI-X entries. - Patch 14 add a boolean property to let the virtio-net can calculate the MSI-X bar size based on the number of MSI-X vectors and keep migration compatibility with legacy version whose bar size is 4096. With this patch, we can support up to 256 queues. Since x86 can only allow about 240 interrupt vectors for MSI-X, current Linux driver can only have about 80 queue pairs has their private MSI-X interrupt vectors. With sharing IRQ with queue pairs (RFC posted in https://lkml.org/lkml/2014/12/25/169), Linux driver can have up to about 186 queue pairs has their private MSI-X interrupt vectors. Stress/migration test on virtio-pci, compile test/make check on s390x-softmmu. Cc: Paolo Bonzini pbonz...@redhat.com Cc: Richard Henderson r...@twiddle.net Cc: Anthony Liguori aligu...@amazon.com Cc: Michael S. Tsirkin m...@redhat.com Cc: Alexander Graf ag...@suse.de Cc: Keith Busch keith.bu...@intel.com Cc: Kevin Wolf kw...@redhat.com Cc: Stefan Hajnoczi stefa...@redhat.com Cc: Anthony Liguori aligu...@amazon.com Cc: Christian Borntraeger borntrae...@de.ibm.com Cc: Cornelia Huck cornelia.h...@de.ibm.com Cc: Amit Shah amit.s...@redhat.com Please review Thanks Changes from V2: - Move transport specific limitation to their implementation. (The left is VIRTIO_CCW_QUEUE_MAX since I fail to find a common header files other than virtio.h) - Use virtio_get_queue_max() if possbile in virtio.c - AdapterRoutes should use ccw limit - Introduce a vector to queue mapping for virito devices and speedup the MSI-X masking and unmasking through this. Changes from V1: - add a validation against the bus limitation - switch to use a bus specific queue limit instead of a global one, this will allow us to just increase the limit of one transport without disturbing others. - only increase the queue limit of virtio-pci - limit the maximum number of virtio queues to 64 for legacy machine types Jason Wang (14): virtio-net: validate backend queue numbers against bus limitation virtio-net: fix the upper bound when trying to delete queues virito: introduce bus specific queue limit virtio-ccw: introduce ccw specific queue limit virtio-s390: switch to bus specific queue limit virtio-serial-bus: switch to bus specific queue limit virtio-mmio: switch to bus specific queue limit virtio-pci: switch to use bus specific queue limit virtio: introduce vector to virtqueues mapping virtio: introduce virtio_queue_get_index() virtio-pci: speedup MSI-X masking and unmasking virtio-pci: increase the maximum number of virtqueues to 513 pci: remove hard-coded bar size in msix_init_exclusive_bar() virtio-pci: introduce auto_msix_bar_size property hw/block/nvme.c| 2 +- hw/char/virtio-serial-bus.c| 4 ++- hw/i386/pc_piix.c | 10 ++ hw/i386/pc_q35.c | 9 + hw/misc/ivshmem.c | 2 +- hw/net/virtio-net.c| 9 - hw/pci/msix.c | 18 -- hw/ppc/spapr.c | 5 +++ hw/s390x/s390-virtio-bus.c | 7 ++-- hw/s390x/s390-virtio-ccw.c | 7 ++-- hw/s390x/virtio-ccw.c | 12 --- hw/scsi/virtio-scsi.c | 4 +-- hw/virtio/virtio-mmio.c| 7 ++-- hw/virtio/virtio-pci.c | 78 -- hw/virtio/virtio-pci.h | 3 ++ hw/virtio/virtio.c | 74 ++- include/hw/compat.h| 8 + include/hw/pci/msix.h | 2 +- include/hw/s390x/s390_flic.h | 2 +- include/hw/virtio/virtio-bus.h | 2 ++ include/hw/virtio/virtio.h | 7 +++- 21 files changed, 199
Re: [Qemu-devel] [PATCH v2] hmp: add info iothreads command
On 2015-3-12 17:05, Fam Zheng wrote:
On Thu, 03/12 16:35, Ting Wang wrote:
Make info iothreads available on the HMP monitor.
The results are as follows:
id1: thread_id1
id2: thread_id2
Does this match the actual output format? I think you're missing a =.
Signed-off-by: Ting Wang kathy.wangt...@huawei.com
---
v2: add braces for if
---
hmp-commands.hx | 2 ++
hmp.c | 22 ++
hmp.h | 1 +
monitor.c | 7 +++
4 files changed, 32 insertions(+)
diff --git a/hmp-commands.hx b/hmp-commands.hx
index d5022d8..67d76ed 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -1746,6 +1746,8 @@ show roms
show the TPM device
@item info memory-devices
show the memory devices
+@item info iothreads
+show iothreads
@end table
ETEXI
diff --git a/hmp.c b/hmp.c
index 71c28bc..e87cb14 100644
--- a/hmp.c
+++ b/hmp.c
@@ -821,6 +821,28 @@ void hmp_info_tpm(Monitor *mon, const QDict *qdict)
qapi_free_TPMInfoList(info_list);
}
+void hmp_info_iothreads(Monitor *mon, const QDict *qdict)
+{
+IOThreadInfoList *head = NULL, *elem = NULL;
+
+head = qmp_query_iothreads(NULL);
+if (!head) {
+monitor_printf(mon, No iothread has been added\n);
+return;
+}
+
+elem = head;
+while (elem) {
+if (elem-value) {
+monitor_printf(mon, %s: thread_id=%ld\n, elem-value-id,
Please remove the trailing whitespace. You can use scripts/checkpatch.pl to
catch the coding style issues your self.
OK. Thank you.
You should also add documentation in hmp-commands.hx.
Fam
It is a command in info group, I think documentation as follows is OK, do you
agree with it?
diff --git a/hmp-commands.hx b/hmp-commands.hx
index d5022d8..67d76ed 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -1746,6 +1746,8 @@ show roms
show the TPM device
@item info memory-devices
show the memory devices
+@item info iothreads
+show iothreads
@end table
ETEXI
Ting
+elem-value-thread_id);
+}
+elem = elem-next;
+}
+
+qapi_free_IOThreadInfoList(head);
+}
+
void hmp_quit(Monitor *mon, const QDict *qdict)
{
monitor_suspend(mon);
diff --git a/hmp.h b/hmp.h
index 81177b2..d99090e 100644
--- a/hmp.h
+++ b/hmp.h
@@ -38,6 +38,7 @@ void hmp_info_balloon(Monitor *mon, const QDict *qdict);
void hmp_info_pci(Monitor *mon, const QDict *qdict);
void hmp_info_block_jobs(Monitor *mon, const QDict *qdict);
void hmp_info_tpm(Monitor *mon, const QDict *qdict);
+void hmp_info_iothreads(Monitor *mon, const QDict *qdict);
void hmp_quit(Monitor *mon, const QDict *qdict);
void hmp_stop(Monitor *mon, const QDict *qdict);
void hmp_system_reset(Monitor *mon, const QDict *qdict);
diff --git a/monitor.c b/monitor.c
index c86a89e..076a306 100644
--- a/monitor.c
+++ b/monitor.c
@@ -2924,6 +2924,13 @@ static mon_cmd_t info_cmds[] = {
.mhandler.cmd = hmp_info_memory_devices,
},
{
+.name = iothreads,
+.args_type = ,
+.params = ,
+.help = show iothreads,
+.mhandler.cmd = hmp_info_iothreads,
+},
+{
.name = NULL,
},
};
--
1.8.5
.
Re: [Qemu-devel] [PATCH V3 00/14] Support more virtio queues
On Thu, Mar 12, 2015 at 5:28 PM, Michael S. Tsirkin m...@redhat.com wrote: On Thu, Mar 05, 2015 at 01:48:37PM +0800, Jason Wang wrote: We current limit the max virtio queues to 64. This is not sufficient to support multiqueue deivces (e.g recent Linux support up to 256 tap queues). So this series try to let virtio to support more queues. For some reason I was Cc'd only on some patches. If you want me to apply series, pls Cc on all of them. Ok, will cc you for all patches in V4. And looks like 2.3 is a little bit risky. Will target this to 2.4 Thanks
Re: [Qemu-devel] [PATCH v2] hmp: add info iothreads command
On Thu, 03/12 17:32, Ting Wang wrote: It is a command in info group, I think documentation as follows is OK, do you agree with it? diff --git a/hmp-commands.hx b/hmp-commands.hx index d5022d8..67d76ed 100644 --- a/hmp-commands.hx +++ b/hmp-commands.hx @@ -1746,6 +1746,8 @@ show roms show the TPM device @item info memory-devices show the memory devices +@item info iothreads +show iothreads @end table ETEXI Yes, looks good. Fam
Re: [Qemu-devel] [PATCH 2/2 RFC] s390x/pci: rework pci infrastructure modeling
On Thu, Mar 12, 2015 at 09:46:44AM +0100, Frank Blaschka wrote: On Wed, Mar 11, 2015 at 03:57:05PM +0100, Michael S. Tsirkin wrote: On Wed, Mar 11, 2015 at 03:38:44PM +0100, Frank Blaschka wrote: I like Alex's idea because: 1) It reflects pretty well the actual nature of the pci system in real s390 hw why do you say this? does real hw has this one device per bridge limit? Actually we don't know. HW does not expose this information. All we know is each pci function is completely separated. So it is a good assumption to have a separate bridge/bus for each pci function. By the way the Linux kernel for s390 makes the same assumption by creating a new pci domain for each function. You may want to read the cover letter again to get more technical details on this. I'm sorry, my question wasn't clear. I'll try to rephrase. Imagine that I'm using s390, and I add a pci to pci bridge: -device s390-pcihost,fid=17,uid=2217,id=mydev -device ne2k_pci,bus=mydev.0,addr=0 -device pci-bridge,chassis_nr=2,bus=bus=mydev.0,addr=0,id=newdev -device ne2k_pci,bus=newdev,addr=8 What happens with your scheme then? It seems reasonable to assume that this is a legal configuration on real hardware. -- MST
Re: [Qemu-devel] [PATCH v2 3/3] target-arm: get_phys_addr_lpae: more xn control
On 10 March 2015 at 21:06, Andrew Jones drjo...@redhat.com wrote:
This patch makes the following changes to the determination of
whether an address is executable, when translating addresses
using LPAE.
1. No longer assumes that PL0 can't execute when it can't read.
It can in AArch64, a difference from AArch32.
2. Use va_size == 64 to determine we're in AArch64, rather than
arm_feature(env, ARM_FEATURE_V8), which is insufficient.
3. Add additional XN determinants
- NS is_secure (SCR SCR_SIF)
- WXN (prot PAGE_WRITE)
- AArch64: (prot_PL0 PAGE_WRITE)
- AArch32: UWXN (prot_PL0 PAGE_WRITE)
- XN determination should also work in secure mode (untested)
- XN may even work in EL2 (currently impossible to test)
4. Cleans up the bloated PAGE_EXEC condition - by removing it.
The helper get_S1prot is introduced. It may even work in EL2,
when support for that comes, but, as the function name implies,
it only works for stage 1 translations.
Signed-off-by: Andrew Jones drjo...@redhat.com
I like the general shape of this patch. Minor comment below:
---
target-arm/helper.c | 129
1 file changed, 100 insertions(+), 29 deletions(-)
diff --git a/target-arm/helper.c b/target-arm/helper.c
index d996659652f8d..c457e9ab8c85a 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -4962,15 +4962,11 @@ static inline int ap_to_rw_prot(CPUARMState *env,
ARMMMUIdx mmu_idx,
/* Translate section/page access permissions to page
* R/W protection flags.
*
- * @env: CPUARMState
- * @mmu_idx: MMU index indicating required translation regime
* @ap: The 2-bit simple AP (AP[2:1])
+ * @is_user: TRUE if accessing from PL0
*/
-static inline int
-simple_ap_to_rw_prot(CPUARMState *env, ARMMMUIdx mmu_idx, int ap)
+static inline int simple_ap_to_rw_prot_is_user(int ap, bool is_user)
{
-bool is_user = regime_is_user(env, mmu_idx);
-
switch (ap) {
case 0:
return is_user ? 0 : PAGE_READ | PAGE_WRITE;
@@ -4985,6 +4981,94 @@ simple_ap_to_rw_prot(CPUARMState *env, ARMMMUIdx
mmu_idx, int ap)
}
}
+static inline int
+simple_ap_to_rw_prot(CPUARMState *env, ARMMMUIdx mmu_idx, int ap)
+{
+return simple_ap_to_rw_prot_is_user(ap, regime_is_user(env, mmu_idx));
+}
+
+/* Translate section/page access permissions to protection flags
+ *
+ * @env: CPUARMState
+ * @mmu_idx: MMU index indicating required translation regime
+ * @is_aa64: TRUE if AArch64
+ * @ap: The 2-bit simple AP (AP[2:1])
+ * @ns: NS (non-secure) bit
+ * @xn: XN (execute-never) bit
+ * @pxn: PXN (privileged execute-never) bit
+ */
+static int get_S1prot(CPUARMState *env, ARMMMUIdx mmu_idx, bool is_aa64,
+ int ap, int ns, int xn, int pxn)
+{
+bool is_user = regime_is_user(env, mmu_idx);
+int prot_rw, user_rw;
+bool have_wxn;
+int wxn = 0;
+
+assert(mmu_idx != ARMMMUIdx_S2NS);
+
+user_rw = simple_ap_to_rw_prot_is_user(ap, true);
+if (is_user) {
+prot_rw = user_rw;
+} else {
+prot_rw = simple_ap_to_rw_prot_is_user(ap, false);
+}
+
+if (ns arm_is_secure(env) (env-cp15.scr_el3 SCR_SIF)) {
+return prot_rw;
+}
+
+/* TODO have_wxn should be replaced with
+ * ARM_FEATURE_V8 || (ARM_FEATURE_V7 ARM_FEATURE_EL2)
+ * when ARM_FEATURE_EL2 starts getting set. For now we assume all LPAE
+ * compatible processors have EL2, which is required for [U]WXN.
+ */
+have_wxn = arm_feature(env, ARM_FEATURE_LPAE);
+
+if (have_wxn) {
+wxn = regime_sctlr(env, mmu_idx) SCTLR_WXN;
+}
+
+if (is_aa64) {
+switch (regime_el(env, mmu_idx)) {
+case 1:
+if (is_user !user_rw) {
+wxn = 0;
I don't understand this. We ignore the WXN bit if this is
a user access and the page is not readable ?
I also find the naming of this variable user_rw (and
to a lesser extent prot_rw) very confusing. I keep
misreading if (user_rw) as meaning if this page is
read-write for the user, when in fact it only means
if this page is readable for the user.
Maybe it would be less confusing if we always did tests
against a set of PAGE_* flags rather than doing an
is/is-not-zero test?
The rest looked OK to me.
-- PMM
Re: [Qemu-devel] [PULL 0/2] target-mips queue
On 11 March 2015 at 16:15, Leon Alrae leon.al...@imgtec.com wrote: Hi, This pull request contains remaining change for 2.3 which was originally submitted before soft-freeze. Thanks, Leon Cc: Peter Maydell peter.mayd...@linaro.org Cc: Aurelien Jarno aurel...@aurel32.net The following changes since commit 48412371415a260d00fc7fdcdb400da55f268828: Merge remote-tracking branch 'remotes/ehabkost/tags/x86-pull-request' into staging (2015-03-11 11:12:35 +) are available in the git repository at: git://github.com/lalrae/qemu.git tags/mips-20150311 for you to fetch changes up to 64457e7ca9f26d633a59c202a297113a796c: target-mips: add missing MSACSR and restore fp_status and hflags (2015-03-11 14:13:57 +) MIPS patches 2015-03-11 Changes: * use VMStateDescription for MIPS CPU Applied, thanks. -- PMM
Re: [Qemu-devel] [PATCH v6 07/15] spapr_rtas: add ibm, configure-connector RTAS interface
On Thu, Mar 05, 2015 at 08:12:58AM -0600, Michael Roth wrote:
Quoting David Gibson (2015-03-04 22:30:40)
On Wed, Mar 04, 2015 at 07:37:08AM -0600, Michael Roth wrote:
Quoting Michael Roth (2015-03-03 23:50:34)
Quoting David Gibson (2015-03-02 23:33:39)
On Mon, Mar 02, 2015 at 10:40:16PM -0600, Michael Roth wrote:
Quoting David Gibson (2015-03-02 01:02:46)
On Thu, Feb 26, 2015 at 09:11:07PM -0600, Michael Roth wrote:
This interface is used to fetch an OF device-tree nodes that
describes a
newly-attached device to guest. It is called multiple times to
walk the
device-tree node and fetch individual properties into a
'workarea'/buffer
provided by the guest.
The device-tree is generated by QEMU and passed to an
sPAPRDRConnector during
the initial hotplug operation, and the state of these RTAS
calls is tracked by
the sPAPRDRConnector. When the last of these properties is
successfully
fetched, we report as special return value to the guest and
transition
the device to a 'configured' state on the QEMU/DRC side.
See docs/specs/ppc-spapr-hotplug.txt for a complete description
of
this interface.
Signed-off-by: Michael Roth mdr...@linux.vnet.ibm.com
So, actually, here's probably the best place to explain what I
had in
mind for changing the internal interface for this stuff. I was
thinking something like this pseudocode:
struct DRCCCState {
void *fdt;
int offset;
int depth;
};
rtas_configure_connector()
{
...
DRCCCState *ccstate;
...
/* check parameters, retrieve drc */
ccstate = drc-ccstate;
if (!ccstate) {
/* Haven't started configuring yet */
ccstate = malloc(...);
/* Retrieve the dt fragment from the backend */
ccstate-fdt = drck-get_dt(...);
ccstate-offset = 0;
}
while (get next tag from fdt) {
switch (tag)
case FDT_PROPERTY:
/* Translate property into rtas return
values */
return SPAPR_DR_CC_RESPONSE_NEXT_PROPERTY;
/* other cases ... */
}
/* Fall through only if we've completed streaming out the
dt
*/
/* Tell the back end we've finished configuring */
drck-cc_completed(...);
return SPAPR_DR_CC_RESPONSE_SUCCESS;
}
On reset, or anything else which interrupts the configuration
process,
just blow away drc-ccstate.
Ok, that seems reasonable. I took a stab at it here:
https://github.com/mdroth/qemu/commit/79ce372743da1b63a6fa33e3de1f1daba8ea1fdc
https://github.com/mdroth/qemu/commits/spapr-hotplug-pci
It's looking pretty close now, thanks for the rework.
It exposes the ccstate as you suggested, via drck-get_cc_state(),
and in
place of drck-cc_completed() I have drck-set_configured() which
serves
roughly the same purpose I think. I opted not to let RTAS handle
allocation, since it seemed to imply RTAS owns it and not the DRC.
So, that was intentional; basically RTAS *does* own the CCstate. But
for convenience of index we need connect it to the DRC. Think of it
like an rtas_priv field in the DRC.
In particular I think the CCstate should be opaque to everything
except the RTAS code itself, which means initializing the offset and
depth in RTAS, not in a drck callback. As far as the drck callback
is concerned, it's supplying a dt fragment, but it doesn't care about
the details of how the upper layer communicates that through to the
guest.
Ah ok, so it was about moving the CCState out of DRC, and not just the
awkward interface that wraps FDT traversal. So I went ahead and did it
as you suggested, but also making it actually opaque, and relying on
a couple callbacks that configure-connector passes to
drc-begin_configure_connector to handle init/reset of the CCState
fields (such as the fdt, and the start offset (which isn't necessarilly
0)):
https://github.com/mdroth/qemu/commits/spapr-hotplug-pci
https://github.com/mdroth/qemu/commit/732aa10fa2e41951c396373e7df7d31861322531
I think I have all your other comments addressed, so if that looks ok
I'll post v7 soon. Thanks!
Yikes, just
Re: [Qemu-devel] E5-2620v2 - emulation stop error
* Andrey Korolyov (and...@xdel.ru) wrote: On Wed, Mar 11, 2015 at 10:59 PM, Dr. David Alan Gilbert dgilb...@redhat.com wrote: * Andrey Korolyov (and...@xdel.ru) wrote: On Wed, Mar 11, 2015 at 10:33 PM, Dr. David Alan Gilbert dgilb...@redhat.com wrote: * Kevin O'Connor (ke...@koconnor.net) wrote: On Wed, Mar 11, 2015 at 02:45:31PM -0400, Kevin O'Connor wrote: On Wed, Mar 11, 2015 at 02:40:39PM -0400, Kevin O'Connor wrote: For what it's worth, I can't seem to trigger the problem if I move the cmos read above the SIPI/LAPIC code (see patch below). Ugh! That's a seabios bug. Main processor modifies the rtc index (rtc_read()) while APs try to clear the NMI bit by modifying the rtc index (romlayout.S:transition32). I'll put together a fix. The seabios patch below resolves the issue for me. Thanks! Looks good here. Andrey, Paolo, Bandan: Does it fix it for you as well? Thanks Kevin, Dave, I`m afraid that I`m hitting something different not only because different suberror code but also because of mine version of seabios - I am using 1.7.5 and corresponding code in the proposed patch looks different - there is no smp-related code patch is about of. Those mentioned devices went to production successfully and I`m afraid I cannot afford playing on them anymore, even if I re-trigger the issue with patched 1.8.1-rc, there is no way to switch to a different kernel and retest due to specific conditions of this production suite. I`ve ordered a pair of new shoes^W 2620v2-s which should arrive to me next Well I was testing on a pair of 'E5-2620 v2'; but as you saw my test case was pretty simple. If you can suggest any flags I should add etc to the test I'd be happy to give it a go. Dave Here is mine launch string: qemu-system-x86_64 -enable-kvm -name vmtest -S -machine pc-i440fx-2.1,accel=kvm,usb=off -cpu SandyBridge,+kvm_pv_eoi -m 512 -realtime mlock=off -smp 12,sockets=1,cores=12,threads=12 -numa node,nodeid=0,cpus=0-11,mem=512 -nographic -no-user-config -nodefaults -device sga -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device nec-usb-xhci,id=usb,bus=pci.0,addr=0x4 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -m 512,slots=31,maxmem=16384M -object memory-backend-ram,id=mem0,size=512M -device pc-dimm,id=dimm0,node=0,memdev=mem0 I omitted disk backend in this example, but there is a chance that my problem is not reproducible without some calls made explicitly by a bootloader (not sure what to say for mid-runtime failures). It seems to survive OK: while true; do (sleep 1; echo -e '\001cc\n'; sleep 5; echo -e 'q\n')|/opt/qemu-try-world3/bin/qemu-system-x86_64 -enable-kvm -name vmtest -S -machine pc-i440fx-2.1,accel=kvm,usb=off -cpu SandyBridge,+kvm_pv_eoi -m 512 -realtime mlock=off -smp 12,sockets=1,cores=12,threads=12 -numa node,nodeid=0,cpus=0-11,mem=512 -nographic -no-user-config -device sga -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device nec-usb-xhci,id=usb,bus=pci.0,addr=0x4 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -m 512,slots=31,maxmem=16384M -object memory-backend-ram,id=mem0,size=512M -device pc-dimm,id=dimm0,node=0,memdev=mem0 ~/pi.vfd 21 | tee /tmp/qemu.op; grep internal error /tmp/qemu.op -q break; done Dave Monday, so I`ll be able to test a) against 1.8.0-release, b) against patched bios code, c) reproduce initial error on master/3.19 (may be I`ll take them before weekend by going into this computer shop in person). Until then, I have a very deep feeling that mine issue is not there :) Also I became very curious on how a lack of IDT feature may completely eliminate the issue appearance for me, the only possible explanation is a clock-related race which is kinda stupid suggestion and unlikely to exist in nature. Thanks again for everyone for throughout testing and ideas! -Kevin --- a/src/romlayout.S +++ b/src/romlayout.S @@ -22,7 +22,8 @@ // %edx = return location (in 32bit mode) // Clobbers: ecx, flags, segment registers, cr0, idt/gdt DECLFUNC transition32 -transition32_for_smi: +transition32_nmi_off: +// transition32 when NMI and A20 are already initialized movl %eax, %ecx jmp 1f transition32: @@ -205,7 +206,7 @@ __farcall16: entry_smi: // Transition to 32bit mode. movl $1f + BUILD_BIOS_ADDR, %edx -jmp transition32_for_smi +jmp transition32_nmi_off .code32 1: movl $BUILD_SMM_ADDR + 0x8000, %esp calll _cfunc32flat_handle_smi - BUILD_BIOS_ADDR @@ -216,8 +217,10 @@
Re: [Qemu-devel] [PATCH] virtio-pci: Clear IRQ at reset
On Thu, Mar 12, 2015 at 06:00:28PM +0800, Fam Zheng wrote:
On Thu, 03/12 10:41, Michael S. Tsirkin wrote:
On Thu, Mar 12, 2015 at 02:40:55PM +0800, Fam Zheng wrote:
Currently we could leave PCI IRQ asserted even after reset, it is safer
to clear it.
In the case that a buggy driver has disabled MSI-X unintentially, we may
have already injected IRQ in previous virtio_pci_notify, which will not
be cleared by guest because it doesn't expect it (i.e. no irq handler).
However the driver may eventually notice the unresponsiveness and reset
the device, at that point, clearing the irq is meaningful.
Signed-off-by: Fam Zheng f...@redhat.com
I don't think we care about buggy drivers being able to recover, but the
same would apply to e.g. kdump when using virtio blk/scsi after a crash,
correct?
OK, yes, get your point.
So thinking about this more, by the time kdump tries to reset device,
linux has probably already disabled the IRQ at the APIC level.
Isn't that the case? If so, the patch won't help, will it?
And this also relates to the patch you replied
yesterday:
http://www.spinics.net/lists/kernel/msg1943182.html
OK can you please write a commit message that
explains the problem and how it's fixed,
so I can put it in git log?
/*
The hanging problem, which is due to irq not being acknowledged, can only be
fixed by your patch if the irq is cleared at reset.
The uninterruptable process doesn't really matter, the system would still
shutdown, as long as the wrong irq is cleard.
See also RHBZ https://bugzilla.redhat.com/show_bug.cgi?id=1199155
*/
Fam
---
hw/virtio/virtio-pci.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index e7baf7b..2600f1e 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio/virtio-pci.c
@@ -988,6 +988,7 @@ static void virtio_pci_reset(DeviceState *qdev)
virtio_pci_stop_ioeventfd(proxy);
virtio_bus_reset(bus);
msix_unuse_all_vectors(proxy-pci_dev);
+pci_irq_deassert(proxy-pci_dev);
}
static Property virtio_pci_properties[] = {
--
1.9.3
Re: [Qemu-devel] [PATCH 2/2 RFC] s390x/pci: rework pci infrastructure modeling
On Thu, Mar 12, 2015 at 11:03:50AM +0100, Michael S. Tsirkin wrote: On Thu, Mar 12, 2015 at 10:54:24AM +0100, Frank Blaschka wrote: On Wed, Mar 11, 2015 at 06:42:34PM +0100, Michael S. Tsirkin wrote: On Wed, Mar 11, 2015 at 03:38:44PM +0100, Frank Blaschka wrote: On Tue, Mar 10, 2015 at 03:26:23PM +0100, Michael S. Tsirkin wrote: On Tue, Mar 10, 2015 at 02:03:34PM +0100, Frank Blaschka wrote: This patch changes the modeling of the s390 qemu pci infrastructure to better match the actual pci architecture defined by the real hardware. A pci host bridge like device (s390-pcihost) models the abstract view of the bare pci function. It provides s390 specific configuration attributes (fid and uid) for the attached pci device. The host bridge restrict the pci bus to just hold one single pci device. Also we have to make the s390 pci host bridge hot plugable. This requirement is really because of the 1 device per bus limitation, isn't it? If you supported many devices per bus, you could use hotplug there and there won't be need to support hotplug of the host bridge. Absolutely yes. Have you seen my first proposal? It basically exploits the normal pci bridge/bus/slot mechanism but need a place to store s390 specific configuration attributes. The idea of a host bridge having this attributes and limit the bus to one slot was an alternate design approach suggested by Alex. I like Alex's idea because: 1) It reflects pretty well the actual nature of the pci system in real s390 hw 2) It does not create an somehow artifical pci topology I'll have to re-read but here's a thought: use your patch but remove host bridge hotplug support code. Stick a standard bridge with shpc support in the single slot behind your host bridge (existing pci-bridge-dev should do the trick, though not many people use it, so you might run into bugs, but fixing them is a good idea anyway). You can instanciate it automatically like Marcel's patches do for PXB. Still don't undertsand so I try to summarize in my words please corrent me if I got something wrong - create a standard host bridge - change the s390-pcihost to be a pci 2 pci bridge Actually I suggested simply adding a pci 2 pci bridge behind s390-pcihost. - now we can hotplug the s390-pcihost + hotplug a pci device to this s390-pcihost using standard pci hotplug mechanism My idea was to just hotplug a pci device behind the standard pci 2 pci bridge. don't support hotplugging bridge itself or s390-pcihost itself. - we keep the 1 slot limit on the s390-pcihost. We need a place to store fid and uid information (see mail thread from my 1 proposal) Yes. - If we need more than 32 pci functions we have to extend the primary pci bus via standart pci 2 pci bridges or add another standart host bridge Is this your suggestion? Almost, clarifications above. OK, got your idea. Have to think about it and may do some prototyping. THX! You get hotplug + multiple devices for free. And the resulting topology is clearly something that *can* exist on bare-metal, since no one can prevent users sticking a pci bridge device in a pci slot. Again on bar s390 metal we do not have bridge bus slot at all. OS does not have any knowledge about it. So anything we try to model is somehow artificial. So I wonder: what does guest see if you do it like the above in QEMU? Do s390 guests even have ability to enumerate pci to pci bridges? I think the answer is no. All a s390 guest can do is call a s390 instruction to get a list of pci functions. There is no further information about the function. The fact there might be a bridge/bus/slot is completely abstracted in hw and not exposed to the OS. I think the fact, the hw guaranties a pci function is completetly independent, made the kernel folks to decide to enumarate the domain. Looking at a pci address on the guest (or in general on s390 kernel) you will never see a bus or slot != 0 (:00:00.0) Anyhow what we are doing do model pci in qemu, the guest will only see a list of pci functions and enumerate the domain to create a pci address and that's it Why do I prefer pci hotplug to s390 hotplug? s390 hotplug is really surprise removal. There's no way Don't understand this neither. s390 linux kernel is well prepared to receive s390 specific events to signal a pci function is going away. Anyhow we end up I can generate this events to get ack from guest. Linux isn't very well equipped to handle that, we might be able to fix it with time but current virtio drivers aren't very happy. This is done by implementing a s390 specific bus to attach this new host bridge like devices. Sample qemu configuration:
Re: [Qemu-devel] [PATCH] virtio-pci: Clear IRQ at reset
On Thu, Mar 12, 2015 at 10:21:47AM +, Peter Maydell wrote: On 12 March 2015 at 10:16, Michael S. Tsirkin m...@redhat.com wrote: So thinking about this more, by the time kdump tries to reset device, linux has probably already disabled the IRQ at the APIC level. Isn't that the case? If so, the patch won't help, will it? Trying to deassert (or worse, assert) interrupt lines in device reset functions is slightly bogus, yes. In general the theory is that the interrupt controller the interrupt line is connected to should have its own reset handling which treats the line as going back to deasserted, because there's no guarantee made about which of the two ends of the line gets its reset handler called first. Things are not really this neat in practice though. (There's no good way to model a device which comes out of reset with a line asserted, for instance.) -- PMM This isn't a device reset though. The function that Fam is touching is called when a special virtio reset register to poked by the driver. It only resets part of the device, not all of it, and it seems reasonable to ask that it clear the interrupt. So I think the patch is correct, even if just for spec compliance reasons, but I would like to find out and document the workloads that actually benefit. -- MST
Re: [Qemu-devel] E5-2620v2 - emulation stop error
On Thu, Mar 12, 2015 at 12:59 PM, Dr. David Alan Gilbert dgilb...@redhat.com wrote: * Andrey Korolyov (and...@xdel.ru) wrote: On Wed, Mar 11, 2015 at 10:59 PM, Dr. David Alan Gilbert dgilb...@redhat.com wrote: * Andrey Korolyov (and...@xdel.ru) wrote: On Wed, Mar 11, 2015 at 10:33 PM, Dr. David Alan Gilbert dgilb...@redhat.com wrote: * Kevin O'Connor (ke...@koconnor.net) wrote: On Wed, Mar 11, 2015 at 02:45:31PM -0400, Kevin O'Connor wrote: On Wed, Mar 11, 2015 at 02:40:39PM -0400, Kevin O'Connor wrote: For what it's worth, I can't seem to trigger the problem if I move the cmos read above the SIPI/LAPIC code (see patch below). Ugh! That's a seabios bug. Main processor modifies the rtc index (rtc_read()) while APs try to clear the NMI bit by modifying the rtc index (romlayout.S:transition32). I'll put together a fix. The seabios patch below resolves the issue for me. Thanks! Looks good here. Andrey, Paolo, Bandan: Does it fix it for you as well? Thanks Kevin, Dave, I`m afraid that I`m hitting something different not only because different suberror code but also because of mine version of seabios - I am using 1.7.5 and corresponding code in the proposed patch looks different - there is no smp-related code patch is about of. Those mentioned devices went to production successfully and I`m afraid I cannot afford playing on them anymore, even if I re-trigger the issue with patched 1.8.1-rc, there is no way to switch to a different kernel and retest due to specific conditions of this production suite. I`ve ordered a pair of new shoes^W 2620v2-s which should arrive to me next Well I was testing on a pair of 'E5-2620 v2'; but as you saw my test case was pretty simple. If you can suggest any flags I should add etc to the test I'd be happy to give it a go. Dave Here is mine launch string: qemu-system-x86_64 -enable-kvm -name vmtest -S -machine pc-i440fx-2.1,accel=kvm,usb=off -cpu SandyBridge,+kvm_pv_eoi -m 512 -realtime mlock=off -smp 12,sockets=1,cores=12,threads=12 -numa node,nodeid=0,cpus=0-11,mem=512 -nographic -no-user-config -nodefaults -device sga -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device nec-usb-xhci,id=usb,bus=pci.0,addr=0x4 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -m 512,slots=31,maxmem=16384M -object memory-backend-ram,id=mem0,size=512M -device pc-dimm,id=dimm0,node=0,memdev=mem0 I omitted disk backend in this example, but there is a chance that my problem is not reproducible without some calls made explicitly by a bootloader (not sure what to say for mid-runtime failures). It seems to survive OK: Thanks David, I`ll go through test sequence and report. Unfortunately my orchestration does not have even a hundred millisecond precision for libvirt events, so I can`t tell if the immediate start-up failures happened before bootloader execution or during it, all I have for those is a less-than-two-second interval between actual pass of a launch command and paused state event. QEMU logging also does not give me timestamps for an emulation errors even with appropriate timestamp arg. while true; do (sleep 1; echo -e '\001cc\n'; sleep 5; echo -e 'q\n')|/opt/qemu-try-world3/bin/qemu-system-x86_64 -enable-kvm -name vmtest -S -machine pc-i440fx-2.1,accel=kvm,usb=off -cpu SandyBridge,+kvm_pv_eoi -m 512 -realtime mlock=off -smp 12,sockets=1,cores=12,threads=12 -numa node,nodeid=0,cpus=0-11,mem=512 -nographic -no-user-config -device sga -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device nec-usb-xhci,id=usb,bus=pci.0,addr=0x4 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -m 512,slots=31,maxmem=16384M -object memory-backend-ram,id=mem0,size=512M -device pc-dimm,id=dimm0,node=0,memdev=mem0 ~/pi.vfd 21 | tee /tmp/qemu.op; grep internal error /tmp/qemu.op -q break; done Dave Monday, so I`ll be able to test a) against 1.8.0-release, b) against patched bios code, c) reproduce initial error on master/3.19 (may be I`ll take them before weekend by going into this computer shop in person). Until then, I have a very deep feeling that mine issue is not there :) Also I became very curious on how a lack of IDT feature may completely eliminate the issue appearance for me, the only possible explanation is a clock-related race which is kinda stupid suggestion and unlikely to exist in nature. Thanks again for everyone for throughout testing and ideas! -Kevin --- a/src/romlayout.S +++ b/src/romlayout.S @@ -22,7 +22,8 @@ // %edx = return location (in 32bit mode) // Clobbers: ecx, flags, segment registers, cr0, idt/gdt
Re: [Qemu-devel] [PATCH] uapi/virtio_scsi: allow overriding CDB/SENSE size
On Wed, Mar 11, 2015 at 02:19:03PM +0100, Michael S. Tsirkin wrote:
QEMU wants to use virtio scsi structures with
a different VIRTIO_SCSI_CDB_SIZE/VIRTIO_SCSI_SENSE_SIZE,
let's add ifdefs to allow overriding them.
Keep the old defines under new names:
VIRTIO_SCSI_CDB_DEFAULT_SIZE/VIRTIO_SCSI_SENSE_DEFAULT_SIZE,
since that's what these values really are:
defaults for cdb/sense size fields.
Suggested-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
Rusty, pls note, if possible I'd like this one
merged for 4.0 because it's important for QEMU
(which now imports linux headers).
include/uapi/linux/virtio_scsi.h | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/include/uapi/linux/virtio_scsi.h
b/include/uapi/linux/virtio_scsi.h
index 42b9370..cc18ef8 100644
--- a/include/uapi/linux/virtio_scsi.h
+++ b/include/uapi/linux/virtio_scsi.h
@@ -29,8 +29,16 @@
#include linux/virtio_types.h
-#define VIRTIO_SCSI_CDB_SIZE 32
-#define VIRTIO_SCSI_SENSE_SIZE 96
+/* Default values of the CDB and sense data size configuration fields */
+#define VIRTIO_SCSI_CDB_DEFAULT_SIZE 32
+#define VIRTIO_SCSI_SENSE_DEFAULT_SIZE 96
+
+#ifndef VIRTIO_SCSI_CDB_SIZE
+#define VIRTIO_SCSI_CDB_SIZE VIRTIO_SCSI_CDB_DEFAULT_SIZE
+#endif
+#ifndef VIRTIO_SCSI_SENSE_SIZE
+#define VIRTIO_SCSI_SENSE_SIZE VIRTIO_SCSI_SENSE_DEFAULT_SIZE
+#endif
/* SCSI command request, followed by data-out */
struct virtio_scsi_cmd_req {
--
MST
Re: [Qemu-devel] [PATCH] virtio-pci: Clear IRQ at reset
On Thu, Mar 12, 2015 at 06:00:28PM +0800, Fam Zheng wrote:
On Thu, 03/12 10:41, Michael S. Tsirkin wrote:
On Thu, Mar 12, 2015 at 02:40:55PM +0800, Fam Zheng wrote:
Currently we could leave PCI IRQ asserted even after reset, it is safer
to clear it.
In the case that a buggy driver has disabled MSI-X unintentially, we may
have already injected IRQ in previous virtio_pci_notify, which will not
be cleared by guest because it doesn't expect it (i.e. no irq handler).
However the driver may eventually notice the unresponsiveness and reset
the device, at that point, clearing the irq is meaningful.
Signed-off-by: Fam Zheng f...@redhat.com
I don't think we care about buggy drivers being able to recover, but the
same would apply to e.g. kdump when using virtio blk/scsi after a crash,
correct?
OK, yes, get your point. And this also relates to the patch you replied
yesterday:
http://www.spinics.net/lists/kernel/msg1943182.html
About that one, I still don't know why it's necessary.
reboot causes a system reset and that will eventually
deassert an irq, no?
/*
The hanging problem, which is due to irq not being acknowledged, can only be
fixed by your patch if the irq is cleared at reset.
The uninterruptable process doesn't really matter, the system would still
shutdown, as long as the wrong irq is cleard.
See also RHBZ https://bugzilla.redhat.com/show_bug.cgi?id=1199155
*/
Fam
---
hw/virtio/virtio-pci.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index e7baf7b..2600f1e 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio/virtio-pci.c
@@ -988,6 +988,7 @@ static void virtio_pci_reset(DeviceState *qdev)
virtio_pci_stop_ioeventfd(proxy);
virtio_bus_reset(bus);
msix_unuse_all_vectors(proxy-pci_dev);
+pci_irq_deassert(proxy-pci_dev);
}
static Property virtio_pci_properties[] = {
--
1.9.3
[Qemu-devel] [PATCH v5 2/7] aer: impove pcie_aer_init to support vfio device
pcie_aer_init was used to emulate an aer capability for pcie device,
but for vfio device, the aer config space size is mutable and is not
always equal to PCI_ERR_SIZEOF(0x48). it depends on where the TLP Prefix
register required, so here we add a size argument.
Signed-off-by: Chen Fan chen.fan.f...@cn.fujitsu.com
---
hw/pci-bridge/ioh3420.c| 2 +-
hw/pci-bridge/xio3130_downstream.c | 2 +-
hw/pci-bridge/xio3130_upstream.c | 2 +-
hw/pci/pcie_aer.c | 4 ++--
include/hw/pci/pcie_aer.h | 2 +-
5 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/hw/pci-bridge/ioh3420.c b/hw/pci-bridge/ioh3420.c
index cce2fdd..4d9cd3f 100644
--- a/hw/pci-bridge/ioh3420.c
+++ b/hw/pci-bridge/ioh3420.c
@@ -129,7 +129,7 @@ static int ioh3420_initfn(PCIDevice *d)
goto err_pcie_cap;
}
pcie_cap_root_init(d);
-rc = pcie_aer_init(d, IOH_EP_AER_OFFSET);
+rc = pcie_aer_init(d, IOH_EP_AER_OFFSET, PCI_ERR_SIZEOF);
if (rc 0) {
goto err;
}
diff --git a/hw/pci-bridge/xio3130_downstream.c
b/hw/pci-bridge/xio3130_downstream.c
index b3a6479..9737041 100644
--- a/hw/pci-bridge/xio3130_downstream.c
+++ b/hw/pci-bridge/xio3130_downstream.c
@@ -92,7 +92,7 @@ static int xio3130_downstream_initfn(PCIDevice *d)
goto err_pcie_cap;
}
pcie_cap_arifwd_init(d);
-rc = pcie_aer_init(d, XIO3130_AER_OFFSET);
+rc = pcie_aer_init(d, XIO3130_AER_OFFSET, PCI_ERR_SIZEOF);
if (rc 0) {
goto err;
}
diff --git a/hw/pci-bridge/xio3130_upstream.c b/hw/pci-bridge/xio3130_upstream.c
index eada582..4d7f894 100644
--- a/hw/pci-bridge/xio3130_upstream.c
+++ b/hw/pci-bridge/xio3130_upstream.c
@@ -81,7 +81,7 @@ static int xio3130_upstream_initfn(PCIDevice *d)
}
pcie_cap_flr_init(d);
pcie_cap_deverr_init(d);
-rc = pcie_aer_init(d, XIO3130_AER_OFFSET);
+rc = pcie_aer_init(d, XIO3130_AER_OFFSET, PCI_ERR_SIZEOF);
if (rc 0) {
goto err;
}
diff --git a/hw/pci/pcie_aer.c b/hw/pci/pcie_aer.c
index 5a25c32..71045eb 100644
--- a/hw/pci/pcie_aer.c
+++ b/hw/pci/pcie_aer.c
@@ -94,12 +94,12 @@ static void aer_log_clear_all_err(PCIEAERLog *aer_log)
aer_log-log_num = 0;
}
-int pcie_aer_init(PCIDevice *dev, uint16_t offset)
+int pcie_aer_init(PCIDevice *dev, uint16_t offset, uint16_t size)
{
PCIExpressDevice *exp;
pcie_add_capability(dev, PCI_EXT_CAP_ID_ERR, PCI_ERR_VER,
-offset, PCI_ERR_SIZEOF);
+offset, size);
exp = dev-exp;
exp-aer_cap = offset;
diff --git a/include/hw/pci/pcie_aer.h b/include/hw/pci/pcie_aer.h
index bcac80a..a4cc6f3 100644
--- a/include/hw/pci/pcie_aer.h
+++ b/include/hw/pci/pcie_aer.h
@@ -87,7 +87,7 @@ struct PCIEAERErr {
extern const VMStateDescription vmstate_pcie_aer_log;
-int pcie_aer_init(PCIDevice *dev, uint16_t offset);
+int pcie_aer_init(PCIDevice *dev, uint16_t offset, uint16_t size);
void pcie_aer_exit(PCIDevice *dev);
void pcie_aer_write_config(PCIDevice *dev,
uint32_t addr, uint32_t val, int len);
--
1.9.3
Re: [Qemu-devel] [PATCH] virtio-pci: Clear IRQ at reset
On Thu, Mar 12, 2015 at 11:04:33AM +, Peter Maydell wrote:
On 12 March 2015 at 10:57, Michael S. Tsirkin m...@redhat.com wrote:
This isn't a device reset though.
The function that Fam is touching is called
when a special virtio reset register to
poked by the driver.
It only resets part of the device, not all of it,
and it seems reasonable to ask that it clear the
interrupt.
Oh, right, sorry. Yes, that should clear the interrupt, then.
(Is there a similar bug on other virtio transports?)
-- PMM
Hmm interesting.
I looked at virtio_reset and that one does:
vdev-isr = 0;
vdev-config_vector = VIRTIO_NO_VECTOR;
virtio_notify_vector(vdev, vdev-config_vector);
which in turn would call
static void virtio_pci_notify(DeviceState *d, uint16_t vector)
{
VirtIOPCIProxy *proxy = to_virtio_pci_proxy_fast(d);
if (msix_enabled(proxy-pci_dev))
msix_notify(proxy-pci_dev, vector);
else {
VirtIODevice *vdev = virtio_bus_get_device(proxy-bus);
pci_set_irq(proxy-pci_dev, vdev-isr 1);
}
}
since isr is 0, and msi is disabled, it looks like
pci_set_irq will get invoked automatically.
so at this point I stopped understanding how can
this patch help.
Fam, does your patch actually help some guests?
Could you pls investigate why isn't virtio_reset
sufficient?
--
MST
Re: [Qemu-devel] [PATCH 2/2 RFC] s390x/pci: rework pci infrastructure modeling
On Wed, Mar 11, 2015 at 06:42:34PM +0100, Michael S. Tsirkin wrote: On Wed, Mar 11, 2015 at 03:38:44PM +0100, Frank Blaschka wrote: On Tue, Mar 10, 2015 at 03:26:23PM +0100, Michael S. Tsirkin wrote: On Tue, Mar 10, 2015 at 02:03:34PM +0100, Frank Blaschka wrote: This patch changes the modeling of the s390 qemu pci infrastructure to better match the actual pci architecture defined by the real hardware. A pci host bridge like device (s390-pcihost) models the abstract view of the bare pci function. It provides s390 specific configuration attributes (fid and uid) for the attached pci device. The host bridge restrict the pci bus to just hold one single pci device. Also we have to make the s390 pci host bridge hot plugable. This requirement is really because of the 1 device per bus limitation, isn't it? If you supported many devices per bus, you could use hotplug there and there won't be need to support hotplug of the host bridge. Absolutely yes. Have you seen my first proposal? It basically exploits the normal pci bridge/bus/slot mechanism but need a place to store s390 specific configuration attributes. The idea of a host bridge having this attributes and limit the bus to one slot was an alternate design approach suggested by Alex. I like Alex's idea because: 1) It reflects pretty well the actual nature of the pci system in real s390 hw 2) It does not create an somehow artifical pci topology I'll have to re-read but here's a thought: use your patch but remove host bridge hotplug support code. Stick a standard bridge with shpc support in the single slot behind your host bridge (existing pci-bridge-dev should do the trick, though not many people use it, so you might run into bugs, but fixing them is a good idea anyway). You can instanciate it automatically like Marcel's patches do for PXB. Still don't undertsand so I try to summarize in my words please corrent me if I got something wrong - create a standard host bridge - change the s390-pcihost to be a pci 2 pci bridge - now we can hotplug the s390-pcihost + hotplug a pci device to this s390-pcihost using standard pci hotplug mechanism - we keep the 1 slot limit on the s390-pcihost. We need a place to store fid and uid information (see mail thread from my 1 proposal) - If we need more than 32 pci functions we have to extend the primary pci bus via standart pci 2 pci bridges or add another standart host bridge Is this your suggestion? You get hotplug + multiple devices for free. And the resulting topology is clearly something that *can* exist on bare-metal, since no one can prevent users sticking a pci bridge device in a pci slot. Again on bar s390 metal we do not have bridge bus slot at all. OS does not have any knowledge about it. So anything we try to model is somehow artificial. Why do I prefer pci hotplug to s390 hotplug? s390 hotplug is really surprise removal. There's no way Don't understand this neither. s390 linux kernel is well prepared to receive s390 specific events to signal a pci function is going away. Anyhow we end up I can generate this events to get ack from guest. Linux isn't very well equipped to handle that, we might be able to fix it with time but current virtio drivers aren't very happy. This is done by implementing a s390 specific bus to attach this new host bridge like devices. Sample qemu configuration: -device s390-pcihost,fid=16,uid=2216 -device e1000,bus=pci.0 -device s390-pcihost,fid=17,uid=2217,id=mydev -device ne2k_pci,bus=mydev.0,addr=0 A pci device references the corresponding host bridge via pci bus name (as usual). The pci device must be attached to slot 0 of the bus. The fid and uid must be unique for the qemu instance. The design allows to define (static and hotplug) multiple host bridges and support a large number of pci devices. How about sticking a pci to pci bridge behind the host bridge? You could also support hotplug using shpc, all this without writing code. Hm, I don't understand this in detail, can you elaborate a little bit more on this? For me it looks like this has the same issues like my first proposal. We build a complete artifical pci topology in qemu, which has nothing to do with the real hw. If we include pci 2 pci bridges this makes configuration even more a nightmare for users. Do you think detangle pci bus from bridge breaks some fundamental design? If so, I would rather go with my first proposal than adding even more complexity to implementation and configuration. Thx, Frank Signed-off-by: Frank Blaschka blasc...@linux.vnet.ibm.com --- hw/s390x/s390-pci-bus.c| 174 ++--- hw/s390x/s390-pci-bus.h| 24 ++- hw/s390x/s390-pci-inst.c | 2 +- hw/s390x/s390-virtio-ccw.c | 4 +-
Re: [Qemu-devel] [PULL 00/25] misc fixes and cleanups
On 11 March 2015 at 19:50, Michael S. Tsirkin m...@redhat.com wrote: OK, doing a pull request now before it grows up to be another 100 patch monster. And the virtio scsi bug at least blocks some testers, so there's some urgency. Pls pull. The following changes since commit 8437f7be3b1c49631e435c652707f2cee477149d: Merge remote-tracking branch 'remotes/mjt/tags/pull-trivial-patches-2015-03-04' into staging (2015-03-10 11:44:59 +) are available in the git repository at: git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git tags/for_upstream for you to fetch changes up to 18bf9e2f379334306530cbfd44218748eceaf67d: virtio-scsi: remove empty wrapper for cmd (2015-03-11 18:24:30 +0100) misc fixes and cleanups A bunch of fixes all over the place, some of the bugs fixed are actually regressions. Signed-off-by: Michael S. Tsirkin m...@redhat.com Applied, thanks. -- PMM
[Qemu-devel] [PATCH v5 7/7] pc: add PC_I440FX_COMPAT to disable aercap for vifo device
for piix4 chipset, we don't need to expose aer, so introduce
PC_I440FX_COMPAT for all piix4 machines to disable aercap,
and add HW_COMPAT_2_2 to disable aercap for all lower
than 2.3.
Signed-off-by: Chen Fan chen.fan.f...@cn.fujitsu.com
---
hw/i386/pc_piix.c | 9 +
hw/i386/pc_q35.c| 4
include/hw/compat.h | 10 ++
3 files changed, 23 insertions(+)
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 8eab4ba..ff9d312 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -307,6 +307,11 @@ static void pc_init1(MachineState *machine,
static void pc_init_pci(MachineState *machine)
{
+static GlobalProperty pc_compat_props[] = {
+PC_I440FX_COMPAT,
+{ /* end of list */ }
+};
+qdev_prop_register_global_list(pc_compat_props);
pc_init1(machine, 1, 1);
}
@@ -534,6 +539,10 @@ static QEMUMachine pc_i440fx_machine_v2_2 = {
PC_I440FX_2_2_MACHINE_OPTIONS,
.name = pc-i440fx-2.2,
.init = pc_init_pci_2_2,
+.compat_props = (GlobalProperty[]) {
+HW_COMPAT_2_2,
+{ /* end of list */ }
+},
};
#define PC_I440FX_2_1_MACHINE_OPTIONS \
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index c0f21fe..97afb7d 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -431,6 +431,10 @@ static QEMUMachine pc_q35_machine_v2_2 = {
PC_Q35_2_2_MACHINE_OPTIONS,
.name = pc-q35-2.2,
.init = pc_q35_init_2_2,
+.compat_props = (GlobalProperty[]) {
+HW_COMPAT_2_2,
+{ /* end of list */ }
+},
};
#define PC_Q35_2_1_MACHINE_OPTIONS \
diff --git a/include/hw/compat.h b/include/hw/compat.h
index 313682a..40c974a 100644
--- a/include/hw/compat.h
+++ b/include/hw/compat.h
@@ -1,7 +1,17 @@
#ifndef HW_COMPAT_H
#define HW_COMPAT_H
+#define HW_COMPAT_2_2 PC_I440FX_COMPAT
+
+#define PC_I440FX_COMPAT \
+{\
+.driver = vfio-pci,\
+.property = x-aer,\
+.value= off,\
+}
+
#define HW_COMPAT_2_1 \
+HW_COMPAT_2_2, \
{\
.driver = intel-hda,\
.property = old_msi_addr,\
--
1.9.3
[Qemu-devel] [PATCH v5 0/7] pass aer error to guest for vfio device
For now, for vfio pci passthough devices when qemu receives an error from host aer report, there just terminate the guest, but usually user want to know what error occurred but stop the guest, so this patches add aer capability support for vfio device, and pass the error to guest, and have guest driver to recover from the error. and turning on SERR# for error forwording in bridge control register patch in seabios has been merged. v3-v4: 1. add 'x-aer' for user to off aer capability. 2. refactor vfio device to parse extended capabilities. v2-v3: 1. refactor vfio device to parse extended capability. 2. add global property for piix4 to disable vfio aer cap. v1-v2: 1. turn on SERR# for bridge control register in firmware. 2. initilize aer capability for vfio device. 3. fix some trivial bug. Chen Fan (7): vfio: add pcie extanded capability support aer: impove pcie_aer_init to support vfio device vfio: add aer support for vfio device pcie_aer: expose pcie_aer_msg() interface vfio-pci: pass the aer error to guest vfio: add 'x-aer' property to expose aercap pc: add PC_I440FX_COMPAT to disable aercap for vifo device hw/i386/pc_piix.c | 9 +++ hw/i386/pc_q35.c | 4 + hw/pci-bridge/ioh3420.c| 2 +- hw/pci-bridge/xio3130_downstream.c | 2 +- hw/pci-bridge/xio3130_upstream.c | 2 +- hw/pci/pcie_aer.c | 6 +- hw/vfio/pci.c | 158 +++-- include/hw/compat.h| 10 +++ include/hw/pci/pcie_aer.h | 3 +- 9 files changed, 182 insertions(+), 14 deletions(-) -- 1.9.3
[Qemu-devel] [PATCH v5 6/7] vfio: add 'x-aer' property to expose aercap
add 'x-aer' property to let user able to decide whether expose
the aer capability.
Signed-off-by: Chen Fan chen.fan.f...@cn.fujitsu.com
---
hw/vfio/pci.c | 8
1 file changed, 8 insertions(+)
diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index 8966c49..0517091 100644
--- a/hw/vfio/pci.c
+++ b/hw/vfio/pci.c
@@ -159,6 +159,8 @@ typedef struct VFIOPCIDevice {
#define VFIO_FEATURE_ENABLE_VGA (1 VFIO_FEATURE_ENABLE_VGA_BIT)
#define VFIO_FEATURE_ENABLE_REQ_BIT 1
#define VFIO_FEATURE_ENABLE_REQ (1 VFIO_FEATURE_ENABLE_REQ_BIT)
+#define VFIO_FEATURE_ENABLE_AER_BIT 2
+#define VFIO_FEATURE_ENABLE_AER (1 VFIO_FEATURE_ENABLE_AER_BIT)
int32_t bootindex;
uint8_t pm_cap;
bool has_vga;
@@ -2731,6 +2733,10 @@ static int vfio_setup_aer(VFIOPCIDevice *vdev, int pos,
uint16_t size)
uint32_t severity, errcap;
int ret;
+if (!(vdev-features VFIO_FEATURE_ENABLE_AER)) {
+return 0;
+}
+
errcap = vfio_pci_read_config(pdev, pdev-exp.aer_cap + PCI_ERR_CAP, 4);
/* The ability to record multiple headers is depending on
the state of the Multiple Header Recording Capable bit and
@@ -3691,6 +3697,8 @@ static Property vfio_pci_dev_properties[] = {
VFIO_FEATURE_ENABLE_VGA_BIT, false),
DEFINE_PROP_BIT(x-req, VFIOPCIDevice, features,
VFIO_FEATURE_ENABLE_REQ_BIT, true),
+DEFINE_PROP_BIT(x-aer, VFIOPCIDevice, features,
+VFIO_FEATURE_ENABLE_AER_BIT, true),
DEFINE_PROP_INT32(bootindex, VFIOPCIDevice, bootindex, -1),
DEFINE_PROP_BOOL(x-mmap, VFIOPCIDevice, vbasedev.allow_mmap, true),
/*
--
1.9.3
Re: [Qemu-devel] [RFC v4 4/9] aer: impove pcie_aer_init to support vfio device
On 03/10/2015 04:29 AM, Alex Williamson wrote:
On Mon, 2015-03-02 at 15:16 +0800, Chen Fan wrote:
extend pcie_aer_init arguments to adjust vfio device.
Some discussion of why vfio wants this would be useful.
I remain this patch at the latest v5. and add the 'size' argument,
because, the aer config space is not fixed. the TLP Prefix Log Register
is not always implemented. for instance, my local network device:
Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI
Express Gigabit Ethernet controller,
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Virtual Channel
the size is 0x40.
So I think we need a size argument indeed.
Thanks,
Chen
Signed-off-by: Chen Fan chen.fan.f...@cn.fujitsu.com
---
hw/pci-bridge/ioh3420.c| 3 ++-
hw/pci-bridge/xio3130_downstream.c | 3 ++-
hw/pci-bridge/xio3130_upstream.c | 3 ++-
hw/pci/pcie_aer.c | 7 ---
include/hw/pci/pcie_aer.h | 4 +++-
5 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/hw/pci-bridge/ioh3420.c b/hw/pci-bridge/ioh3420.c
index cce2fdd..354574f 100644
--- a/hw/pci-bridge/ioh3420.c
+++ b/hw/pci-bridge/ioh3420.c
@@ -129,7 +129,8 @@ static int ioh3420_initfn(PCIDevice *d)
goto err_pcie_cap;
}
pcie_cap_root_init(d);
-rc = pcie_aer_init(d, IOH_EP_AER_OFFSET);
+rc = pcie_aer_init(d, PCI_ERR_VER,
+ IOH_EP_AER_OFFSET, PCI_ERR_SIZEOF);
if (rc 0) {
goto err;
}
diff --git a/hw/pci-bridge/xio3130_downstream.c
b/hw/pci-bridge/xio3130_downstream.c
index b3a6479..407f75f 100644
--- a/hw/pci-bridge/xio3130_downstream.c
+++ b/hw/pci-bridge/xio3130_downstream.c
@@ -92,7 +92,8 @@ static int xio3130_downstream_initfn(PCIDevice *d)
goto err_pcie_cap;
}
pcie_cap_arifwd_init(d);
-rc = pcie_aer_init(d, XIO3130_AER_OFFSET);
+rc = pcie_aer_init(d, PCI_ERR_VER,
+ XIO3130_AER_OFFSET, PCI_ERR_SIZEOF);
if (rc 0) {
goto err;
}
diff --git a/hw/pci-bridge/xio3130_upstream.c b/hw/pci-bridge/xio3130_upstream.c
index eada582..52b130f 100644
--- a/hw/pci-bridge/xio3130_upstream.c
+++ b/hw/pci-bridge/xio3130_upstream.c
@@ -81,7 +81,8 @@ static int xio3130_upstream_initfn(PCIDevice *d)
}
pcie_cap_flr_init(d);
pcie_cap_deverr_init(d);
-rc = pcie_aer_init(d, XIO3130_AER_OFFSET);
+rc = pcie_aer_init(d, PCI_ERR_VER,
+ XIO3130_AER_OFFSET, PCI_ERR_SIZEOF);
if (rc 0) {
goto err;
}
diff --git a/hw/pci/pcie_aer.c b/hw/pci/pcie_aer.c
index ece1487..a76a943 100644
--- a/hw/pci/pcie_aer.c
+++ b/hw/pci/pcie_aer.c
@@ -94,12 +94,13 @@ static void aer_log_clear_all_err(PCIEAERLog *aer_log)
aer_log-log_num = 0;
}
-int pcie_aer_init(PCIDevice *dev, uint16_t offset)
+int pcie_aer_init(PCIDevice *dev, uint8_t cap_ver,
+ uint16_t offset, uint16_t size)
{
PCIExpressDevice *exp;
-pcie_add_capability(dev, PCI_EXT_CAP_ID_ERR, PCI_ERR_VER,
-offset, PCI_ERR_SIZEOF);
+pcie_add_capability(dev, PCI_EXT_CAP_ID_ERR,
+cap_ver, offset, size);
exp = dev-exp;
exp-aer_cap = offset;
diff --git a/include/hw/pci/pcie_aer.h b/include/hw/pci/pcie_aer.h
index bcac80a..afa074e 100644
--- a/include/hw/pci/pcie_aer.h
+++ b/include/hw/pci/pcie_aer.h
@@ -87,7 +87,9 @@ struct PCIEAERErr {
extern const VMStateDescription vmstate_pcie_aer_log;
-int pcie_aer_init(PCIDevice *dev, uint16_t offset);
+int pcie_aer_init(PCIDevice *dev, uint8_t cap_ver,
+ uint16_t offset, uint16_t size);
+
void pcie_aer_exit(PCIDevice *dev);
void pcie_aer_write_config(PCIDevice *dev,
uint32_t addr, uint32_t val, int len);
.
Re: [Qemu-devel] [PATCH 1/3] pcie_aer: fix typos in pcie_aer_inject_error comment
On 03/10/2015 10:57 PM, Michael S. Tsirkin wrote: On Tue, Mar 10, 2015 at 09:34:58AM +0300, Michael Tokarev wrote: 10.03.2015 04:49, Chen Fan пишет: Refer to PCI Express Base Spec3.0, this comments can't fit the description in spec, so we should fix them. Signed-off-by: Chen Fan chen.fan.f...@cn.fujitsu.com --- hw/pci/pcie_aer.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/hw/pci/pcie_aer.c b/hw/pci/pcie_aer.c index 1f4be16..7ca077a 100644 --- a/hw/pci/pcie_aer.c +++ b/hw/pci/pcie_aer.c @@ -618,11 +618,11 @@ static bool pcie_aer_inject_uncor_error(PCIEAERInject *inj, bool is_fatal) * non-Function specific error must be recorded in all functions. * It is the responsibility of the caller of this function. * It is also caller's responsibility to determine which function should - * report the rerror. + * report the error. * * 6.2.4 Error Logging - * 6.2.5 Sqeunce of Device Error Signaling and Logging Operations - * table 6-2: Flowchard Showing Sequence of Device Error Signaling and Logging + * 6.2.5 Sequence of Device Error Signaling and Logging Operations + * table 6-2: Flowchart Showing Sequence of Device Error Signaling and Logging *Operations this 6-2 is not a table, it is Figure 6-2 on page 479, unless, ofcourse, you mean Table 6-2: General PCI Express Error List on page 481. I can fix this when applying. Thanks, /mjt OK so you want to take all 3 patches? Hi mjt, can you check in these patch? Thanks, Chen */ int pcie_aer_inject_error(PCIDevice *dev, const PCIEAERErr *err) .
Re: [Qemu-devel] [PULL v2 0/5] sdl patch queue.
On 12 March 2015 at 10:48, Gerd Hoffmann kra...@redhat.com wrote: Hi, Still fails to build on OSX: manooth$ make -C build/all CClm32-softmmu/hw/lm32/milkymist.o In file included from /Users/pm215/src/qemu/hw/lm32/milkymist.c:30: /Users/pm215/src/qemu/hw/lm32/milkymist-hw.h:90:10: fatal error: 'X11/Xlib.h' file not found #include X11/Xlib.h ^ 1 error generated. Does the attached patch fix it? That patch doesn't apply, because it does: - opengl_pkgs=egl gl glesv2 + opengl_pkgs=glx egl gl glesv2 but the configure as of your pull req has just: opengl_pkgs=gl -- PMM
Re: [Qemu-devel] [PULL v3 00/13] Net patches
On 12 March 2015 at 12:19, Stefan Hajnoczi stefa...@redhat.com wrote: v3: * Add clang 3.5.0 warning fixes * Squash David Ahern's clang struct definition warnings fix v2: * Squash in Jiri's fix for rocker format string specifiers [Peter] * Squash in Windows build fix [Peter] * Both build fixes are described in rocker: add new rocker switch device The following changes since commit ee74801035b0b5f1fdfd4e31d3a53f511f91c804: Merge remote-tracking branch 'remotes/lalrae/tags/mips-20150311' into staging (2015-03-11 18:22:15 +) are available in the git repository at: git://github.com/stefanha/qemu.git tags/net-pull-request for you to fetch changes up to 92935abc6b4f5b9eec6607879bfbfafa5c367494: rocker: timestamp on the debug logs helps correlate with events in the VM (2015-03-12 10:55:22 +) Pull request This makes OSX builds incredibly noisy because every compile now warns: CChw/net/dp8393x.o warning: unknown warning option '-Wno-unknown-attributes'; did you mean '-Wno-ignored-attributes'? [-Wunknown-warning-option] -- PMM
Re: [Qemu-devel] [PATCH 0/1] Get the list of arguments from a QMP command
Am 11.03.2015 um 20:22 hat Markus Armbruster geschrieben:
Alberto Garcia be...@igalia.com writes:
On Wed, Mar 11, 2015 at 11:21:43AM +0100, Markus Armbruster wrote:
I can actually try to implement full introspection support, but I
would like to know what API you would like. Something like this?
'query-commands'
'query-enums'
'query-events'
'query-types'
'query-unions'
You propose a separate query-FOO for each kind of thing in the
schema: command, event, the various types. Not fundamentally
different to a single query-schema. We can discuss which of the two
approaches is easier to use.
I don't think it makes much difference in terms of complexity
from the QEMU side. I proposed those because query-commands and
query-events already exist, so adding the missing ones seemed the most
straightforward solution to me.
They only tell you what commands and events exist, but nothing about
their 'data' or 'returns'.
True, but luckily they were defined to return not just a list of
strings, but of CommandInfo dicts. So extending that seems to be the
natural option in order to get a coherent interface in the end.
But if query-schema is more convenient I don't have any problem with
that.
The real work is processing the full schema into the externally visible
sub-schema. Whether to split it into several parts for presentation is
the least of my worries.
I'm fine with with building up introspection step by step. But I want
us to have a reasonable idea of the end result. Without that,
incremental development together with our ABI promise is prone to
produce a tangled mess. We already have enough of those :)
Okay. Let's try to define just enough to get a reasonable idea of the
end result.
Let's start with the commands that we will have, without looking at
the structure of their arguments and return values yet:
* query-commands, which returns a list of CommandInfos. This contains at
least the name of each command. (Mandated by backwards compatibility
requirements)
* query-events, which returns a list of EventInfos. This contains at
least the name of each event. (Mandated by backwards compatibility
requirements)
* Something to query the full description of commands, including the
type of their return value and name, type and optionality of their
arguments.
I propose combining this with query-commands by extending CommandInfo.
* Something to query QAPI types, including:
- The fields of a complex type, including their name, type and
optionality.
I propose that this information be returned in a structure analogous
to how arguments are described in query-commands, whatever that may
be.
- The possible values of an enum type
- Union types are complex (sorry, my bad), we probably don't want to
expose them the way they are in the schema. This needs more thought.
The details of how each type is described, as well as the exact
command to query it, aren't of importance for adding command argument
querying and shouldn't affect it, so I'd leave that for later.
What I do propose is that in order to maintain consistency with the
already existing query-{commands,events}, we introduct a separate
command for these. This may be a single 'query-types', but it could
also be 'query-complex-types'/'query-enums'/'query-unions'.
Unless you think it makes a difference for defining what we need now,
I think we can leave this question open.
* Possibly something to query the fields of events, if we ever need
that (I doubt it). If we do, in consistency with the above I propose
extending EventInfo and exposing the information the same way as for
command arguments and complex type fields.
Do you agree so far?
Anything else you want to get answered before you think you have a
reasonable idea of the end result on the high level?
If not, the next step would be to define the exact structure of each
command. I for one don't think that there is a need to define it for all
of the commands now, but you may think otherwise?
If so, putting together the schema for the query commands (without
implementing them yet) shouldn't be that hard and I'd be happy to do
that. Perhaps with the exception of union types, but if you think it's
important, I can propose something for them, too.
I feel a necessary early step is to actually define our schema language,
and separate syntactic sugar from its core. Introspection wants the
core, but for schema development, a modest amount of sugar is
convenient. Some of the current schema syntax needs to be redefined as
sugar for a suitable desugared form. We've discussed this for asterisk
means optional already. Eric's series brings us closer, it just needs
to be finished.
Our schema language is an implementation detail, we shouldn't worry
about it too much in this discussion. As long as we agree that arguments
do have a name, a type and a boolean that
Re: [Qemu-devel] [PULL v3 00/13] Net patches
On 12 March 2015 at 12:37, Peter Maydell peter.mayd...@linaro.org wrote: On 12 March 2015 at 12:19, Stefan Hajnoczi stefa...@redhat.com wrote: v3: * Add clang 3.5.0 warning fixes * Squash David Ahern's clang struct definition warnings fix v2: * Squash in Jiri's fix for rocker format string specifiers [Peter] * Squash in Windows build fix [Peter] * Both build fixes are described in rocker: add new rocker switch device The following changes since commit ee74801035b0b5f1fdfd4e31d3a53f511f91c804: Merge remote-tracking branch 'remotes/lalrae/tags/mips-20150311' into staging (2015-03-11 18:22:15 +) are available in the git repository at: git://github.com/stefanha/qemu.git tags/net-pull-request for you to fetch changes up to 92935abc6b4f5b9eec6607879bfbfafa5c367494: rocker: timestamp on the debug logs helps correlate with events in the VM (2015-03-12 10:55:22 +) Pull request This makes OSX builds incredibly noisy because every compile now warns: CChw/net/dp8393x.o warning: unknown warning option '-Wno-unknown-attributes'; did you mean '-Wno-ignored-attributes'? [-Wunknown-warning-option] Also fails to build for w32: CCutil/cutils.o cc1: error: unrecognized command line option -Wno-unknown-attributes and for x86/clang: CCqga/commands.o error: unknown warning option '-Wno-unknown-attributes'; did you mean '-Wno-ignored-attributes'? [-Werror,-Wunknown-warning-option] -- PMM
[Qemu-devel] [PULL v4 02/11] tests: rtl8139: test timers and interrupt
From: Frediano Ziglio fredd...@gmail.com
Test behaviour of timers and interrupts related to timeouts.
Signed-off-by: Frediano Ziglio fredd...@gmail.com
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
Message-id: 1420742303-3030-1-git-send-email-fredd...@gmail.com
Signed-off-by: Stefan Hajnoczi stefa...@redhat.com
---
tests/Makefile | 2 +-
tests/rtl8139-test.c | 181 +++
2 files changed, 182 insertions(+), 1 deletion(-)
diff --git a/tests/Makefile b/tests/Makefile
index 588f438..1ef95c9 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -332,7 +332,7 @@ tests/tmp105-test$(EXESUF): tests/tmp105-test.o
$(libqos-omap-obj-y)
tests/i440fx-test$(EXESUF): tests/i440fx-test.o $(libqos-pc-obj-y)
tests/fw_cfg-test$(EXESUF): tests/fw_cfg-test.o $(libqos-pc-obj-y)
tests/e1000-test$(EXESUF): tests/e1000-test.o
-tests/rtl8139-test$(EXESUF): tests/rtl8139-test.o
+tests/rtl8139-test$(EXESUF): tests/rtl8139-test.o $(libqos-pc-obj-y)
tests/pcnet-test$(EXESUF): tests/pcnet-test.o
tests/eepro100-test$(EXESUF): tests/eepro100-test.o
tests/vmxnet3-test$(EXESUF): tests/vmxnet3-test.o
diff --git a/tests/rtl8139-test.c b/tests/rtl8139-test.c
index f6a1be3..4e0bf02 100644
--- a/tests/rtl8139-test.c
+++ b/tests/rtl8139-test.c
@@ -10,19 +10,200 @@
#include glib.h
#include string.h
#include libqtest.h
+#include libqos/pci-pc.h
#include qemu/osdep.h
+#include qemu-common.h
/* Tests only initialization so far. TODO: Replace with functional tests */
static void nop(void)
{
}
+#define CLK 3300
+#define NS_PER_SEC 10ULL
+
+static QPCIBus *pcibus;
+static QPCIDevice *dev;
+static void *dev_base;
+
+static void save_fn(QPCIDevice *dev, int devfn, void *data)
+{
+QPCIDevice **pdev = (QPCIDevice **) data;
+
+*pdev = dev;
+}
+
+static QPCIDevice *get_device(void)
+{
+QPCIDevice *dev;
+
+pcibus = qpci_init_pc();
+qpci_device_foreach(pcibus, 0x10ec, 0x8139, save_fn, dev);
+g_assert(dev != NULL);
+
+return dev;
+}
+
+#define PORT(name, len, val) \
+static unsigned __attribute__((unused)) in_##name(void) \
+{ \
+unsigned res = qpci_io_read##len(dev, dev_base+(val)); \
+g_test_message(*%s - %x\n, #name, res); \
+return res; \
+} \
+static void out_##name(unsigned v) \
+{ \
+g_test_message(%x - *%s\n, v, #name); \
+qpci_io_write##len(dev, dev_base+(val), v); \
+}
+
+PORT(Timer, l, 0x48)
+PORT(IntrMask, w, 0x3c)
+PORT(IntrStatus, w, 0x3E)
+PORT(TimerInt, l, 0x54)
+
+#define fatal(...) do { g_test_message(__VA_ARGS__); g_assert(0); } while (0)
+
+static void test_timer(void)
+{
+const unsigned from = 0.95 * CLK;
+const unsigned to = 1.6 * CLK;
+unsigned prev, curr, next;
+unsigned cnt, diff;
+
+out_IntrMask(0);
+
+in_IntrStatus();
+in_Timer();
+in_Timer();
+
+/* Test 1. test counter continue and continue */
+out_TimerInt(0); /* disable timer */
+out_IntrStatus(0x4000);
+out_Timer(12345); /* reset timer to 0 */
+curr = in_Timer();
+if (curr 0.1 * CLK) {
+fatal(time too big %u\n, curr);
+}
+for (cnt = 0; ; ) {
+clock_step(1 * NS_PER_SEC);
+prev = curr;
+curr = in_Timer();
+
+/* test skip is in a specific range */
+diff = (curr-prev) 0xu;
+if (diff from || diff to) {
+fatal(Invalid diff %u (%u-%u)\n, diff, from, to);
+}
+if (curr prev ++cnt == 3) {
+break;
+}
+}
+
+/* Test 2. Check we didn't get an interrupt with TimerInt == 0 */
+if (in_IntrStatus() 0x4000) {
+fatal(got an interrupt\n);
+}
+
+/* Test 3. Setting TimerInt to 1 and Timer to 0 get interrupt */
+out_TimerInt(1);
+out_Timer(0);
+clock_step(40);
+if ((in_IntrStatus() 0x4000) == 0) {
+fatal(we should have an interrupt here!\n);
+}
+
+/* Test 3. Check acknowledge */
+out_IntrStatus(0x4000);
+if (in_IntrStatus() 0x4000) {
+fatal(got an interrupt\n);
+}
+
+/* Test. Status set after Timer reset */
+out_Timer(0);
+out_TimerInt(0);
+out_IntrStatus(0x4000);
+curr = in_Timer();
+out_TimerInt(curr + 0.5 * CLK);
+clock_step(1 * NS_PER_SEC);
+out_Timer(0);
+if ((in_IntrStatus() 0x4000) == 0) {
+fatal(we should have an interrupt here!\n);
+}
+
+/* Test. Status set after TimerInt reset */
+out_Timer(0);
+out_TimerInt(0);
+out_IntrStatus(0x4000);
+curr = in_Timer();
+out_TimerInt(curr + 0.5 * CLK);
+clock_step(1 * NS_PER_SEC);
+out_TimerInt(0);
+if ((in_IntrStatus() 0x4000) == 0) {
+fatal(we should have an interrupt here!\n);
+}
+
+/* Test 4. Increment TimerInt we should see an interrupt */
+curr = in_Timer();
+next = curr + 5.0 * CLK;
+out_TimerInt(next);
+for (cnt = 0; ; ) {
+clock_step(1 * NS_PER_SEC);
+prev = curr;
+curr = in_Timer();
+diff = (curr-prev)
Re: [Qemu-devel] [PATCH] queue: fix QSLIST_INSERT_HEAD_ATOMIC race
On Tue, Mar 10, 2015 at 04:45:57PM +0100, Paolo Bonzini wrote: There is a not-so-subtle race in QSLIST_INSERT_HEAD_ATOMIC. Because atomic_cmpxchg returns the old value instead of a success flag, QSLIST_INSERT_HEAD_ATOMIC was checking for success by comparing against the second argument to atomic_cmpxchg. Unfortunately, this only works if the second argument is a local or thread-local variable. If it is in memory, it can be subject to common subexpression elimination (and then everything's fine) or reloaded after the atomic_cmpxchg, depending on the compiler's whims. If the latter happens, the race can happen. A thread can sneak in, doing something on elm-field.sle_next after the atomic_cmpxchg and before the comparison. This causes a wrong failure, and then two threads are using elm at the same time. In the case discovered by Christian, the sequence was likely something like this: thread 1 | thread 2 QSLIST_INSERT_HEAD_ATOMIC | atomic_cmpxchg succeeds | elm added to list| | steal release_pool | QSLIST_REMOVE_HEAD | elm removed from list | ... | QSLIST_INSERT_HEAD_ATOMIC | (overwrites sle_next) spurious failure | atomic_cmpxchg succeeds | elm added to list again | | steal release_pool | QSLIST_REMOVE_HEAD | elm removed again | The last three steps could be done by a third thread as well. A reproducer that failed in a matter of seconds is as follows: - the guest has 32 VCPUs on a 28 core host (hyperthreading was enabled), memory was 16G just to err on the safe side (the host has 64G, but hey at least you need no s390) - the guest has 24 null-aio virtio-blk devices using dataplane (-object iothread,id=ioN -drive if=none,id=blkN,driver=null-aio,size=500G -device virtio-blk-pci,iothread=ioN,drive=blkN) - the guest also has a single network interface. It's only doing loopback tests so slirp vs. tap and the model doesn't matter. - the guest is running fio with the following script: [global] rw=randread blocksize=16k ioengine=libaio runtime=10m buffered=0 fallocate=none time_based iodepth=32 [virtio1a] filename=/dev/block/252\:16 [virtio1b] filename=/dev/block/252\:16 ... [virtio24a] filename=/dev/block/252\:384 [virtio24b] filename=/dev/block/252\:384 [listen1] protocol=tcp ioengine=net port=12345 listen rw=read bs=4k size=1000g [connect1] protocol=tcp hostname=localhost ioengine=net port=12345 protocol=tcp rw=write startdelay=1 size=1000g ... [listen8] protocol=tcp ioengine=net port=12352 listen rw=read bs=4k size=1000g [connect8] protocol=tcp hostname=localhost ioengine=net port=12352 rw=write startdelay=1 size=1000g Moral of the story: I should refrain from writing more clever stuff. At least it looks like it is not too clever to be undebuggable. Reported-by: Christian Borntraeger borntrae...@de.ibm.com Fixes: c740ad92d0d958fa785e5d7aa1b67ecaf30a6a54 Signed-off-by: Paolo Bonzini pbonz...@redhat.com --- include/qemu/queue.h | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) Reviewed-by: Stefan Hajnoczi stefa...@redhat.com pgpm4HgalHhs5.pgp Description: PGP signature
Re: [Qemu-devel] [Qemu-block] [PATCH 0/2] AHCI: avoid mapping stale guest memory
On Tue, Mar 10, 2015 at 05:29:02PM -0400, John Snow wrote: Currently, the AHCI device tries to re-map guest memory every time the low or high address registers are written to, whether or not the AHCI device is currently active. If the other register has stale information in it, this may lead to runtime failures. Reconfigure the AHCI device to ignore writes to these registers while the device is active, and otherwise postpone the dma memory map until the device becomes active. John Snow (2): AHCI: Do not (re)map FB/CLB buffers while not running AHCI: Protect cmd register hw/ide/ahci.c | 61 --- hw/ide/ahci.h | 2 ++ 2 files changed, 48 insertions(+), 15 deletions(-) By the way, despite the compiler warning and my comment, I'd like to get a fix into QEMU 2.3. I'll be away Friday 13th and Monday 16th of March, so please go ahead without me. Kevin could review. Stefan pgpaK_wTwyoYx.pgp Description: PGP signature
Re: [Qemu-devel] [PATCH 0/6] [PREVIEW] s390x/kvm: fixes and features
On Thu, Mar 12, 2015 at 01:53:48PM +0100, Jens Freimann wrote: Sorry, please ignore the PREVIEW in the subject which I should have removed before sending the patches. Jens Conny, Alex, Christian, a few more s390 patches: Patch 1: encapsulates the HAS_DEVICE check into a generic function Patch 2: use the function introduced in Patch 1 Patch 3: introduces two new machine options for indicating the state of AES/DEA key wrapping functions Patch 4 and 5: remove dead code Patch 6: fill in length for sei_nt2 event regards Jens Dominik Dingel (3): kvm: encapsulate HAS_DEVICE for vm attrs s390x/kvm: make use of generic vm attribute check s390x/ipl: remove dead code Frank Blaschka (1): s390x/pci: fix length in sei_nt2 event Thomas Huth (1): s390x/virtio-bus: Remove unused function s390_virtio_bus_console() Tony Krowiak (1): s390x: CPACF: Handle key wrap machine options hw/s390x/ipl.c | 3 -- hw/s390x/s390-pci-bus.c| 1 + hw/s390x/s390-virtio-bus.c | 5 --- hw/s390x/s390-virtio-bus.h | 1 - hw/s390x/s390-virtio-ccw.c | 63 +++ include/sysemu/kvm.h | 12 ++ kvm-all.c | 21 +++ qemu-options.hx| 12 +- target-s390x/kvm.c | 93 +- 9 files changed, 166 insertions(+), 45 deletions(-) -- 2.1.4
Re: [Qemu-devel] [PATCH v2] hmp: add info iothreads command
On Thu, Mar 12, 2015 at 04:35:24PM +0800, Ting Wang wrote:
+void hmp_info_iothreads(Monitor *mon, const QDict *qdict)
+{
+IOThreadInfoList *head = NULL, *elem = NULL;
+
+head = qmp_query_iothreads(NULL);
+if (!head) {
+monitor_printf(mon, No iothread has been added\n);
+return;
+}
+
+elem = head;
+while (elem) {
+if (elem-value) {
+monitor_printf(mon, %s: thread_id=%ld\n, elem-value-id,
+elem-value-thread_id);
%ld does not work on 32-bit hosts or 64-bit Windows hosts where long is
32-bit.
Please use the PRId64 format specifier macro for the int64_t thread_id.
pgp5rJ6eMr_85.pgp
Description: PGP signature
[Qemu-devel] [PULL v4 01/11] net: synchronize net_host_device_remove with host_net_remove_completion
From: Paolo Bonzini pbonz...@redhat.com
Using net_host_check_device is unnecessary. qemu_del_net_client asserts
for the non-peer case that it can only process NIC type NetClientStates,
and that assertion is valid for the peered case as well, so move it and
use the same check in net_host_device_remove. host_net_remove_completion
is already checking the type.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Reviewed-by: Jason Wang jasow...@redhat.com
Message-id: 1419353600-30519-2-git-send-email-pbonz...@redhat.com
Signed-off-by: Stefan Hajnoczi stefa...@redhat.com
---
net/net.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/net.c b/net/net.c
index 11fb769..0be084d 100644
--- a/net/net.c
+++ b/net/net.c
@@ -324,6 +324,8 @@ void qemu_del_net_client(NetClientState *nc)
NetClientState *ncs[MAX_QUEUE_NUM];
int queues, i;
+assert(nc-info-type != NET_CLIENT_OPTIONS_KIND_NIC);
+
/* If the NetClientState belongs to a multiqueue backend, we will change
all
* other NetClientStates also.
*/
@@ -355,8 +357,6 @@ void qemu_del_net_client(NetClientState *nc)
return;
}
-assert(nc-info-type != NET_CLIENT_OPTIONS_KIND_NIC);
-
for (i = 0; i queues; i++) {
qemu_cleanup_net_client(ncs[i]);
qemu_free_net_client(ncs[i]);
@@ -991,7 +991,7 @@ void hmp_host_net_remove(Monitor *mon, const QDict *qdict)
device, vlan_id);
return;
}
-if (!net_host_check_device(nc-model)) {
+if (nc-info-type == NET_CLIENT_OPTIONS_KIND_NIC) {
error_report(invalid host network device '%s', device);
return;
}
--
2.1.0
[Qemu-devel] [PULL v4 07/11] pci: add network device class 'other' for network switches
From: Scott Feldman sfel...@gmail.com Rocker is an ethernet switch device, so add 'other' network device class as defined by PCI to cover these types of devices. Signed-off-by: Scott Feldman sfel...@gmail.com Signed-off-by: Jiri Pirko j...@resnulli.us Message-id: 1424123271-7656-6-git-send-email-sfel...@gmail.com Signed-off-by: Stefan Hajnoczi stefa...@redhat.com --- include/hw/pci/pci_ids.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/hw/pci/pci_ids.h b/include/hw/pci/pci_ids.h index d7be386..c6de710 100644 --- a/include/hw/pci/pci_ids.h +++ b/include/hw/pci/pci_ids.h @@ -23,6 +23,7 @@ #define PCI_CLASS_STORAGE_OTHER 0x0180 #define PCI_CLASS_NETWORK_ETHERNET 0x0200 +#define PCI_CLASS_NETWORK_OTHER 0x0280 #define PCI_CLASS_DISPLAY_VGA0x0300 #define PCI_CLASS_DISPLAY_OTHER 0x0380 -- 2.1.0
[Qemu-devel] [PULL v4 11/11] rocker: timestamp on the debug logs helps correlate with events in the VM
From: David Ahern dsah...@gmail.com
Signed-off-by: David Ahern dsah...@gmail.com
Signed-off-by: Scott Feldman sfel...@gmail.com
Signed-off-by: Jiri Pirko j...@resnulli.us
Message-id: 1424123271-7656-11-git-send-email-sfel...@gmail.com
Signed-off-by: Stefan Hajnoczi stefa...@redhat.com
---
hw/net/rocker/rocker.h | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/hw/net/rocker/rocker.h b/hw/net/rocker/rocker.h
index 6ae74ff..b3310b6 100644
--- a/hw/net/rocker/rocker.h
+++ b/hw/net/rocker/rocker.h
@@ -23,7 +23,16 @@
#if defined(DEBUG_ROCKER)
# define DPRINTF(fmt, ...) \
-do { fprintf(stderr, ROCKER: fmt, ## __VA_ARGS__); } while (0)
+do { \
+struct timeval tv; \
+char timestr[64]; \
+time_t now;\
+gettimeofday(tv, NULL); \
+now = tv.tv_sec; \
+strftime(timestr, sizeof(timestr), %T, localtime(now)); \
+fprintf(stderr, %s.%06ld , timestr, tv.tv_usec); \
+fprintf(stderr, ROCKER: fmt, ## __VA_ARGS__); \
+} while (0)
#else
static inline GCC_FMT_ATTR(1, 2) int DPRINTF(const char *fmt, ...)
{
--
2.1.0
Re: [Qemu-devel] configure: enable kvm on x32
On 12/03/2015 09:06, Michael Tokarev wrote: 12.03.2015 10:16, Peter Maydell wrote: On 12 March 2015 at 06:13, Michael Tokarev m...@tls.msk.ru wrote: Here's a trivial change to enable kvm on x32 architecture. I'm not 100% sure the result works correctly in all cases, but this is a good start and in theory everything should work. Given the pessimism expressed in this comment, perhaps we should delay this to 2.4 and when it's had more testing? There's no pessimism really. It is a new arch for kvm, so _something_ might not work. In practice it works fairy well, see https://bugs.debian.org/778737 -- at least debian can be installed in x32 kvm. And we don't lose anything really because it is a new arch. That's why it was Cc'd -trivial. Acked-by: Paolo Bonzini pbonz...@redhat.com ... but I'm not going to test it. Paolo
Re: [Qemu-devel] fw_cfg specification ?
On 11/03/2015 22:30, Laszlo Ersek wrote: In any case, I'm unaware of *any* instance when an fw_cfg blob is rewritten by the guest. In fact, such *write* callbacks are registered in qemu with fw_cfg_add_callback(), and I can't see any calls to that function. It's dead code, apparently. Let's nuke it. :) Paolo
Re: [Qemu-devel] [PULL v4 00/11] Net patches
On 12 March 2015 at 14:33, Stefan Hajnoczi stefa...@redhat.com wrote: v4: * Drop clang 3.5.0 fixes since they break with older clang and w32 [Peter] v3: * Add clang 3.5.0 warning fixes * Squash David Ahern's clang struct definition warnings fix v2: * Squash in Jiri's fix for rocker format string specifiers [Peter] * Squash in Windows build fix [Peter] * Both build fixes are described in rocker: add new rocker switch device The following changes since commit ee74801035b0b5f1fdfd4e31d3a53f511f91c804: Merge remote-tracking branch 'remotes/lalrae/tags/mips-20150311' into staging (2015-03-11 18:22:15 +) are available in the git repository at: git://github.com/stefanha/qemu.git tags/net-pull-request for you to fetch changes up to 8d3f4f565fb4adf940a8824882a7f549304f34fd: rocker: timestamp on the debug logs helps correlate with events in the VM (2015-03-12 14:18:11 +) w32 build failure :-( cc1: warnings being treated as errors /home/petmay01/linaro/qemu-for-merges/hw/net/rocker/rocker.c: In function 'rocker_io_readq': /home/petmay01/linaro/qemu-for-merges/hw/net/rocker/rocker.c:1109: warning: integer constant is too large for 'long' type (64 bit constant without ULL suffix.) -- PMM
[Qemu-devel] [PATCH] qdev: Deprecated qdev_init() is finally unused, drop
Signed-off-by: Markus Armbruster arm...@redhat.com
---
Depends on
[PATCH 3/3] s390x: Replace unchecked qdev_init() by qdev_init_nofail()
[PATCH] macio: Convert to realize()
hw/core/qdev.c | 44 +---
include/hw/qdev-core.h | 3 +--
2 files changed, 14 insertions(+), 33 deletions(-)
diff --git a/hw/core/qdev.c b/hw/core/qdev.c
index 6be5866..dcb344c 100644
--- a/hw/core/qdev.c
+++ b/hw/core/qdev.c
@@ -126,9 +126,9 @@ void qbus_set_bus_hotplug_handler(BusState *bus, Error
**errp)
qbus_set_hotplug_handler_internal(bus, OBJECT(bus), errp);
}
-/* Create a new device. This only initializes the device state structure
- and allows properties to be set. qdev_init should be called to
- initialize the actual device emulation. */
+/* Create a new device. This only initializes the device state
+ structure and allows properties to be set. The device still needs
+ to be realized. See qdev-core.h. */
DeviceState *qdev_create(BusState *bus, const char *name)
{
DeviceState *dev;
@@ -168,27 +168,6 @@ DeviceState *qdev_try_create(BusState *bus, const char
*type)
return dev;
}
-/* Initialize a device. Device properties should be set before calling
- this function. IRQs and MMIO regions should be connected/mapped after
- calling this function.
- On failure, destroy the device and return negative value.
- Return 0 on success. */
-int qdev_init(DeviceState *dev)
-{
-Error *local_err = NULL;
-
-assert(!dev-realized);
-
-object_property_set_bool(OBJECT(dev), true, realized, local_err);
-if (local_err != NULL) {
-qerror_report_err(local_err);
-error_free(local_err);
-object_unparent(OBJECT(dev));
-return -1;
-}
-return 0;
-}
-
static QTAILQ_HEAD(device_listeners, DeviceListener) device_listeners
= QTAILQ_HEAD_INITIALIZER(device_listeners);
@@ -364,13 +343,16 @@ void qdev_simple_device_unplug_cb(HotplugHandler
*hotplug_dev,
object_unparent(OBJECT(dev));
}
-/* Like qdev_init(), but terminate program via error_report() instead of
- returning an error value. This is okay during machine creation.
- Don't use for hotplug, because there callers need to recover from
- failure. Exception: if you know the device's init() callback can't
- fail, then qdev_init_nofail() can't fail either, and is therefore
- usable even then. But relying on the device implementation that
- way is somewhat unclean, and best avoided. */
+/* Initialize a device. Device properties should be set before calling
+ this function. IRQs and MMIO regions should be connected/mapped after
+ calling this function.
+ On failure, report an error with error_report() and terminate the
+ program. This is okay during machine creation. Don't use for
+ hotplug, because there callers need to recover from failure.
+ Exception: if you know the device's init() callback can't fail,
+ then qdev_init_nofail() can't fail either, and is therefore usable
+ even then. But relying on the device implementation that way is
+ somewhat unclean, and best avoided. */
void qdev_init_nofail(DeviceState *dev)
{
Error *err = NULL;
diff --git a/include/hw/qdev-core.h b/include/hw/qdev-core.h
index 4e673f9..8f7e1c9 100644
--- a/include/hw/qdev-core.h
+++ b/include/hw/qdev-core.h
@@ -66,7 +66,7 @@ struct VMStateDescription;
* After successful realization, setting static properties will fail.
*
* As an interim step, the #DeviceState:realized property is set by deprecated
- * functions qdev_init() and qdev_init_nofail().
+ * function qdev_init_nofail().
* In the future, devices will propagate this state change to their children
* and along busses they expose.
* The point in time will be deferred to machine creation, so that values
@@ -262,7 +262,6 @@ typedef struct GlobalProperty {
DeviceState *qdev_create(BusState *bus, const char *name);
DeviceState *qdev_try_create(BusState *bus, const char *name);
-int qdev_init(DeviceState *dev) QEMU_WARN_UNUSED_RESULT;
void qdev_init_nofail(DeviceState *dev);
void qdev_set_legacy_instance_id(DeviceState *dev, int alias_id,
int required_for_version);
--
1.9.3
Re: [Qemu-devel] [PATCH] When building qga-vss.dll with 64-bit MinGW toolchain, qga-vss.dll linking fails with unresolved symbols from libssp, stack protection support, like the following message:
On 12/03/2015 11:35, Joseph Hindin wrote: .../qga/vss-win32/install.cpp:52: undefined reference to `__stack_chk_fail' The patch fixes the problem by adding -fstack-protector-all option to the linker options' list. Signed-off-by: Joseph Hindin jhin...@daynix.com --- qga/vss-win32/Makefile.objs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/qga/vss-win32/Makefile.objs b/qga/vss-win32/Makefile.objs index 6a69d50..3b296f0 100644 --- a/qga/vss-win32/Makefile.objs +++ b/qga/vss-win32/Makefile.objs @@ -5,7 +5,7 @@ qga-vss-dll-obj-y += requester.o provider.o install.o obj-qga-vss-dll-obj-y = $(addprefix $(obj)/, $(qga-vss-dll-obj-y)) $(obj-qga-vss-dll-obj-y): QEMU_CXXFLAGS = $(filter-out -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Wold-style-declaration -Wold-style-definition -Wredundant-decls -fstack-protector-all, $(QEMU_CFLAGS)) -Wno-unknown-pragmas -Wno-delete-non-virtual-dtor -$(obj)/qga-vss.dll: LDFLAGS = -shared -Wl,--add-stdcall-alias,--enable-stdcall-fixup -lole32 -loleaut32 -lshlwapi -luuid -static +$(obj)/qga-vss.dll: LDFLAGS = -fstack-protector-all -shared -Wl,--add-stdcall-alias,--enable-stdcall-fixup -lole32 -loleaut32 -lshlwapi -luuid -static $(obj)/qga-vss.dll: $(obj-qga-vss-dll-obj-y) $(SRC_PATH)/$(obj)/qga-vss.def $(call quiet-command,$(CXX) -o $@ $(qga-vss-dll-obj-y) $(SRC_PATH)/qga/vss-win32/qga-vss.def $(CXXFLAGS) $(LDFLAGS), LINK $(TARGET_DIR)$@) Sorry for the late reply to v1. I left a few other comments there. Basically, the Makefile is trying to disable ssp, in the line above the one you touched. Either we can support ssp, and then that incomplete effort must be removed, or we cannot, and then your fix may hide other bugs. Paolo
