Re: [Qemu-devel] [PATCH v17 00/14] Drop in_use from BlockDriverState and enable point-in-time snapshot exporting over NBD
On Mon, 03/10 15:25, Fam Zheng wrote: v17: Rebase to current master. Ping?
[Qemu-devel] [PATCH] block: Handle error of bdrv_getlength in bdrv_create_dirty_bitmap
bdrv_getlength could fail, check the return value before using it.
Signed-off-by: Fam Zheng f...@redhat.com
---
block-migration.c | 28
block.c | 10 --
block/mirror.c| 5 -
include/block/block.h | 3 ++-
4 files changed, 38 insertions(+), 8 deletions(-)
diff --git a/block-migration.c b/block-migration.c
index 897fdba..62cd597 100644
--- a/block-migration.c
+++ b/block-migration.c
@@ -310,13 +310,26 @@ static int mig_save_device_bulk(QEMUFile *f,
BlkMigDevState *bmds)
/* Called with iothread lock taken. */
-static void set_dirty_tracking(void)
+static int set_dirty_tracking(void)
{
BlkMigDevState *bmds;
QSIMPLEQ_FOREACH(bmds, block_mig_state.bmds_list, entry) {
-bmds-dirty_bitmap = bdrv_create_dirty_bitmap(bmds-bs, BLOCK_SIZE);
+bmds-dirty_bitmap = bdrv_create_dirty_bitmap(bmds-bs, BLOCK_SIZE,
+ NULL);
+if (!bmds-dirty_bitmap) {
+goto fail;
+}
+}
+return 0;
+
+fail:
+QSIMPLEQ_FOREACH(bmds, block_mig_state.bmds_list, entry) {
+if (bmds-dirty_bitmap) {
+bdrv_release_dirty_bitmap(bmds-bs, bmds-dirty_bitmap);
+}
}
+return -1;
}
static void unset_dirty_tracking(void)
@@ -611,10 +624,17 @@ static int block_save_setup(QEMUFile *f, void *opaque)
block_mig_state.submitted, block_mig_state.transferred);
qemu_mutex_lock_iothread();
-init_blk_migration(f);
/* start track dirty blocks */
-set_dirty_tracking();
+ret = set_dirty_tracking();
+
+if (ret) {
+qemu_mutex_unlock_iothread();
+return ret;
+}
+
+init_blk_migration(f);
+
qemu_mutex_unlock_iothread();
ret = flush_blks(f);
diff --git a/block.c b/block.c
index acb70fd..93006de 100644
--- a/block.c
+++ b/block.c
@@ -5079,7 +5079,8 @@ bool bdrv_qiov_is_aligned(BlockDriverState *bs,
QEMUIOVector *qiov)
return true;
}
-BdrvDirtyBitmap *bdrv_create_dirty_bitmap(BlockDriverState *bs, int
granularity)
+BdrvDirtyBitmap *bdrv_create_dirty_bitmap(BlockDriverState *bs, int
granularity,
+ Error **errp)
{
int64_t bitmap_size;
BdrvDirtyBitmap *bitmap;
@@ -5088,7 +5089,12 @@ BdrvDirtyBitmap
*bdrv_create_dirty_bitmap(BlockDriverState *bs, int granularity)
granularity = BDRV_SECTOR_BITS;
assert(granularity);
-bitmap_size = (bdrv_getlength(bs) BDRV_SECTOR_BITS);
+bitmap_size = bdrv_getlength(bs);
+if (bitmap_size 0) {
+error_setg(errp, could not get length of device);
+return NULL;
+}
+bitmap_size = BDRV_SECTOR_BITS;
bitmap = g_malloc0(sizeof(BdrvDirtyBitmap));
bitmap-bitmap = hbitmap_alloc(bitmap_size, ffs(granularity) - 1);
QLIST_INSERT_HEAD(bs-dirty_bitmaps, bitmap, list);
diff --git a/block/mirror.c b/block/mirror.c
index 0ef41f9..2618c37 100644
--- a/block/mirror.c
+++ b/block/mirror.c
@@ -605,7 +605,10 @@ static void mirror_start_job(BlockDriverState *bs,
BlockDriverState *target,
s-granularity = granularity;
s-buf_size = MAX(buf_size, granularity);
-s-dirty_bitmap = bdrv_create_dirty_bitmap(bs, granularity);
+s-dirty_bitmap = bdrv_create_dirty_bitmap(bs, granularity, errp);
+if (!s-dirty_bitmap) {
+return;
+}
bdrv_set_enable_write_cache(s-target, true);
bdrv_set_on_error(s-target, on_target_error, on_target_error);
bdrv_iostatus_enable(s-target);
diff --git a/include/block/block.h b/include/block/block.h
index 1ed55d8..8e70a57 100644
--- a/include/block/block.h
+++ b/include/block/block.h
@@ -428,7 +428,8 @@ bool bdrv_qiov_is_aligned(BlockDriverState *bs,
QEMUIOVector *qiov);
struct HBitmapIter;
typedef struct BdrvDirtyBitmap BdrvDirtyBitmap;
-BdrvDirtyBitmap *bdrv_create_dirty_bitmap(BlockDriverState *bs, int
granularity);
+BdrvDirtyBitmap *bdrv_create_dirty_bitmap(BlockDriverState *bs, int
granularity,
+ Error **errp);
void bdrv_release_dirty_bitmap(BlockDriverState *bs, BdrvDirtyBitmap *bitmap);
BlockDirtyInfoList *bdrv_query_dirty_bitmaps(BlockDriverState *bs);
int bdrv_get_dirty(BlockDriverState *bs, BdrvDirtyBitmap *bitmap, int64_t
sector);
--
1.9.1
[Qemu-devel] [Bug 1278977] Re: qemu-system-sparc64 crash when initializing disk
Hi, here is the kernel and image: http://www.openadk.org/sparc64/ Inside the system do: rw tar xvf perl-5.18.1.tar.gz The kernel contains full debug info. Be sure that your system has a high load. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1278977 Title: qemu-system-sparc64 crash when initializing disk Status in QEMU: New Bug description: Hi, I try to boot up Linux for SPARC64 in qemu-system-sparc64 (qemu 1.7.0). A self compiled kernel with initramfs as piggyback boots up fine. (http://www.openadk.org/qemu-sparc64-initramfs-piggyback-kernel) When trying to use a disk image I get following trace: qemu-system-sparc64 -nographic -kernel /home/wbx/openadk/bin/qemu_sparc64_eglibc/qemu-sparc64-archive-kernel qemu-sparc64.img -append root=/dev/sda1 [ 43.520705] ata1.00: ATA-7: QEMU HARDDISK, 1.7.0, max UDMA/100 [ 43.792734] ata1.00: 1048576 sectors, multi 16: LBA48 [ 44.100768] ata1.00: configured for UDMA/33 [ 44.316791] scsi 0:0:0:0: Direct-Access ATA QEMU HARDDISK1.7. PQ: 0 ANSI: 5 [ 44.724835] sd 0:0:0:0: [sda] 1048576 512-byte logical blocks: (536 MB/512 MiB) [ 45.172883] ata2.00: ATAPI: QEMU DVD-ROM, 1.7.0, max UDMA/100 [ 45.508920] ata2.00: configured for UDMA/33 [ 45.752946] scsi 1:0:0:0: CD-ROMQEMU QEMU DVD-ROM 1.7. PQ: 0 ANSI: 5 [ 46.309006] sd 0:0:0:0: [sda] Write Protect is off [ 46.737053] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA qemu: fatal: Trap 0x0032 while trap level (5) = MAXTL (5), Error state pc: 004055dc npc: 004055e0 %g0-3: 0200 f80006a3f170 0200 %g4-7: f5000464 f80006a3c000 f500 %o0-3: f80006a10140 f80006a10160 f80006900010 06a6c000 %o4-7: 0002 03e7 f80006a3e1c1 00593988 %l0-3: 00ff 2000 0001 %l4-7: f80006a0d980 0001 c0004000 %i0-3: ff00 0001 0001 %i4-7: f80006a11d50 f80006a1 f80006a3e271 00582444 %f00: %f08: %f16: 076e072707740720 0773077507700770 076f077207740720 07440750074f0720 %f24: 076f077207200746 0755074107200720 0720072007200720 0720072007200720 %f32: 0720072007200720 0720072007200720 0720072007200720 0720072007200720 %f40: 0720072007200720 0720072007200720 0720072007200720 0720072007200720 %f48: 0720072007200720 0755074107200720 0720072007200720 0720072007200720 %f56: 0720072007200720 0720072007200720 0720072007200720 0720072007200720 pstate: 0015 ccr: 00 (icc: xcc: ) asi: 80 tl: 5 pil: e cansave: 4 canrestore: 2 otherwin: 0 wstate: 0 cleanwin: 7 cwp: 4 fsr: y: fprs: Aborted Same happens when starting up Debian/wheezy 7.4 for sparc64: qemu-system-sparc64 -nographic -kernel vmlinuz -initrd initrd.gz qemu.img [ 102.943129] eth0: RealTek RTL-8029 found at 0x1fe02000400, IRQ 6, 52:54:00:12:34:56. [ 105.143367] scsi0 : pata_cmd64x [ 105.667424] scsi1 : pata_cmd64x [ 106.003460] ata1: PATA max UDMA/33 cmd 0x1fe02000500 ctl 0x1fe02000580 bmdma 0x1fe02000700 irq 7 [ 106.871554] ata2: PATA max UDMA/33 cmd 0x1fe02000600 ctl 0x1fe02000680 bmdma 0x1fe02000708 irq 7 [ 108.247703] ata1.00: ATA-7: QEMU HARDDISK, 1.7.0, max UDMA/100 [ 108.775760] ata1.00: 1048576 sectors, multi 16: LBA48 [ 109.399827] ata1.00: configured for UDMA/33 [ 109.815872] scsi 0:0:0:0: Direct-Access ATA QEMU HARDDISK1.7. PQ: 0 ANSI: 5 [ 111.004001] ata2.00: ATAPI: QEMU DVD-ROM, 1.7.0, max UDMA/100 [ 111.608066] ata2.00: configured for UDMA/33 [ 112.040113] scsi 1:0:0:0: CD-ROMQEMU QEMU DVD-ROM 1.7. PQ: 0 ANSI: 5 [ 114.344362] sd 0:0:0:0: [sda] 1048576 512-byte logical blocks: (536 MB/512 MiB) qemu: fatal: Trap 0x0032 while trap level (5) = MAXTL (5), Error state pc: 004055bc npc: 004055c0 %g0-3: 0200 f80007e6bd10 0200 %g4-7: f5000464 f80005d34000 f500 %o0-3: f80005f68148 f80005f68180 000c 0001 %o4-7: f80005d4b889 01fe02000600 f8000705b391 10064474 %l0-3: 007f6330 00200200 f80007e6be60 %l4-7: 00945bd8 00945fd8 009463d8 %i0-3: f80005f68000 f80005f68148 0058 0001 %i4-7: f80005f69ce8 f8000705b451
Re: [Qemu-devel] [PULL for-2.0 2/2] cpu: Avoid QOM casts for CPU()
On Mon, Mar 31, 2014 at 7:37 PM, Andreas Färber afaer...@suse.de wrote: CPU address spaces touching load and store helpers as well as the movement of (almost) all fields from CPU_COMMON to CPUState have led to a noticeable increase of CPU() usage in hot paths for both TCG and KVM. While CPU()'s OBJECT_CHECK() might help detect development errors, i.e. in form of crashes due to QOM vs. non-QOM mismatches rather than QOM type mismatches, it is not really needed at runtime since mostly used in CPU-specific paths, coming from a target-specific CPU subtype. If that pointer is damaged, other errors are highly likely to occur elsewhere anyway. Keep the CPU() macro for a consistent developer experience and for flexibility to exchange its implementation, but turn it into a pure, unchecked C cast for now. Compare commit 6e42be7cd10260fd3a006d94f6c870692bf7a2c0. Reported-by: Laurent Desnogues laurent.desnog...@gmail.com Suggested-by: Paolo Bonzini pbonz...@redhat.com Signed-off-by: Andreas Färber afaer...@suse.de It works fine here. Tested-by: Laurent Desnogues laurent.desnog...@gmail.com Thanks, Laurent --- include/qom/cpu.h | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/include/qom/cpu.h b/include/qom/cpu.h index f99885a..df977c8 100644 --- a/include/qom/cpu.h +++ b/include/qom/cpu.h @@ -53,7 +53,12 @@ typedef uint64_t vaddr; #define TYPE_CPU cpu -#define CPU(obj) OBJECT_CHECK(CPUState, (obj), TYPE_CPU) +/* Since this macro is used a lot in hot code paths and in conjunction with + * FooCPU *foo_env_get_cpu(), we deviate from usual QOM practice by using + * an unchecked cast. + */ +#define CPU(obj) ((CPUState *)(obj)) + #define CPU_CLASS(class) OBJECT_CLASS_CHECK(CPUClass, (class), TYPE_CPU) #define CPU_GET_CLASS(obj) OBJECT_GET_CLASS(CPUClass, (obj), TYPE_CPU) -- 1.8.4.5
[Qemu-devel] Framebuffer corruption in QEMU or Linux's cirrus driver
Running: ./virtme-run --installed-kernel from this virtme commit: https://git.kernel.org/cgit/utils/kernel/virtme/virtme.git/commit/?id=2b409a086d15b7a878c7d5204b1f44a6564a341f results in a bunch of missing lines of text once bootup finishes. Pressing enter a few times gradually fixes it. I don't know whether this is a qemu bug or a Linux bug. I'm seeing this on Fedora's 3.13.7 kernel and on a fairly recent 3.14-rc kernel. For the latter, cirrus is built-in (not a module), I'm running: virtme-run --kimg arch/x86/boot/bzImage and I see more profound corruption. --Andy
Re: [Qemu-devel] Framebuffer corruption in QEMU or Linux's cirrus driver
On Tue, Apr 1, 2014 at 3:09 PM, Andy Lutomirski l...@amacapital.net wrote: Running: ./virtme-run --installed-kernel from this virtme commit: https://git.kernel.org/cgit/utils/kernel/virtme/virtme.git/commit/?id=2b409a086d15b7a878c7d5204b1f44a6564a341f results in a bunch of missing lines of text once bootup finishes. Pressing enter a few times gradually fixes it. I don't know whether this is a qemu bug or a Linux bug. I'm seeing this on Fedora's 3.13.7 kernel and on a fairly recent 3.14-rc kernel. For the latter, cirrus is built-in (not a module), I'm running: virtme-run --kimg arch/x86/boot/bzImage and I see more profound corruption. I'm guessing this is a cirrus drm bug. bochs-drm (using virtme-run --installed-kernel --qemu-opts -vga std) does not appear to have the same issue. Neither does qxl. (qxl is painfully slow, though, and it doesn't seem to be using UC memory.) --Andy
[Qemu-devel] [Bug 1301047] [NEW] Windows guest freezes after exiting an 3D application on guest.
Public bug reported: I have the following issue with my Windows 8.1 guest. (Technical stuff is at the bottom): I have vfio-binded my graphics card(NVIDIA GTX670) and is passing it through to the guest. I run heavy 3D applications such as games(Guild Wars 2, Diablo 3, DOTA etc) which works fine(performance is about 90% of a physical Windows). When it comes to Rocksmith 2014 and Battlefield 4 things starts to act up. I can play both games just as good as any other game in the guest(passing through the USB Rocksmith Cable and audio is working perfect), however when I exit one of these two applications the guest freezes completely up. I loose contact via Synergy(mouse/keyboard), I cant ping the guest, the screen freezes(always freezing before I see the desktop again), CPU usage of the processes drops down to 0. The memory dedicated to the guest is latent/in use though, as reported by htop/free -m. I have among other things tested with lowering the memory from 16Gb to 8Gb and CPU used from 6 to 4. The issue remains unsolved. My host(Arch Linux) works fine while the host is frozen up. Is it reproducible? Yes, every time with the same applications when exiting. Starting and using the applications works fine. Expected outcome: Application closes, guest does not freeze. My theory is that the GPU is flushing its memory cache in a way that Qemu is not prepared for which results in a lock of the Qemu process where it cant get out and therefore the guest is frozen/locked up. Suggested solution(if at all possible): Implement a function which get called if the Qemu lock appears where the GPU gets disconnected and then connected again. (Not sure if safe? PCI Express supports hot plugging?) Or make sure the Qemu process can not get into the state where a total freeze of the machine can happen if there is anything GPU related freezes. (So we still can trigger a remote reboot via Powershell/CMD etc) If there is some more information you need, please do not hesitate to ask for it. Also, this is my first bug report so please be kind, I appreciate any feedback :) Technical Information: CPU: Intel(R) Core(TM) i7-4771 CPU @ 3.50GHz GPU: NVIDIA GTX 670, latest NVIDIA drivers installed in Windows. QEMU version: qemu-git 2.0.r31965.g63678e1-1 Host Kernel: Linux 3.13.6-1-mainline x86_64 Guest: Windows 8.1 Professional, fully updated as of 30th March 2014 Qemu command line used: sudo -E qemu-system-x86_64 \ -enable-kvm \ -M q35 \ -m 8G \ -mem-path /dev/hugepages \ -mem-prealloc \ -cpu host \ -smp 4,sockets=1,cores=4,threads=1 \ -device vfio-pci,host=00:1b.0 \ -bios /usr/share/qemu/bios.bin \ -vga none \ -device ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root.1 \ -device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on \ -nographic \ -device ahci,bus=pcie.0,id=ahci \ -drive file=/var/lib/libvirt/images/Windows8.1.img,id=disk,format=raw,cache=none \ -device ide-hd,bus=ahci.0,drive=disk \ -device vfio-pci,host=00:19.0,bus=pcie.0 \ -drive file=/dev/sdb1,id=mmo,format=raw,cache=none \ -device ide-hd,bus=ahci.1,drive=mmo \ -drive file=/home/thor/Windows/Windows-Steam.img,id=steam,format=raw,cache=none \ -usb -usbdevice host:045e:028e \ -usb -usbdevice host:12ba:00ff \ -net none \ -device ide-hd,bus=ahci.2,drive=steam Strace output in the seconds leading up to the freeze: See attachment . Journalctl output on the host while the guest froze: Apr 01 22:03:19 ultimaarch kernel: xhci_hcd :00:14.0: ERROR Transfer event for disabled endpoint or incorrect stream ring Apr 01 22:03:19 ultimaarch kernel: xhci_hcd :00:14.0: @e410 fff9f480 0d0c 07058000 Apr 01 22:03:19 ultimaarch kernel: xhci_hcd :00:14.0: ERROR Transfer event for disabled endpoint or incorrect stream ring Apr 01 22:03:19 ultimaarch kernel: xhci_hcd :00:14.0: @e420 fff9f490 0d0c 07058000 Apr 01 22:03:19 ultimaarch kernel: xhci_hcd :00:14.0: ERROR Transfer event for disabled endpoint or incorrect stream ring Apr 01 22:03:19 ultimaarch kernel: xhci_hcd :00:14.0: @e430 fff9f4a0 0d0c 07058000 Apr 01 22:03:19 ultimaarch kernel: xhci_hcd :00:14.0: ERROR Transfer event for disabled endpoint or incorrect stream ring Apr 01 22:03:19 ultimaarch kernel: xhci_hcd :00:14.0: @e440 fff9f4b0 0d0c 07058000 Apr 01 22:03:19 ultimaarch kernel: xhci_hcd :00:14.0: ERROR Transfer event for disabled endpoint or incorrect stream ring Apr 01 22:03:19 ultimaarch kernel: xhci_hcd :00:14.0: @e450 fff9f4c0 0d0a 07058000 Apr 01 22:03:19 ultimaarch kernel: xhci_hcd :00:14.0: ERROR Transfer event for disabled endpoint or incorrect stream ring Apr 01 22:03:19 ultimaarch kernel: xhci_hcd :00:14.0: @e460 fff9f4d0 0d0c 07058000 Apr 01 22:03:19 ultimaarch kernel: xhci_hcd :00:14.0: ERROR Transfer event for disabled endpoint or incorrect
[Qemu-devel] [PATCH 0/2] unset RAMBlock idstr when unregistering
When hotplug an memdev that was previously plugged and unplugged, RAMBlock idstr is not cleared and triggers an assert error in qemu_ram_set_idstr(). This series fixes it. Hu Tao (2): exec: introduce qemu_ram_unset_idstr() to unset RAMBlock idstr unset RAMBlock idstr when unregister MemoryRegion exec.c| 26 +- include/exec/cpu-common.h | 1 + savevm.c | 2 +- 3 files changed, 23 insertions(+), 6 deletions(-) -- 1.8.5.2.229.g4448466
[Qemu-devel] [PATCH 1/2] exec: introduce qemu_ram_unset_idstr() to unset RAMBlock idstr
Signed-off-by: Hu Tao hu...@cn.fujitsu.com
---
exec.c| 26 +-
include/exec/cpu-common.h | 1 +
2 files changed, 22 insertions(+), 5 deletions(-)
diff --git a/exec.c b/exec.c
index 91513c6..cbf7923 100644
--- a/exec.c
+++ b/exec.c
@@ -1202,17 +1202,24 @@ static void qemu_ram_setup_dump(void *addr, ram_addr_t
size)
}
}
-void qemu_ram_set_idstr(ram_addr_t addr, const char *name, DeviceState *dev)
+static RAMBlock *find_ram_block(ram_addr_t addr)
{
-RAMBlock *new_block, *block;
+RAMBlock *block;
-new_block = NULL;
QTAILQ_FOREACH(block, ram_list.blocks, next) {
if (block-offset == addr) {
-new_block = block;
-break;
+return block;
}
}
+
+return NULL;
+}
+
+void qemu_ram_set_idstr(ram_addr_t addr, const char *name, DeviceState *dev)
+{
+RAMBlock *new_block = find_ram_block(addr);
+RAMBlock *block;
+
assert(new_block);
assert(!new_block-idstr[0]);
@@ -1237,6 +1244,15 @@ void qemu_ram_set_idstr(ram_addr_t addr, const char
*name, DeviceState *dev)
qemu_mutex_unlock_ramlist();
}
+void qemu_ram_unset_idstr(ram_addr_t addr)
+{
+RAMBlock *block = find_ram_block(addr);
+
+if (block) {
+memset(block-idstr, 0, sizeof(block-idstr));
+}
+}
+
static int memory_try_enable_merging(void *addr, size_t len)
{
if (!qemu_opt_get_bool(qemu_get_machine_opts(), mem-merge, true)) {
diff --git a/include/exec/cpu-common.h b/include/exec/cpu-common.h
index a21b65a..89ec640 100644
--- a/include/exec/cpu-common.h
+++ b/include/exec/cpu-common.h
@@ -54,6 +54,7 @@ void qemu_ram_remap(ram_addr_t addr, ram_addr_t length);
/* This should not be used by devices. */
MemoryRegion *qemu_ram_addr_from_host(void *ptr, ram_addr_t *ram_addr);
void qemu_ram_set_idstr(ram_addr_t addr, const char *name, DeviceState *dev);
+void qemu_ram_unset_idstr(ram_addr_t addr);
void cpu_physical_memory_rw(hwaddr addr, uint8_t *buf,
int len, int is_write);
--
1.8.5.2.229.g4448466
[Qemu-devel] [PATCH 2/2] unset RAMBlock idstr when unregister MemoryRegion
Signed-off-by: Hu Tao hu...@cn.fujitsu.com
---
savevm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/savevm.c b/savevm.c
index 22123be..6f4b1a5 100644
--- a/savevm.c
+++ b/savevm.c
@@ -1208,7 +1208,7 @@ void vmstate_register_ram(MemoryRegion *mr, DeviceState
*dev)
void vmstate_unregister_ram(MemoryRegion *mr, DeviceState *dev)
{
-/* Nothing do to while the implementation is in RAMBlock */
+qemu_ram_unset_idstr(memory_region_get_ram_addr(mr) TARGET_PAGE_MASK);
}
void vmstate_register_ram_global(MemoryRegion *mr)
--
1.8.5.2.229.g4448466
[Qemu-devel] ATA timeouts on Solaris/OpenIndiana/Opensolaris
Hi I am booting an OpenIndiana image on qemu by using the -smp 4 option. I seem to be running into this known bug http://docs.oracle.com/cd/E19253-01/820-5245/ggmsj/index.html Can someone tell me how can i go about doing workaround 2 on qemu?? Workaround 3,4 are not an option for me. I already tried workaround 5 and it does not work. Can someone help me ? Thanks.
Re: [Qemu-devel] [PATCH/RFC] s390: Provide a configuration and control device
On 01/04/14 16:47, Christian Borntraeger wrote: We want to configure several things in KVM that go beyond what ENABLE_CAP (we need payload) or ONE_REG (we need it for the VM and we need to do more complex actions) can provide. Instead of adding several s390 specific ioctls, lets provide a configuration and control device that encapsulates different commands into groups of the same area (MEMORY, CPU, ..) We also provide an initial nameless base group, with a simple first user to set the guest name. We need that name in the kernel for the emulation of STSI (which provides the guest name to the guest) but we need to implement the emulation in supervisor mode, as it also provides the underlying levels of hipervisors. Currently we have the following GROUPS and ATTRs pending, which configure some memory management related function or allow to set the guest facilities, cpuids etc: #define KVM_DEV_CONFIG_GROUP0 #define KVM_DEV_CONFIG_NAME 0 #define KVM_DEV_CONFIG_GROUP_MEM1 #define KVM_DEV_CONFIG_MEM_ENABLE_CMMA 0 #define KVM_DEV_CONFIG_MEM_CLR_CMMA 1 #define KVM_DEV_CONFIG_MEM_CLR_PAGES2 #define KVM_DEV_CONFIG_GROUP_CPU2 #define KVM_DEV_CONFIG_CPU_TYPE 0 #define KVM_DEV_CONFIG_CPU_FAC 1 #define KVM_DEV_CONFIG_CPU_FAC_MASK 2 #define KVM_DEV_CONFIG_CPU_IBC 3 #define KVM_DEV_CONFIG_CPU_IBC_RANGE4 In addition other groups like #define KVM_DEV_CONFIG_GROUP_CRYPTO are under consideration to configure crypto acceleration. Unless there is a major concern, I will add this to the next s390 PULL requests for KVM. Christian @Alex, regarding STSI, what about the following: The kernel will fill in every part of STSI as of now, but we will provide a CAP that qemu can enable which then tells the kernel to pass control to QEMU after it has filled in the data. QEMU can then do nothing (e.g. for stsi 111) or change the information (e.g. for 322) and return to kernel. That would a: cover the name aspect b: will work with future enhancements for levels 1 and 2 since the kernel will still pass that through to the HW or LPAR c: allows QEMU to override everything if necessary @Paolo, Alex, I have several changes pending that will require new ioctls. I planned to use the config device to avoid creating new ioctls. Some option: a: define new ioctls for these things (might end up with ~10 new ioctls) b: allow GET_ATTR/SET_ATTR on the vm fd. We would define those as architecture specific attributes of the VM. c: use a config device an anchor for GET_ATTR/SET_ATTR d: any better idea This question is really a bike shed color discussion (which interface for specific thing between qemu/kvm is considered best), but it will be ABI. Paolo, do you have any preference? I dont care about which solution we choose, but I obviously need a decision to rework pending patches. Christian
Re: [Qemu-devel] Unresponsive linux guest once migrated
It's looking good so far, after a few migrations (it takes a while to test because I'm waiting at least 5 hours between migrations). I'll be happier once I've done a couple of weeks of this without any failures! Does anyone have any hints how to debug this thing? :( I've tried to put hanged guest under gdb and found it's looped deep inside kernel time management functions. Disabling kvmclock suggests it is somehow related to its corruption during migration. It happens on both old and new versions of guest kernels. Any hints from developers are welcome:) -- mg
Re: [Qemu-devel] [RFC PATCH]pci-assign: Fix memory out of bound when MSI-X table not fit in a single page
Hi,
Actually I move the judge in function assigned_dev_register_msix_mmio.
Because assigned_dev_register_msix_mmio do not address the return value,
if dev-msix_table is null, this will result a segfault. Right?
I see the confusion, there is a bug there but I think it should be fixed
by setting msix_table to NULL in the MAP_FAILED case. The intent of
assigned_dev_msix_reset() is to put the msix table in the state it would
be in at reset. Without a memset() that doesn't happen. I believe the
reason we test msix_table in assigned_dev_msix_reset() is so that the
function could be called from anywhere, such as reset_assigned_device()
even though it's currently not called from there. So, if the memset()
gets removed, then the whole function should be dissolved. I'd prefer
to keep it and store or recalculate the size for memset.
Yep, agreed. Thank you so much. I want to post a formal patch, can I?
memset(dev-msix_table, 0, MSIX_PAGE_SIZE);
This memset may no longer cover the entire table
Yeah, this memset is useless. Do it in assigned_dev_register_msix_mmio.
Not useless, see above.
for (i = 0, entry = dev-msix_table; i dev-msix_max; i++,
entry++)
{
@@ -1604,13 +1600,31 @@ static void
assigned_dev_msix_reset(AssignedDevice *dev)
static int assigned_dev_register_msix_mmio(AssignedDevice *dev)
{
-dev-msix_table = mmap(NULL, MSIX_PAGE_SIZE,
PROT_READ|PROT_WRITE,
+int nr_pages;
+int size;
+int entry_per_page = MSIX_PAGE_SIZE / sizeof(struct
MSIXTableEntry);
+
+if (dev-msix_max entry_per_page) {
+nr_pages = dev-msix_max / entry_per_page;
+if (dev-msix_max % entry_per_page) {
+nr_pages += 1;
+}
+} else {
+nr_pages = 1;
+}
+
+size = MSIX_PAGE_SIZE * nr_pages;
Agree with the ROUND_UP comments:
size = ROUND_UP(dev-msix_max * sizeof(struct MSIXTableEntry),
MSIX_PAGE_SIZE);
Nice. I don't know the macro before. Thank you so much!
+dev-msix_table = mmap(NULL, size, PROT_READ|PROT_WRITE,
MAP_ANONYMOUS|MAP_PRIVATE, 0,
0);
if (dev-msix_table == MAP_FAILED) {
error_report(fail allocate msix_table! %s, strerror(errno));
return -EFAULT;
}
+if (!dev-msix_table) {
+return -EFAULT;
+}
This is a bogus test for mmap(2)
+memset(dev-msix_table, 0, size);
This is unnecessary when assigned_dev_msix_reset() is fixed to memset
the whole mmap.
assigned_dev_msix_reset(dev);
memory_region_init_io(dev-mmio, OBJECT(dev),
assigned_dev_msix_mmio_ops,
This memory_region_init_io also requires a size parameter that isn't
updated for the new size.
Nice catch.
As noted by other comments, the munmap() size isn't addressed.
Get it.
IMHO, the correct way to fix this would be to update pci-assign to use
the msix infrastructure, but legacy KVM assignment is being phased out
and replaced by VFIO. Is there something that ties you to pci-assign
instead of using vfio-pci? Thanks,
I will have a try. Alex, What's your opinion about my former letter about
the
MSI-X maximum entry.
From other thread:
BTW, do you think the KVM should upsize the max support MSI-X entry to
2048.
Because the MSI-X supports a maximum table size of 2048 entries, which is
descript in
PCI specification 3.0 version 6.8.3.2: MSI-X Configuration.
The history patch about downsize the MSI-X entry size to 256:
http://thread.gmane.org/gmane.comp.emulators.kvm.devel/38852/focus=388
49
No, I think we should deprecate KVM device assignment and use VFIO.
Thanks,
OK. I will send the result of using VFIO later.
Best regards,
-Gonglei
Re: [Qemu-devel] [PATCH/RFC] s390: Provide a configuration and control device
On 02/04/14 10:39, Alexander Graf wrote:
On 02.04.14 10:31, Christian Borntraeger wrote:
On 01/04/14 16:47, Christian Borntraeger wrote:
We want to configure several things in KVM that go beyond what
ENABLE_CAP (we need payload) or ONE_REG (we need it for the VM
and we need to do more complex actions) can provide. Instead of
adding several s390 specific ioctls, lets provide a configuration
and control device that encapsulates different commands into
groups of the same area (MEMORY, CPU, ..)
We also provide an initial nameless base group, with a simple first
user to set the guest name. We need that name in the kernel for
the emulation of STSI (which provides the guest name to the guest)
but we need to implement the emulation in supervisor mode, as it
also provides the underlying levels of hipervisors.
Currently we have the following GROUPS and ATTRs pending, which
configure some memory management related function or allow to set
the guest facilities, cpuids etc:
#define KVM_DEV_CONFIG_GROUP0
#define KVM_DEV_CONFIG_NAME 0
#define KVM_DEV_CONFIG_GROUP_MEM1
#define KVM_DEV_CONFIG_MEM_ENABLE_CMMA 0
#define KVM_DEV_CONFIG_MEM_CLR_CMMA 1
#define KVM_DEV_CONFIG_MEM_CLR_PAGES2
#define KVM_DEV_CONFIG_GROUP_CPU2
#define KVM_DEV_CONFIG_CPU_TYPE 0
#define KVM_DEV_CONFIG_CPU_FAC 1
#define KVM_DEV_CONFIG_CPU_FAC_MASK 2
#define KVM_DEV_CONFIG_CPU_IBC 3
#define KVM_DEV_CONFIG_CPU_IBC_RANGE4
In addition other groups like
#define KVM_DEV_CONFIG_GROUP_CRYPTO
are under consideration to configure crypto acceleration.
Unless there is a major concern, I will add this to the next
s390 PULL requests for KVM.
Christian
@Alex,
regarding STSI, what about the following:
The kernel will fill in every part of STSI as of now, but we will provide a
CAP that qemu can enable which then tells the kernel to pass control to QEMU
after it has filled in the data. QEMU can then do nothing (e.g. for stsi
111) or change
the information (e.g. for 322) and return to kernel. That would
a: cover the name aspect
b: will work with future enhancements for levels 1 and 2 since the kernel
will still pass that through to the HW or LPAR
c: allows QEMU to override everything if necessary
I like that one, yes. Does the STSI payload fit into our exit payload union?
No, its up to 4k. So the STSI exit would need Function code, selector1, and
selector2, as well as guest logical address.
So something like:
index a8f4ee5..3ea5727 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -297,6 +297,13 @@ struct kvm_run {
__u32 ipb;
__u8 dequeued;
} s390_tsch;
+ /* KVM_EXIT_S390_STSI */
+ struct {
+ __u64 addr;
+ __u8 fc;
+ __u8 sel1;
+ __u16 sel2;
+ } s390_stsi;
/* KVM_EXIT_EPR */
struct {
__u32 epr;
@Paolo, Alex,
I have several changes pending that will require new ioctls. I planned to
use the config device to avoid creating new ioctls. Some option:
a: define new ioctls for these things (might end up with ~10 new ioctls)
b: allow GET_ATTR/SET_ATTR on the vm fd. We would define those as
architecture specific attributes of the VM.
c: use a config device an anchor for GET_ATTR/SET_ATTR
d: any better idea
This question is really a bike shed color discussion (which interface for
specific thing between qemu/kvm is considered best), but it will be ABI.
Paolo, do you have any preference?
I dont care about which solution we choose, but I obviously need a decision
to rework pending patches.
I think it semantically makes a lot of sense to treat the VM fd as an
implements device class :). So allowing GET_ATTR/SET_ATTR on the VM fd
makes most sense to me.
Paolo, are you ok with allowing GET_ATTR/SET_ATTR/HAS_ATTR on the vm fd. All
Attributes are then architecture specific. We might also reserve a group (e.g.
0) to be cross architecture.
As for all the individual bits you need to set, I'd like to make sure we talk
about them on a case-by-case basis. As you've seen with STSI, other solutions
might be a better fit.
Absolutely. There is a reason why this patch has an RFC and not a PULL.
Christian
[Qemu-devel] [PATCH] xbzrle: page may not be update if it has been in the cache
From: ChenLiang chenlian...@huawei.com
The cache_insert don't check whether the page has been in the cache.
Signed-off-by: ChenLiang chenlian...@huawei.com
Signed-off-by: Gonglei arei.gong...@huawei.com
---
page_cache.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/page_cache.c b/page_cache.c
index c78157b..78f7590 100644
--- a/page_cache.c
+++ b/page_cache.c
@@ -171,7 +171,7 @@ int cache_insert(PageCache *cache, uint64_t addr, const
uint8_t *pdata,
/* actual update of entry */
it = cache_get_by_addr(cache, addr);
-if (it-it_data
+if (it-it_data it-it_addr != addr
it-it_age + CACHED_PAGE_LIFETIME current_age) {
/* the cache page is fresh, don't replace it */
return -1;
--
1.7.12.4
Re: [Qemu-devel] [PATCH v4 5/8] XBZRLE: optimize XBZRLE to decrease the cache misses
Subject: Re: [Qemu-devel] [PATCH v4 5/8] XBZRLE: optimize XBZRLE to decrease the cache misses I've got a world with just patches 1..5 on that's seeing corruptions, but I've not seen where the problem is. So far the world with 1..4 on hasn't hit those corruption, but maybe I need to test more. Have you tested this set with google stressapptest? Let it migrate for a few cycles with stress apptest running, then ctrl-z the stressapptest program to let the migration complete, then fg it to collect the results. xbzrle_cache_zero_page may insert a page which has been in the cache. Thanks, Dave Best regards, -Gonglei
Re: [Qemu-devel] Unresponsive linux guest once migrated
* Marcin Gibu??a (m.gib...@beyond.pl) wrote: It's looking good so far, after a few migrations (it takes a while to test because I'm waiting at least 5 hours between migrations). I'll be happier once I've done a couple of weeks of this without any failures! Does anyone have any hints how to debug this thing? :( I've tried to put hanged guest under gdb and found it's looped deep inside kernel time management functions. Disabling kvmclock suggests it is somehow related to its corruption during migration. It happens on both old and new versions of guest kernels. Any hints from developers are welcome:) Can you give: 1) A backtrace from the guest thread apply all bt full in gdb 2) What's the earliest/newest qemu versions you've seen this on? 3) What guest OS are you running? 4) What host OS are you running? 5) What CPU are you running on? 6) What does your qemu command line look like? 7) How exactly are you migrating? 8) You talk about having to wait a few hours to trigger it - do you have a more exact description of a test? 9) Is there any output from qemu stderr/stdout in your qemu logs? Dave -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [Qemu-devel] Unresponsive linux guest once migrated
Can you give: 1) A backtrace from the guest thread apply all bt full in gdb You mean from gdb attached to hanged guest? I'll try to get it. From what I remember it looks rather normal - busy executing guest code. 2) What's the earliest/newest qemu versions you've seen this on? 1.4 - 1.6 Don't know about earlier versions because I didn't use migration on them. Haven't tried 1.7 yet (I know about XBZRLE fixes, but it happened without it as well...). 3) What guest OS are you running? All flavors of Centos, Ubuntu, Redhat, etc. Also Windows. But never seen a crash with Windows so far. Seems that few people who also have this issue, reports success with kvmclock disabled (either in qemu or kernel command line). 4) What host OS are you running? Distro is Gentoo based (with no crazy compiler options). I've been using kernel 3.4 - 3.10. 5) What CPU are you running on? AMD Opteron(tm) Processor 6164 HE 6) What does your qemu command line look like? Example VM: /usr/bin/qemu-system-x86_64 -machine accel=kvm -name 3b5e37ea-04be-4a6b-8d63-f1a5853f2138 -S -machine pc-i440fx-1.5,accel=kvm,usb=off -cpu qemu64,+misalignsse,+abm,+lahf_lm,+rdtscp,+popcnt,+x2apic,-svm,+kvmclock -m 1024 -realtime mlock=on -smp 2,sockets=4,cores=12,threads=1 -uuid 3b5e37ea-04be-4a6b-8d63-f1a5853f2138 -smbios type=0,vendor=HAL 9000 -smbios type=1,manufacturer=cloud -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/3b5e37ea-04be-4a6b-8d63-f1a5853f2138.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,clock=vm,driftfix=slew -no-hpet -no-kvm-pit-reinjection -no-shutdown -boot menu=off -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x4 -drive file=/dev/stor1c/2e7fd7aa-8588-47ed-a091-af2b81c9e935,if=none,id=drive-virtio-disk0,format=raw,cache=none,aio=native,bps_rd=57671680,bps_wr=57671680,iops_rd=275,iops_wr=275 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=2 -drive if=none,id=drive-ide0-0-0,readonly=on,format=raw -device ide-cd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -netdev tap,fd=22,id=hostnet0,vhost=on,vhostfd=27 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:11:11:11:11,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/f16x86_64.agent,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.1 -device usb-tablet,id=input0 -vnc 0.0.0.0:4,password -vga cirrus -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 -sandbox on I've tried playing with different CPU model (Opteron_G3) and flags, it didn't make any difference. 7) How exactly are you migrating? Via libvirt live migration. Seen it with and without XBZRLE enabled. 8) You talk about having to wait a few hours to trigger it - do you have a more exact description of a test? Yes, that's where it gets weird. I've never seen this on fresh VM. It needs to be idle for couple of hours at least. And even then it doesn't always hang. 9) Is there any output from qemu stderr/stdout in your qemu logs? Nothing unusual. From QEMU point of view guest is up and running. Only its OS is hanged (but not panicked, there is no backtrace, oops or BUG on its screen). -- mg
Re: [Qemu-devel] Unresponsive linux guest once migrated
* Marcin Gibu??a (m.gib...@beyond.pl) wrote: Can you give: 1) A backtrace from the guest thread apply all bt full in gdb You mean from gdb attached to hanged guest? I'll try to get it. From what I remember it looks rather normal - busy executing guest code. yes; if you can send it a sysrq to trigger a backtrace it might also be worth a try - I'm just trying to find what the guest is really doing when it's apparentyly 'hung'. 2) What's the earliest/newest qemu versions you've seen this on? 1.4 - 1.6 Don't know about earlier versions because I didn't use migration on them. Haven't tried 1.7 yet (I know about XBZRLE fixes, but it happened without it as well...). If you were going to try one thing, I'd prefer you to try the head of git, i.e.the very latest. 3) What guest OS are you running? All flavors of Centos, Ubuntu, Redhat, etc. Also Windows. But never seen a crash with Windows so far. Seems that few people who also have this issue, reports success with kvmclock disabled (either in qemu or kernel command line). OK. 4) What host OS are you running? Distro is Gentoo based (with no crazy compiler options). I've been using kernel 3.4 - 3.10. 5) What CPU are you running on? AMD Opteron(tm) Processor 6164 HE 6) What does your qemu command line look like? Example VM: /usr/bin/qemu-system-x86_64 -machine accel=kvm -name 3b5e37ea-04be-4a6b-8d63-f1a5853f2138 -S -machine pc-i440fx-1.5,accel=kvm,usb=off -cpu qemu64,+misalignsse,+abm,+lahf_lm,+rdtscp,+popcnt,+x2apic,-svm,+kvmclock -m 1024 -realtime mlock=on -smp 2,sockets=4,cores=12,threads=1 -uuid 3b5e37ea-04be-4a6b-8d63-f1a5853f2138 -smbios type=0,vendor=HAL 9000 -smbios type=1,manufacturer=cloud -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/3b5e37ea-04be-4a6b-8d63-f1a5853f2138.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,clock=vm,driftfix=slew -no-hpet -no-kvm-pit-reinjection -no-shutdown -boot menu=off -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x4 -drive file=/dev/stor1c/2e7fd7aa-8588-47ed-a091-af2b81c9e935,if=none,id=drive-virtio-disk0,format=raw,cache=none,aio=native,bps_rd=57671680,bps_wr=57671680,iops_rd=275,iops_wr=275 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=2 -drive if=none,id=drive-ide0-0-0,readonly=on,format=raw -device ide-cd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -netdev tap,fd=22,id=hostnet0,vhost=on,vhostfd=27 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:11:11:11:11,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/f16x86_64.agent,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.1 -device usb-tablet,id=input0 -vnc 0.0.0.0:4,password -vga cirrus -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 -sandbox on I've tried playing with different CPU model (Opteron_G3) and flags, it didn't make any difference. 7) How exactly are you migrating? Via libvirt live migration. Seen it with and without XBZRLE enabled. 8) You talk about having to wait a few hours to trigger it - do you have a more exact description of a test? Yes, that's where it gets weird. I've never seen this on fresh VM. It needs to be idle for couple of hours at least. And even then it doesn't always hang. So your OS is just sitting at a text console, running nothing special? When you reboot after the migration what's the last thing you see in the guests logs? Is there anything from after the migration? 9) Is there any output from qemu stderr/stdout in your qemu logs? Nothing unusual. From QEMU point of view guest is up and running. Only its OS is hanged (but not panicked, there is no backtrace, oops or BUG on its screen). Dave -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
[Qemu-devel] [PATCH 2.0] PPC: openpic_kvm: Filter memory events properly
Commit 6f1834a2b exposed a bug in openpic_kvm where we don't filter
for memory events that only happen to the region we want to know
events about.
Add proper filtering, fixing the e500plat target with KVM.
Signed-off-by: Alexander Graf ag...@suse.de
---
hw/intc/openpic_kvm.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/hw/intc/openpic_kvm.c b/hw/intc/openpic_kvm.c
index afa604d..6635407 100644
--- a/hw/intc/openpic_kvm.c
+++ b/hw/intc/openpic_kvm.c
@@ -118,6 +118,11 @@ static void kvm_openpic_region_add(MemoryListener
*listener,
abort();
}
+/* Ignore events on regions that are not us */
+if (section-mr != opp-mem) {
+return;
+}
+
reg_base = section-offset_within_address_space;
attr.group = KVM_DEV_MPIC_GRP_MISC;
@@ -140,6 +145,11 @@ static void kvm_openpic_region_del(MemoryListener
*listener,
uint64_t reg_base = 0;
int ret;
+/* Ignore events on regions that are not us */
+if (section-mr != opp-mem) {
+return;
+}
+
attr.group = KVM_DEV_MPIC_GRP_MISC;
attr.attr = KVM_DEV_MPIC_BASE_ADDR;
attr.addr = (uint64_t)(unsigned long)reg_base;
--
1.8.1.4
Re: [Qemu-devel] [RFC PATCH V4 2/5] qapi: add event helper functions
于 2014/3/28 16:21, Markus Armbruster 写道:
Eric Blake ebl...@redhat.com writes:
On 03/27/2014 02:03 AM, Wenchao Xia wrote:
This file holds some functions that do not need to be generated.
Signed-off-by: Wenchao Xia wenchaoq...@gmail.com
---
include/qapi/qmp-event.h | 27 +
qapi/Makefile.objs |1 +
qapi/qmp-event.c | 70
++
3 files changed, 98 insertions(+), 0 deletions(-)
create mode 100644 include/qapi/qmp-event.h
create mode 100644 qapi/qmp-event.c
+err = qemu_gettimeofday(tv);
+if (err 0) {
+/* Put -1 to indicate failure of getting host time */
+tv.tv_sec = -1;
+tv.tv_usec = -1;
You fixed the problem with C promotion here, but...
+}
+
+obj = qobject_from_jsonf({ 'seconds': % PRId64 ,
+ 'microseconds': % PRId64 },
+ (int64_t) tv.tv_sec, (int64_t) tv.tv_usec);
...here, C promotion rules bite once again :( If tv_usec is uint32_t,
then it zero-extends rather than sign-extends into int64_t, and you may
end up with 0x instead of the intended -1. When doing
potentially widening casts, it is only safe if you know the signedness
of the pre-cast value; but with struct timeval, POSIX doesn't make that
easy.
Maybe it's easier to just rewrite things with known types:
int64_t sec;
int usec;
qemu_timval tv;
err = qemu_gettimeofday(tv);
if (err 0) {
sec = -1;
usec = -1;
} else {
sec = tv.tv_sec;
usec = tv.tv_usec;
}
qobject_from_jsonf(... %PRId64 , ...%d, sec, usec)
since 'int' is guaranteed to be large enough for all the usec values we
care about on all platforms we compile on (that is, we require 32-bit
int, even if C allows for a 16-bit int implementation).
If you go that route, then why not go all the way nad make both sec and
usec int64_t? Look ma, no type casts!
Yep, in this way code looks better... I will respin it later with a
full conversion.
Re: [Qemu-devel] [PATCH] net: Update netdev peer on link change
On Thu, Nov 21, 2013 at 09:05:51PM -0500, Vlad Yasevich wrote:
When a link change occurs on a backend (like tap), we currently do
not propage such change to the nic. As a result, when someone turns
off a link on a tap device, for instance, then a guest doesn't see
that change and continues to try to send traffic or run DHCP even
though the lower-layer is disconnected. This is OK when the network
is set up as a HUB since the the guest may be connected to other HUB
ports too, but when it's set up as a netdev, it makes thinkgs worse.
The patch addresses this by setting the peers link down only when the
peer is not a HUBPORT device. With this patch, in the following config
-netdev tap,id=net0 -device e1000,mac=X,netdev=net0
when net0 link is turned off, the guest e1000 shows lower-layer link
down. This allows guests to boot much faster in such configurations.
With windows guest, it also allows the network to recover properly
since windows will not configure the link-local IPv4 address, and
when the link is turned on, the proper address address is configured.
Signed-off-by: Vlad Yasevich vyase...@redhat.com
---
net/net.c | 26 +-
1 file changed, 17 insertions(+), 9 deletions(-)
diff --git a/net/net.c b/net/net.c
index 0a88e68..8a084bf 100644
--- a/net/net.c
+++ b/net/net.c
@@ -1065,15 +1065,23 @@ void qmp_set_link(const char *name, bool up, Error
**errp)
nc-info-link_status_changed(nc);
}
-/* Notify peer. Don't update peer link status: this makes it possible to
- * disconnect from host network without notifying the guest.
- * FIXME: is disconnected link status change operation useful?
- *
- * Current behaviour is compatible with qemu vlans where there could be
- * multiple clients that can still communicate with each other in
- * disconnected mode. For now maintain this compatibility. */
Hmm this went in without much discussion.
But before this change went in, it was possible to control link state on NIC
and on link separately, without guest noticing.
Why did we decide to drop this functionality?
-if (nc-peer nc-peer-info-link_status_changed) {
-nc-peer-info-link_status_changed(nc-peer);
+if (nc-peer) {
+/* Change peer link only if the peer is NIC and then notify peer.
+ * If the peer is a HUBPORT or a backend, we do not change the
+ * link status.
+ *
+ * This behavior is compatible with qemu vlans where there could be
+ * multiple clients that can still communicate with each other in
+ * disconnected mode. For now maintain this compatibility.
+ */
+if (nc-peer-info-type == NET_CLIENT_OPTIONS_KIND_NIC) {
+for (i = 0; i queues; i++) {
+ncs[i]-peer-link_down = !up;
+}
+}
+if (nc-peer-info-link_status_changed) {
+nc-peer-info-link_status_changed(nc-peer);
+}
}
}
--
1.8.4.2
Re: [Qemu-devel] Unresponsive linux guest once migrated
On 02.04.2014 11:39, Dr. David Alan Gilbert wrote: * Marcin Gibu??a (m.gib...@beyond.pl) wrote: Can you give: 1) A backtrace from the guest thread apply all bt full in gdb You mean from gdb attached to hanged guest? I'll try to get it. From what I remember it looks rather normal - busy executing guest code. yes; if you can send it a sysrq to trigger a backtrace it might also be worth a try - I'm just trying to find what the guest is really doing when it's apparentyly 'hung'. IIRC VM doesn't respond to sysrq key sequence. It doesn't respond to anything actually but NMI. I tried to do inject-nmi. VMs kernel responded with timestamped message Uhhuh. NMI received. Dazed and confused, but trying to continue. That timestamp never changes - its like time is frozen on VM. I'll try to find my notes from this gdb session. -- mg
Re: [Qemu-devel] [PATCH] net: Update netdev peer on link change
On Apr 2, 2014, at 11:51 AM, Michael S. Tsirkin m...@redhat.com wrote:
On Thu, Nov 21, 2013 at 09:05:51PM -0500, Vlad Yasevich wrote:
When a link change occurs on a backend (like tap), we currently do
not propage such change to the nic. As a result, when someone turns
off a link on a tap device, for instance, then a guest doesn't see
that change and continues to try to send traffic or run DHCP even
though the lower-layer is disconnected. This is OK when the network
is set up as a HUB since the the guest may be connected to other HUB
ports too, but when it's set up as a netdev, it makes thinkgs worse.
The patch addresses this by setting the peers link down only when the
peer is not a HUBPORT device. With this patch, in the following config
-netdev tap,id=net0 -device e1000,mac=X,netdev=net0
when net0 link is turned off, the guest e1000 shows lower-layer link
down. This allows guests to boot much faster in such configurations.
With windows guest, it also allows the network to recover properly
since windows will not configure the link-local IPv4 address, and
when the link is turned on, the proper address address is configured.
Signed-off-by: Vlad Yasevich vyase...@redhat.com
---
net/net.c | 26 +-
1 file changed, 17 insertions(+), 9 deletions(-)
diff --git a/net/net.c b/net/net.c
index 0a88e68..8a084bf 100644
--- a/net/net.c
+++ b/net/net.c
@@ -1065,15 +1065,23 @@ void qmp_set_link(const char *name, bool up, Error
**errp)
nc-info-link_status_changed(nc);
}
-/* Notify peer. Don't update peer link status: this makes it possible to
- * disconnect from host network without notifying the guest.
- * FIXME: is disconnected link status change operation useful?
- *
- * Current behaviour is compatible with qemu vlans where there could be
- * multiple clients that can still communicate with each other in
- * disconnected mode. For now maintain this compatibility. */
Hmm this went in without much discussion.
But before this change went in, it was possible to control link state on NIC
and on link separately, without guest noticing.
Why did we decide to drop this functionality?
Not sure there was a real need for the patch.
On other hand Windows guest will not receive IP address from DHCP server if you
start VM with tap link down and then set it to up without toggling link state
of the guest device as well.
Yan.
-if (nc-peer nc-peer-info-link_status_changed) {
-nc-peer-info-link_status_changed(nc-peer);
+if (nc-peer) {
+/* Change peer link only if the peer is NIC and then notify peer.
+ * If the peer is a HUBPORT or a backend, we do not change the
+ * link status.
+ *
+ * This behavior is compatible with qemu vlans where there could be
+ * multiple clients that can still communicate with each other in
+ * disconnected mode. For now maintain this compatibility.
+ */
+if (nc-peer-info-type == NET_CLIENT_OPTIONS_KIND_NIC) {
+for (i = 0; i queues; i++) {
+ncs[i]-peer-link_down = !up;
+}
+}
+if (nc-peer-info-link_status_changed) {
+nc-peer-info-link_status_changed(nc-peer);
+}
}
}
--
1.8.4.2
Re: [Qemu-devel] [PATCH 2/6] intc/openpic_kvm: fix MemListener delete regiion callback function
Am 02.04.2014 10:54, schrieb Alexander Graf: On 24.03.14 15:25, Andreas Färber wrote: Am 23.03.2014 10:28, schrieb Prasad Joshi: Signed-off-by: Prasad Joshi prasadjoshi.li...@gmail.com --- hw/intc/openpic_kvm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Thanks for spotting this, applied to ppc-next (w/ typo fix in subject): https://github.com/afaerber/qemu-cpu/commits/ppc-next This patch breaks the e500 platform target. Ouch. I had specifically tested build and -M pseries on PowerKVM but obviously did not for e500. Means it was theoretically broken from the start then, if you compare my extended commit message: http://git.qemu.org/?p=qemu.git;a=commit;h=6f1834a2baa2f2688efaa7756d000876c7898d13 Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH] net: Update netdev peer on link change
On Wed, Apr 02, 2014 at 01:46:14PM +0300, Yan Vugenfirer wrote:
On Apr 2, 2014, at 11:51 AM, Michael S. Tsirkin m...@redhat.com wrote:
On Thu, Nov 21, 2013 at 09:05:51PM -0500, Vlad Yasevich wrote:
When a link change occurs on a backend (like tap), we currently do
not propage such change to the nic. As a result, when someone turns
off a link on a tap device, for instance, then a guest doesn't see
that change and continues to try to send traffic or run DHCP even
though the lower-layer is disconnected. This is OK when the network
is set up as a HUB since the the guest may be connected to other HUB
ports too, but when it's set up as a netdev, it makes thinkgs worse.
The patch addresses this by setting the peers link down only when the
peer is not a HUBPORT device. With this patch, in the following config
-netdev tap,id=net0 -device e1000,mac=X,netdev=net0
when net0 link is turned off, the guest e1000 shows lower-layer link
down. This allows guests to boot much faster in such configurations.
With windows guest, it also allows the network to recover properly
since windows will not configure the link-local IPv4 address, and
when the link is turned on, the proper address address is configured.
Signed-off-by: Vlad Yasevich vyase...@redhat.com
---
net/net.c | 26 +-
1 file changed, 17 insertions(+), 9 deletions(-)
diff --git a/net/net.c b/net/net.c
index 0a88e68..8a084bf 100644
--- a/net/net.c
+++ b/net/net.c
@@ -1065,15 +1065,23 @@ void qmp_set_link(const char *name, bool up, Error
**errp)
nc-info-link_status_changed(nc);
}
-/* Notify peer. Don't update peer link status: this makes it possible
to
- * disconnect from host network without notifying the guest.
- * FIXME: is disconnected link status change operation useful?
- *
- * Current behaviour is compatible with qemu vlans where there could
be
- * multiple clients that can still communicate with each other in
- * disconnected mode. For now maintain this compatibility. */
Hmm this went in without much discussion.
But before this change went in, it was possible to control link state on NIC
and on link separately, without guest noticing.
Why did we decide to drop this functionality?
Not sure there was a real need for the patch.
On other hand Windows guest will not receive IP address from DHCP server if
you start VM with tap link down and then set it to up without toggling link
state of the guest device as well.
Yan.
So why not toggle the link of the guest device?
-if (nc-peer nc-peer-info-link_status_changed) {
-nc-peer-info-link_status_changed(nc-peer);
+if (nc-peer) {
+/* Change peer link only if the peer is NIC and then notify peer.
+ * If the peer is a HUBPORT or a backend, we do not change the
+ * link status.
+ *
+ * This behavior is compatible with qemu vlans where there could
be
+ * multiple clients that can still communicate with each other in
+ * disconnected mode. For now maintain this compatibility.
+ */
+if (nc-peer-info-type == NET_CLIENT_OPTIONS_KIND_NIC) {
+for (i = 0; i queues; i++) {
+ncs[i]-peer-link_down = !up;
+}
+}
+if (nc-peer-info-link_status_changed) {
+nc-peer-info-link_status_changed(nc-peer);
+}
}
}
--
1.8.4.2
Re: [Qemu-devel] Qemu 2.0 regression with xen: qemu crash on any domUs S.O. start
Il 01/04/2014 18:24, Laszlo Ersek ha scritto: On 04/01/14 17:01, Fabio Fantoni wrote: Today I tried latest qemu 2.0 compiled from git (commit 63678e17cf399ff81b93417fe7bee8d6ef6b6b1b) on this dom0: Debian 7 (Wheezy) 64 bit with kernel from package linux-image-3.2.0-4-amd64 version 3.2.54-2 and all dependency packages for xen, spice and usb redirection. Seabios 1.7.3-3, spice 0.12.4-0nocelt2 and usbredir 0.6-2 compiled from debian unstable sources. The xen-unstable upstream commit is 4787f667bcee205c56a27da59b766a53e1e929eb, plus these patches not upstream: tools: various things just to build test tools: Improve make debball libxl: Add qxl vga interface support for upstream qemu libxl: add basic spice support for pv domUs Qemu crashes always on domU S.O. start, on both pv and hvm domUs. Same dom0 with qemu 1.6 from xen-unstable repository used for some tests yesterday and was full working. I also update seabios to 1.7.4-4 compiled from debian unstable sources but the problem persists. I looked on dom0 logs, qemu logs and xl dmesg and I found only a qemu segfault related on each domU in dom0 syslog, for example the latest: [ 844.273170] qemu-system-i38[3545]: segfault at 8 ip 7fa905dcc4c1 sp 7fff41220810 error 4 in qemu-system-i386[7fa905ad5000+598000] If you need more informations, tests and/or logs tell me and I'll post them. Whoever looks into this would be greatly helped: - if you bisected the issue (between 1.6 and 2.0-rcX), I tried time ago qemu 1.7 and qemu 2.0 on start of development without problem on domUs start but I'll retry. - if you posted qemu's backtrace at the sigsegv. I tried to use gdb following this old post: https://lists.gnu.org/archive/html/qemu-devel/2011-12/msg02575.html but with same changes: /usr/lib/xen/bin# vi qemu-system-i386 #!/bin/sh exec gdbserver 0.0.0.0:1234 /usr/lib/xen/bin/qemu-system-i386.bak $@ gdb /usr/lib/xen/bin/qemu-system-i386.bak target remote localhost:1234 This command with gdb on qemu fails: xl -vvv create /etc/xen/wheezy.cfg ... libxl: error: libxl_dm.c:1378:device_model_spawn_outcome: domain 13 device model: spawn failed (rc=-3) libxl: error: libxl_create.c:1207:domcreate_devmodel_started: device model did not start: -3 libxl: debug: libxl_dm.c:1485:kill_device_model: Device Model signaled ... the dom0 syslog show segfault also in this case and the qemu log is different on first lines (probably for gdbserver): less /var/log/xen/qemu-dm-wheezy.log Process /usr/lib/xen/bin/qemu-system-i386.bak created; pid = 8238 Listening on port 1234 Remote debugging from host 127.0.0.1 xc: error: linux_gnttab_set_max_grants: ioctl SET_MAX_GRANTS failed (22 = Invalid argument): Internal error xen be: qdisk-51712: xc_gnttab_set_max_grants failed: Invalid argument gdb on xl create show: (gdb) target remote localhost:1234 Remote debugging using localhost:1234 Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/ld-linux-x86-64.so.2 0x77dddaf0 in ?? () from /lib64/ld-linux-x86-64.so.2 (gdb) (gdb) bt full #0 0x77dddaf0 in ?? () from /lib64/ld-linux-x86-64.so.2 No symbol table info available. #1 0x0013 in ?? () No symbol table info available. #2 0x7fffe871 in ?? () No symbol table info available. #3 0x7fffe897 in ?? () No symbol table info available. #4 0x7fffe8a2 in ?? () No symbol table info available. #5 0x7fffe8a5 in ?? () No symbol table info available. #6 0x7fffe8ae in ?? () No symbol table info available. #7 0x7fffe8ef in ?? () No symbol table info available. #8 0x7fffe8f4 in ?? () No symbol table info available. #9 0x7fffe913 in ?? () No symbol table info available. #10 0x7fffe91f in ?? () No symbol table info available. #11 0x7fffe92b in ?? () No symbol table info available. #12 0x7fffe931 in ?? () ---Type return to continue, or q return to quit--- the qemu include debug and is not stripped: file /usr/lib/xen/bin/qemu-system-i386.bak /usr/lib/xen/bin/qemu-system-i386.bak: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=0x5aa043b5524d74d166ead62527343080384d586b, not stripped and I also tried: aptitude install libc6-dbg but same result. I not understand what I missed for correct xl create and/or gdb informations. Can someone help me please? Thanks for any reply Laszlo
Re: [Qemu-devel] [PATCH 2/6] intc/openpic_kvm: fix MemListener delete regiion callback function
Am 02.04.2014 um 12:53 schrieb Andreas Färber afaer...@suse.de: Am 02.04.2014 10:54, schrieb Alexander Graf: On 24.03.14 15:25, Andreas Färber wrote: Am 23.03.2014 10:28, schrieb Prasad Joshi: Signed-off-by: Prasad Joshi prasadjoshi.li...@gmail.com --- hw/intc/openpic_kvm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Thanks for spotting this, applied to ppc-next (w/ typo fix in subject): https://github.com/afaerber/qemu-cpu/commits/ppc-next This patch breaks the e500 platform target. Ouch. I had specifically tested build and -M pseries on PowerKVM but obviously did not for e500. Yeah, this file is only used on e500 with kvm enabled. No worries, things worked out well :). Means it was theoretically broken from the start then, if you compare my extended commit message: http://git.qemu.org/?p=qemu.git;a=commit;h=6f1834a2baa2f2688efaa7756d000876c7898d13 Well, it definitely worked before, though most likely by chance ;). Alex Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
[Qemu-devel] [Bug 1285708] Re: FreeBSD Guest crash on boot due to xsave instruction issue
** Also affects: qemu-kvm Importance: Undecided Status: New ** Also affects: qemu (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1285708 Title: FreeBSD Guest crash on boot due to xsave instruction issue Status in QEMU: New Status in qemu-kvm: New Status in “qemu” package in Ubuntu: New Bug description: When trying to boot a working FreeBSD 9.1/9.2 guest on a kvm/qemu host with the following command: kvm -m 256 -cdrom FreeBSD-9.2-RELEASE-amd64-disc1.iso -drive file=FreeBSD-9.2-RELEASE-amd64.qcow2,if=virtio -net nic,model=virtio -net user -nographic -vnc :10 -enable-kvm -balloon virtio -cpu core2duo,+xsave The FreeBSD Guest will kernel crash on boot with the following error: panic: CPU0 does not support X87 or SSE: 0 When launching the guest without the cpu flags, it works just fine. This bug has been resolved in source: https://lkml.org/lkml/2014/2/22/58 Can this fix be included in Precise ASAP! To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1285708/+subscriptions
Re: [Qemu-devel] [PATCH] QEMU: ARM: boot: Load kernel at an Image friendly address
On Wed, Apr 2, 2014 at 3:10 AM, Peter Maydell peter.mayd...@linaro.org wrote: On 25 March 2014 03:34, Joel Fernandes jo...@ti.com wrote: Loading kernel at offset 0x1 works only for zImage, but not for Image, because the kernel expect the start of decompressed kernel (.head.text) to be at an address that's a distance that's 16MB aligned from PAGE_OFFSET + TEXT_OFFSET (see vmlinux.lds.S). This check is enfornced in __fixup_pv_table in arch/arm/kernel/head.S TEXT_OFFSET is 0x8000, so a 16MB alignment needs to have a 0x8000 in the lower 16 bits so that they cancel out. Currently the offset Qemu loads it at is 0x1. With zImage, this need is met because zImage loads the uncompressed Image correctly, however when loading an Image and executing directly Qemu is required it to load it at the correct location. Doing so, doesn't break Qemu's zImage loading. With this patch, both zImage and Image work correctly. Signed-off-by: Joel Fernandes jo...@ti.com Reviewed-by: Peter Maydell peter.mayd...@linaro.org Like others, I have been carrying this change locally. Good to see it up! Reviewed-by: Peter Crosthwaite peter.crosthwa...@xilinx.com Tested-by: Peter Crosthwaite peter.crosthwa...@xilinx.com I'll put this in target-arm.next after 2.0 has released. thanks -- PMM
Re: [Qemu-devel] [PATCH v5 27/37] target-arm: Remove THUMB2EE feature from AArch64 'any' CPU
On Sat, Mar 29, 2014 at 2:10 AM, Peter Maydell peter.mayd...@linaro.org wrote: The AArch64 usermode 'any' CPU type was accidentally specified with the ARM_FEATURE_THUMB2EE bit set. This is incorrect since ARMv8 removes Thumb2EE completely. Since we never implemented Thumb2EE anyway having the feature bit set was fairly harmless for user-mode, but the correct thing is to not set it at all. Signed-off-by: Peter Maydell peter.mayd...@linaro.org Reviewed-by: Peter Crosthwaite peter.crosthwa...@xilinx.com --- target-arm/cpu64.c | 1 - 1 file changed, 1 deletion(-) diff --git a/target-arm/cpu64.c b/target-arm/cpu64.c index 5be7d72..b8b4fa6 100644 --- a/target-arm/cpu64.c +++ b/target-arm/cpu64.c @@ -83,7 +83,6 @@ static void aarch64_any_initfn(Object *obj) set_feature(cpu-env, ARM_FEATURE_VFP4); set_feature(cpu-env, ARM_FEATURE_VFP_FP16); set_feature(cpu-env, ARM_FEATURE_NEON); -set_feature(cpu-env, ARM_FEATURE_THUMB2EE); set_feature(cpu-env, ARM_FEATURE_ARM_DIV); set_feature(cpu-env, ARM_FEATURE_V7MP); set_feature(cpu-env, ARM_FEATURE_AARCH64); -- 1.9.0
Re: [Qemu-devel] [PATCH 0/4] Fix relative pointer tracking on Gtk UI
At Tue, 01 Apr 2014 16:34:15 -0400, Cole Robinson wrote: On 02/13/2014 06:15 AM, Takashi Iwai wrote: Hi, this is a series of patches to fix / improve the behavior of Gtk UI in the relative pointer tracking mode. Most people didn't notice the bug likely because it doesn't appear as long as the aboslute mode is used, e.g. when vmmouse input driver is enabled. But I hit this annoying behavior because of the recent regression of vmmouse driver (that doesn't work as default). Or, it might be that this didn't happen with the old Gtk2. Dunno. The last two patches are no actual fixes but rather behavior changes for my tastes. Both are to align the behavior compatible with SDL UI, and I like it better just because I got used to it. So, I don't mind if they are skipped. I just hit this issue too. Unfortunately Anthony hasn't been around qemu-devel much recently so these slipped through the cracks. Can you rebase on qemu.git (you'll have to s/kbd_mouse_is_absolute/qemu_mouse_is_absolute/ at least) and repost? Please cc me and kra...@redhat.com, I'll test and review OK, I'm going to submit the renewed patch series. thanks, Takashi
Re: [Qemu-devel] [PULL for-2.0 2/2] cpu: Avoid QOM casts for CPU()
On Mon, Mar 31, 2014 at 7:37 PM, Andreas Färber afaer...@suse.de wrote: CPU address spaces touching load and store helpers as well as the movement of (almost) all fields from CPU_COMMON to CPUState have led to a noticeable increase of CPU() usage in hot paths for both TCG and KVM. While CPU()'s OBJECT_CHECK() might help detect development errors, i.e. in form of crashes due to QOM vs. non-QOM mismatches rather than QOM type mismatches, it is not really needed at runtime since mostly used in CPU-specific paths, coming from a target-specific CPU subtype. If that pointer is damaged, other errors are highly likely to occur elsewhere anyway. Keep the CPU() macro for a consistent developer experience and for flexibility to exchange its implementation, but turn it into a pure, unchecked C cast for now. I re-ran my image to measure the improvements. Intel 4770K (no HT, no OC) Fedora Core 19 QEMU 82c6f513735297ad76acaaf2e87f0c5a0b3647a7 Image: ARM kernel + Google V8 running Sunspider old: without this patch strong: default stack protection (strong in my case) noprot: no stack protection (--disable-stack-protector) disable: no QOM debug (--disable-qom-cast-debug) old+strong 16.7 old+strong+disable 15.9 old+noprot 16.6 old+noprot+disable 16.0 strong 15.8 strong+disable 15.7 noprot 15.6 noprot+disable 15.5 Thanks, Laurent Compare commit 6e42be7cd10260fd3a006d94f6c870692bf7a2c0. Reported-by: Laurent Desnogues laurent.desnog...@gmail.com Suggested-by: Paolo Bonzini pbonz...@redhat.com Signed-off-by: Andreas Färber afaer...@suse.de --- include/qom/cpu.h | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/include/qom/cpu.h b/include/qom/cpu.h index f99885a..df977c8 100644 --- a/include/qom/cpu.h +++ b/include/qom/cpu.h @@ -53,7 +53,12 @@ typedef uint64_t vaddr; #define TYPE_CPU cpu -#define CPU(obj) OBJECT_CHECK(CPUState, (obj), TYPE_CPU) +/* Since this macro is used a lot in hot code paths and in conjunction with + * FooCPU *foo_env_get_cpu(), we deviate from usual QOM practice by using + * an unchecked cast. + */ +#define CPU(obj) ((CPUState *)(obj)) + #define CPU_CLASS(class) OBJECT_CLASS_CHECK(CPUClass, (class), TYPE_CPU) #define CPU_GET_CLASS(obj) OBJECT_GET_CLASS(CPUClass, (obj), TYPE_CPU) -- 1.8.4.5
[Qemu-devel] [PATCH v2 0/4] Fix relative pointer tracking on Gtk UI (v2)
Hi, this is the renewed patch series, just rebased the previous ones on top of the current git tree. Below is the original description: *** Hi, this is a series of patches to fix / improve the behavior of Gtk UI in the relative pointer tracking mode. Most people didn't notice the bug likely because it doesn't appear as long as the aboslute mode is used, e.g. when vmmouse input driver is enabled. But I hit this annoying behavior because of the recent regression of vmmouse driver (that doesn't work as default). Or, it might be that this didn't happen with the old Gtk2. Dunno. The last two patches are no actual fixes but rather behavior changes for my tastes. Both are to align the behavior compatible with SDL UI, and I like it better just because I got used to it. So, I don't mind if they are skipped. thanks, Takashi
[Qemu-devel] [PATCH v2 4/4] gtk: Add Grab On Click option
I simply like it better, you don't? :)
Signed-off-by: Takashi Iwai ti...@suse.de
---
ui/gtk.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/ui/gtk.c b/ui/gtk.c
index 9b8df1224fdb..ffaf91ea453a 100644
--- a/ui/gtk.c
+++ b/ui/gtk.c
@@ -141,6 +141,7 @@ typedef struct GtkDisplayState
GtkWidget *zoom_fit_item;
GtkWidget *grab_item;
GtkWidget *grab_on_hover_item;
+GtkWidget *grab_on_click_item;
GtkWidget *vga_item;
int nb_vcs;
@@ -189,6 +190,11 @@ static bool gd_grab_on_hover(GtkDisplayState *s)
return
gtk_check_menu_item_get_active(GTK_CHECK_MENU_ITEM(s-grab_on_hover_item));
}
+static bool gd_grab_on_click(GtkDisplayState *s)
+{
+return
gtk_check_menu_item_get_active(GTK_CHECK_MENU_ITEM(s-grab_on_click_item));
+}
+
static bool gd_on_vga(GtkDisplayState *s)
{
return gtk_notebook_get_current_page(GTK_NOTEBOOK(s-notebook)) == 0;
@@ -685,6 +691,12 @@ static gboolean gd_button_event(GtkWidget *widget,
GdkEventButton *button,
GtkDisplayState *s = opaque;
InputButton btn;
+if (button-button == 1 button-type == GDK_BUTTON_PRESS
+ !gd_is_grab_active(s) gd_grab_on_click(s) button-button == 1) {
+gtk_check_menu_item_set_active(GTK_CHECK_MENU_ITEM(s-grab_item),
TRUE);
+ return TRUE;
+}
+
if (button-button == 1) {
btn = INPUT_BUTTON_LEFT;
} else if (button-button == 2) {
@@ -1416,6 +1428,9 @@ static GtkWidget *gd_create_menu_view(GtkDisplayState *s,
GtkAccelGroup *accel_g
s-grab_on_hover_item = gtk_check_menu_item_new_with_mnemonic(_(Grab On
_Hover));
gtk_menu_shell_append(GTK_MENU_SHELL(view_menu), s-grab_on_hover_item);
+s-grab_on_click_item = gtk_check_menu_item_new_with_mnemonic(_(Grab On
_Click));
+gtk_menu_shell_append(GTK_MENU_SHELL(view_menu), s-grab_on_click_item);
+
s-grab_item = gtk_check_menu_item_new_with_mnemonic(_(_Grab Input));
gtk_menu_item_set_accel_path(GTK_MENU_ITEM(s-grab_item),
QEMU/View/Grab Input);
--
1.9.1
[Qemu-devel] [PATCH v2 3/4] gtk: Remember the last grabbed pointer position
It's pretty annoying that the pointer reappears at a random place once
after grabbing and ungrabbing the input. Better to restore to the
original position where the pointer was grabbed.
Reference: https://bugzilla.novell.com/show_bug.cgi?id=849587
Signed-off-by: Takashi Iwai ti...@suse.de
---
ui/gtk.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/ui/gtk.c b/ui/gtk.c
index c407fc8dd1a3..9b8df1224fdb 100644
--- a/ui/gtk.c
+++ b/ui/gtk.c
@@ -159,6 +159,8 @@ typedef struct GtkDisplayState
gboolean last_set;
int last_x;
int last_y;
+int grab_x_root;
+int grab_y_root;
double scale_x;
double scale_y;
@@ -970,8 +972,8 @@ static void gd_ungrab_keyboard(GtkDisplayState *s)
static void gd_grab_pointer(GtkDisplayState *s)
{
-#if GTK_CHECK_VERSION(3, 0, 0)
GdkDisplay *display = gtk_widget_get_display(s-drawing_area);
+#if GTK_CHECK_VERSION(3, 0, 0)
GdkDeviceManager *mgr = gdk_display_get_device_manager(display);
GList *devices = gdk_device_manager_list_devices(mgr,
GDK_DEVICE_TYPE_MASTER);
@@ -995,6 +997,8 @@ static void gd_grab_pointer(GtkDisplayState *s)
tmp = tmp-next;
}
g_list_free(devices);
+gdk_device_get_position(gdk_device_manager_get_client_pointer(mgr),
+NULL, s-grab_x_root, s-grab_y_root);
#else
gdk_pointer_grab(gtk_widget_get_window(s-drawing_area),
FALSE, /* All events to come to our window directly */
@@ -1006,13 +1010,15 @@ static void gd_grab_pointer(GtkDisplayState *s)
NULL, /* Allow cursor to move over entire desktop */
s-null_cursor,
GDK_CURRENT_TIME);
+gdk_display_get_pointer(display, NULL,
+s-grab_x_root, s-grab_y_root, NULL);
#endif
}
static void gd_ungrab_pointer(GtkDisplayState *s)
{
-#if GTK_CHECK_VERSION(3, 0, 0)
GdkDisplay *display = gtk_widget_get_display(s-drawing_area);
+#if GTK_CHECK_VERSION(3, 0, 0)
GdkDeviceManager *mgr = gdk_display_get_device_manager(display);
GList *devices = gdk_device_manager_list_devices(mgr,
GDK_DEVICE_TYPE_MASTER);
@@ -1026,8 +1032,14 @@ static void gd_ungrab_pointer(GtkDisplayState *s)
tmp = tmp-next;
}
g_list_free(devices);
+gdk_device_warp(gdk_device_manager_get_client_pointer(mgr),
+gtk_widget_get_screen(s-drawing_area),
+s-grab_x_root, s-grab_y_root);
#else
gdk_pointer_ungrab(GDK_CURRENT_TIME);
+gdk_display_warp_pointer(display,
+ gtk_widget_get_screen(s-drawing_area),
+ s-grab_x_root, s-grab_y_root);
#endif
}
--
1.9.1
[Qemu-devel] [PATCH v2 1/4] gtk: Use gtk generic event signal instead of motion-notify-event
The GDK motion-notify-event isn't generated when the pointer goes out
of the target window even if the pointer is grabbed, which essentially
means to lose the pointer tracking in gtk-ui.
Meanwhile the generic event signal is sent when the pointer is
grabbed, so we can use this and pick the motion notify events manually
there instead.
Reference: https://bugzilla.novell.com/show_bug.cgi?id=849587
Signed-off-by: Takashi Iwai ti...@suse.de
---
ui/gtk.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/ui/gtk.c b/ui/gtk.c
index f056e4034b3e..54b835428a28 100644
--- a/ui/gtk.c
+++ b/ui/gtk.c
@@ -765,6 +765,13 @@ static gboolean gd_key_event(GtkWidget *widget,
GdkEventKey *key, void *opaque)
return TRUE;
}
+static gboolean gd_event(GtkWidget *widget, GdkEvent *event, void *opaque)
+{
+if (event-type == GDK_MOTION_NOTIFY)
+return gd_motion_event(widget, event-motion, opaque);
+return FALSE;
+}
+
/** Window Menu Actions **/
static void gd_menu_pause(GtkMenuItem *item, void *opaque)
@@ -1267,8 +1274,8 @@ static void gd_connect_signals(GtkDisplayState *s)
g_signal_connect(s-drawing_area, expose-event,
G_CALLBACK(gd_expose_event), s);
#endif
-g_signal_connect(s-drawing_area, motion-notify-event,
- G_CALLBACK(gd_motion_event), s);
+g_signal_connect(s-drawing_area, event,
+ G_CALLBACK(gd_event), s);
g_signal_connect(s-drawing_area, button-press-event,
G_CALLBACK(gd_button_event), s);
g_signal_connect(s-drawing_area, button-release-event,
--
1.9.1
[Qemu-devel] [PATCH v2 2/4] gtk: Fix the relative pointer tracking mode
The relative pointer tracking mode was still buggy even after the
previous fix of the motion-notify-event since the events are filtered
out when the pointer moves outside the drawing window due to the
boundary check for the absolute mode.
This patch fixes the issue by moving the unnecessary boundary check
into the if block of absolute mode, and keep the coordinate in the
relative mode even if it's outside the drawing area. But this makes
the coordinate (last_x, last_y) possibly pointing to (-1,-1),
introduce a new flag to indicate the last coordinate has been
updated.
Reference: https://bugzilla.novell.com/show_bug.cgi?id=849587
Signed-off-by: Takashi Iwai ti...@suse.de
---
ui/gtk.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/ui/gtk.c b/ui/gtk.c
index 54b835428a28..c407fc8dd1a3 100644
--- a/ui/gtk.c
+++ b/ui/gtk.c
@@ -156,6 +156,7 @@ typedef struct GtkDisplayState
DisplayChangeListener dcl;
DisplaySurface *ds;
int button_mask;
+gboolean last_set;
int last_x;
int last_y;
@@ -616,25 +617,25 @@ static gboolean gd_motion_event(GtkWidget *widget,
GdkEventMotion *motion,
x = (motion-x - mx) / s-scale_x;
y = (motion-y - my) / s-scale_y;
-if (x 0 || y 0 ||
-x = surface_width(s-ds) ||
-y = surface_height(s-ds)) {
-return TRUE;
-}
-
if (qemu_input_is_absolute()) {
+if (x 0 || y 0 ||
+x = surface_width(s-ds) ||
+y = surface_height(s-ds)) {
+return TRUE;
+}
qemu_input_queue_abs(s-dcl.con, INPUT_AXIS_X, x,
surface_width(s-ds));
qemu_input_queue_abs(s-dcl.con, INPUT_AXIS_Y, y,
surface_height(s-ds));
qemu_input_event_sync();
-} else if (s-last_x != -1 s-last_y != -1 gd_is_grab_active(s)) {
+} else if (s-last_set gd_is_grab_active(s)) {
qemu_input_queue_rel(s-dcl.con, INPUT_AXIS_X, x - s-last_x);
qemu_input_queue_rel(s-dcl.con, INPUT_AXIS_Y, y - s-last_y);
qemu_input_event_sync();
}
s-last_x = x;
s-last_y = y;
+s-last_set = TRUE;
if (!qemu_input_is_absolute() gd_is_grab_active(s)) {
GdkScreen *screen = gtk_widget_get_screen(s-drawing_area);
@@ -669,8 +670,7 @@ static gboolean gd_motion_event(GtkWidget *widget,
GdkEventMotion *motion,
GdkDisplay *display = gtk_widget_get_display(widget);
gdk_display_warp_pointer(display, screen, x, y);
#endif
-s-last_x = -1;
-s-last_y = -1;
+s-last_set = FALSE;
return FALSE;
}
}
--
1.9.1
Re: [Qemu-devel] E820 (Re: [v4 PATCH 00/12] SMBIOS: build full tables in QEMU)
On Wed, Apr 02, 2014 at 12:35:26AM +0200, Laszlo Ersek wrote:
On 04/02/14 00:00, Kevin O'Connor wrote:
On Tue, Apr 01, 2014 at 11:44:12PM +0200, Laszlo Ersek wrote:
Right now, OVMF can accept individual fields, or table-at-a-time blobs,
via fw_cfg.
The internal interface (EFI_SMBIOS_PROTOCOL) expects one table at a time
(for which table-at-a-time blobs are a perfect match).
I wasn't aware of this. The SMBIOS spec calls for all the sub-tables
to be concatenanted into a single linear area of memory. Is there
something in EFI or OVMF that is dictating otherwise? Can you provide
a link so I can further understand? (I briefly checked through the
UEFI v2.3.1 spec and nothing popped out at me.)
The UEFI Specification is not relevant here, the UEFI Platform
Initialization (PI) Specification is.
You can download the PI spec at http://www.uefi.org/specs/access. The
relevant section is (I have version 1.2.1):
VOLUME 5: Platform Initialization Specification
Standards
6 SMBIOS Protocol
The function to call is EFI_SMBIOS_PROTOCOL.Add().
I think that concatenating table-at-a-time blobs in SeaBIOS is easier
than parsing splitting a complete dump into tables in OVMF.
I don't think it's very difficult either way. It would be nice,
though, if there was just one owner for the smbios. The current setup
where some data comes from QEMU and some from the firmware, along with
mechanisms for providing defaults and overrides is way too complex in
my opinion.
I certainly agree with the direction. I'm OK with the current
table-at-a-time blobs (which should leave only the SMBIOS entry point to
the firmware). I'm also OK with any new, comprehensive format that
allows me, with reasonable parsing, to identify the individual tables in
the big concat (and to throw away the passed down entry point).
I already wrote display_uuid() [src/fw/smbios.c] for SeaBIOS, so I guess
I could repeat the exercise if it's unavoidable... :)
Kevin, Laszlo,
What if I found a way to send an entry point structure via fw_cfg, as
a signal to ${BIOS} to simply assemble all the table-at-a-time blobs,
but without generating any of its own ?
I'm still working my way through whether *I* like the idea or not, but
figured I'd throw it out there as a potential compromise ? :)
Thx,
--Gabriel
[Qemu-devel] [PATCH for-2.0] iscsi: recognize invalid field ASCQ from WRITE SAME command
Some targets may return invalid field as the ASCQ from WRITE SAME
if they support the command only without the UNMAP field. Recognize
that, and return ENOTSUP just like for invalid operation code.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
block/iscsi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/block/iscsi.c b/block/iscsi.c
index 6d6cd4f..f01c883 100644
--- a/block/iscsi.c
+++ b/block/iscsi.c
@@ -1012,7 +1012,8 @@ retry:
if (iTask.status == SCSI_STATUS_CHECK_CONDITION
iTask.task-sense.key == SCSI_SENSE_ILLEGAL_REQUEST
-iTask.task-sense.ascq == SCSI_SENSE_ASCQ_INVALID_OPERATION_CODE) {
+(iTask.task-sense.ascq == SCSI_SENSE_ASCQ_INVALID_OPERATION_CODE ||
+iTask.task-sense.ascq == SCSI_SENSE_ASCQ_INVALID_FIELD_IN_CDB)) {
/* WRITE SAME is not supported by the target */
iscsilun-has_write_same = false;
scsi_free_scsi_task(iTask.task);
--
1.9.0
Re: [Qemu-devel] [PATCH] QEMU: ARM: boot: Load kernel at an Image friendly address
On 2 April 2014 13:11, Peter Crosthwaite peter.crosthwa...@xilinx.com wrote: Like others, I have been carrying this change locally. Good to see it up! Why are you all booting raw Images anyway (just out of curiosity)? All my test cases boot either a zImage or a uImage, or occasionally a full SD card image, or I'd have noticed this earlier... thanks -- PMM
Re: [Qemu-devel] [PATCH for-2.0 2/2] prep: remove CPU reset entry point hack related to OpenHack'Ware
Il 01/04/2014 23:19, Hervé Poussineau ha scritto:
Signed-off-by: Hervé Poussineau hpous...@reactos.org
---
hw/ppc/prep.c |3 ---
1 file changed, 3 deletions(-)
diff --git a/hw/ppc/prep.c b/hw/ppc/prep.c
index 035b5b2..dfe4a5c 100644
--- a/hw/ppc/prep.c
+++ b/hw/ppc/prep.c
@@ -346,9 +346,6 @@ static void ppc_prep_reset(void *opaque)
PowerPCCPU *cpu = opaque;
cpu_reset(CPU(cpu));
-
-/* Reset address */
-cpu-env.nip = 0xfffc;
}
static const MemoryRegionPortio prep_portio_list[] = {
Is ppc_prep_reset needed at all now?
Paolo
Re: [Qemu-devel] [PATCH] QEMU: ARM: boot: Load kernel at an Image friendly address
On Wed, Apr 2, 2014 at 10:47 PM, Peter Maydell peter.mayd...@linaro.org wrote: On 2 April 2014 13:11, Peter Crosthwaite peter.crosthwa...@xilinx.com wrote: Like others, I have been carrying this change locally. Good to see it up! Why are you all booting raw Images anyway (just out of curiosity)? All my test cases boot either a zImage or a uImage, or occasionally a full SD card image, or I'd have noticed this earlier... Simplicity more than anything. It is much easier to debug against head.S (esp. with the -d in_asm option), when you can see the head.s asm as the very first thing the CPU executes. Otherwise you gotta filter out the zImage stuffs. There have also been occasions where I have broken QEMU locally as part of some random work-in-progress development such that the zImage head doesnt work and i'd rather just move my debug efforts to kernel proper. None of them are fantastic reasons from a user perspective but it's just a little easier on developing. Regards, Peter thanks -- PMM
[Qemu-devel] [PATCH for-2.0] iscsi: ignore flushes on scsi-generic devices
Non-block SCSI devices do not support flushing, but we may still send
them requests via bdrv_flush_all. Just ignore them.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
block/iscsi.c | 4
1 file changed, 4 insertions(+)
diff --git a/block/iscsi.c b/block/iscsi.c
index 0d15b4d..00316af 100644
--- a/block/iscsi.c
+++ b/block/iscsi.c
@@ -417,6 +417,10 @@ static int coroutine_fn iscsi_co_flush(BlockDriverState
*bs)
IscsiLun *iscsilun = bs-opaque;
struct IscsiTask iTask;
+if (bs-sg) {
+return 0;
+}
+
iscsi_co_init_iscsitask(iscsilun, iTask);
retry:
--
1.9.0
Re: [Qemu-devel] [PATCH] net: Update netdev peer on link change
On 04/02/2014 04:51 AM, Michael S. Tsirkin wrote:
On Thu, Nov 21, 2013 at 09:05:51PM -0500, Vlad Yasevich wrote:
When a link change occurs on a backend (like tap), we currently do
not propage such change to the nic. As a result, when someone turns
off a link on a tap device, for instance, then a guest doesn't see
that change and continues to try to send traffic or run DHCP even
though the lower-layer is disconnected. This is OK when the network
is set up as a HUB since the the guest may be connected to other HUB
ports too, but when it's set up as a netdev, it makes thinkgs worse.
The patch addresses this by setting the peers link down only when the
peer is not a HUBPORT device. With this patch, in the following config
-netdev tap,id=net0 -device e1000,mac=X,netdev=net0
when net0 link is turned off, the guest e1000 shows lower-layer link
down. This allows guests to boot much faster in such configurations.
With windows guest, it also allows the network to recover properly
since windows will not configure the link-local IPv4 address, and
when the link is turned on, the proper address address is configured.
Signed-off-by: Vlad Yasevich vyase...@redhat.com
---
net/net.c | 26 +-
1 file changed, 17 insertions(+), 9 deletions(-)
diff --git a/net/net.c b/net/net.c
index 0a88e68..8a084bf 100644
--- a/net/net.c
+++ b/net/net.c
@@ -1065,15 +1065,23 @@ void qmp_set_link(const char *name, bool up, Error
**errp)
nc-info-link_status_changed(nc);
}
-/* Notify peer. Don't update peer link status: this makes it possible to
- * disconnect from host network without notifying the guest.
- * FIXME: is disconnected link status change operation useful?
- *
- * Current behaviour is compatible with qemu vlans where there could be
- * multiple clients that can still communicate with each other in
- * disconnected mode. For now maintain this compatibility. */
Hmm this went in without much discussion.
But before this change went in, it was possible to control link state on NIC
and on link separately, without guest noticing.
Why did we decide to drop this functionality?
This was causing some interesting issues in the non-hub
configurations. In these configs, the loss of link on the backend
did not propagate to the guest. The guest would continue to send
traffic and it would just queue up and get dropped. Eventually the
guest could lose the DHCP lease and there wouldn't be any indication
at all as to why it happened. From the guest perspective, the link
is working, but it is completely disconnected.
This patch essentially equates the backend to a carrier on the guest
and the loss of a backend is loss of carrier.
This is only done for configurations where you have a 1-to-1
relationship between a hw nic and netdev. For the old vlan/hubport,
there is no change, since in those case, the guest nic can talk to
other hubports. In the case of netdev, it can't.
As an example, try booting a VM in which the netdev link is down.
First, it'll take a while to boot if it uses DHCP. When you
re-enable, the link, the VM will not issue DHCP requests and you'd
have to manually restart the nic in the VM.
With this patch, link detection works properly.
-vlad
-if (nc-peer nc-peer-info-link_status_changed) {
-nc-peer-info-link_status_changed(nc-peer);
+if (nc-peer) {
+/* Change peer link only if the peer is NIC and then notify peer.
+ * If the peer is a HUBPORT or a backend, we do not change the
+ * link status.
+ *
+ * This behavior is compatible with qemu vlans where there could be
+ * multiple clients that can still communicate with each other in
+ * disconnected mode. For now maintain this compatibility.
+ */
+if (nc-peer-info-type == NET_CLIENT_OPTIONS_KIND_NIC) {
+for (i = 0; i queues; i++) {
+ncs[i]-peer-link_down = !up;
+}
+}
+if (nc-peer-info-link_status_changed) {
+nc-peer-info-link_status_changed(nc-peer);
+}
}
}
--
1.8.4.2
Re: [Qemu-devel] [PATCH v2 1/4] gtk: Use gtk generic event signal instead of motion-notify-event
On 04/02/2014 08:32 AM, Takashi Iwai wrote:
The GDK motion-notify-event isn't generated when the pointer goes out
of the target window even if the pointer is grabbed, which essentially
means to lose the pointer tracking in gtk-ui.
Meanwhile the generic event signal is sent when the pointer is
grabbed, so we can use this and pick the motion notify events manually
there instead.
Reference: https://bugzilla.novell.com/show_bug.cgi?id=849587
Signed-off-by: Takashi Iwai ti...@suse.de
---
ui/gtk.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/ui/gtk.c b/ui/gtk.c
index f056e4034b3e..54b835428a28 100644
--- a/ui/gtk.c
+++ b/ui/gtk.c
@@ -765,6 +765,13 @@ static gboolean gd_key_event(GtkWidget *widget,
GdkEventKey *key, void *opaque)
return TRUE;
}
+static gboolean gd_event(GtkWidget *widget, GdkEvent *event, void *opaque)
+{
+if (event-type == GDK_MOTION_NOTIFY)
+return gd_motion_event(widget, event-motion, opaque);
+return FALSE;
+}
+
/** Window Menu Actions **/
static void gd_menu_pause(GtkMenuItem *item, void *opaque)
@@ -1267,8 +1274,8 @@ static void gd_connect_signals(GtkDisplayState *s)
g_signal_connect(s-drawing_area, expose-event,
G_CALLBACK(gd_expose_event), s);
#endif
-g_signal_connect(s-drawing_area, motion-notify-event,
- G_CALLBACK(gd_motion_event), s);
+g_signal_connect(s-drawing_area, event,
+ G_CALLBACK(gd_event), s);
g_signal_connect(s-drawing_area, button-press-event,
G_CALLBACK(gd_button_event), s);
g_signal_connect(s-drawing_area, button-release-event,
Tested-by: Cole Robinson crobi...@redhat.com
Reviewed-by: Cole Robinson crobi...@redhat.com
Thanks,
Cole
Re: [Qemu-devel] [PATCH v2 2/4] gtk: Fix the relative pointer tracking mode
On 04/02/2014 08:32 AM, Takashi Iwai wrote: The relative pointer tracking mode was still buggy even after the previous fix of the motion-notify-event since the events are filtered out when the pointer moves outside the drawing window due to the boundary check for the absolute mode. This patch fixes the issue by moving the unnecessary boundary check into the if block of absolute mode, and keep the coordinate in the relative mode even if it's outside the drawing area. But this makes the coordinate (last_x, last_y) possibly pointing to (-1,-1), introduce a new flag to indicate the last coordinate has been updated. Reference: https://bugzilla.novell.com/show_bug.cgi?id=849587 Signed-off-by: Takashi Iwai ti...@suse.de Tested-by: Cole Robinson crobi...@redhat.com Reviewed-by: Cole Robinson crobi...@redhat.com Thanks, Cole
Re: [Qemu-devel] [PATCH v2 3/4] gtk: Remember the last grabbed pointer position
On 04/02/2014 08:32 AM, Takashi Iwai wrote: It's pretty annoying that the pointer reappears at a random place once after grabbing and ungrabbing the input. Better to restore to the original position where the pointer was grabbed. Reference: https://bugzilla.novell.com/show_bug.cgi?id=849587 Signed-off-by: Takashi Iwai ti...@suse.de I agree, and IMO it's a good idea in general to keep behavior similar between the gtk and sdl frontends. Tested-by: Cole Robinson crobi...@redhat.com Reviewed-by: Cole Robinson crobi...@redhat.com Thanks, Cole
Re: [Qemu-devel] [PATCH v2 4/4] gtk: Add Grab On Click option
On 04/02/2014 08:32 AM, Takashi Iwai wrote:
I simply like it better, you don't? :)
In fact, relative mouse mode is a pain without this feature, you need to
manually initiate a grab with ctrl+alt+g before mouse movement will even work.
Compare to our sdl front end, or virt-viewer, vinagre, virt-manager, where
grab-on-click is the default (there isn't even an option to disable that
behavior).
I don't know what the original intention of the code was, but I think this
behavior should be the default. Anthony, Gerd, thoughts?
- Cole
Signed-off-by: Takashi Iwai ti...@suse.de
---
ui/gtk.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/ui/gtk.c b/ui/gtk.c
index 9b8df1224fdb..ffaf91ea453a 100644
--- a/ui/gtk.c
+++ b/ui/gtk.c
@@ -141,6 +141,7 @@ typedef struct GtkDisplayState
GtkWidget *zoom_fit_item;
GtkWidget *grab_item;
GtkWidget *grab_on_hover_item;
+GtkWidget *grab_on_click_item;
GtkWidget *vga_item;
int nb_vcs;
@@ -189,6 +190,11 @@ static bool gd_grab_on_hover(GtkDisplayState *s)
return
gtk_check_menu_item_get_active(GTK_CHECK_MENU_ITEM(s-grab_on_hover_item));
}
+static bool gd_grab_on_click(GtkDisplayState *s)
+{
+return
gtk_check_menu_item_get_active(GTK_CHECK_MENU_ITEM(s-grab_on_click_item));
+}
+
static bool gd_on_vga(GtkDisplayState *s)
{
return gtk_notebook_get_current_page(GTK_NOTEBOOK(s-notebook)) == 0;
@@ -685,6 +691,12 @@ static gboolean gd_button_event(GtkWidget *widget,
GdkEventButton *button,
GtkDisplayState *s = opaque;
InputButton btn;
+if (button-button == 1 button-type == GDK_BUTTON_PRESS
+ !gd_is_grab_active(s) gd_grab_on_click(s) button-button == 1) {
+gtk_check_menu_item_set_active(GTK_CHECK_MENU_ITEM(s-grab_item),
TRUE);
+ return TRUE;
+}
+
if (button-button == 1) {
btn = INPUT_BUTTON_LEFT;
} else if (button-button == 2) {
@@ -1416,6 +1428,9 @@ static GtkWidget *gd_create_menu_view(GtkDisplayState
*s, GtkAccelGroup *accel_g
s-grab_on_hover_item = gtk_check_menu_item_new_with_mnemonic(_(Grab On
_Hover));
gtk_menu_shell_append(GTK_MENU_SHELL(view_menu), s-grab_on_hover_item);
+s-grab_on_click_item = gtk_check_menu_item_new_with_mnemonic(_(Grab On
_Click));
+gtk_menu_shell_append(GTK_MENU_SHELL(view_menu), s-grab_on_click_item);
+
s-grab_item = gtk_check_menu_item_new_with_mnemonic(_(_Grab Input));
gtk_menu_item_set_accel_path(GTK_MENU_ITEM(s-grab_item),
QEMU/View/Grab Input);
Re: [Qemu-devel] Qemu 2.0 regression with xen: qemu crash on any domUs S.O. start
On 04/02/14 13:13, Fabio Fantoni wrote: Il 01/04/2014 18:24, Laszlo Ersek ha scritto: On 04/01/14 17:01, Fabio Fantoni wrote: Today I tried latest qemu 2.0 compiled from git (commit 63678e17cf399ff81b93417fe7bee8d6ef6b6b1b) on this dom0: Debian 7 (Wheezy) 64 bit with kernel from package linux-image-3.2.0-4-amd64 version 3.2.54-2 and all dependency packages for xen, spice and usb redirection. Seabios 1.7.3-3, spice 0.12.4-0nocelt2 and usbredir 0.6-2 compiled from debian unstable sources. The xen-unstable upstream commit is 4787f667bcee205c56a27da59b766a53e1e929eb, plus these patches not upstream: tools: various things just to build test tools: Improve make debball libxl: Add qxl vga interface support for upstream qemu libxl: add basic spice support for pv domUs Qemu crashes always on domU S.O. start, on both pv and hvm domUs. I may have misunderstood you (hence my gdb suggestion may not have been appropriate) -- does the guest kernel crash *in* qemu, or does the qemu host-side process crash? I understood your message to imply the latter. Same dom0 with qemu 1.6 from xen-unstable repository used for some tests yesterday and was full working. I also update seabios to 1.7.4-4 compiled from debian unstable sources but the problem persists. I looked on dom0 logs, qemu logs and xl dmesg and I found only a qemu segfault related on each domU in dom0 syslog, for example the latest: [ 844.273170] qemu-system-i38[3545]: segfault at 8 ip 7fa905dcc4c1 sp 7fff41220810 error 4 in qemu-system-i386[7fa905ad5000+598000] Can you reproduce this qemu process SIGSEGV while running qemu in (host-)gdb? Or else, can you save a coredump and look into it with gdb? The steps you describe with gdbserver target the guest OS as debuggee. I suggested that the host side qemu process be debugged (because that's what crashes). Laszlo If you need more informations, tests and/or logs tell me and I'll post them. Whoever looks into this would be greatly helped: - if you bisected the issue (between 1.6 and 2.0-rcX), I tried time ago qemu 1.7 and qemu 2.0 on start of development without problem on domUs start but I'll retry. - if you posted qemu's backtrace at the sigsegv. I tried to use gdb following this old post: https://lists.gnu.org/archive/html/qemu-devel/2011-12/msg02575.html but with same changes: /usr/lib/xen/bin# vi qemu-system-i386 #!/bin/sh exec gdbserver 0.0.0.0:1234 /usr/lib/xen/bin/qemu-system-i386.bak $@ gdb /usr/lib/xen/bin/qemu-system-i386.bak target remote localhost:1234 This command with gdb on qemu fails: xl -vvv create /etc/xen/wheezy.cfg ... libxl: error: libxl_dm.c:1378:device_model_spawn_outcome: domain 13 device model: spawn failed (rc=-3) libxl: error: libxl_create.c:1207:domcreate_devmodel_started: device model did not start: -3 libxl: debug: libxl_dm.c:1485:kill_device_model: Device Model signaled ... the dom0 syslog show segfault also in this case and the qemu log is different on first lines (probably for gdbserver): less /var/log/xen/qemu-dm-wheezy.log Process /usr/lib/xen/bin/qemu-system-i386.bak created; pid = 8238 Listening on port 1234 Remote debugging from host 127.0.0.1 xc: error: linux_gnttab_set_max_grants: ioctl SET_MAX_GRANTS failed (22 = Invalid argument): Internal error xen be: qdisk-51712: xc_gnttab_set_max_grants failed: Invalid argument gdb on xl create show: (gdb) target remote localhost:1234 Remote debugging using localhost:1234 Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/ld-linux-x86-64.so.2 0x77dddaf0 in ?? () from /lib64/ld-linux-x86-64.so.2 (gdb) (gdb) bt full #0 0x77dddaf0 in ?? () from /lib64/ld-linux-x86-64.so.2 No symbol table info available. #1 0x0013 in ?? () No symbol table info available. #2 0x7fffe871 in ?? () No symbol table info available. #3 0x7fffe897 in ?? () No symbol table info available. #4 0x7fffe8a2 in ?? () No symbol table info available. #5 0x7fffe8a5 in ?? () No symbol table info available. #6 0x7fffe8ae in ?? () No symbol table info available. #7 0x7fffe8ef in ?? () No symbol table info available. #8 0x7fffe8f4 in ?? () No symbol table info available. #9 0x7fffe913 in ?? () No symbol table info available. #10 0x7fffe91f in ?? () No symbol table info available. #11 0x7fffe92b in ?? () No symbol table info available. #12 0x7fffe931 in ?? () ---Type return to continue, or q return to quit--- the qemu include debug and is not stripped: file /usr/lib/xen/bin/qemu-system-i386.bak /usr/lib/xen/bin/qemu-system-i386.bak: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=0x5aa043b5524d74d166ead62527343080384d586b, not stripped and I also tried: aptitude install libc6-dbg
Re: [Qemu-devel] E820 (Re: [v4 PATCH 00/12] SMBIOS: build full tables in QEMU)
On 04/02/14 14:38, Gabriel L. Somlo wrote:
On Wed, Apr 02, 2014 at 12:35:26AM +0200, Laszlo Ersek wrote:
On 04/02/14 00:00, Kevin O'Connor wrote:
On Tue, Apr 01, 2014 at 11:44:12PM +0200, Laszlo Ersek wrote:
Right now, OVMF can accept individual fields, or table-at-a-time blobs,
via fw_cfg.
The internal interface (EFI_SMBIOS_PROTOCOL) expects one table at a time
(for which table-at-a-time blobs are a perfect match).
I wasn't aware of this. The SMBIOS spec calls for all the sub-tables
to be concatenanted into a single linear area of memory. Is there
something in EFI or OVMF that is dictating otherwise? Can you provide
a link so I can further understand? (I briefly checked through the
UEFI v2.3.1 spec and nothing popped out at me.)
The UEFI Specification is not relevant here, the UEFI Platform
Initialization (PI) Specification is.
You can download the PI spec at http://www.uefi.org/specs/access. The
relevant section is (I have version 1.2.1):
VOLUME 5: Platform Initialization Specification
Standards
6 SMBIOS Protocol
The function to call is EFI_SMBIOS_PROTOCOL.Add().
I think that concatenating table-at-a-time blobs in SeaBIOS is easier
than parsing splitting a complete dump into tables in OVMF.
I don't think it's very difficult either way. It would be nice,
though, if there was just one owner for the smbios. The current setup
where some data comes from QEMU and some from the firmware, along with
mechanisms for providing defaults and overrides is way too complex in
my opinion.
I certainly agree with the direction. I'm OK with the current
table-at-a-time blobs (which should leave only the SMBIOS entry point to
the firmware). I'm also OK with any new, comprehensive format that
allows me, with reasonable parsing, to identify the individual tables in
the big concat (and to throw away the passed down entry point).
I already wrote display_uuid() [src/fw/smbios.c] for SeaBIOS, so I guess
I could repeat the exercise if it's unavoidable... :)
Kevin, Laszlo,
What if I found a way to send an entry point structure via fw_cfg, as
a signal to ${BIOS} to simply assemble all the table-at-a-time blobs,
but without generating any of its own ?
I'm still working my way through whether *I* like the idea or not, but
figured I'd throw it out there as a potential compromise ? :)
If you send the entry point structure in a new fw_cfg file, then (I
believe) I could ignore it easily, and just go ahead with the
table-at-a-time blobs. OVMF has defaults (fallbacks) only for Type 0 and
Type 1 tables now, which you are (almost) guaranteed to send down
anyway, so the above approach might work for OVMF without even changing
the OVMF code. (Regarding individual fields, you'd simply not send such,
if I understand correctly.)
Thanks
Laszlo
Re: [Qemu-devel] [PATCH v2 4/4] gtk: Add Grab On Click option
At Wed, 02 Apr 2014 09:28:54 -0400,
Cole Robinson wrote:
On 04/02/2014 08:32 AM, Takashi Iwai wrote:
I simply like it better, you don't? :)
In fact, relative mouse mode is a pain without this feature, you need to
manually initiate a grab with ctrl+alt+g before mouse movement will even work.
Compare to our sdl front end, or virt-viewer, vinagre, virt-manager, where
grab-on-click is the default (there isn't even an option to disable that
behavior).
I don't know what the original intention of the code was, but I think this
behavior should be the default. Anthony, Gerd, thoughts?
I noticed later that the original gtk-ui behavior is better when
vmmouse driver is available, i.e. the absolute mode is working. With
grab-on-click, you have to ungrab at each time you want to leave from
VM window.
So I think we should leave the default behavior as is, since vmmouse
driver is likely available in most cases. But, still having this in
the menu makes our lives easier in case vmmouse isn't available or
doesn't work with QEMU.
Takashi
- Cole
Signed-off-by: Takashi Iwai ti...@suse.de
---
ui/gtk.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/ui/gtk.c b/ui/gtk.c
index 9b8df1224fdb..ffaf91ea453a 100644
--- a/ui/gtk.c
+++ b/ui/gtk.c
@@ -141,6 +141,7 @@ typedef struct GtkDisplayState
GtkWidget *zoom_fit_item;
GtkWidget *grab_item;
GtkWidget *grab_on_hover_item;
+GtkWidget *grab_on_click_item;
GtkWidget *vga_item;
int nb_vcs;
@@ -189,6 +190,11 @@ static bool gd_grab_on_hover(GtkDisplayState *s)
return
gtk_check_menu_item_get_active(GTK_CHECK_MENU_ITEM(s-grab_on_hover_item));
}
+static bool gd_grab_on_click(GtkDisplayState *s)
+{
+return
gtk_check_menu_item_get_active(GTK_CHECK_MENU_ITEM(s-grab_on_click_item));
+}
+
static bool gd_on_vga(GtkDisplayState *s)
{
return gtk_notebook_get_current_page(GTK_NOTEBOOK(s-notebook)) == 0;
@@ -685,6 +691,12 @@ static gboolean gd_button_event(GtkWidget *widget,
GdkEventButton *button,
GtkDisplayState *s = opaque;
InputButton btn;
+if (button-button == 1 button-type == GDK_BUTTON_PRESS
+ !gd_is_grab_active(s) gd_grab_on_click(s) button-button == 1) {
+gtk_check_menu_item_set_active(GTK_CHECK_MENU_ITEM(s-grab_item),
TRUE);
+ return TRUE;
+}
+
if (button-button == 1) {
btn = INPUT_BUTTON_LEFT;
} else if (button-button == 2) {
@@ -1416,6 +1428,9 @@ static GtkWidget *gd_create_menu_view(GtkDisplayState
*s, GtkAccelGroup *accel_g
s-grab_on_hover_item = gtk_check_menu_item_new_with_mnemonic(_(Grab
On _Hover));
gtk_menu_shell_append(GTK_MENU_SHELL(view_menu),
s-grab_on_hover_item);
+s-grab_on_click_item = gtk_check_menu_item_new_with_mnemonic(_(Grab
On _Click));
+gtk_menu_shell_append(GTK_MENU_SHELL(view_menu),
s-grab_on_click_item);
+
s-grab_item = gtk_check_menu_item_new_with_mnemonic(_(_Grab Input));
gtk_menu_item_set_accel_path(GTK_MENU_ITEM(s-grab_item),
QEMU/View/Grab Input);
[Qemu-devel] [PATCH for-2.0] iscsi: always query max WRITE SAME length
Max WRITE SAME length is also used when the UNMAP bit is zero, so it
should be queried even if LBPWS=0. Same for the optimal transfer
length.
However, the write_zeroes_alignment only matters for UNMAP=1 so we
still restrict it to LBPWS=1.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
block/iscsi.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/block/iscsi.c b/block/iscsi.c
index 00316af..bb88b4b 100644
--- a/block/iscsi.c
+++ b/block/iscsi.c
@@ -1335,18 +1335,20 @@ static int iscsi_refresh_limits(BlockDriverState *bs)
/* We don't actually refresh here, but just return data queried in
* iscsi_open(): iscsi targets don't change their limits. */
-if (iscsilun-lbp.lbpu || iscsilun-lbp.lbpws) {
+if (iscsilun-lbp.lbpu) {
if (iscsilun-bl.max_unmap 0x) {
bs-bl.max_discard = sector_lun2qemu(iscsilun-bl.max_unmap,
iscsilun);
}
bs-bl.discard_alignment = sector_lun2qemu(iscsilun-bl.opt_unmap_gran,
iscsilun);
+}
-if (iscsilun-bl.max_ws_len 0x) {
-bs-bl.max_write_zeroes = sector_lun2qemu(iscsilun-bl.max_ws_len,
- iscsilun);
-}
+if (iscsilun-bl.max_ws_len 0x) {
+bs-bl.max_write_zeroes = sector_lun2qemu(iscsilun-bl.max_ws_len,
+ iscsilun);
+}
+if (iscsilun-lbp.lbpws) {
bs-bl.write_zeroes_alignment =
sector_lun2qemu(iscsilun-bl.opt_unmap_gran,
iscsilun);
}
--
1.9.0
Re: [Qemu-devel] [PATCH for-2.0 2/2] prep: remove CPU reset entry point hack related to OpenHack'Ware
Am 02.04.2014 14:48, schrieb Paolo Bonzini:
Il 01/04/2014 23:19, Hervé Poussineau ha scritto:
Signed-off-by: Hervé Poussineau hpous...@reactos.org
---
hw/ppc/prep.c |3 ---
1 file changed, 3 deletions(-)
diff --git a/hw/ppc/prep.c b/hw/ppc/prep.c
index 035b5b2..dfe4a5c 100644
--- a/hw/ppc/prep.c
+++ b/hw/ppc/prep.c
@@ -346,9 +346,6 @@ static void ppc_prep_reset(void *opaque)
PowerPCCPU *cpu = opaque;
cpu_reset(CPU(cpu));
-
-/* Reset address */
-cpu-env.nip = 0xfffc;
}
static const MemoryRegionPortio prep_portio_list[] = {
Is ppc_prep_reset needed at all now?
I believe so, CPU reset is historically handled by the machines rather
than by CPUs themselves. (also Alpha is an oddball in not handling nor
implementing reset - some WIP on qom-cpu-alpha)
Regards,
Andreas
Re: [Qemu-devel] [PATCH v2 4/4] gtk: Add Grab On Click option
On 04/02/2014 09:42 AM, Takashi Iwai wrote: At Wed, 02 Apr 2014 09:28:54 -0400, Cole Robinson wrote: On 04/02/2014 08:32 AM, Takashi Iwai wrote: I simply like it better, you don't? :) In fact, relative mouse mode is a pain without this feature, you need to manually initiate a grab with ctrl+alt+g before mouse movement will even work. Compare to our sdl front end, or virt-viewer, vinagre, virt-manager, where grab-on-click is the default (there isn't even an option to disable that behavior). I don't know what the original intention of the code was, but I think this behavior should be the default. Anthony, Gerd, thoughts? I noticed later that the original gtk-ui behavior is better when vmmouse driver is available, i.e. the absolute mode is working. With grab-on-click, you have to ungrab at each time you want to leave from VM window. So I think we should leave the default behavior as is, since vmmouse driver is likely available in most cases. But, still having this in the menu makes our lives easier in case vmmouse isn't available or doesn't work with QEMU. Or we just do what sdl.c does (and virt-viewer, and vinagre, and virt-manager): absolute mode == grab on hover, ungrab when pointer leaves the window relative mode == grab on click, require manual ungrab - Cole
[Qemu-devel] Does QEMU support mips64 SMP support?
I am using octeon linux as guest operating system with mips64. I want to use SMP support. When i use '-smp 2' it display following error: *Number of SMP cpus requested (2), exceeds max cpus supported by machine `octeon' (1)* Does QEMU support SMP for mips64? Regards -- Maryyam Muhammad Din Al-Khawarizmi Institute of Computer Science UET Lahore
Re: [Qemu-devel] [PATCH/RFC] s390: Provide a configuration and control device
On 02.04.14 10:31, Christian Borntraeger wrote: On 01/04/14 16:47, Christian Borntraeger wrote: We want to configure several things in KVM that go beyond what ENABLE_CAP (we need payload) or ONE_REG (we need it for the VM and we need to do more complex actions) can provide. Instead of adding several s390 specific ioctls, lets provide a configuration and control device that encapsulates different commands into groups of the same area (MEMORY, CPU, ..) We also provide an initial nameless base group, with a simple first user to set the guest name. We need that name in the kernel for the emulation of STSI (which provides the guest name to the guest) but we need to implement the emulation in supervisor mode, as it also provides the underlying levels of hipervisors. Currently we have the following GROUPS and ATTRs pending, which configure some memory management related function or allow to set the guest facilities, cpuids etc: #define KVM_DEV_CONFIG_GROUP0 #define KVM_DEV_CONFIG_NAME 0 #define KVM_DEV_CONFIG_GROUP_MEM1 #define KVM_DEV_CONFIG_MEM_ENABLE_CMMA 0 #define KVM_DEV_CONFIG_MEM_CLR_CMMA 1 #define KVM_DEV_CONFIG_MEM_CLR_PAGES2 #define KVM_DEV_CONFIG_GROUP_CPU2 #define KVM_DEV_CONFIG_CPU_TYPE 0 #define KVM_DEV_CONFIG_CPU_FAC 1 #define KVM_DEV_CONFIG_CPU_FAC_MASK 2 #define KVM_DEV_CONFIG_CPU_IBC 3 #define KVM_DEV_CONFIG_CPU_IBC_RANGE4 In addition other groups like #define KVM_DEV_CONFIG_GROUP_CRYPTO are under consideration to configure crypto acceleration. Unless there is a major concern, I will add this to the next s390 PULL requests for KVM. Christian @Alex, regarding STSI, what about the following: The kernel will fill in every part of STSI as of now, but we will provide a CAP that qemu can enable which then tells the kernel to pass control to QEMU after it has filled in the data. QEMU can then do nothing (e.g. for stsi 111) or change the information (e.g. for 322) and return to kernel. That would a: cover the name aspect b: will work with future enhancements for levels 1 and 2 since the kernel will still pass that through to the HW or LPAR c: allows QEMU to override everything if necessary I like that one, yes. Does the STSI payload fit into our exit payload union? @Paolo, Alex, I have several changes pending that will require new ioctls. I planned to use the config device to avoid creating new ioctls. Some option: a: define new ioctls for these things (might end up with ~10 new ioctls) b: allow GET_ATTR/SET_ATTR on the vm fd. We would define those as architecture specific attributes of the VM. c: use a config device an anchor for GET_ATTR/SET_ATTR d: any better idea This question is really a bike shed color discussion (which interface for specific thing between qemu/kvm is considered best), but it will be ABI. Paolo, do you have any preference? I dont care about which solution we choose, but I obviously need a decision to rework pending patches. I think it semantically makes a lot of sense to treat the VM fd as an implements device class :). So allowing GET_ATTR/SET_ATTR on the VM fd makes most sense to me. As for all the individual bits you need to set, I'd like to make sure we talk about them on a case-by-case basis. As you've seen with STSI, other solutions might be a better fit. Alex
Re: [Qemu-devel] [PATCH 2/6] intc/openpic_kvm: fix MemListener delete regiion callback function
On 24.03.14 15:25, Andreas Färber wrote: Am 23.03.2014 10:28, schrieb Prasad Joshi: Signed-off-by: Prasad Joshi prasadjoshi.li...@gmail.com --- hw/intc/openpic_kvm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Thanks for spotting this, applied to ppc-next (w/ typo fix in subject): https://github.com/afaerber/qemu-cpu/commits/ppc-next This patch breaks the e500 platform target. Alex
[Qemu-devel] [RFC for-2.0] bswap: Fix build on FreeBSD 10.0
FreeBSD 10.0-RELEASE has bswap16() etc. macros defined in sys/endian.h, which leads to a conflict with our static inline definitions. Force using the system version of the macros. Signed-off-by: Andreas Färber andreas.faer...@web.de --- On 9.0-RELEASE I did not have this issue, so unsure if some version check is needed or some more generic configure check? include/qemu/bswap.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/qemu/bswap.h b/include/qemu/bswap.h index 0cb7c05..0f9c6cf 100644 --- a/include/qemu/bswap.h +++ b/include/qemu/bswap.h @@ -11,6 +11,8 @@ # include sys/endian.h # include sys/types.h # include machine/bswap.h +#elif defined(__FreeBSD__) +# include sys/endian.h #elif defined(CONFIG_BYTESWAP_H) # include byteswap.h -- 1.8.4.5
[Qemu-devel] [PATCH] Patch for shrinking qcow2 disk image
Signed-off-by: Jun Li junm...@gmail.com
This patch can make sure the data still existing after shrinking. And only
discard the unused (guest) clusters. If shrinking to the size which stored
data, It will return an error and will not do any change.
As this patch can support shrinking, so changed the func name of
qcow2_grow_l1_table to qcow2_truncate_l1_table.
---
block/qcow2-cluster.c | 20 ++--
block/qcow2-snapshot.c | 2 +-
block/qcow2.c | 8 +---
block/qcow2.h | 2 +-
4 files changed, 17 insertions(+), 15 deletions(-)
diff --git a/block/qcow2-cluster.c b/block/qcow2-cluster.c
index 9499df9..70e61ea 100644
--- a/block/qcow2-cluster.c
+++ b/block/qcow2-cluster.c
@@ -29,7 +29,7 @@
#include block/qcow2.h
#include trace.h
-int qcow2_grow_l1_table(BlockDriverState *bs, uint64_t min_size,
+int qcow2_truncate_l1_table(BlockDriverState *bs, uint64_t min_size,
bool exact_size)
{
BDRVQcowState *s = bs-opaque;
@@ -39,9 +39,6 @@ int qcow2_grow_l1_table(BlockDriverState *bs, uint64_t
min_size,
int64_t new_l1_table_offset, new_l1_size;
uint8_t data[12];
-if (min_size = s-l1_size)
-return 0;
-
if (exact_size) {
new_l1_size = min_size;
} else {
@@ -66,7 +63,18 @@ int qcow2_grow_l1_table(BlockDriverState *bs, uint64_t
min_size,
new_l1_size2 = sizeof(uint64_t) * new_l1_size;
new_l1_table = g_malloc0(align_offset(new_l1_size2, 512));
-memcpy(new_l1_table, s-l1_table, s-l1_size * sizeof(uint64_t));
+
+/* shrinking the image */
+if (min_size = s-l1_size) {
+if (s-l1_table[new_l1_size] != 0) {
+error_report(Could not shrink to this size,
+it will destory image data);
+return -ENOTSUP;
+}
+memcpy(new_l1_table, s-l1_table, new_l1_size2);
+}
+
+ memcpy(new_l1_table, s-l1_table, s-l1_size * sizeof(uint64_t));
/* write new table (align to cluster) */
BLKDBG_EVENT(bs-file, BLKDBG_L1_GROW_ALLOC_TABLE);
@@ -559,7 +567,7 @@ static int get_cluster_table(BlockDriverState *bs, uint64_t
offset,
l1_index = offset (s-l2_bits + s-cluster_bits);
if (l1_index = s-l1_size) {
-ret = qcow2_grow_l1_table(bs, l1_index + 1, false);
+ret = qcow2_truncate_l1_table(bs, l1_index + 1, false);
if (ret 0) {
return ret;
}
diff --git a/block/qcow2-snapshot.c b/block/qcow2-snapshot.c
index 2fc6320..ab16c52 100644
--- a/block/qcow2-snapshot.c
+++ b/block/qcow2-snapshot.c
@@ -491,7 +491,7 @@ int qcow2_snapshot_goto(BlockDriverState *bs, const char
*snapshot_id)
* L1 table of the snapshot. If the snapshot L1 table is smaller, the
* current one must be padded with zeros.
*/
-ret = qcow2_grow_l1_table(bs, sn-l1_size, true);
+ret = qcow2_truncate_l1_table(bs, sn-l1_size, true);
if (ret 0) {
goto fail;
}
diff --git a/block/qcow2.c b/block/qcow2.c
index b9dc960..4797879 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -1764,14 +1764,8 @@ static int qcow2_truncate(BlockDriverState *bs, int64_t
offset)
return -ENOTSUP;
}
-/* shrinking is currently not supported */
-if (offset bs-total_sectors * 512) {
-error_report(qcow2 doesn't support shrinking images yet);
-return -ENOTSUP;
-}
-
new_l1_size = size_to_l1(s, offset);
-ret = qcow2_grow_l1_table(bs, new_l1_size, true);
+ret = qcow2_truncate_l1_table(bs, new_l1_size, true);
if (ret 0) {
return ret;
}
diff --git a/block/qcow2.h b/block/qcow2.h
index 0b0eac8..298d84e 100644
--- a/block/qcow2.h
+++ b/block/qcow2.h
@@ -455,7 +455,7 @@ int qcow2_pre_write_overlap_check(BlockDriverState *bs, int
ign, int64_t offset,
int64_t size);
/* qcow2-cluster.c functions */
-int qcow2_grow_l1_table(BlockDriverState *bs, uint64_t min_size,
+int qcow2_truncate_l1_table(BlockDriverState *bs, uint64_t min_size,
bool exact_size);
int qcow2_write_l1_entry(BlockDriverState *bs, int l1_index);
void qcow2_l2_cache_reset(BlockDriverState *bs);
--
1.8.3.1
[Qemu-devel] [PATCH] qcow2: Patch for shrinking qcow2 disk image
Signed-off-by: Jun Li junm...@gmail.com
This patch can make sure the data still existing after shrinking. And only
discard the unused (guest) clusters. If shrinking to the size which stored
data, It will return an error and will not do any change.
As this patch can support shrinking, so changed the func name of
qcow2_grow_l1_table to qcow2_truncate_l1_table.
---
block/qcow2-cluster.c | 20 ++--
block/qcow2-snapshot.c | 2 +-
block/qcow2.c | 8 +---
block/qcow2.h | 2 +-
4 files changed, 17 insertions(+), 15 deletions(-)
diff --git a/block/qcow2-cluster.c b/block/qcow2-cluster.c
index 9499df9..70e61ea 100644
--- a/block/qcow2-cluster.c
+++ b/block/qcow2-cluster.c
@@ -29,7 +29,7 @@
#include block/qcow2.h
#include trace.h
-int qcow2_grow_l1_table(BlockDriverState *bs, uint64_t min_size,
+int qcow2_truncate_l1_table(BlockDriverState *bs, uint64_t min_size,
bool exact_size)
{
BDRVQcowState *s = bs-opaque;
@@ -39,9 +39,6 @@ int qcow2_grow_l1_table(BlockDriverState *bs, uint64_t
min_size,
int64_t new_l1_table_offset, new_l1_size;
uint8_t data[12];
-if (min_size = s-l1_size)
-return 0;
-
if (exact_size) {
new_l1_size = min_size;
} else {
@@ -66,7 +63,18 @@ int qcow2_grow_l1_table(BlockDriverState *bs, uint64_t
min_size,
new_l1_size2 = sizeof(uint64_t) * new_l1_size;
new_l1_table = g_malloc0(align_offset(new_l1_size2, 512));
-memcpy(new_l1_table, s-l1_table, s-l1_size * sizeof(uint64_t));
+
+/* shrinking the image */
+if (min_size = s-l1_size) {
+if (s-l1_table[new_l1_size] != 0) {
+error_report(Could not shrink to this size,
+it will destory image data);
+return -ENOTSUP;
+}
+memcpy(new_l1_table, s-l1_table, new_l1_size2);
+}
+
+ memcpy(new_l1_table, s-l1_table, s-l1_size * sizeof(uint64_t));
/* write new table (align to cluster) */
BLKDBG_EVENT(bs-file, BLKDBG_L1_GROW_ALLOC_TABLE);
@@ -559,7 +567,7 @@ static int get_cluster_table(BlockDriverState *bs, uint64_t
offset,
l1_index = offset (s-l2_bits + s-cluster_bits);
if (l1_index = s-l1_size) {
-ret = qcow2_grow_l1_table(bs, l1_index + 1, false);
+ret = qcow2_truncate_l1_table(bs, l1_index + 1, false);
if (ret 0) {
return ret;
}
diff --git a/block/qcow2-snapshot.c b/block/qcow2-snapshot.c
index 2fc6320..ab16c52 100644
--- a/block/qcow2-snapshot.c
+++ b/block/qcow2-snapshot.c
@@ -491,7 +491,7 @@ int qcow2_snapshot_goto(BlockDriverState *bs, const char
*snapshot_id)
* L1 table of the snapshot. If the snapshot L1 table is smaller, the
* current one must be padded with zeros.
*/
-ret = qcow2_grow_l1_table(bs, sn-l1_size, true);
+ret = qcow2_truncate_l1_table(bs, sn-l1_size, true);
if (ret 0) {
goto fail;
}
diff --git a/block/qcow2.c b/block/qcow2.c
index b9dc960..4797879 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -1764,14 +1764,8 @@ static int qcow2_truncate(BlockDriverState *bs, int64_t
offset)
return -ENOTSUP;
}
-/* shrinking is currently not supported */
-if (offset bs-total_sectors * 512) {
-error_report(qcow2 doesn't support shrinking images yet);
-return -ENOTSUP;
-}
-
new_l1_size = size_to_l1(s, offset);
-ret = qcow2_grow_l1_table(bs, new_l1_size, true);
+ret = qcow2_truncate_l1_table(bs, new_l1_size, true);
if (ret 0) {
return ret;
}
diff --git a/block/qcow2.h b/block/qcow2.h
index 0b0eac8..298d84e 100644
--- a/block/qcow2.h
+++ b/block/qcow2.h
@@ -455,7 +455,7 @@ int qcow2_pre_write_overlap_check(BlockDriverState *bs, int
ign, int64_t offset,
int64_t size);
/* qcow2-cluster.c functions */
-int qcow2_grow_l1_table(BlockDriverState *bs, uint64_t min_size,
+int qcow2_truncate_l1_table(BlockDriverState *bs, uint64_t min_size,
bool exact_size);
int qcow2_write_l1_entry(BlockDriverState *bs, int l1_index);
void qcow2_l2_cache_reset(BlockDriverState *bs);
--
1.8.3.1
[Qemu-devel] [PATCH] qcow2: Patch for shrinking qcow2 disk image
Signed-off-by: Jun Li junm...@gmail.com
This patch can make sure the data still existing after shrinking. And only
discard the unused (guest) clusters. If shrinking to the size which stored
data, It will return an error and will not do any change.
As this patch can support shrinking, so changed the func name of
qcow2_grow_l1_table to qcow2_truncate_l1_table.
---
block/qcow2-cluster.c | 20 ++--
block/qcow2-snapshot.c | 2 +-
block/qcow2.c | 8 +---
block/qcow2.h | 2 +-
4 files changed, 17 insertions(+), 15 deletions(-)
diff --git a/block/qcow2-cluster.c b/block/qcow2-cluster.c
index 9499df9..70e61ea 100644
--- a/block/qcow2-cluster.c
+++ b/block/qcow2-cluster.c
@@ -29,7 +29,7 @@
#include block/qcow2.h
#include trace.h
-int qcow2_grow_l1_table(BlockDriverState *bs, uint64_t min_size,
+int qcow2_truncate_l1_table(BlockDriverState *bs, uint64_t min_size,
bool exact_size)
{
BDRVQcowState *s = bs-opaque;
@@ -39,9 +39,6 @@ int qcow2_grow_l1_table(BlockDriverState *bs, uint64_t
min_size,
int64_t new_l1_table_offset, new_l1_size;
uint8_t data[12];
-if (min_size = s-l1_size)
-return 0;
-
if (exact_size) {
new_l1_size = min_size;
} else {
@@ -66,7 +63,18 @@ int qcow2_grow_l1_table(BlockDriverState *bs, uint64_t
min_size,
new_l1_size2 = sizeof(uint64_t) * new_l1_size;
new_l1_table = g_malloc0(align_offset(new_l1_size2, 512));
-memcpy(new_l1_table, s-l1_table, s-l1_size * sizeof(uint64_t));
+
+/* shrinking the image */
+if (min_size = s-l1_size) {
+if (s-l1_table[new_l1_size] != 0) {
+error_report(Could not shrink to this size,
+it will destory image data);
+return -ENOTSUP;
+}
+memcpy(new_l1_table, s-l1_table, new_l1_size2);
+}
+
+ memcpy(new_l1_table, s-l1_table, s-l1_size * sizeof(uint64_t));
/* write new table (align to cluster) */
BLKDBG_EVENT(bs-file, BLKDBG_L1_GROW_ALLOC_TABLE);
@@ -559,7 +567,7 @@ static int get_cluster_table(BlockDriverState *bs, uint64_t
offset,
l1_index = offset (s-l2_bits + s-cluster_bits);
if (l1_index = s-l1_size) {
-ret = qcow2_grow_l1_table(bs, l1_index + 1, false);
+ret = qcow2_truncate_l1_table(bs, l1_index + 1, false);
if (ret 0) {
return ret;
}
diff --git a/block/qcow2-snapshot.c b/block/qcow2-snapshot.c
index 2fc6320..ab16c52 100644
--- a/block/qcow2-snapshot.c
+++ b/block/qcow2-snapshot.c
@@ -491,7 +491,7 @@ int qcow2_snapshot_goto(BlockDriverState *bs, const char
*snapshot_id)
* L1 table of the snapshot. If the snapshot L1 table is smaller, the
* current one must be padded with zeros.
*/
-ret = qcow2_grow_l1_table(bs, sn-l1_size, true);
+ret = qcow2_truncate_l1_table(bs, sn-l1_size, true);
if (ret 0) {
goto fail;
}
diff --git a/block/qcow2.c b/block/qcow2.c
index b9dc960..4797879 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -1764,14 +1764,8 @@ static int qcow2_truncate(BlockDriverState *bs, int64_t
offset)
return -ENOTSUP;
}
-/* shrinking is currently not supported */
-if (offset bs-total_sectors * 512) {
-error_report(qcow2 doesn't support shrinking images yet);
-return -ENOTSUP;
-}
-
new_l1_size = size_to_l1(s, offset);
-ret = qcow2_grow_l1_table(bs, new_l1_size, true);
+ret = qcow2_truncate_l1_table(bs, new_l1_size, true);
if (ret 0) {
return ret;
}
diff --git a/block/qcow2.h b/block/qcow2.h
index 0b0eac8..298d84e 100644
--- a/block/qcow2.h
+++ b/block/qcow2.h
@@ -455,7 +455,7 @@ int qcow2_pre_write_overlap_check(BlockDriverState *bs, int
ign, int64_t offset,
int64_t size);
/* qcow2-cluster.c functions */
-int qcow2_grow_l1_table(BlockDriverState *bs, uint64_t min_size,
+int qcow2_truncate_l1_table(BlockDriverState *bs, uint64_t min_size,
bool exact_size);
int qcow2_write_l1_entry(BlockDriverState *bs, int l1_index);
void qcow2_l2_cache_reset(BlockDriverState *bs);
--
1.8.3.1
[Qemu-devel] [PATCH] Patch for shrinking qcow2 disk image
Signed-off-by: Jun Li junm...@gmail.com
This patch can make sure the data still existing after shrinking. And only
discard the unused (guest) clusters. If shrinking to the size which stored
data, It will return an error and will not do any change.
As this patch can support shrinking, so changed the func name of
qcow2_grow_l1_table to qcow2_truncate_l1_table.
---
block/qcow2-cluster.c | 20 ++--
block/qcow2-snapshot.c | 2 +-
block/qcow2.c | 8 +---
block/qcow2.h | 2 +-
4 files changed, 17 insertions(+), 15 deletions(-)
diff --git a/block/qcow2-cluster.c b/block/qcow2-cluster.c
index 9499df9..70e61ea 100644
--- a/block/qcow2-cluster.c
+++ b/block/qcow2-cluster.c
@@ -29,7 +29,7 @@
#include block/qcow2.h
#include trace.h
-int qcow2_grow_l1_table(BlockDriverState *bs, uint64_t min_size,
+int qcow2_truncate_l1_table(BlockDriverState *bs, uint64_t min_size,
bool exact_size)
{
BDRVQcowState *s = bs-opaque;
@@ -39,9 +39,6 @@ int qcow2_grow_l1_table(BlockDriverState *bs, uint64_t
min_size,
int64_t new_l1_table_offset, new_l1_size;
uint8_t data[12];
-if (min_size = s-l1_size)
-return 0;
-
if (exact_size) {
new_l1_size = min_size;
} else {
@@ -66,7 +63,18 @@ int qcow2_grow_l1_table(BlockDriverState *bs, uint64_t
min_size,
new_l1_size2 = sizeof(uint64_t) * new_l1_size;
new_l1_table = g_malloc0(align_offset(new_l1_size2, 512));
-memcpy(new_l1_table, s-l1_table, s-l1_size * sizeof(uint64_t));
+
+/* shrinking the image */
+if (min_size = s-l1_size) {
+if (s-l1_table[new_l1_size] != 0) {
+error_report(Could not shrink to this size,
+it will destory image data);
+return -ENOTSUP;
+}
+memcpy(new_l1_table, s-l1_table, new_l1_size2);
+}
+
+ memcpy(new_l1_table, s-l1_table, s-l1_size * sizeof(uint64_t));
/* write new table (align to cluster) */
BLKDBG_EVENT(bs-file, BLKDBG_L1_GROW_ALLOC_TABLE);
@@ -559,7 +567,7 @@ static int get_cluster_table(BlockDriverState *bs, uint64_t
offset,
l1_index = offset (s-l2_bits + s-cluster_bits);
if (l1_index = s-l1_size) {
-ret = qcow2_grow_l1_table(bs, l1_index + 1, false);
+ret = qcow2_truncate_l1_table(bs, l1_index + 1, false);
if (ret 0) {
return ret;
}
diff --git a/block/qcow2-snapshot.c b/block/qcow2-snapshot.c
index 2fc6320..ab16c52 100644
--- a/block/qcow2-snapshot.c
+++ b/block/qcow2-snapshot.c
@@ -491,7 +491,7 @@ int qcow2_snapshot_goto(BlockDriverState *bs, const char
*snapshot_id)
* L1 table of the snapshot. If the snapshot L1 table is smaller, the
* current one must be padded with zeros.
*/
-ret = qcow2_grow_l1_table(bs, sn-l1_size, true);
+ret = qcow2_truncate_l1_table(bs, sn-l1_size, true);
if (ret 0) {
goto fail;
}
diff --git a/block/qcow2.c b/block/qcow2.c
index b9dc960..4797879 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -1764,14 +1764,8 @@ static int qcow2_truncate(BlockDriverState *bs, int64_t
offset)
return -ENOTSUP;
}
-/* shrinking is currently not supported */
-if (offset bs-total_sectors * 512) {
-error_report(qcow2 doesn't support shrinking images yet);
-return -ENOTSUP;
-}
-
new_l1_size = size_to_l1(s, offset);
-ret = qcow2_grow_l1_table(bs, new_l1_size, true);
+ret = qcow2_truncate_l1_table(bs, new_l1_size, true);
if (ret 0) {
return ret;
}
diff --git a/block/qcow2.h b/block/qcow2.h
index 0b0eac8..298d84e 100644
--- a/block/qcow2.h
+++ b/block/qcow2.h
@@ -455,7 +455,7 @@ int qcow2_pre_write_overlap_check(BlockDriverState *bs, int
ign, int64_t offset,
int64_t size);
/* qcow2-cluster.c functions */
-int qcow2_grow_l1_table(BlockDriverState *bs, uint64_t min_size,
+int qcow2_truncate_l1_table(BlockDriverState *bs, uint64_t min_size,
bool exact_size);
int qcow2_write_l1_entry(BlockDriverState *bs, int l1_index);
void qcow2_l2_cache_reset(BlockDriverState *bs);
--
1.8.3.1
[Qemu-devel] [PATCH] Patch for shrinking qcow2 disk image
Signed-off-by: Jun Li junm...@gmail.com
This patch can make sure the data still existing after shrinking. And only
discard the unused (guest) clusters. If shrinking to the size which stored
data, It will return an error and will not do any change.
As this patch can support shrinking, so changed the func name of
qcow2_grow_l1_table to qcow2_truncate_l1_table.
---
block/qcow2-cluster.c | 20 ++--
block/qcow2-snapshot.c | 2 +-
block/qcow2.c | 8 +---
block/qcow2.h | 2 +-
4 files changed, 17 insertions(+), 15 deletions(-)
diff --git a/block/qcow2-cluster.c b/block/qcow2-cluster.c
index 9499df9..70e61ea 100644
--- a/block/qcow2-cluster.c
+++ b/block/qcow2-cluster.c
@@ -29,7 +29,7 @@
#include block/qcow2.h
#include trace.h
-int qcow2_grow_l1_table(BlockDriverState *bs, uint64_t min_size,
+int qcow2_truncate_l1_table(BlockDriverState *bs, uint64_t min_size,
bool exact_size)
{
BDRVQcowState *s = bs-opaque;
@@ -39,9 +39,6 @@ int qcow2_grow_l1_table(BlockDriverState *bs, uint64_t
min_size,
int64_t new_l1_table_offset, new_l1_size;
uint8_t data[12];
-if (min_size = s-l1_size)
-return 0;
-
if (exact_size) {
new_l1_size = min_size;
} else {
@@ -66,7 +63,18 @@ int qcow2_grow_l1_table(BlockDriverState *bs, uint64_t
min_size,
new_l1_size2 = sizeof(uint64_t) * new_l1_size;
new_l1_table = g_malloc0(align_offset(new_l1_size2, 512));
-memcpy(new_l1_table, s-l1_table, s-l1_size * sizeof(uint64_t));
+
+/* shrinking the image */
+if (min_size = s-l1_size) {
+if (s-l1_table[new_l1_size] != 0) {
+error_report(Could not shrink to this size,
+it will destory image data);
+return -ENOTSUP;
+}
+memcpy(new_l1_table, s-l1_table, new_l1_size2);
+}
+
+ memcpy(new_l1_table, s-l1_table, s-l1_size * sizeof(uint64_t));
/* write new table (align to cluster) */
BLKDBG_EVENT(bs-file, BLKDBG_L1_GROW_ALLOC_TABLE);
@@ -559,7 +567,7 @@ static int get_cluster_table(BlockDriverState *bs, uint64_t
offset,
l1_index = offset (s-l2_bits + s-cluster_bits);
if (l1_index = s-l1_size) {
-ret = qcow2_grow_l1_table(bs, l1_index + 1, false);
+ret = qcow2_truncate_l1_table(bs, l1_index + 1, false);
if (ret 0) {
return ret;
}
diff --git a/block/qcow2-snapshot.c b/block/qcow2-snapshot.c
index 2fc6320..ab16c52 100644
--- a/block/qcow2-snapshot.c
+++ b/block/qcow2-snapshot.c
@@ -491,7 +491,7 @@ int qcow2_snapshot_goto(BlockDriverState *bs, const char
*snapshot_id)
* L1 table of the snapshot. If the snapshot L1 table is smaller, the
* current one must be padded with zeros.
*/
-ret = qcow2_grow_l1_table(bs, sn-l1_size, true);
+ret = qcow2_truncate_l1_table(bs, sn-l1_size, true);
if (ret 0) {
goto fail;
}
diff --git a/block/qcow2.c b/block/qcow2.c
index b9dc960..4797879 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -1764,14 +1764,8 @@ static int qcow2_truncate(BlockDriverState *bs, int64_t
offset)
return -ENOTSUP;
}
-/* shrinking is currently not supported */
-if (offset bs-total_sectors * 512) {
-error_report(qcow2 doesn't support shrinking images yet);
-return -ENOTSUP;
-}
-
new_l1_size = size_to_l1(s, offset);
-ret = qcow2_grow_l1_table(bs, new_l1_size, true);
+ret = qcow2_truncate_l1_table(bs, new_l1_size, true);
if (ret 0) {
return ret;
}
diff --git a/block/qcow2.h b/block/qcow2.h
index 0b0eac8..298d84e 100644
--- a/block/qcow2.h
+++ b/block/qcow2.h
@@ -455,7 +455,7 @@ int qcow2_pre_write_overlap_check(BlockDriverState *bs, int
ign, int64_t offset,
int64_t size);
/* qcow2-cluster.c functions */
-int qcow2_grow_l1_table(BlockDriverState *bs, uint64_t min_size,
+int qcow2_truncate_l1_table(BlockDriverState *bs, uint64_t min_size,
bool exact_size);
int qcow2_write_l1_entry(BlockDriverState *bs, int l1_index);
void qcow2_l2_cache_reset(BlockDriverState *bs);
--
1.8.3.1
Re: [Qemu-devel] [PATCH] qemu-thread-posix: Fix build against older glibc version
On 11 March 2014 12:13, Dr. David Alan Gilbert dgilb...@redhat.com wrote: Except pthread_setname_np is not portable and was previously ifdef'd _GNU_SOURCE anyway, and the parameters on other OSs maybe different (freebsd has got a 3rd parameter for no apparent reason). No, glibc's arguments are identical to FreeBSD's. The difference is that it's pthread_set_name_np (with an extra underscore). FreeBSD: void pthread_set_name_np(pthread_t, const char *); glibc: int pthread_setname_np(pthread_t, const char *); NetBSD: int pthread_setname_np(pthread_t, const char *, void *); Darwin: pthread_setname_np(const char *);
Re: [Qemu-devel] drive_del vs. device_del: what should come first?
On 01/04/14 17:48, Markus Armbruster wrote: Heinz Graalfs graa...@linux.vnet.ibm.com writes: Hi Kevin, doing a virsh detach-device ... ends up in the following QEMU monitor commands: 1. device_del ... 2. drive_del ... qmp_device_del() performs the device unplug path. In case of a block device do_drive_del() tries to prevent further IO against the host device. However, bdrv_find() during drive_del() results in an error, because the device is already gone. Due to this error all the bdrv_xxx calls to quiesce the block driver as well as all other processing is skipped. Is the sequence that libvirt triggers OK? Shouldn't drive_del be executed first? No. OK, I see. The drive is deleted implicitly (release_drive()). Doing a device_del() requires another drive_add() AND device_add(). (Doing just a device_add() complains about the missing drive. A subsequent info qtree lets QEMU abort.) drive_del is nasty. Its purpose is to revoke access to an image even when the guest refuses to cooperate. To the guest, this looks like hardware failure. Deleting a device during active IO is nasty and it should look like a hardware failure. I would expect lots of errors. If you drive_del before device_del, even a perfectly well-behaved guest guest is exposed to a terminally broken device between drive_del and completion of unplug. The early drive_del() would mean that no further IO would be possible. Always try a device_del first, and only if that does not complete within reasonable time, and you absolutely must revoke access to the image, then whack it over the head with drive_del. What is this reasonable time? On 390 we experience problems (QEMU abort) when asynch block IO completes and the virtqueues are already gone. I suppose the bdrv_drain_all() in bdrv_close() is a little late. I don't see such problems with an early bdrv_drain_all() (drive_del) and an unplug (device_del) afterwards.
Re: [Qemu-devel] Qemu 2.0 regression with xen: qemu crash on any domUs S.O. start
Il 02/04/2014 15:31, Laszlo Ersek ha scritto: On 04/02/14 13:13, Fabio Fantoni wrote: Il 01/04/2014 18:24, Laszlo Ersek ha scritto: On 04/01/14 17:01, Fabio Fantoni wrote: Today I tried latest qemu 2.0 compiled from git (commit 63678e17cf399ff81b93417fe7bee8d6ef6b6b1b) on this dom0: Debian 7 (Wheezy) 64 bit with kernel from package linux-image-3.2.0-4-amd64 version 3.2.54-2 and all dependency packages for xen, spice and usb redirection. Seabios 1.7.3-3, spice 0.12.4-0nocelt2 and usbredir 0.6-2 compiled from debian unstable sources. The xen-unstable upstream commit is 4787f667bcee205c56a27da59b766a53e1e929eb, plus these patches not upstream: tools: various things just to build test tools: Improve make debball libxl: Add qxl vga interface support for upstream qemu libxl: add basic spice support for pv domUs Qemu crashes always on domU S.O. start, on both pv and hvm domUs. I may have misunderstood you (hence my gdb suggestion may not have been appropriate) -- does the guest kernel crash *in* qemu, or does the qemu host-side process crash? I understood your message to imply the latter. Same dom0 with qemu 1.6 from xen-unstable repository used for some tests yesterday and was full working. I also update seabios to 1.7.4-4 compiled from debian unstable sources but the problem persists. I looked on dom0 logs, qemu logs and xl dmesg and I found only a qemu segfault related on each domU in dom0 syslog, for example the latest: [ 844.273170] qemu-system-i38[3545]: segfault at 8 ip 7fa905dcc4c1 sp 7fff41220810 error 4 in qemu-system-i386[7fa905ad5000+598000] Can you reproduce this qemu process SIGSEGV while running qemu in (host-)gdb? Or else, can you save a coredump and look into it with gdb? The steps you describe with gdbserver target the guest OS as debuggee. I suggested that the host side qemu process be debugged (because that's what crashes). Laszlo The gdbserver target in my previous test was /usr/lib/xen/bin/qemu-system-i386.bak on dom0 which is called by xl create and crashes with segfault. I don't understand how doing that would target the guest OS as debuggee. Can you describe the steps to target the right process? Thanks for any reply. If you need more informations, tests and/or logs tell me and I'll post them. Whoever looks into this would be greatly helped: - if you bisected the issue (between 1.6 and 2.0-rcX), I tried time ago qemu 1.7 and qemu 2.0 on start of development without problem on domUs start but I'll retry. - if you posted qemu's backtrace at the sigsegv. I tried to use gdb following this old post: https://lists.gnu.org/archive/html/qemu-devel/2011-12/msg02575.html but with same changes: /usr/lib/xen/bin# vi qemu-system-i386 #!/bin/sh exec gdbserver 0.0.0.0:1234 /usr/lib/xen/bin/qemu-system-i386.bak $@ gdb /usr/lib/xen/bin/qemu-system-i386.bak target remote localhost:1234 This command with gdb on qemu fails: xl -vvv create /etc/xen/wheezy.cfg ... libxl: error: libxl_dm.c:1378:device_model_spawn_outcome: domain 13 device model: spawn failed (rc=-3) libxl: error: libxl_create.c:1207:domcreate_devmodel_started: device model did not start: -3 libxl: debug: libxl_dm.c:1485:kill_device_model: Device Model signaled ... the dom0 syslog show segfault also in this case and the qemu log is different on first lines (probably for gdbserver): less /var/log/xen/qemu-dm-wheezy.log Process /usr/lib/xen/bin/qemu-system-i386.bak created; pid = 8238 Listening on port 1234 Remote debugging from host 127.0.0.1 xc: error: linux_gnttab_set_max_grants: ioctl SET_MAX_GRANTS failed (22 = Invalid argument): Internal error xen be: qdisk-51712: xc_gnttab_set_max_grants failed: Invalid argument gdb on xl create show: (gdb) target remote localhost:1234 Remote debugging using localhost:1234 Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/ld-linux-x86-64.so.2 0x77dddaf0 in ?? () from /lib64/ld-linux-x86-64.so.2 (gdb) (gdb) bt full #0 0x77dddaf0 in ?? () from /lib64/ld-linux-x86-64.so.2 No symbol table info available. #1 0x0013 in ?? () No symbol table info available. #2 0x7fffe871 in ?? () No symbol table info available. #3 0x7fffe897 in ?? () No symbol table info available. #4 0x7fffe8a2 in ?? () No symbol table info available. #5 0x7fffe8a5 in ?? () No symbol table info available. #6 0x7fffe8ae in ?? () No symbol table info available. #7 0x7fffe8ef in ?? () No symbol table info available. #8 0x7fffe8f4 in ?? () No symbol table info available. #9 0x7fffe913 in ?? () No symbol table info available. #10 0x7fffe91f in ?? () No symbol table info available. #11 0x7fffe92b in ?? () No symbol table info available. #12 0x7fffe931 in ?? () ---Type return to continue, or q return to quit--- the qemu include debug and is not stripped: file /usr/lib/xen/bin/qemu-system-i386.bak
[Qemu-devel] [PATCH] Fix typo in eTSEC Ethernet controller
IRQ are lowered when ievent bit is cleared, so irq_pulse makes no sense
here...
Signed-off-by: Fabien Chouteau chout...@adacore.com
---
hw/net/fsl_etsec/rings.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/net/fsl_etsec/rings.c b/hw/net/fsl_etsec/rings.c
index e36cfbe..d4a494f 100644
--- a/hw/net/fsl_etsec/rings.c
+++ b/hw/net/fsl_etsec/rings.c
@@ -159,7 +159,7 @@ static void ievent_set(eTSEC*etsec,
if ((flags IEVENT_RXB etsec-regs[IMASK].value IMASK_RXBEN)
|| (flags IEVENT_RXF etsec-regs[IMASK].value IMASK_RXFEN)) {
-qemu_irq_pulse(etsec-rx_irq);
+qemu_irq_raise(etsec-rx_irq);
RING_DEBUG(%s Raise Rx IRQ\n, __func__);
}
}
--
1.7.9.5
Re: [Qemu-devel] [PATCH] Fix typo in eTSEC Ethernet controller
On 02.04.2014, at 16:49, Fabien Chouteau chout...@adacore.com wrote: IRQ are lowered when ievent bit is cleared, so irq_pulse makes no sense here... Signed-off-by: Fabien Chouteau chout...@adacore.com Thanks, applied to ppc-next. Given that the wiring with boards is still missing I don't think this is a critical 2.0 fix. Alex
Re: [Qemu-devel] [PATCH] net: Update netdev peer on link change
On 04/02/2014 06:46 AM, Yan Vugenfirer wrote:
On Apr 2, 2014, at 11:51 AM, Michael S. Tsirkin m...@redhat.com wrote:
On Thu, Nov 21, 2013 at 09:05:51PM -0500, Vlad Yasevich wrote:
When a link change occurs on a backend (like tap), we currently do
not propage such change to the nic. As a result, when someone turns
off a link on a tap device, for instance, then a guest doesn't see
that change and continues to try to send traffic or run DHCP even
though the lower-layer is disconnected. This is OK when the network
is set up as a HUB since the the guest may be connected to other HUB
ports too, but when it's set up as a netdev, it makes thinkgs worse.
The patch addresses this by setting the peers link down only when the
peer is not a HUBPORT device. With this patch, in the following config
-netdev tap,id=net0 -device e1000,mac=X,netdev=net0
when net0 link is turned off, the guest e1000 shows lower-layer link
down. This allows guests to boot much faster in such configurations.
With windows guest, it also allows the network to recover properly
since windows will not configure the link-local IPv4 address, and
when the link is turned on, the proper address address is configured.
Signed-off-by: Vlad Yasevich vyase...@redhat.com
---
net/net.c | 26 +-
1 file changed, 17 insertions(+), 9 deletions(-)
diff --git a/net/net.c b/net/net.c
index 0a88e68..8a084bf 100644
--- a/net/net.c
+++ b/net/net.c
@@ -1065,15 +1065,23 @@ void qmp_set_link(const char *name, bool up, Error
**errp)
nc-info-link_status_changed(nc);
}
-/* Notify peer. Don't update peer link status: this makes it possible
to
- * disconnect from host network without notifying the guest.
- * FIXME: is disconnected link status change operation useful?
- *
- * Current behaviour is compatible with qemu vlans where there could be
- * multiple clients that can still communicate with each other in
- * disconnected mode. For now maintain this compatibility. */
Hmm this went in without much discussion.
But before this change went in, it was possible to control link state on NIC
and on link separately, without guest noticing.
Why did we decide to drop this functionality?
Not sure there was a real need for the patch.
On other hand Windows guest will not receive IP address from DHCP server if
you start VM with tap link down and then set it to up without toggling link
state of the guest device as well.
Same for a linux guest. It a fault scenario. So we either handle
it by propagating the link event, or we forbid it. Doing neither
allows for a bad state in common configuration.
This patch chose to propagate the event under certain configuration.
-vlad
Yan.
-if (nc-peer nc-peer-info-link_status_changed) {
-nc-peer-info-link_status_changed(nc-peer);
+if (nc-peer) {
+/* Change peer link only if the peer is NIC and then notify peer.
+ * If the peer is a HUBPORT or a backend, we do not change the
+ * link status.
+ *
+ * This behavior is compatible with qemu vlans where there could be
+ * multiple clients that can still communicate with each other in
+ * disconnected mode. For now maintain this compatibility.
+ */
+if (nc-peer-info-type == NET_CLIENT_OPTIONS_KIND_NIC) {
+for (i = 0; i queues; i++) {
+ncs[i]-peer-link_down = !up;
+}
+}
+if (nc-peer-info-link_status_changed) {
+nc-peer-info-link_status_changed(nc-peer);
+}
}
}
--
1.8.4.2
Re: [Qemu-devel] [PATCH] Fix typo in eTSEC Ethernet controller
On 04/02/2014 04:52 PM, Alexander Graf wrote: On 02.04.2014, at 16:49, Fabien Chouteau chout...@adacore.com wrote: IRQ are lowered when ievent bit is cleared, so irq_pulse makes no sense here... Signed-off-by: Fabien Chouteau chout...@adacore.com Thanks, applied to ppc-next. Thanks Alex, Given that the wiring with boards is still missing I don't think this is a critical 2.0 fix. That's right. Regards,
[Qemu-devel] [RFC] tests: Add ivshmem qtest
Note that it launches two instances to as sharing memory is the purpose
of Nahanni/ivshmem.
Cc: Cam Macdonell c...@cs.ualberta.ca
Signed-off-by: Andreas Färber afaer...@suse.de
---
This test demonstrates a use case of running two QEMU instances in qtest.
However, similar to mst's proposed KVM acpi-test, it fails on systems
without KVM support, and we cannot use $(CONFIG_KVM) to make it conditional
since that is a per-target define rather than host-wide.
I wonder if libqtest should expose an API to start a QEMU instance and
inquire via QMP whether the executable supports KVM, returning true or false?
tests/Makefile | 3 +++
tests/ivshmem-test.c | 40
2 files changed, 43 insertions(+)
create mode 100644 tests/ivshmem-test.c
diff --git a/tests/Makefile b/tests/Makefile
index 6086f68..e4c3b12 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -137,6 +137,8 @@ check-qtest-i386-y += tests/pvpanic-test$(EXESUF)
gcov-files-i386-y += i386-softmmu/hw/misc/pvpanic.c
check-qtest-i386-y += tests/i82801b11-test$(EXESUF)
gcov-files-i386-y += hw/pci-bridge/i82801b11.c
+check-qtest-i386-y += tests/ivshmem-test$(EXESUF)
+gcov-files-i386-y += i386-softmmu/hw/misc/ivshmem.c
check-qtest-x86_64-y = $(check-qtest-i386-y)
gcov-files-i386-y += i386-softmmu/hw/timer/mc146818rtc.c
gcov-files-x86_64-y = $(subst
i386-softmmu/,x86_64-softmmu/,$(gcov-files-i386-y))
@@ -287,6 +289,7 @@ tests/qdev-monitor-test$(EXESUF): tests/qdev-monitor-test.o
$(libqos-pc-obj-y)
tests/nvme-test$(EXESUF): tests/nvme-test.o
tests/pvpanic-test$(EXESUF): tests/pvpanic-test.o
tests/i82801b11-test$(EXESUF): tests/i82801b11-test.o
+tests/ivshmem-test$(EXESUF): tests/ivshmem-test.o
tests/qemu-iotests/socket_scm_helper$(EXESUF):
tests/qemu-iotests/socket_scm_helper.o
# QTest rules
diff --git a/tests/ivshmem-test.c b/tests/ivshmem-test.c
new file mode 100644
index 000..e981ad3
--- /dev/null
+++ b/tests/ivshmem-test.c
@@ -0,0 +1,40 @@
+/*
+ * QTest testcase for Nahanni
+ *
+ * Copyright (c) 2014 SUSE LINUX Products GmbH
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+#include glib.h
+#include string.h
+#include libqtest.h
+#include qemu/osdep.h
+
+/* Tests only initialization so far. TODO: Replace with functional tests */
+static void nop(void)
+{
+}
+
+int main(int argc, char **argv)
+{
+QTestState *s1, *s2;
+char *cmd;
+int ret;
+
+g_test_init(argc, argv, NULL);
+qtest_add_func(/ivshmem/nop, nop);
+
+cmd = g_strdup_printf(-device ivshmem,shm=%s,size=1M, qtest);
+s1 = qtest_start(cmd);
+s2 = qtest_start(cmd);
+g_free(cmd);
+
+ret = g_test_run();
+
+qtest_quit(s1);
+qtest_quit(s2);
+
+return ret;
+}
--
1.8.4.5
Re: [Qemu-devel] [PATCH] net: Update netdev peer on link change
On Wed, Apr 02, 2014 at 10:57:08AM -0400, Vlad Yasevich wrote:
On 04/02/2014 06:46 AM, Yan Vugenfirer wrote:
On Apr 2, 2014, at 11:51 AM, Michael S. Tsirkin m...@redhat.com wrote:
On Thu, Nov 21, 2013 at 09:05:51PM -0500, Vlad Yasevich wrote:
When a link change occurs on a backend (like tap), we currently do
not propage such change to the nic. As a result, when someone turns
off a link on a tap device, for instance, then a guest doesn't see
that change and continues to try to send traffic or run DHCP even
though the lower-layer is disconnected. This is OK when the network
is set up as a HUB since the the guest may be connected to other HUB
ports too, but when it's set up as a netdev, it makes thinkgs worse.
The patch addresses this by setting the peers link down only when the
peer is not a HUBPORT device. With this patch, in the following config
-netdev tap,id=net0 -device e1000,mac=X,netdev=net0
when net0 link is turned off, the guest e1000 shows lower-layer link
down. This allows guests to boot much faster in such configurations.
With windows guest, it also allows the network to recover properly
since windows will not configure the link-local IPv4 address, and
when the link is turned on, the proper address address is configured.
Signed-off-by: Vlad Yasevich vyase...@redhat.com
---
net/net.c | 26 +-
1 file changed, 17 insertions(+), 9 deletions(-)
diff --git a/net/net.c b/net/net.c
index 0a88e68..8a084bf 100644
--- a/net/net.c
+++ b/net/net.c
@@ -1065,15 +1065,23 @@ void qmp_set_link(const char *name, bool up,
Error **errp)
nc-info-link_status_changed(nc);
}
-/* Notify peer. Don't update peer link status: this makes it
possible to
- * disconnect from host network without notifying the guest.
- * FIXME: is disconnected link status change operation useful?
- *
- * Current behaviour is compatible with qemu vlans where there could
be
- * multiple clients that can still communicate with each other in
- * disconnected mode. For now maintain this compatibility. */
Hmm this went in without much discussion.
But before this change went in, it was possible to control link state on
NIC
and on link separately, without guest noticing.
Why did we decide to drop this functionality?
Not sure there was a real need for the patch.
On other hand Windows guest will not receive IP address from DHCP server if
you start VM with tap link down and then set it to up without toggling link
state of the guest device as well.
Same for a linux guest. It a fault scenario. So we either handle
it by propagating the link event, or we forbid it. Doing neither
allows for a bad state in common configuration.
It's how networking works.
If I turn off my router at home I can't get dhcp either.
We had a way to disable networking at link or at
the router, then removed the ability to turn it
off at the router and I'm asking why.
This patch chose to propagate the event under certain configuration.
-vlad
So don't do this then.
If you want guest to know that link is down,
put it down on guest side.
It's that simple.
Yan.
-if (nc-peer nc-peer-info-link_status_changed) {
-nc-peer-info-link_status_changed(nc-peer);
+if (nc-peer) {
+/* Change peer link only if the peer is NIC and then notify peer.
+ * If the peer is a HUBPORT or a backend, we do not change the
+ * link status.
+ *
+ * This behavior is compatible with qemu vlans where there could
be
+ * multiple clients that can still communicate with each other in
+ * disconnected mode. For now maintain this compatibility.
+ */
+if (nc-peer-info-type == NET_CLIENT_OPTIONS_KIND_NIC) {
+for (i = 0; i queues; i++) {
+ncs[i]-peer-link_down = !up;
+}
+}
+if (nc-peer-info-link_status_changed) {
+nc-peer-info-link_status_changed(nc-peer);
+}
}
}
--
1.8.4.2
Re: [Qemu-devel] [PATCH v2 4/4] gtk: Add Grab On Click option
On Mi, 2014-04-02 at 09:28 -0400, Cole Robinson wrote: On 04/02/2014 08:32 AM, Takashi Iwai wrote: I simply like it better, you don't? :) In fact, relative mouse mode is a pain without this feature, you need to manually initiate a grab with ctrl+alt+g before mouse movement will even work. Compare to our sdl front end, or virt-viewer, vinagre, virt-manager, where grab-on-click is the default (there isn't even an option to disable that behavior). I don't know what the original intention of the code was, but I think this behavior should be the default. Anthony, Gerd, thoughts? There are *two* grabs. Pointer grab and keyboard grab. grab-on-hover is for the keyboard, i.e. if the qemu gtk window has the mouse focus it will grab the keyboard (if enabled), with the effect that special keys like ctrl-alt-del are received by qemu and forwarded to the guest instead of being intercepted by the hosts window manager. grab-on-click is for the mouse. I don't think we need an option for it, instead it should depend on whenever the pointer works in absolute or relative mode. In absolute mode you don't need a pointer grab in the first place. Relative mode is pretty much unusable without pointer grab. Activating the pointer grab without a mouse click is pretty annoying though. hope that clarifies, Gerd
Re: [Qemu-devel] [PATCH] QEMU: ARM: boot: Load kernel at an Image friendly address
[On 04/02/2014 08:47 AM, Peter Maydell wrote: On 2 April 2014 13:11, Peter Crosthwaite peter.crosthwa...@xilinx.com wrote: Like others, I have been carrying this change locally. Good to see it up! Why are you all booting raw Images anyway (just out of curiosity)? All my test cases boot either a zImage or a uImage, or occasionally a full SD card image, or I'd have noticed this earlier... I do it in part for uniformity with arm64 kernels. Christopher -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation.
Re: [Qemu-devel] E820 (Re: [v4 PATCH 00/12] SMBIOS: build full tables in QEMU)
Hi, From the conversation so far, it seems to me that: - type 0 is best left to the BIOS (user overrides via command line at their own risk) I think it was a bad idea to allow overriding type0 fields in the first place. It also isn't used in practice. I don't think it is a big problem to loose that capability. - therefore, the maximum granularity of QEMU-generated elements should be full tables of a given type, and not the full SMBIOS blob at once (other mechanisms to allow the BIOS to insert its own type 0 welcome, but so far this seems the most straightforward one). Just an idea: Is the table ordering important? I don't think so. If qemu supplies a blob with all tables except type0, can the firmware simply append a type0 record to the blob supplied by qemu? I don't agree - I think ultimately we want QEMU to generate the full SMBIOS table and pass it to the firmware via the romfile_loader mechanism. I still think the firmware (and *only* the firmware) should supply the type0 table. I also think seabios should fill in something more sensible in there, such as Vendor: SeaBIOS and Version: rel-1.7.4-0-g96917a8- The only thing that has been raised as an issue with this is one bit in the smbios table (UEFI support). IMO 'dmidecode -t0' should show what firmware you are running (seabios/ovmf/coreboot/whatever), not something made up by qemu. cheers, Gerd
Re: [Qemu-devel] [RFC] tests: Add ivshmem qtest
Am 02.04.2014 17:06, schrieb Michael S. Tsirkin: On Wed, Apr 02, 2014 at 04:57:48PM +0200, Andreas Färber wrote: Note that it launches two instances to as sharing memory is the purpose of Nahanni/ivshmem. Cc: Cam Macdonell c...@cs.ualberta.ca Signed-off-by: Andreas Färber afaer...@suse.de --- This test demonstrates a use case of running two QEMU instances in qtest. However, similar to mst's proposed KVM acpi-test, it fails on systems without KVM support, Hmm, acpi-test no longer depends on kvm. You only committed the TCG version due to someone raising the issue. But maybe I'm mistaken... Andreas and we cannot use $(CONFIG_KVM) to make it conditional since that is a per-target define rather than host-wide. I wonder if libqtest should expose an API to start a QEMU instance and inquire via QMP whether the executable supports KVM, returning true or false? -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
[Qemu-devel] [PATCH] gtk: Grab pointer on click when in relative mode
Without this, we need to initiate a manual grab with ctrl+alt+g just
to get a usable mouse.
Signed-off-by: Cole Robinson crobi...@redhat.com
---
Gerd, Takashi, I think this should do what we want.
ui/gtk.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/ui/gtk.c b/ui/gtk.c
index 9b8df12..ebaade2 100644
--- a/ui/gtk.c
+++ b/ui/gtk.c
@@ -685,6 +685,15 @@ static gboolean gd_button_event(GtkWidget *widget,
GdkEventButton *button,
GtkDisplayState *s = opaque;
InputButton btn;
+if (button-button == 1
+button-type == GDK_BUTTON_PRESS
+!gd_is_grab_active(s)
+!qemu_input_is_absolute()) {
+gtk_check_menu_item_set_active(GTK_CHECK_MENU_ITEM(s-grab_item),
+ TRUE);
+return TRUE;
+}
+
if (button-button == 1) {
btn = INPUT_BUTTON_LEFT;
} else if (button-button == 2) {
--
1.9.0
Re: [Qemu-devel] E820 (Re: [v4 PATCH 00/12] SMBIOS: build full tables in QEMU)
Hi, If qemu gives OVMF a complete, concatenated dump of all tables, I'll have to split that up into individual tables, and install those one by one. I feel like I should have a look at how coreboot handles this for an additional data point ... cheers, Gerd
Re: [Qemu-devel] [RFC] tests: Add ivshmem qtest
On Wed, Apr 02, 2014 at 04:57:48PM +0200, Andreas Färber wrote:
Note that it launches two instances to as sharing memory is the purpose
of Nahanni/ivshmem.
Cc: Cam Macdonell c...@cs.ualberta.ca
Signed-off-by: Andreas Färber afaer...@suse.de
---
This test demonstrates a use case of running two QEMU instances in qtest.
However, similar to mst's proposed KVM acpi-test, it fails on systems
without KVM support,
Hmm, acpi-test no longer depends on kvm.
and we cannot use $(CONFIG_KVM) to make it conditional
since that is a per-target define rather than host-wide.
I wonder if libqtest should expose an API to start a QEMU instance and
inquire via QMP whether the executable supports KVM, returning true or false?
tests/Makefile | 3 +++
tests/ivshmem-test.c | 40
2 files changed, 43 insertions(+)
create mode 100644 tests/ivshmem-test.c
diff --git a/tests/Makefile b/tests/Makefile
index 6086f68..e4c3b12 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -137,6 +137,8 @@ check-qtest-i386-y += tests/pvpanic-test$(EXESUF)
gcov-files-i386-y += i386-softmmu/hw/misc/pvpanic.c
check-qtest-i386-y += tests/i82801b11-test$(EXESUF)
gcov-files-i386-y += hw/pci-bridge/i82801b11.c
+check-qtest-i386-y += tests/ivshmem-test$(EXESUF)
+gcov-files-i386-y += i386-softmmu/hw/misc/ivshmem.c
check-qtest-x86_64-y = $(check-qtest-i386-y)
gcov-files-i386-y += i386-softmmu/hw/timer/mc146818rtc.c
gcov-files-x86_64-y = $(subst
i386-softmmu/,x86_64-softmmu/,$(gcov-files-i386-y))
@@ -287,6 +289,7 @@ tests/qdev-monitor-test$(EXESUF):
tests/qdev-monitor-test.o $(libqos-pc-obj-y)
tests/nvme-test$(EXESUF): tests/nvme-test.o
tests/pvpanic-test$(EXESUF): tests/pvpanic-test.o
tests/i82801b11-test$(EXESUF): tests/i82801b11-test.o
+tests/ivshmem-test$(EXESUF): tests/ivshmem-test.o
tests/qemu-iotests/socket_scm_helper$(EXESUF):
tests/qemu-iotests/socket_scm_helper.o
# QTest rules
diff --git a/tests/ivshmem-test.c b/tests/ivshmem-test.c
new file mode 100644
index 000..e981ad3
--- /dev/null
+++ b/tests/ivshmem-test.c
@@ -0,0 +1,40 @@
+/*
+ * QTest testcase for Nahanni
+ *
+ * Copyright (c) 2014 SUSE LINUX Products GmbH
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+#include glib.h
+#include string.h
+#include libqtest.h
+#include qemu/osdep.h
+
+/* Tests only initialization so far. TODO: Replace with functional tests */
+static void nop(void)
+{
+}
+
+int main(int argc, char **argv)
+{
+QTestState *s1, *s2;
+char *cmd;
+int ret;
+
+g_test_init(argc, argv, NULL);
+qtest_add_func(/ivshmem/nop, nop);
+
+cmd = g_strdup_printf(-device ivshmem,shm=%s,size=1M, qtest);
+s1 = qtest_start(cmd);
+s2 = qtest_start(cmd);
+g_free(cmd);
+
+ret = g_test_run();
+
+qtest_quit(s1);
+qtest_quit(s2);
+
+return ret;
+}
--
1.8.4.5
[Qemu-devel] [PATCH v8 2/4] qapi: [trivial] Show full exception message in test-qapi.py
Signed-off-by: Lluís Vilanova vilan...@ac.upc.edu --- tests/qapi-schema/test-qapi.py |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tests/qapi-schema/test-qapi.py b/tests/qapi-schema/test-qapi.py index b3d1e1d..ac6da13 100644 --- a/tests/qapi-schema/test-qapi.py +++ b/tests/qapi-schema/test-qapi.py @@ -18,8 +18,8 @@ try: exprs = parse_schema(sys.stdin) except SystemExit: raise -except: -print sys.stderr, Crashed:, sys.exc_info()[0] +except Exception, e: +print sys.stderr, Crashed:, str(e) exit(1) pprint(exprs)
[Qemu-devel] [PATCH v8 1/4] qapi: [trivial] Break long command lines
Signed-off-by: Lluís Vilanova vilan...@ac.upc.edu --- Makefile | 24 ++-- tests/Makefile | 20 2 files changed, 34 insertions(+), 10 deletions(-) diff --git a/Makefile b/Makefile index ec74039..84345ee 100644 --- a/Makefile +++ b/Makefile @@ -237,23 +237,35 @@ qapi-py = $(SRC_PATH)/scripts/qapi.py $(SRC_PATH)/scripts/ordereddict.py qga/qapi-generated/qga-qapi-types.c qga/qapi-generated/qga-qapi-types.h :\ $(SRC_PATH)/qga/qapi-schema.json $(SRC_PATH)/scripts/qapi-types.py $(qapi-py) - $(call quiet-command,$(PYTHON) $(SRC_PATH)/scripts/qapi-types.py $(gen-out-type) -o qga/qapi-generated -p qga- $, GEN $@) + $(call quiet-command,$(PYTHON) $(SRC_PATH)/scripts/qapi-types.py \ + $(gen-out-type) -o qga/qapi-generated -p qga- $, \ + GEN $@) qga/qapi-generated/qga-qapi-visit.c qga/qapi-generated/qga-qapi-visit.h :\ $(SRC_PATH)/qga/qapi-schema.json $(SRC_PATH)/scripts/qapi-visit.py $(qapi-py) - $(call quiet-command,$(PYTHON) $(SRC_PATH)/scripts/qapi-visit.py $(gen-out-type) -o qga/qapi-generated -p qga- $, GEN $@) + $(call quiet-command,$(PYTHON) $(SRC_PATH)/scripts/qapi-visit.py \ + $(gen-out-type) -o qga/qapi-generated -p qga- $, \ + GEN $@) qga/qapi-generated/qga-qmp-commands.h qga/qapi-generated/qga-qmp-marshal.c :\ $(SRC_PATH)/qga/qapi-schema.json $(SRC_PATH)/scripts/qapi-commands.py $(qapi-py) - $(call quiet-command,$(PYTHON) $(SRC_PATH)/scripts/qapi-commands.py $(gen-out-type) -o qga/qapi-generated -p qga- $, GEN $@) + $(call quiet-command,$(PYTHON) $(SRC_PATH)/scripts/qapi-commands.py \ + $(gen-out-type) -o qga/qapi-generated -p qga- $, \ + GEN $@) qapi-types.c qapi-types.h :\ $(SRC_PATH)/qapi-schema.json $(SRC_PATH)/scripts/qapi-types.py $(qapi-py) - $(call quiet-command,$(PYTHON) $(SRC_PATH)/scripts/qapi-types.py $(gen-out-type) -o . -b $, GEN $@) + $(call quiet-command,$(PYTHON) $(SRC_PATH)/scripts/qapi-types.py \ + $(gen-out-type) -o . -b $, \ + GEN $@) qapi-visit.c qapi-visit.h :\ $(SRC_PATH)/qapi-schema.json $(SRC_PATH)/scripts/qapi-visit.py $(qapi-py) - $(call quiet-command,$(PYTHON) $(SRC_PATH)/scripts/qapi-visit.py $(gen-out-type) -o . -b $, GEN $@) + $(call quiet-command,$(PYTHON) $(SRC_PATH)/scripts/qapi-visit.py \ + $(gen-out-type) -o . -b $, \ + GEN $@) qmp-commands.h qmp-marshal.c :\ $(SRC_PATH)/qapi-schema.json $(SRC_PATH)/scripts/qapi-commands.py $(qapi-py) - $(call quiet-command,$(PYTHON) $(SRC_PATH)/scripts/qapi-commands.py $(gen-out-type) -m -o . $, GEN $@) + $(call quiet-command,$(PYTHON) $(SRC_PATH)/scripts/qapi-commands.py \ + $(gen-out-type) -o . -m $, \ + GEN $@) QGALIB_GEN=$(addprefix qga/qapi-generated/, qga-qapi-types.h qga-qapi-visit.h qga-qmp-commands.h) $(qga-obj-y) qemu-ga.o: $(QGALIB_GEN) diff --git a/tests/Makefile b/tests/Makefile index 2d021fb..42ed652 100644 --- a/tests/Makefile +++ b/tests/Makefile @@ -216,13 +216,19 @@ tests/test-vmstate$(EXESUF): tests/test-vmstate.o \ tests/test-qapi-types.c tests/test-qapi-types.h :\ $(SRC_PATH)/tests/qapi-schema/qapi-schema-test.json $(SRC_PATH)/scripts/qapi-types.py - $(call quiet-command,$(PYTHON) $(SRC_PATH)/scripts/qapi-types.py $(gen-out-type) -o tests -p test- $, GEN $@) + $(call quiet-command,$(PYTHON) $(SRC_PATH)/scripts/qapi-types.py \ + $(gen-out-type) -o tests -p test- $, \ + GEN $@) tests/test-qapi-visit.c tests/test-qapi-visit.h :\ $(SRC_PATH)/tests/qapi-schema/qapi-schema-test.json $(SRC_PATH)/scripts/qapi-visit.py - $(call quiet-command,$(PYTHON) $(SRC_PATH)/scripts/qapi-visit.py $(gen-out-type) -o tests -p test- $, GEN $@) + $(call quiet-command,$(PYTHON) $(SRC_PATH)/scripts/qapi-visit.py \ + $(gen-out-type) -o tests -p test- $, \ + GEN $@) tests/test-qmp-commands.h tests/test-qmp-marshal.c :\ $(SRC_PATH)/tests/qapi-schema/qapi-schema-test.json $(SRC_PATH)/scripts/qapi-commands.py - $(call quiet-command,$(PYTHON) $(SRC_PATH)/scripts/qapi-commands.py $(gen-out-type) -o tests -p test- $, GEN $@) + $(call quiet-command,$(PYTHON) $(SRC_PATH)/scripts/qapi-commands.py \ + $(gen-out-type) -o tests -p test- $, \ + GEN $@) tests/test-string-output-visitor$(EXESUF): tests/test-string-output-visitor.o $(test-qapi-obj-y) libqemuutil.a libqemustub.a tests/test-string-input-visitor$(EXESUF): tests/test-string-input-visitor.o $(test-qapi-obj-y) libqemuutil.a libqemustub.a @@ -362,7 +368,13 @@ check-tests/test-qapi.py: tests/test-qapi.py .PHONY: $(patsubst %, check-%, $(check-qapi-schema-y)) $(patsubst %, check-%, $(check-qapi-schema-y)): check-%.json: $(SRC_PATH)/%.json - $(call
Re: [Qemu-devel] [RFC] tests: Add ivshmem qtest
On Wed, Apr 02, 2014 at 05:07:09PM +0200, Andreas Färber wrote: Am 02.04.2014 17:06, schrieb Michael S. Tsirkin: On Wed, Apr 02, 2014 at 04:57:48PM +0200, Andreas Färber wrote: Note that it launches two instances to as sharing memory is the purpose of Nahanni/ivshmem. Cc: Cam Macdonell c...@cs.ualberta.ca Signed-off-by: Andreas Färber afaer...@suse.de --- This test demonstrates a use case of running two QEMU instances in qtest. However, similar to mst's proposed KVM acpi-test, it fails on systems without KVM support, Hmm, acpi-test no longer depends on kvm. You only committed the TCG version due to someone raising the issue. But maybe I'm mistaken... Andreas Yes and I think this someone was you actually. Can something similar be done for this test? and we cannot use $(CONFIG_KVM) to make it conditional since that is a per-target define rather than host-wide. I wonder if libqtest should expose an API to start a QEMU instance and inquire via QMP whether the executable supports KVM, returning true or false? -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [RFC] tests: Add ivshmem qtest
Il 02/04/2014 17:15, Michael S. Tsirkin ha scritto: Yes and I think this someone was you actually. Can something similar be done for this test? I think ivshmem depends on ioeventfd, doesn't it? So short of implementing ioeventfd for TCG, no. Paolo
[Qemu-devel] [PATCH v8 4/4] qapi: Add a primitive to include other files from a QAPI schema file
Signed-off-by: Lluís Vilanova vilan...@ac.upc.edu --- docs/qapi-code-gen.txt | 11 + scripts/qapi.py| 66 +++- tests/Makefile |5 ++ tests/qapi-schema/include-after-err.err|1 tests/qapi-schema/include-after-err.exit |1 tests/qapi-schema/include-after-err.json |2 + tests/qapi-schema/include-after-err.out|0 tests/qapi-schema/include-cycle-b.json |1 tests/qapi-schema/include-cycle-c.json |1 tests/qapi-schema/include-cycle.err|3 + tests/qapi-schema/include-cycle.exit |1 tests/qapi-schema/include-cycle.json |1 tests/qapi-schema/include-cycle.out|0 tests/qapi-schema/include-format-err.err |1 tests/qapi-schema/include-format-err.exit |1 tests/qapi-schema/include-format-err.json |2 + tests/qapi-schema/include-format-err.out |0 tests/qapi-schema/include-nested-err.err |2 + tests/qapi-schema/include-nested-err.exit |1 tests/qapi-schema/include-nested-err.json |1 tests/qapi-schema/include-nested-err.out |0 tests/qapi-schema/include-no-file.err |1 tests/qapi-schema/include-no-file.exit |1 tests/qapi-schema/include-no-file.json |1 tests/qapi-schema/include-no-file.out |0 tests/qapi-schema/include-non-file.err |1 tests/qapi-schema/include-non-file.exit|1 tests/qapi-schema/include-non-file.json|1 tests/qapi-schema/include-non-file.out |0 tests/qapi-schema/include-relpath-sub.json |2 + tests/qapi-schema/include-relpath.err |0 tests/qapi-schema/include-relpath.exit |1 tests/qapi-schema/include-relpath.json |1 tests/qapi-schema/include-relpath.out |3 + tests/qapi-schema/include-self-cycle.err |1 tests/qapi-schema/include-self-cycle.exit |1 tests/qapi-schema/include-self-cycle.json |1 tests/qapi-schema/include-self-cycle.out |0 tests/qapi-schema/include-simple-sub.json |2 + tests/qapi-schema/include-simple.err |0 tests/qapi-schema/include-simple.exit |1 tests/qapi-schema/include-simple.json |1 tests/qapi-schema/include-simple.out |3 + tests/qapi-schema/include/relpath.json |1 44 files changed, 113 insertions(+), 12 deletions(-) create mode 100644 tests/qapi-schema/include-after-err.err create mode 100644 tests/qapi-schema/include-after-err.exit create mode 100644 tests/qapi-schema/include-after-err.json create mode 100644 tests/qapi-schema/include-after-err.out create mode 100644 tests/qapi-schema/include-cycle-b.json create mode 100644 tests/qapi-schema/include-cycle-c.json create mode 100644 tests/qapi-schema/include-cycle.err create mode 100644 tests/qapi-schema/include-cycle.exit create mode 100644 tests/qapi-schema/include-cycle.json create mode 100644 tests/qapi-schema/include-cycle.out create mode 100644 tests/qapi-schema/include-format-err.err create mode 100644 tests/qapi-schema/include-format-err.exit create mode 100644 tests/qapi-schema/include-format-err.json create mode 100644 tests/qapi-schema/include-format-err.out create mode 100644 tests/qapi-schema/include-nested-err.err create mode 100644 tests/qapi-schema/include-nested-err.exit create mode 100644 tests/qapi-schema/include-nested-err.json create mode 100644 tests/qapi-schema/include-nested-err.out create mode 100644 tests/qapi-schema/include-no-file.err create mode 100644 tests/qapi-schema/include-no-file.exit create mode 100644 tests/qapi-schema/include-no-file.json create mode 100644 tests/qapi-schema/include-no-file.out create mode 100644 tests/qapi-schema/include-non-file.err create mode 100644 tests/qapi-schema/include-non-file.exit create mode 100644 tests/qapi-schema/include-non-file.json create mode 100644 tests/qapi-schema/include-non-file.out create mode 100644 tests/qapi-schema/include-relpath-sub.json create mode 100644 tests/qapi-schema/include-relpath.err create mode 100644 tests/qapi-schema/include-relpath.exit create mode 100644 tests/qapi-schema/include-relpath.json create mode 100644 tests/qapi-schema/include-relpath.out create mode 100644 tests/qapi-schema/include-self-cycle.err create mode 100644 tests/qapi-schema/include-self-cycle.exit create mode 100644 tests/qapi-schema/include-self-cycle.json create mode 100644 tests/qapi-schema/include-self-cycle.out create mode 100644 tests/qapi-schema/include-simple-sub.json create mode 100644 tests/qapi-schema/include-simple.err create mode 100644 tests/qapi-schema/include-simple.exit create mode 100644 tests/qapi-schema/include-simple.json create mode 100644 tests/qapi-schema/include-simple.out create mode 100644 tests/qapi-schema/include/relpath.json diff --git a/docs/qapi-code-gen.txt b/docs/qapi-code-gen.txt index 63b03cf..051d109 100644 ---
Re: [Qemu-devel] [PATCH v2 1/4] gtk: Use gtk generic event signal instead of motion-notify-event
On Mi, 2014-04-02 at 14:32 +0200, Takashi Iwai wrote:
+static gboolean gd_event(GtkWidget *widget, GdkEvent *event, void
*opaque)
+{
+if (event-type == GDK_MOTION_NOTIFY)
+return gd_motion_event(widget, event-motion, opaque);
+return FALSE;
+}
Fails checkpatch:
WARNING: braces {} are necessary for all arms of this statement
#12: FILE: ui/gtk.c:771:
+if (event-type == GDK_MOTION_NOTIFY)
[...]
total: 0 errors, 1 warnings, 23 lines checked
cheers,
Gerd
[Qemu-devel] [PATCH v8 3/4] qapi: Use an explicit input file
Use an explicit input file on the command-line instead of reading from standard input Signed-off-by: Lluís Vilanova vilan...@ac.upc.edu --- Makefile | 12 ++-- docs/qapi-code-gen.txt |4 ++-- scripts/qapi-commands.py | 10 +++--- scripts/qapi-types.py |9 ++--- scripts/qapi-visit.py |9 ++--- scripts/qapi.py|5 +++-- tests/Makefile | 11 +++ tests/qapi-schema/duplicate-key.err|2 +- .../qapi-schema/flat-union-invalid-branch-key.err |2 +- .../flat-union-invalid-discriminator.err |2 +- tests/qapi-schema/flat-union-no-base.err |2 +- .../flat-union-string-discriminator.err|2 +- tests/qapi-schema/funny-char.err |2 +- tests/qapi-schema/missing-colon.err|2 +- tests/qapi-schema/missing-comma-list.err |2 +- tests/qapi-schema/missing-comma-object.err |2 +- tests/qapi-schema/non-objects.err |2 +- tests/qapi-schema/quoted-structural-chars.err |2 +- tests/qapi-schema/test-qapi.py |3 ++- tests/qapi-schema/trailing-comma-list.err |2 +- tests/qapi-schema/trailing-comma-object.err|2 +- tests/qapi-schema/unclosed-list.err|2 +- tests/qapi-schema/unclosed-object.err |2 +- tests/qapi-schema/unclosed-string.err |2 +- tests/qapi-schema/union-invalid-base.err |2 +- 25 files changed, 56 insertions(+), 41 deletions(-) diff --git a/Makefile b/Makefile index 84345ee..ac6a047 100644 --- a/Makefile +++ b/Makefile @@ -238,33 +238,33 @@ qapi-py = $(SRC_PATH)/scripts/qapi.py $(SRC_PATH)/scripts/ordereddict.py qga/qapi-generated/qga-qapi-types.c qga/qapi-generated/qga-qapi-types.h :\ $(SRC_PATH)/qga/qapi-schema.json $(SRC_PATH)/scripts/qapi-types.py $(qapi-py) $(call quiet-command,$(PYTHON) $(SRC_PATH)/scripts/qapi-types.py \ - $(gen-out-type) -o qga/qapi-generated -p qga- $, \ + $(gen-out-type) -o qga/qapi-generated -p qga- -i $, \ GEN $@) qga/qapi-generated/qga-qapi-visit.c qga/qapi-generated/qga-qapi-visit.h :\ $(SRC_PATH)/qga/qapi-schema.json $(SRC_PATH)/scripts/qapi-visit.py $(qapi-py) $(call quiet-command,$(PYTHON) $(SRC_PATH)/scripts/qapi-visit.py \ - $(gen-out-type) -o qga/qapi-generated -p qga- $, \ + $(gen-out-type) -o qga/qapi-generated -p qga- -i $, \ GEN $@) qga/qapi-generated/qga-qmp-commands.h qga/qapi-generated/qga-qmp-marshal.c :\ $(SRC_PATH)/qga/qapi-schema.json $(SRC_PATH)/scripts/qapi-commands.py $(qapi-py) $(call quiet-command,$(PYTHON) $(SRC_PATH)/scripts/qapi-commands.py \ - $(gen-out-type) -o qga/qapi-generated -p qga- $, \ + $(gen-out-type) -o qga/qapi-generated -p qga- -i $, \ GEN $@) qapi-types.c qapi-types.h :\ $(SRC_PATH)/qapi-schema.json $(SRC_PATH)/scripts/qapi-types.py $(qapi-py) $(call quiet-command,$(PYTHON) $(SRC_PATH)/scripts/qapi-types.py \ - $(gen-out-type) -o . -b $, \ + $(gen-out-type) -o . -b -i $, \ GEN $@) qapi-visit.c qapi-visit.h :\ $(SRC_PATH)/qapi-schema.json $(SRC_PATH)/scripts/qapi-visit.py $(qapi-py) $(call quiet-command,$(PYTHON) $(SRC_PATH)/scripts/qapi-visit.py \ - $(gen-out-type) -o . -b $, \ + $(gen-out-type) -o . -b -i $, \ GEN $@) qmp-commands.h qmp-marshal.c :\ $(SRC_PATH)/qapi-schema.json $(SRC_PATH)/scripts/qapi-commands.py $(qapi-py) $(call quiet-command,$(PYTHON) $(SRC_PATH)/scripts/qapi-commands.py \ - $(gen-out-type) -o . -m $, \ + $(gen-out-type) -o . -m -i $, \ GEN $@) QGALIB_GEN=$(addprefix qga/qapi-generated/, qga-qapi-types.h qga-qapi-visit.h qga-qmp-commands.h) diff --git a/docs/qapi-code-gen.txt b/docs/qapi-code-gen.txt index d78921f..63b03cf 100644 --- a/docs/qapi-code-gen.txt +++ b/docs/qapi-code-gen.txt @@ -221,7 +221,7 @@ created code. Example: mdroth@illuin:~/w/qemu2.git$ python scripts/qapi-types.py \ - --output-dir=qapi-generated --prefix=example- example-schema.json + --output-dir=qapi-generated --prefix=example- --input-file=example-schema.json mdroth@illuin:~/w/qemu2.git$ cat qapi-generated/example-qapi-types.c /* AUTOMATICALLY GENERATED, DO NOT MODIFY */ @@ -291,7 +291,7 @@ $(prefix)qapi-visit.h: declarations for previously mentioned visitor Example: mdroth@illuin:~/w/qemu2.git$ python scripts/qapi-visit.py \ ---output-dir=qapi-generated --prefix=example- example-schema.json +
Re: [Qemu-devel] [PATCH] gtk: Grab pointer on click when in relative mode
On Mi, 2014-04-02 at 11:07 -0400, Cole Robinson wrote:
+if (button-button == 1
+button-type == GDK_BUTTON_PRESS
+!gd_is_grab_active(s)
+!qemu_input_is_absolute()) {
+
gtk_check_menu_item_set_active(GTK_CHECK_MENU_ITEM(s-grab_item),
+ TRUE);
+return TRUE;
+}
Looks sane on a quick glance (as replacement for patch #4 of Takashi's
patch series). Didn't test yet.
cheers,
Gerd
Re: [Qemu-devel] [PATCH] gtk: Grab pointer on click when in relative mode
At Wed, 02 Apr 2014 17:19:51 +0200,
Gerd Hoffmann wrote:
On Mi, 2014-04-02 at 11:07 -0400, Cole Robinson wrote:
+if (button-button == 1
+button-type == GDK_BUTTON_PRESS
+!gd_is_grab_active(s)
+!qemu_input_is_absolute()) {
+
gtk_check_menu_item_set_active(GTK_CHECK_MENU_ITEM(s-grab_item),
+ TRUE);
+return TRUE;
+}
Looks sane on a quick glance (as replacement for patch #4 of Takashi's
patch series). Didn't test yet.
Unfortunately, this doesn't work perfectly as expected.
The input mode change happens after the first click action, thus
this always results in grabbing if you do left-click at first, even
after X starts up and vmmouse gets active.
I thought of checking it via notifier, but the notification happens
also after the first mouse click event. Hmm.
Takashi
[Qemu-devel] [PATCH v8 0/4] qapi: Allow modularization of QAPI schema files
Adds an include primitive to the syntax of QAPI schema files, allowing these to be modularized into multiple per-topic files in the future. Signed-off-by: Lluís Vilanova vilan...@ac.upc.edu --- Changes in v8: * Do not show absolute paths in error messages. Changes in v7: * Add tests for relative path inclusion. * Print inclusion path on all errors. * Add test to ensure errors after an include have the correct context. * Squash qapi.py changes and tests into a single patch. * Add test for 'include' directive format. * s/file path/file name/. * s/included/include/. * Move -i to the end of the command. * Fix GNUism when using sed. Changes in v6: * Split changes for long-line breaking in makefiles. * Put documentation on a separate section; reference recursiveness. * Check (and test) for non-string include arguments (tanks to Benoît Canet). Changes in v5: * Rebase on b3706fa. * Remove 'error_base' argument in 'parse_schema'; fix test checks instead. * Implement include directive using JSON syntax. Changes in v4: * Rebase on 3e890c7. * Minor cosmetic changes. * Fix recording of included files in case of a cycle error. * Add a more complex include cycle test. Changes in v3: * Fix documentation examples regarding how the input file is passed to the scripts. * Add documentation for the 'include' directive. * Detect inclusion loops. * Fix tests/qapi-schema/test-qapi.py and tests/Makefile to use an explicit input file when running tests. * Fix QAPI tests to cope with an explicit input file. * Add tests for the include directive. Changes in v2: * Change the scripts to use an explicit input file instead of standard input. * Fix tests/Makefile to use the new argument. * Get the input directory for the include directive from the input file dirname. Lluís Vilanova (4): qapi: [trivial] Break long command lines qapi: [trivial] Show full exception message in test-qapi.py qapi: Use an explicit input file qapi: Add a primitive to include other files from a QAPI schema file Makefile | 24 +-- docs/qapi-code-gen.txt | 15 scripts/qapi-commands.py | 10 ++- scripts/qapi-types.py |9 ++- scripts/qapi-visit.py |9 ++- scripts/qapi.py| 71 tests/Makefile | 28 ++-- tests/qapi-schema/duplicate-key.err|2 - .../qapi-schema/flat-union-invalid-branch-key.err |2 - .../flat-union-invalid-discriminator.err |2 - tests/qapi-schema/flat-union-no-base.err |2 - .../flat-union-string-discriminator.err|2 - tests/qapi-schema/funny-char.err |2 - tests/qapi-schema/include-after-err.err|1 tests/qapi-schema/include-after-err.exit |1 tests/qapi-schema/include-after-err.json |2 + tests/qapi-schema/include-after-err.out|0 tests/qapi-schema/include-cycle-b.json |1 tests/qapi-schema/include-cycle-c.json |1 tests/qapi-schema/include-cycle.err|3 + tests/qapi-schema/include-cycle.exit |1 tests/qapi-schema/include-cycle.json |1 tests/qapi-schema/include-cycle.out|0 tests/qapi-schema/include-format-err.err |1 tests/qapi-schema/include-format-err.exit |1 tests/qapi-schema/include-format-err.json |2 + tests/qapi-schema/include-format-err.out |0 tests/qapi-schema/include-nested-err.err |2 + tests/qapi-schema/include-nested-err.exit |1 tests/qapi-schema/include-nested-err.json |1 tests/qapi-schema/include-nested-err.out |0 tests/qapi-schema/include-no-file.err |1 tests/qapi-schema/include-no-file.exit |1 tests/qapi-schema/include-no-file.json |1 tests/qapi-schema/include-no-file.out |0 tests/qapi-schema/include-non-file.err |1 tests/qapi-schema/include-non-file.exit|1 tests/qapi-schema/include-non-file.json|1 tests/qapi-schema/include-non-file.out |0 tests/qapi-schema/include-relpath-sub.json |2 + tests/qapi-schema/include-relpath.err |0 tests/qapi-schema/include-relpath.exit |1 tests/qapi-schema/include-relpath.json |1 tests/qapi-schema/include-relpath.out |3 + tests/qapi-schema/include-self-cycle.err |1 tests/qapi-schema/include-self-cycle.exit |1 tests/qapi-schema/include-self-cycle.json |1 tests/qapi-schema/include-self-cycle.out |0
Re: [Qemu-devel] [PATCH] net: Update netdev peer on link change
On 04/02/2014 11:03 AM, Michael S. Tsirkin wrote:
On Wed, Apr 02, 2014 at 10:57:08AM -0400, Vlad Yasevich wrote:
On 04/02/2014 06:46 AM, Yan Vugenfirer wrote:
On Apr 2, 2014, at 11:51 AM, Michael S. Tsirkin m...@redhat.com wrote:
On Thu, Nov 21, 2013 at 09:05:51PM -0500, Vlad Yasevich wrote:
When a link change occurs on a backend (like tap), we currently do
not propage such change to the nic. As a result, when someone turns
off a link on a tap device, for instance, then a guest doesn't see
that change and continues to try to send traffic or run DHCP even
though the lower-layer is disconnected. This is OK when the network
is set up as a HUB since the the guest may be connected to other HUB
ports too, but when it's set up as a netdev, it makes thinkgs worse.
The patch addresses this by setting the peers link down only when the
peer is not a HUBPORT device. With this patch, in the following config
-netdev tap,id=net0 -device e1000,mac=X,netdev=net0
when net0 link is turned off, the guest e1000 shows lower-layer link
down. This allows guests to boot much faster in such configurations.
With windows guest, it also allows the network to recover properly
since windows will not configure the link-local IPv4 address, and
when the link is turned on, the proper address address is configured.
Signed-off-by: Vlad Yasevich vyase...@redhat.com
---
net/net.c | 26 +-
1 file changed, 17 insertions(+), 9 deletions(-)
diff --git a/net/net.c b/net/net.c
index 0a88e68..8a084bf 100644
--- a/net/net.c
+++ b/net/net.c
@@ -1065,15 +1065,23 @@ void qmp_set_link(const char *name, bool up,
Error **errp)
nc-info-link_status_changed(nc);
}
-/* Notify peer. Don't update peer link status: this makes it
possible to
- * disconnect from host network without notifying the guest.
- * FIXME: is disconnected link status change operation useful?
- *
- * Current behaviour is compatible with qemu vlans where there could
be
- * multiple clients that can still communicate with each other in
- * disconnected mode. For now maintain this compatibility. */
Hmm this went in without much discussion.
But before this change went in, it was possible to control link state on
NIC
and on link separately, without guest noticing.
Why did we decide to drop this functionality?
Not sure there was a real need for the patch.
On other hand Windows guest will not receive IP address from DHCP server if
you start VM with tap link down and then set it to up without toggling link
state of the guest device as well.
Same for a linux guest. It a fault scenario. So we either handle
it by propagating the link event, or we forbid it. Doing neither
allows for a bad state in common configuration.
It's how networking works.
If I turn off my router at home I can't get dhcp either.
And you device link will show that it has not carrier.
We had a way to disable networking at link or at
the router, then removed the ability to turn it
off at the router and I'm asking why.
We didn't remove the ability to turn it off at router/switch.
We just now propagate carrier loss correctly.
In fact, if you have a configuration where the VM is connected
to a hub in qemu, turning off the link on the 'tap' connected
to the same hub doesn't not change guest state.
This patch chose to propagate the event under certain configuration.
-vlad
So don't do this then.
If you want guest to know that link is down,
put it down on guest side.
It's that simple.
Sorry, but that's not always possible. The host administrator
may not always be vm administrator and without this patch vm
administrator has no idea what happened to his network.
-vlad
Yan.
-if (nc-peer nc-peer-info-link_status_changed) {
-nc-peer-info-link_status_changed(nc-peer);
+if (nc-peer) {
+/* Change peer link only if the peer is NIC and then notify peer.
+ * If the peer is a HUBPORT or a backend, we do not change the
+ * link status.
+ *
+ * This behavior is compatible with qemu vlans where there could
be
+ * multiple clients that can still communicate with each other in
+ * disconnected mode. For now maintain this compatibility.
+ */
+if (nc-peer-info-type == NET_CLIENT_OPTIONS_KIND_NIC) {
+for (i = 0; i queues; i++) {
+ncs[i]-peer-link_down = !up;
+}
+}
+if (nc-peer-info-link_status_changed) {
+nc-peer-info-link_status_changed(nc-peer);
+}
}
}
--
1.8.4.2
Re: [Qemu-devel] [PATCH v2 1/4] gtk: Use gtk generic event signal instead of motion-notify-event
At Wed, 02 Apr 2014 17:17:54 +0200,
Gerd Hoffmann wrote:
On Mi, 2014-04-02 at 14:32 +0200, Takashi Iwai wrote:
+static gboolean gd_event(GtkWidget *widget, GdkEvent *event, void
*opaque)
+{
+if (event-type == GDK_MOTION_NOTIFY)
+return gd_motion_event(widget, event-motion, opaque);
+return FALSE;
+}
Fails checkpatch:
WARNING: braces {} are necessary for all arms of this statement
#12: FILE: ui/gtk.c:771:
+if (event-type == GDK_MOTION_NOTIFY)
[...]
total: 0 errors, 1 warnings, 23 lines checked
OK, you guys have a different checkpatch bible than the kernel tree :)
I'll tidy up later, if the patch is really acceptable.
thanks,
Takashi
Re: [Qemu-devel] [PATCH v2 3/7] hw/net/stellaris_enet: Rewrite tx fifo handling code
* Peter Maydell (peter.mayd...@linaro.org) wrote: The datasheet is clear that the frame length written to the DATA register is actually stored in the TX FIFO; this means we don't need to keep both tx_frame_len and tx_fifo_len state separately. Signed-off-by: Peter Maydell peter.mayd...@linaro.org Reviewed-by: Dr. David Alan Gilbert dgilb...@redhat.com --- -register_savevm(dev, stellaris_enet, -1, 1, +register_savevm(dev, stellaris_enet, -1, 2, stellaris_enet_save, stellaris_enet_load, s); return 0; Note that as well as inc'ing that you would have to change the if (version_id != 1) in stellaris_enet_load (if you weren't about to scrap the load/save code anyway). Dave } -- 1.9.0 -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [Qemu-devel] [PATCH] net: Update netdev peer on link change
On Wed, Apr 02, 2014 at 11:25:32AM -0400, Vlad Yasevich wrote:
On 04/02/2014 11:03 AM, Michael S. Tsirkin wrote:
On Wed, Apr 02, 2014 at 10:57:08AM -0400, Vlad Yasevich wrote:
On 04/02/2014 06:46 AM, Yan Vugenfirer wrote:
On Apr 2, 2014, at 11:51 AM, Michael S. Tsirkin m...@redhat.com wrote:
On Thu, Nov 21, 2013 at 09:05:51PM -0500, Vlad Yasevich wrote:
When a link change occurs on a backend (like tap), we currently do
not propage such change to the nic. As a result, when someone turns
off a link on a tap device, for instance, then a guest doesn't see
that change and continues to try to send traffic or run DHCP even
though the lower-layer is disconnected. This is OK when the network
is set up as a HUB since the the guest may be connected to other HUB
ports too, but when it's set up as a netdev, it makes thinkgs worse.
The patch addresses this by setting the peers link down only when the
peer is not a HUBPORT device. With this patch, in the following config
-netdev tap,id=net0 -device e1000,mac=X,netdev=net0
when net0 link is turned off, the guest e1000 shows lower-layer link
down. This allows guests to boot much faster in such configurations.
With windows guest, it also allows the network to recover properly
since windows will not configure the link-local IPv4 address, and
when the link is turned on, the proper address address is configured.
Signed-off-by: Vlad Yasevich vyase...@redhat.com
---
net/net.c | 26 +-
1 file changed, 17 insertions(+), 9 deletions(-)
diff --git a/net/net.c b/net/net.c
index 0a88e68..8a084bf 100644
--- a/net/net.c
+++ b/net/net.c
@@ -1065,15 +1065,23 @@ void qmp_set_link(const char *name, bool up,
Error **errp)
nc-info-link_status_changed(nc);
}
-/* Notify peer. Don't update peer link status: this makes it
possible to
- * disconnect from host network without notifying the guest.
- * FIXME: is disconnected link status change operation useful?
- *
- * Current behaviour is compatible with qemu vlans where there
could be
- * multiple clients that can still communicate with each other in
- * disconnected mode. For now maintain this compatibility. */
Hmm this went in without much discussion.
But before this change went in, it was possible to control link state on
NIC
and on link separately, without guest noticing.
Why did we decide to drop this functionality?
Not sure there was a real need for the patch.
On other hand Windows guest will not receive IP address from DHCP server
if you start VM with tap link down and then set it to up without toggling
link state of the guest device as well.
Same for a linux guest. It a fault scenario. So we either handle
it by propagating the link event, or we forbid it. Doing neither
allows for a bad state in common configuration.
It's how networking works.
If I turn off my router at home I can't get dhcp either.
And you device link will show that it has not carrier.
It doesn't as long as the switch it's connected to is up.
We had a way to disable networking at link or at
the router, then removed the ability to turn it
off at the router and I'm asking why.
We didn't remove the ability to turn it off at router/switch.
We just now propagate carrier loss correctly.
In fact, if you have a configuration where the VM is connected
to a hub in qemu, turning off the link on the 'tap' connected
to the same hub doesn't not change guest state.
So why is it a good idea to make -netdev inconsistent
with this?
It doesn't seem to add anything useful.
It might fix things for users who turned off link
at the wrong place by mistake but I doubt it's
a common scenario.
Where end users getting it wrong and complaining?
This patch chose to propagate the event under certain configuration.
-vlad
So don't do this then.
If you want guest to know that link is down,
put it down on guest side.
It's that simple.
Sorry, but that's not always possible. The host administrator
may not always be vm administrator and without this patch vm
administrator has no idea what happened to his network.
-vlad
Yan.
-if (nc-peer nc-peer-info-link_status_changed) {
-nc-peer-info-link_status_changed(nc-peer);
+if (nc-peer) {
+/* Change peer link only if the peer is NIC and then notify
peer.
+ * If the peer is a HUBPORT or a backend, we do not change the
+ * link status.
+ *
+ * This behavior is compatible with qemu vlans where there
could be
+ * multiple clients that can still communicate with each other
in
+ * disconnected mode. For now maintain this compatibility.
+ */
+if (nc-peer-info-type == NET_CLIENT_OPTIONS_KIND_NIC) {
+for (i = 0; i queues; i++) {
+
[Qemu-devel] [PATCH for-2.0] target-i386: reorder fields in cpu/msr_hyperv_hypercall subsection
The subsection already exists in one well-known enterprise Linux
distribution, but for some strange reason the fields were swapped
when forward-porting the patch to upstream.
Limit headaches for said enterprise Linux distributor when the
time will come to rebase their version of QEMU.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
target-i386/machine.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target-i386/machine.c b/target-i386/machine.c
index 24bc373..168cab6 100644
--- a/target-i386/machine.c
+++ b/target-i386/machine.c
@@ -569,8 +569,8 @@ static const VMStateDescription
vmstate_msr_hypercall_hypercall = {
.minimum_version_id = 1,
.minimum_version_id_old = 1,
.fields = (VMStateField []) {
-VMSTATE_UINT64(env.msr_hv_hypercall, X86CPU),
VMSTATE_UINT64(env.msr_hv_guest_os_id, X86CPU),
+VMSTATE_UINT64(env.msr_hv_hypercall, X86CPU),
VMSTATE_END_OF_LIST()
}
};
--
1.9.0
Re: [Qemu-devel] [PATCH v2 4/7] hw/net/stellaris_enet: Correctly implement the TR and THR registers
* Peter Maydell (peter.mayd...@linaro.org) wrote:
Packet transmission for the stellaris ethernet controller can be triggered
in one of two ways:
* by setting a threshold value in the THR register; when the FIFO
fill level reaches the threshold, the h/w starts transmitting.
Software has to finish filling the FIFO before the transmit
process completes to avoid a (silent) underrun
* by software writing to the TR register to explicitly trigger
transmission
Since QEMU transmits packets instantaneously (from the guest's
point of view), implement transmit based on threshold with
our existing mechanism of transmit as soon as we have the whole
packet, with the additional wrinkle that we don't transmit if
the packet size is below the specified threshold, and implement
transmit by specific request properly.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
Reviewed-by: Dr. David Alan Gilbert dgilb...@redhat.com
---
hw/net/stellaris_enet.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/hw/net/stellaris_enet.c b/hw/net/stellaris_enet.c
index 47787fd..db6e43e 100644
--- a/hw/net/stellaris_enet.c
+++ b/hw/net/stellaris_enet.c
@@ -109,6 +109,15 @@ static inline bool
stellaris_txpacket_complete(stellaris_enet_state *s)
return s-tx_fifo_len = framelen;
}
+/* Return true if the TX FIFO threshold is enabled and the FIFO
+ * has filled enough to reach it.
+ */
+static inline bool stellaris_tx_thr_reached(stellaris_enet_state *s)
+{
+return (s-thr 0x3f
+(s-tx_fifo_len = 4 * (s-thr * 8 + 1)));
+}
+
/* Send the packet currently in the TX FIFO */
static void stellaris_enet_send(stellaris_enet_state *s)
{
@@ -309,7 +318,7 @@ static void stellaris_enet_write(void *opaque, hwaddr
offset,
s-tx_fifo[s-tx_fifo_len++] = value 24;
}
-if (stellaris_txpacket_complete(s)) {
+if (stellaris_tx_thr_reached(s) stellaris_txpacket_complete(s)) {
stellaris_enet_send(s);
}
break;
@@ -338,9 +347,13 @@ static void stellaris_enet_write(void *opaque, hwaddr
offset,
case 0x2c: /* MTXD */
s-mtxd = value 0xff;
break;
+case 0x38: /* TR */
+if (value 1) {
+stellaris_enet_send(s);
+}
+break;
case 0x30: /* MRXD */
case 0x34: /* NP */
-case 0x38: /* TR */
/* Ignored. */
case 0x3c: /* Undocuented: Timestamp? */
/* Ignored. */
--
1.9.0
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [Qemu-devel] [PATCH for-2.0] target-i386: reorder fields in cpu/msr_hyperv_hypercall subsection
On Wed, Apr 02, 2014 at 05:33:02PM +0200, Paolo Bonzini wrote:
The subsection already exists in one well-known enterprise Linux
distribution, but for some strange reason the fields were swapped
when forward-porting the patch to upstream.
Limit headaches for said enterprise Linux distributor when the
time will come to rebase their version of QEMU.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Reviewed-by: Michael S. Tsirkin m...@redhat.com
Peter could you pick this up for 2.0 please?
Otherwise we will need to maintain 2.0
compatibility code which is annoying ...
---
target-i386/machine.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target-i386/machine.c b/target-i386/machine.c
index 24bc373..168cab6 100644
--- a/target-i386/machine.c
+++ b/target-i386/machine.c
@@ -569,8 +569,8 @@ static const VMStateDescription
vmstate_msr_hypercall_hypercall = {
.minimum_version_id = 1,
.minimum_version_id_old = 1,
.fields = (VMStateField []) {
-VMSTATE_UINT64(env.msr_hv_hypercall, X86CPU),
VMSTATE_UINT64(env.msr_hv_guest_os_id, X86CPU),
+VMSTATE_UINT64(env.msr_hv_hypercall, X86CPU),
VMSTATE_END_OF_LIST()
}
};
--
1.9.0
Re: [Qemu-devel] [PATCH] qemu-thread-posix: Fix build against older glibc version
* Ed Maste (ema...@freebsd.org) wrote: On 11 March 2014 12:13, Dr. David Alan Gilbert dgilb...@redhat.com wrote: Except pthread_setname_np is not portable and was previously ifdef'd _GNU_SOURCE anyway, and the parameters on other OSs maybe different (freebsd has got a 3rd parameter for no apparent reason). No, glibc's arguments are identical to FreeBSD's. The difference is that it's pthread_set_name_np (with an extra underscore). FreeBSD: void pthread_set_name_np(pthread_t, const char *); glibc: int pthread_setname_np(pthread_t, const char *); NetBSD: int pthread_setname_np(pthread_t, const char *, void *); Darwin: pthread_setname_np(const char *); Ah, apologies - I got the wrong *BSD for the 3rd argument stuff. Anyway, feel free to add your favorite OS to the configure check/use. Dave -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [Qemu-devel] [PATCH] net: Update netdev peer on link change
On 04/02/2014 11:29 AM, Michael S. Tsirkin wrote:
On Wed, Apr 02, 2014 at 11:25:32AM -0400, Vlad Yasevich wrote:
On 04/02/2014 11:03 AM, Michael S. Tsirkin wrote:
On Wed, Apr 02, 2014 at 10:57:08AM -0400, Vlad Yasevich wrote:
On 04/02/2014 06:46 AM, Yan Vugenfirer wrote:
On Apr 2, 2014, at 11:51 AM, Michael S. Tsirkin m...@redhat.com wrote:
On Thu, Nov 21, 2013 at 09:05:51PM -0500, Vlad Yasevich wrote:
When a link change occurs on a backend (like tap), we currently do
not propage such change to the nic. As a result, when someone turns
off a link on a tap device, for instance, then a guest doesn't see
that change and continues to try to send traffic or run DHCP even
though the lower-layer is disconnected. This is OK when the network
is set up as a HUB since the the guest may be connected to other HUB
ports too, but when it's set up as a netdev, it makes thinkgs worse.
The patch addresses this by setting the peers link down only when the
peer is not a HUBPORT device. With this patch, in the following config
-netdev tap,id=net0 -device e1000,mac=X,netdev=net0
when net0 link is turned off, the guest e1000 shows lower-layer link
down. This allows guests to boot much faster in such configurations.
With windows guest, it also allows the network to recover properly
since windows will not configure the link-local IPv4 address, and
when the link is turned on, the proper address address is configured.
Signed-off-by: Vlad Yasevich vyase...@redhat.com
---
net/net.c | 26 +-
1 file changed, 17 insertions(+), 9 deletions(-)
diff --git a/net/net.c b/net/net.c
index 0a88e68..8a084bf 100644
--- a/net/net.c
+++ b/net/net.c
@@ -1065,15 +1065,23 @@ void qmp_set_link(const char *name, bool up,
Error **errp)
nc-info-link_status_changed(nc);
}
-/* Notify peer. Don't update peer link status: this makes it
possible to
- * disconnect from host network without notifying the guest.
- * FIXME: is disconnected link status change operation useful?
- *
- * Current behaviour is compatible with qemu vlans where there
could be
- * multiple clients that can still communicate with each other in
- * disconnected mode. For now maintain this compatibility. */
Hmm this went in without much discussion.
But before this change went in, it was possible to control link state on
NIC
and on link separately, without guest noticing.
Why did we decide to drop this functionality?
Not sure there was a real need for the patch.
On other hand Windows guest will not receive IP address from DHCP server
if you start VM with tap link down and then set it to up without toggling
link state of the guest device as well.
Same for a linux guest. It a fault scenario. So we either handle
it by propagating the link event, or we forbid it. Doing neither
allows for a bad state in common configuration.
It's how networking works.
If I turn off my router at home I can't get dhcp either.
And you device link will show that it has not carrier.
It doesn't as long as the switch it's connected to is up.
We had a way to disable networking at link or at
the router, then removed the ability to turn it
off at the router and I'm asking why.
We didn't remove the ability to turn it off at router/switch.
We just now propagate carrier loss correctly.
In fact, if you have a configuration where the VM is connected
to a hub in qemu, turning off the link on the 'tap' connected
to the same hub doesn't not change guest state.
So why is it a good idea to make -netdev inconsistent
with this?
Because -netdev has a 1-1 relationship with -device. You
could think of it a physical wire that connects the nic
to the network. If something happens to the wire, the
nic should notice it.
It doesn't seem to add anything useful.
It might fix things for users who turned off link
at the wrong place by mistake but I doubt it's
a common scenario.
I don't think link state management in general is a common scenario, but
we support it. I think this makes the behavior better and improves
the vm experience.
Where end users getting it wrong and complaining?
Yes, I can provide you with a list reported bugs if you wish.
-vlad
This patch chose to propagate the event under certain configuration.
-vlad
So don't do this then.
If you want guest to know that link is down,
put it down on guest side.
It's that simple.
Sorry, but that's not always possible. The host administrator
may not always be vm administrator and without this patch vm
administrator has no idea what happened to his network.
-vlad
Yan.
-if (nc-peer nc-peer-info-link_status_changed) {
-nc-peer-info-link_status_changed(nc-peer);
+if (nc-peer) {
+/* Change peer link only if the peer is NIC and then notify
peer.
+ * If the peer is a HUBPORT or a backend, we do not change the
+ * link status.
+
