Re: [Qemu-devel] where is the definition of this fuction?
2009/11/9 yuanzhu86 yuanzh...@163.com:
Hi everyone:
as I want to analysis the source code of qemu now, and there is a litte
trouble at this fuction:
in the file--Translate.c(target-i386)
Line 6113 :
case 0xea: /* ljmp im */
{
unsigned int selector, offset;
if (CODE64(s))
goto illegal_op;
ot = dflag ? OT_LONG : OT_WORD;
offset = insn_get(s, ot);
selector = insn_get(s, OT_WORD);
gen_op_movl_T0_im(selector);
gen_op_movl_T1_imu(offset);
}
goto do_ljmp;
--
do_ljmp:
if (s-pe !s-vm86) {
if (s-cc_op != CC_OP_DYNAMIC)
gen_op_set_cc_op(s-cc_op);
gen_jmp_im(pc_start - s-cs_base);
tcg_gen_trunc_tl_i32(cpu_tmp2_i32, cpu_T[0]);
gen_helper_ljmp_protected(cpu_tmp2_i32, cpu_T[1],
tcg_const_i32(s-pc - pc_start));
} else {
gen_op_movl_seg_T0_vm(R_CS);
gen_op_movl_T0_T1();
gen_op_jmp_T0();
}
gen_eob(s);
break;
this fucion:
gen_helper_ljmp_protected(cpu_tmp2_i32, cpu_T[1],
tcg_const_i32(s-pc - pc_start));
I guess it should use the fuction glue() to create,but I can not find where
it is ,could someone tell me that if you konw !
thanks very much !look forward to your answer !
Helper functions are built using macros.
This will find the definition:
grep -r ljmp_protected .
Laurent
Re: [Qemu-devel] [sneak preview] major scsi overhaul
On 11/07/09 16:22, Blue Swirl wrote: In general the commits look good, there are many obviously correct cleanups. However, what happens to the DPRINTFs, it looks like they are removed in the process? I guess you are talking about the ones for each emulated command in scsi-disk.c? There is scsi_print_req() now, filling this hole. I'll stick in a call, wrapped into #ifdef DEBUG_SCSI, so you'll get this printed by default when compiling with debugging enabled. You are also moving the compilation to Makefile.hw, which is not exactly an improvement. Is this needed because of the QEMUIOVector stuff? Almost correct ;) It is because of QEMUSGList which drags in a target_phys_addr_t dependency. cheers, Gerd
[Qemu-devel] Doubt about COW feature of QCOW2
Hello All, I had a doubt about the COW implementation of QCOW2. Suppose two clusters point to the same address, then in that case, the QCOW_OFLAG_COPIED is cleared in the l2 entries for both the clusters. Now suppose a write is made to any one of the clusters, then how is the other cluster identified, in order to set the QCOW_OFLAG_COPIED since only reference is left. Thanks in advance, Furquan
Re: [Qemu-devel] [sneak preview] major scsi overhaul
On 11/09/2009 11:08 AM, Gerd Hoffmann wrote: You are also moving the compilation to Makefile.hw, which is not exactly an improvement. Is this needed because of the QEMUIOVector stuff? Almost correct ;) It is because of QEMUSGList which drags in a target_phys_addr_t dependency. As Michael notes, devices have physical address sizes independent of the target platform; a PCI device that supports 64-bit addresses can be plugged into a motherboard that supports 32-bit address bus processors. We can fix this in several ways: - creating QEMUSG64List and QEMUSG32List (and typedefing PCISGList to the former) - making QEMUSGList always use 64-bit addresses since it will almost always be used with devices (which are often 64-bit capable) - making target_phys_addr_t always 64-bit (which loses some performance with 32-on-32 emulation) - others? -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [sneak preview] major scsi overhaul
On 11/09/09 13:37, Avi Kivity wrote: On 11/09/2009 11:08 AM, Gerd Hoffmann wrote: It is because of QEMUSGList which drags in a target_phys_addr_t dependency. As Michael notes, devices have physical address sizes independent of the target platform; a PCI device that supports 64-bit addresses can be plugged into a motherboard that supports 32-bit address bus processors. We can fix this in several ways: - creating QEMUSG64List and QEMUSG32List (and typedefing PCISGList to the former) Doesn't fly. Either every SCSI HBA uses QEMUSG64List (thus making this aequivalent to the next option from the scsi point of view), or scsi-disk would have to support both formats. - making QEMUSGList always use 64-bit addresses since it will almost always be used with devices (which are often 64-bit capable) Possible. - making target_phys_addr_t always 64-bit (which loses some performance with 32-on-32 emulation) Possible too. Has the advantage that more code can be compiled only once, often target_phys_addr_t is the only reason a source file is in Makefile.hw instead of Makefile. Question is how big the performance hit actually is and whenever we are willing to accept that or not ... cheers, Gerd
Re: [Qemu-devel] [sneak preview] major scsi overhaul
On 11/09/2009 03:03 PM, Gerd Hoffmann wrote: On 11/09/09 13:37, Avi Kivity wrote: On 11/09/2009 11:08 AM, Gerd Hoffmann wrote: It is because of QEMUSGList which drags in a target_phys_addr_t dependency. As Michael notes, devices have physical address sizes independent of the target platform; a PCI device that supports 64-bit addresses can be plugged into a motherboard that supports 32-bit address bus processors. We can fix this in several ways: - creating QEMUSG64List and QEMUSG32List (and typedefing PCISGList to the former) Doesn't fly. Either every SCSI HBA uses QEMUSG64List (thus making this aequivalent to the next option from the scsi point of view), or scsi-disk would have to support both formats. A device or device set which is always 64-bit would always use QEMUSG64List. A device which is always 32-bit would use QEMUSG32List. - making QEMUSGList always use 64-bit addresses since it will almost always be used with devices (which are often 64-bit capable) Possible. This is my preferred option btw. There's no performance impact since actual device emulation will dwarf an 64-bit impact. - making target_phys_addr_t always 64-bit (which loses some performance with 32-on-32 emulation) Possible too. Has the advantage that more code can be compiled only once, often target_phys_addr_t is the only reason a source file is in Makefile.hw instead of Makefile. Question is how big the performance hit actually is and whenever we are willing to accept that or not ... Probably unmeasurable, but the qemu-devel thread size will be very measurable so not worth it. Note platform-independent devices (like pci) shouldn't depend on target_phys_addr_t anyway; QEMSG64List is one part of this. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [sneak preview] major scsi overhaul
Hi, Doesn't fly. Either every SCSI HBA uses QEMUSG64List (thus making this aequivalent to the next option from the scsi point of view), or scsi-disk would have to support both formats. A device or device set which is always 64-bit would always use QEMUSG64List. A device which is always 32-bit would use QEMUSG32List. A scsi-disk can be connected to both 32-bit and 64-bit HBAs though ... Question is how big the performance hit actually is and whenever we are willing to accept that or not ... Probably unmeasurable, but the qemu-devel thread size will be very measurable so not worth it. ;) cheers, Gerd
Re: [Qemu-devel] [sneak preview] major scsi overhaul
On 11/09/2009 03:39 PM, Gerd Hoffmann wrote: Hi, Doesn't fly. Either every SCSI HBA uses QEMUSG64List (thus making this aequivalent to the next option from the scsi point of view), or scsi-disk would have to support both formats. A device or device set which is always 64-bit would always use QEMUSG64List. A device which is always 32-bit would use QEMUSG32List. A scsi-disk can be connected to both 32-bit and 64-bit HBAs though ... A line has to be drawn. Since we have a limited number of HBAs, and since the performance impact will be minimal, we can safely use 64-bit for scsi. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [RFC] virtio: Report new guest memory statistics pertinent to memory ballooning
Avi Kivity wrote: (qemu) info balloon balloon: actual=1024 MB balloon: pswapin=0 pages balloon: pswapout=0 pages balloon: panon=3928 KB balloon: pgmajfault=0 balloon: pgminfault=247914 balloon: memfree=987032 KB balloon: memtot=1020812 KB Is this agreeable? It's important that these statistics be cross platform. Can you (or someone knowledgeable in Windows) verify that all of these are meaningful there? I'd expect it to be so with the possible exception of panon. They don't have to all be cross platform. We can expose platform specific metrics via feature bits. We should only disable features that the guest has acknowledged. But of course, whenever possible, we want metrics to be meaningful cross platform. -- Regards, Anthony Liguori
Re: [Qemu-devel] don't look for libuuid on Darwin
On Sun, Nov 08, 2009 at 06:37:34PM -0700, C.W. Betts wrote: In Darwin, the libSystem.B.dylib is a container for a lot of libraries, among them is libuuid. However, there isn't, by default, a static link libuuid to libSystem. The configure script should just check to see if there's a uuid header and don't look for a libuuid. Checking for static libraries is a bad idea in general. Care to submit a patch to fix this check up to do the usual compile test (tiny code fragment that needs libuuid)
Re: [Qemu-devel] [PATCH 4/4] Add support for -net bridge
Avi Kivity wrote: On 11/08/2009 12:11 AM, Anthony Liguori wrote: You don't need root privileges to use a tap device. You can access a preconfigured tap device but you cannot allocate a tap device and connect it to a bridge without CAP_NET_ADMIN. btw, shouldn't we, in the general case, create a bridge per user and use IP NAT? If we have a global bridge, users can spoof each other's MAC addresses and interfere with their virtual machines. qemu-bridge-helper supports that model quite well :-) You would create a NAT'd bridge for each user as the administrator, then create a bridge.conf that consisted of per-user includes with appropriate permissions set on each of those files. They can also interfere with the real network. That's not a concern with most one-user-per-machine configurations, but the default configuration should be safe. Let's not kid ourselves, no matter what we do we're giving a user elevated privileges. Even with NAT, if the host can access the NAT'ed network, then you can run a privileged service (like NFS) in that network. Like it or not, some networks rely on privileged services being trusted as part of their security model (consider NIS). I think the best we can do is provide a tool that allows an administrator to grant users additional privileges in the tiniest increments possible. Putting people in wheel just so they can do virtualization is too much. I don't see having an fscap-based helper as creating policy. I see it as adding a mechanism for administrators to create policy. -- Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH] Add support for multiple simultaneously used keyboard devices.
Filip Navara wrote: The support for multiple keyboard devices is essential for emulating embedded boards where multiple input devices are present (eg. keypad and rotary encoder) which are implemented using separate QEMU devices. Signed-off-by: Filip Navara filip.nav...@gmail.com What boards would we actually expose multiple keyboards with? Moreover, we're not doing anything useful here. We're just repeating a single keypress to multiple keyboards which seems rather hackish. Regards, Anthony Liguori
[Qemu-devel]question:arm's mutli-core emulator
2009/11/7 m9807418 m9807...@mail.ntust.edu.tw:
When I used qemu-system-arm and the -smp option.
I key -smp 2.
It have a message Number of SMP cpus requested (2), exceeds max cpus
supported by machine `Versatile' (1)
which files of the qemu source code can i change?
And the change can let me emulator arm's multi-core.
1. Your question has nothing to do with the development of qemu, so
don't be surprised when you don't get too many responses.
2. See qemu/hw/realview.c
if (!cpu_model)
cpu_model = arm926;
/* FIXME: obey smp_cpus. */
if (strcmp(cpu_model, arm11mpcore) == 0) {
ncpu = 4;
} else {
ncpu = 1;
}
Scott tsai's answer whether i must use arm11mpcore cpu,i just can emulator 4
cpus.
Can i change the number and get the number i want?
And Versatilepb.c i use the same way like Realview.c.
Qemu shell can find 2 cpus,but the OS can't install.
I am fail.
Now i have another question.
1.Arm's multi-core emulator whether can use arm Versatile?
If it can, i must do what?
2.If can not use arm Versatile,can talk me which can be emulator multi-core
except arm RealView.
Sorry.I don't know how to do use qemu emulator RealView
and where to download theRealView's kernel and initrd file?
Anyone have some step to emulator arm Realview.
like http://www.aurel32.net/info/debian_arm_qemu.php
anybody can help me
thank
qun yi
[Qemu-devel] Build on i386
Hi , I have patched the qemu to even build on i386. Now all the targets build, but I cannot run all targets. ./i386-softmmu/qemu -L / /bin/ls qemu: could not load PC BIOS 'bios.bin' Does not work. ./i386-linux-user/qemu-i386 -L / /bin/ls qemu: Unsupported syscall: 240 qemu: Unsupported syscall: 240 acl.c config-host.ld kvm-all.c posix-aio-compat.o qemu-thread.ctarget-cris acl.d config-host.makkvm.h ppc64abi32-linux-user qemu-thread.htarget-i386 Works. ./x86_64-softmmu/qemu-system-x86_64 -L / /bin/ls qemu: could not load PC BIOS 'bios.bin' mdup...@introspector-desktop:~/2009/11/external/qemugit/mainline/qemu$ ./x86_64-linux-user/qemu-x86_64 -L / /bin/ls Error -8 while loading /bin/ls diff --git a/configure b/configure index aa2cc43..451c2be 100755 --- a/configure +++ b/configure @@ -1736,7 +1736,8 @@ if test $debug = no ; then fi QEMU_CFLAGS=-Wall -Wundef -Wendif-labels -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_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE $QEMU_CFLAGS +QEMU_CFLAGS=-D_GNU_SOURCE -D_LARGEFILE_SOURCE $QEMU_CFLAGS QEMU_CFLAGS=-U_FORTIFY_SOURCE $QEMU_CFLAGS QEMU_CFLAGS=-I. -I\$(SRC_PATH) $QEMU_CFLAGS LDFLAGS=-g $LDFLAGS
Re: [Qemu-devel] Build on i386
On Mon, Nov 9, 2009 at 3:39 PM, jamesmikedup...@googlemail.com jamesmikedup...@googlemail.com wrote: [...] ./i386-softmmu/qemu -L / /bin/ls qemu: could not load PC BIOS 'bios.bin' Does not work. Do you know what softmmu means? You should read QEMU user manual. [...] ./x86_64-softmmu/qemu-system-x86_64 -L / /bin/ls qemu: could not load PC BIOS 'bios.bin' mdup...@introspector-desktop:~/2009/11/external/qemugit/mainline/qemu$ ./x86_64-linux-user/qemu-x86_64 -L / /bin/ls Error -8 while loading /bin/ls This can't run given that your /bin/ls is an i386 executable. Laurent
Re: [Qemu-devel] [PATCH 4/4] Add support for -net bridge
Anthony Liguori wrote: Let's not kid ourselves, no matter what we do we're giving a user elevated privileges. Even with NAT, if the host can access the NAT'ed network, then you can run a privileged service (like NFS) in that network. I don't see how outgoing NAT (SNAT), where the guest can make _outgoing_ connections to the network, allows the guest to run a privileged service accessible to the network. Sure, the guest can run an NFS server, but it means nothing to the outside - it's on the guest's own private little network. Same as Slirp. The guest cannot even make an outgoing request which appears to come from an privileged port - if the SNAT rule has the appropriate options to force the port into an unprivileged range. For the guest's NFS server to be visible to the network requires incoming NAT (DNAT) on the host, often called port forwarding. But that is done by explicit administration; if you can do that, you can run a privileged service on the host anyway. I think the best we can do is provide a tool that allows an administrator to grant users additional privileges in the tiniest increments possible. Putting people in wheel just so they can do virtualization is too much. I don't see having an fscap-based helper as creating policy. I see it as adding a mechanism for administrators to create policy. I agree with both of these. -- Jamie
Re: [Qemu-devel] [PATCH 4/4] Add support for -net bridge
Jamie Lokier wrote: Anthony Liguori wrote: Let's not kid ourselves, no matter what we do we're giving a user elevated privileges. Even with NAT, if the host can access the NAT'ed network, then you can run a privileged service (like NFS) in that network. I don't see how outgoing NAT (SNAT), where the guest can make _outgoing_ connections to the network, allows the guest to run a privileged service accessible to the network. Sure, the guest can run an NFS server, but it means nothing to the outside - it's on the guest's own private little network. Same as Slirp. The guest cannot even make an outgoing request which appears to come from an privileged port - if the SNAT rule has the appropriate options to force the port into an unprivileged range. For the guest's NFS server to be visible to the network requires incoming NAT (DNAT) on the host, often called port forwarding. But that is done by explicit administration; if you can do that, you can run a privileged service on the host anyway. You are correct except that I qualified this as NAT with host access which so far is the common model. If the host can access the NAT'd network behind the NAT, then port privileges are important. -- Regards, Anthony Liguori
[Qemu-devel] [RFC] virtio: Report new guest memory statistics pertinent to memory ballooning (V2)
Changes since V1:
- In the monitor, print all stats on one line with less abbreviated names
- Coding style changes
When using ballooning to manage overcommitted memory on a host, a system for
guests to communicate their memory usage to the host can provide information
that will minimize the impact of ballooning on the guests. The current method
employs a daemon running in each guest that communicates memory statistics to a
host daemon at a specified time interval. The host daemon aggregates this
information and inflates and/or deflates balloons according to the level of
host memory pressure. This approach is effective but overly complex since a
daemon must be installed inside each guest and coordinated to communicate with
the host. A simpler approach is to collect memory statistics in the virtio
balloon driver and communicate them to the host via the device config space.
This patch implements the qemu side of the communication channel. I will post
the kernel driver modifications in-reply to this message.
Signed-off-by: Adam Litke a...@us.ibm.com
Cc: Anthony Liguori aligu...@us.ibm.com
Cc: Avi Kivity a...@redhat.com
diff --git a/balloon.h b/balloon.h
index 60b4a5d..4008d1b 100644
--- a/balloon.h
+++ b/balloon.h
@@ -14,14 +14,21 @@
#ifndef _QEMU_BALLOON_H
#define _QEMU_BALLOON_H
+#include hw/virtio-balloon.h
#include cpu-defs.h
-typedef ram_addr_t (QEMUBalloonEvent)(void *opaque, ram_addr_t target);
+typedef struct QEMUBalloonState {
+ram_addr_t actual;
+virtio_balloon_stats stats;
+} QEMUBalloonState;
+
+typedef void (QEMUBalloonEvent)(void *opaque, ram_addr_t target,
+ QEMUBalloonState *state);
void qemu_add_balloon_handler(QEMUBalloonEvent *func, void *opaque);
void qemu_balloon(ram_addr_t target);
-ram_addr_t qemu_balloon_status(void);
+int qemu_balloon_status(QEMUBalloonState *s);
#endif
diff --git a/hw/virtio-balloon.c b/hw/virtio-balloon.c
index cfd3b41..3d74e7f 100644
--- a/hw/virtio-balloon.c
+++ b/hw/virtio-balloon.c
@@ -30,6 +30,7 @@ typedef struct VirtIOBalloon
VirtQueue *ivq, *dvq;
uint32_t num_pages;
uint32_t actual;
+virtio_balloon_stats stats;
} VirtIOBalloon;
static VirtIOBalloon *to_virtio_balloon(VirtIODevice *vdev)
@@ -111,8 +112,15 @@ static void virtio_balloon_get_config(VirtIODevice *vdev,
uint8_t *config_data)
config.num_pages = cpu_to_le32(dev-num_pages);
config.actual = cpu_to_le32(dev-actual);
-
-memcpy(config_data, config, 8);
+config.stats.pswapin = cpu_to_le32(dev-stats.pswapin);
+config.stats.pswapout = cpu_to_le32(dev-stats.pswapout);
+config.stats.panon = cpu_to_le32(dev-stats.panon);
+config.stats.pgmajfault = cpu_to_le32(dev-stats.pgmajfault);
+config.stats.pgminfault = cpu_to_le32(dev-stats.pgminfault);
+config.stats.memfree = cpu_to_le32(dev-stats.memfree);
+config.stats.memtot = cpu_to_le32(dev-stats.memtot);
+
+memcpy(config_data, config, sizeof(config));
}
static void virtio_balloon_set_config(VirtIODevice *vdev,
@@ -120,16 +128,39 @@ static void virtio_balloon_set_config(VirtIODevice *vdev,
{
VirtIOBalloon *dev = to_virtio_balloon(vdev);
struct virtio_balloon_config config;
-memcpy(config, config_data, 8);
+memcpy(config, config_data, sizeof(config));
dev-actual = config.actual;
+dev-stats.pswapin = config.stats.pswapin;
+dev-stats.pswapout = config.stats.pswapout;
+dev-stats.panon = config.stats.panon;
+dev-stats.pgmajfault = config.stats.pgmajfault;
+dev-stats.pgminfault = config.stats.pgminfault;
+dev-stats.memfree = config.stats.memfree;
+dev-stats.memtot = config.stats.memtot;
}
static uint32_t virtio_balloon_get_features(VirtIODevice *vdev)
{
-return 0;
+uint32_t features = 0;
+
+features |= (1 VIRTIO_BALLOON_F_RPT_SWAP_IN) |
+(1 VIRTIO_BALLOON_F_RPT_SWAP_OUT) |
+(1 VIRTIO_BALLOON_F_RPT_ANON) |
+(1 VIRTIO_BALLOON_F_RPT_MAJFLT) |
+(1 VIRTIO_BALLOON_F_RPT_MINFLT) |
+(1 VIRTIO_BALLOON_F_RPT_MEMFREE) |
+(1 VIRTIO_BALLOON_F_RPT_MEMTOT);
+
+return features;
+}
+
+static inline int has_feature(VirtIOBalloon *dev, int feature)
+{
+ return (dev-vdev.features 1feature);
}
-static ram_addr_t virtio_balloon_to_target(void *opaque, ram_addr_t target)
+static void virtio_balloon_to_target(void *opaque, ram_addr_t target,
+ QEMUBalloonState *s)
{
VirtIOBalloon *dev = opaque;
@@ -141,7 +172,23 @@ static ram_addr_t virtio_balloon_to_target(void *opaque,
ram_addr_t target)
virtio_notify_config(dev-vdev);
}
-return ram_size - (dev-actual VIRTIO_BALLOON_PFN_SHIFT);
+if (s) {
+s-actual = ram_size - (dev-actual VIRTIO_BALLOON_PFN_SHIFT);
+s-stats.pswapin = has_feature(dev, VIRTIO_BALLOON_F_RPT_SWAP_OUT) ?
+
Re: [Qemu-devel] Re: [PATCH 05/26] Unexport ticks_per_sec variable. Create get_ticks_per_sec() function
On Friday 11 September 2009, Anthony Liguori wrote: malc wrote: And generalizations are always true. Anyhow, i'm explicitly against the patch, so first obtain the express acknowledgment from the leaders, otherwise i'll revert it should it go in. I'm adding the following patch to Juan's series. The result is that get_ticks_per_sec() should be optimized to a literal value. The result being that uses of it are faster than they were before (not it should matter). Having this as a function/variable is completely misleading. It is and always will be 10. You'd be better off using QEMU_TIMER_BASE directly. Paul
Re: [Qemu-devel] [PATCH 0/2] port over extboot from kvm
On 11/09/09 17:06, Paul Brook wrote: On Tuesday 08 September 2009, Anthony Liguori wrote: Gerd Hoffmann wrote: $subject says pretty much everything. extboot.[cS] are a straight copy from the kvm tree. The windup in vl,c and hw/pc.c is done slightly different, I've added a function to lookup the boot drive instead of adding a new global variable. I think the function here is high even if the implementation is ugly. In the past, Paul strongly objected to this. Paul, care to comment? Doesn't gpxe support virtio-blk, without requiring any additional qemu features? As far I know patches exist but where never merged. Also there is no way to boot from scsi+usb ... cheers, Gerd
[Qemu-devel] virtio: Add memory statistics reporting to the balloon driver
When using ballooning to manage overcommitted memory on a host, a system for
guests to communicate their memory usage to the host can provide information
that will minimize the impact of ballooning on the guests. The current method
employs a daemon running in each guest that communicates memory statistics to a
host daemon at a specified time interval. The host daemon aggregates this
information and inflates and/or deflates balloons according to the level of
host memory pressure. This approach is effective but overly complex since a
daemon must be installed inside each guest and coordinated to communicate with
the host. A simpler approach is to collect memory statistics in the virtio
balloon driver and communicate them to the host via the device config space.
This patch enables the guest-side support by adding stats collection and
reporting to the virtio balloon driver.
Comments?
Signed-off-by: Adam Litke a...@us.ibm.com
Cc: Rusty Russell ru...@rustcorp.com.au
Cc: Anthony Liguori anth...@codemonkey.ws
Cc: Avi Kivity a...@redhat.com
Cc: virtualizat...@lists.linux-foundation.org
Cc: linux-ker...@vger.kernel.org
diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 200c22f..0c9a9a1 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -180,6 +180,41 @@ static void update_balloon_size(struct virtio_balloon *vb)
actual, sizeof(actual));
}
+static inline void update_stat(struct virtio_device *vdev, int feature,
+ unsigned long value, unsigned offset)
+{
+ __le32 __v = cpu_to_le32(value);
+ if (virtio_has_feature(vdev, feature))
+ vdev-config-set(vdev, offset, __v, sizeof(__v));
+}
+
+#define K(x) ((x) (PAGE_SHIFT - 10))
+static void update_balloon_stats(struct virtio_balloon *vb)
+{
+ unsigned long events[NR_VM_EVENT_ITEMS];
+ struct sysinfo i;
+ unsigned off = offsetof(struct virtio_balloon_config, stats);
+
+ all_vm_events(events);
+
+ update_stat(vb-vdev, VIRTIO_BALLOON_F_RPT_SWAP_IN, events[PSWPIN],
+ off + offsetof(struct virtio_balloon_stats, pswapin));
+ update_stat(vb-vdev, VIRTIO_BALLOON_F_RPT_SWAP_OUT, events[PSWPOUT],
+ off + offsetof(struct virtio_balloon_stats, pswapout));
+ update_stat(vb-vdev, VIRTIO_BALLOON_F_RPT_MAJFLT, events[PGMAJFAULT],
+ off + offsetof(struct virtio_balloon_stats, pgmajfault));
+ update_stat(vb-vdev, VIRTIO_BALLOON_F_RPT_MINFLT, events[PGFAULT],
+ off + offsetof(struct virtio_balloon_stats, pgminfault));
+ update_stat(vb-vdev, VIRTIO_BALLOON_F_RPT_ANON,
+ K(global_page_state(NR_ANON_PAGES)),
+ off + offsetof(struct virtio_balloon_stats, panon));
+ si_meminfo(i);
+ update_stat(vb-vdev, VIRTIO_BALLOON_F_RPT_MEMFREE, K(i.freeram),
+ off + offsetof(struct virtio_balloon_stats, memfree));
+ update_stat(vb-vdev, VIRTIO_BALLOON_F_RPT_MEMTOT, K(i.totalram),
+ off + offsetof(struct virtio_balloon_stats, memtot));
+}
+
static int balloon(void *_vballoon)
{
struct virtio_balloon *vb = _vballoon;
@@ -189,15 +224,17 @@ static int balloon(void *_vballoon)
s64 diff;
try_to_freeze();
- wait_event_interruptible(vb-config_change,
+ wait_event_interruptible_timeout(vb-config_change,
(diff = towards_target(vb)) != 0
|| kthread_should_stop()
-|| freezing(current));
+|| freezing(current),
+VIRTIO_BALLOON_TIMEOUT);
if (diff 0)
fill_balloon(vb, diff);
else if (diff 0)
leak_balloon(vb, -diff);
update_balloon_size(vb);
+ update_balloon_stats(vb);
}
return 0;
}
@@ -265,7 +302,12 @@ static void virtballoon_remove(struct virtio_device *vdev)
kfree(vb);
}
-static unsigned int features[] = { VIRTIO_BALLOON_F_MUST_TELL_HOST };
+static unsigned int features[] = {
+ VIRTIO_BALLOON_F_MUST_TELL_HOST, VIRTIO_BALLOON_F_RPT_SWAP_IN,
+ VIRTIO_BALLOON_F_RPT_SWAP_OUT, VIRTIO_BALLOON_F_RPT_ANON,
+ VIRTIO_BALLOON_F_RPT_MAJFLT, VIRTIO_BALLOON_F_RPT_MINFLT,
+ VIRTIO_BALLOON_F_RPT_MEMFREE, VIRTIO_BALLOON_F_RPT_MEMTOT,
+};
static struct virtio_driver virtio_balloon = {
.feature_table = features,
diff --git a/include/linux/virtio_balloon.h b/include/linux/virtio_balloon.h
index 09d7300..0bff4b8 100644
--- a/include/linux/virtio_balloon.h
+++ b/include/linux/virtio_balloon.h
@@ -6,15 +6,39 @@
/* The feature bitmap for virtio balloon */
#define VIRTIO_BALLOON_F_MUST_TELL_HOST0 /* Tell before reclaiming
Re: [Qemu-devel] [PATCH 0/2] port over extboot from kvm
Gerd Hoffmann wrote: On 11/09/09 17:06, Paul Brook wrote: On Tuesday 08 September 2009, Anthony Liguori wrote: Gerd Hoffmann wrote: $subject says pretty much everything. extboot.[cS] are a straight copy from the kvm tree. The windup in vl,c and hw/pc.c is done slightly different, I've added a function to lookup the boot drive instead of adding a new global variable. I think the function here is high even if the implementation is ugly. In the past, Paul strongly objected to this. Paul, care to comment? Doesn't gpxe support virtio-blk, without requiring any additional qemu features? As far I know patches exist but where never merged. Also there is no way to boot from scsi+usb ... I think Kevin mentioned he would likely to usb boot support for SeaBIOS. Adding virtio-blk support to SeaBIOS would also be pretty reasonable. SCSI is a bit more tough. Doing an LSI driver in SeaBIOS would be a bit tougher. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH 3/4] S/390 host support for TCG
On Monday 02 November 2009, Aurelien Jarno wrote:
First of all I have a question about s390/s390x. It seems that you
plan to support both s390 and s390x in the same file. Is that correct?
Actually, I didn't think about supporting s390 hosts at all, but it
should be possible.
Do you know how far the 32-bit support is far from compiling/working?
It is not entirely unlikely that it's close. You obviously can't use the
64-bit instructions on a 31-bit host, but other than that...
Would it be really possible to support both in the same file?
It would, but we would need different implementations for the 64-bit
operations.
From a practical point of view, I don't see any merit in supporting
31-bit hosts, simply because there aren't many in use anymore. (It's a
different story for the target: 31-bit _software_ is still widespread.)
+SEARCH_DIR(/usr/s390x-suse-linux/lib64);
SEARCH_DIR(/usr/local/lib64); SEARCH_DIR(/lib64);
SEARCH_DIR(/usr/lib64); SEARCH_DIR(/usr/s390x-suse-linux/lib);
SEARCH_DIR(/usr/lib64); SEARCH_DIR(/usr/local/lib);
SEARCH_DIR(/lib); SEARCH_DIR(/usr/lib);
Why adding some search directories manually here? The one you are
adding are SuSE specific. They should already be detected by the
configure script and added to config-host.ld.
I merely copied the linker script and made some minor adjustments, I
didn't really pay much attention to what it actually contains...
+tcg_out32(s, 0xa784); /* je label1 (offset will be patched
in later) */
Would be nice to have the corresponding tcg_out_ function and the
corresponding value instead of the magic value. Also I am not sure the
comment is correct here, je being an x86_64 instruction.
objdump disassembles it as je, though the POP doesn't specify any
aliases for the different mask values for BRC.
+tcg_out_sh64(s, SH64_SRAG, data_reg, data_reg,
SH64_REG_NONE, 48); +break;
+case 2 | 4:
+tcg_out_b9(s, B9_LGFR, data_reg, arg0);
+break;
+case 0: case 1: case 2: case 3: default:
+/* unsigned - just copy */
+tcg_out_b9(s, B9_LGR, data_reg, arg0);
Is it always correct? On x86_64, starting with gcc 4.3, it is not
guaranteed anymore that non used bits are set to 0.
Do I understand you correctly in that you are suggesting to do an
explicit zero extension here? (But what does GCC have to do with
TCG-generated code?)
+case INDEX_op_call:
+//fprintf(stderr,op 0x%x call 0x%lx 0x%lx
0x%lx\n,opc,args[0],args[1],args[2]); +if (const_args[0]) {
+tcg_target_long off = (args[0] -
(tcg_target_long)s-code_ptr + 4) 1; /* FIXME: + 4? Where did
that come from? */ +if (off -0x8000 off
0x7fff) { /* relative call */ +tcg_out_brasl(s,
TCG_REG_R14, off 1);
+tcg_abort(); // untested
If not tested, it's probably better to remove this part and do not
mark call accepting constants.
I suppose so. It's obviously never used anyway.
+}
+else { /* too far for a relative call, load full
address */ +tcg_out_movi(s, TCG_TYPE_PTR,
TCG_REG_R13, args[0]); +tcg_out_rr(s, RR_BASR,
TCG_REG_R14, TCG_REG_R13);
Not sure it is very useful here. It's probably better to redefine the
constraints of the constant, so that the reg allocator use a register
to pass the value.
+}
+}
+else { /* call function in register args[0] */
+tcg_out_rr(s, RR_BASR, TCG_REG_R14, args[0]);
+}
+break;
+case INDEX_op_jmp:
+fprintf(stderr,op 0x%x jmp 0x%lx 0x%lx
0x%lx\n,opc,args[0],args[1],args[2]); +tcg_abort();
+break;
What about implementing that?
Do you know a target that actually uses it? I try to avoid implementing
stuff that I can't test.
+static inline void tcg_out_addi(TCGContext *s, int reg,
tcg_target_long val) +{
+tcg_abort();
+}
Why this one is not implemented? This is definitely needed so that
arguments can be passed on the stack.
Generally, if something is not implemented yet it's because it has never
been used anywhere.
+#define TCG_TARGET_HAS_div_i32
+#undef TCG_TARGET_HAS_div_i64
Is that corrects? It looks strange an architecture has different
division in 32- and 64-bits mode.
The 64-bit instruction set actually has both. Maybe I just forgot to
implement it.
CU
Uli
--
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
Re: [Qemu-devel] [PATCH 2/9] S/390 CPU emulation
On Monday 02 November 2009, Laurent Desnogues wrote: That indeed looks strange: fixing the TB chaining on ARM made nbench i386 three times faster. Note the gain was less for FP parts of the benchmark due to the use of helpers. out of curiosity could you post your tb_set_jmp_target1 function? I'm on an AMD64 host, so it's the same code as in mainline. The only thing I can think of at the moment that could make the code slower is that the program you ran was not reusing blocks and/or cache flushing in tb_set_jmp_target1 is overkill. There is no cache flushing in the AMD64 tb_set_jmp_target1() function, and the polarssl test suite is by nature rather repetitive. I did some experiments, and it seems disabling the TB chaining (by emptying tb_set_jmp_target()) does not have any impact on performance at all on AMD64. I tested it with several CPU-intensive programs (md5sum and the like) with AMD64 on AMD64 userspace emulation (qemu-x86_64), and the difference in performance with TB chaining and without is hardly measurable. The chaining is performed as advertised if enabled, I checked that, but it does not seem to help performance. How is this possible? Could this be related to cache size? I suspect the Phenom 9500 of mine is better equipped in that area than the average ARM controller. And does the TB chaining actually work on AMD64 at all? I checked by adding some debug output, and it seems to patch the jumps correctly, but maybe somebody can verify that. CU Uli -- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
[Qemu-devel] git submodules (.gitmodules) incorrect
Current .gitmodules contains: [submodule roms/vgabios] path = roms/vgabios url = ../vgabios.git [submodule roms/seabios] path = roms/seabios url = ../seabios.git but these URLs don't work for me. They resolve to URLs like git://git.savannah.nongnu.org/seabios.git which just gives a fatal error when you try to access it: fatal: The remote end hung up unexpectedly Also isn't there supposed to be a pc-bios git submodule? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top
Re: [Qemu-devel] [RFC] virtio: Report new guest memory statistics pertinent to memory ballooning (V2)
Adam Litke wrote: +s-stats.pswapin = has_feature(dev, VIRTIO_BALLOON_F_RPT_SWAP_OUT) ? + dev-stats.pswapin : -1; (etc.) Why not simply have the guest fill in the unused fields with -1, and say that's how no meaningful value is represented in the ABI? All guests have to know about all those fields anyway, for the structure layout. Is there any benefit to specifying feature bits in advance over simply storing -1 there? -- Jamie
Re: [Qemu-devel] [RFC] virtio: Report new guest memory statistics pertinent to memory ballooning (V2)
Adam Litke wrote:
+static inline void print_stat(Monitor *mon, uint32_t val, const char *label)
+{
+if (val != -1) {
+monitor_printf(mon, ,%s=%u, label, val);
+}
+}
+
static void do_info_balloon(Monitor *mon)
{
-ram_addr_t actual;
+QEMUBalloonState s;
+int ret;
-actual = qemu_balloon_status();
-if (kvm_enabled() !kvm_has_sync_mmu())
+ret = qemu_balloon_status(s);
+if (kvm_enabled() !kvm_has_sync_mmu()) {
monitor_printf(mon, Using KVM without synchronous MMU,
ballooning disabled\n);
-else if (actual == 0)
+} else if (ret 0) {
monitor_printf(mon, Ballooning not activated in VM\n);
-else
-monitor_printf(mon, balloon: actual=%d\n, (int)(actual 20));
+} else {
+monitor_printf(mon, balloon: actual=%d, (int)(s.actual 20));
+print_stat(mon, s.stats.pswapin, pages_swapped_in);
+print_stat(mon, s.stats.pswapout, pages_swapped_out);
+print_stat(mon, s.stats.panon, anon_pages);
+print_stat(mon, s.stats.pgmajfault, major_page_faults);
+print_stat(mon, s.stats.pgminfault, minor_page_faults);
+print_stat(mon, s.stats.memfree, free_memory);
+print_stat(mon, s.stats.memtot, total_memory);
+monitor_printf(mon, \n);
+}
+
}
These days, would it make more sense to emit a QJSON object?
In this case the JSON object is quite human readable too.
-- Jamie
Re: [Qemu-devel] [RFC] virtio: Report new guest memory statistics pertinent to memory ballooning (V2)
On Mon, 2009-11-09 at 19:00 +, Jamie Lokier wrote: Adam Litke wrote: +s-stats.pswapin = has_feature(dev, VIRTIO_BALLOON_F_RPT_SWAP_OUT) ? + dev-stats.pswapin : -1; (etc.) Why not simply have the guest fill in the unused fields with -1, and say that's how no meaningful value is represented in the ABI? All guests have to know about all those fields anyway, for the structure layout. Is there any benefit to specifying feature bits in advance over simply storing -1 there? This holds true for fields that exist but might not be supported by a guest, but what about the case where we add a new field? In that case, qemu and the guest may disagree on the structure layout. -- Thanks, Adam
Re: [Qemu-devel] [PATCH 4/4] Add support for -net bridge
Anthony Liguori wrote: You are correct except that I qualified this as NAT with host access which so far is the common model. If the host can access the NAT'd network behind the NAT, then port privileges are important. You're right. This is why QEMU guests should be run inside an LXC container :-) Or in the general case, a security-conscious net-setup script should ensure general user invocations are limited to admin-decided subnets with admin-decided firewall rules, so that they just look like processes with ordinary access to everything else. Iptables being what it is, that'd have to be distro specific and sometimes site specific. -- Jamie
Re: [Qemu-devel] [RFC] virtio: Report new guest memory statistics pertinent to memory ballooning (V2)
On Mon, 2009-11-09 at 19:01 +, Jamie Lokier wrote: These days, would it make more sense to emit a QJSON object? In this case the JSON object is quite human readable too. I'm not very particular on the output format since it's main consumer is likely another program. Is XML output via the monitor a new precedent in qemu? I was unable to find any other monitor command that emits XML. -- Thanks, Adam
Re: [Qemu-devel] [PATCH 0/4] net-bridge: rootless bridge support for qemu
Avi Kivity wrote: On 11/07/2009 12:44 PM, Jamie Lokier wrote: Aiee - what's the plan? Can a running KVM be forked, as in into two separate processes to run the forked guests in parallel, or not? kvm fds do not support fork(). Nothing prevents you from stopping the guest, reading guest state, fork()ing, and creating a new VM in the child with the same state, then restarting both instances. qemu in general cannot be forked; the two instances would trample on each others disk images, host network connections (i.e. vnc, X, the monitor), guest network connections, etc. Oh, I understand that qemu forking is fraught. It would need to fork at just the right moment and recreate all sorts of things. And I'm not surprised that the kvm fd does not fork. Why should it? fds refer to device instances, and fork does not generally create new instances. What I'd like to know is, if all of QEMU's state is appropriately recreated in the child instance, and KVM's device is reopened with a copy of the kvm state (by using the recently introduced ioctls to get and set it), will it fork the _guest RAM_ mapped into KVM in the way that fork does? Or is it necessary to copy all the guest RAM from original instance into the new ones, so that there must be multiple copies of all the guest RAM pages, even if they are the same? What I have in mind is a test state server, which is a KVM instance halted in a state where loadvm has loaded up all of guest memory in a state where the guest is ready to do something. Incoming requests cause that server to fork off and start all the device emulations, open network connections, create -snapshot qcow2 temporary fork files, etc., so the forked child is a running VM, doing whatever it was poised to do, with no permanent effect. (Naturally the guest would have to be in a usefully prepared state, probably it's just about to run a network config script to get it's per-instance settings and then fetch a test script to run.) Basically, will KVM (the kernel bits) work using guest RAM which is shared with other guest instances and a non-guest instance (the parent process which hasn't yet started KVM) in that way? Will KVM (the kernel bits) also work the other way, where it is paused and all the devices closed (as if we're doing savevm and shutting down), but instead of saving and unmapping guest memory, only the device state is savevm'd, that's used to put it into the halted state described above, from which it's able to reload device state and continue? In a nutshell, does KVM mind the guest's memory pages (including device memory like framebuffers) being COW-shared in all the ways that fork() can cause? I know it's an arcane question, so thanks a lot if you answer! :-) -- Jamie
Re: [Qemu-devel] [PATCH 9/9] Move mp_state to CPU_COMMON
Alexander Graf wrote: On 29.10.2009, at 22:39, Hollis Blanchard wrote: On Wed, 2009-10-21 at 21:17 +0200, Alexander Graf wrote: MP State is implemented in the generic code, so let's move the variable it accesses to generic code as well. Still unbreaks PPC and now even S390x w/ KVM. Signed-off-by: Alexander Graf ag...@suse.de Acked-by: Hollis Blanchard holl...@us.ibm.com Anthony, this patch fixes a build break in PowerPC KVM. Arguably it should not be patch 9/9 in an S390 series, but in any case please apply it. :) Anthony, could you please apply it? Not having S390 support is pitiful, but having PPC break too is even worse! mp_state does not belong in CPU_COMMON. Regards, Anthony Liguori Alex
Re: [Qemu-devel] [PATCH 9/9] Move mp_state to CPU_COMMON
On 09.11.2009, at 20:44, Anthony Liguori wrote: Alexander Graf wrote: On 29.10.2009, at 22:39, Hollis Blanchard wrote: On Wed, 2009-10-21 at 21:17 +0200, Alexander Graf wrote: MP State is implemented in the generic code, so let's move the variable it accesses to generic code as well. Still unbreaks PPC and now even S390x w/ KVM. Signed-off-by: Alexander Graf ag...@suse.de Acked-by: Hollis Blanchard holl...@us.ibm.com Anthony, this patch fixes a build break in PowerPC KVM. Arguably it should not be patch 9/9 in an S390 series, but in any case please apply it. :) Anthony, could you please apply it? Not having S390 support is pitiful, but having PPC break too is even worse! mp_state does not belong in CPU_COMMON. So you'd rather like a patch #ifdef'ing out the mp code to x86 only? Or move it to target-i386/kvm.c? Alex
Re: [Qemu-devel] [sneak preview] major scsi overhaul
On Mon, Nov 9, 2009 at 2:37 PM, Avi Kivity a...@redhat.com wrote: On 11/09/2009 11:08 AM, Gerd Hoffmann wrote: You are also moving the compilation to Makefile.hw, which is not exactly an improvement. Is this needed because of the QEMUIOVector stuff? Almost correct ;) It is because of QEMUSGList which drags in a target_phys_addr_t dependency. As Michael notes, devices have physical address sizes independent of the target platform; a PCI device that supports 64-bit addresses can be plugged into a motherboard that supports 32-bit address bus processors. True. But I think the solution is not to make all buses maximum width, but support multiple buses with width translation in between. We can fix this in several ways: - creating QEMUSG64List and QEMUSG32List (and typedefing PCISGList to the former) - making QEMUSGList always use 64-bit addresses since it will almost always be used with devices (which are often 64-bit capable) - making target_phys_addr_t always 64-bit (which loses some performance with 32-on-32 emulation) - others? We could improve the compilation system so that on 64 bit hosts the benefit of single size target_phys_addr_t results in compiling the files only once.
[PATCH 0 of 2] Fix PowerPC KVM build breaks
Hi Anthony, please apply these two patches to fix the PowerPC KVM build. -Hollis -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1 of 2] kvm: Move KVM mp_state accessors to i386-specific code
Unbreaks PowerPC and S390 KVM builds.
Signed-off-by: Hollis Blanchard holl...@us.ibm.com
diff --git a/kvm-all.c b/kvm-all.c
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -207,26 +207,6 @@ err:
return ret;
}
-int kvm_put_mp_state(CPUState *env)
-{
-struct kvm_mp_state mp_state = { .mp_state = env-mp_state };
-
-return kvm_vcpu_ioctl(env, KVM_SET_MP_STATE, mp_state);
-}
-
-int kvm_get_mp_state(CPUState *env)
-{
-struct kvm_mp_state mp_state;
-int ret;
-
-ret = kvm_vcpu_ioctl(env, KVM_GET_MP_STATE, mp_state);
-if (ret 0) {
-return ret;
-}
-env-mp_state = mp_state.mp_state;
-return 0;
-}
-
/*
* dirty pages logging control
*/
diff --git a/kvm.h b/kvm.h
--- a/kvm.h
+++ b/kvm.h
@@ -74,9 +74,6 @@ int kvm_vm_ioctl(KVMState *s, int type,
int kvm_vcpu_ioctl(CPUState *env, int type, ...);
-int kvm_get_mp_state(CPUState *env);
-int kvm_put_mp_state(CPUState *env);
-
/* Arch specific hooks */
int kvm_arch_post_run(CPUState *env, struct kvm_run *run);
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -659,6 +659,26 @@ static int kvm_get_msrs(CPUState *env)
return 0;
}
+static int kvm_put_mp_state(CPUState *env)
+{
+struct kvm_mp_state mp_state = { .mp_state = env-mp_state };
+
+return kvm_vcpu_ioctl(env, KVM_SET_MP_STATE, mp_state);
+}
+
+static int kvm_get_mp_state(CPUState *env)
+{
+struct kvm_mp_state mp_state;
+int ret;
+
+ret = kvm_vcpu_ioctl(env, KVM_GET_MP_STATE, mp_state);
+if (ret 0) {
+return ret;
+}
+env-mp_state = mp_state.mp_state;
+return 0;
+}
+
int kvm_arch_put_registers(CPUState *env)
{
int ret;
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2 of 2] kvm ppc: Remove unused label
Signed-off-by: Hollis Blanchard holl...@us.ibm.com diff --git a/target-ppc/kvm_ppc.c b/target-ppc/kvm_ppc.c --- a/target-ppc/kvm_ppc.c +++ b/target-ppc/kvm_ppc.c @@ -52,7 +52,6 @@ close: fclose(f); free: free(path); -out: return ret; } -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [RFC] virtio: Report new guest memory statistics pertinent to memory ballooning (V2)
Jamie Lokier wrote: Adam Litke wrote: +s-stats.pswapin = has_feature(dev, VIRTIO_BALLOON_F_RPT_SWAP_OUT) ? + dev-stats.pswapin : -1; (etc.) Why not simply have the guest fill in the unused fields with -1, and say that's how no meaningful value is represented in the ABI? All guests have to know about all those fields anyway, for the structure layout. Is there any benefit to specifying feature bits in advance over simply storing -1 there? Features are negotiated. It lets a host advertise the support of a feature and it lets the guest acknowledge it's support of a feature. Most importantly, why invent a new mechanism when we already have one? -- Regards, Anthony Liguori
Re: [Qemu-devel] [sneak preview] major scsi overhaul
On 11/09/09 21:38, Blue Swirl wrote: As Michael notes, devices have physical address sizes independent of the target platform; a PCI device that supports 64-bit addresses can be plugged into a motherboard that supports 32-bit address bus processors. True. But I think the solution is not to make all buses maximum width, but support multiple buses with width translation in between. I suspect translating between 32 and 64 bit is more complex and more overhead than simply using 64bit all the time. We could improve the compilation system so that on 64 bit hosts the benefit of single size target_phys_addr_t results in compiling the files only once. I think this is already the case. When building on x86_64 host (both 32bit and 64bit targets) I find the libhw32 directory empty ... cheers, Gerd
Re: [PATCH 1 of 2] kvm: Move KVM mp_state accessors to i386-specific code
Hollis Blanchard wrote:
Unbreaks PowerPC and S390 KVM builds.
What breaks precisely?
Note that KVM_GET/SET_MP_STATE are generic IOCTLs and supposed to be
shared with ia64 - one day. We could still move things back then, but
maybe we can handle the build issues already in place, specifically as
qemu-kvm is carrying this in generic code since ages.
Jan
Signed-off-by: Hollis Blanchard holl...@us.ibm.com
diff --git a/kvm-all.c b/kvm-all.c
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -207,26 +207,6 @@ err:
return ret;
}
-int kvm_put_mp_state(CPUState *env)
-{
-struct kvm_mp_state mp_state = { .mp_state = env-mp_state };
-
-return kvm_vcpu_ioctl(env, KVM_SET_MP_STATE, mp_state);
-}
-
-int kvm_get_mp_state(CPUState *env)
-{
-struct kvm_mp_state mp_state;
-int ret;
-
-ret = kvm_vcpu_ioctl(env, KVM_GET_MP_STATE, mp_state);
-if (ret 0) {
-return ret;
-}
-env-mp_state = mp_state.mp_state;
-return 0;
-}
-
/*
* dirty pages logging control
*/
diff --git a/kvm.h b/kvm.h
--- a/kvm.h
+++ b/kvm.h
@@ -74,9 +74,6 @@ int kvm_vm_ioctl(KVMState *s, int type,
int kvm_vcpu_ioctl(CPUState *env, int type, ...);
-int kvm_get_mp_state(CPUState *env);
-int kvm_put_mp_state(CPUState *env);
-
/* Arch specific hooks */
int kvm_arch_post_run(CPUState *env, struct kvm_run *run);
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -659,6 +659,26 @@ static int kvm_get_msrs(CPUState *env)
return 0;
}
+static int kvm_put_mp_state(CPUState *env)
+{
+struct kvm_mp_state mp_state = { .mp_state = env-mp_state };
+
+return kvm_vcpu_ioctl(env, KVM_SET_MP_STATE, mp_state);
+}
+
+static int kvm_get_mp_state(CPUState *env)
+{
+struct kvm_mp_state mp_state;
+int ret;
+
+ret = kvm_vcpu_ioctl(env, KVM_GET_MP_STATE, mp_state);
+if (ret 0) {
+return ret;
+}
+env-mp_state = mp_state.mp_state;
+return 0;
+}
+
int kvm_arch_put_registers(CPUState *env)
{
int ret;
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 1 of 2] kvm: Move KVM mp_state accessors to i386-specific code
On 09.11.2009, at 23:12, Jan Kiszka wrote: Hollis Blanchard wrote: Unbreaks PowerPC and S390 KVM builds. What breaks precisely? Note that KVM_GET/SET_MP_STATE are generic IOCTLs and supposed to be shared with ia64 - one day. We could still move things back then, but maybe we can handle the build issues already in place, specifically as qemu-kvm is carrying this in generic code since ages. The generic code tries to access env-mp_state which doesn't exist in PPC's env because it's only defined in the X86 env. I honestly don't care where to move things. And I don't think anyone else should. Either move it to CPU_COMMON if you think it's generic or move the code to the platform specific part. We've been going through this at least 2 times in previous threads. But qemu HEAD has been broken for PPC kvm since MP states got introduced and it's no fun talking against walls on this. Alex -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Qemu-devel] Re: [PATCH 1 of 2] kvm: Move KVM mp_state accessors to i386-specific code
This is the technique Anthony requested this morning, rather than
relocating mp_state. To be honest, I don't care which way it's fixed;
this is at least the 3rd patch to solve this seemingly trivial
problem.
/home/hollisb/source/qemu-fresh.hg/kvm-all.c: In function 'kvm_put_mp_state':
/home/hollisb/source/qemu-fresh.hg/kvm-all.c:212: error: 'struct
CPUPPCState' has no member named 'mp_state'
-Hollis
On Mon, Nov 9, 2009 at 2:12 PM, Jan Kiszka jan.kis...@web.de wrote:
Hollis Blanchard wrote:
Unbreaks PowerPC and S390 KVM builds.
What breaks precisely?
Note that KVM_GET/SET_MP_STATE are generic IOCTLs and supposed to be
shared with ia64 - one day. We could still move things back then, but
maybe we can handle the build issues already in place, specifically as
qemu-kvm is carrying this in generic code since ages.
Jan
Signed-off-by: Hollis Blanchard holl...@us.ibm.com
diff --git a/kvm-all.c b/kvm-all.c
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -207,26 +207,6 @@ err:
return ret;
}
-int kvm_put_mp_state(CPUState *env)
-{
- struct kvm_mp_state mp_state = { .mp_state = env-mp_state };
-
- return kvm_vcpu_ioctl(env, KVM_SET_MP_STATE, mp_state);
-}
-
-int kvm_get_mp_state(CPUState *env)
-{
- struct kvm_mp_state mp_state;
- int ret;
-
- ret = kvm_vcpu_ioctl(env, KVM_GET_MP_STATE, mp_state);
- if (ret 0) {
- return ret;
- }
- env-mp_state = mp_state.mp_state;
- return 0;
-}
-
/*
* dirty pages logging control
*/
diff --git a/kvm.h b/kvm.h
--- a/kvm.h
+++ b/kvm.h
@@ -74,9 +74,6 @@ int kvm_vm_ioctl(KVMState *s, int type,
int kvm_vcpu_ioctl(CPUState *env, int type, ...);
-int kvm_get_mp_state(CPUState *env);
-int kvm_put_mp_state(CPUState *env);
-
/* Arch specific hooks */
int kvm_arch_post_run(CPUState *env, struct kvm_run *run);
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -659,6 +659,26 @@ static int kvm_get_msrs(CPUState *env)
return 0;
}
+static int kvm_put_mp_state(CPUState *env)
+{
+ struct kvm_mp_state mp_state = { .mp_state = env-mp_state };
+
+ return kvm_vcpu_ioctl(env, KVM_SET_MP_STATE, mp_state);
+}
+
+static int kvm_get_mp_state(CPUState *env)
+{
+ struct kvm_mp_state mp_state;
+ int ret;
+
+ ret = kvm_vcpu_ioctl(env, KVM_GET_MP_STATE, mp_state);
+ if (ret 0) {
+ return ret;
+ }
+ env-mp_state = mp_state.mp_state;
+ return 0;
+}
+
int kvm_arch_put_registers(CPUState *env)
{
int ret;
Re: [PATCH 1 of 2] kvm: Move KVM mp_state accessors to i386-specific code
Hollis Blanchard wrote:
This is the technique Anthony requested this morning, rather than
relocating mp_state.
Then let's move it. There is not that much code to share anyway.
To be honest, I don't care which way it's fixed;
this is at least the 3rd patch to solve this seemingly trivial
problem.
That's indeed unfortunate, but I think to remember that not all of these
attempts were clean.
Jan
/home/hollisb/source/qemu-fresh.hg/kvm-all.c: In function 'kvm_put_mp_state':
/home/hollisb/source/qemu-fresh.hg/kvm-all.c:212: error: 'struct
CPUPPCState' has no member named 'mp_state'
-Hollis
On Mon, Nov 9, 2009 at 2:12 PM, Jan Kiszka jan.kis...@web.de wrote:
Hollis Blanchard wrote:
Unbreaks PowerPC and S390 KVM builds.
What breaks precisely?
Note that KVM_GET/SET_MP_STATE are generic IOCTLs and supposed to be
shared with ia64 - one day. We could still move things back then, but
maybe we can handle the build issues already in place, specifically as
qemu-kvm is carrying this in generic code since ages.
Jan
Signed-off-by: Hollis Blanchard holl...@us.ibm.com
diff --git a/kvm-all.c b/kvm-all.c
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -207,26 +207,6 @@ err:
return ret;
}
-int kvm_put_mp_state(CPUState *env)
-{
-struct kvm_mp_state mp_state = { .mp_state = env-mp_state };
-
-return kvm_vcpu_ioctl(env, KVM_SET_MP_STATE, mp_state);
-}
-
-int kvm_get_mp_state(CPUState *env)
-{
-struct kvm_mp_state mp_state;
-int ret;
-
-ret = kvm_vcpu_ioctl(env, KVM_GET_MP_STATE, mp_state);
-if (ret 0) {
-return ret;
-}
-env-mp_state = mp_state.mp_state;
-return 0;
-}
-
/*
* dirty pages logging control
*/
diff --git a/kvm.h b/kvm.h
--- a/kvm.h
+++ b/kvm.h
@@ -74,9 +74,6 @@ int kvm_vm_ioctl(KVMState *s, int type,
int kvm_vcpu_ioctl(CPUState *env, int type, ...);
-int kvm_get_mp_state(CPUState *env);
-int kvm_put_mp_state(CPUState *env);
-
/* Arch specific hooks */
int kvm_arch_post_run(CPUState *env, struct kvm_run *run);
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -659,6 +659,26 @@ static int kvm_get_msrs(CPUState *env)
return 0;
}
+static int kvm_put_mp_state(CPUState *env)
+{
+struct kvm_mp_state mp_state = { .mp_state = env-mp_state };
+
+return kvm_vcpu_ioctl(env, KVM_SET_MP_STATE, mp_state);
+}
+
+static int kvm_get_mp_state(CPUState *env)
+{
+struct kvm_mp_state mp_state;
+int ret;
+
+ret = kvm_vcpu_ioctl(env, KVM_GET_MP_STATE, mp_state);
+if (ret 0) {
+return ret;
+}
+env-mp_state = mp_state.mp_state;
+return 0;
+}
+
int kvm_arch_put_registers(CPUState *env)
{
int ret;
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] SPARC user mode multithread
I just patched and ran with two of the programs with from the parsec suite and they both run with the small input sets. I will run the full suite later tonight and let you know the results. Thanks for the help, David - Original Message - From: Blue Swirl blauwir...@gmail.com To: David Munday cro...@soe.ucsc.edu Cc: qemu-devel@nongnu.org Sent: Sunday, November 8, 2009 11:28:21 AM GMT -08:00 US/Canada Pacific Subject: Re: [Qemu-devel] SPARC user mode multithread On Fri, Nov 6, 2009 at 9:10 PM, David Munday cro...@soe.ucsc.edu wrote: Hi, Sorry forgot attachment! I have attached it to this email now. I also noticed that the last line should assign the pid to the child, but I didn't see where I can find that info and pass it into the cpu_clone_regs function. Could you test if this patch helps?
[Qemu-devel] Re: virtio: Add memory statistics reporting to the balloon driver
On Tue, 10 Nov 2009 03:02:06 am Adam Litke wrote: A simpler approach is to collect memory statistics in the virtio balloon driver and communicate them to the host via the device config space. There are two issues I see with this. First, there's an atomicity problem since you can't tell when the stats are consistent. Second, polling is ugly. A stats vq might solve this more cleanly? Rusty.
Re: [Qemu-devel] don't look for libuuid on Darwin
On Nov 9, 2009, at 12:22 PM, Christoph Hellwig wrote: On Mon, Nov 09, 2009 at 11:46:13AM -0700, C.W. Betts wrote: Does this work? diff --git a/configure b/configure index aa2cc43..00e04e9 100755 --- a/configure +++ b/configure @@ -1060,7 +1060,11 @@ fi ## # uuid_generate() probe, used for vdi block driver if test $uuid != no ; then - uuid_libs=-luuid + if test $darwin == yes; then +uuid_libs= + else +uuid_libs=-luuid + fi It might work, but does Darwin really provide no libuuid at all? I thought it was just the static one that is missing? The uuid definitions are in the libSystem library, which everything links against. LibSystem also includes libc, libm, pthreads, etc. If it really is the case a comment above the test would help. Also I think you should try to keep the mailinglist on Cc - it includes people that can provide valueable feedback, and also people that unlike me can actually apply the patch to the qemu repository. heh, sorry. I replied to the wrong message.
[Qemu-devel] Share the file between guest and host OS ?
hi everyone : Resently I used the QEMU to install XP system ,and the OS of my PC is XP ,too. but how to install the other software on the XP system which is on the top of qemu? I have searched some methods through google ,like using USB, or ISO , or FTP and so on , and there so many methods about connecting between the linux and windows ,but just a little infomation about how to connect all the guest and the host os is XP . maybe there is a good method you know , could you give me a suggestion ! Now I try to use the ISO or USB ! look forword to your answer! thanks very much! ---yuanzhu 11.10
