Re: [Qemu-devel] [PATCH 1/6] memory: change dirty getting API to take a size
On 02/08/2012 11:42 AM, Jan Kiszka wrote:
On 2012-02-08 08:19, Evgeny Voevodin wrote:
On 01/29/2012 11:13 PM, Blue Swirl wrote:
Instead of each device knowing or guessing the guest page size,
just pass the desired size of dirtied memory area.
Signed-off-by: Blue Swirlblauwir...@gmail.com
---
arch_init.c |7 ---
exec-obsolete.h | 15 +--
hw/framebuffer.c |9 +
hw/g364fb.c |3 ++-
hw/sm501.c | 11 ---
hw/tcx.c | 19 +--
hw/vga.c | 17 +
memory.c |5 +++--
memory.h |9 +
9 files changed, 46 insertions(+), 49 deletions(-)
diff --git a/arch_init.c b/arch_init.c
index 2366511..699bdd1 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -141,7 +141,8 @@ static int ram_save_block(QEMUFile *f)
do {
mr = block-mr;
-if (memory_region_get_dirty(mr, offset,
DIRTY_MEMORY_MIGRATION)) {
+if (memory_region_get_dirty(mr, offset, TARGET_PAGE_SIZE,
+DIRTY_MEMORY_MIGRATION)) {
uint8_t *p;
int cont = (block == last_block) ?
RAM_SAVE_FLAG_CONTINUE : 0;
@@ -198,7 +199,7 @@ static ram_addr_t ram_save_remaining(void)
QLIST_FOREACH(block,ram_list.blocks, next) {
ram_addr_t addr;
for (addr = 0; addr block-length; addr +=
TARGET_PAGE_SIZE) {
-if (memory_region_get_dirty(block-mr, addr,
+if (memory_region_get_dirty(block-mr, addr,
TARGET_PAGE_SIZE,
DIRTY_MEMORY_MIGRATION)) {
count++;
}
@@ -283,7 +284,7 @@ int ram_save_live(Monitor *mon, QEMUFile *f, int
stage, void *opaque)
/* Make sure all dirty bits are set */
QLIST_FOREACH(block,ram_list.blocks, next) {
for (addr = 0; addr block-length; addr +=
TARGET_PAGE_SIZE) {
-if (!memory_region_get_dirty(block-mr, addr,
+if (!memory_region_get_dirty(block-mr, addr,
TARGET_PAGE_SIZE,
DIRTY_MEMORY_MIGRATION)) {
memory_region_set_dirty(block-mr, addr,
TARGET_PAGE_SIZE);
}
diff --git a/exec-obsolete.h b/exec-obsolete.h
index d2749d3..94c23d0 100644
--- a/exec-obsolete.h
+++ b/exec-obsolete.h
@@ -59,10 +59,21 @@ static inline int
cpu_physical_memory_get_dirty_flags(ram_addr_t addr)
return ram_list.phys_dirty[addr TARGET_PAGE_BITS];
}
-static inline int cpu_physical_memory_get_dirty(ram_addr_t addr,
+static inline int cpu_physical_memory_get_dirty(ram_addr_t start,
+ram_addr_t length,
int dirty_flags)
{
-return ram_list.phys_dirty[addr TARGET_PAGE_BITS] dirty_flags;
+int ret = 0;
+uint8_t *p;
+ram_addr_t addr, end;
+
+end = TARGET_PAGE_ALIGN(start + length);
+start= TARGET_PAGE_MASK;
+p = ram_list.phys_dirty + (start TARGET_PAGE_BITS);
+for (addr = start; addr end; addr += TARGET_PAGE_SIZE) {
+ret |= *p++ dirty_flags;
+}
+return ret;
}
static inline void cpu_physical_memory_set_dirty(ram_addr_t addr)
diff --git a/hw/framebuffer.c b/hw/framebuffer.c
index 6bf48dc..ea122fb 100644
--- a/hw/framebuffer.c
+++ b/hw/framebuffer.c
@@ -87,15 +87,8 @@ void framebuffer_update_display(
dest += i * dest_row_pitch;
for (; i rows; i++) {
-target_phys_addr_t dirty_offset;
-dirty = 0;
-dirty_offset = 0;
-while (addr + dirty_offset TARGET_PAGE_ALIGN(addr +
src_width)) {
-dirty |= memory_region_get_dirty(mem, addr + dirty_offset,
+dirty = memory_region_get_dirty(mem, addr, addr + src_width,
DIRTY_MEMORY_VGA);
-dirty_offset += TARGET_PAGE_SIZE;
-}
-
if (dirty || invalidate) {
fn(opaque, dest, src, cols, dest_col_pitch);
if (first == -1)
diff --git a/hw/g364fb.c b/hw/g364fb.c
index 82b31f7..fa25033 100644
--- a/hw/g364fb.c
+++ b/hw/g364fb.c
@@ -62,7 +62,8 @@ typedef struct G364State {
static inline int check_dirty(G364State *s, ram_addr_t page)
{
-return memory_region_get_dirty(s-mem_vram, page,
DIRTY_MEMORY_VGA);
+return memory_region_get_dirty(s-mem_vram, page, G364_PAGE_SIZE,
+ DIRTY_MEMORY_VGA);
}
static inline void reset_dirty(G364State *s,
diff --git a/hw/sm501.c b/hw/sm501.c
index 09c5894..94c0abf 100644
--- a/hw/sm501.c
+++ b/hw/sm501.c
@@ -1323,15 +1323,12 @@ static void sm501_draw_crt(SM501State * s)
for (y = 0; y height; y++) {
int update_hwc = draw_hwc_line ? within_hwc_y_range(s, y, 1) : 0;
int update = full_update || update_hwc;
-ram_addr_t page0 = offset TARGET_PAGE_MASK;
-ram_addr_t page1 = (offset + width *
[Qemu-devel] [Bug 928676] [NEW] QEMU does not support Westmere (Intel Xeon) CPU model
Public bug reported: Setting the CPU model to Westmere (Intel Xeon server CPU) is not possible. libvirt uses 'core2duo' as fallback: https://bugzilla.redhat.com/show_bug.cgi?id=708927 $ qemu -cpu ? x86 [n270] x86 [athlon] x86 [pentium3] x86 [pentium2] x86[pentium] x86[486] x86[coreduo] x86 [kvm32] x86 [qemu32] x86 [kvm64] x86 [core2duo] x86 [phenom] x86 [qemu64] $ qemu --version QEMU emulator version 1.0 (Debian 1.0+dfsg-3), Copyright (c) 2003-2008 Fabrice Bellard ** Affects: qemu 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/928676 Title: QEMU does not support Westmere (Intel Xeon) CPU model Status in QEMU: New Bug description: Setting the CPU model to Westmere (Intel Xeon server CPU) is not possible. libvirt uses 'core2duo' as fallback: https://bugzilla.redhat.com/show_bug.cgi?id=708927 $ qemu -cpu ? x86 [n270] x86 [athlon] x86 [pentium3] x86 [pentium2] x86[pentium] x86[486] x86[coreduo] x86 [kvm32] x86 [qemu32] x86 [kvm64] x86 [core2duo] x86 [phenom] x86 [qemu64] $ qemu --version QEMU emulator version 1.0 (Debian 1.0+dfsg-3), Copyright (c) 2003-2008 Fabrice Bellard To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/928676/+subscriptions
Re: [Qemu-devel] [PATCH v1 0/1] Allow the building of VirtFS to be disabled
On Tue, 7 Feb 2012 14:44:05 -0600, Meador Inge mead...@codesourcery.com wrote: There have been reports [1, 2] where folks have had issues building VirtFS and the virtio backend on older systems. I personally saw problems due to the use of features (struct statfs f_frsize field, fdopendir, O_NOATIME) in this code that are not available on much older Linux systems. Given, the system I ran into this on is ancient (RH8 sysroot), but I still need to build QEMU on it nonetheless. This patch adds a new configure option for disabling the building of VirtFS all together. Tested by building with and without --disable-virtfs on older (RH8 sysroot) and newer systems (x64 Fedora 16). [1] http://lists.nongnu.org/archive/html/qemu-devel/2011-12/msg00171.html [2] http://lists.nongnu.org/archive/html/qemu-devel/2012-02/msg00404.html Meador Inge (1): ./configure: add option for disabling VirtFS Makefile |4 configure | 16 +--- 2 files changed, 17 insertions(+), 3 deletions(-) I like the patch because it help to get qemu build on platforms where the build failures are only due to virtfs. VirtFS do depend on some of the recent linux APIs, so sometime we do break build on old Linux distros. Anthony any objection here ? -aneesh
Re: [Qemu-devel] [PATCH 0/4] arm: add device tree support (via machine opts)
Hi Peter, Anthony suggested to us the Idea of setting up bootloaders as devices in order to solve this command line argument problem. I have posted a patch to the mailing list ([RFC PATCH] arm boot: added QOM device definition) which is my first attempt at this for arm_boot, i.e. arm_boot.c is now a device model and boot command line arguments (e.g. like the new dtb argument this series introduces) can be added as device model properties without requiring a change pattern to vl.c and friends. Could I get a review of that in the context of what you are trying to do with command line arguments here? Regards, Peter On Wed, Feb 8, 2012 at 3:41 PM, Peter Maydell peter.mayd...@linaro.orgwrote: This patch series is basically Grant's v2 arm: add device tree support patch (http://patchwork.ozlabs.org/patch/138883/) rearranged to use qemu -machine options rather than a global to pass through the device tree blob filename. This is based on a suggestion by Anthony in IRC; I'm a bit sceptical myself, but anyway here's the code... Patches 1 and 2 are pure bugfixes to the existing -machine handling and should be applied anyway IMHO: they fix a bug where only the last of any -enable-kvm and -machine foo=bar options have effect. Differences between Grant's v2 and this: * use -machine options rather than a global * patch 1/2 bug fixes * some rearrangement/cleanup of arm_load_kernel() code Grant Likely (1): arm: add device tree support Peter Maydell (3): qemu-option: Add support for merged QemuOptsLists Make -machine/-enable-kvm options merge into a single list Make kernel, initrd and append be machine_opts Makefile.target |1 + configure |1 + hw/arm-misc.h |1 + hw/arm_boot.c | 96 +++--- qemu-config.c | 17 ++ qemu-option.c |7 +++- qemu-option.h |1 + qemu-options.hx |9 + vl.c| 35 ++-- 9 files changed, 151 insertions(+), 17 deletions(-) -- 1.7.5.4
Re: [Qemu-devel] [RFC PATCH v2 0/4]Zynq-7000 EPP platform model
2012/2/7 Paul Brook p...@codesourcery.com This is an RFC for a suite of Device models and a machine model for the Xilinx Zynq-7000 Extensible Processing Platform: http://www.xilinx.com/products/silicon-devices/epp/zynq-7000/index.htm I don't see any documentation on that page. Are technical docs available? It's much easier to review (and maintain) this sort of thing if we can cross- reference with the programming manuals. The TRM for the platform is yet to be disclosed - this series was developed off a pre-release version of the TRM. We will request disclosure for the purposes of this review. Paul Peter
[Qemu-devel] [Bug 824650] Re: Latest GIT assert error in arp_table.c
okay I forgot to post the qemu command here it is:
qemu-system-i386 -balloon none -smbios
type=0,vendor=Lenovo,version=7LETC6WW,date=05/11/2009,release=2.38 \
-smbios
type=1,manufacturer=Lenovo,product=8896AB5,version=ThinkPadT61,serial=L3C3845,uuid=5D867F81-4A91-11CB-90B0-BF62749B684D,family=ThinkPadT61
\
-drive file=/var/vm/machines/RouterOS-ROS/System-5G_RouterOS-ROS.hdd -no-frame
-vga vmware -monitor stdio -cdrom /var/vm/iso/mikrotik-4.17.iso \
-m 256 -boot menu=on -net nic,model=e1000,macaddr=52:54:00:BE:4E:B7 -net
user,net=192.168.255.0/24 -net nic,model=e1000,macaddr=52:54:00:E5:AC:3A \
-net vde,sock=/var/vm/vde/vHOME -rtc base=localtime -name RouterOS-ROS
-writeconfig /var/vm/machines/RouterOS-ROS/RouterOS-ROS.cfg -machine type=pc \
-cpu core2duo
It doesn't matter if I use the VDE Socket or not. The Error occures everytime
with every configuration.
I even changed the NIC model to rtl8139 | virtio | pcnet
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/824650
Title:
Latest GIT assert error in arp_table.c
Status in QEMU:
New
Bug description:
The latest git version of qemu (commit
8cc7c3952d4d0a681d8d4c3ac89a206a5bfd7f00) crashes after a few minutes.
All was fine up to a few days ago. This is wth both x86 and sparc
emulation, on an x86_64 host.
e.g. qemu-system-sparc -drive
file=netbsd5.0.2-sparc,index=0,media=disk,cache=unsafe -m 256 -boot c
-nographic -redir tcp:2232::22:
qemu-system-sparc: slirp/arp_table.c:75: arp_table_search: Assertion
`(ip_addr (__extension__ ({ register unsigned int __v, __x = (~(0xf
28)); if (__builtin_constant_p (__x)) __v = __x) 0xff00)
24) | (((__x) 0x00ff) 8) | (((__x) 0xff00) 8) |
(((__x) 0x00ff) 24)); else __asm__ (bswap %0 : =r (__v) :
0 (__x)); __v; }))) != 0' failed.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/824650/+subscriptions
Re: [Qemu-devel] [RFC PATCH] replication agent module
On 02/08/2012 08:10 AM, Ori Mamluk wrote: On 07/02/2012 17:47, Paolo Bonzini wrote: On 02/07/2012 03:48 PM, Ori Mamluk wrote: The current streaming code in QEMU only deals with the former. Streaming to a remote server would not be supported. I need it at the same time. The Rephub reads either the full volume or parts of, and concurrently protects new IOs. Why can't QEMU itself stream the full volume in the background, and send that together with any new I/O? Is it because the rephub knows which parts are out-of-date and need recovery? In that case, as a first approximation the rephub can pass the sector at which streaming should start. Yes - it's because rephub knows. The parts that need recovery may be a series of random IOs that were lost because of a network outage somewhere along the replication pipe. Easy to think of it as a bitmap holding the not-yet-replicated IOs. The rephub occasionally reads those areas to 'sync' them, so in effect the rephub needs read access - it's not really to trigger streaming from an offset. But I'm also starting to wonder whether it would be simpler to use existing replication code. DRBD is more feature-rich, and you can use it over loopback or NBD devices (respectively raw and non-raw), and also store the replication metadata on a file using the loopback device. Ceph even has a userspace library and support within QEMU. I think there are two immediate problems that drbd poses: 1. Our replication is not a simple mirror - it maintains history. I.e. you can recover to any point in time in the last X hours (usually 24) at a granularity of about 5 seconds. To be able to do that and keep the replica consistent we need to be notified for each IO. Can you please elaborate some more in the exact details - In theory, you can build a setup where the drbd (or nbd) copy on the destination side write to a intermediate image and every such write is trapped locally on the destination and you may not immediately propagate that to the disk image the VM sees. 2. drbd is 'below' all the Qemu block layers - if the protected volume is qcow2 then drbd doesn't get the raw IOs, right? That's one of the major caveats in drbd/iscsi/nbd - there is no support for block level snapshots[1]. I wonder if the scsi protocol has something like this so we'll get efficient replication of qcow2/lvm snapshots that their base is already shared. If we'll gain such functionality, we'll benefit of it for storage vm motion solution too. Another issue w/ drbd is that a continuous backup solution requires to do consistent snapshot and call file system freeze and sync it w/ the current block IO transfer. DRBD doesn't do that nor the other protocols. Of course DRBD can be enhanced but it will take allot more time. A third requirement and similar to above is to group snapshots of several VMs so a consistent _cross vm application view_ will be created. It demands some control over IO tagging. To summarize, IMHO drbd (which I used successfully 6 years ago and I love) is not dropreplace solution to this case. I recommend we either to fit the nbd/iscsi case and improve our vm storage motion on the way or worse case develop proprietary logic that can live out side of qemu using IO tapping interface, similar to the guidelines Ori outlines. Thanks, Dor [1] Check the far too basic approach for snapshots: http://www.drbd.org/users-guide/s-lvm-snapshots.html Ori
Re: [Qemu-devel] [RFC PATCH] replication agent module
Am 08.02.2012 07:10, schrieb Ori Mamluk: On 07/02/2012 17:47, Paolo Bonzini wrote: On 02/07/2012 03:48 PM, Ori Mamluk wrote: The current streaming code in QEMU only deals with the former. Streaming to a remote server would not be supported. I need it at the same time. The Rephub reads either the full volume or parts of, and concurrently protects new IOs. Why can't QEMU itself stream the full volume in the background, and send that together with any new I/O? Is it because the rephub knows which parts are out-of-date and need recovery? In that case, as a first approximation the rephub can pass the sector at which streaming should start. Yes - it's because rephub knows. The parts that need recovery may be a series of random IOs that were lost because of a network outage somewhere along the replication pipe. Easy to think of it as a bitmap holding the not-yet-replicated IOs. The rephub occasionally reads those areas to 'sync' them, so in effect the rephub needs read access - it's not really to trigger streaming from an offset. So how does the rephub know which areas were touched by lost requests? Isn't qemu the only one who could know what it sent? Kevin
Re: [Qemu-devel] [RFC PATCH] arm boot: added QOM device definition
diff --git a/hw/versatilepb.c b/hw/versatilepb.c
index 6e28e78..e42d845 100644
--- a/hw/versatilepb.c
+++ b/hw/versatilepb.c
@@ -313,12 +313,14 @@ static void versatile_init(ram_addr_t ram_size,
/* 0x101f3000 UART2. */
/* 0x101f4000 SSPI. */
-versatile_binfo.ram_size = ram_size;
-versatile_binfo.kernel_filename = kernel_filename;
-versatile_binfo.kernel_cmdline = kernel_cmdline;
-versatile_binfo.initrd_filename = initrd_filename;
-versatile_binfo.board_id = board_id;
-arm_load_kernel(env, versatile_binfo);
+ if (kernel_filename) {
+ versatile_binfo.ram_size = ram_size;
+ versatile_binfo.kernel_filename = kernel_filename;
+ versatile_binfo.kernel_cmdline = kernel_cmdline;
+ versatile_binfo.initrd_filename = initrd_filename;
+ versatile_binfo.board_id = board_id;
+ arm_load_kernel(env, versatile_binfo);
+ }
}
This should be using the new object you just added.
You also need to fix all the other uses of arm_load_kernel.
Paul
Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
Vadim Rozenfeld píše v St 08. 02. 2012 v 02:47 -0500: I'm afraid to give you any recommendations regarding QEMU stability. I usually work with qemu-kvm repository. But we are always doing WHQL process on RHEL platform only. Maybe someone from the SPICE team can comment on your question? We also focus our testing on RHEL components. We have done some new feature testing on Fedora with virt-preview repo: http://repos.fedorapeople.org/repos/jforbes/virt-preview/ but it still says nothing about qemu stability for your purposes and the qemu version is still 1.0. David Best regards, Vadim. - Original Message - From: Charles.Tsai-蔡清海-研究發展部 charles.t...@cloudena.com To: Vadim Rozenfeld vroze...@redhat.com Cc: Michael Roth mdr...@linux.vnet.ibm.com, Stefan Hajnoczi stefa...@gmail.com, spice-de...@lists.freedesktop.org, Alex Huang-黃必賢-研究發展部 alex.hu...@cloudena.com, Alon Levy al...@redhat.com, qemu-devel qemu-devel@nongnu.org, Paul Lu-盧偉智-研究發展部 paul...@cloudena.com Sent: Wednesday, February 8, 2012 4:39:22 AM Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15 Vadim, Thanks. I tested Windows guest OS driver the over qemu-kvm-devel 1.0.50 from git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git and it worked. The latest Windows guest driver from (https://github.com/YanVugenfirer/) seems to have to work with Qemu 1.0.50. My previous test ran over Qemu 1.0 and that was why it failed to work. As you mentioned, the latest driver from (https://github.com/YanVugenfirer/) is much more stable than the old one. But those drivers must work with Qemu 1.0.50 which was not verified to be stable. Do you think Qemu 1.0.50 is stable to be used? Please give us a recommendation. -Original Message- From: Vadim Rozenfeld [mailto:vroze...@redhat.com] Sent: Wednesday, February 08, 2012 3:06 AM To: Charles.Tsai-蔡清海-研究發展部 Cc: Michael Roth; Stefan Hajnoczi; spice-de...@lists.freedesktop.org; Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel; Paul Lu-盧偉智-研究發展部 Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15 I have tried to reproduce the problem several times without success. QEMU: QEMU 1.0.50 from git://git.qemu.org/qemu.git ,and qemu-kvm-devel 1.0.50 from git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git My guest info: OS Name: Microsoft Windows 7 Enterprise OS Version:6.1.7600 N/A Build 7600 QEMU command line: sudo /home/vrozenfe/work/upstream/qemu/x86_64-softmmu/qemu-system-x86_64 -m 1024 -smp 1,sockets=1,cores=1,threads=1 -name SERIAL -uuid d9388815-ddd3-c38e-33c2-a9d5fcc7a775 -monitor stdio -rtc base=localtime -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,multifunction=on,addr=0x5.0x0 -drive file=/home/vrozenfe/work/images/win7.qcow2,if=none,id=drive-ide0-0-0,format=qcow2 -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -netdev tap,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=22:3A:40:3F:2F:12,bus=pci.0,multifunction=on,addr=0x3.0x0 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -usb -device usb-tablet,id=input0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,multifunction=on,addr=0x4.0x0 -cdrom /home/vrozenfe/work/virtio-win-1.4.0.iso -snapshot -enable-kvm Drivers: Both, MS signed from RHEL6.2 virtio-win RPM, as well as compiled by myself with the sources from our internal repository (which contains absolutely the same code as in Yan's repository). - Original Message - From: Charles.Tsai-蔡清海-研究發展部 charles.t...@cloudena.com To: Vadim Rozenfeld vroze...@redhat.com Cc: Michael Roth mdr...@linux.vnet.ibm.com, Stefan Hajnoczi stefa...@gmail.com, spice-de...@lists.freedesktop.org, Alex Huang-黃必賢-研究發展部 alex.hu...@cloudena.com, Alon Levy al...@redhat.com, qemu-devel qemu-devel@nongnu.org, Paul Lu-盧偉智-研究發展部 paul...@cloudena.com Sent: Monday, February 6, 2012 3:08:55 PM Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15 Vadim, I did the same test again today and no luck to made it work. Let us what you find since we might have missed some points when we did the test. -Original Message- From: Vadim Rozenfeld [mailto:vroze...@redhat.com] Sent: Sunday, February 05, 2012 2:14 AM To: Charles.Tsai-蔡清海-研究發展部 Cc: Michael Roth; Stefan Hajnoczi; spice-de...@lists.freedesktop.org; Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel; Paul Lu-盧偉智-研究發展部 Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15 Thanks, I'll check this problem. Vadim. - Original Message - From: Charles.Tsai-蔡清海-研究發展部 charles.t...@cloudena.com To: Charles.Tsai-蔡清海-研究發展部
[Qemu-devel] [PATCH] slirp: Prevent sending ICMP error replies to source-only addresses
This triggered the related assert in arp_table_search.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
slirp/ip_icmp.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/slirp/ip_icmp.c b/slirp/ip_icmp.c
index 4b43994..5dbf21d 100644
--- a/slirp/ip_icmp.c
+++ b/slirp/ip_icmp.c
@@ -262,6 +262,11 @@ icmp_error(struct mbuf *msrc, u_char type, u_char code,
int minsize,
#endif
if(ip-ip_off IP_OFFMASK) goto end_error;/* Only reply to fragment 0 */
+ /* Do not reply to source-only IPs */
+ if ((ip-ip_src.s_addr htonl(~(0xf 28))) == 0) {
+ goto end_error;
+ }
+
shlen=ip-ip_hl 2;
s_ip_len=ip-ip_len;
if(ip-ip_p == IPPROTO_ICMP) {
--
1.7.3.4
Re: [Qemu-devel] [PATCH 01/19] linux-user: stack_base is now mandatory on all targets
On Fri, Feb 3, 2012 at 3:49 PM, riku.voi...@linaro.org wrote:
From: Riku Voipio riku.voi...@linaro.org
Signed-off-by: Riku Voipio riku.voi...@linaro.org
---
linux-user/qemu.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/linux-user/qemu.h b/linux-user/qemu.h
index 55ad9d8..30e2abd 100644
--- a/linux-user/qemu.h
+++ b/linux-user/qemu.h
@@ -123,10 +123,10 @@ typedef struct TaskState {
#endif
#if defined(TARGET_ARM) || defined(TARGET_M68K) || defined(TARGET_UNICORE32)
/* Extra fields for semihosted binaries. */
- uint32_t stack_base;
uint32_t heap_base;
uint32_t heap_limit;
#endif
+ uint32_t stack_base;
Shouldn't this be abi_ulong instead of uint32_t?
int used; /* non zero if used */
struct image_info *info;
struct linux_binprm *bprm;
Laurent
Re: [Qemu-devel] [RFC PATCH] replication agent module
On 08/02/2012 10:55, Kevin Wolf wrote: Am 08.02.2012 07:10, schrieb Ori Mamluk: On 07/02/2012 17:47, Paolo Bonzini wrote: Why can't QEMU itself stream the full volume in the background, and send that together with any new I/O? Is it because the rephub knows which parts are out-of-date and need recovery? In that case, as a first approximation the rephub can pass the sector at which streaming should start. Yes - it's because rephub knows. The parts that need recovery may be a series of random IOs that were lost because of a network outage somewhere along the replication pipe. Easy to think of it as a bitmap holding the not-yet-replicated IOs. The rephub occasionally reads those areas to 'sync' them, so in effect the rephub needs read access - it's not really to trigger streaming from an offset. So how does the rephub know which areas were touched by lost requests? Isn't qemu the only one who could know what it sent? Kevin You're right. Currently only Qemu knows. The problem is that if we move the responsibility to a layer below Qemu - then rephub will never know. Our (Zerto's) solution for vmware has a different design, but it has 3 parts relevant to this discussion: 1. Tapping to protected writes / read protected volume 2. Maintain a bitmap 3. Provide cross-VM consistency for recovery. I want to simplify our design by taking it one step at a time. My first goal for Qemu is to have only step 1 - meaning tap all protected writes, and be able to read. I think it will be simpler for all of us to complete that first, and it provides a basic ability (though not optimal) for protection and recovery. I think using an external streaming mechanism will make the next stages impossible.
Re: [Qemu-devel] Support for multiboot images in elf64 (EM_X86_64) format
Stefan Hajnoczi stefa...@gmail.com writes:
On Sat, Feb 4, 2012 at 5:38 PM, Goswin von Brederlow goswin-...@web.de
wrote:
Description: Allow 64bit elf binaries in multiboot format
This patch allows 64bit elf files with multiboot header to be loaded.
The entry point will still be called in 32bit mode and the kernel
must switch to 64bit mode on its own. The image and all modules must
also be located in the lower 2GB of ram. All the restrictions of a
32bit image still apply.
Author: Goswin von Brederlow goswin-...@web.de
Last-Updated: 2011-04-08
---
The multiboot specification is 32-bit only. This patch enables a
non-standard 64-bit version of multiboot. Have you checked whether
GRUB or other multiboot loaders have equivalent functionality? Have
you contacted the multiboot specification authors?
Not really. The multiboot specification allow for different executable
formats as long as the multiboot header is correct. For example you can
have an a.out multiboot image. The entry vector specified in the
multiboot header is still called in 32bit mode, as per specs. All that
changes is that the kvm allows another executable format for loading the
image.
Actually per mutliboot specs the elf64 image should already be loaded as
plain image (which means not neccessarily reloacted to the right
address) just like a.out would but kvm doesn't support that.
I don't think other loaders support elf64 (yet) unless they support
plain images. Frankly I never tried booting a toy kernel on real
hardware so there never was the need.
--- qemu-kvm-0.14.0+dfsg.orig/hw/multiboot.c
+++ qemu-kvm-0.14.0+dfsg/hw/multiboot.c
@@ -173,8 +173,7 @@ int load_multiboot(void *fw_cfg,
fclose(f);
if (((struct elf64_hdr*)header)-e_machine == EM_X86_64) {
- fprintf(stderr, Cannot load x86-64 image, give a 32bit
one.\n);
- exit(1);
+ mb_debug(qemu: 64bit elf, I hope you know what you are
doing\n);
This is silent by default, but given the nature of 64-bit multiboot
support I think this warning should be on by default. Anyone using
this really needs to know what they are doing and QEMU should not
silently do weird things.
Stefan
Fine by me to make this more verbose. I only care about removing the
exit(1).
MfG
Goswin
Re: [Qemu-devel] [RFC PATCH] replication agent module
Am 08.02.2012 10:47, schrieb Ori Mamluk: On 08/02/2012 10:55, Kevin Wolf wrote: Am 08.02.2012 07:10, schrieb Ori Mamluk: On 07/02/2012 17:47, Paolo Bonzini wrote: Why can't QEMU itself stream the full volume in the background, and send that together with any new I/O? Is it because the rephub knows which parts are out-of-date and need recovery? In that case, as a first approximation the rephub can pass the sector at which streaming should start. Yes - it's because rephub knows. The parts that need recovery may be a series of random IOs that were lost because of a network outage somewhere along the replication pipe. Easy to think of it as a bitmap holding the not-yet-replicated IOs. The rephub occasionally reads those areas to 'sync' them, so in effect the rephub needs read access - it's not really to trigger streaming from an offset. So how does the rephub know which areas were touched by lost requests? Isn't qemu the only one who could know what it sent? Kevin You're right. Currently only Qemu knows. How could it change later on? If the network is down, qemu can't communicate it to anyone else, so it stays the only one who knows. The problem is that if we move the responsibility to a layer below Qemu - then rephub will never know. Our (Zerto's) solution for vmware has a different design, but it has 3 parts relevant to this discussion: 1. Tapping to protected writes / read protected volume 2. Maintain a bitmap 3. Provide cross-VM consistency for recovery. I want to simplify our design by taking it one step at a time. My first goal for Qemu is to have only step 1 - meaning tap all protected writes, and be able to read. I think it will be simpler for all of us to complete that first, and it provides a basic ability (though not optimal) for protection and recovery. I think using an external streaming mechanism will make the next stages impossible. Well, then we need to discuss all stages now. If you tell only part of what you're going to do, you'll get a design that will only work for part of what you need. Kevin
Re: [Qemu-devel] [RFC PATCH] arm boot: added QOM device definition
2012/2/8 Paul Brook p...@codesourcery.com
diff --git a/hw/versatilepb.c b/hw/versatilepb.c
index 6e28e78..e42d845 100644
--- a/hw/versatilepb.c
+++ b/hw/versatilepb.c
@@ -313,12 +313,14 @@ static void versatile_init(ram_addr_t ram_size,
/* 0x101f3000 UART2. */
/* 0x101f4000 SSPI. */
-versatile_binfo.ram_size = ram_size;
-versatile_binfo.kernel_filename = kernel_filename;
-versatile_binfo.kernel_cmdline = kernel_cmdline;
-versatile_binfo.initrd_filename = initrd_filename;
-versatile_binfo.board_id = board_id;
-arm_load_kernel(env, versatile_binfo);
+ if (kernel_filename) {
+ versatile_binfo.ram_size = ram_size;
+ versatile_binfo.kernel_filename = kernel_filename;
+ versatile_binfo.kernel_cmdline = kernel_cmdline;
+ versatile_binfo.initrd_filename = initrd_filename;
+ versatile_binfo.board_id = board_id;
+ arm_load_kernel(env, versatile_binfo);
+ }
}
This should be using the new object you just added.
Yes I agree. There is another question tho that if this approach is to be
considered, should this call to arm_load_kernel be removed from the machine
model altogether? Only reason to keep it would be backwards compatibility
for the original command line format.
You also need to fix all the other uses of arm_load_kernel.
Ok. I wanted to put this idea forward for a single machine model
(versatilepb in this case) as a proof of concept, before applying a
significant change pattern to all the arm machines. If this approach is to
be considered then I can recreate this series with the change pattern
applied to all arm platforms.
Paul
Peter
[Qemu-devel] Restore consistent formatting
The last commit Restore consistent formatting (cf4dc461a4cfc3e056ee24edb26154f4d34a6278) which is on the master but absent in mailing list results in such output of checkpatch.pl: ./scripts/checkpatch.pl --no-tree --file hw/cs4231a.c ... total: 107 errors, 88 warnings, 696 lines checked - ./scripts/checkpatch.pl --no-tree --file hw/adlib.c ... total: 7 errors, 58 warnings, 337 lines checked - ./scripts/checkpatch.pl --no-tree --file hw/ac97.c ... total: 16 errors, 324 warnings, 1380 lines checked and so on. -- Kind regards, Evgeny Voevodin, Leading Software Engineer, ASWG, Moscow RD center, Samsung Electronics e-mail: e.voevo...@samsung.com
Re: [Qemu-devel] [PATCH v1 0/1] Allow the building of VirtFS to be disabled
On Wed, Feb 08, 2012 at 01:45:15PM +0530, Aneesh Kumar K.V wrote: On Tue, 7 Feb 2012 14:44:05 -0600, Meador Inge mead...@codesourcery.com wrote: There have been reports [1, 2] where folks have had issues building VirtFS and the virtio backend on older systems. I personally saw problems due to the use of features (struct statfs f_frsize field, fdopendir, O_NOATIME) in this code that are not available on much older Linux systems. Given, the system I ran into this on is ancient (RH8 sysroot), but I still need to build QEMU on it nonetheless. [snip] I like the patch because it help to get qemu build on platforms where the build failures are only due to virtfs. VirtFS do depend on some of the recent linux APIs, so sometime we do break build on old Linux distros. Allowing build to be disabled is a fine goal in itself. I think someone should still fix the code to be more portable though. f_frsize is a non-standardized field in 'struct stat', so its usage should be made conditional. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Re: [Qemu-devel] [RFC PATCH v2 2/4] cadence_ttc: initial version of device model
Implemented cadence Triple Timer Counter (TCC) It looks like you're implementing a periodic timer as sequence of chained oneshot timers. This is a bad idea. In qemu interrupt latency may be high, so you're likely to suffer from significant time skew. Ok, I could implemented the wraparound event as a periodic timer and the match events are kicked off as seperate one-shot timers when the wrap around occurs? There would still be a small delay on match events, but it would get rid of the integration effect of lots of little delays (over many wrap arounds) add up to a significant skew. I'm not sure why you need the oneshot timers at all. But then again I'm not really sure what the desired semantics are either :-) It would help me if you could describe how these timers operate. In particular: - Are they free running. i.e. keep counting until explicitly stopped by the user, or stop when an event occurs. - When are interrupts raised. You mention a user specified match value. Do we also get an interrupt on wraparound? - What happens when the timer hits the limit (zero if count-down, match value if count-up)? Does it wrap? or load a fixed value? If you've got independent wrap and match events then I guess yes, a periodic wrap plus a oneshot match event is probably appropriate. If wrapping does not generate an interrupt, or wrap and match are effectively the same thing then you just need to transpose the counter onto a single periodic timer. If the timers can be configured in both periodic and oneshot modes, then you may want to have different implementations based on that. Paul
Re: [Qemu-devel] [RFC PATCH v2 2/4] cadence_ttc: initial version of device model
2012/2/8 Paul Brook p...@codesourcery.com Implemented cadence Triple Timer Counter (TCC) It looks like you're implementing a periodic timer as sequence of chained oneshot timers. This is a bad idea. In qemu interrupt latency may be high, so you're likely to suffer from significant time skew. Ok, I could implemented the wraparound event as a periodic timer and the match events are kicked off as seperate one-shot timers when the wrap around occurs? There would still be a small delay on match events, but it would get rid of the integration effect of lots of little delays (over many wrap arounds) add up to a significant skew. I'm not sure why you need the oneshot timers at all. But then again I'm not really sure what the desired semantics are either :-) It would help me if you could describe how these timers operate. In particular: - Are they free running. i.e. keep counting until explicitly stopped by the user, or stop when an event occurs. Free running - When are interrupts raised. You mention a user specified match value. Do we also get an interrupt on wraparound? Yes, an interrupts occur on wrap around of the 16 bit timer value. There are three match registers which correspond to three more (separately maskable) interrupts which are risen when the timer crosses that value. My implementation will figure out which of the three events (or the wraparound) will occur next, and one shot the corresponding period of time. Note that a match can occur an raise an interrupt without a wrap or reset occuring. E.G. i could set my timer counting up from 0 and when the value hits BEEF, i get an interrupt, but the timer still counts all the way to before wrapping. - What happens when the timer hits the limit (zero if count-down, match value if count-up)? Does it wrap? or load a fixed value? Either wrap or load a fixed value, there is a control bit to determine which. If you've got independent wrap and match events then I guess yes, a periodic wrap plus a oneshot match event is probably appropriate. Yes this is the case. I will look into making it happen. If wrapping does not generate an interrupt, or wrap and match are effectively the same thing then you just need to transpose the counter onto a single periodic timer. If the timers can be configured in both periodic and oneshot modes, then you may want to have different implementations based on that. I dont think this will be needed, the match mechanism detail above is more of an issue and is the underlying reason for the one shot chaining implementation. Paul Peter
Re: [Qemu-devel] [RFC PATCH] arm boot: added QOM device definition
+ arm_load_kernel(env, versatile_binfo); + } } This should be using the new object you just added. Yes I agree. There is another question tho that if this approach is to be considered, should this call to arm_load_kernel be removed from the machine model altogether? Only reason to keep it would be backwards compatibility for the original command line format. I think we want the -kernel commandline option, butI'mnot attached to a particular implementation. Once we have an arm_linux_loader device then arm_load_kernel should go away, or at least be a private implementation detail of arm_linux_loader. Who creates the arm_linux_loader object (common code or board init function), and how we arrange for it to have the right properties (filename from -kernel, board ID from specific machine) is something I haven't entirely figured out. I suspect we want to replace the arm_load_kernel call with an arm_linux_loader device with appropriate properties. We should have some mechanism for the user to override/augment those properties (e.g. overriding the FDT file). I don't know if that functionality actually exists, or if what we have is particularly well thought out. Ideally the -kernel commandline would just be shorthand for setting/overriding the filename property on that device. The machine-init arguments are removed. That's probably going to need wider coordination with other arches. Paul
Re: [Qemu-devel] [PATCH v5 0/6] block: zero writes
Am 07.02.2012 14:27, schrieb Stefan Hajnoczi: This series adds an interface for efficient writes when data contains all zeros. It also takes advantage of this new interface by extending the copy-on-read feature to perform zero-detection. The details of efficient zero representations depend on the image format. This series includes a patch for the QED image format to write special zero clusters that keep the image file compact. In the future qcow2v3 could also support an efficient zero representation. The new BlockDriver interface is called .bdrv_co_write_zeroes() and is optional. If the interface is not implemented by a BlockDriver then a regular .bdrv_co_writev() operation will be performed. The public interface is called bdrv_co_write_zeroes() and can be tested via the new qemu-io write -z option. Copy-on-read is extended to detect zeroes and invoke the .bdrv_co_write_zeroes() interface when possible. As a result we avoid bloating the image file if the backing file contains zeroes. My motivation for this feature is efficient image streaming. The destination file must stay compact even when copying zeroes from the source file. We now only do zero detection for copy-on-read requests, whereas previous revisions of this patch series scanned all write requests for zeroes. The old behavior wasted CPU cycles in most cases but we could add a feature to explicitly scan guest writes for zeroes in the future, if desired. v5: * assert length constraint in buffer_is_zero() [Kevin] * explain why bdrv_co_write_zeroes() is not suitable for huge requests [Kevin] v3: * Rebased on image streaming series v2: * Introduce .bdrv_co_write_zeroes() [Kevin] * Perform zero detection only on copy-on-read requests [Kevin] Stefan Hajnoczi (6): cutils: extract buffer_is_zero() from qemu-img.c block: add .bdrv_co_write_zeroes() interface block: perform zero-detection during copy-on-read qed: replace is_write with flags field qed: add .bdrv_co_write_zeroes() support qemu-io: add write -z option for bdrv_co_write_zeroes block.c | 67 ++ block.h |8 block/qed.c | 125 ++--- block/qed.h |7 +++- block_int.h |8 cutils.c | 35 qemu-common.h |2 + qemu-img.c| 46 +++-- qemu-io.c | 77 +++ trace-events |3 +- 10 files changed, 305 insertions(+), 73 deletions(-) Thanks, applied all to the block branch. Kevin
Re: [Qemu-devel] QEMU build errors with 'fdopendir'
Hi, I will give a fix to disable virtfs by providing a configure option --disable-virtfs. But if you want use virtfs with your current setup, we can give the option to disable handle and proxy FS driver. Still you can use local FS driver. Meador Inge wrote: Did these [1] builds errors ever get fixed? I am running into one of them. I am building QEMU in an environment where 'fdopendir' is not present. 'fdopendir' was introduced in POSIX 2008 (and The Open Group Technical Standard, 2006, Extended API Set Part 2.), so it may not be available in some environments where QEMU is built. [1] http://lists.nongnu.org/archive/html/qemu-devel/2011-12/msg00171.html
Re: [Qemu-devel] [Qemu-ppc] [PATCH] PPC64: Add support for ldbrx and stdbrx instructions
On Wed, Feb 08, 2012 at 10:54:21AM +0400, malc wrote: On Wed, 8 Feb 2012, David Gibson wrote: From: Thomas Huth th...@linux.vnet.ibm.com These instructions for loading and storing byte-swapped 64-bit values have been introduced in PowerISA 2.06. Signed-off-by: Thomas Huth th...@linux.vnet.ibm.com --- target-ppc/translate.c | 30 ++ 1 files changed, 30 insertions(+), 0 deletions(-) I seem to recall that POWER5 machine i had access to didn't have ld/stdbrx while CBE did have it (or was it the other way around?) so question is - is PPC_64B sufficient? Ah, I think it's not. I think I spotted that before, but then forgot about it. Thanks for the reminder. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
[Qemu-devel] [PATCH v3 4/6] suspend: make ps/2 devices wakeup the guest
This patch adds wakeup support to ps/2 emulation. Any key press on the
ps/2 keyboard will wakeup the guest. Likewise any mouse button press
will wakeup the guest. Mouse moves are ignored, so the guest will not
wakeup in case your mouse crosses the vnc window of a suspended guest by
accident.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
hw/ps2.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/hw/ps2.c b/hw/ps2.c
index 1d9057b..d1b2505 100644
--- a/hw/ps2.c
+++ b/hw/ps2.c
@@ -24,6 +24,7 @@
#include hw.h
#include ps2.h
#include console.h
+#include sysemu.h
/* debug PC keyboard */
//#define DEBUG_KBD
@@ -154,6 +155,7 @@ static void ps2_put_keycode(void *opaque, int keycode)
{
PS2KbdState *s = opaque;
+qemu_system_wakeup_request();
/* XXX: add support for scancode set 1 */
if (!s-translate keycode 0xe0 s-scancode_set 1) {
if (keycode 0x80) {
@@ -368,6 +370,10 @@ static void ps2_mouse_event(void *opaque,
return;
s-mouse_buttons = buttons_state;
+if (buttons_state) {
+qemu_system_wakeup_request();
+}
+
if (!(s-mouse_status MOUSE_STATUS_REMOTE)
(s-common.queue.count (PS2_QUEUE_SIZE - 16))) {
for(;;) {
--
1.7.1
[Qemu-devel] [PATCH v3 1/6] suspend: add infrastructure
This patch adds some infrastructure to handle suspend and resume to
qemu. First there are two functions to switch state and second there
is a suspend notifier:
* qemu_system_suspend_request() is supposed to be called when the
guest asks for being be suspended, for example via ACPI.
* qemu_system_wakeup_request is supposed to be called on events which
should wake up the guest.
* qemu_register_suspend_notifier can be used to register a notifier
which will be called when the guest is suspended. Machine types
and device models can hook in there to modify state if needed.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
sysemu.h |3 +++
vl.c | 28
2 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/sysemu.h b/sysemu.h
index 9d5ce33..3b9d7f5 100644
--- a/sysemu.h
+++ b/sysemu.h
@@ -39,6 +39,9 @@ void vm_stop(RunState state);
void vm_stop_force_state(RunState state);
void qemu_system_reset_request(void);
+void qemu_system_suspend_request(void);
+void qemu_register_suspend_notifier(Notifier *notifier);
+void qemu_system_wakeup_request(void);
void qemu_system_shutdown_request(void);
void qemu_system_powerdown_request(void);
void qemu_system_debug_request(void);
diff --git a/vl.c b/vl.c
index 63dd725..822fd58 100644
--- a/vl.c
+++ b/vl.c
@@ -1283,6 +1283,9 @@ static int shutdown_requested, shutdown_signal = -1;
static pid_t shutdown_pid;
static int powerdown_requested;
static int debug_requested;
+static bool is_suspended;
+static NotifierList suspend_notifiers =
+NOTIFIER_LIST_INITIALIZER(suspend_notifiers);
static RunState vmstop_requested = RUN_STATE_MAX;
int qemu_shutdown_requested_get(void)
@@ -1398,6 +1401,31 @@ void qemu_system_reset_request(void)
qemu_notify_event();
}
+void qemu_system_suspend_request(void)
+{
+if (is_suspended) {
+return;
+}
+cpu_stop_current();
+notifier_list_notify(suspend_notifiers, NULL);
+is_suspended = true;
+}
+
+void qemu_register_suspend_notifier(Notifier *notifier)
+{
+notifier_list_add(suspend_notifiers, notifier);
+}
+
+void qemu_system_wakeup_request(void)
+{
+if (!is_suspended) {
+return;
+}
+reset_requested = 1;
+qemu_notify_event();
+is_suspended = false;
+}
+
void qemu_system_killed(int signal, pid_t pid)
{
shutdown_signal = signal;
--
1.7.1
[Qemu-devel] [PATCH v3 3/6] suspend: add system_wakeup monitor command
This patch adds the system_wakeup monitor command which will simply
wake up suspended guests.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
hmp-commands.hx | 14 ++
hmp.c|5 +
hmp.h|1 +
qapi-schema.json | 11 +++
qmp-commands.hx | 21 +
qmp.c|5 +
6 files changed, 57 insertions(+), 0 deletions(-)
diff --git a/hmp-commands.hx b/hmp-commands.hx
index 573b823..64b3656 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -352,6 +352,20 @@ Resume emulation.
ETEXI
{
+.name = system_wakeup,
+.args_type = ,
+.params = ,
+.help = wakeup guest from suspend,
+.mhandler.cmd = hmp_system_wakeup,
+},
+
+STEXI
+@item system_wakeup
+@findex system_wakeup
+Wakeup guest from suspend.
+ETEXI
+
+{
.name = gdbserver,
.args_type = device:s?,
.params = [device],
diff --git a/hmp.c b/hmp.c
index 8ff8c94..3a54455 100644
--- a/hmp.c
+++ b/hmp.c
@@ -632,6 +632,11 @@ void hmp_cont(Monitor *mon, const QDict *qdict)
}
}
+void hmp_system_wakeup(Monitor *mon, const QDict *qdict)
+{
+qmp_system_wakeup(NULL);
+}
+
void hmp_inject_nmi(Monitor *mon, const QDict *qdict)
{
Error *errp = NULL;
diff --git a/hmp.h b/hmp.h
index 18eecbd..5409464 100644
--- a/hmp.h
+++ b/hmp.h
@@ -41,6 +41,7 @@ void hmp_cpu(Monitor *mon, const QDict *qdict);
void hmp_memsave(Monitor *mon, const QDict *qdict);
void hmp_pmemsave(Monitor *mon, const QDict *qdict);
void hmp_cont(Monitor *mon, const QDict *qdict);
+void hmp_system_wakeup(Monitor *mon, const QDict *qdict);
void hmp_inject_nmi(Monitor *mon, const QDict *qdict);
void hmp_set_link(Monitor *mon, const QDict *qdict);
void hmp_block_passwd(Monitor *mon, const QDict *qdict);
diff --git a/qapi-schema.json b/qapi-schema.json
index d02ee86..226c1da 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -999,6 +999,17 @@
{ 'command': 'cont' }
##
+# @system_wakeup:
+#
+# Wakeup guest from suspend
+#
+# Since: 1.1
+#
+# Returns: nothing.
+##
+{ 'command': 'system_wakeup' }
+
+##
# @inject-nmi:
#
# Injects an Non-Maskable Interrupt into all guest's VCPUs.
diff --git a/qmp-commands.hx b/qmp-commands.hx
index b5e2ab8..f5081e2 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -212,6 +212,27 @@ Example:
EQMP
{
+.name = system_wakeup,
+.args_type = ,
+.mhandler.cmd_new = qmp_marshal_input_system_wakeup,
+},
+
+SQMP
+system_wakeup
+-
+
+Wakeup guest from suspend.
+
+Arguments: None.
+
+Example:
+
+- { execute: system_wakeup }
+- { return: {} }
+
+EQMP
+
+{
.name = system_reset,
.args_type = ,
.mhandler.cmd_new = qmp_marshal_input_system_reset,
diff --git a/qmp.c b/qmp.c
index 45052cc..9ff5ec3 100644
--- a/qmp.c
+++ b/qmp.c
@@ -164,6 +164,11 @@ void qmp_cont(Error **errp)
vm_start();
}
+void qmp_system_wakeup(Error **errp)
+{
+qemu_system_wakeup_request();
+}
+
ObjectPropertyInfoList *qmp_qom_list(const char *path, Error **errp)
{
Object *obj;
--
1.7.1
Re: [Qemu-devel] [RFC PATCH] replication agent module
On Wed, Feb 8, 2012 at 6:10 AM, Ori Mamluk omam...@zerto.com wrote: 2. drbd is 'below' all the Qemu block layers - if the protected volume is qcow2 then drbd doesn't get the raw IOs, right? No, if you look at the layers again: Guest - QEMU - drbd - local NBD server The local NBD server runs the qcow2, qed, etc code. drbd is on top of image format code. Stefan
Re: [Qemu-devel] [RFC PATCH] arm boot: added QOM device definition
2012/2/8 Paul Brook p...@codesourcery.com + arm_load_kernel(env, versatile_binfo); + } } This should be using the new object you just added. Yes I agree. There is another question tho that if this approach is to be considered, should this call to arm_load_kernel be removed from the machine model altogether? Only reason to keep it would be backwards compatibility for the original command line format. I think we want the -kernel commandline option, butI'mnot attached to a particular implementation. Once we have an arm_linux_loader device then arm_load_kernel should go away, or at least be a private implementation detail of arm_linux_loader. Who creates the arm_linux_loader object (common code or board init function), and how we arrange for it to have the right properties (filename from -kernel, board ID from specific machine) is something I haven't entirely figured out. Peter Maydell just emailed a series today that exported kernel_filename friends as machine opts. Maybe if fundamental machine properties (such as num cpus, ram size and board ID) come from machine opts and the bootload specifics such as filepaths and command lines come from the bootloader device props? The existing -kernel arguments could come via the machine opts path and form defaults for the bootloader device if no -kernel arg is specified to the bootloader device? I suspect we want to replace the arm_load_kernel call with an arm_linux_loader device with appropriate properties. Ok, so does this mean the machine model would still explicitly instantiate the bootloader device? Will there be a way of removing the bootloader from the machine model so if I need to create my own custom bootloader flow i can? We are doing some custom non-linux boots in our application where arm-boot.c is not working for us so being able to swap out arm_boot.c for another implemenation is one of our goals. The bootloader-as-a-device flow is ideal for this but only works if a user can choose their bootloader on the command line. We should have some mechanism for the user to override/augment those properties (e.g. overriding the FDT file). I don't know if that functionality actually exists, or if what we have is particularly well thought out. Ideally the -kernel commandline would just be shorthand for setting/overriding the filename property on that device. The machine-init arguments are removed. That's probably going to need wider coordination with other arches. Paul
[Qemu-devel] [Bug 818673] Re: virtio: trying to map MMIO memory
Now have next config and bug still: /usr/bin/kvm -S -M pc-0.12 -cpu qemu32 -enable-kvm -m 2048 -smp 1 -name boss_xp -uuid 9041090d-acee-da4a-921d-238f2a43be64 -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/boss_xp.monitor,server,nowait -monitor chardev:monitor -localtime -boot c -drive file=/root/boss_xp.qcow2,if=virtio,index=0,boot=on,format=raw,cache=none -drive file=/home/admino/virtio-win-1.1.16.iso,if=ide,media=cdrom,index=2,format=raw -net nic,macaddr=00:16:36:49:83:6c,vlan=0,model=rtl8139,name=rtl8139.0 -net tap,fd=43,vlan=0,name=tap.0 -serial none -parallel none -usb -usbdevice tablet -vnc 127.0.0.1:2 -k en-us -vga cirrus -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/818673 Title: virtio: trying to map MMIO memory Status in QEMU: New Bug description: Qemu host is Core i7, running Linux. Guest is Windows XP sp3. Often, qemu will crash shortly after starting (1-5 minutes) with a statement qemu-system-x86_64: virtio: trying to map MMIO memory This has occured with qemu-kvm 0.14, qemu-kvm 0.14.1, qemu-0.15.0-rc0 and qemu 0.15.0-rc1. Qemu is started as such: qemu-system-x86_64 -cpu host -enable-kvm -pidfile /home/rick/qemu/hds/wxp.pid -drive file=/home/rick/qemu/hds/wxp.raw,if=virtio -m 768 -name WinXP -net nic,model=virtio -net user -localtime -usb -vga qxl -device virtio-serial -chardev spicevmc,name=vdagent,id=vdagent -device virtserialport,chardev=vdagent,name=com.redhat.spice.0 -spice port=1234,disable-ticketing -daemonize -monitor telnet:localhost:12341,server,nowait The WXP guest has virtio 1.1.16 drivers for net and scsi, and the most current spice binaries from spice-space.org. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/818673/+subscriptions
Re: [Qemu-devel] Support for multiboot images in elf64 (EM_X86_64) format
Am 08.02.2012 10:53, schrieb Goswin von Brederlow: Stefan Hajnoczi stefa...@gmail.com writes: On Sat, Feb 4, 2012 at 5:38 PM, Goswin von Brederlow goswin-...@web.de wrote: Description: Allow 64bit elf binaries in multiboot format This patch allows 64bit elf files with multiboot header to be loaded. The entry point will still be called in 32bit mode and the kernel must switch to 64bit mode on its own. The image and all modules must also be located in the lower 2GB of ram. All the restrictions of a 32bit image still apply. Author: Goswin von Brederlow goswin-...@web.de Last-Updated: 2011-04-08 --- The multiboot specification is 32-bit only. This patch enables a non-standard 64-bit version of multiboot. Have you checked whether GRUB or other multiboot loaders have equivalent functionality? Have you contacted the multiboot specification authors? Not really. The multiboot specification allow for different executable formats as long as the multiboot header is correct. For example you can have an a.out multiboot image. The entry vector specified in the multiboot header is still called in 32bit mode, as per specs. All that changes is that the kvm allows another executable format for loading the image. Actually per mutliboot specs the elf64 image should already be loaded as plain image (which means not neccessarily reloacted to the right address) just like a.out would but kvm doesn't support that. I don't think other loaders support elf64 (yet) unless they support plain images. Frankly I never tried booting a toy kernel on real hardware so there never was the need. If you want to use it this way, you need to use the a.out kludge, i.e. the multiboot header must have set bit 16 of the flag and the address fields must be present in the multiboot header. In this case, the code path that you're patching isn't even run. Kevin
[Qemu-devel] [PATCH v3 2/6] suspend: switch acpi s3 to new infrastructure.
This patch switches pc s3 suspend over to the new infrastructure.
The cmos_s3 qemu_irq is killed, the new notifier is used instead.
The xen hack goes away with that too, the hypercall can simply be
done in a notifier function now.
This patch also makes the guest actually stay suspended instead
of leaving suspend instantly, so it is useful for more than just
testing whenever the suspend/resume cycle actually works.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
hw/acpi.c| 11 +--
hw/acpi.h|2 --
hw/acpi_piix4.c |3 +--
hw/mc146818rtc.c | 12
hw/mips_malta.c |2 +-
hw/pc.c | 11 ---
hw/pc.h |3 +--
hw/pc_piix.c |8 +---
hw/vt82c686.c|1 -
xen-all.c| 11 ++-
10 files changed, 23 insertions(+), 41 deletions(-)
diff --git a/hw/acpi.c b/hw/acpi.c
index 79b179b..67dcd43 100644
--- a/hw/acpi.c
+++ b/hw/acpi.c
@@ -330,11 +330,6 @@ void acpi_pm_tmr_reset(ACPIPMTimer *tmr)
}
/* ACPI PM1aCNT */
-void acpi_pm1_cnt_init(ACPIPM1CNT *pm1_cnt, qemu_irq cmos_s3)
-{
-pm1_cnt-cmos_s3 = cmos_s3;
-}
-
void acpi_pm1_cnt_write(ACPIPM1EVT *pm1a, ACPIPM1CNT *pm1_cnt, uint16_t val)
{
pm1_cnt-cnt = val ~(ACPI_BITMASK_SLEEP_ENABLE);
@@ -351,8 +346,7 @@ void acpi_pm1_cnt_write(ACPIPM1EVT *pm1a, ACPIPM1CNT
*pm1_cnt, uint16_t val)
Pretend that resume was caused by power button */
pm1a-sts |=
(ACPI_BITMASK_WAKE_STATUS | ACPI_BITMASK_POWER_BUTTON_STATUS);
-qemu_system_reset_request();
-qemu_irq_raise(pm1_cnt-cmos_s3);
+qemu_system_suspend_request();
default:
break;
}
@@ -373,9 +367,6 @@ void acpi_pm1_cnt_update(ACPIPM1CNT *pm1_cnt,
void acpi_pm1_cnt_reset(ACPIPM1CNT *pm1_cnt)
{
pm1_cnt-cnt = 0;
-if (pm1_cnt-cmos_s3) {
-qemu_irq_lower(pm1_cnt-cmos_s3);
-}
}
/* ACPI GPE */
diff --git a/hw/acpi.h b/hw/acpi.h
index c141e65..e0c7dbe 100644
--- a/hw/acpi.h
+++ b/hw/acpi.h
@@ -115,8 +115,6 @@ void acpi_pm1_evt_reset(ACPIPM1EVT *pm1);
/* PM1a_CNT: piix and ich9 don't implement PM1b CNT. */
struct ACPIPM1CNT {
uint16_t cnt;
-
-qemu_irq cmos_s3;
};
typedef struct ACPIPM1CNT ACPIPM1CNT;
diff --git a/hw/acpi_piix4.c b/hw/acpi_piix4.c
index 21484ae..bc77dc5 100644
--- a/hw/acpi_piix4.c
+++ b/hw/acpi_piix4.c
@@ -376,7 +376,7 @@ static int piix4_pm_initfn(PCIDevice *dev)
}
i2c_bus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t smb_io_base,
- qemu_irq sci_irq, qemu_irq cmos_s3, qemu_irq smi_irq,
+ qemu_irq sci_irq, qemu_irq smi_irq,
int kvm_enabled)
{
PCIDevice *dev;
@@ -387,7 +387,6 @@ i2c_bus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t
smb_io_base,
s = DO_UPCAST(PIIX4PMState, dev, dev);
s-irq = sci_irq;
-acpi_pm1_cnt_init(s-pm1_cnt, cmos_s3);
s-smi_irq = smi_irq;
s-kvm_enabled = kvm_enabled;
diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
index 4a43225..314ed52 100644
--- a/hw/mc146818rtc.c
+++ b/hw/mc146818rtc.c
@@ -102,6 +102,7 @@ typedef struct RTCState {
QEMUTimer *second_timer2;
Notifier clock_reset_notifier;
LostTickPolicy lost_tick_policy;
+Notifier suspend_notifier;
} RTCState;
static void rtc_set_time(RTCState *s);
@@ -596,6 +597,14 @@ static void rtc_notify_clock_reset(Notifier *notifier,
void *data)
#endif
}
+/* set CMOS shutdown status register (index 0xF) as S3_resume(0xFE)
+ BIOS will read it and start S3 resume at POST Entry */
+static void rtc_notify_suspend(Notifier *notifier, void *data)
+{
+RTCState *s = container_of(notifier, RTCState, suspend_notifier);
+rtc_set_memory(s-dev, 0xF, 0xFE);
+}
+
static void rtc_reset(void *opaque)
{
RTCState *s = opaque;
@@ -676,6 +685,9 @@ static int rtc_initfn(ISADevice *dev)
s-clock_reset_notifier.notify = rtc_notify_clock_reset;
qemu_register_clock_reset_notifier(rtc_clock, s-clock_reset_notifier);
+s-suspend_notifier.notify = rtc_notify_suspend;
+qemu_register_suspend_notifier(s-suspend_notifier);
+
s-next_second_time =
qemu_get_clock_ns(rtc_clock) + (get_ticks_per_sec() * 99) / 100;
qemu_mod_timer(s-second_timer2, s-next_second_time);
diff --git a/hw/mips_malta.c b/hw/mips_malta.c
index d232630..fe02c93 100644
--- a/hw/mips_malta.c
+++ b/hw/mips_malta.c
@@ -966,7 +966,7 @@ void mips_malta_init (ram_addr_t ram_size,
pci_piix4_ide_init(pci_bus, hd, piix4_devfn + 1);
usb_uhci_piix4_init(pci_bus, piix4_devfn + 2);
smbus = piix4_pm_init(pci_bus, piix4_devfn + 3, 0x1100,
- isa_get_irq(NULL, 9), NULL, NULL, 0);
+ isa_get_irq(NULL, 9), NULL, 0);
/* TODO: Populate SPD eeprom data. */
smbus_eeprom_init(smbus, 8, NULL, 0);
pit = pit_init(isa_bus, 0x40, 0);
diff --git a/hw/pc.c b/hw/pc.c
index 7f3aa65..7b93aee 100644
--- a/hw/pc.c
+++
[Qemu-devel] [PATCH v3 6/6] suspend: make rtc alarm wakeup the guest.
Add a 'wakeup' property to the mc146818rtc. It is on by default.
When enabled the rtc will wake up the guest when the alarm fires.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
hw/mc146818rtc.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
index 314ed52..3b912c6 100644
--- a/hw/mc146818rtc.c
+++ b/hw/mc146818rtc.c
@@ -86,6 +86,7 @@ typedef struct RTCState {
uint8_t cmos_index;
struct tm current_tm;
int32_t base_year;
+uint32_t wakeup;
qemu_irq irq;
qemu_irq sqw_irq;
int it_shift;
@@ -437,6 +438,9 @@ static void rtc_update_second2(void *opaque)
s-cmos_data[RTC_REG_C] |= REG_C_AF;
if (s-cmos_data[RTC_REG_B] REG_B_AIE) {
+if (s-wakeup) {
+qemu_system_wakeup_request();
+}
qemu_irq_raise(s-irq);
s-cmos_data[RTC_REG_C] |= REG_C_IRQF;
}
@@ -725,6 +729,7 @@ static Property mc146818rtc_properties[] = {
DEFINE_PROP_INT32(base_year, RTCState, base_year, 1980),
DEFINE_PROP_LOSTTICKPOLICY(lost_tick_policy, RTCState,
lost_tick_policy, LOST_TICK_DISCARD),
+DEFINE_PROP_UINT32(wakeup, RTCState, wakeup,1),
DEFINE_PROP_END_OF_LIST(),
};
--
1.7.1
[Qemu-devel] [PATCH v3 5/6] suspend: make serial ports wakeup the guest.
Add a 'wakeup' property to the serial port. It is off by default. When
enabled any incoming character on the serial line will wake up the
guest. Useful for guests which have a serial console configured.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
hw/serial.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/hw/serial.c b/hw/serial.c
index 82917e2..108bb94 100644
--- a/hw/serial.c
+++ b/hw/serial.c
@@ -139,6 +139,7 @@ struct SerialState {
int it_shift;
int baudbase;
int tsr_retry;
+uint32_t wakeup;
uint64_t last_xmit_ts; /* Time when the last byte was
successfully sent out of the tsr */
SerialFIFO recv_fifo;
@@ -635,6 +636,10 @@ static int serial_can_receive1(void *opaque)
static void serial_receive1(void *opaque, const uint8_t *buf, int size)
{
SerialState *s = opaque;
+
+if (s-wakeup) {
+qemu_system_wakeup_request();
+}
if(s-fcr UART_FCR_FE) {
int i;
for (i = 0; i size; i++) {
@@ -884,6 +889,7 @@ static Property serial_isa_properties[] = {
DEFINE_PROP_HEX32(iobase, ISASerialState, iobase, -1),
DEFINE_PROP_UINT32(irq, ISASerialState, isairq, -1),
DEFINE_PROP_CHR(chardev, ISASerialState, state.chr),
+DEFINE_PROP_UINT32(wakeup, ISASerialState, state.wakeup, 0),
DEFINE_PROP_END_OF_LIST(),
};
--
1.7.1
[Qemu-devel] [PATCH v3 0/6] initial suspend support
This patch series makes suspend support in qemu alot more useful. Right now the guest can put itself into s3, but qemu will wakeup the guest instantly. With this patch series applied the guest will stay suspended instead and there are a few events which can kick the guest out of suspend state: A monitor command, ps/2 input, serial input, rtc. Not much yet, but it's a start with the low hanging fruits ;) Changes in v3: * Rename monitor command to 'system_wakeup'. * Fix tyops in documentation. Changes in v2: * Add a suspend notifier. * Replace the cmos_s3 qemu_irq with the notifier, zap a bunch of hackish cmos_s3 windup code (this touches xen-all.c, thus cc xen-devel). * Add rtc wakeup support. Gerd Hoffmann (6): suspend: add infrastructure suspend: switch acpi s3 to new infrastructure. suspend: add system_wakeup monitor command suspend: make ps/2 devices wakeup the guest suspend: make serial ports wakeup the guest. suspend: make rtc alarm wakeup the guest. hmp-commands.hx | 14 ++ hmp.c|5 + hmp.h|1 + hw/acpi.c| 11 +-- hw/acpi.h|2 -- hw/acpi_piix4.c |3 +-- hw/mc146818rtc.c | 17 + hw/mips_malta.c |2 +- hw/pc.c | 11 --- hw/pc.h |3 +-- hw/pc_piix.c |8 +--- hw/ps2.c |6 ++ hw/serial.c |6 ++ hw/vt82c686.c|1 - qapi-schema.json | 11 +++ qmp-commands.hx | 21 + qmp.c|5 + sysemu.h |3 +++ vl.c | 28 xen-all.c| 11 ++- 20 files changed, 128 insertions(+), 41 deletions(-)
Re: [Qemu-devel] [RFC PATCH] arm boot: added QOM device definition
I suspect we want to replace the arm_load_kernel call with an arm_linux_loader device with appropriate properties. Ok, so does this mean the machine model would still explicitly instantiate the bootloader device? Yes. Bootloaders inherently have machine specific knowledge. They need to know ram location, board ID, secondary CPU boot protocols, etc. Requiring the user specify all these things separately from the rest of the machine description is IMO not acceptable. Will there be a way of removing the bootloader from the machine model so if I need to create my own custom bootloader flow i can? We are doing some custom non-linux boots in our application where arm-boot.c is not working for us so being able to swap out arm_boot.c for another implemenation is one of our goals. The bootloader-as-a-device flow is ideal for this but only works if a user can choose their bootloader on the command line. I think that's solved the same lines as any other custom machine variant. It's also part of the reason I think it's important to cleanly separate devices that provide functionality from those that are just convenience objects for creating a particular assembly of devices. Having generic ELF and maybe binary blob image loaders is certainly useful. They can all coexist happily within the same machine. I'm inclined to say that anything else isn't worth the effort. Users with other special needs can use third party tools[1] to embed/wrap their magic in a regular image. Paul [1] In many cases cases you just need to splat the supplied bootloader+kernel images into ram, not postprocessing is necessary. For most of the rest objcopy is sufficient.
Re: [Qemu-devel] [RFC PATCH] replication agent module
On Tue, 07 Feb 2012 14:34:12 +0100 Kevin Wolf kw...@redhat.com wrote: The other message types could possibly be implemented as QMP commands. I guess we might need to attach multiple QMP monitors for this to work (one for libvirt, one for the rephub). I'm not sure if there is a fundamental problem with this or if it just needs to be done. Afaik, multiple QMP instances is not well tested. It's something I've tried not to break when adding new functionality, but I don't think it got any serious usage so far.
Re: [Qemu-devel] [RFC PATCH] arm boot: added QOM device definition
2012/2/8 Paul Brook p...@codesourcery.com I suspect we want to replace the arm_load_kernel call with an arm_linux_loader device with appropriate properties. Ok, so does this mean the machine model would still explicitly instantiate the bootloader device? Yes. Bootloaders inherently have machine specific knowledge. They need to know ram location, board ID, secondary CPU boot protocols, etc. Requiring the user specify all these things separately from the rest of the machine description is IMO not acceptable. So what im suggesting here is that machines export these properties to a globally accessible location. Perhaps via the machine opts mechanism? Then we are in a best of both worls situation where machine models do not need bootloader awareness yet bootloaders can still query qemu for ram_size, smp#, board_id and friends. Will there be a way of removing the bootloader from the machine model so if I need to create my own custom bootloader flow i can? We are doing some custom non-linux boots in our application where arm-boot.c is not working for us so being able to swap out arm_boot.c for another implemenation is one of our goals. The bootloader-as-a-device flow is ideal for this but only works if a user can choose their bootloader on the command line. I think that's solved the same lines as any other custom machine variant. It's also part of the reason I think it's important to cleanly separate devices that provide functionality from those that are just convenience objects for creating a particular assembly of devices. Having generic ELF and maybe binary blob image loaders is certainly useful. They can all coexist happily within the same machine. I'm inclined to say that anything else isn't worth the effort. Users with other special needs can use third party tools[1] to embed/wrap their magic in a regular image. Paul [1] In many cases cases you just need to splat the supplied bootloader+kernel images into ram, not postprocessing is necessary. For most of the rest objcopy is sufficient.
Re: [Qemu-devel] [RFC PATCH] replication agent module
2012/2/8 Dor Laor dl...@redhat.com: On 02/08/2012 08:10 AM, Ori Mamluk wrote: 2. drbd is 'below' all the Qemu block layers - if the protected volume is qcow2 then drbd doesn't get the raw IOs, right? That's one of the major caveats in drbd/iscsi/nbd - there is no support for block level snapshots[1]. I wonder if the scsi protocol has something like this so we'll get efficient replication of qcow2/lvm snapshots that their base is already shared. If we'll gain such functionality, we'll benefit of it for storage vm motion solution too. In the case of copy-on-write disk images we do want to mirror all writes because, by definition, they are not shared. I think the trickier part is how to do the initial synchronization without copying the entire backing file. Another issue w/ drbd is that a continuous backup solution requires to do consistent snapshot and call file system freeze and sync it w/ the current block IO transfer. DRBD doesn't do that nor the other protocols. Of course DRBD can be enhanced but it will take allot more time. Ori's patch simply mirrors writes, it doesn't have any higher-level consistent snapshot support either. Consistent snapshots are different from continuous backups - I thought these were being addressed with completely separate QMP and guest agent commands? A third requirement and similar to above is to group snapshots of several VMs so a consistent _cross vm application view_ will be created. It demands some control over IO tagging. If I understand correctly this means being able to go back to time T across multiple VMs' volumes. That sounds like a timestamping issue and is mainly a server-side feature, the agent is not involved. To summarize, IMHO drbd (which I used successfully 6 years ago and I love) is not dropreplace solution to this case. I recommend we either to fit the nbd/iscsi case and improve our vm storage motion on the way or worse case develop proprietary logic that can live out side of qemu using IO tapping interface, similar to the guidelines Ori outlines. Perhaps we can figure out how to make this replication functionality fit in with image streaming and block migration. If it provides generally useful functionality (outside of just the replication case) then that would be worth adding to QEMU because it would be useful beyond drbd territory. Stefan
Re: [Qemu-devel] [RFC Patch 1/7]Qemu: Enhance info block to display host cache setting
On Wed, 01 Feb 2012 08:36:14 +0530
Supriya Kannery supri...@linux.vnet.ibm.com wrote:
Enhance info block to display hostcache setting for each
block device.
Example:
(qemu) info block
ide0-hd0: removable=0 file=../rhel6-32.raw ro=0 drv=raw encrypted=0
Enhanced to display hostcache setting:
(qemu) info block
ide0-hd0: removable=0 hostcache=1 file=../rhel6-32.raw ro=0 drv=raw
encrypted=0
The day we'll want to refactor 'info block' output is coming...
Signed-off-by: Supriya Kannery supri...@linux.vnet.ibm.com
---
block.c | 20
qmp-commands.hx |2 ++
2 files changed, 18 insertions(+), 4 deletions(-)
Index: qemu/qapi-schema.json
===
--- qemu.orig/qapi-schema.json
+++ qemu/qapi-schema.json
@@ -423,6 +423,8 @@
# @locked: True if the guest has locked this device from having its media
# removed
#
+# @hostcache: True if host pagecache is enabled.
+#
# @tray_open: #optional True if the device has a tray and it is open
# (only present if removable is true)
#
@@ -436,7 +438,7 @@
##
{ 'type': 'BlockInfo',
'data': {'device': 'str', 'type': 'str', 'removable': 'bool',
- 'locked': 'bool', '*inserted': 'BlockDeviceInfo',
+ 'locked': 'bool','hostcache': 'bool', '*inserted':
'BlockDeviceInfo',
'*tray_open': 'bool', '*io-status': 'BlockDeviceIoStatus'} }
##
Index: qemu/block.c
===
--- qemu.orig/block.c
+++ qemu/block.c
@@ -2285,6 +2285,7 @@ BlockInfoList *qmp_query_block(Error **e
info-value-device = g_strdup(bs-device_name);
info-value-type = g_strdup(unknown);
info-value-locked = bdrv_dev_is_medium_locked(bs);
+info-value-hostcache = !(bs-open_flags BDRV_O_NOCACHE);
info-value-removable = bdrv_dev_has_removable_media(bs);
if (bdrv_dev_has_removable_media(bs)) {
Index: qemu/hmp.c
===
--- qemu.orig/hmp.c
+++ qemu/hmp.c
@@ -209,6 +209,8 @@ void hmp_info_block(Monitor *mon)
monitor_printf(mon, tray-open=%d, info-value-tray_open);
}
+monitor_printf(mon, hostcache=%d, info-value-hostcache);
+
if (info-value-has_io_status) {
monitor_printf(mon, io-status=%s,
BlockDeviceIoStatus_lookup[info-value-io_status]);
Re: [Qemu-devel] [RFC PATCH] replication agent module
On Wed, Feb 8, 2012 at 6:10 AM, Ori Mamluk omam...@zerto.com wrote: On 07/02/2012 17:47, Paolo Bonzini wrote: But I'm also starting to wonder whether it would be simpler to use existing replication code. DRBD is more feature-rich, and you can use it over loopback or NBD devices (respectively raw and non-raw), and also store the replication metadata on a file using the loopback device. Ceph even has a userspace library and support within QEMU. I think there are two immediate problems that drbd poses: 1. Our replication is not a simple mirror - it maintains history. I.e. you can recover to any point in time in the last X hours (usually 24) at a granularity of about 5 seconds. To be able to do that and keep the replica consistent we need to be notified for each IO. If you intend to run an unmodified drbd server on the rephub, then it may not be possible to get point-in-time backups. (Although this probably depends since things like btrfs or zfs may allow you to get back to arbitrary transactions or timestamps.) But you could consider drbd as a network protocol and implement your own server which speaks the protocol. Then you can add any functionality you like, just like the case with the proprietary rephub server you mentioned in your patch. So the only difference is that instead of using a new custom protocol the rephub would need to speak the drbd protocol. Stefan
Re: [Qemu-devel] Support for multiboot images in elf64 (EM_X86_64) format
On Wed, Feb 8, 2012 at 9:53 AM, Goswin von Brederlow goswin-...@web.de wrote: Stefan Hajnoczi stefa...@gmail.com writes: On Sat, Feb 4, 2012 at 5:38 PM, Goswin von Brederlow goswin-...@web.de wrote: Description: Allow 64bit elf binaries in multiboot format This patch allows 64bit elf files with multiboot header to be loaded. The entry point will still be called in 32bit mode and the kernel must switch to 64bit mode on its own. The image and all modules must also be located in the lower 2GB of ram. All the restrictions of a 32bit image still apply. Author: Goswin von Brederlow goswin-...@web.de Last-Updated: 2011-04-08 --- The multiboot specification is 32-bit only. This patch enables a non-standard 64-bit version of multiboot. Have you checked whether GRUB or other multiboot loaders have equivalent functionality? Have you contacted the multiboot specification authors? Not really. The multiboot specification allow for different executable formats as long as the multiboot header is correct. For example you can have an a.out multiboot image. The entry vector specified in the multiboot header is still called in 32bit mode, as per specs. All that changes is that the kvm allows another executable format for loading the image. Actually per mutliboot specs the elf64 image should already be loaded as plain image (which means not neccessarily reloacted to the right address) just like a.out would but kvm doesn't support that. I don't think other loaders support elf64 (yet) unless they support plain images. Frankly I never tried booting a toy kernel on real hardware so there never was the need. Yes, this is why I asked about support in other software. If each bootloader implements a different custom method then it will be a pain to run your binary on real hardware in the future. It's worth at least checking their source first - maybe there is already a similar code path that we can be compatible with, hence making life easier for developers who want to play with 64-bit payloads in multiboot executables. Stefan
Re: [Qemu-devel] [RFC Patch 3/7]Qemu: Cmd block_set_hostcache for dynamic cache change
On Wed, 01 Feb 2012 08:36:41 +0530
Supriya Kannery supri...@linux.vnet.ibm.com wrote:
New command block_set_hostcache added for dynamically changing
host pagecache setting of a block device.
Usage:
block_set_hostcache device option
device = block device
option = on/off
Example:
(qemu) block_set_hostcache ide0-hd0 off
Signed-off-by: Supriya Kannery supri...@linux.vnet.ibm.com
---
block.c | 54 ++
block.h |2 ++
blockdev.c | 26 ++
blockdev.h |2 ++
hmp-commands.hx | 14 ++
qmp-commands.hx | 27 +++
6 files changed, 125 insertions(+)
Index: qemu/block.c
===
--- qemu.orig/block.c
+++ qemu/block.c
@@ -808,6 +808,35 @@ unlink_and_fail:
return ret;
}
+int bdrv_reopen(BlockDriverState *bs, int bdrv_flags)
+{
+BlockDriver *drv = bs-drv;
+int ret = 0, open_flags;
+
+/* Quiesce IO for the given block device */
+qemu_aio_flush();
+ret = bdrv_flush(bs);
+if (ret != 0) {
+qerror_report(QERR_DATA_SYNC_FAILED, bs-device_name);
+return ret;
+}
+open_flags = bs-open_flags;
+bdrv_close(bs);
+
+ret = bdrv_open(bs, bs-filename, bdrv_flags, drv);
+if (ret 0) {
+/* Reopen failed. Try to open with original flags */
+qerror_report(QERR_REOPEN_FILE_FAILED, bs-filename);
OPEN_FILE_FAILED is fine.
+ret = bdrv_open(bs, bs-filename, open_flags, drv);
+if (ret 0) {
+/* Reopen failed with orig and modified flags */
+abort();
+}
+}
+
+return ret;
+}
+
void bdrv_close(BlockDriverState *bs)
{
if (bs-drv) {
@@ -870,6 +899,33 @@ void bdrv_drain_all(void)
}
}
+int bdrv_change_hostcache(BlockDriverState *bs, bool enable_host_cache)
+{
+int bdrv_flags = bs-open_flags;
+
+/* set hostcache flags (without changing WCE/flush bits) */
+if (enable_host_cache) {
+bdrv_flags = ~BDRV_O_NOCACHE;
+} else {
+bdrv_flags |= BDRV_O_NOCACHE;
+}
+
+/* If no change in flags, no need to reopen */
+if (bdrv_flags == bs-open_flags) {
+return 0;
+}
+
+if (bdrv_is_inserted(bs)) {
+/* Reopen file with changed set of flags */
+bdrv_flags = ~BDRV_O_CACHE_WB;
+return bdrv_reopen(bs, bdrv_flags);
+} else {
+/* Save hostcache change for future use */
+bs-open_flags = bdrv_flags;
+return 0;
+}
+}
+
/* make a BlockDriverState anonymous by removing from bdrv_state list.
Also, NULL terminate the device_name to prevent double remove */
void bdrv_make_anon(BlockDriverState *bs)
Index: qemu/block.h
===
--- qemu.orig/block.h
+++ qemu/block.h
@@ -119,6 +119,7 @@ int bdrv_parse_cache_flags(const char *m
int bdrv_file_open(BlockDriverState **pbs, const char *filename, int flags);
int bdrv_open(BlockDriverState *bs, const char *filename, int flags,
BlockDriver *drv);
+int bdrv_reopen(BlockDriverState *bs, int bdrv_flags);
void bdrv_close(BlockDriverState *bs);
int bdrv_attach_dev(BlockDriverState *bs, void *dev);
void bdrv_attach_dev_nofail(BlockDriverState *bs, void *dev);
@@ -160,6 +161,7 @@ void bdrv_commit_all(void);
int bdrv_change_backing_file(BlockDriverState *bs,
const char *backing_file, const char *backing_fmt);
void bdrv_register(BlockDriver *bdrv);
+int bdrv_change_hostcache(BlockDriverState *bs, bool enable_host_cache);
typedef struct BdrvCheckResult {
Index: qemu/blockdev.c
===
--- qemu.orig/blockdev.c
+++ qemu/blockdev.c
@@ -1080,3 +1080,29 @@ BlockJobInfoList *qmp_query_block_jobs(E
bdrv_iterate(do_qmp_query_block_jobs_one, prev);
return dummy.next;
}
+
+
+/*
+ * Change host page cache setting while guest is running.
+*/
+int do_block_set_hostcache(Monitor *mon, const QDict *qdict,
+ QObject **ret_data)
This is not a QAPI command, please read docs/writing-qmp-commands.txt to know
how to write QMP commands using the QAPI.
+{
+BlockDriverState *bs = NULL;
+int enable;
+const char *device;
+
+/* Validate device */
+device = qdict_get_str(qdict, device);
+bs = bdrv_find(device);
+if (!bs) {
+qerror_report(QERR_DEVICE_NOT_FOUND, device);
+return -1;
+}
+
+/* Read hostcache setting */
+enable = qdict_get_bool(qdict, option);
+return bdrv_change_hostcache(bs, enable);
+
+}
+
Index: qemu/blockdev.h
===
--- qemu.orig/blockdev.h
+++ qemu/blockdev.h
@@ -62,4 +62,6 @@ void qmp_change_blockdev(const char
Re: [Qemu-devel] [RFC PATCH] replication agent module
On 02/07/2012 04:05 PM, Paolo Bonzini wrote: On 02/07/2012 02:50 PM, Stefan Hajnoczi wrote: I guess we might need to attach multiple QMP monitors for this to work (one for libvirt, one for the rephub). I'm not sure if there is a fundamental problem with this or if it just needs to be done. Agreed. You can already query block devices using QMP 'query-block'. By adding in-process NBD server support you could then launch an NBD server for each volume which you wish to replicate. However, in this case it sounds almost like you want the reverse - you could provide an NBD server on the rephub and QEMU would mirror writes to it (the NBD client code is already in QEMU). Yes, this is how we were also planning to do migration without shared storage, right? We originally planned to run ISCSI target . But now that NBD can handle a file chain we can use it too. Paolo
[Qemu-devel] [PATCH] vnc: lift modifier keys on client disconnect.
For any modifier key (shift, ctrl, alt) still pressed on disconnect
inject a key-up event into the guest. The vnc client is gone, it will
not do that, so qemu has to do it instead.
Without this keys will get stuck, making the guest act in weird ways
after reconnecting. Reproducer: exit vnc client via Alt-F4, guest
continues to see the pressed alt key and will not react to key events
in any useful way until you tap the alt key once to unstuck it.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
ui/vnc.c | 25 +
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/ui/vnc.c b/ui/vnc.c
index 83a9b15..02b71bc 100644
--- a/ui/vnc.c
+++ b/ui/vnc.c
@@ -46,6 +46,7 @@ static VncDisplay *vnc_display; /* needed for info vnc */
static DisplayChangeListener *dcl;
static int vnc_cursor_define(VncState *vs);
+static void vnc_release_modifiers(VncState *vs);
static void vnc_set_share_mode(VncState *vs, VncShareMode mode)
{
@@ -1051,6 +1052,7 @@ static void vnc_disconnect_finish(VncState *vs)
vnc_sasl_client_cleanup(vs);
#endif /* CONFIG_VNC_SASL */
audio_del(vs);
+vnc_release_modifiers(vs);
QTAILQ_REMOVE(vs-vd-clients, vs, next);
@@ -1679,6 +1681,29 @@ static void do_key_event(VncState *vs, int down, int
keycode, int sym)
}
}
+static void vnc_release_modifiers(VncState *vs)
+{
+static const int keycodes[] = {
+/* shift, control, alt keys, both left right */
+0x2a, 0x36, 0x1d, 0x9d, 0x38, 0xb8,
+};
+int i, keycode;
+
+if (!is_graphic_console()) {
+return;
+}
+for (i = 0; i ARRAY_SIZE(keycodes); i++) {
+keycode = keycodes[i];
+if (!vs-modifiers_state[keycode]) {
+continue;
+}
+if (keycode SCANCODE_GREY) {
+kbd_put_keycode(SCANCODE_EMUL0);
+}
+kbd_put_keycode(keycode | SCANCODE_UP);
+}
+}
+
static void key_event(VncState *vs, int down, uint32_t sym)
{
int keycode;
--
1.7.1
Re: [Qemu-devel] [RFC PATCH] arm boot: added QOM device definition
2012/2/8 Paul Brook p...@codesourcery.com I suspect we want to replace the arm_load_kernel call with an arm_linux_loader device with appropriate properties. Ok, so does this mean the machine model would still explicitly instantiate the bootloader device? Yes. Bootloaders inherently have machine specific knowledge. They need to know ram location, board ID, secondary CPU boot protocols, etc. Requiring the user specify all these things separately from the rest of the machine description is IMO not acceptable. So what im suggesting here is that machines export these properties to a globally accessible location. Perhaps via the machine opts mechanism? Then we are in a best of both worls situation where machine models do not need bootloader awareness yet bootloaders can still query qemu for ram_size, smp#, board_id and friends. Hmm, I suppose this might work. I'm not sure what you think the benefit of this is though. Fact is the machine needs to have bootloader awareness, whether it be instantating an object or setting magic variables. Having devices rummage around in global state feels messy. I'd much rather use actual properties on the device. IMO changing the bootloader is similar complexity to (say) changing a UART. i.e. it's a board-level change not an end-user level change. Board-level changes are something that will happen after QOM conversion, i.e. when we replace machine-init with a board config file. Paul
Re: [Qemu-devel] [PATCH v2 06/27] qom: add QObject-based property get/set wrappers
On Tue, 07 Feb 2012 10:12:34 +0100 Paolo Bonzini pbonz...@redhat.com wrote: On 02/06/2012 03:16 PM, Anthony Liguori wrote: Move the creation of QmpInputVisitor and QmpOutputVisitor from qmp.c to qom/object.c, since it's the only practical way to access object properties. Signed-off-by: Paolo Bonzinipbonz...@redhat.com Reluctantly-Reviewed-by: Anthony Liguori aligu...@us.ibm.com Fair enough, thanks very much. :) As long as we keep this isolated such that it's easy to remove. At some point, we need to remove all usage of QObject in the tree and replace it with GVariant. Agreed, we'll revisit after Luiz completes QAPI. Commands are not far away. Events are still missing, although they could be converted along with the introduction of GVariant.
Re: [Qemu-devel] [RFC PATCH] replication agent module
On 02/07/2012 04:45 PM, Ori Mamluk wrote: On 07/02/2012 15:34, Kevin Wolf wrote: Am 07.02.2012 11:29, schrieb Ori Mamluk: Repagent is a new module that allows an external replication system to replicate a volume of a Qemu VM. This RFC patch adds the repagent client module to Qemu. Documentation of the module role and API is in the patch at replication/qemu-repagent.txt The main motivation behind the module is to allow replication of VMs in a virtualization environment like RhevM. To achieve this we need basic replication support in Qemu. This is the first submission of this module, which was written as a Proof Of Concept, and used successfully for replicating and recovering a Qemu VM. I'll mostly ignore the code for now and just comment on the design. That's fine. The code was mainly for my understanding of the system. One thing to consider for the next version of the RFC would be to split this in a series smaller patches. This one has become quite large, which makes it hard to review (and yes, please use git send-email). Points and open issues: * The module interfaces the Qemu storage stack at block.c generic layer. Is this the right place to intercept/inject IOs? There are two ways to intercept I/O requests. The first one is what you chose, just add some code to bdrv_co_do_writev, and I think it's reasonable to do this. The other one would be to add a special block driver for a replication: protocol that writes to two different places (the real block driver for the image, and the network connection). Generally this feels even a bit more elegant, but it brings new problems with it: For example, when you create an external snapshot, you need to pay attention not to lose the replication because the protocol is somewhere in the middle of a backing file chain. Yes. With this solution we'll have to somehow make sure that the replication driver is closer to the guest than any driver which alters the IO. * The patch contains performing IO reads invoked by a new thread (a TCP listener thread). See repaget_read_vol in repagent.c. It is not protected by any lock – is this OK? No, definitely not. Block layer code expects that it holds qemu_global_mutex. I'm not sure if a thread is the right solution. You should probably use something that resembles other asynchronous code in qemu, i.e. either callback or coroutine based. I call bdrv_aio_readv - which in my understanding creates a co-routing, so my current solution is co-routines based. Did I get something wrong? * VM ID – the replication system implies an environment with several VMs connected to a central replication system (Rephub). This requires some sort of identification for a VM. The current patch does not include a VM ID – I did not find any adequate ID to use. The replication hub already opened a connection to the VM, so it somehow managed to know which VM this process represents, right? The current design has the server at the Rephub side, so the VM connects to the Rephub, and not the other way around. The VM could be instructed to enable protection by a monitor command, and then it connects to the 'known' Rephub. The unique ID would be something like the PID of the VM or the file descriptor of the communication channel to it. The PID might be useful - we'll later need to correlate it to the way Rhevm identifies the machine, but not right now... diff --git a/Makefile b/Makefile index 4f6eaa4..a1b3701 100644 --- a/Makefile +++ b/Makefile @@ -149,9 +149,9 @@ qemu-img.o qemu-tool.o qemu-nbd.o qemu-io.o cmd.o qemu-ga.o: $(GENERATED_HEADERS tools-obj-y = qemu-tool.o $(oslib-obj-y) $(trace-obj-y) \ qemu-timer-common.o cutils.o -qemu-img$(EXESUF): qemu-img.o $(tools-obj-y) $(block-obj-y) -qemu-nbd$(EXESUF): qemu-nbd.o $(tools-obj-y) $(block-obj-y) -qemu-io$(EXESUF): qemu-io.o cmd.o $(tools-obj-y) $(block-obj-y) +qemu-img$(EXESUF): qemu-img.o $(tools-obj-y) $(block-obj-y) $(replication-obj-y) +qemu-nbd$(EXESUF): qemu-nbd.o $(tools-obj-y) $(block-obj-y) $(replication-obj-y) +qemu-io$(EXESUF): qemu-io.o cmd.o $(tools-obj-y) $(block-obj-y) $(replication-obj-y) $(replication-obj-y) should be included in $(block-obj-y) instead @@ -2733,6 +2739,7 @@ echo curl support $curl echo check support $check_utests echo mingw32 support $mingw32 echo Audio drivers $audio_drv_list +echo Replication $replication echo Extra audio cards $audio_card_list echo Block whitelist $block_drv_whitelist echo Mixer emulation $mixemu Why do you add it in the middle rather than at the end? No reason, I'll change it. diff --git a/replication/qemu-repagent.txt b/replication/qemu-repagent.txt new file mode 100755 index 000..e3b0c1e --- /dev/null +++ b/replication/qemu-repagent.txt @@ -0,0 +1,104 @@ + repagent - replication agent - a Qemu module
Re: [Qemu-devel] [RFC PATCH v2 2/4] cadence_ttc: initial version of device model
- When are interrupts raised. You mention a user specified match value. Do we also get an interrupt on wraparound? Yes, an interrupts occur on wrap around of the 16 bit timer value. There are three match registers which correspond to three more (separately maskable) interrupts which are risen when the timer crosses that value. My implementation will figure out which of the three events (or the wraparound) will occur next, and one shot the corresponding period of time. Note that a match can occur an raise an interrupt without a wrap or reset occuring. E.G. i could set my timer counting up from 0 and when the value hits BEEF, i get an interrupt, but the timer still counts all the way to before wrapping. Ok. I'd missed that there are 3 matches per timer. If you've got independent wrap and match events then I guess yes, a periodic wrap plus a oneshot match event is probably appropriate. Yes this is the case. I will look into making it happen. It's probably not worth using ptimer at all. Instead use QEMUTimer/qemu_mod_timer directly. The trick is to call qemu_get_clock_ns when the timer is started and calculate all deadlines incrementally from that, not from the time when the last timeout happened to fire. See ptimer.c:ptimer_reload/tick or stellaris.c:gptm_reload/tick for examples. ptimer.c provides a common implementation of a simple periodic timer. Previously we had a dozen different implementations, most of which were broken in one way or annother. For more complicated devices you need to know what you're doing anyway :-) Paul
Re: [Qemu-devel] [RFC PATCH] arm boot: added QOM device definition
On 08.02.2012, at 13:27, Paul Brook wrote: 2012/2/8 Paul Brook p...@codesourcery.com I suspect we want to replace the arm_load_kernel call with an arm_linux_loader device with appropriate properties. Ok, so does this mean the machine model would still explicitly instantiate the bootloader device? Yes. Bootloaders inherently have machine specific knowledge. They need to know ram location, board ID, secondary CPU boot protocols, etc. Requiring the user specify all these things separately from the rest of the machine description is IMO not acceptable. So what im suggesting here is that machines export these properties to a globally accessible location. Perhaps via the machine opts mechanism? Then we are in a best of both worls situation where machine models do not need bootloader awareness yet bootloaders can still query qemu for ram_size, smp#, board_id and friends. Hmm, I suppose this might work. I'm not sure what you think the benefit of this is though. Fact is the machine needs to have bootloader awareness, whether it be instantating an object or setting magic variables. Having devices rummage around in global state feels messy. I'd much rather use actual properties on the device. IMO changing the bootloader is similar complexity to (say) changing a UART. i.e. it's a board-level change not an end-user level change. Board-level changes are something that will happen after QOM conversion, i.e. when we replace machine-init with a board config file. Yeah, basically the variable flow goes: vl.c - machine_opts - machine_init() - device properties - device_init() So that the machine init function that creates the bootloader device enumerates the machine_opts (just like is done in Peter's patches) and then passes those on to the bootloader device as device properties. The rationale behind machine opts is that they're basically a dynamic number of properties for the not-yet-existing machine object. Alex
Re: [Qemu-devel] Restore consistent formatting
malc, Arbitrarily reformatting your files is not okay. If you want a different formatting, you need to fix checkpatch.pl first to not error on that formatting in your files. And please post your patches to the mailing list. Thanks, Andreas Am 08.02.2012 11:11, schrieb Evgeny Voevodin: The last commit Restore consistent formatting (cf4dc461a4cfc3e056ee24edb26154f4d34a6278) which is on the master but absent in mailing list results in such output of checkpatch.pl: ./scripts/checkpatch.pl --no-tree --file hw/cs4231a.c ... total: 107 errors, 88 warnings, 696 lines checked - ./scripts/checkpatch.pl --no-tree --file hw/adlib.c ... total: 7 errors, 58 warnings, 337 lines checked - ./scripts/checkpatch.pl --no-tree --file hw/ac97.c ... total: 16 errors, 324 warnings, 1380 lines checked and so on. -- 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 PATCH v2 2/4] cadence_ttc: initial version of device model
2012/2/8 Paul Brook p...@codesourcery.com - When are interrupts raised. You mention a user specified match value. Do we also get an interrupt on wraparound? Yes, an interrupts occur on wrap around of the 16 bit timer value. There are three match registers which correspond to three more (separately maskable) interrupts which are risen when the timer crosses that value. My implementation will figure out which of the three events (or the wraparound) will occur next, and one shot the corresponding period of time. Note that a match can occur an raise an interrupt without a wrap or reset occuring. E.G. i could set my timer counting up from 0 and when the value hits BEEF, i get an interrupt, but the timer still counts all the way to before wrapping. Ok. I'd missed that there are 3 matches per timer. If you've got independent wrap and match events then I guess yes, a periodic wrap plus a oneshot match event is probably appropriate. Yes this is the case. I will look into making it happen. It's probably not worth using ptimer at all. Instead use QEMUTimer/qemu_mod_timer directly. The trick is to call qemu_get_clock_ns when the timer is started and calculate all deadlines incrementally from that, not from the time when the last timeout happened to fire. See ptimer.c:ptimer_reload/tick or stellaris.c:gptm_reload/tick for examples. ptimer.c provides a common implementation of a simple periodic timer. Previously we had a dozen different implementations, most of which were broken in one way or annother. For more complicated devices you need to know what you're doing anyway :-) Ok, this would lead to a more minimal change then :). Just replace ptimer with QEMUTimer and stick with the incremental deadlines approach which is pretty much the code is as it stands. Paul Peter
[Qemu-devel] [PATCH] build: allow turning off debuginfo
This patch adds --{enable,disable}-debug-info switches to configure
which allows to include/exclude the '-g' switch on the gcc ld
command lines. Not building debug info reduces ressource usage
(especially disk) alot and is quite useful for test builds.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
configure | 15 +--
1 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/configure b/configure
index 763db24..8e46600 100755
--- a/configure
+++ b/configure
@@ -98,6 +98,7 @@ audio_pt_int=
audio_win_int=
cc_i386=i386-pc-linux-gnu-gcc
libs_qga=
+debug_info=yes
target_list=
@@ -207,6 +208,10 @@ for opt do
;;
--extra-ldflags=*) LDFLAGS=$optarg $LDFLAGS
;;
+ --enable-debug-info) debug_info=yes
+ ;;
+ --disable-debug-info) debug_info=no
+ ;;
--sparc_cpu=*)
sparc_cpu=$optarg
case $sparc_cpu in
@@ -244,13 +249,15 @@ sdl_config=${SDL_CONFIG-${cross_prefix}sdl-config}
# default flags for all hosts
QEMU_CFLAGS=-fno-strict-aliasing $QEMU_CFLAGS
-CFLAGS=-g $CFLAGS
QEMU_CFLAGS=-Wall -Wundef -Wwrite-strings -Wmissing-prototypes $QEMU_CFLAGS
QEMU_CFLAGS=-Wstrict-prototypes -Wredundant-decls $QEMU_CFLAGS
QEMU_CFLAGS=-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
$QEMU_CFLAGS
QEMU_CFLAGS=-D_FORTIFY_SOURCE=2 $QEMU_CFLAGS
QEMU_INCLUDES=-I. -I\$(SRC_PATH) -I\$(SRC_PATH)/fpu
-LDFLAGS=-g $LDFLAGS
+if test $debug_info = yes; then
+CFLAGS=-g $CFLAGS
+LDFLAGS=-g $LDFLAGS
+fi
# make source path absolute
source_path=`cd $source_path; pwd`
@@ -545,6 +552,10 @@ for opt do
;;
--extra-ldflags=*)
;;
+ --enable-debug-info)
+ ;;
+ --disable-debug-info)
+ ;;
--cpu=*)
;;
--target-list=*) target_list=$optarg
--
1.7.1
[Qemu-devel] [RFC] Replication agent requirements (was [RFC PATCH] replication agent module)
Hi, Following previous mails from Kevin and Dor, I'd like to specify the high level requirements of a replication agent as I see them. 1. Report each write to a protected volume to the rephub, at an IO transaction granularity * The reporting is not synchronous, i.e. the write completion is not delayed until the rephub received it. * The IOs have to be the raw guest IOs - i.e. not converted to any sparse format or another filter that alters the size/offset 2. Report failures to report an IO (e.g. socket disconnect or send timeout) or failed IOs (bad status from storage) to rephub * It is enough to disconnect the socket - that can be considered a 'failure report' 3. Enable rephub to read arbitrary regions in the protected volume * Assume that rephub can identify IOs which were dropped by the replication system, and needs to re-read the data of these IOs. We'd like to treat the following requirement as a second stage - not to implement it in the first version: 4. Synchronously report IO writes meta data (offset, size) to an external API * Synchronous meaning that it is reported (blocking) before the IO is processed by storage. * The goal is to maintain a dirty bitmap outside of the Qemu process * The tracking needs to be more persistent than the Qemu process. A good example for that is to expose an additional process API (yet another NBD??) that will be hold the bitmap by either the host RAM or by writing persistently to storage. The emphasis to report single IO transactions is because high end replication (near synchronous) requires access to every IO shortly after it is written to the storage. Thanks, Ori
Re: [Qemu-devel] [RFC PATCH] arm boot: added QOM device definition
On Wed, Feb 8, 2012 at 10:41 PM, Alexander Graf ag...@suse.de wrote: On 08.02.2012, at 13:27, Paul Brook wrote: 2012/2/8 Paul Brook p...@codesourcery.com I suspect we want to replace the arm_load_kernel call with an arm_linux_loader device with appropriate properties. Ok, so does this mean the machine model would still explicitly instantiate the bootloader device? Yes. Bootloaders inherently have machine specific knowledge. They need to know ram location, board ID, secondary CPU boot protocols, etc. Requiring the user specify all these things separately from the rest of the machine description is IMO not acceptable. So what im suggesting here is that machines export these properties to a globally accessible location. Perhaps via the machine opts mechanism? Then we are in a best of both worls situation where machine models do not need bootloader awareness yet bootloaders can still query qemu for ram_size, smp#, board_id and friends. Hmm, I suppose this might work. I'm not sure what you think the benefit of this is though. Fact is the machine needs to have bootloader awareness, whether it be instantating an object or setting magic variables. Having devices rummage around in global state feels messy. I'd much rather use actual properties on the device. IMO changing the bootloader is similar complexity to (say) changing a UART. i.e. it's a board-level change not an end-user level change. Board-level changes are something that will happen after QOM conversion, i.e. when we replace machine-init with a board config file. Yeah, basically the variable flow goes: vl.c - machine_opts - machine_init() - device properties - device_init() So that the machine init function that creates the bootloader device enumerates the machine_opts (just like is done in Peter's patches) and then passes those on to the bootloader device as device properties. So in patch 4/4 in Peters series where he adds a new bootloader feature (the -dtb switch) its done slightly differently, the machine model does not handle the machine_opts at all, i.e. The machine model has no awareness of this dtb argument. Instead the arm boot loader directly queries the machine_opts API itself: @@ -251,6 +317,9 @@ void arm_load_kernel(CPUState *env, struct arm_boot_info *info) exit(1); } +info-dtb_filename = qemu_opt_get(qemu_opts_find( qemu_find_opts(machine), + 0), dtb); + There is no path through the machine_init for this particular property. What I am suggesting is that a similar approach is take for machine model set properties (such as ram_size), but instead of the command line setting the props its done by the machine model. The machine model qemu_opt_set() the ram_size = whatever. Then the bootloader qemu_opt_get()s it. If you did this for the key properties related to boot then you would remove the need for machines to have awareness of their boot process. The rationale behind machine opts is that they're basically a dynamic number of properties for the not-yet-existing machine object. Alex
Re: [Qemu-devel] [Qemu-ppc] Emulating AmigaOS 4.0
On 08.02.2012, at 14:00, Davide Calaminici wrote: Hello, just would like to know if with QEMU is possible to emulate AmigaOS 4.0 (powerPC 440 embedded processor). Emulating the CPU shouldn't be too bad, but I'm fairly sure we don't emulate the bootstrap and board model. If you have machine specs, it should certainly be doable though. Patches are welcome :). Alex
Re: [Qemu-devel] [RFC PATCH] arm boot: added QOM device definition
On 08.02.2012, at 14:04, Peter Crosthwaite wrote: On Wed, Feb 8, 2012 at 10:41 PM, Alexander Graf ag...@suse.de wrote: On 08.02.2012, at 13:27, Paul Brook wrote: 2012/2/8 Paul Brook p...@codesourcery.com I suspect we want to replace the arm_load_kernel call with an arm_linux_loader device with appropriate properties. Ok, so does this mean the machine model would still explicitly instantiate the bootloader device? Yes. Bootloaders inherently have machine specific knowledge. They need to know ram location, board ID, secondary CPU boot protocols, etc. Requiring the user specify all these things separately from the rest of the machine description is IMO not acceptable. So what im suggesting here is that machines export these properties to a globally accessible location. Perhaps via the machine opts mechanism? Then we are in a best of both worls situation where machine models do not need bootloader awareness yet bootloaders can still query qemu for ram_size, smp#, board_id and friends. Hmm, I suppose this might work. I'm not sure what you think the benefit of this is though. Fact is the machine needs to have bootloader awareness, whether it be instantating an object or setting magic variables. Having devices rummage around in global state feels messy. I'd much rather use actual properties on the device. IMO changing the bootloader is similar complexity to (say) changing a UART. i.e. it's a board-level change not an end-user level change. Board-level changes are something that will happen after QOM conversion, i.e. when we replace machine-init with a board config file. Yeah, basically the variable flow goes: vl.c - machine_opts - machine_init() - device properties - device_init() So that the machine init function that creates the bootloader device enumerates the machine_opts (just like is done in Peter's patches) and then passes those on to the bootloader device as device properties. So in patch 4/4 in Peters series where he adds a new bootloader feature (the -dtb switch) its done slightly differently, the machine model does not handle the machine_opts at all, i.e. The machine model has no awareness of this dtb argument. Instead the arm boot loader directly queries the machine_opts API itself: @@ -251,6 +317,9 @@ void arm_load_kernel(CPUState *env, struct arm_boot_info *info) exit(1); } +info-dtb_filename = qemu_opt_get(qemu_opts_find(qemu_find_opts(machine), + 0), dtb); + There is no path through the machine_init for this particular property. Ah, I see. So he derived from the original proposal, oh well :). What I am suggesting is that a similar approach is take for machine model set properties (such as ram_size), but instead of the command line setting the props its done by the machine model. The machine model qemu_opt_set() the ram_size = whatever. Then the bootloader qemu_opt_get()s it. If you did this for the key properties related to boot then you would remove the need for machines to have awareness of their boot process. But that's exactly what we want. We want the machine to be aware of its boot process, because that's the one place that needs to instantiate the boot device, no? Alex
Re: [Qemu-devel] [RFC PATCH] replication agent module
On 02/08/2012 01:03 PM, Stefan Hajnoczi wrote: If you intend to run an unmodified drbd server on the rephub, then it may not be possible to get point-in-time backups. (Although this probably depends since things like btrfs or zfs may allow you to get back to arbitrary transactions or timestamps.) I'm not sure what's the overhead, but btrfs copy-on-write (reflinks) may help. But you could consider drbd as a network protocol and implement your own server which speaks the protocol. Then you can add any functionality you like, just like the case with the proprietary rephub server you mentioned in your patch. So the only difference is that instead of using a new custom protocol the rephub would need to speak the drbd protocol. So you're suggesting DRBD-over-NBD on the client, and for the replication hub a custom server speaking the DRBD protocol? I didn't find any documentation for DRBD and the code is only in the kernel, so this sounds like a lot of work. What about taking the existing Ceph/RBD driver in QEMU and changing it to support arbitrary image formats rather than just raw? That sounds much much easier. The main advantage is that Ceph has a user-space library for use in the replication hub. It also supports snapshots. Paolo
Re: [Qemu-devel] [PATCH] rewrite QEMU_BUILD_BUG_ON
Am 20.12.2011 10:03, schrieb Dong Xu Wang: From: Dong Xu Wang wdon...@linux.vnet.ibm.com On some platforms, __LINE__ will not expand to real number in QEMU_BUILD_BUG_ON, so if using QEMU_BUILD_BUG_ON twice, compiler will report errors. This patch will fix it. BTW, I got error message on RHEL 6.1/gcc 4.4.5. Signed-off-by: Dong Xu Wang wdon...@linux.vnet.ibm.com Thanks, applied to the block branch. Kevin
Re: [Qemu-devel] [PATCH v2 0/8] qemu-ga: add support for Windows
On Wed, Feb 08, 2012 at 09:18:24AM +0200, Gleb Natapov wrote: On Tue, Feb 07, 2012 at 07:35:34PM -0500, Kevin O'Connor wrote: I'm concerned about the VGA passthrough case. (I know that's not common and has other issues, but I also know several people have been working with it.) As near as I can tell, running the VGA rom on S3 resume has as much chance of breaking things as helping things. It's fine for the cirrus/bochsvga vgaroms that are totally under our control, but it'd be an open guess for any third-party code. (Again, if someone has documentation to the contrary please let me know.) VGA passthrough does not work with QEMU without code changes. Whoever works on it will have to provide etc/s3-resume-vga-init file with appropriate value. My patch above does not remove run time selection, it only changes the default. True. I view running the vgabios on s3 a hack and think an explicit please apply hack flag is nicer than the inverse. However, it's clear this hack helps the majority of qemu/kvm users. So, I'm okay with changing the default. It is a change of default though (upstream kvm/qemu has never run the vgabios on s3 resume before). So, we need to make sure there's proper notice of the change and assuming no objection I'll go forward with it. -Kevin
Re: [Qemu-devel] [Qemu-ppc] [PATCH] PPC64: Add support for ldbrx and stdbrx instructions
Am Wed, 8 Feb 2012 21:48:40 +1100 schrieb David Gibson da...@gibson.dropbear.id.au: On Wed, Feb 08, 2012 at 10:54:21AM +0400, malc wrote: On Wed, 8 Feb 2012, David Gibson wrote: From: Thomas Huth th...@linux.vnet.ibm.com These instructions for loading and storing byte-swapped 64-bit values have been introduced in PowerISA 2.06. Signed-off-by: Thomas Huth th...@linux.vnet.ibm.com --- target-ppc/translate.c | 30 ++ 1 files changed, 30 insertions(+), 0 deletions(-) I seem to recall that POWER5 machine i had access to didn't have ld/stdbrx while CBE did have it (or was it the other way around?) so question is - is PPC_64B sufficient? Ah, I think it's not. I think I spotted that before, but then forgot about it. Thanks for the reminder. Maybe it's a better idea to use PPC_64BX here? ... but that flag seems to be missing in POWERPC_INSNS_POWER7... David, could PPC_64BX also be included in that flag list? Thomas
Re: [Qemu-devel] [RFC] Replication agent design (was [RFC PATCH] replication agent module)
Hi, Thanks for all the valuable inputs provided so far, I'll try to suggest a design based on them. The main inputs were about the use a new transport protocol between repagent and rephub. It was suggested to use some standard network storage protocol instead, and use QMP commands for the control path. The main idea is to use two NBD connections per protected volume: NBD tap - protected VM is the client, rephub is the server, used to report writes. The tap is not a standard NBD backing - it is for replication, meaning that its importance is lesser than the main image path. Errors are not reported to the protected VM as IO error. NBD reader - protected VM is the server, rephub is the client, used for reading the protected volume. The NBD reader is a generic remote read (can add also write) capability, probably usable for other various needs. Actually the reader will probably be more useful as a reader/writer, but for the agent - only read is required. Here's a list of the protocol messages from the previous design and how they're implemented in this design: Rephub -- Repagent: * Start protect Will be done via QMP command. * Read volume request Covered by NBD reader Repagent -- Rephub * Protected write Covered by NBD tap * Report VM volumes Isn't required in the protocol. I assume the management system tracks the volumes * Read Volume Response Covered by NBD tap * Agent shutdown Not covered. The start protect scenario will look something like: * User calls start protect for a volume * Mgmt system (e.g. Rhev) sends QMP command to VM - start protect, with volume details (path) and a IP+port number for NBD tap -- Qemu connects to the NBD tap server * Mgmt system sends QMP command to VM - start remote reader with volume details and port number for NBD reader. -- Qemu starts to listen as an NBD server on that port Issues: * As far as I understand, NBD requires socket/port per volume, which the management system allocates. This is a little cumbersome The original design had a single server in the rephub - a single port allocation, and a socket per Qemu. Appreciate any comments and ideas. Thanks, Ori
Re: [Qemu-devel] [RFC PATCH] arm boot: added QOM device definition
On Wed, Feb 8, 2012 at 11:10 PM, Alexander Graf ag...@suse.de wrote: On 08.02.2012, at 14:04, Peter Crosthwaite wrote: On Wed, Feb 8, 2012 at 10:41 PM, Alexander Graf ag...@suse.de wrote: On 08.02.2012, at 13:27, Paul Brook wrote: 2012/2/8 Paul Brook p...@codesourcery.com I suspect we want to replace the arm_load_kernel call with an arm_linux_loader device with appropriate properties. Ok, so does this mean the machine model would still explicitly instantiate the bootloader device? Yes. Bootloaders inherently have machine specific knowledge. They need to know ram location, board ID, secondary CPU boot protocols, etc. Requiring the user specify all these things separately from the rest of the machine description is IMO not acceptable. So what im suggesting here is that machines export these properties to a globally accessible location. Perhaps via the machine opts mechanism? Then we are in a best of both worls situation where machine models do not need bootloader awareness yet bootloaders can still query qemu for ram_size, smp#, board_id and friends. Hmm, I suppose this might work. I'm not sure what you think the benefit of this is though. Fact is the machine needs to have bootloader awareness, whether it be instantating an object or setting magic variables. Having devices rummage around in global state feels messy. I'd much rather use actual properties on the device. IMO changing the bootloader is similar complexity to (say) changing a UART. i.e. it's a board-level change not an end-user level change. Board-level changes are something that will happen after QOM conversion, i.e. when we replace machine-init with a board config file. Yeah, basically the variable flow goes: vl.c - machine_opts - machine_init() - device properties - device_init() So that the machine init function that creates the bootloader device enumerates the machine_opts (just like is done in Peter's patches) and then passes those on to the bootloader device as device properties. So in patch 4/4 in Peters series where he adds a new bootloader feature (the -dtb switch) its done slightly differently, the machine model does not handle the machine_opts at all, i.e. The machine model has no awareness of this dtb argument. Instead the arm boot loader directly queries the machine_opts API itself: @@ -251,6 +317,9 @@ void arm_load_kernel(CPUState *env, struct arm_boot_info *info) exit(1); } +info-dtb_filename = qemu_opt_get(qemu_opts_find( qemu_find_opts(machine), + 0), dtb); + There is no path through the machine_init for this particular property. Ah, I see. So he derived from the original proposal, oh well :). Isn't this the best approach tho? If you changed it over to the other flow, then you would end up with a change pattern where every machine model would need to get and pass the new argument. This way the diff is limited to the command line infrastructure and the bootloader. What I am suggesting is that a similar approach is take for machine model set properties (such as ram_size), but instead of the command line setting the props its done by the machine model. The machine model qemu_opt_set() the ram_size = whatever. Then the bootloader qemu_opt_get()s it. If you did this for the key properties related to boot then you would remove the need for machines to have awareness of their boot process. But that's exactly what we want. We want the machine to be aware of its boot process, because that's the one place that needs to instantiate the boot device, no? More a case of the reverse isnt it? The bootloader needs to know about the machine its generating code for, but the machine generation process doesnt need to know about the software its going to run. The machine being aware of the bootloader implementation and instantiating it you are putting in place a policy where you forcing a particular bootflow on every user of that machine. The hardware is placing policy on what software its running. In the case of arm boot you end up with a situation where you are trying to write a bootloader that can handle every possible scenario, what I am suggesting is arm_boot.c as it is becomes a linux specific bootloader and other bootflows such as booting from elfs or raw images (or other unforseen bootflows) are different bootloader devices. The choice of which bootloader you use is driven by which -device you put down on command line. Alex Peter
Re: [Qemu-devel] [RFC] Replication agent requirements (was [RFC PATCH] replication agent module)
On 02/08/2012 07:00 AM, Ori Mamluk wrote: Hi, Following previous mails from Kevin and Dor, I'd like to specify the high level requirements of a replication agent as I see them. 1. Report each write to a protected volume to the rephub, at an IO transaction granularity * The reporting is not synchronous, i.e. the write completion is not delayed until the rephub received it. * The IOs have to be the raw guest IOs - i.e. not converted to any sparse format or another filter that alters the size/offset For now. I'm sure you'll eventually have a synchronous replication requirement. We're doomed to reinvent all of the Linux storage layer it seems. I think we really only have two choices: make better use of kernel facilities for this (like drbd) or have a proper, pluggable, storage interface so that QEMU proper doesn't have to deal with all of this. Gluster is appealing as a pluggable storage interface although the license is problematic for us today. I'm quite confident that we shouldn't be in the business of replicating storage though. If the answer is NBD++, that's fine too. Regards, Anthony Liguori
[Qemu-devel] [PATCH] server: support IPV6 addresses in channel events sent to qemu
RHBZ #788444
CC: Gerd Hoffmann kra...@redhat.com
Signed-off-by: Gerd Hoffmann kra...@redhat.com
Signed-off-by: Yonit Halperin yhalp...@redhat.com
---
server/reds.c | 21 +
server/spice.h |6 ++
2 files changed, 23 insertions(+), 4 deletions(-)
diff --git a/server/reds.c b/server/reds.c
index 2492a89..828ba65 100644
--- a/server/reds.c
+++ b/server/reds.c
@@ -2005,7 +2005,7 @@ static void reds_get_spice_ticket(RedLinkInfo *link)
#if HAVE_SASL
static char *addr_to_string(const char *format,
-struct sockaddr *sa,
+struct sockaddr_storage *sa,
socklen_t salen) {
char *addr;
char host[NI_MAXHOST];
@@ -2013,7 +2013,7 @@ static char *addr_to_string(const char *format,
int err;
size_t addrlen;
-if ((err = getnameinfo(sa, salen,
+if ((err = getnameinfo((struct sockaddr *)sa, salen,
host, sizeof(host),
serv, sizeof(serv),
NI_NUMERICHOST | NI_NUMERICSERV)) != 0) {
@@ -2402,11 +2402,13 @@ static void reds_start_auth_sasl(RedLinkInfo *link)
RedsSASL *sasl = link-stream-sasl;
/* Get local remote client addresses in form IPADDR;PORT */
-if (!(localAddr = addr_to_string(%s;%s, link-stream-info.laddr,
link-stream-info.llen))) {
+if (!(localAddr = addr_to_string(%s;%s, link-stream-info.laddr_ext,
+ link-stream-info.llen_ext))) {
goto error;
}
-if (!(remoteAddr = addr_to_string(%s;%s, link-stream-info.paddr,
link-stream-info.plen))) {
+if (!(remoteAddr = addr_to_string(%s;%s, link-stream-info.paddr_ext,
+ link-stream-info.plen_ext))) {
free(localAddr);
goto error;
}
@@ -2717,10 +2719,21 @@ static RedLinkInfo *reds_init_client_connection(int
socket)
stream-socket = socket;
/* gather info + send event */
+
+/* deprecated fields. Filling them for backward compatibility */
stream-info.llen = sizeof(stream-info.laddr);
stream-info.plen = sizeof(stream-info.paddr);
getsockname(stream-socket, (struct sockaddr*)(stream-info.laddr),
stream-info.llen);
getpeername(stream-socket, (struct sockaddr*)(stream-info.paddr),
stream-info.plen);
+
+stream-info.flags |= SPICE_CHANNEL_EVENT_FLAG_ADDR_EXT;
+stream-info.llen_ext = sizeof(stream-info.laddr_ext);
+stream-info.plen_ext = sizeof(stream-info.paddr_ext);
+getsockname(stream-socket, (struct sockaddr*)(stream-info.laddr_ext),
+stream-info.llen_ext);
+getpeername(stream-socket, (struct sockaddr*)(stream-info.paddr_ext),
+stream-info.plen_ext);
+
reds_stream_channel_event(stream, SPICE_CHANNEL_EVENT_CONNECTED);
openssl_init(link);
diff --git a/server/spice.h b/server/spice.h
index c582e6c..7397655 100644
--- a/server/spice.h
+++ b/server/spice.h
@@ -54,6 +54,7 @@ typedef struct SpiceCoreInterface SpiceCoreInterface;
#define SPICE_CHANNEL_EVENT_DISCONNECTED 3
#define SPICE_CHANNEL_EVENT_FLAG_TLS (1 0)
+#define SPICE_CHANNEL_EVENT_FLAG_ADDR_EXT (1 1)
typedef struct SpiceWatch SpiceWatch;
typedef void (*SpiceWatchFunc)(int fd, int event, void *opaque);
@@ -66,9 +67,14 @@ typedef struct SpiceChannelEventInfo {
int type;
int id;
int flags;
+/* deprecated, can't hold ipv6 addresses, kept for backward compatibility
*/
struct sockaddr laddr;
struct sockaddr paddr;
socklen_t llen, plen;
+/* should be used if (flags SPICE_CHANNEL_EVENT_FLAG_ADDR_EXT) */
+struct sockaddr_storage laddr_ext;
+struct sockaddr_storage paddr_ext;
+socklen_t llen_ext, plen_ext;
} SpiceChannelEventInfo;
struct SpiceCoreInterface {
--
1.7.7.6
[Qemu-devel] [PATCH] spice: support ipv6 channel address in monitor events and in spice info
RHBZ #788444
CC: Gerd Hoffmann kra...@redhat.com
Signed-off-by: Yonit Halperin yhalp...@redhat.com
---
ui/spice-core.c | 37 -
1 files changed, 32 insertions(+), 5 deletions(-)
diff --git a/ui/spice-core.c b/ui/spice-core.c
index 5639c6f..60fd6c3 100644
--- a/ui/spice-core.c
+++ b/ui/spice-core.c
@@ -220,10 +220,23 @@ static void channel_event(int event,
SpiceChannelEventInfo *info)
}
client = qdict_new();
-add_addr_info(client, info-paddr, info-plen);
-
server = qdict_new();
-add_addr_info(server, info-laddr, info-llen);
+
+#ifdef SPICE_CHANNEL_EVENT_FLAG_ADDR_EXT
+if (info-flags SPICE_CHANNEL_EVENT_FLAG_ADDR_EXT) {
+add_addr_info(client, (struct sockaddr *)info-paddr_ext,
+ info-plen_ext);
+add_addr_info(server, (struct sockaddr *)info-laddr_ext,
+ info-llen_ext);
+} else {
+fprintf(stderr, spice: %s, extended address is expected\n,
+__func__);
+#endif
+add_addr_info(client, info-paddr, info-plen);
+add_addr_info(server, info-laddr, info-llen);
+#ifdef SPICE_CHANNEL_EVENT_FLAG_ADDR_EXT
+}
+#endif
if (event == SPICE_CHANNEL_EVENT_INITIALIZED) {
qdict_put(server, auth, qstring_from_str(auth));
@@ -376,16 +389,30 @@ static SpiceChannelList *qmp_query_spice_channels(void)
QTAILQ_FOREACH(item, channel_list, link) {
SpiceChannelList *chan;
char host[NI_MAXHOST], port[NI_MAXSERV];
+struct sockaddr *paddr;
+socklen_t plen;
chan = g_malloc0(sizeof(*chan));
chan-value = g_malloc0(sizeof(*chan-value));
-getnameinfo(item-info-paddr, item-info-plen,
+#ifdef SPICE_CHANNEL_EVENT_FLAG_ADDR_EXT
+if (item-info-flags SPICE_CHANNEL_EVENT_FLAG_ADDR_EXT) {
+paddr = (struct sockaddr *)item-info-paddr_ext;
+plen = item-info-plen_ext;
+} else {
+#endif
+paddr = item-info-paddr;
+plen = item-info-plen;
+#ifdef SPICE_CHANNEL_EVENT_FLAG_ADDR_EXT
+}
+#endif
+
+getnameinfo(paddr, plen,
host, sizeof(host), port, sizeof(port),
NI_NUMERICHOST | NI_NUMERICSERV);
chan-value-host = g_strdup(host);
chan-value-port = g_strdup(port);
-chan-value-family =
g_strdup(inet_strfamily(item-info-paddr.sa_family));
+chan-value-family = g_strdup(inet_strfamily(paddr-sa_family));
chan-value-connection_id = item-info-connection_id;
chan-value-channel_type = item-info-type;
--
1.7.7.6
Re: [Qemu-devel] [RFC PATCH] arm boot: added QOM device definition
On 02/08/2012 01:55 AM, Peter A. G. Crosthwaite wrote:
From: Peter A. G. Crosthwaitepeter.crosthwa...@petalogix.com
Create a QOM device for bootstrapping linux on arm. Wraps the existing
arm_boot code and calls arm_load_kernel() at device init. Allows booting
of linux without -kernel -initrd -append arguments. The main drawback is
the boardid now has to be specified as there is no API for querying the
machine model for that. The code also assumes it is booting on first_cpu.
Added an automatic detection for the machine ram size so that ram size can
be detected by the bootloader without needing to get the value from either
the command line or machine model
Signed-off-by: Peter A. G. Crosthwaitepeter.crosthwa...@petalogix.com
---
Makefile.objs|1 +
hw/arm-misc.h| 10
hw/arm_boot.c| 59 ++
hw/versatilepb.c | 14 +++-
4 files changed, 73 insertions(+), 11 deletions(-)
diff --git a/Makefile.objs b/Makefile.objs
index ec35320..c397aa7 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -189,6 +189,7 @@ user-obj-y += $(trace-obj-y)
hw-obj-y =
hw-obj-y += vl.o loader.o
+hw-obj-y += image-loader.o
hw-obj-$(CONFIG_VIRTIO) += virtio-console.o
hw-obj-y += usb-libhw.o
hw-obj-$(CONFIG_VIRTIO_PCI) += virtio-pci.o
diff --git a/hw/arm-misc.h b/hw/arm-misc.h
index 5e5204b..754d8bd 100644
--- a/hw/arm-misc.h
+++ b/hw/arm-misc.h
@@ -25,10 +25,10 @@ qemu_irq *armv7m_init(MemoryRegion *address_space_mem,
/* arm_boot.c */
struct arm_boot_info {
-int ram_size;
-const char *kernel_filename;
-const char *kernel_cmdline;
-const char *initrd_filename;
+uint32_t ram_size;
+char *kernel_filename;
+char *kernel_cmdline;
+char *initrd_filename;
target_phys_addr_t loader_start;
/* multicore boards that use the default secondary core boot functions
* need to put the address of the secondary boot code, the boot reg,
@@ -39,7 +39,7 @@ struct arm_boot_info {
target_phys_addr_t smp_bootreg_addr;
target_phys_addr_t smp_priv_base;
int nb_cpus;
-int board_id;
+uint32_t board_id;
int (*atag_board)(const struct arm_boot_info *info, void *p);
/* multicore boards that use the default secondary core boot functions
* can ignore these two function calls. If the default functions won't
diff --git a/hw/arm_boot.c b/hw/arm_boot.c
index 5f163fd..1f028f4 100644
--- a/hw/arm_boot.c
+++ b/hw/arm_boot.c
@@ -12,6 +12,9 @@
#include sysemu.h
#include loader.h
#include elf.h
+#include qdev.h
+#include exec-memory.h
+
#define KERNEL_ARGS_ADDR 0x100
#define KERNEL_LOAD_ADDR 0x0001
@@ -245,6 +248,20 @@ void arm_load_kernel(CPUState *env, struct arm_boot_info
*info)
target_phys_addr_t entry;
int big_endian;
+if (!env) {
+env = first_cpu;
+}
+
+if (!info-ram_size) {
+MemoryRegion *sysmem = get_system_memory();
+MemoryRegion *ram = memory_region_find(sysmem, 0, 4).mr;
+if (!ram) {
+fprintf(stderr, Ram size not specified and autodetect failed\n);
+exit(1);
+}
+info-ram_size = memory_region_size(ram);
+}
+
/* Load the kernel. */
if (!info-kernel_filename) {
fprintf(stderr, Kernel image must be specified\n);
@@ -321,3 +338,45 @@ void arm_load_kernel(CPUState *env, struct arm_boot_info
*info)
qemu_register_reset(do_cpu_reset, env);
}
}
+
+struct ArmBoot {
+DeviceState qdev;
+struct arm_boot_info info;
+};
+
+static int arm_boot_init(DeviceState *dev)
+{
+struct ArmBoot *s = (struct ArmBoot *)dev;
+arm_load_kernel(NULL,s-info);
+return 0;
+}
+
+static Property arm_boot_properties [] = {
+DEFINE_PROP_UINT32(boardid, struct ArmBoot, info.board_id, 0),
+DEFINE_PROP_STRING(initrd, struct ArmBoot, info.initrd_filename),
+DEFINE_PROP_STRING(kernel, struct ArmBoot, info.kernel_filename),
+DEFINE_PROP_STRING(cmdline, struct ArmBoot, info.kernel_cmdline),
+DEFINE_PROP_END_OF_LIST(),
+};
+
+static void arm_boot_class_init(ObjectClass *klass, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(klass);
+
+dc-init = arm_boot_init;
+dc-props = arm_boot_properties;
+}
+
+static TypeInfo arm_boot_info_ = {
Please don't leave a trailing _ on the end.
+.name = arm_linux_loader,
+.parent= TYPE_DEVICE,
+.class_init= arm_boot_class_init,
+.instance_size = sizeof(struct ArmBoot),
+};
+
+static void arm_boot_register(void)
+{
+type_register_static(arm_boot_info_);
+}
+
+device_init(arm_boot_register)
Why have a separate arm_boot_info instead of folding the fields into ArmBoot?
Regards,
Anthony Liguori
diff --git a/hw/versatilepb.c b/hw/versatilepb.c
index 6e28e78..e42d845 100644
--- a/hw/versatilepb.c
+++ b/hw/versatilepb.c
@@ -313,12 +313,14 @@ static void versatile_init(ram_addr_t ram_size,
/*
Re: [Qemu-devel] [RFC PATCH] arm boot: added QOM device definition
On 02/08/2012 06:41 AM, Alexander Graf wrote: On 08.02.2012, at 13:27, Paul Brook wrote: 2012/2/8 Paul Brookp...@codesourcery.com I suspect we want to replace the arm_load_kernel call with an arm_linux_loader device with appropriate properties. Ok, so does this mean the machine model would still explicitly instantiate the bootloader device? Yes. Bootloaders inherently have machine specific knowledge. They need to know ram location, board ID, secondary CPU boot protocols, etc. Requiring the user specify all these things separately from the rest of the machine description is IMO not acceptable. So what im suggesting here is that machines export these properties to a globally accessible location. Perhaps via the machine opts mechanism? Then we are in a best of both worls situation where machine models do not need bootloader awareness yet bootloaders can still query qemu for ram_size, smp#, board_id and friends. Hmm, I suppose this might work. I'm not sure what you think the benefit of this is though. Fact is the machine needs to have bootloader awareness, whether it be instantating an object or setting magic variables. Having devices rummage around in global state feels messy. I'd much rather use actual properties on the device. IMO changing the bootloader is similar complexity to (say) changing a UART. i.e. it's a board-level change not an end-user level change. Board-level changes are something that will happen after QOM conversion, i.e. when we replace machine-init with a board config file. Yeah, basically the variable flow goes: vl.c - machine_opts - machine_init() - device properties - device_init() And the rationale is that machine_init() will do nothing other than use QOM primitives to create a set of expected devices and set up their properties such that a person (or management tool) could do everything that machine_init() is doing. Down the road, we'll introduce a -no-machine property that will not run machine_init() at all. The reason to use machine_opts instead of a global is that we have mechanisms to query the existence of machine_opts, display inline help, introspect them in a running QEMU instance, etc. So that the machine init function that creates the bootloader device enumerates the machine_opts (just like is done in Peter's patches) and then passes those on to the bootloader device as device properties. The rationale behind machine opts is that they're basically a dynamic number of properties for the not-yet-existing machine object. Yes, we could also model machine_init() as an object, but in general, it should strictly be a super object that composes together other objects and forwards properties. We don't want any actually logic to live in the machines. Regards. Anthony Liguori Alex
Re: [Qemu-devel] [RFC PATCH] arm boot: added QOM device definition
On Wed, Feb 8, 2012 at 11:35 PM, Alexander Graf ag...@suse.de wrote: On 08.02.2012, at 14:30, Peter Crosthwaite wrote: On Wed, Feb 8, 2012 at 11:10 PM, Alexander Graf ag...@suse.de wrote: On 08.02.2012, at 14:04, Peter Crosthwaite wrote: On Wed, Feb 8, 2012 at 10:41 PM, Alexander Graf ag...@suse.de wrote: On 08.02.2012, at 13:27, Paul Brook wrote: 2012/2/8 Paul Brook p...@codesourcery.com I suspect we want to replace the arm_load_kernel call with an arm_linux_loader device with appropriate properties. Ok, so does this mean the machine model would still explicitly instantiate the bootloader device? Yes. Bootloaders inherently have machine specific knowledge. They need to know ram location, board ID, secondary CPU boot protocols, etc. Requiring the user specify all these things separately from the rest of the machine description is IMO not acceptable. So what im suggesting here is that machines export these properties to a globally accessible location. Perhaps via the machine opts mechanism? Then we are in a best of both worls situation where machine models do not need bootloader awareness yet bootloaders can still query qemu for ram_size, smp#, board_id and friends. Hmm, I suppose this might work. I'm not sure what you think the benefit of this is though. Fact is the machine needs to have bootloader awareness, whether it be instantating an object or setting magic variables. Having devices rummage around in global state feels messy. I'd much rather use actual properties on the device. IMO changing the bootloader is similar complexity to (say) changing a UART. i.e. it's a board-level change not an end-user level change. Board-level changes are something that will happen after QOM conversion, i.e. when we replace machine-init with a board config file. Yeah, basically the variable flow goes: vl.c - machine_opts - machine_init() - device properties - device_init() So that the machine init function that creates the bootloader device enumerates the machine_opts (just like is done in Peter's patches) and then passes those on to the bootloader device as device properties. So in patch 4/4 in Peters series where he adds a new bootloader feature (the -dtb switch) its done slightly differently, the machine model does not handle the machine_opts at all, i.e. The machine model has no awareness of this dtb argument. Instead the arm boot loader directly queries the machine_opts API itself: @@ -251,6 +317,9 @@ void arm_load_kernel(CPUState *env, struct arm_boot_info *info) exit(1); } +info-dtb_filename = qemu_opt_get(qemu_opts_find( qemu_find_opts(machine), + 0), dtb); + There is no path through the machine_init for this particular property. Ah, I see. So he derived from the original proposal, oh well :). Isn't this the best approach tho? If you changed it over to the other flow, then you would end up with a change pattern where every machine model would need to get and pass the new argument. This way the diff is limited to the command line infrastructure and the bootloader. If you want the smallest diff, just make things globals and call it a day. This whole thing is a discussion around device architecture, right? So if we consider this bootloader a device and its -dtb argument a property of that device, then what you are implying is that every device property of every device in a machine must be managed by the machine model? Isn't the dynamic machine model work that is in progress is trying to get away the approach where fixed machine models have to micromanage all their attached devices? with the ultimate goal of -no-machine how will the bootloader get this dtb argument? What I am suggesting is that a similar approach is take for machine model set properties (such as ram_size), but instead of the command line setting the props its done by the machine model. The machine model qemu_opt_set() the ram_size = whatever. Then the bootloader qemu_opt_get()s it. If you did this for the key properties related to boot then you would remove the need for machines to have awareness of their boot process. But that's exactly what we want. We want the machine to be aware of its boot process, because that's the one place that needs to instantiate the boot device, no? More a case of the reverse isnt it? The bootloader needs to know about the machine its generating code for, but the machine generation process doesnt need to know about the software its going to run. The machine being aware of the bootloader implementation and instantiating it you are putting in place a policy where you forcing a particular bootflow on every user of that machine. The hardware is placing policy on what software its running. In the case of arm boot you end up with a situation where you are trying to write a bootloader that can
Re: [Qemu-devel] [RFC PATCH] arm boot: added QOM device definition
On 08.02.2012, at 15:05, Peter Crosthwaite wrote: On Wed, Feb 8, 2012 at 11:35 PM, Alexander Graf ag...@suse.de wrote: On 08.02.2012, at 14:30, Peter Crosthwaite wrote: On Wed, Feb 8, 2012 at 11:10 PM, Alexander Graf ag...@suse.de wrote: On 08.02.2012, at 14:04, Peter Crosthwaite wrote: On Wed, Feb 8, 2012 at 10:41 PM, Alexander Graf ag...@suse.de wrote: On 08.02.2012, at 13:27, Paul Brook wrote: 2012/2/8 Paul Brook p...@codesourcery.com I suspect we want to replace the arm_load_kernel call with an arm_linux_loader device with appropriate properties. Ok, so does this mean the machine model would still explicitly instantiate the bootloader device? Yes. Bootloaders inherently have machine specific knowledge. They need to know ram location, board ID, secondary CPU boot protocols, etc. Requiring the user specify all these things separately from the rest of the machine description is IMO not acceptable. So what im suggesting here is that machines export these properties to a globally accessible location. Perhaps via the machine opts mechanism? Then we are in a best of both worls situation where machine models do not need bootloader awareness yet bootloaders can still query qemu for ram_size, smp#, board_id and friends. Hmm, I suppose this might work. I'm not sure what you think the benefit of this is though. Fact is the machine needs to have bootloader awareness, whether it be instantating an object or setting magic variables. Having devices rummage around in global state feels messy. I'd much rather use actual properties on the device. IMO changing the bootloader is similar complexity to (say) changing a UART. i.e. it's a board-level change not an end-user level change. Board-level changes are something that will happen after QOM conversion, i.e. when we replace machine-init with a board config file. Yeah, basically the variable flow goes: vl.c - machine_opts - machine_init() - device properties - device_init() So that the machine init function that creates the bootloader device enumerates the machine_opts (just like is done in Peter's patches) and then passes those on to the bootloader device as device properties. So in patch 4/4 in Peters series where he adds a new bootloader feature (the -dtb switch) its done slightly differently, the machine model does not handle the machine_opts at all, i.e. The machine model has no awareness of this dtb argument. Instead the arm boot loader directly queries the machine_opts API itself: @@ -251,6 +317,9 @@ void arm_load_kernel(CPUState *env, struct arm_boot_info *info) exit(1); } +info-dtb_filename = qemu_opt_get(qemu_opts_find(qemu_find_opts(machine), + 0), dtb); + There is no path through the machine_init for this particular property. Ah, I see. So he derived from the original proposal, oh well :). Isn't this the best approach tho? If you changed it over to the other flow, then you would end up with a change pattern where every machine model would need to get and pass the new argument. This way the diff is limited to the command line infrastructure and the bootloader. If you want the smallest diff, just make things globals and call it a day. This whole thing is a discussion around device architecture, right? So if we consider this bootloader a device and its -dtb argument a property of that device, then what you are implying is that every device property of every device in a machine must be managed by the machine model? Isn't the dynamic machine model work that is in progress is trying to get away the approach where fixed machine models have to micromanage all their attached devices? with the ultimate goal of -no-machine how will the bootloader get this dtb argument? That is the point really. With a machine model, the machine model creates the device with all its properties (kernel file name, initrd file name, dtb file name) while with -no-machine, you would manually create the bootloader device with -device ...,kernel=..,initrd=... If the device would read machine_opts itself, we couldn't do the -device part. What I am suggesting is that a similar approach is take for machine model set properties (such as ram_size), but instead of the command line setting the props its done by the machine model. The machine model qemu_opt_set() the ram_size = whatever. Then the bootloader qemu_opt_get()s it. If you did this for the key properties related to boot then you would remove the need for machines to have awareness of their boot process. But that's exactly what we want. We want the machine to be aware of its boot process, because that's the one place that needs to instantiate the boot device, no? More a case of the reverse isnt it? The bootloader needs to know about the machine its
Re: [Qemu-devel] [RFC PATCH] arm boot: added QOM device definition
So if we consider this bootloader a device and its -dtb argument a property of that device, then what you are implying is that every device property of every device in a machine must be managed by the machine model? Isn't the dynamic machine model work that is in progress is trying to get away the approach where fixed machine models have to micromanage all their attached devices? with the ultimate goal of -no-machine how will the bootloader get this dtb argument? My expectation is that we have some way for the machine description to tag objects/properties that pap to the generic commandline options. In the same way that we'd probably want to tag the default PCI bus, or UARTs for matching with the -serial commandline. Some of these can be guessed, others you need the machine description to tell you. Paul
Re: [Qemu-devel] [RFC PATCH] arm boot: added QOM device definition
2012/2/9 Paul Brook p...@codesourcery.com So if we consider this bootloader a device and its -dtb argument a property of that device, then what you are implying is that every device property of every device in a machine must be managed by the machine model? Isn't the dynamic machine model work that is in progress is trying to get away the approach where fixed machine models have to micromanage all their attached devices? with the ultimate goal of -no-machine how will the bootloader get this dtb argument? My expectation is that we have some way for the machine description to tag objects/properties that pap to the generic commandline options. In the same way that we'd probably want to tag the default PCI bus, or UARTs for matching with the -serial commandline. Some of these can be guessed, others you need the machine description to tell you. Paul Ok, so it seems that for command line driven arguments the policy is with standard arguments such as -dtb, the machine model must get it on the device behalf and instantiate the device, and that fits in with this patch. Its the other problem I am more worried about, i.e. when I -device instantiate my bootloader with an existing machine how do I get my ram_size and board_ID? The no machine opts for devices policy makes this impossible such that I would have to pass in board_id and ram_size to the boot-loader on the command line. Is there any acceptable way where the machine model can make something globally available to devices for the purpose of instantiating them with -device?
Re: [Qemu-devel] [RFC PATCH] replication agent module
On Wed, Feb 8, 2012 at 12:46 PM, Paolo Bonzini pbonz...@redhat.com wrote: On 02/08/2012 01:03 PM, Stefan Hajnoczi wrote: If you intend to run an unmodified drbd server on the rephub, then it may not be possible to get point-in-time backups. (Although this probably depends since things like btrfs or zfs may allow you to get back to arbitrary transactions or timestamps.) I'm not sure what's the overhead, but btrfs copy-on-write (reflinks) may help. But you could consider drbd as a network protocol and implement your own server which speaks the protocol. Then you can add any functionality you like, just like the case with the proprietary rephub server you mentioned in your patch. So the only difference is that instead of using a new custom protocol the rephub would need to speak the drbd protocol. So you're suggesting DRBD-over-NBD on the client, and for the replication hub a custom server speaking the DRBD protocol? I didn't find any documentation for DRBD and the code is only in the kernel, so this sounds like a lot of work. Adding code to QEMU is definitely the easiest solution. I'm just not sure whether it's the right one if this will evolve to have the same features as drbd. What about taking the existing Ceph/RBD driver in QEMU and changing it to support arbitrary image formats rather than just raw? That sounds much much easier. The main advantage is that Ceph has a user-space library for use in the replication hub. It also supports snapshots. I missed how Ceph/RBD helps. Can you explain how we would use it? Stefan
Re: [Qemu-devel] [RFC Patch 5/7]Qemu: raw-posix image file reopen
Am 01.02.2012 04:07, schrieb Supriya Kannery:
raw-posix driver changes for bdrv_reopen_xx functions to
safely reopen image files. Reopening of image files while
changing hostcache dynamically is handled here.
Signed-off-by: Supriya Kannery supri...@linux.vnet.ibm.com
Index: qemu/block/raw.c
===
--- qemu.orig/block/raw.c
+++ qemu/block/raw.c
@@ -9,6 +9,22 @@ static int raw_open(BlockDriverState *bs
return 0;
}
+static int raw_reopen_prepare(BlockDriverState *bs, BDRVReopenState **prs,
+ int flags)
+{
+return bdrv_reopen_prepare(bs-file, prs, flags);
+}
+
+static void raw_reopen_commit(BlockDriverState *bs, BDRVReopenState *rs)
+{
+bdrv_reopen_commit(bs-file, rs);
+}
+
+static void raw_reopen_abort(BlockDriverState *bs, BDRVReopenState *rs)
+{
+bdrv_reopen_abort(bs-file, rs);
+}
+
static int coroutine_fn raw_co_readv(BlockDriverState *bs, int64_t
sector_num,
int nb_sectors, QEMUIOVector *qiov)
{
@@ -109,6 +125,10 @@ static BlockDriver bdrv_raw = {
.instance_size = 1,
.bdrv_open = raw_open,
+.bdrv_reopen_prepare
+= raw_reopen_prepare,
You can just indent to the next level instead of line wrapping.
+.bdrv_reopen_commit = raw_reopen_commit,
+.bdrv_reopen_abort = raw_reopen_abort,
.bdrv_close = raw_close,
.bdrv_co_readv = raw_co_readv,
Index: qemu/block/raw-posix.c
===
--- qemu.orig/block/raw-posix.c
+++ qemu/block/raw-posix.c
@@ -136,6 +136,11 @@ typedef struct BDRVRawState {
#endif
} BDRVRawState;
+typedef struct BDRVRawReopenState {
+BDRVReopenState reopen_state;
+BDRVRawState *stash_s;
+} BDRVRawReopenState;
See Stefan's comment. If it's possible to save only the fd and maybe one
or two other fields, then we should do that.
static int fd_open(BlockDriverState *bs);
static int64_t raw_getlength(BlockDriverState *bs);
@@ -279,6 +284,71 @@ static int raw_open(BlockDriverState *bs
return raw_open_common(bs, filename, flags, 0);
}
+static int raw_reopen_prepare(BlockDriverState *bs, BDRVReopenState **prs,
+ int flags)
+{
+BDRVRawReopenState *raw_rs = g_malloc0(sizeof(BDRVRawReopenState));
+BDRVRawState *s = bs-opaque;
+int ret = 0;
+
+raw_rs-reopen_state.bs = bs;
+
+/* stash state before reopen */
+raw_rs-stash_s = g_malloc0(sizeof(BDRVRawState));
+memcpy(raw_rs-stash_s, s, sizeof(BDRVRawState));
+s-fd = dup(raw_rs-stash_s-fd);
+
+*prs = (raw_rs-reopen_state);
+
+/* Flags that can be set using fcntl */
+int fcntl_flags = BDRV_O_NOCACHE;
+
+if ((bs-open_flags ~fcntl_flags) == (flags ~fcntl_flags)) {
+if ((flags BDRV_O_NOCACHE)) {
+s-open_flags |= O_DIRECT;
+} else {
+s-open_flags = ~O_DIRECT;
+}
+printf(O_DIRECT flag\n);
Debugging leftover?
+ret = fcntl_setfl(s-fd, s-open_flags);
+} else {
+
+printf(close and open with new flags\n);
Same here.
Kevin
Re: [Qemu-devel] [RFC PATCH] replication agent module
On 02/08/2012 03:39 PM, Stefan Hajnoczi wrote: What about taking the existing Ceph/RBD driver in QEMU and changing it to support arbitrary image formats rather than just raw? That sounds much much easier. The main advantage is that Ceph has a user-space library for use in the replication hub. It also supports snapshots. I missed how Ceph/RBD helps. Can you explain how we would use it? Ceph supports replication, you would just put images in a Ceph store rather than in a normal filesystem. Paolo
Re: [Qemu-devel] [RFC PATCH] arm boot: added QOM device definition
Its the other problem I am more worried about, i.e. when I -device instantiate my bootloader with an existing machine how do I get my ram_size and board_ID? The no machine opts for devices policy makes this impossible such that I would have to pass in board_id and ram_size to the boot-loader on the command line. Is there any acceptable way where the machine model can make something globally available to devices for the purpose of instantiating them with -device? I'm not convinved this is a problem worth solving. i.e. is it really worth consirering the bootloader a user-replaceable part of the machine (without actually changing the machine description)? Making our bootloader not suck seems a better option. Paul
Re: [Qemu-devel] [RFC] Replication agent design (was [RFC PATCH] replication agent module)
On Wed, Feb 8, 2012 at 1:28 PM, Ori Mamluk omam...@zerto.com wrote: Hi, Thanks for all the valuable inputs provided so far, I'll try to suggest a design based on them. The main inputs were about the use a new transport protocol between repagent and rephub. It was suggested to use some standard network storage protocol instead, and use QMP commands for the control path. The main idea is to use two NBD connections per protected volume: NBD tap - protected VM is the client, rephub is the server, used to report writes. The tap is not a standard NBD backing - it is for replication, meaning that its importance is lesser than the main image path. Errors are not reported to the protected VM as IO error. You mentioned a future feature that sends request metadata (offset, length) to the rephub synchronously so that protection is 100%. (Otherwise a network failure or crash might result in missed writes that the rephub does not know about.) The NBD tap might not be the right channel for sending synchronous request metadata, since the protocol is geared towards block I/O requests that include the actual data. I'm not sure that QMP should be used either - even though we have the concept of QMP events - because it's not a low-latency, high ops communications channel. Which channel do you use in your existing products for synchronous request metadata? Stefan
Re: [Qemu-devel] [RFC] Replication agent design (was [RFC PATCH] replication agent module)
On Wed, Feb 8, 2012 at 2:59 PM, Stefan Hajnoczi stefa...@gmail.com wrote: On Wed, Feb 8, 2012 at 1:28 PM, Ori Mamluk omam...@zerto.com wrote: Hi, Thanks for all the valuable inputs provided so far, I'll try to suggest a design based on them. The main inputs were about the use a new transport protocol between repagent and rephub. It was suggested to use some standard network storage protocol instead, and use QMP commands for the control path. The main idea is to use two NBD connections per protected volume: NBD tap - protected VM is the client, rephub is the server, used to report writes. The tap is not a standard NBD backing - it is for replication, meaning that its importance is lesser than the main image path. Errors are not reported to the protected VM as IO error. You mentioned a future feature that sends request metadata (offset, length) to the rephub synchronously so that protection is 100%. (Otherwise a network failure or crash might result in missed writes that the rephub does not know about.) The NBD tap might not be the right channel for sending synchronous request metadata, since the protocol is geared towards block I/O requests that include the actual data. I'm not sure that QMP should be used either - even though we have the concept of QMP events - because it's not a low-latency, high ops communications channel. Which channel do you use in your existing products for synchronous request metadata? BTW, your design makes sense to me. Stefan
Re: [Qemu-devel] [RFC Patch 6/7]Qemu: raw-win32 image file reopen
Am 01.02.2012 04:07, schrieb Supriya Kannery:
win32 driver changes for bdrv_reopen_xx functions to
safely reopen image files. Reopening of image files while
changing hostcache dynamically is handled here.
Signed-off-by: Supriya Kannery supri...@linux.vnet.ibm.com
Index: qemu/block/raw-win32.c
===
--- qemu.orig/block/raw-win32.c
+++ qemu/block/raw-win32.c
@@ -26,18 +26,27 @@
#include block_int.h
#include module.h
#include windows.h
+#include winbase.h
#include winioctl.h
#define FTYPE_FILE 0
#define FTYPE_CD 1
#define FTYPE_HARDDISK 2
+#define WINDOWS_VISTA 6
typedef struct BDRVRawState {
HANDLE hfile;
int type;
char drive_path[16]; /* format: d:\ */
+DWORD overlapped;
} BDRVRawState;
+typedef struct BDRVRawReopenState {
+BDRVReopenState reopen_state;
+HANDLE stash_hfile;
+DWORD stash_overlapped;
+} BDRVRawReopenState;
+
int qemu_ftruncate64(int fd, int64_t length)
{
LARGE_INTEGER li;
@@ -106,9 +115,96 @@ static int raw_open(BlockDriverState *bs
return -EACCES;
return -1;
}
+s-overlapped = overlapped;
return 0;
}
+static int raw_reopen_prepare(BlockDriverState *bs, BDRVReopenState **prs,
+ int flags)
+{
+BDRVRawReopenState *raw_rs = g_malloc0(sizeof(BDRVRawReopenState));
+BDRVRawState *s = bs-opaque;
+int ret = 0;
+OSVERSIONINFO osvi;
+BOOL bIsWindowsVistaorLater;
+
+raw_rs-bs = bs;
+raw_rs-stash_hfile = s-hfile;
+raw_rs-stash_overlapped = s-overlapped;
+*prs = raw_rs;
+
+if (flags BDRV_O_NOCACHE) {
+s-overlapped |= FILE_FLAG_NO_BUFFERING;
+} else {
+s-overlapped = ~FILE_FLAG_NO_BUFFERING;
+}
+
+if (!(flags BDRV_O_CACHE_WB)) {
+s-overlapped |= FILE_FLAG_WRITE_THROUGH;
+} else {
+s-overlapped = ~FILE_FLAG_WRITE_THROUGH;
+}
+
+ZeroMemory(osvi, sizeof(OSVERSIONINFO));
+osvi.dwOSVersionInfoSize = sizeof(OSVERSIONINFO);
+
+GetVersionEx(osvi);
+
+if (osvi.dwMajorVersion = WINDOWS_VISTA) {
+s-hfile = ReOpenFile(raw_rs-stash_hfile, 0, FILE_SHARE_READ,
+ overlapped);
+if (s-hfile == INVALID_HANDLE_VALUE) {
+int err = GetLastError();
+if (err == ERROR_ACCESS_DENIED) {
+ret = -EACCES;
+} else {
+ret = -1;
Returning -1 where -errno is expected is bad (turns out as -EPERM on
Linux, which is misleading). Maybe -EIO here.
Kevin
[Qemu-devel] [PATCH v2] nic: zap obsolote romloading bits from ne2k + pcnet
These days one just needs to specify the romfile in PCiDeviceInfo and
everything magically works. It also allows to disable pxe rom loading
via romfile=emptystring like it is possible for all other nics.
[ v2: rebased adapted to qom changes ]
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
hw/ne2000.c|9 +
hw/pcnet-pci.c |9 +
2 files changed, 2 insertions(+), 16 deletions(-)
diff --git a/hw/ne2000.c b/hw/ne2000.c
index 080811e..c4b574d 100644
--- a/hw/ne2000.c
+++ b/hw/ne2000.c
@@ -763,14 +763,6 @@ static int pci_ne2000_init(PCIDevice *pci_dev)
object_get_typename(OBJECT(pci_dev)),
pci_dev-qdev.id, s);
qemu_format_nic_info_str(s-nic-nc, s-c.macaddr.a);
-if (!pci_dev-qdev.hotplugged) {
-static int loaded = 0;
-if (!loaded) {
-rom_add_option(pxe-ne2k_pci.rom, -1);
-loaded = 1;
-}
-}
-
add_boot_device_path(s-c.bootindex, pci_dev-qdev, /ethernet-phy@0);
return 0;
@@ -798,6 +790,7 @@ static void ne2000_class_init(ObjectClass *klass, void
*data)
k-init = pci_ne2000_init;
k-exit = pci_ne2000_exit;
+k-romfile = pxe-ne2k_pci.rom,
k-vendor_id = PCI_VENDOR_ID_REALTEK;
k-device_id = PCI_DEVICE_ID_REALTEK_8029;
k-class_id = PCI_CLASS_NETWORK_ETHERNET;
diff --git a/hw/pcnet-pci.c b/hw/pcnet-pci.c
index 439f32c..6f4755d 100644
--- a/hw/pcnet-pci.c
+++ b/hw/pcnet-pci.c
@@ -330,14 +330,6 @@ static int pci_pcnet_init(PCIDevice *pci_dev)
s-phys_mem_write = pci_physical_memory_write;
s-dma_opaque = pci_dev;
-if (!pci_dev-qdev.hotplugged) {
-static int loaded = 0;
-if (!loaded) {
-rom_add_option(pxe-pcnet.rom, -1);
-loaded = 1;
-}
-}
-
return pcnet_common_init(pci_dev-qdev, s, net_pci_pcnet_info);
}
@@ -360,6 +352,7 @@ static void pcnet_class_init(ObjectClass *klass, void *data)
k-init = pci_pcnet_init;
k-exit = pci_pcnet_uninit;
+k-romfile = pxe-pcnet.rom,
k-vendor_id = PCI_VENDOR_ID_AMD;
k-device_id = PCI_DEVICE_ID_AMD_LANCE;
k-revision = 0x10;
--
1.7.1
Re: [Qemu-devel] [RFC Patch 4/7]Qemu: Framework for reopening image files safely
Am 01.02.2012 04:06, schrieb Supriya Kannery:
Struct BDRVReopenState along with three reopen related functions
introduced for handling reopening of images safely. This can be
extended by each of the block drivers to reopen respective
image files.
Signed-off-by: Supriya Kannery supri...@linux.vnet.ibm.com
Index: qemu/block.c
===
--- qemu.orig/block.c
+++ qemu/block.c
@@ -808,10 +808,32 @@ unlink_and_fail:
return ret;
}
+int bdrv_reopen_prepare(BlockDriverState *bs, BDRVReopenState **prs, int
flags)
+{
+ BlockDriver *drv = bs-drv;
+
+ return drv-bdrv_reopen_prepare(bs, prs, flags);
+}
+
+void bdrv_reopen_commit(BlockDriverState *bs, BDRVReopenState *rs)
+{
+BlockDriver *drv = bs-drv;
+
+drv-bdrv_reopen_commit(bs, rs);
+}
+
+void bdrv_reopen_abort(BlockDriverState *bs, BDRVReopenState *rs)
+{
+BlockDriver *drv = bs-drv;
+
+drv-bdrv_reopen_abort(bs, rs);
+}
+
int bdrv_reopen(BlockDriverState *bs, int bdrv_flags)
{
BlockDriver *drv = bs-drv;
int ret = 0, open_flags;
+BDRVReopenState *reopen_state = NULL;
/* Quiesce IO for the given block device */
qemu_aio_flush();
@@ -820,17 +842,32 @@ int bdrv_reopen(BlockDriverState *bs, in
qerror_report(QERR_DATA_SYNC_FAILED, bs-device_name);
return ret;
}
-open_flags = bs-open_flags;
-bdrv_close(bs);
-ret = bdrv_open(bs, bs-filename, bdrv_flags, drv);
-if (ret 0) {
-/* Reopen failed. Try to open with original flags */
-qerror_report(QERR_REOPEN_FILE_FAILED, bs-filename);
-ret = bdrv_open(bs, bs-filename, open_flags, drv);
+/* Use driver specific reopen() if available */
+if (drv-bdrv_reopen_prepare) {
+ret = bdrv_reopen_prepare(bs, reopen_state, bdrv_flags);
+ if (ret 0) {
+bdrv_reopen_abort(bs, reopen_state);
+qerror_report(QERR_REOPEN_FILE_FAILED, bs-filename);
+return ret;
+}
+
+bdrv_reopen_commit(bs, reopen_state);
+bs-open_flags = bdrv_flags;
+
+} else {
+ open_flags = bs-open_flags;
+ bdrv_close(bs);
+
+ ret = bdrv_open(bs, bs-filename, bdrv_flags, drv);
if (ret 0) {
-/* Reopen failed with orig and modified flags */
-abort();
+/* Reopen failed. Try to open with original flags */
+qerror_report(QERR_REOPEN_FILE_FAILED, bs-filename);
+ret = bdrv_open(bs, bs-filename, open_flags, drv);
+if (ret 0) {
+/* Reopen failed with orig and modified flags */
+bs-drv = NULL;
+}
}
Most image formats don't have a bdrv_reopen_* implementation after this
series, so usually you'll have something like qcow2 on top of file. This
code uses bdrv_close/open for the whole stack, even though the file
layer could actually make use of a bdrv_reopen_* implementation and the
qcow2 open isn't likely to fail if the image file could be opened.
I think we can use drv-bdrv_close/open to reopen only one layer and try
using bdrv_reopen_* for the lower layer again.
This is an improvement that can be done in a separate patch, though.
Kevin
Re: [Qemu-devel] Restore consistent formatting
On Wed, 8 Feb 2012, Andreas F?rber wrote: malc, Arbitrarily reformatting your files is not okay. If you want a different formatting, you need to fix checkpatch.pl first to not error on that formatting in your files. It was always formatter like this (internally consistent), then others added code which made it not so. [..snip..] -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [RFC PATCH] replication agent module
On Wed, Feb 8, 2012 at 2:55 PM, Paolo Bonzini pbonz...@redhat.com wrote: On 02/08/2012 03:39 PM, Stefan Hajnoczi wrote: What about taking the existing Ceph/RBD driver in QEMU and changing it to support arbitrary image formats rather than just raw? That sounds much much easier. The main advantage is that Ceph has a user-space library for use in the replication hub. It also supports snapshots. I missed how Ceph/RBD helps. Can you explain how we would use it? Ceph supports replication, you would just put images in a Ceph store rather than in a normal filesystem. I don't think that meets the need to replicate guest I/Os before they've been sliced and diced by an image format. Stefan
Re: [Qemu-devel] [RFC PATCH] arm boot: added QOM device definition
So here are some of the problems im trying to solve with the bootloader: Smp bootstrap secondary CPUs while loading an elf (currently elfs will be assumed to be not kernels). Change the kernel, initrd and dtb load address on the command line. Use my own SMP secondary bootloop. My intention with this patch was to set myself to do boot parameterizations on the command line by just adding them as qdev props to the arm_linux_loader and set them using -device instantiation. E.G. -device arm_boot_loader,initrd_addr=0x1000. But if I take the approach you are suggesting, the for this initrd load address option, I would need to add myself a command line option, fetch that command line option in every arm machine model and then pass it to arm_load_kernel. The change pattern is huge and is intrusive to every arm machine model. Whereas what I am suggesting would limit changes to only the bootloader device. 2012/2/9 Paul Brook p...@codesourcery.com Its the other problem I am more worried about, i.e. when I -device instantiate my bootloader with an existing machine how do I get my ram_size and board_ID? The no machine opts for devices policy makes this impossible such that I would have to pass in board_id and ram_size to the boot-loader on the command line. Is there any acceptable way where the machine model can make something globally available to devices for the purpose of instantiating them with -device? I'm not convinved this is a problem worth solving. i.e. is it really worth consirering the bootloader a user-replaceable part of the machine (without actually changing the machine description)? Making our bootloader not suck seems a better option. Paul
Re: [Qemu-devel] [PATCH] configure: ignore spice libraries on 32 bit.
On 02/08/12 01:17, Rusty Russell wrote:
As featured on:
https://bugs.launchpad.net/qemu-linaro/+bug/928432
Since we compile with -Werror, the presence of spice headers breaks
compile. Yet except for x86-64, it doesn't compile, doesn't work, isn't
supported. See: http://spice-space.org/faq.html
Outdated. 64bit restrictions are gone, spice server works on 32bit too.
Thats why 32bit spice packages exist in the first place ;)
Attached patch fixes the warnings.
cheers,
Gerd
From a45a8229260d45804fea654fb9b45c35eb454478 Mon Sep 17 00:00:00 2001
From: Gerd Hoffmann kra...@redhat.com
Date: Wed, 8 Feb 2012 15:58:35 +0100
Subject: [PATCH] qxl: fix warnings on 32bit
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
hw/qxl.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/hw/qxl.c b/hw/qxl.c
index 3b5f45a..da7ee1b 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@@ -625,7 +625,7 @@ static void interface_release_resource(QXLInstance *sin,
if (ext.group_id == MEMSLOT_GROUP_HOST) {
/* host group - vga mode update request */
-qemu_spice_destroy_update(qxl-ssd, (void*)ext.info-id);
+qemu_spice_destroy_update(qxl-ssd, (void *)(intptr_t)ext.info-id);
return;
}
@@ -748,7 +748,8 @@ static void interface_async_complete(QXLInstance *sin,
uint64_t cookie)
qxl-current_async = QXL_UNDEFINED_IO;
qemu_mutex_unlock(qxl-async_lock);
-dprint(qxl, 2, async_complete: %d (%ld) done\n, current_async, cookie);
+dprint(qxl, 2, async_complete: %d (% PRId64 ) done\n,
+ current_async, cookie);
switch (current_async) {
case QXL_IO_CREATE_PRIMARY_ASYNC:
qxl_create_guest_primary_complete(qxl);
@@ -1017,7 +1018,7 @@ void *qxl_phys2virt(PCIQXLDevice *qxl, QXLPHYSICAL pqxl,
int group_id)
switch (group_id) {
case MEMSLOT_GROUP_HOST:
-return (void*)offset;
+return (void *)(intptr_t)offset;
case MEMSLOT_GROUP_GUEST:
PANIC_ON(slot = NUM_MEMSLOTS);
PANIC_ON(!qxl-guest_slots[slot].active);
--
1.7.1
Re: [Qemu-devel] Restore consistent formatting
On 02/08/2012 09:04 AM, malc wrote: On Wed, 8 Feb 2012, Andreas F?rber wrote: malc, Arbitrarily reformatting your files is not okay. If you want a different formatting, you need to fix checkpatch.pl first to not error on that formatting in your files. It was always formatter like this (internally consistent), then others added code which made it not so. We do have a mixed style in the audio layer. I'm not happy about that but I also feel strongly that going through and doing a reformat is not a worthwhile exercise. I can also understand the desire to keep things consistent. But patches should always go to the mailing list. I certainly would have acked such a patch FWIW. I think people get a bit too excited about coding style. There are much more important things to worry about in life than the number of spaces before a parenthesis :-) Regards, Anthony Liguori [..snip..]
Re: [Qemu-devel] [PATCH 1/3] Device isolation group infrastructure (v3)
On Wed, Feb 01, 2012 at 03:46:52PM +1100, David Gibson wrote: In order to safely drive a device with a userspace driver, or to pass it through to a guest system, we must first make sure that the device is isolated in such a way that it cannot interfere with other devices on the system. This isolation is only available on some systems and will generally require an iommu, and might require other support in bridges or other system hardware. Often, it's not possible to isolate every device from every other device in the system. For example, certain PCI/PCIe bridge configurations mean that an iommu cannot reliably distinguish which device behind the bridge initiated a DMA transaction. Similarly some buggy PCI multifunction devices initiate all DMAs as function 0, so the functions cannot be isolated from each other, even if the IOMMU normally allows this. Therefore, the user, and code to allow userspace drivers or guest passthrough, needs a way to determine which devices can be isolated from which others. This patch adds infrastructure to handle this by introducing the concept of a device isolation group - a group of devices which can, as a unit, be safely isolated from the rest of the system and therefore can be, as a unit, safely assigned to an unprivileged used or guest. That is, the groups represent the minimum granularity with which devices may be assigned to untrusted components. This code manages groups, but does not create them or allow use of grouped devices by a guest. Creating groups would be done by iommu or bridge drivers, using the interface this patch provides. It's expected that the groups will be used in future by the in-kernel iommu interface, and would also be used by VFIO or other subsystems to allow safe passthrough of devices to userspace or guests. Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru Signed-off-by: David Gibson da...@gibson.dropbear.id.au --- drivers/base/Kconfig |3 + drivers/base/Makefile|1 + drivers/base/base.h |3 + drivers/base/core.c |6 ++ drivers/base/device_isolation.c | 184 ++ drivers/base/init.c |2 + include/linux/device.h |5 + include/linux/device_isolation.h | 100 + Again, device grouping is done by the IOMMU drivers, so this all belongs into the generic iommu-code rather than the driver core. I think it makes sense to introduce a device-iommu pointer which depends on CONFIG_IOMMU_API and put the group information into it. This also has the benefit that we can consolidate all the device-arch.iommu pointers into device-iommu as well. 8 files changed, 304 insertions(+), 0 deletions(-) create mode 100644 drivers/base/device_isolation.c create mode 100644 include/linux/device_isolation.h diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig index 7be9f79..a52f2db 100644 --- a/drivers/base/Kconfig +++ b/drivers/base/Kconfig @@ -189,4 +189,7 @@ config DMA_SHARED_BUFFER APIs extension; the file's descriptor can then be passed on to other driver. +config DEVICE_ISOLATION + bool Enable isolating devices for safe pass-through to guests or user space. + No need for a config option. When IOMMU drivers are enabled we also want the group code to be active. Joerg -- AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers: Alberto Bozzo Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632
[Qemu-devel] [PATCH 05/10] memory: code motion: move MEMORY_LISTENER_CALL()
So it can be used in earlier code.
Signed-off-by: Avi Kivity a...@redhat.com
---
memory.c | 64 +++---
1 files changed, 32 insertions(+), 32 deletions(-)
diff --git a/memory.c b/memory.c
index cb2b4f1..a1013bc 100644
--- a/memory.c
+++ b/memory.c
@@ -82,6 +82,38 @@ static AddrRange addrrange_intersection(AddrRange r1,
AddrRange r2)
return addrrange_make(start, int128_sub(end, start));
}
+enum ListenerDirection { Forward, Reverse };
+
+#define MEMORY_LISTENER_CALL(_callback, _direction, _args...) \
+do {\
+MemoryListener *_listener; \
+\
+switch (_direction) { \
+case Forward: \
+QTAILQ_FOREACH(_listener, memory_listeners, link) {\
+_listener-_callback(_listener, ##_args); \
+} \
+break; \
+case Reverse: \
+QTAILQ_FOREACH_REVERSE(_listener, memory_listeners,\
+ memory_listeners, link) {\
+_listener-_callback(_listener, ##_args); \
+} \
+break; \
+default:\
+abort();\
+} \
+} while (0)
+
+#define MEMORY_LISTENER_UPDATE_REGION(fr, as, dir, callback)\
+MEMORY_LISTENER_CALL(callback, dir, (MemoryRegionSection) {\
+.mr = (fr)-mr, \
+.address_space = (as)-root,\
+.offset_within_region = (fr)-offset_in_region, \
+.size = int128_get64((fr)-addr.size), \
+.offset_within_address_space = int128_get64((fr)-addr.start), \
+})
+
struct CoalescedMemoryRange {
AddrRange addr;
QTAILQ_ENTRY(CoalescedMemoryRange) link;
@@ -678,38 +710,6 @@ static void address_space_update_ioeventfds(AddressSpace
*as)
as-ioeventfd_nb = ioeventfd_nb;
}
-enum ListenerDirection { Forward, Reverse };
-
-#define MEMORY_LISTENER_CALL(_callback, _direction, _args...) \
-do {\
-MemoryListener *_listener; \
-\
-switch (_direction) { \
-case Forward: \
-QTAILQ_FOREACH(_listener, memory_listeners, link) {\
-_listener-_callback(_listener, ##_args); \
-} \
-break; \
-case Reverse: \
-QTAILQ_FOREACH_REVERSE(_listener, memory_listeners,\
- memory_listeners, link) {\
-_listener-_callback(_listener, ##_args); \
-} \
-break; \
-default:\
-abort();\
-} \
-} while (0)
-
-#define MEMORY_LISTENER_UPDATE_REGION(fr, as, dir, callback)\
-MEMORY_LISTENER_CALL(callback, dir, (MemoryRegionSection) {\
-.mr = (fr)-mr, \
-.address_space = (as)-root,\
-.offset_within_region = (fr)-offset_in_region, \
-.size = int128_get64((fr)-addr.size), \
-.offset_within_address_space = int128_get64((fr)-addr.start), \
-})
-
static void address_space_update_topology_pass(AddressSpace *as,
FlatView old_view,
FlatView new_view,
--
1.7.9
[Qemu-devel] [PATCH 04/10] memory: switch memory listeners to a QTAILQ
This allows reverse iteration, which in turns allows consistent ordering
among multiple listeners:
l1-add
l2-add
l2-del
l1-del
Signed-off-by: Avi Kivity a...@redhat.com
---
hw/vhost.c |1 +
kvm-all.c |1 +
memory.c | 70 ++--
memory.h |4 ++-
xen-all.c |1 +
5 files changed, 55 insertions(+), 22 deletions(-)
diff --git a/hw/vhost.c b/hw/vhost.c
index 5ece659..4737145 100644
--- a/hw/vhost.c
+++ b/hw/vhost.c
@@ -751,6 +751,7 @@ int vhost_dev_init(struct vhost_dev *hdev, int devfd, bool
force)
.log_sync = vhost_log_sync,
.log_global_start = vhost_log_global_start,
.log_global_stop = vhost_log_global_stop,
+.priority = 10
};
hdev-mem = g_malloc0(offsetof(struct vhost_memory, regions));
hdev-n_mem_sections = 0;
diff --git a/kvm-all.c b/kvm-all.c
index 0b87658..6835fd4 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -726,6 +726,7 @@ static void kvm_log_global_stop(struct MemoryListener
*listener)
.log_sync = kvm_log_sync,
.log_global_start = kvm_log_global_start,
.log_global_stop = kvm_log_global_stop,
+.priority = 10,
};
static void kvm_handle_interrupt(CPUState *env, int mask)
diff --git a/memory.c b/memory.c
index 6afe414..cb2b4f1 100644
--- a/memory.c
+++ b/memory.c
@@ -27,8 +27,8 @@
static bool memory_region_update_pending = false;
static bool global_dirty_log = false;
-static QLIST_HEAD(, MemoryListener) memory_listeners
-= QLIST_HEAD_INITIALIZER(memory_listeners);
+static QTAILQ_HEAD(memory_listeners, MemoryListener) memory_listeners
+= QTAILQ_HEAD_INITIALIZER(memory_listeners);
typedef struct AddrRange AddrRange;
@@ -678,17 +678,31 @@ static void address_space_update_ioeventfds(AddressSpace
*as)
as-ioeventfd_nb = ioeventfd_nb;
}
-#define MEMORY_LISTENER_CALL(_callback, _args...) \
-do {\
-MemoryListener *_listener; \
-\
-QLIST_FOREACH(_listener, memory_listeners, link) { \
-_listener-_callback(_listener, ##_args); \
-} \
+enum ListenerDirection { Forward, Reverse };
+
+#define MEMORY_LISTENER_CALL(_callback, _direction, _args...) \
+do {\
+MemoryListener *_listener; \
+\
+switch (_direction) { \
+case Forward: \
+QTAILQ_FOREACH(_listener, memory_listeners, link) {\
+_listener-_callback(_listener, ##_args); \
+} \
+break; \
+case Reverse: \
+QTAILQ_FOREACH_REVERSE(_listener, memory_listeners,\
+ memory_listeners, link) {\
+_listener-_callback(_listener, ##_args); \
+} \
+break; \
+default:\
+abort();\
+} \
} while (0)
-#define MEMORY_LISTENER_UPDATE_REGION(fr, as, callback) \
-MEMORY_LISTENER_CALL(callback, (MemoryRegionSection) { \
+#define MEMORY_LISTENER_UPDATE_REGION(fr, as, dir, callback)\
+MEMORY_LISTENER_CALL(callback, dir, (MemoryRegionSection) {\
.mr = (fr)-mr, \
.address_space = (as)-root,\
.offset_within_region = (fr)-offset_in_region, \
@@ -728,7 +742,7 @@ static void address_space_update_topology_pass(AddressSpace
*as,
/* In old, but (not in new, or in new but attributes changed). */
if (!adding) {
-MEMORY_LISTENER_UPDATE_REGION(frold, as, region_del);
+MEMORY_LISTENER_UPDATE_REGION(frold, as, Reverse, region_del);
as-ops-range_del(as, frold);
}
@@ -738,11 +752,11 @@ static void
address_space_update_topology_pass(AddressSpace *as,
if (adding) {
if (frold-dirty_log_mask !frnew-dirty_log_mask) {
-MEMORY_LISTENER_UPDATE_REGION(frnew, as, log_stop);
+
[Qemu-devel] [PATCH 02/10] memory: remove memory_region_set_offset()
memory_region_set_offset() complicates the API, and has been deprecated
since its introduction. Now that it is no longer used, remove it.
Signed-off-by: Avi Kivity a...@redhat.com
---
memory.c | 26 ++
memory.h |9 -
2 files changed, 10 insertions(+), 25 deletions(-)
diff --git a/memory.c b/memory.c
index 5e77d8a..382dded 100644
--- a/memory.c
+++ b/memory.c
@@ -401,17 +401,17 @@ static void memory_region_iorange_read(IORange *iorange,
*data = ((uint64_t)1 (width * 8)) - 1;
if (mrp) {
-*data = mrp-read(mr-opaque, offset + mr-offset);
+*data = mrp-read(mr-opaque, offset);
} else if (width == 2) {
mrp = find_portio(mr, offset, 1, false);
assert(mrp);
-*data = mrp-read(mr-opaque, offset + mr-offset) |
-(mrp-read(mr-opaque, offset + mr-offset + 1) 8);
+*data = mrp-read(mr-opaque, offset) |
+(mrp-read(mr-opaque, offset + 1) 8);
}
return;
}
*data = 0;
-access_with_adjusted_size(offset + mr-offset, data, width,
+access_with_adjusted_size(offset, data, width,
mr-ops-impl.min_access_size,
mr-ops-impl.max_access_size,
memory_region_read_accessor, mr);
@@ -428,16 +428,16 @@ static void memory_region_iorange_write(IORange *iorange,
const MemoryRegionPortio *mrp = find_portio(mr, offset, width, true);
if (mrp) {
-mrp-write(mr-opaque, offset + mr-offset, data);
+mrp-write(mr-opaque, offset, data);
} else if (width == 2) {
mrp = find_portio(mr, offset, 1, false);
assert(mrp);
-mrp-write(mr-opaque, offset + mr-offset, data 0xff);
-mrp-write(mr-opaque, offset + mr-offset + 1, data 8);
+mrp-write(mr-opaque, offset, data 0xff);
+mrp-write(mr-opaque, offset + 1, data 8);
}
return;
}
-access_with_adjusted_size(offset + mr-offset, data, width,
+access_with_adjusted_size(offset, data, width,
mr-ops-impl.min_access_size,
mr-ops-impl.max_access_size,
memory_region_write_accessor, mr);
@@ -863,7 +863,6 @@ void memory_region_init(MemoryRegion *mr,
mr-size = int128_2_64();
}
mr-addr = 0;
-mr-offset = 0;
mr-subpage = false;
mr-enabled = true;
mr-terminates = false;
@@ -925,7 +924,7 @@ static uint64_t memory_region_dispatch_read1(MemoryRegion
*mr,
}
/* FIXME: support unaligned access */
-access_with_adjusted_size(addr + mr-offset, data, size,
+access_with_adjusted_size(addr, data, size,
mr-ops-impl.min_access_size,
mr-ops-impl.max_access_size,
memory_region_read_accessor, mr);
@@ -979,7 +978,7 @@ static void memory_region_dispatch_write(MemoryRegion *mr,
}
/* FIXME: support unaligned access */
-access_with_adjusted_size(addr + mr-offset, data, size,
+access_with_adjusted_size(addr, data, size,
mr-ops-impl.min_access_size,
mr-ops-impl.max_access_size,
memory_region_write_accessor, mr);
@@ -1122,11 +1121,6 @@ bool memory_region_is_rom(MemoryRegion *mr)
return mr-ram mr-readonly;
}
-void memory_region_set_offset(MemoryRegion *mr, target_phys_addr_t offset)
-{
-mr-offset = offset;
-}
-
void memory_region_set_log(MemoryRegion *mr, bool log, unsigned client)
{
uint8_t mask = 1 client;
diff --git a/memory.h b/memory.h
index 4cf8d2f..4763286 100644
--- a/memory.h
+++ b/memory.h
@@ -115,7 +115,6 @@ struct MemoryRegion {
MemoryRegion *parent;
Int128 size;
target_phys_addr_t addr;
-target_phys_addr_t offset;
void (*destructor)(MemoryRegion *mr);
ram_addr_t ram_addr;
IORange iorange;
@@ -359,14 +358,6 @@ bool memory_region_is_rom(MemoryRegion *mr);
void *memory_region_get_ram_ptr(MemoryRegion *mr);
/**
- * memory_region_set_offset: Sets an offset to be added to MemoryRegionOps
- * callbacks.
- *
- * This function is deprecated and should not be used in new code.
- */
-void memory_region_set_offset(MemoryRegion *mr, target_phys_addr_t offset);
-
-/**
* memory_region_set_log: Turn dirty logging on or off for a region.
*
* Turns dirty logging on or off for a specified client (display, migration).
--
1.7.9
[Qemu-devel] [PATCH 06/10] memory: move ioeventfd ops to MemoryListener
This way the accelerator (kvm) can handle them directly.
Signed-off-by: Avi Kivity a...@redhat.com
---
hw/vhost.c | 14 ++
kvm-all.c | 78
memory.c | 74 ++---
memory.h |4 +++
xen-all.c | 14 ++
5 files changed, 128 insertions(+), 56 deletions(-)
diff --git a/hw/vhost.c b/hw/vhost.c
index 4737145..e1e7e01 100644
--- a/hw/vhost.c
+++ b/hw/vhost.c
@@ -720,6 +720,18 @@ static void vhost_virtqueue_cleanup(struct vhost_dev *dev,
0, virtio_queue_get_desc_size(vdev, idx));
}
+static void vhost_eventfd_add(MemoryListener *listener,
+ MemoryRegionSection *section,
+ bool match_data, uint64_t data, int fd)
+{
+}
+
+static void vhost_eventfd_del(MemoryListener *listener,
+ MemoryRegionSection *section,
+ bool match_data, uint64_t data, int fd)
+{
+}
+
int vhost_dev_init(struct vhost_dev *hdev, int devfd, bool force)
{
uint64_t features;
@@ -751,6 +763,8 @@ int vhost_dev_init(struct vhost_dev *hdev, int devfd, bool
force)
.log_sync = vhost_log_sync,
.log_global_start = vhost_log_global_start,
.log_global_stop = vhost_log_global_stop,
+.eventfd_add = vhost_eventfd_add,
+.eventfd_del = vhost_eventfd_del,
.priority = 10
};
hdev-mem = g_malloc0(offsetof(struct vhost_memory, regions));
diff --git a/kvm-all.c b/kvm-all.c
index 6835fd4..a05e591 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -28,6 +28,7 @@
#include kvm.h
#include bswap.h
#include memory.h
+#include exec-memory.h
/* This check must be after config-host.h is included */
#ifdef CONFIG_EVENTFD
@@ -718,6 +719,81 @@ static void kvm_log_global_stop(struct MemoryListener
*listener)
assert(r = 0);
}
+static void kvm_mem_ioeventfd_add(MemoryRegionSection *section,
+ bool match_data, uint64_t data, int fd)
+{
+int r;
+
+assert(match_data section-size == 4);
+
+r = kvm_set_ioeventfd_mmio_long(fd, section-offset_within_address_space,
+data, true);
+if (r 0) {
+abort();
+}
+}
+
+static void kvm_mem_ioeventfd_del(MemoryRegionSection *section,
+ bool match_data, uint64_t data, int fd)
+{
+int r;
+
+r = kvm_set_ioeventfd_mmio_long(fd, section-offset_within_address_space,
+data, false);
+if (r 0) {
+abort();
+}
+}
+
+static void kvm_io_ioeventfd_add(MemoryRegionSection *section,
+ bool match_data, uint64_t data, int fd)
+{
+int r;
+
+assert(match_data section-size == 2);
+
+r = kvm_set_ioeventfd_pio_word(fd, section-offset_within_address_space,
+ data, true);
+if (r 0) {
+abort();
+}
+}
+
+static void kvm_io_ioeventfd_del(MemoryRegionSection *section,
+ bool match_data, uint64_t data, int fd)
+
+{
+int r;
+
+r = kvm_set_ioeventfd_pio_word(fd, section-offset_within_address_space,
+ data, false);
+if (r 0) {
+abort();
+}
+}
+
+static void kvm_eventfd_add(MemoryListener *listener,
+MemoryRegionSection *section,
+bool match_data, uint64_t data, int fd)
+{
+if (section-address_space == get_system_memory()) {
+kvm_mem_ioeventfd_add(section, match_data, data, fd);
+} else {
+kvm_io_ioeventfd_add(section, match_data, data, fd);
+}
+}
+
+static void kvm_eventfd_del(MemoryListener *listener,
+MemoryRegionSection *section,
+bool match_data, uint64_t data, int fd)
+{
+if (section-address_space == get_system_memory()) {
+kvm_mem_ioeventfd_del(section, match_data, data, fd);
+} else {
+kvm_io_ioeventfd_del(section, match_data, data, fd);
+}
+}
+
static MemoryListener kvm_memory_listener = {
.region_add = kvm_region_add,
.region_del = kvm_region_del,
@@ -726,6 +802,8 @@ static void kvm_log_global_stop(struct MemoryListener
*listener)
.log_sync = kvm_log_sync,
.log_global_start = kvm_log_global_start,
.log_global_stop = kvm_log_global_stop,
+.eventfd_add = kvm_eventfd_add,
+.eventfd_del = kvm_eventfd_del,
.priority = 10,
};
diff --git a/memory.c b/memory.c
index a1013bc..e1a31d4 100644
--- a/memory.c
+++ b/memory.c
@@ -202,8 +202,6 @@ struct AddressSpaceOps {
void (*range_del)(AddressSpace *as, FlatRange *fr);
void (*log_start)(AddressSpace *as, FlatRange *fr);
void (*log_stop)(AddressSpace *as, FlatRange *fr);
-void (*ioeventfd_add)(AddressSpace *as, MemoryRegionIoeventfd *fd);
-void (*ioeventfd_del)(AddressSpace
[Qemu-devel] [PATCH 03/10] memory: add shorthand for invoking a callback on all listeners
Signed-off-by: Avi Kivity a...@redhat.com
---
memory.c | 54 +++---
1 files changed, 19 insertions(+), 35 deletions(-)
diff --git a/memory.c b/memory.c
index 382dded..6afe414 100644
--- a/memory.c
+++ b/memory.c
@@ -678,31 +678,23 @@ static void address_space_update_ioeventfds(AddressSpace
*as)
as-ioeventfd_nb = ioeventfd_nb;
}
-typedef void ListenerCallback(MemoryListener *listener,
- MemoryRegionSection *mrs);
-
-/* Want void (MemoryListener::*callback)(const MemoryRegionSection s) */
-static void memory_listener_update_region(FlatRange *fr, AddressSpace *as,
- size_t callback_offset)
-{
-MemoryRegionSection section = {
-.mr = fr-mr,
-.address_space = as-root,
-.offset_within_region = fr-offset_in_region,
-.size = int128_get64(fr-addr.size),
-.offset_within_address_space = int128_get64(fr-addr.start),
-};
-MemoryListener *listener;
-
-QLIST_FOREACH(listener, memory_listeners, link) {
-ListenerCallback *callback
-= *(ListenerCallback **)((void *)listener + callback_offset);
-callback(listener, section);
-}
-}
-
-#define MEMORY_LISTENER_UPDATE_REGION(fr, as, callback) \
-memory_listener_update_region(fr, as, offsetof(MemoryListener, callback))
+#define MEMORY_LISTENER_CALL(_callback, _args...) \
+do {\
+MemoryListener *_listener; \
+\
+QLIST_FOREACH(_listener, memory_listeners, link) { \
+_listener-_callback(_listener, ##_args); \
+} \
+} while (0)
+
+#define MEMORY_LISTENER_UPDATE_REGION(fr, as, callback) \
+MEMORY_LISTENER_CALL(callback, (MemoryRegionSection) { \
+.mr = (fr)-mr, \
+.address_space = (as)-root,\
+.offset_within_region = (fr)-offset_in_region, \
+.size = int128_get64((fr)-addr.size), \
+.offset_within_address_space = int128_get64((fr)-addr.start), \
+})
static void address_space_update_topology_pass(AddressSpace *as,
FlatView old_view,
@@ -1483,23 +1475,15 @@ void memory_global_sync_dirty_bitmap(MemoryRegion
*address_space)
void memory_global_dirty_log_start(void)
{
-MemoryListener *listener;
-
cpu_physical_memory_set_dirty_tracking(1);
global_dirty_log = true;
-QLIST_FOREACH(listener, memory_listeners, link) {
-listener-log_global_start(listener);
-}
+MEMORY_LISTENER_CALL(log_global_start);
}
void memory_global_dirty_log_stop(void)
{
-MemoryListener *listener;
-
global_dirty_log = false;
-QLIST_FOREACH(listener, memory_listeners, link) {
-listener-log_global_stop(listener);
-}
+MEMORY_LISTENER_CALL(log_global_stop);
cpu_physical_memory_set_dirty_tracking(0);
}
--
1.7.9
[Qemu-devel] [PATCH 01/10] ioport: change portio_list not to use memory_region_set_offset()
memory_region_set_offset() will be going away soon, so don't use it.
Use an alias instead.
Signed-off-by: Avi Kivity a...@redhat.com
---
ioport.c | 25 +++--
ioport.h |1 +
2 files changed, 20 insertions(+), 6 deletions(-)
diff --git a/ioport.c b/ioport.c
index 36fa3a4..505b252 100644
--- a/ioport.c
+++ b/ioport.c
@@ -328,6 +328,7 @@ void portio_list_init(PortioList *piolist,
piolist-ports = callbacks;
piolist-nr = 0;
piolist-regions = g_new0(MemoryRegion *, n);
+piolist-aliases = g_new0(MemoryRegion *, n);
piolist-address_space = NULL;
piolist-opaque = opaque;
piolist-name = name;
@@ -336,6 +337,7 @@ void portio_list_init(PortioList *piolist,
void portio_list_destroy(PortioList *piolist)
{
g_free(piolist-regions);
+g_free(piolist-aliases);
}
static void portio_list_add_1(PortioList *piolist,
@@ -345,7 +347,7 @@ static void portio_list_add_1(PortioList *piolist,
{
MemoryRegionPortio *pio;
MemoryRegionOps *ops;
-MemoryRegion *region;
+MemoryRegion *region, *alias;
unsigned i;
/* Copy the sub-list and null-terminate it. */
@@ -362,12 +364,19 @@ static void portio_list_add_1(PortioList *piolist,
ops-old_portio = pio;
region = g_new(MemoryRegion, 1);
+alias = g_new(MemoryRegion, 1);
+/*
+ * Use an alias so that the callback is called with an absolute address,
+ * rather than an offset relative to to start + off_low.
+ */
memory_region_init_io(region, ops, piolist-opaque, piolist-name,
- off_high - off_low);
-memory_region_set_offset(region, start + off_low);
+ UINT64_MAX);
+memory_region_init_alias(alias, piolist-name,
+ region, start + off_low, off_high - off_low);
memory_region_add_subregion(piolist-address_space,
-start + off_low, region);
+start + off_low, alias);
piolist-regions[piolist-nr++] = region;
+piolist-aliases[piolist-nr++] = alias;
}
void portio_list_add(PortioList *piolist,
@@ -409,15 +418,19 @@ void portio_list_add(PortioList *piolist,
void portio_list_del(PortioList *piolist)
{
-MemoryRegion *mr;
+MemoryRegion *mr, *alias;
unsigned i;
for (i = 0; i piolist-nr; ++i) {
mr = piolist-regions[i];
-memory_region_del_subregion(piolist-address_space, mr);
+alias = piolist-aliases[i];
+memory_region_del_subregion(piolist-address_space, alias);
+memory_region_destroy(alias);
memory_region_destroy(mr);
g_free((MemoryRegionOps *)mr-ops);
g_free(mr);
+g_free(alias);
piolist-regions[i] = NULL;
+piolist-aliases[i] = NULL;
}
}
diff --git a/ioport.h b/ioport.h
index ae3e9da..ab29c89 100644
--- a/ioport.h
+++ b/ioport.h
@@ -60,6 +60,7 @@ typedef struct PortioList {
struct MemoryRegion *address_space;
unsigned nr;
struct MemoryRegion **regions;
+struct MemoryRegion **aliases;
void *opaque;
const char *name;
} PortioList;
--
1.7.9
[Qemu-devel] [PATCH 07/10] memory: add a readonly attribute to MemoryRegionSection
.readonly cannot be obtained from the MemoryRegion, since it is
inherited from aliases (so you can have a MemoryRegion mapped RW
at one address and RO at another). Record it in a MemoryRegionSection
for listeners.
Signed-off-by: Avi Kivity a...@redhat.com
---
memory.c |5 +
memory.h |2 ++
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/memory.c b/memory.c
index e1a31d4..4f37152 100644
--- a/memory.c
+++ b/memory.c
@@ -112,6 +112,7 @@ static AddrRange addrrange_intersection(AddrRange r1,
AddrRange r2)
.offset_within_region = (fr)-offset_in_region, \
.size = int128_get64((fr)-addr.size), \
.offset_within_address_space = int128_get64((fr)-addr.start), \
+.readonly = (fr)-readonly, \
})
struct CoalescedMemoryRange {
@@ -342,6 +343,7 @@ static void as_memory_range_add(AddressSpace *as, FlatRange
*fr)
.offset_within_address_space = int128_get64(fr-addr.start),
.offset_within_region = fr-offset_in_region,
.size = int128_get64(fr-addr.size),
+.readonly = fr-readonly,
};
cpu_register_physical_memory_log(section, fr-readable, fr-readonly);
@@ -354,6 +356,7 @@ static void as_memory_range_del(AddressSpace *as, FlatRange
*fr)
.offset_within_address_space = int128_get64(fr-addr.start),
.offset_within_region = int128_get64(fr-addr.start),
.size = int128_get64(fr-addr.size),
+.readonly = fr-readonly,
};
cpu_register_physical_memory_log(section, true, false);
@@ -1437,6 +1440,7 @@ MemoryRegionSection memory_region_find(MemoryRegion
*address_space,
fr-addr.start));
ret.size = int128_get64(range.size);
ret.offset_within_address_space = int128_get64(range.start);
+ret.readonly = fr-readonly;
return ret;
}
@@ -1479,6 +1483,7 @@ static void listener_add_address_space(MemoryListener
*listener,
.offset_within_region = fr-offset_in_region,
.size = int128_get64(fr-addr.size),
.offset_within_address_space = int128_get64(fr-addr.start),
+.readonly = fr-readonly,
};
listener-region_add(listener, section);
}
diff --git a/memory.h b/memory.h
index 84bb67c..1d99cee 100644
--- a/memory.h
+++ b/memory.h
@@ -160,6 +160,7 @@ typedef struct MemoryRegionSection MemoryRegionSection;
* @size: the size of the section; will not exceed @mr's boundaries
* @offset_within_address_space: the address of the first byte of the section
* relative to the region's address space
+ * @readonly: writes to this section are ignored
*/
struct MemoryRegionSection {
MemoryRegion *mr;
@@ -167,6 +168,7 @@ struct MemoryRegionSection {
target_phys_addr_t offset_within_region;
uint64_t size;
target_phys_addr_t offset_within_address_space;
+bool readonly;
};
typedef struct MemoryListener MemoryListener;
--
1.7.9
Re: [Qemu-devel] Restore consistent formatting
Am 08.02.2012 16:04, schrieb malc: On Wed, 8 Feb 2012, Andreas F?rber wrote: Arbitrarily reformatting your files is not okay. If you want a different formatting, you need to fix checkpatch.pl first to not error on that formatting in your files. It was always formatter like this (internally consistent), then others added code which made it not so. That's not the point. We use the checkpatch.pl script to check the formatting of patches, we tell contributors to run it. If you want your files to have an additional space then _you_ would have to change the script to not error on that formatting in certain files or else your formatting changes will get reverted again in the parts other people touch. Right now you silently caused a needless conflict with other people's patches, including device_init() - type_init(). That's a really great way to say I'm back after lots of 'mail receiving disabled' messages... 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] [PATCH 09/10] memory: use a MemoryListener for core memory map updates too
This transforms memory.c into a library which can then be unit tested
easily, by feeding it inputs and listening to its outputs.
Signed-off-by: Avi Kivity a...@redhat.com
---
exec-obsolete.h |3 ++
exec.c | 75 +++
memory.c| 27 +---
3 files changed, 79 insertions(+), 26 deletions(-)
diff --git a/exec-obsolete.h b/exec-obsolete.h
index 23ffbaa..4dbe476 100644
--- a/exec-obsolete.h
+++ b/exec-obsolete.h
@@ -121,6 +121,9 @@ static inline void
cpu_physical_memory_mask_dirty_range(ram_addr_t start,
void cpu_physical_memory_reset_dirty(ram_addr_t start, ram_addr_t end,
int dirty_flags);
+
+extern const IORangeOps memory_region_iorange_ops;
+
#endif
#endif
diff --git a/exec.c b/exec.c
index d3020ab..7fb5d4e 100644
--- a/exec.c
+++ b/exec.c
@@ -3488,6 +3488,79 @@ static void io_mem_init(void)
watch, UINT64_MAX);
}
+static void core_region_add(MemoryListener *listener,
+MemoryRegionSection *section)
+{
+if (section-address_space == get_system_memory()) {
+cpu_register_physical_memory_log(section, section-readonly);
+} else {
+iorange_init(section-mr-iorange, memory_region_iorange_ops,
+ section-offset_within_address_space, section-size);
+ioport_register(section-mr-iorange);
+}
+}
+
+static void core_region_del(MemoryListener *listener,
+MemoryRegionSection *section)
+{
+if (section-address_space == get_system_memory()) {
+cpu_register_physical_memory_log(section, false);
+} else {
+isa_unassign_ioport(section-offset_within_address_space,
+section-size);
+}
+}
+
+static void core_log_start(MemoryListener *listener,
+ MemoryRegionSection *section)
+{
+}
+
+static void core_log_stop(MemoryListener *listener,
+ MemoryRegionSection *section)
+{
+}
+
+static void core_log_sync(MemoryListener *listener,
+ MemoryRegionSection *section)
+{
+}
+
+static void core_log_global_start(MemoryListener *listener)
+{
+cpu_physical_memory_set_dirty_tracking(1);
+}
+
+static void core_log_global_stop(MemoryListener *listener)
+{
+cpu_physical_memory_set_dirty_tracking(0);
+}
+
+static void core_eventfd_add(MemoryListener *listener,
+ MemoryRegionSection *section,
+ bool match_data, uint64_t data, int fd)
+{
+}
+
+static void core_eventfd_del(MemoryListener *listener,
+ MemoryRegionSection *section,
+ bool match_data, uint64_t data, int fd)
+{
+}
+
+static MemoryListener core_memory_listener = {
+.region_add = core_region_add,
+.region_del = core_region_del,
+.log_start = core_log_start,
+.log_stop = core_log_stop,
+.log_sync = core_log_sync,
+.log_global_start = core_log_global_start,
+.log_global_stop = core_log_global_stop,
+.eventfd_add = core_eventfd_add,
+.eventfd_del = core_eventfd_del,
+.priority = 0,
+};
+
static void memory_map_init(void)
{
system_memory = g_malloc(sizeof(*system_memory));
@@ -3497,6 +3570,8 @@ static void memory_map_init(void)
system_io = g_malloc(sizeof(*system_io));
memory_region_init(system_io, io, 65536);
set_system_io_map(system_io);
+
+memory_listener_register(core_memory_listener);
}
MemoryRegion *get_system_memory(void)
diff --git a/memory.c b/memory.c
index 71039c4..4e7a90b 100644
--- a/memory.c
+++ b/memory.c
@@ -338,28 +338,10 @@ static void access_with_adjusted_size(target_phys_addr_t
addr,
static void as_memory_range_add(AddressSpace *as, FlatRange *fr)
{
-MemoryRegionSection section = {
-.mr = fr-mr,
-.offset_within_address_space = int128_get64(fr-addr.start),
-.offset_within_region = fr-offset_in_region,
-.size = int128_get64(fr-addr.size),
-.readonly = fr-readonly,
-};
-
-cpu_register_physical_memory_log(section, fr-readonly);
}
static void as_memory_range_del(AddressSpace *as, FlatRange *fr)
{
-MemoryRegionSection section = {
-.mr = io_mem_unassigned,
-.offset_within_address_space = int128_get64(fr-addr.start),
-.offset_within_region = int128_get64(fr-addr.start),
-.size = int128_get64(fr-addr.size),
-.readonly = fr-readonly,
-};
-
-cpu_register_physical_memory_log(section, false);
}
static void as_memory_log_start(AddressSpace *as, FlatRange *fr)
@@ -450,22 +432,17 @@ static void memory_region_iorange_write(IORange *iorange,
memory_region_write_accessor, mr);
}
-static const IORangeOps memory_region_iorange_ops = {
+const IORangeOps memory_region_iorange_ops = {
.read = memory_region_iorange_read,
.write = memory_region_iorange_write,
Re: [Qemu-devel] [PATCH 00/10] Remove AddressSpaceOps
On 02/08/2012 05:27 PM, Avi Kivity wrote: This patchset makes the memory core (memory.c) talk to the backend (in exec.c) via a MemoryListener instead of named functions. While the motivation for this is to simplify the memory core, it also enables optimizing accelerators some more (by having a tcg MemoryListener to do tcg specific core) and allows unit testing of memory.c (by adding a testing MemoryListener and seeing what it outputs as various inputs are fed into the core). Something that is very visible here is that MemoryListeners switch quite a lot on the address space. This suggests that we need to allow observing a specific address space. I'll address that in a future patch. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] Restore consistent formatting
Am 08.02.2012 16:23, schrieb Anthony Liguori: On 02/08/2012 09:04 AM, malc wrote: On Wed, 8 Feb 2012, Andreas F?rber wrote: Arbitrarily reformatting your files is not okay. If you want a different formatting, you need to fix checkpatch.pl first to not error on that formatting in your files. It was always formatter like this (internally consistent), then others added code which made it not so. We do have a mixed style in the audio layer. I'm not happy about that but I also feel strongly that going through and doing a reformat is not a worthwhile exercise. I can also understand the desire to keep things consistent. But patches should always go to the mailing list. I certainly would have acked such a patch FWIW. I think people get a bit too excited about coding style. There are much more important things to worry about in life than the number of spaces before a parenthesis :-) This is not about whether or not we put a space somewhere. It's about reviewers and SubmitAPatch telling people to run checkpatch.pl on patches and checkpatch.pl reporting this as an ERROR, not a WARNING. So if you follow Stefan's instructions on running the script as a commit hook (which is the only sane way to run it when handling lots of patches) you can't commit a patch or your local changes when there are ERRORs. I just spent half the night trying to find out why checkpatch.pl reports CPUX86State *env, CPUYState *env, CPyState *env as ERRORs but not CPUState *env. I did not succeed in really understanding it. So either we need to all stop using and telling to use checkpatch.pl or someone needs to fix it. 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] [PATCH 00/10] Remove AddressSpaceOps
This patchset makes the memory core (memory.c) talk to the backend (in exec.c) via a MemoryListener instead of named functions. While the motivation for this is to simplify the memory core, it also enables optimizing accelerators some more (by having a tcg MemoryListener to do tcg specific core) and allows unit testing of memory.c (by adding a testing MemoryListener and seeing what it outputs as various inputs are fed into the core). Avi Kivity (10): ioport: change portio_list not to use memory_region_set_offset() memory: remove memory_region_set_offset() memory: add shorthand for invoking a callback on all listeners memory: switch memory listeners to a QTAILQ memory: code motion: move MEMORY_LISTENER_CALL() memory: move ioeventfd ops to MemoryListener memory: add a readonly attribute to MemoryRegionSection memory: don't pass -readable attribute to cpu_register_physical_memory_log memory: use a MemoryListener for core memory map updates too memory: drop AddressSpaceOps exec-obsolete.h |5 +- exec.c | 77 +++- hw/vhost.c | 15 +++ ioport.c| 25 - ioport.h|1 + kvm-all.c | 79 +++ memory.c| 288 ++- memory.h| 19 ++-- xen-all.c | 15 +++ 9 files changed, 310 insertions(+), 214 deletions(-) -- 1.7.9
Re: [Qemu-devel] Restore consistent formatting
On 02/08/2012 09:36 AM, Andreas Färber wrote: Am 08.02.2012 16:23, schrieb Anthony Liguori: On 02/08/2012 09:04 AM, malc wrote: On Wed, 8 Feb 2012, Andreas F?rber wrote: Arbitrarily reformatting your files is not okay. If you want a different formatting, you need to fix checkpatch.pl first to not error on that formatting in your files. It was always formatter like this (internally consistent), then others added code which made it not so. We do have a mixed style in the audio layer. I'm not happy about that but I also feel strongly that going through and doing a reformat is not a worthwhile exercise. I can also understand the desire to keep things consistent. But patches should always go to the mailing list. I certainly would have acked such a patch FWIW. I think people get a bit too excited about coding style. There are much more important things to worry about in life than the number of spaces before a parenthesis :-) This is not about whether or not we put a space somewhere. It's about reviewers and SubmitAPatch telling people to run checkpatch.pl on patches and checkpatch.pl reporting this as an ERROR, not a WARNING. So if you follow Stefan's instructions on running the script as a commit hook (which is the only sane way to run it when handling lots of patches) you can't commit a patch or your local changes when there are ERRORs. It's a suggestion, it still assumes that you are going to exercise discretion and make rational decisions when checkpatch does something silly. I just spent half the night trying to find out why checkpatch.pl reports CPUX86State *env, CPUYState *env, CPyState *env as ERRORs but not CPUState *env. I did not succeed in really understanding it. So either we need to all stop using and telling to use checkpatch.pl or someone needs to fix it. checkpatch.pl is a tool. Tools are meant to make our lives easier, not harder. You should use checkpatch.pl to help you figure out if you have coding style issues but it is not a QEMU maintainer that gives you a required Ack before you code gets accepted. If it's doing something stupid, ignore it. Making checkpatch 100% perfect (or event 99% perfect) is simply not worth the effort. Parsing C is insanely hard and doing it in perl only makes the problem worse :-) If you want to tone down the language in SubmitAPatch, please go ahead. It's a wiki after all. Regards, Anthony Liguori Andreas
