[COMMIT master] pci passthrough: zap option rom scanning.
From: Gerd Hoffmann kra...@redhat.com
Nowdays (qemu 0.12) seabios loads option roms from pci rom bars. So
there is no need any more to scan for option roms and have qemu load
them. Zap the code.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/hw/device-assignment.c b/hw/device-assignment.c
index f4a1e32..e347d15 100644
--- a/hw/device-assignment.c
+++ b/hw/device-assignment.c
@@ -1498,77 +1498,6 @@ void add_assigned_devices(PCIBus *bus, const char
**devices, int n_devices)
}
}
-/* Option ROM header */
-struct option_rom_header {
-uint8_t signature[2];
-uint8_t rom_size;
-uint32_t entry_point;
-uint8_t reserved[17];
-uint16_t pci_header_offset;
-uint16_t expansion_header_offset;
-} __attribute__ ((packed));
-
-/* Option ROM PCI data structure */
-struct option_rom_pci_header {
-uint8_t signature[4];
-uint16_t vendor_id;
-uint16_t device_id;
-uint16_t vital_product_data_offset;
-uint16_t structure_length;
-uint8_t structure_revision;
-uint8_t class_code[3];
-uint16_t image_length;
-uint16_t image_revision;
-uint8_t code_type;
-uint8_t indicator;
-uint16_t reserved;
-} __attribute__ ((packed));
-
-/*
- * Scan the list of Option ROMs at roms. If a suitable Option ROM is found,
- * allocate a ram space and copy it there. Then return its size aligned to
- * both 2KB and target page size.
- */
-#define OPTION_ROM_ALIGN(x) (((x) + 2047) ~2047)
-static void scan_option_rom(const char *name, uint8_t devfn, void *roms)
-{
-int i, size;
-uint8_t csum;
-struct option_rom_header *rom;
-struct option_rom_pci_header *pcih;
-
-rom = roms;
-
-for ( ; ; ) {
-/* Invalid signature means we're out of option ROMs. */
-if (strncmp((char *)rom-signature, \x55\xaa, 2) ||
- (rom-rom_size == 0))
-break;
-
-size = rom-rom_size * 512;
-/* Invalid checksum means we're out of option ROMs. */
-csum = 0;
-for (i = 0; i size; i++)
-csum += ((uint8_t *)rom)[i];
-if (csum != 0)
-break;
-
-/* Check the PCI header (if any) for a match. */
-pcih = (struct option_rom_pci_header *)
-((char *)rom + rom-pci_header_offset);
-if ((rom-pci_header_offset != 0)
- !strncmp((char *)pcih-signature, PCIR, 4))
-goto found;
-
-rom = (struct option_rom_header *)((char *)rom + size);
-}
-return;
-
- found:
-rom_add_blob(name ? name : assigned device, rom, size, 0);
-return;
-}
-
/*
* Scan the assigned devices for the devices that have an option ROM, and then
* load the corresponding ROM data to RAM. If an error occurs while loading an
@@ -1632,9 +1561,5 @@ static void assigned_dev_load_option_rom(AssignedDevice
*dev)
size, PROT_READ);
}
-if (!dev-dev.qdev.hotplugged) {
-/* Scan the buffer for suitable ROMs and increase the offset */
-scan_option_rom(dev-dev.qdev.id, dev-dev.devfn, buf);
-}
free(buf);
}
--
To unsubscribe from this list: send the line unsubscribe kvm-commits in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[COMMIT master] kvm: qemu: Remove reminder for checking dmesg after emulation failure
From: Sheng Yang sh...@linux.intel.com User can use QEmu to get more information. E.g. using the QEmu built-in disassembly to get the failure instruction like(in the monitor): x /20i $eip to dump the code at $eip, or using x /20i $eip-20 to look around. Signed-off-by: Sheng Yang sh...@linux.intel.com Signed-off-by: Marcelo Tosatti mtosa...@redhat.com diff --git a/qemu-kvm.c b/qemu-kvm.c index 599c3d6..09a3076 100644 --- a/qemu-kvm.c +++ b/qemu-kvm.c @@ -892,7 +892,7 @@ static int kvm_handle_internal_error(kvm_context_t kvm, #endif kvm_show_regs(env); if (run-internal.suberror == KVM_INTERNAL_ERROR_EMULATION) -fprintf(stderr, emulation failure, check dmesg for details\n); +fprintf(stderr, emulation failure\n); vm_stop(0); return 1; } -- To unsubscribe from this list: send the line unsubscribe kvm-commits in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[COMMIT master] qemu-kvm: Detect availability of kvm_para.h
From: Jan Kiszka jan.kis...@web.de
Will be required for upstream's KVM cpuid, so qemu-kvm will probably
morph towards conditional paravirt support as well, depending on
CONFIG_KVM_PARA. Make it available already.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/configure b/configure
index 6ba565a..b6bebac 100755
--- a/configure
+++ b/configure
@@ -226,6 +226,7 @@ curses=
docs=
fdt=
kvm=
+kvm_para=
nptl=
sdl=
sparse=no
@@ -1445,6 +1446,13 @@ EOF
kvm_cflags=$kvm_cflags -idirafter $source_path/compat
if compile_prog $kvm_cflags ; then
kvm=yes
+cat $TMPC EOF
+#include linux/kvm_para.h
+int main(void) { return 0; }
+EOF
+if compile_prog $kvm_cflags ; then
+ kvm_para=yes
+fi
else
if test $kvm = yes ; then
if [ -x `which awk 2/dev/null` ] \
@@ -2559,6 +2567,9 @@ case $target_arch2 in
\( $target_arch2 = i386 -a $cpu = x86_64 \) \) ; then
echo CONFIG_KVM=y $config_target_mak
echo KVM_CFLAGS=$kvm_cflags $config_target_mak
+ if test $kvm_para = yes; then
+echo CONFIG_KVM_PARA=y $config_target_mak
+ fi
if test $kvm_cap_pit = yes ; then
echo CONFIG_KVM_PIT=y $config_target_mak
fi
--
To unsubscribe from this list: send the line unsubscribe kvm-commits in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[COMMIT master] qemu-kvm: Use kvm-kmod headers if available
From: Jan Kiszka jan.kis...@web.de Since kvm-kmod-2.6.32.2 we have an alternative source for recent KVM kernel headers. Use it when available and not overruled by --kerneldir. If there is no kvm-kmod and no --kerneldir, we continue to fall back to the qemu-kvm's kernel headers. Signed-off-by: Jan Kiszka jan.kis...@siemens.com Signed-off-by: Marcelo Tosatti mtosa...@redhat.com diff --git a/configure b/configure index 20c374a..6ba565a 100755 --- a/configure +++ b/configure @@ -1424,6 +1424,8 @@ EOF kvm_cflags=$kvm_cflags -I$kerneldir/arch/$cpu/include fi else +kvm_cflags=`pkg-config --cflags kvm-kmod 2 /dev/null` +if test $kvm_cflags = ; then case $cpu in i386 | x86_64) kvm_arch=x86 @@ -1438,6 +1440,7 @@ EOF kvm_cflags=-I$source_path/kvm/include kvm_cflags=$kvm_cflags -include $source_path/kvm/include/linux/config.h kvm_cflags=$kvm_cflags -I$source_path/kvm/include/$kvm_arch +fi fi kvm_cflags=$kvm_cflags -idirafter $source_path/compat if compile_prog $kvm_cflags ; then -- To unsubscribe from this list: send the line unsubscribe kvm-commits in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[COMMIT master] QMP: Emit Basic events
From: Luiz Capitulino lcapitul...@redhat.com
While testing QMP on qemu-kvm I found that it's not emitting basic
events like RESET or POWERDOWN.
The reason is that in QEMU upstream those events are triggered
in QEMU's main loop (ie. vl.c:main_loop()), but control doesn't
reach there in qemu-kvm as it has its own main loop in
qemu-kvm.c:kvm_main_loop().
This commit adds the same set of events there too.
NOTE: The STOP event is not being added because it should be
triggered in vm_stop() and not in the main loop, this will be
fixed upstream.
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/qemu-kvm.c b/qemu-kvm.c
index 1c34846..06706c9 100644
--- a/qemu-kvm.c
+++ b/qemu-kvm.c
@@ -17,6 +17,7 @@
#include block.h
#include compatfd.h
#include gdbstub.h
+#include monitor.h
#include qemu-kvm.h
#include libkvm.h
@@ -2124,11 +2125,14 @@ int kvm_main_loop(void)
vm_stop(0);
} else
break;
-} else if (qemu_powerdown_requested())
+} else if (qemu_powerdown_requested()) {
+monitor_protocol_event(QEVENT_POWERDOWN, NULL);
qemu_irq_raise(qemu_system_powerdown);
-else if (qemu_reset_requested())
+} else if (qemu_reset_requested()) {
+monitor_protocol_event(QEVENT_RESET, NULL);
qemu_kvm_system_reset();
-else if (kvm_debug_cpu_requested) {
+} else if (kvm_debug_cpu_requested) {
+monitor_protocol_event(QEVENT_DEBUG, NULL);
gdb_set_stop_cpu(kvm_debug_cpu_requested);
vm_stop(EXCP_DEBUG);
kvm_debug_cpu_requested = NULL;
--
To unsubscribe from this list: send the line unsubscribe kvm-commits in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[COMMIT master] Merge branch 'upstream-merge'
From: Marcelo Tosatti mtosa...@redhat.com * upstream-merge: (167 commits) Revert block: prevent multiwrite_merge from creating too large iovecs make: qemu-img depends on config-host.h reduce number of reinjects on ACK block: prevent multiwrite_merge from creating too large iovecs block: fix cache flushing in bdrv_commit virtio-console: qdev conversion, new virtio-serial-bus QMP: Fix asynchronous events delivery virtio: Remove duplicate macro definition for max. virtqueues, bump up the max vnc: Use inet_strfamily() net: inet_strfamily(): Better unknown family report net: Make inet_strfamily() public virtio-serial: Use MSI vectors for port virtqueues Move virtio-serial to Makefile.objs virtio-serial: Add a 'virtserialport' device for generic serial port support virtio-serial-bus: Add ability to hot-unplug ports virtio-serial-bus: Add a port 'name' property for port discovery in guests virtio-serial-bus: Maintain guest and host port open/close state Added drives' readonly option Documentation: Add missing documentation for qdev related command line options Disable fall-back to read-only when cannot open drive's file for read-write ... Signed-off-by: Marcelo Tosatti mtosa...@redhat.com -- To unsubscribe from this list: send the line unsubscribe kvm-commits in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[COMMIT master] Merge branch 'upstream-merge'
From: Marcelo Tosatti mtosa...@redhat.com * upstream-merge: (95 commits) bsd/darwin-user: mmap_frag() users only check for -1 error cris: Prettify register dumps. sparc32 don't mark page dirty when failing sparc64: implement basic IOMMU/interrupt handling Sparc64: byte swap IO port access virtio-blk: Fix error cases which ignored rerror/werror virtio-blk: Fix restart after read error cirrus: Properly re-register cirrus_linear_io_addr on vram unmap virtio_blk: Factor virtio_blk_handle_request out virtio-serial-bus: Fix bus initialisation and allow for bus identification softmmu: Dont clobber retaddr in slow_ldx(). Solaris: test for presence of commands with has() Add and use has() and path_of() funcs Check for sdl-config before calling it Monitor: Fix command execution regression sparc64: reimplement tick timers v4 sparc64: correct write extra bits to cwp Fix BSD build Fix regression in option parsing pflash: Buffer block writes ... Signed-off-by: Marcelo Tosatti mtosa...@redhat.com -- To unsubscribe from this list: send the line unsubscribe kvm-commits in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[COMMIT master] Synchronize kvm headers
From: Marcelo Tosatti mtosa...@redhat.com
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/kvm/include/linux/kvm.h b/kvm/include/linux/kvm.h
index db10887..3fd3371 100644
--- a/kvm/include/linux/kvm.h
+++ b/kvm/include/linux/kvm.h
@@ -181,6 +181,11 @@ struct kvm_run {
__u64 cr8;
__u64 apic_base;
+#ifdef __KVM_S390
+ /* the processor status word for s390 */
+ __u64 psw_mask; /* psw upper half */
+ __u64 psw_addr; /* psw lower half */
+#endif
union {
/* KVM_EXIT_UNKNOWN */
struct {
@@ -232,8 +237,6 @@ struct kvm_run {
/* KVM_EXIT_S390_SIEIC */
struct {
__u8 icptcode;
- __u64 mask; /* psw upper half */
- __u64 addr; /* psw lower half */
__u16 ipa;
__u32 ipb;
} s390_sieic;
@@ -492,6 +495,8 @@ struct kvm_ioeventfd {
#ifdef __KVM_HAVE_VCPU_EVENTS
#define KVM_CAP_VCPU_EVENTS 41
#endif
+#define KVM_CAP_S390_PSW 42
+#define KVM_CAP_PPC_SEGSTATE 43
#ifdef KVM_CAP_IRQ_ROUTING
diff --git a/kvm/include/x86/asm/kvm.h b/kvm/include/x86/asm/kvm.h
index 950df43..f46b79f 100644
--- a/kvm/include/x86/asm/kvm.h
+++ b/kvm/include/x86/asm/kvm.h
@@ -254,6 +254,10 @@ struct kvm_reinject_control {
__u8 reserved[31];
};
+/* When set in flags, include corresponding fields on KVM_SET_VCPU_EVENTS */
+#define KVM_VCPUEVENT_VALID_NMI_PENDING0x0001
+#define KVM_VCPUEVENT_VALID_SIPI_VECTOR0x0002
+
/* for KVM_GET/SET_VCPU_EVENTS */
struct kvm_vcpu_events {
struct {
--
To unsubscribe from this list: send the line unsubscribe kvm-commits in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[COMMIT master] Revert roms/seabios to commit id of 0.5.1
From: Marcelo Tosatti mtosa...@redhat.com Signed-off-by: Marcelo Tosatti mtosa...@redhat.com diff --git a/roms/seabios b/roms/seabios index 8362699..5da6833 16 --- a/roms/seabios +++ b/roms/seabios @@ -1 +1 @@ -Subproject commit 8362699269d7b3c816981be0e306d7531aa3ea1d +Subproject commit 5da68339ecf44677b8f4f115cdf3cb1da46a9f6c -- To unsubscribe from this list: send the line unsubscribe kvm-commits in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[COMMIT master] Fix device-assignment.c compilation without KVM_CAP_PCI_SEGMENT
From: Marcelo Tosatti mtosa...@redhat.com Signed-off-by: Marcelo Tosatti mtosa...@redhat.com diff --git a/hw/device-assignment.c b/hw/device-assignment.c index 315fc72..4522ef4 100644 --- a/hw/device-assignment.c +++ b/hw/device-assignment.c @@ -822,7 +822,9 @@ static int assign_device(AssignedDevice *dev) memset(assigned_dev_data, 0, sizeof(assigned_dev_data)); assigned_dev_data.assigned_dev_id = calc_assigned_dev_id(dev-h_segnr, dev-h_busnr, dev-h_devfn); +#ifdef KVM_CAP_PCI_SEGMENT assigned_dev_data.segnr = dev-h_segnr; +#endif assigned_dev_data.busnr = dev-h_busnr; assigned_dev_data.devfn = dev-h_devfn; -- To unsubscribe from this list: send the line unsubscribe kvm-commits in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[COMMIT master] enable PCI multiple-segments for pass-through device
From: Zhai, Edwin edwin.z...@intel.com
Enable optional parameter (default 0) - PCI segment (or domain) besides
BDF, when assigning PCI device to guest.
Signed-off-by: Zhai Edwin edwin.z...@intel.com
Acked-by: Chris Wright chr...@sous-sol.org
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/hw/device-assignment.c b/hw/device-assignment.c
index 869b71e..315fc72 100644
--- a/hw/device-assignment.c
+++ b/hw/device-assignment.c
@@ -595,8 +595,8 @@ static int get_real_device_id(const char *devpath, uint16_t
*val)
return get_real_id(devpath, device, val);
}
-static int get_real_device(AssignedDevice *pci_dev, uint8_t r_bus,
- uint8_t r_dev, uint8_t r_func)
+static int get_real_device(AssignedDevice *pci_dev, uint16_t r_seg,
+ uint8_t r_bus, uint8_t r_dev, uint8_t r_func)
{
char dir[128], name[128];
int fd, r = 0, v;
@@ -609,8 +609,8 @@ static int get_real_device(AssignedDevice *pci_dev, uint8_t
r_bus,
dev-region_number = 0;
-snprintf(dir, sizeof(dir), /sys/bus/pci/devices/:%02x:%02x.%x/,
-r_bus, r_dev, r_func);
+snprintf(dir, sizeof(dir), /sys/bus/pci/devices/%04x:%02x:%02x.%x/,
+r_seg, r_bus, r_dev, r_func);
snprintf(name, sizeof(name), %sconfig, dir);
@@ -752,9 +752,9 @@ static void free_assigned_device(AssignedDevice *dev)
}
}
-static uint32_t calc_assigned_dev_id(uint8_t bus, uint8_t devfn)
+static uint32_t calc_assigned_dev_id(uint16_t seg, uint8_t bus, uint8_t devfn)
{
-return (uint32_t)bus 8 | (uint32_t)devfn;
+return (uint32_t)seg 16 | (uint32_t)bus 8 | (uint32_t)devfn;
}
static void assign_failed_examine(AssignedDevice *dev)
@@ -763,9 +763,8 @@ static void assign_failed_examine(AssignedDevice *dev)
uint16_t vendor_id, device_id;
int r;
-/* XXX implement multidomain */
-sprintf(dir, /sys/bus/pci/devices/:%02x:%02x.%01x/,
- dev-host.bus, dev-host.dev, dev-host.func);
+sprintf(dir, /sys/bus/pci/devices/%04x:%02x:%02x.%01x/,
+dev-host.seg, dev-host.bus, dev-host.dev, dev-host.func);
sprintf(name, %sdriver, dir);
@@ -782,19 +781,19 @@ static void assign_failed_examine(AssignedDevice *dev)
}
fprintf(stderr, *** The driver '%s' is occupying your device
-%02x:%02x.%x.\n,
-ns, dev-host.bus, dev-host.dev, dev-host.func);
+%04x:%02x:%02x.%x.\n,
+ns, dev-host.seg, dev-host.bus, dev-host.dev, dev-host.func);
fprintf(stderr, ***\n);
fprintf(stderr, *** You can try the following commands to free it:\n);
fprintf(stderr, ***\n);
fprintf(stderr, *** $ echo \%04x %04x\ /sys/bus/pci/drivers/pci-stub/
new_id\n, vendor_id, device_id);
-fprintf(stderr, *** $ echo \:%02x:%02x.%x\ /sys/bus/pci/drivers/
+fprintf(stderr, *** $ echo \%04x:%02x:%02x.%x\ /sys/bus/pci/drivers/
%s/unbind\n,
-dev-host.bus, dev-host.dev, dev-host.func, ns);
-fprintf(stderr, *** $ echo \:%02x:%02x.%x\ /sys/bus/pci/drivers/
+dev-host.seg, dev-host.bus, dev-host.dev, dev-host.func, ns);
+fprintf(stderr, *** $ echo \%04x:%02x:%02x.%x\ /sys/bus/pci/drivers/
pci-stub/bind\n,
-dev-host.bus, dev-host.dev, dev-host.func);
+dev-host.seg, dev-host.bus, dev-host.dev, dev-host.func);
fprintf(stderr, *** $ echo \%04x %04x\ /sys/bus/pci/drivers/pci-stub
/remove_id\n, vendor_id, device_id);
fprintf(stderr, ***\n);
@@ -810,9 +809,20 @@ static int assign_device(AssignedDevice *dev)
struct kvm_assigned_pci_dev assigned_dev_data;
int r;
+#ifdef KVM_CAP_PCI_SEGMENT
+/* Only pass non-zero PCI segment to capable module */
+if (!kvm_check_extension(kvm_state, KVM_CAP_PCI_SEGMENT)
+dev-h_segnr) {
+fprintf(stderr, Can't assign device inside non-zero PCI segment
+as this KVM module doesn't support it.\n);
+return -ENODEV;
+}
+#endif
+
memset(assigned_dev_data, 0, sizeof(assigned_dev_data));
assigned_dev_data.assigned_dev_id =
- calc_assigned_dev_id(dev-h_busnr, dev-h_devfn);
+ calc_assigned_dev_id(dev-h_segnr, dev-h_busnr, dev-h_devfn);
+assigned_dev_data.segnr = dev-h_segnr;
assigned_dev_data.busnr = dev-h_busnr;
assigned_dev_data.devfn = dev-h_devfn;
@@ -867,7 +877,7 @@ static int assign_irq(AssignedDevice *dev)
memset(assigned_irq_data, 0, sizeof(assigned_irq_data));
assigned_irq_data.assigned_dev_id =
-calc_assigned_dev_id(dev-h_busnr, dev-h_devfn);
+calc_assigned_dev_id(dev-h_segnr, dev-h_busnr, dev-h_devfn);
assigned_irq_data.guest_irq = irq;
assigned_irq_data.host_irq = dev-real_device.irq;
#ifdef KVM_CAP_ASSIGN_DEV_IRQ
@@ -908,7 +918,7 @@ static void deassign_device(AssignedDevice *dev)
memset(assigned_dev_data, 0,
[COMMIT master] KVM: fix Hyper-V hypercall warnings and wrong mask value
From: Gleb Natapov g...@redhat.com
Fix compilation warnings and wrong mask value.
Signed-off-by: Gleb Natapov g...@redhat.com
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 47c6e23..a311751 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -3807,12 +3807,12 @@ int kvm_hv_hypercall(struct kvm_vcpu *vcpu)
longmode = is_long_mode(vcpu) cs_l == 1;
if (!longmode) {
- param = (kvm_register_read(vcpu, VCPU_REGS_RDX) 32) |
- (kvm_register_read(vcpu, VCPU_REGS_RAX) 0xff);
- ingpa = (kvm_register_read(vcpu, VCPU_REGS_RBX) 32) |
- (kvm_register_read(vcpu, VCPU_REGS_RCX) 0xff);
- outgpa = (kvm_register_read(vcpu, VCPU_REGS_RDI) 32) |
- (kvm_register_read(vcpu, VCPU_REGS_RSI) 0xff);
+ param = ((u64)kvm_register_read(vcpu, VCPU_REGS_RDX) 32) |
+ (kvm_register_read(vcpu, VCPU_REGS_RAX) 0x);
+ ingpa = ((u64)kvm_register_read(vcpu, VCPU_REGS_RBX) 32) |
+ (kvm_register_read(vcpu, VCPU_REGS_RCX) 0x);
+ outgpa = ((u64)kvm_register_read(vcpu, VCPU_REGS_RDI) 32) |
+ (kvm_register_read(vcpu, VCPU_REGS_RSI) 0x);
}
#ifdef CONFIG_X86_64
else {
--
To unsubscribe from this list: send the line unsubscribe kvm-commits in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[COMMIT master] KVM: fix cleanup_srcu_struct on vm destruction
From: Marcelo Tosatti mtosa...@redhat.com
cleanup_srcu_struct on VM destruction remains broken:
BUG: unable to handle kernel paging request at
IP: [802533d2] srcu_read_lock+0x16/0x21
RIP: 0010:[802533d2] [802533d2] srcu_read_lock+0x16/0x21
Call Trace:
[a05354c4] kvm_arch_vcpu_uninit+0x1b/0x48 [kvm]
[a05339c6] kvm_vcpu_uninit+0x9/0x15 [kvm]
[a0569f7d] vmx_free_vcpu+0x7f/0x8f [kvm_intel]
[a05357b5] kvm_arch_destroy_vm+0x78/0x111 [kvm]
[a053315b] kvm_put_kvm+0xd4/0xfe [kvm]
Move it to kvm_arch_destroy_vm.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
Reported-by: Jan Kiszka jan.kis...@siemens.com
diff --git a/arch/ia64/kvm/kvm-ia64.c b/arch/ia64/kvm/kvm-ia64.c
index e6ac549..0618898 100644
--- a/arch/ia64/kvm/kvm-ia64.c
+++ b/arch/ia64/kvm/kvm-ia64.c
@@ -1404,6 +1404,7 @@ void kvm_arch_destroy_vm(struct kvm *kvm)
kfree(kvm-arch.vioapic);
kvm_release_vm_pages(kvm);
kvm_free_physmem(kvm);
+ cleanup_srcu_struct(kvm-srcu);
free_kvm(kvm);
}
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 2c29116..51aedd7 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -137,6 +137,7 @@ void kvm_arch_destroy_vm(struct kvm *kvm)
{
kvmppc_free_vcpus(kvm);
kvm_free_physmem(kvm);
+ cleanup_srcu_struct(kvm-srcu);
kfree(kvm);
}
diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
index 8bedd31..8f09959 100644
--- a/arch/s390/kvm/kvm-s390.c
+++ b/arch/s390/kvm/kvm-s390.c
@@ -241,6 +241,7 @@ void kvm_arch_destroy_vm(struct kvm *kvm)
kvm_free_physmem(kvm);
free_page((unsigned long)(kvm-arch.sca));
debug_unregister(kvm-arch.dbf);
+ cleanup_srcu_struct(kvm-srcu);
kfree(kvm);
}
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index a311751..56a90a6 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -5546,6 +5546,7 @@ void kvm_arch_destroy_vm(struct kvm *kvm)
put_page(kvm-arch.apic_access_page);
if (kvm-arch.ept_identity_pagetable)
put_page(kvm-arch.ept_identity_pagetable);
+ cleanup_srcu_struct(kvm-srcu);
kfree(kvm-arch.aliases);
kfree(kvm);
}
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 2b7cd6c..7c5c873 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -506,7 +506,6 @@ static void kvm_destroy_vm(struct kvm *kvm)
#else
kvm_arch_flush_shadow(kvm);
#endif
- cleanup_srcu_struct(kvm-srcu);
kvm_arch_destroy_vm(kvm);
hardware_disable_all();
mmdrop(mm);
--
To unsubscribe from this list: send the line unsubscribe kvm-commits in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[COMMIT master] KVM: MMU: bail out pagewalk on kvm_read_guest error
From: Marcelo Tosatti mtosa...@redhat.com Exit the guest pagetable walk loop if reading gpte failed. Otherwise its possible to enter an endless loop processing the previous present pte. Cc: sta...@kernel.org Signed-off-by: Marcelo Tosatti mtosa...@redhat.com diff --git a/arch/x86/kvm/paging_tmpl.h b/arch/x86/kvm/paging_tmpl.h index 74efcfe..df15a53 100644 --- a/arch/x86/kvm/paging_tmpl.h +++ b/arch/x86/kvm/paging_tmpl.h @@ -150,7 +150,9 @@ walk: walker-table_gfn[walker-level - 1] = table_gfn; walker-pte_gpa[walker-level - 1] = pte_gpa; - kvm_read_guest(vcpu-kvm, pte_gpa, pte, sizeof(pte)); + if (kvm_read_guest(vcpu-kvm, pte_gpa, pte, sizeof(pte))) + goto not_present; + trace_kvm_mmu_paging_element(pte, walker-level); if (!is_present_gpte(pte)) -- To unsubscribe from this list: send the line unsubscribe kvm-commits in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[COMMIT master] KVM: x86: Use macros for x86_emulate_ops to avoid future mistakes
From: Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp
The return values from x86_emulate_ops are defined
in kvm_emulate.h as macros X86EMUL_*.
But in emulate.c, we are comparing the return values
from these ops with 0 to check if they're X86EMUL_CONTINUE
or not: X86EMUL_CONTINUE is defined as 0 now.
To avoid possible mistakes in the future, this patch
substitutes X86EMUL_CONTINUE for 0 that are being
compared with the return values from x86_emulate_ops.
We think that there are more places we should use these
macros, but the meanings of rc values in x86_emulate_insn()
were not so clear at a glance. If we use proper macros in
this function, we would be able to follow the flow of each
emulation more easily and, maybe, more securely.
Signed-off-by: Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index 0f89e32..48c7f9f 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -1196,7 +1196,7 @@ static int emulate_pop(struct x86_emulate_ctxt *ctxt,
rc = ops-read_emulated(register_address(c, ss_base(ctxt),
c-regs[VCPU_REGS_RSP]),
dest, len, ctxt-vcpu);
- if (rc != 0)
+ if (rc != X86EMUL_CONTINUE)
return rc;
register_address_increment(c, c-regs[VCPU_REGS_RSP], len);
@@ -1370,7 +1370,7 @@ static inline int emulate_grp9(struct x86_emulate_ctxt
*ctxt,
int rc;
rc = ops-read_emulated(memop, old, 8, ctxt-vcpu);
- if (rc != 0)
+ if (rc != X86EMUL_CONTINUE)
return rc;
if (((u32) (old 0) != (u32) c-regs[VCPU_REGS_RAX]) ||
@@ -1385,7 +1385,7 @@ static inline int emulate_grp9(struct x86_emulate_ctxt
*ctxt,
(u32) c-regs[VCPU_REGS_RBX];
rc = ops-cmpxchg_emulated(memop, old, new, 8, ctxt-vcpu);
- if (rc != 0)
+ if (rc != X86EMUL_CONTINUE)
return rc;
ctxt-eflags |= EFLG_ZF;
}
@@ -1451,7 +1451,7 @@ static inline int writeback(struct x86_emulate_ctxt *ctxt,
c-dst.val,
c-dst.bytes,
ctxt-vcpu);
- if (rc != 0)
+ if (rc != X86EMUL_CONTINUE)
return rc;
break;
case OP_NONE:
@@ -1749,7 +1749,7 @@ x86_emulate_insn(struct x86_emulate_ctxt *ctxt, struct
x86_emulate_ops *ops)
c-src.val,
c-src.bytes,
ctxt-vcpu);
- if (rc != 0)
+ if (rc != X86EMUL_CONTINUE)
goto done;
c-src.orig_val = c-src.val;
}
@@ -1768,12 +1768,15 @@ x86_emulate_insn(struct x86_emulate_ctxt *ctxt, struct
x86_emulate_ops *ops)
c-dst.ptr = (void *)c-dst.ptr +
(c-src.val mask) / 8;
}
- if (!(c-d Mov)
- /* optimisation - avoid slow emulated read */
- ((rc = ops-read_emulated((unsigned long)c-dst.ptr,
- c-dst.val,
- c-dst.bytes, ctxt-vcpu)) != 0))
- goto done;
+ if (!(c-d Mov)) {
+ /* optimisation - avoid slow emulated read */
+ rc = ops-read_emulated((unsigned long)c-dst.ptr,
+ c-dst.val,
+ c-dst.bytes,
+ ctxt-vcpu);
+ if (rc != X86EMUL_CONTINUE)
+ goto done;
+ }
}
c-dst.orig_val = c-dst.val;
@@ -2039,11 +2042,12 @@ special_insn:
c-dst.ptr = (unsigned long *)register_address(c,
es_base(ctxt),
c-regs[VCPU_REGS_RDI]);
- if ((rc = ops-read_emulated(register_address(c,
- seg_override_base(ctxt, c),
- c-regs[VCPU_REGS_RSI]),
+ rc = ops-read_emulated(register_address(c,
+ seg_override_base(ctxt, c),
+ c-regs[VCPU_REGS_RSI]),
c-dst.val,
- c-dst.bytes, ctxt-vcpu)) != 0)
+ c-dst.bytes, ctxt-vcpu);
+ if (rc != X86EMUL_CONTINUE)
goto done;
[COMMIT master] KVM: VMX: Clean up DR6 emulation
From: Jan Kiszka jan.kis...@siemens.com
As we trap all debug register accesses, we do not need to switch real
DR6 at all. Clean up update_exception_bitmap at this chance, too.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 834a8eb..75f1785 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -579,17 +579,12 @@ static void update_exception_bitmap(struct kvm_vcpu *vcpu)
{
u32 eb;
- eb = (1u PF_VECTOR) | (1u UD_VECTOR) | (1u MC_VECTOR)
- | (1u NM_VECTOR);
- /*
-* Unconditionally intercept #DB so we can maintain dr6 without
-* reading it every exit.
-*/
- eb |= 1u DB_VECTOR;
- if (vcpu-guest_debug KVM_GUESTDBG_ENABLE) {
- if (vcpu-guest_debug KVM_GUESTDBG_USE_SW_BP)
- eb |= 1u BP_VECTOR;
- }
+ eb = (1u PF_VECTOR) | (1u UD_VECTOR) | (1u MC_VECTOR) |
+(1u NM_VECTOR) | (1u DB_VECTOR);
+ if ((vcpu-guest_debug
+(KVM_GUESTDBG_ENABLE | KVM_GUESTDBG_USE_SW_BP)) ==
+ (KVM_GUESTDBG_ENABLE | KVM_GUESTDBG_USE_SW_BP))
+ eb |= 1u BP_VECTOR;
if (to_vmx(vcpu)-rmode.vm86_active)
eb = ~0;
if (enable_ept)
@@ -3781,9 +3776,6 @@ static void vmx_vcpu_run(struct kvm_vcpu *vcpu)
*/
vmcs_writel(HOST_CR0, read_cr0());
- if (vcpu-arch.switch_db_regs)
- set_debugreg(vcpu-arch.dr6, 6);
-
asm(
/* Store host registers */
push %%Rdx; push %%Rbp;
@@ -3884,9 +3876,6 @@ static void vmx_vcpu_run(struct kvm_vcpu *vcpu)
| (1 VCPU_EXREG_PDPTR));
vcpu-arch.regs_dirty = 0;
- if (vcpu-arch.switch_db_regs)
- get_debugreg(vcpu-arch.dr6, 6);
-
vmx-idt_vectoring_info = vmcs_read32(IDT_VECTORING_INFO_FIELD);
if (vmx-rmode.irq.pending)
fixup_rmode_irq(vmx);
--
To unsubscribe from this list: send the line unsubscribe kvm-commits in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[COMMIT master] KVM: VMX: Fix emulation of DR4 and DR5
From: Jan Kiszka jan.kis...@siemens.com
Make sure DR4 and DR5 are aliased to DR6 and DR7, respectively, if
CR4.DE is not set.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 4903b41..834a8eb 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -3043,6 +3043,15 @@ static int handle_cr(struct kvm_vcpu *vcpu)
return 0;
}
+static int check_dr_alias(struct kvm_vcpu *vcpu)
+{
+ if (kvm_read_cr4_bits(vcpu, X86_CR4_DE)) {
+ kvm_queue_exception(vcpu, UD_VECTOR);
+ return -1;
+ }
+ return 0;
+}
+
static int handle_dr(struct kvm_vcpu *vcpu)
{
unsigned long exit_qualification;
@@ -3085,14 +3094,20 @@ static int handle_dr(struct kvm_vcpu *vcpu)
case 0 ... 3:
val = vcpu-arch.db[dr];
break;
+ case 4:
+ if (check_dr_alias(vcpu) 0)
+ return 1;
+ /* fall through */
case 6:
val = vcpu-arch.dr6;
break;
- case 7:
+ case 5:
+ if (check_dr_alias(vcpu) 0)
+ return 1;
+ /* fall through */
+ default: /* 7 */
val = vcpu-arch.dr7;
break;
- default:
- val = 0;
}
kvm_register_write(vcpu, reg, val);
} else {
@@ -3103,12 +3118,10 @@ static int handle_dr(struct kvm_vcpu *vcpu)
if (!(vcpu-guest_debug KVM_GUESTDBG_USE_HW_BP))
vcpu-arch.eff_db[dr] = val;
break;
- case 4 ... 5:
- if (kvm_read_cr4_bits(vcpu, X86_CR4_DE)) {
- kvm_queue_exception(vcpu, UD_VECTOR);
+ case 4:
+ if (check_dr_alias(vcpu) 0)
return 1;
- }
- break;
+ /* fall through */
case 6:
if (val 0xULL) {
kvm_inject_gp(vcpu, 0);
@@ -3116,7 +3129,11 @@ static int handle_dr(struct kvm_vcpu *vcpu)
}
vcpu-arch.dr6 = (val DR6_VOLATILE) | DR6_FIXED_1;
break;
- case 7:
+ case 5:
+ if (check_dr_alias(vcpu) 0)
+ return 1;
+ /* fall through */
+ default: /* 7 */
if (val 0xULL) {
kvm_inject_gp(vcpu, 0);
return 1;
--
To unsubscribe from this list: send the line unsubscribe kvm-commits in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[COMMIT master] KVM: Fix kvm_coalesced_mmio_ring duplicate allocation
From: Sheng Yang sh...@linux.intel.com
The commit 0953ca73 KVM: Simplify coalesced mmio initialization
allocate kvm_coalesced_mmio_ring in the kvm_coalesced_mmio_init(), but
didn't discard the original allocation...
Signed-off-by: Sheng Yang sh...@linux.intel.com
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 7c5c873..2b0974a 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -371,9 +371,6 @@ static struct kvm *kvm_create_vm(void)
{
int r = 0, i;
struct kvm *kvm = kvm_arch_create_vm();
-#ifdef KVM_COALESCED_MMIO_PAGE_OFFSET
- struct page *page;
-#endif
if (IS_ERR(kvm))
goto out;
@@ -402,23 +399,9 @@ static struct kvm *kvm_create_vm(void)
}
}
-#ifdef KVM_COALESCED_MMIO_PAGE_OFFSET
- page = alloc_page(GFP_KERNEL | __GFP_ZERO);
- if (!page) {
- cleanup_srcu_struct(kvm-srcu);
- goto out_err;
- }
-
- kvm-coalesced_mmio_ring =
- (struct kvm_coalesced_mmio_ring *)page_address(page);
-#endif
-
r = kvm_init_mmu_notifier(kvm);
if (r) {
cleanup_srcu_struct(kvm-srcu);
-#ifdef KVM_COALESCED_MMIO_PAGE_OFFSET
- put_page(page);
-#endif
goto out_err;
}
--
To unsubscribe from this list: send the line unsubscribe kvm-commits in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[COMMIT master] KVM: S390: fix potential array overrun in intercept handling
From: Christian Borntraeger borntrae...@de.ibm.com
kvm_handle_sie_intercept uses a jump table to get the intercept handler
for a SIE intercept. Static code analysis revealed a potential problem:
the intercept_funcs jump table was defined to contain (0x48 2) entries,
but we only checked for code 0x48 which would cause an off-by-one
array overflow if code == 0x48.
Use the compiler and ARRAY_SIZE to automatically set the limits.
Cc: sta...@kernel.org
Signed-off-by: Christian Borntraeger borntrae...@de.ibm.com
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/arch/s390/kvm/intercept.c b/arch/s390/kvm/intercept.c
index ba9d8a7..b400964 100644
--- a/arch/s390/kvm/intercept.c
+++ b/arch/s390/kvm/intercept.c
@@ -213,7 +213,7 @@ static int handle_instruction_and_prog(struct kvm_vcpu
*vcpu)
return rc2;
}
-static const intercept_handler_t intercept_funcs[0x48 2] = {
+static const intercept_handler_t intercept_funcs[] = {
[0x00 2] = handle_noop,
[0x04 2] = handle_instruction,
[0x08 2] = handle_prog,
@@ -230,7 +230,7 @@ int kvm_handle_sie_intercept(struct kvm_vcpu *vcpu)
intercept_handler_t func;
u8 code = vcpu-arch.sie_block-icptcode;
- if (code 3 || code 0x48)
+ if (code 3 || (code 2) = ARRAY_SIZE(intercept_funcs))
return -ENOTSUPP;
func = intercept_funcs[code 2];
if (func)
--
To unsubscribe from this list: send the line unsubscribe kvm-commits in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[COMMIT master] KVM: x86: Fix probable memory leak of vcpu-arch.mce_banks
From: Wei Yongjun yj...@cn.fujitsu.com
vcpu-arch.mce_banks is malloc in kvm_arch_vcpu_init(), but
never free in any place, this may cause memory leak. So this
patch fixed to free it in kvm_arch_vcpu_uninit().
Cc: sta...@kernel.org
Signed-off-by: Wei Yongjun yj...@cn.fujitsu.com
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 1c0a0c7..72171f5 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -5460,6 +5460,7 @@ void kvm_arch_vcpu_uninit(struct kvm_vcpu *vcpu)
{
int idx;
+ kfree(vcpu-arch.mce_banks);
kvm_free_lapic(vcpu);
idx = srcu_read_lock(vcpu-kvm-srcu);
kvm_mmu_destroy(vcpu);
--
To unsubscribe from this list: send the line unsubscribe kvm-commits in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[COMMIT master] KVM: x86: Fix leak of free lapic date in kvm_arch_vcpu_init()
From: Wei Yongjun yj...@cn.fujitsu.com
In function kvm_arch_vcpu_init(), if the memory malloc for
vcpu-arch.mce_banks is fail, it does not free the memory
of lapic date. This patch fixed it.
Cc: sta...@kernel.org
Signed-off-by: Wei Yongjun yj...@cn.fujitsu.com
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 72171f5..1a0645e 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -5442,12 +5442,13 @@ int kvm_arch_vcpu_init(struct kvm_vcpu *vcpu)
GFP_KERNEL);
if (!vcpu-arch.mce_banks) {
r = -ENOMEM;
- goto fail_mmu_destroy;
+ goto fail_free_lapic;
}
vcpu-arch.mcg_cap = KVM_MAX_MCE_BANKS;
return 0;
-
+fail_free_lapic:
+ kvm_free_lapic(vcpu);
fail_mmu_destroy:
kvm_mmu_destroy(vcpu);
fail_free_pio_data:
--
To unsubscribe from this list: send the line unsubscribe kvm-commits in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[COMMIT master] KVM: PPC: Add PVR/PIR init for E500
From: Liu Yu yu@freescale.com commit 513579e3a391a3874c478a8493080822069976e8 change the way we emulate PVR/PIR, which left PVR/PIR uninitialized on E500, and make guest puzzled. Signed-off-by: Liu Yu yu@freescale.com Acked-by: Alexander Graf ag...@suse.de Signed-off-by: Marcelo Tosatti mtosa...@redhat.com diff --git a/arch/powerpc/kvm/e500.c b/arch/powerpc/kvm/e500.c index 64949ee..efa1198 100644 --- a/arch/powerpc/kvm/e500.c +++ b/arch/powerpc/kvm/e500.c @@ -60,6 +60,12 @@ int kvmppc_core_vcpu_setup(struct kvm_vcpu *vcpu) kvmppc_e500_tlb_setup(vcpu_e500); + /* Registers init */ + vcpu-arch.pvr = mfspr(SPRN_PVR); + + /* Since booke kvm only support one core, update all vcpus' PIR to 0 */ + vcpu-vcpu_id = 0; + return 0; } -- To unsubscribe from this list: send the line unsubscribe kvm-commits in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[COMMIT master] KVM: Move cr0/cr4/efer related helpers to x86.h
From: Avi Kivity a...@redhat.com
They have more general scope than the mmu.
Signed-off-by: Avi Kivity a...@redhat.com
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index 6a429ee..645b245 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -33,7 +33,6 @@
#include asm/kvm_emulate.h
#include x86.h
-#include mmu.h /* for is_long_mode() */
/*
* Opcode effective-address decode tables.
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index ff2b2e8..6f7158f 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -18,6 +18,7 @@
*/
#include mmu.h
+#include x86.h
#include kvm_cache_regs.h
#include linux/kvm_host.h
diff --git a/arch/x86/kvm/mmu.h b/arch/x86/kvm/mmu.h
index 599159f..61ef5a6 100644
--- a/arch/x86/kvm/mmu.h
+++ b/arch/x86/kvm/mmu.h
@@ -58,30 +58,6 @@ static inline int kvm_mmu_reload(struct kvm_vcpu *vcpu)
return kvm_mmu_load(vcpu);
}
-static inline int is_long_mode(struct kvm_vcpu *vcpu)
-{
-#ifdef CONFIG_X86_64
- return vcpu-arch.shadow_efer EFER_LMA;
-#else
- return 0;
-#endif
-}
-
-static inline int is_pae(struct kvm_vcpu *vcpu)
-{
- return kvm_read_cr4_bits(vcpu, X86_CR4_PAE);
-}
-
-static inline int is_pse(struct kvm_vcpu *vcpu)
-{
- return kvm_read_cr4_bits(vcpu, X86_CR4_PSE);
-}
-
-static inline int is_paging(struct kvm_vcpu *vcpu)
-{
- return kvm_read_cr0_bits(vcpu, X86_CR0_PG);
-}
-
static inline int is_present_gpte(unsigned long pte)
{
return pte PT_PRESENT_MASK;
diff --git a/arch/x86/kvm/x86.h b/arch/x86/kvm/x86.h
index f783d8f..2dc24a7 100644
--- a/arch/x86/kvm/x86.h
+++ b/arch/x86/kvm/x86.h
@@ -41,4 +41,28 @@ static inline bool is_protmode(struct kvm_vcpu *vcpu)
return kvm_read_cr0_bits(vcpu, X86_CR0_PE);
}
+static inline int is_long_mode(struct kvm_vcpu *vcpu)
+{
+#ifdef CONFIG_X86_64
+ return vcpu-arch.shadow_efer EFER_LMA;
+#else
+ return 0;
+#endif
+}
+
+static inline int is_pae(struct kvm_vcpu *vcpu)
+{
+ return kvm_read_cr4_bits(vcpu, X86_CR4_PAE);
+}
+
+static inline int is_pse(struct kvm_vcpu *vcpu)
+{
+ return kvm_read_cr4_bits(vcpu, X86_CR4_PSE);
+}
+
+static inline int is_paging(struct kvm_vcpu *vcpu)
+{
+ return kvm_read_cr0_bits(vcpu, X86_CR0_PG);
+}
+
#endif
--
To unsubscribe from this list: send the line unsubscribe kvm-commits in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[COMMIT master] Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
From: Marcelo Tosatti mtosa...@redhat.com Conflicts: arch/x86/kvm/mmu.c arch/x86/kvm/x86.c Signed-off-by: Marcelo Tosatti mtosa...@redhat.com -- To unsubscribe from this list: send the line unsubscribe kvm-commits in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[COMMIT master] KVM: VMX: Pass cr0.mp through to the guest when the fpu is active
From: Avi Kivity a...@redhat.com
When cr0.mp is clear, the guest doesn't expect a #NM in response to
a WAIT instruction. Because we always keep cr0.mp set, it will get
a #NM, and potentially be confused.
Fix by keeping cr0.mp set only when the fpu is inactive, and passing
it through when inactive.
Reported-by: Lorenzo Martignoni martig...@gmail.com
Analyzed-by: Gleb Natapov g...@redhat.com
Signed-off-by: Avi Kivity a...@redhat.com
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 0fa5906..e050c23 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -66,7 +66,7 @@ module_param(emulate_invalid_guest_state, bool, S_IRUGO);
#define KVM_GUEST_CR0_MASK \
(KVM_GUEST_CR0_MASK_UNRESTRICTED_GUEST | X86_CR0_PG | X86_CR0_PE)
#define KVM_VM_CR0_ALWAYS_ON_UNRESTRICTED_GUEST
\
- (X86_CR0_WP | X86_CR0_NE | X86_CR0_MP)
+ (X86_CR0_WP | X86_CR0_NE)
#define KVM_VM_CR0_ALWAYS_ON \
(KVM_VM_CR0_ALWAYS_ON_UNRESTRICTED_GUEST | X86_CR0_PG | X86_CR0_PE)
#define KVM_CR4_GUEST_OWNED_BITS \
@@ -791,12 +791,15 @@ static void vmx_vcpu_put(struct kvm_vcpu *vcpu)
static void vmx_fpu_activate(struct kvm_vcpu *vcpu)
{
+ ulong cr0;
+
if (vcpu-fpu_active)
return;
vcpu-fpu_active = 1;
- vmcs_clear_bits(GUEST_CR0, X86_CR0_TS);
- if (kvm_read_cr0_bits(vcpu, X86_CR0_TS))
- vmcs_set_bits(GUEST_CR0, X86_CR0_TS);
+ cr0 = vmcs_readl(GUEST_CR0);
+ cr0 = ~(X86_CR0_TS | X86_CR0_MP);
+ cr0 |= kvm_read_cr0_bits(vcpu, X86_CR0_TS | X86_CR0_MP);
+ vmcs_writel(GUEST_CR0, cr0);
update_exception_bitmap(vcpu);
vcpu-arch.cr0_guest_owned_bits = X86_CR0_TS;
vmcs_writel(CR0_GUEST_HOST_MASK, ~vcpu-arch.cr0_guest_owned_bits);
@@ -807,7 +810,7 @@ static void vmx_fpu_deactivate(struct kvm_vcpu *vcpu)
ulong old_ts, old_cr0;
old_ts = kvm_read_cr0_bits(vcpu, X86_CR0_TS);
- vmcs_set_bits(GUEST_CR0, X86_CR0_TS);
+ vmcs_set_bits(GUEST_CR0, X86_CR0_TS | X86_CR0_MP);
update_exception_bitmap(vcpu);
vcpu-arch.cr0_guest_owned_bits = 0;
vmcs_writel(CR0_GUEST_HOST_MASK, ~vcpu-arch.cr0_guest_owned_bits);
@@ -1760,7 +1763,7 @@ static void vmx_set_cr0(struct kvm_vcpu *vcpu, unsigned
long cr0)
ept_update_paging_mode_cr0(hw_cr0, cr0, vcpu);
if (!vcpu-fpu_active)
- hw_cr0 |= X86_CR0_TS;
+ hw_cr0 |= X86_CR0_TS | X86_CR0_MP;
vmcs_writel(CR0_READ_SHADOW, cr0);
vmcs_writel(GUEST_CR0, hw_cr0);
--
To unsubscribe from this list: send the line unsubscribe kvm-commits in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[COMMIT master] KVM: trace guest fpu loads and unloads
From: Avi Kivity a...@redhat.com
Signed-off-by: Avi Kivity a...@redhat.com
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 4e781f3..1c0a0c7 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -5293,6 +5293,7 @@ void kvm_load_guest_fpu(struct kvm_vcpu *vcpu)
vcpu-guest_fpu_loaded = 1;
kvm_fx_save(vcpu-arch.host_fx_image);
kvm_fx_restore(vcpu-arch.guest_fx_image);
+ trace_kvm_fpu(1);
}
void kvm_put_guest_fpu(struct kvm_vcpu *vcpu)
@@ -5305,6 +5306,7 @@ void kvm_put_guest_fpu(struct kvm_vcpu *vcpu)
kvm_fx_restore(vcpu-arch.host_fx_image);
++vcpu-stat.fpu_reload;
set_bit(KVM_REQ_DEACTIVATE_FPU, vcpu-requests);
+ trace_kvm_fpu(0);
}
void kvm_arch_vcpu_free(struct kvm_vcpu *vcpu)
diff --git a/include/trace/events/kvm.h b/include/trace/events/kvm.h
index dbe1084..8abdc12 100644
--- a/include/trace/events/kvm.h
+++ b/include/trace/events/kvm.h
@@ -145,6 +145,25 @@ TRACE_EVENT(kvm_mmio,
__entry-len, __entry-gpa, __entry-val)
);
+#define kvm_fpu_load_symbol\
+ {0, unload}, \
+ {1, load}
+
+TRACE_EVENT(kvm_fpu,
+ TP_PROTO(int load),
+ TP_ARGS(load),
+
+ TP_STRUCT__entry(
+ __field(u32,load)
+ ),
+
+ TP_fast_assign(
+ __entry-load = load;
+ ),
+
+ TP_printk(%s, __print_symbolic(__entry-load, kvm_fpu_load_symbol))
+);
+
#endif /* _TRACE_KVM_MAIN_H */
/* This part must be outside protection */
--
To unsubscribe from this list: send the line unsubscribe kvm-commits in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[COMMIT master] KVM: MMU: Remove some useless code from alloc_mmu_pages()
From: Wei Yongjun yj...@cn.fujitsu.com If we fail to alloc page for vcpu-arch.mmu.pae_root, call to free_mmu_pages() is unnecessary, which just do free the page malloc for vcpu-arch.mmu.pae_root. Signed-off-by: Wei Yongjun yj...@cn.fujitsu.com Signed-off-by: Marcelo Tosatti mtosa...@redhat.com diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c index 599c422..dc4d954 100644 --- a/arch/x86/kvm/mmu.c +++ b/arch/x86/kvm/mmu.c @@ -2843,16 +2843,13 @@ static int alloc_mmu_pages(struct kvm_vcpu *vcpu) */ page = alloc_page(GFP_KERNEL | __GFP_DMA32); if (!page) - goto error_1; + return -ENOMEM; + vcpu-arch.mmu.pae_root = page_address(page); for (i = 0; i 4; ++i) vcpu-arch.mmu.pae_root[i] = INVALID_PAGE; return 0; - -error_1: - free_mmu_pages(vcpu); - return -ENOMEM; } int kvm_mmu_create(struct kvm_vcpu *vcpu) -- To unsubscribe from this list: send the line unsubscribe kvm-commits in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[COMMIT master] KVM: Rename vcpu-shadow_efer to efer
From: Avi Kivity a...@redhat.com
None of the other registers have the shadow_ prefix.
Signed-off-by: Avi Kivity a...@redhat.com
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 7ebf9fe..1522337 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -277,7 +277,7 @@ struct kvm_vcpu_arch {
unsigned long cr8;
u32 hflags;
u64 pdptrs[4]; /* pae */
- u64 shadow_efer;
+ u64 efer;
u64 apic_base;
struct kvm_lapic *apic;/* kernel irqchip context */
int32_t apic_arb_prio;
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 6f7158f..599c422 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -237,7 +237,7 @@ static int is_cpuid_PSE36(void)
static int is_nx(struct kvm_vcpu *vcpu)
{
- return vcpu-arch.shadow_efer EFER_NX;
+ return vcpu-arch.efer EFER_NX;
}
static int is_shadow_present_pte(u64 pte)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 800208a..9596cc8 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -231,7 +231,7 @@ static void svm_set_efer(struct kvm_vcpu *vcpu, u64 efer)
efer = ~EFER_LME;
to_svm(vcpu)-vmcb-save.efer = efer | EFER_SVME;
- vcpu-arch.shadow_efer = efer;
+ vcpu-arch.efer = efer;
}
static void svm_queue_exception(struct kvm_vcpu *vcpu, unsigned nr,
@@ -996,14 +996,14 @@ static void svm_set_cr0(struct kvm_vcpu *vcpu, unsigned
long cr0)
struct vcpu_svm *svm = to_svm(vcpu);
#ifdef CONFIG_X86_64
- if (vcpu-arch.shadow_efer EFER_LME) {
+ if (vcpu-arch.efer EFER_LME) {
if (!is_paging(vcpu) (cr0 X86_CR0_PG)) {
- vcpu-arch.shadow_efer |= EFER_LMA;
+ vcpu-arch.efer |= EFER_LMA;
svm-vmcb-save.efer |= EFER_LMA | EFER_LME;
}
if (is_paging(vcpu) !(cr0 X86_CR0_PG)) {
- vcpu-arch.shadow_efer = ~EFER_LMA;
+ vcpu-arch.efer = ~EFER_LMA;
svm-vmcb-save.efer = ~(EFER_LMA | EFER_LME);
}
}
@@ -1361,7 +1361,7 @@ static int vmmcall_interception(struct vcpu_svm *svm)
static int nested_svm_check_permissions(struct vcpu_svm *svm)
{
- if (!(svm-vcpu.arch.shadow_efer EFER_SVME)
+ if (!(svm-vcpu.arch.efer EFER_SVME)
|| !is_paging(svm-vcpu)) {
kvm_queue_exception(svm-vcpu, UD_VECTOR);
return 1;
@@ -1764,7 +1764,7 @@ static bool nested_svm_vmrun(struct vcpu_svm *svm)
hsave-save.ds = vmcb-save.ds;
hsave-save.gdtr = vmcb-save.gdtr;
hsave-save.idtr = vmcb-save.idtr;
- hsave-save.efer = svm-vcpu.arch.shadow_efer;
+ hsave-save.efer = svm-vcpu.arch.efer;
hsave-save.cr0= kvm_read_cr0(svm-vcpu);
hsave-save.cr4= svm-vcpu.arch.cr4;
hsave-save.rflags = vmcb-save.rflags;
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 1336fcc..4745c7d 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -613,7 +613,7 @@ static bool update_transition_efer(struct vcpu_vmx *vmx,
int efer_offset)
u64 guest_efer;
u64 ignore_bits;
- guest_efer = vmx-vcpu.arch.shadow_efer;
+ guest_efer = vmx-vcpu.arch.efer;
/*
* NX is emulated; LMA and LME handled by hardware; SCE meaninless
@@ -958,7 +958,7 @@ static void setup_msrs(struct vcpu_vmx *vmx)
* if efer.sce is enabled.
*/
index = __find_msr_index(vmx, MSR_K6_STAR);
- if ((index = 0) (vmx-vcpu.arch.shadow_efer EFER_SCE))
+ if ((index = 0) (vmx-vcpu.arch.efer EFER_SCE))
move_msr_up(vmx, index, save_nmsrs++);
}
#endif
@@ -1603,7 +1603,7 @@ static void vmx_set_efer(struct kvm_vcpu *vcpu, u64 efer)
* of this msr depends on is_long_mode().
*/
vmx_load_host_state(to_vmx(vcpu));
- vcpu-arch.shadow_efer = efer;
+ vcpu-arch.efer = efer;
if (!msr)
return;
if (efer EFER_LMA) {
@@ -1635,13 +1635,13 @@ static void enter_lmode(struct kvm_vcpu *vcpu)
(guest_tr_ar ~AR_TYPE_MASK)
| AR_TYPE_BUSY_64_TSS);
}
- vcpu-arch.shadow_efer |= EFER_LMA;
- vmx_set_efer(vcpu, vcpu-arch.shadow_efer);
+ vcpu-arch.efer |= EFER_LMA;
+ vmx_set_efer(vcpu, vcpu-arch.efer);
}
static void exit_lmode(struct kvm_vcpu *vcpu)
{
- vcpu-arch.shadow_efer = ~EFER_LMA;
+ vcpu-arch.efer = ~EFER_LMA;
vmcs_write32(VM_ENTRY_CONTROLS,
vmcs_read32(VM_ENTRY_CONTROLS)
@@ -1748,7 +1748,7 @@ static void vmx_set_cr0(struct kvm_vcpu *vcpu, unsigned
long cr0)
enter_rmode(vcpu);
#ifdef CONFIG_X86_64
- if
[COMMIT master] KVM: PPC E500: Add register l1csr0 emulation
From: Liu Yu yu@freescale.com
Latest kernel start to access l1csr0 to contron L1.
We just tell guest no operation is on going.
Signed-off-by: Liu Yu yu@freescale.com
Acked-by: Alexander Graf ag...@suse.de
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/arch/powerpc/include/asm/kvm_e500.h
b/arch/powerpc/include/asm/kvm_e500.h
index 9d497ce..569dfd3 100644
--- a/arch/powerpc/include/asm/kvm_e500.h
+++ b/arch/powerpc/include/asm/kvm_e500.h
@@ -52,6 +52,7 @@ struct kvmppc_vcpu_e500 {
u32 mas5;
u32 mas6;
u32 mas7;
+ u32 l1csr0;
u32 l1csr1;
u32 hid0;
u32 hid1;
diff --git a/arch/powerpc/kvm/e500_emulate.c b/arch/powerpc/kvm/e500_emulate.c
index 7644f7a..95f8ec8 100644
--- a/arch/powerpc/kvm/e500_emulate.c
+++ b/arch/powerpc/kvm/e500_emulate.c
@@ -99,6 +99,10 @@ int kvmppc_core_emulate_mtspr(struct kvm_vcpu *vcpu, int
sprn, int rs)
vcpu_e500-mas6 = spr_val; break;
case SPRN_MAS7:
vcpu_e500-mas7 = spr_val; break;
+ case SPRN_L1CSR0:
+ vcpu_e500-l1csr0 = spr_val;
+ vcpu_e500-l1csr0 = ~(L1CSR0_DCFI | L1CSR0_CLFC);
+ break;
case SPRN_L1CSR1:
vcpu_e500-l1csr1 = spr_val; break;
case SPRN_HID0:
@@ -179,6 +183,8 @@ int kvmppc_core_emulate_mfspr(struct kvm_vcpu *vcpu, int
sprn, int rt)
break;
}
+ case SPRN_L1CSR0:
+ kvmppc_set_gpr(vcpu, rt, vcpu_e500-l1csr0); break;
case SPRN_L1CSR1:
kvmppc_set_gpr(vcpu, rt, vcpu_e500-l1csr1); break;
case SPRN_HID0:
--
To unsubscribe from this list: send the line unsubscribe kvm-commits in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[COMMIT master] kvmclock: count total_sleep_time when updating guest clock
From: Jason Wang jasow...@redhat.com
Current kvm wallclock does not consider the total_sleep_time which could cause
wrong wallclock in guest after host suspend/resume. This patch solve
this issue by counting total_sleep_time to get the correct host boot time.
Cc: sta...@kernel.org
Signed-off-by: Jason Wang jasow...@redhat.com
Acked-by: Glauber Costa glom...@redhat.com
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index ac8672f..d47ceda 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -723,7 +723,7 @@ static void kvm_write_wall_clock(struct kvm *kvm, gpa_t
wall_clock)
{
static int version;
struct pvclock_wall_clock wc;
- struct timespec now, sys, boot;
+ struct timespec boot;
if (!wall_clock)
return;
@@ -738,9 +738,7 @@ static void kvm_write_wall_clock(struct kvm *kvm, gpa_t
wall_clock)
* wall clock specified here. guest system time equals host
* system time for us, thus we must fill in host boot time here.
*/
- now = current_kernel_time();
- ktime_get_ts(sys);
- boot = ns_to_timespec(timespec_to_ns(now) - timespec_to_ns(sys));
+ getboottime(boot);
wc.sec = boot.tv_sec;
wc.nsec = boot.tv_nsec;
@@ -815,6 +813,7 @@ static void kvm_write_guest_time(struct kvm_vcpu *v)
local_irq_save(flags);
kvm_get_msr(v, MSR_IA32_TSC, vcpu-hv_clock.tsc_timestamp);
ktime_get_ts(ts);
+ monotonic_to_bootbased(ts);
local_irq_restore(flags);
/* With all the info we got, fill in the values */
--
To unsubscribe from this list: send the line unsubscribe kvm-commits in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[COMMIT master] KVM: fix load_guest_segment_descriptor() to return X86EMUL_*
From: Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp
This patch fixes load_guest_segment_descriptor() to return
X86EMUL_PROPAGATE_FAULT when it tries to access the descriptor
table beyond the limit of it: suggested by Marcelo.
I have checked current callers of this helper function,
- kvm_load_segment_descriptor()
- kvm_task_switch()
and confirmed that this patch will change nothing in the
upper layers if we do not change the handling of this
return value from load_guest_segment_descriptor().
Next step: Although fixing the kvm_task_switch() to handle the
propagated faults properly seems difficult, and maybe not worth
it because TSS is not used commonly these days, we can fix
kvm_load_segment_descriptor(). By doing so, the injected #GP
becomes possible to be handled by the guest. The only problem
for this is how to differentiate this fault from the page faults
generated by kvm_read_guest_virt(). We may have to split this
function to achive this goal.
Signed-off-by: Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 0bf3df5..01f0b03 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -4663,7 +4663,7 @@ static int load_guest_segment_descriptor(struct kvm_vcpu
*vcpu, u16 selector,
if (dtable.limit index * 8 + 7) {
kvm_queue_exception_e(vcpu, GP_VECTOR, selector 0xfffc);
- return 1;
+ return X86EMUL_PROPAGATE_FAULT;
}
return kvm_read_guest_virt(dtable.base + index*8, seg_desc,
sizeof(*seg_desc), vcpu);
}
--
To unsubscribe from this list: send the line unsubscribe kvm-commits in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[COMMIT master] KVM: mark segments accessed on HW task switch
From: Gleb Natapov g...@redhat.com
On HW task switch newly loaded segments should me marked as accessed.
Reported-by: Lorenzo Martignoni martig...@gmail.com
Signed-off-by: Gleb Natapov g...@redhat.com
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 1a0645e..ac8672f 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -4698,18 +4698,6 @@ static u16 get_segment_selector(struct kvm_vcpu *vcpu,
int seg)
return kvm_seg.selector;
}
-static int load_segment_descriptor_to_kvm_desct(struct kvm_vcpu *vcpu,
- u16 selector,
- struct kvm_segment *kvm_seg)
-{
- struct desc_struct seg_desc;
-
- if (load_guest_segment_descriptor(vcpu, selector, seg_desc))
- return 1;
- seg_desct_to_kvm_desct(seg_desc, selector, kvm_seg);
- return 0;
-}
-
static int kvm_load_realmode_segment(struct kvm_vcpu *vcpu, u16 selector, int
seg)
{
struct kvm_segment segvar = {
@@ -4750,11 +4738,14 @@ int kvm_load_segment_descriptor(struct kvm_vcpu *vcpu,
u16 selector,
int type_bits, int seg)
{
struct kvm_segment kvm_seg;
+ struct desc_struct seg_desc;
if (is_vm86_segment(vcpu, seg) || !is_protmode(vcpu))
return kvm_load_realmode_segment(vcpu, selector, seg);
- if (load_segment_descriptor_to_kvm_desct(vcpu, selector, kvm_seg))
+
+ if (load_guest_segment_descriptor(vcpu, selector, seg_desc))
return 1;
+ seg_desct_to_kvm_desct(seg_desc, selector, kvm_seg);
kvm_check_segment_descriptor(vcpu, seg, selector);
kvm_seg.type |= type_bits;
@@ -4765,6 +4756,11 @@ int kvm_load_segment_descriptor(struct kvm_vcpu *vcpu,
u16 selector,
kvm_seg.unusable = 1;
kvm_set_segment(vcpu, kvm_seg, seg);
+ if (selector !kvm_seg.unusable kvm_seg.s) {
+ /* mark segment as accessed */
+ seg_desc.type |= 1;
+ save_guest_segment_descriptor(vcpu, selector, seg_desc);
+ }
return 0;
}
--
To unsubscribe from this list: send the line unsubscribe kvm-commits in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[COMMIT master] KVM: PIT: control word is write-only
From: Marcelo Tosatti mtosa...@redhat.com PIT control word (address 0x43) is write-only, reads are undefined. Cc: sta...@kernel.org Signed-off-by: Marcelo Tosatti mtosa...@redhat.com diff --git a/arch/x86/kvm/i8254.c b/arch/x86/kvm/i8254.c index caad189..6a74246 100644 --- a/arch/x86/kvm/i8254.c +++ b/arch/x86/kvm/i8254.c @@ -467,6 +467,9 @@ static int pit_ioport_read(struct kvm_io_device *this, return -EOPNOTSUPP; addr = KVM_PIT_CHANNEL_MASK; + if (addr == 3) + return 0; + s = pit_state-channels[addr]; mutex_lock(pit_state-lock); -- To unsubscribe from this list: send the line unsubscribe kvm-commits in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[COMMIT master] KVM: enable PCI multiple-segments for pass-through device
From: Zhai, Edwin edwin.z...@intel.com
Enable optional parameter (default 0) - PCI segment (or domain) besides
BDF, when assigning PCI device to guest.
Signed-off-by: Zhai Edwin edwin.z...@intel.com
Acked-by: Chris Wright chr...@sous-sol.org
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index d47ceda..0bf3df5 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1569,6 +1569,7 @@ int kvm_dev_ioctl_check_extension(long ext)
case KVM_CAP_HYPERV:
case KVM_CAP_HYPERV_VAPIC:
case KVM_CAP_HYPERV_SPIN:
+ case KVM_CAP_PCI_SEGMENT:
r = 1;
break;
case KVM_CAP_COALESCED_MMIO:
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index 4c4937e..dfa54be 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -500,6 +500,7 @@ struct kvm_ioeventfd {
#define KVM_CAP_HYPERV 44
#define KVM_CAP_HYPERV_VAPIC 45
#define KVM_CAP_HYPERV_SPIN 46
+#define KVM_CAP_PCI_SEGMENT 47
#ifdef KVM_CAP_IRQ_ROUTING
@@ -694,8 +695,9 @@ struct kvm_assigned_pci_dev {
__u32 busnr;
__u32 devfn;
__u32 flags;
+ __u32 segnr;
union {
- __u32 reserved[12];
+ __u32 reserved[11];
};
};
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index dfde04b..665c370 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -400,6 +400,7 @@ struct kvm_assigned_dev_kernel {
struct work_struct interrupt_work;
struct list_head list;
int assigned_dev_id;
+ int host_segnr;
int host_busnr;
int host_devfn;
unsigned int entries_nr;
diff --git a/virt/kvm/assigned-dev.c b/virt/kvm/assigned-dev.c
index f51e684..057e2cc 100644
--- a/virt/kvm/assigned-dev.c
+++ b/virt/kvm/assigned-dev.c
@@ -526,7 +526,8 @@ static int kvm_vm_ioctl_assign_device(struct kvm *kvm,
r = -ENOMEM;
goto out;
}
- dev = pci_get_bus_and_slot(assigned_dev-busnr,
+ dev = pci_get_domain_bus_and_slot(assigned_dev-segnr,
+ assigned_dev-busnr,
assigned_dev-devfn);
if (!dev) {
printk(KERN_INFO %s: host device not found\n, __func__);
@@ -548,6 +549,7 @@ static int kvm_vm_ioctl_assign_device(struct kvm *kvm,
pci_reset_function(dev);
match-assigned_dev_id = assigned_dev-assigned_dev_id;
+ match-host_segnr = assigned_dev-segnr;
match-host_busnr = assigned_dev-busnr;
match-host_devfn = assigned_dev-devfn;
match-flags = assigned_dev-flags;
diff --git a/virt/kvm/iommu.c b/virt/kvm/iommu.c
index 65a5143..80fd3ad 100644
--- a/virt/kvm/iommu.c
+++ b/virt/kvm/iommu.c
@@ -106,7 +106,8 @@ int kvm_assign_device(struct kvm *kvm,
r = iommu_attach_device(domain, pdev-dev);
if (r) {
- printk(KERN_ERR assign device %x:%x.%x failed,
+ printk(KERN_ERR assign device %x:%x:%x.%x failed,
+ pci_domain_nr(pdev-bus),
pdev-bus-number,
PCI_SLOT(pdev-devfn),
PCI_FUNC(pdev-devfn));
@@ -127,7 +128,8 @@ int kvm_assign_device(struct kvm *kvm,
goto out_unmap;
}
- printk(KERN_DEBUG assign device: host bdf = %x:%x:%x\n,
+ printk(KERN_DEBUG assign device %x:%x:%x.%x\n,
+ assigned_dev-host_segnr,
assigned_dev-host_busnr,
PCI_SLOT(assigned_dev-host_devfn),
PCI_FUNC(assigned_dev-host_devfn));
@@ -154,7 +156,8 @@ int kvm_deassign_device(struct kvm *kvm,
iommu_detach_device(domain, pdev-dev);
- printk(KERN_DEBUG deassign device: host bdf = %x:%x:%x\n,
+ printk(KERN_DEBUG deassign device %x:%x:%x.%x\n,
+ assigned_dev-host_segnr,
assigned_dev-host_busnr,
PCI_SLOT(assigned_dev-host_devfn),
PCI_FUNC(assigned_dev-host_devfn));
--
To unsubscribe from this list: send the line unsubscribe kvm-commits in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[COMMIT master] KVM: VMX: Wire up .fpu_activate() callback
From: Avi Kivity a...@redhat.com
Signed-off-by: Avi Kivity a...@redhat.com
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 363f2f6..820e5fc 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -4140,6 +4140,7 @@ static struct kvm_x86_ops vmx_x86_ops = {
.cache_reg = vmx_cache_reg,
.get_rflags = vmx_get_rflags,
.set_rflags = vmx_set_rflags,
+ .fpu_activate = vmx_fpu_activate,
.fpu_deactivate = vmx_fpu_deactivate,
.tlb_flush = vmx_flush_tlb,
--
To unsubscribe from this list: send the line unsubscribe kvm-commits in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[COMMIT master] KVM: fix kvm_fix_hypercall() to return X86EMUL_*
From: Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp
This patch fixes kvm_fix_hypercall() to propagate X86EMUL_*
info generated by emulator_write_emulated() to its callers:
suggested by Marcelo.
The effect of this is x86_emulate_insn() will begin to handle
the page faults which occur in emulator_write_emulated():
this should be OK because emulator_write_emulated_onepage()
always injects page fault when emulator_write_emulated()
returns X86EMUL_PROPAGATE_FAULT.
Signed-off-by: Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 01f0b03..c91007f 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -3888,10 +3888,8 @@ EXPORT_SYMBOL_GPL(kvm_emulate_hypercall);
int kvm_fix_hypercall(struct kvm_vcpu *vcpu)
{
char instruction[3];
- int ret = 0;
unsigned long rip = kvm_rip_read(vcpu);
-
/*
* Blow out the MMU to ensure that no other VCPU has an active mapping
* to ensure that the updated hypercall appears atomically across all
@@ -3900,11 +3898,8 @@ int kvm_fix_hypercall(struct kvm_vcpu *vcpu)
kvm_mmu_zap_all(vcpu-kvm);
kvm_x86_ops-patch_hypercall(vcpu, instruction);
- if (emulator_write_emulated(rip, instruction, 3, vcpu)
- != X86EMUL_CONTINUE)
- ret = -EFAULT;
- return ret;
+ return emulator_write_emulated(rip, instruction, 3, vcpu);
}
static u64 mk_cr_64(u64 curr_cr, u32 new_val)
--
To unsubscribe from this list: send the line unsubscribe kvm-commits in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[COMMIT] [WIN-GUEST-DRIVERS] NetKVM: Change debeug level for packet filtering OID
repository: C:/dev/kvm-guest-drivers-windows
branch: master
commit 37cc09539a46f37d18751bb05cb6ae76eb6b3709
Author: Yan Vugenfirer yvuge...@redhat.com
Date: Sun Feb 7 18:19:40 2010 +0200
[WIN-GUEST-DRIVERS] NetKVM: Change debeug level for packet filtering OID
Signed-off-by: Yan Vugenfirer yvuge...@redhat.com
diff --git a/NetKVM/Common/ParaNdis-Oid.c b/NetKVM/Common/ParaNdis-Oid.c
index 328eadd..f724ffc 100644
--- a/NetKVM/Common/ParaNdis-Oid.c
+++ b/NetKVM/Common/ParaNdis-Oid.c
@@ -110,7 +110,7 @@ NDIS_STATUS ParaNdis_OnSetPacketFilter(PARANDIS_ADAPTER
*pContext, tOidDesc *pOi
if (status == NDIS_STATUS_SUCCESS)
{
- DPrintf(0, ([%s] PACKET FILTER SET TO %x, __FUNCTION__,
pContext-PacketFilter));
+ DPrintf(1, ([%s] PACKET FILTER SET TO %x, __FUNCTION__,
pContext-PacketFilter));
}
return status;
}
--
To unsubscribe from this list: send the line unsubscribe kvm-commits in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[COMMIT master] KVM: Introduce kvm_host_page_size
From: Joerg Roedel joerg.roe...@amd.com
This patch introduces a generic function to find out the
host page size for a given gfn. This function is needed by
the kvm iommu code. This patch also simplifies the x86
host_mapping_level function.
Signed-off-by: Joerg Roedel joerg.roe...@amd.com
Signed-off-by: Avi Kivity a...@redhat.com
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index dc4d954..913ef4b 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -468,24 +468,10 @@ static int has_wrprotected_page(struct kvm *kvm,
static int host_mapping_level(struct kvm *kvm, gfn_t gfn)
{
- unsigned long page_size = PAGE_SIZE;
- struct vm_area_struct *vma;
- unsigned long addr;
+ unsigned long page_size;
int i, ret = 0;
- addr = gfn_to_hva(kvm, gfn);
- if (kvm_is_error_hva(addr))
- return PT_PAGE_TABLE_LEVEL;
-
- down_read(current-mm-mmap_sem);
- vma = find_vma(current-mm, addr);
- if (!vma)
- goto out;
-
- page_size = vma_kernel_pagesize(vma);
-
-out:
- up_read(current-mm-mmap_sem);
+ page_size = kvm_host_page_size(kvm, gfn);
for (i = PT_PAGE_TABLE_LEVEL;
i (PT_PAGE_TABLE_LEVEL + KVM_NR_PAGE_SIZES); ++i) {
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 665c370..3145b28 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -300,6 +300,7 @@ int kvm_clear_guest_page(struct kvm *kvm, gfn_t gfn, int
offset, int len);
int kvm_clear_guest(struct kvm *kvm, gpa_t gpa, unsigned long len);
struct kvm_memory_slot *gfn_to_memslot(struct kvm *kvm, gfn_t gfn);
int kvm_is_visible_gfn(struct kvm *kvm, gfn_t gfn);
+unsigned long kvm_host_page_size(struct kvm *kvm, gfn_t gfn);
void mark_page_dirty(struct kvm *kvm, gfn_t gfn);
void kvm_vcpu_block(struct kvm_vcpu *vcpu);
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 2b0974a..0a360c2 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -45,6 +45,7 @@
#include linux/spinlock.h
#include linux/compat.h
#include linux/srcu.h
+#include linux/hugetlb.h
#include asm/processor.h
#include asm/io.h
@@ -867,6 +868,30 @@ int kvm_is_visible_gfn(struct kvm *kvm, gfn_t gfn)
}
EXPORT_SYMBOL_GPL(kvm_is_visible_gfn);
+unsigned long kvm_host_page_size(struct kvm *kvm, gfn_t gfn)
+{
+ struct vm_area_struct *vma;
+ unsigned long addr, size;
+
+ size = PAGE_SIZE;
+
+ addr = gfn_to_hva(kvm, gfn);
+ if (kvm_is_error_hva(addr))
+ return PAGE_SIZE;
+
+ down_read(current-mm-mmap_sem);
+ vma = find_vma(current-mm, addr);
+ if (!vma)
+ goto out;
+
+ size = vma_kernel_pagesize(vma);
+
+out:
+ up_read(current-mm-mmap_sem);
+
+ return size;
+}
+
int memslot_id(struct kvm *kvm, gfn_t gfn)
{
int i;
--
To unsubscribe from this list: send the line unsubscribe kvm-commits in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] vhost-net: switch to smp barriers
On Mon, Feb 01, 2010 at 07:21:02PM +0200, Michael S. Tsirkin wrote:
vhost-net only uses memory barriers to control SMP effects
(communication with userspace potentially running on a different CPU),
so it should use SMP barriers and not mandatory barriers for memory
access ordering, as suggested by Documentation/memory-barriers.txt
Signed-off-by: Michael S. Tsirkin m...@redhat.com
Rusty, any feedback on this one?
Thanks!
---
drivers/vhost/vhost.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
The above applies on top of net-next-2.6. Does not seem to give any
measureable performance gain, but seems to generate less code
and I think it's better to use correct APIs.
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index c8c25db..6eb1525 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -685,7 +685,7 @@ int vhost_log_write(struct vhost_virtqueue *vq, struct
vhost_log *log,
int i, r;
/* Make sure data written is seen before log. */
- wmb();
+ smp_wmb();
for (i = 0; i log_num; ++i) {
u64 l = min(log[i].len, len);
r = log_write(vq-log_base, log[i].addr, l);
@@ -884,7 +884,7 @@ unsigned vhost_get_vq_desc(struct vhost_dev *dev, struct
vhost_virtqueue *vq,
return vq-num;
/* Only get avail ring entries after they have been exposed by guest. */
- rmb();
+ smp_rmb();
/* Grab the next descriptor number they're advertising, and increment
* the index we've seen. */
@@ -996,14 +996,14 @@ int vhost_add_used(struct vhost_virtqueue *vq, unsigned
int head, int len)
return -EFAULT;
}
/* Make sure buffer is written before we update index. */
- wmb();
+ smp_wmb();
if (put_user(vq-last_used_idx + 1, vq-used-idx)) {
vq_err(vq, Failed to increment used idx);
return -EFAULT;
}
if (unlikely(vq-log_used)) {
/* Make sure data is seen before log. */
- wmb();
+ smp_wmb();
log_write(vq-log_base, vq-log_addr + sizeof *vq-used-ring *
(vq-last_used_idx % vq-num),
sizeof *vq-used-ring);
@@ -1060,7 +1060,7 @@ bool vhost_enable_notify(struct vhost_virtqueue *vq)
}
/* They could have slipped one in as we were doing that: make
* sure it's written, then check again. */
- mb();
+ smp_mb();
r = get_user(avail_idx, vq-avail-idx);
if (r) {
vq_err(vq, Failed to check avail idx at %p: %d\n,
--
1.6.6.144.g5c3af
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/11] iommu-api: Add iommu_map and iommu_unmap functions
On 01/28/2010 01:37 PM, Joerg Roedel wrote: These two functions provide support for mapping and unmapping physical addresses to io virtual addresses. The difference to the iommu_(un)map_range() is that the new functions take a gfp_order parameter instead of a size. This allows the IOMMU backend implementations to detect easier if a given range can be mapped by larger page sizes. These new functions should replace the old ones in the long term. These seem to be less flexible in the long term. Sure, it is easier for the backend to map to multiple page sizes if your iommu supports arbitrary power-of-two page sizes, but we should make the APIs easier for the callers, not the backend. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] vhost-net: switch to smp barriers
On 02/01/2010 07:21 PM, Michael S. Tsirkin wrote: vhost-net only uses memory barriers to control SMP effects (communication with userspace potentially running on a different CPU), so it should use SMP barriers and not mandatory barriers for memory access ordering, as suggested by Documentation/memory-barriers.txt A UP guest running on an SMP host still needs those barriers. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/21] qemu-kvm: Hook cleanups and extended use of upstream code
On Wed, Feb 03, 2010 at 09:53:25AM +0100, Jan Kiszka wrote: This version addresses the feedback on v2, namely: - assert(vm stopped || current thread == env-thread) on low-level load/save registers - fixed mpstate initialization With those patched, doing info cpus in monitor kill the guest, which, unfortunately, means that reworked VCPU state writeback is still not so easy to use correctly. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] vhost-net: switch to smp barriers
On Sun, Feb 07, 2010 at 11:42:29AM +0200, Avi Kivity wrote: On 02/01/2010 07:21 PM, Michael S. Tsirkin wrote: vhost-net only uses memory barriers to control SMP effects (communication with userspace potentially running on a different CPU), so it should use SMP barriers and not mandatory barriers for memory access ordering, as suggested by Documentation/memory-barriers.txt A UP guest running on an SMP host still needs those barriers. Correct. And since vhost net is running host-side, smp_XX barriers will do exactly the right thing, right? -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] vhost-net: switch to smp barriers
On 02/07/2010 11:44 AM, Michael S. Tsirkin wrote: On Sun, Feb 07, 2010 at 11:42:29AM +0200, Avi Kivity wrote: On 02/01/2010 07:21 PM, Michael S. Tsirkin wrote: vhost-net only uses memory barriers to control SMP effects (communication with userspace potentially running on a different CPU), so it should use SMP barriers and not mandatory barriers for memory access ordering, as suggested by Documentation/memory-barriers.txt A UP guest running on an SMP host still needs those barriers. Correct. And since vhost net is running host-side, smp_XX barriers will do exactly the right thing, right? Right, of course. Mixed up virtio and vhost. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/11] iommu-api: Add iommu_map and iommu_unmap functions
On Sun, Feb 07, 2010 at 11:38:30AM +0200, Avi Kivity wrote: On 01/28/2010 01:37 PM, Joerg Roedel wrote: These two functions provide support for mapping and unmapping physical addresses to io virtual addresses. The difference to the iommu_(un)map_range() is that the new functions take a gfp_order parameter instead of a size. This allows the IOMMU backend implementations to detect easier if a given range can be mapped by larger page sizes. These new functions should replace the old ones in the long term. These seem to be less flexible in the long term. Sure, it is easier for the backend to map to multiple page sizes if your iommu supports arbitrary power-of-two page sizes, but we should make the APIs easier for the callers, not the backend. These functions are as flexible as the old ones which just tok a size. The benefit of the new interface is that is makes the ability of the IOMMU to map the area with a large page (an get the benefit of fewer hardware tlb walks) visible to the caller. With the old interface the caller is tempted to just map ist whole area using 4kb page sizes. It gives a bit more complexity to the caller, thats right. But given that the page allocator in Linux always returns pages which are aligned to its size takes a lot of that complexity away. Joerg -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM problems with Xeon L5530
On 01/28/2010 01:02 PM, Matteo Ghezzi wrote: Upgraded to 2.6.33-rc5, same qemu-kvm version, same hardware. The Vnc screen is still black and the virtual machine, but now I don't have anymore messages in the logs but directly at standard output: KVM internal error. Suberror: 2 extra data[0]: 8010 extra data[1]: 8b0d rip 014a rflags 00010002 cs c000 (000c/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) That is basically the same error. The guest runs the vga vios and hangs. Please try with a production processor. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/11] iommu-api: Add iommu_map and iommu_unmap functions
On 02/07/2010 12:50 PM, Joerg Roedel wrote: On Sun, Feb 07, 2010 at 11:38:30AM +0200, Avi Kivity wrote: On 01/28/2010 01:37 PM, Joerg Roedel wrote: These two functions provide support for mapping and unmapping physical addresses to io virtual addresses. The difference to the iommu_(un)map_range() is that the new functions take a gfp_order parameter instead of a size. This allows the IOMMU backend implementations to detect easier if a given range can be mapped by larger page sizes. These new functions should replace the old ones in the long term. These seem to be less flexible in the long term. Sure, it is easier for the backend to map to multiple page sizes if your iommu supports arbitrary power-of-two page sizes, but we should make the APIs easier for the callers, not the backend. These functions are as flexible as the old ones which just tok a size. The benefit of the new interface is that is makes the ability of the IOMMU to map the area with a large page (an get the benefit of fewer hardware tlb walks) visible to the caller. With the old interface the caller is tempted to just map ist whole area using 4kb page sizes. It gives a bit more complexity to the caller, thats right. But given that the page allocator in Linux always returns pages which are aligned to its size takes a lot of that complexity away. You are right - I was thinking of the kvm use case which is range oriented, but the ordinary kernel interfaces are gfp_order oriented. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/21] qemu-kvm: Hook cleanups and extended use of upstream code
Gleb Natapov wrote:
On Wed, Feb 03, 2010 at 09:53:25AM +0100, Jan Kiszka wrote:
This version addresses the feedback on v2, namely:
- assert(vm stopped || current thread == env-thread) on low-level
load/save registers
- fixed mpstate initialization
With those patched, doing info cpus in monitor kill the guest, which,
unfortunately, means that reworked VCPU state writeback is still not so
easy to use correctly.
Regression of patch 12 (qemu-kvm: Use upstream kvm_vcpu_dirty), will
be fixed in v3.
Thanks,
Jan
---
diff --git a/qemu-kvm.c b/qemu-kvm.c
index 6a72b89..72c2ca0 100644
--- a/qemu-kvm.c
+++ b/qemu-kvm.c
@@ -1532,13 +1532,13 @@ static void do_kvm_cpu_synchronize_state(void *_env)
CPUState *env = _env;
kvm_arch_save_regs(env);
+env-kvm_vcpu_dirty = 1;
}
void kvm_cpu_synchronize_state(CPUState *env)
{
if (!env-kvm_vcpu_dirty) {
on_vcpu(env, do_kvm_cpu_synchronize_state, env);
-env-kvm_vcpu_dirty = 1;
}
}
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 01/10] arch/ia64: Fix continuation line formats
On 02/02/2010 09:22 AM, Joe Perches wrote: String constants that are continued on subsequent lines with \ are not good. Applied, thanks. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/11] arch/x86/kvm: Correct NULL test
On 02/06/2010 10:43 AM, Julia Lawall wrote: From: Julia Lawallju...@diku.dk msr was tested above, so the second test is not needed. Applied, thanks. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/21] qemu-kvm: Hook cleanups and extended use of upstream code
On Sun, Feb 07, 2010 at 12:28:49PM +0100, Jan Kiszka wrote: Gleb Natapov wrote: On Wed, Feb 03, 2010 at 09:53:25AM +0100, Jan Kiszka wrote: This version addresses the feedback on v2, namely: - assert(vm stopped || current thread == env-thread) on low-level load/save registers - fixed mpstate initialization With those patched, doing info cpus in monitor kill the guest, which, unfortunately, means that reworked VCPU state writeback is still not so easy to use correctly. Regression of patch 12 (qemu-kvm: Use upstream kvm_vcpu_dirty), will be fixed in v3. Looks better now indeed. Thanks. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM: VMX: update cr0 read shadow when deactivating cr0.ts passthrough
On 02/01/2010 06:48 PM, Marcelo Tosatti wrote: On fpu deactivation, the cr0 read shadow is not properly updated, since it assumes vcpu-arch.cr0 contains the guest visible cr0 value before guest had control of cr0.ts. This is not true, since cr0 has been decached (from vmx_fpu_deactivate itself or somewhere else). Fix by unconditionally updating cr0 read shadow (this is not a hot path, in comparison with entry/exit). Fixes FC8 64 install. Applied, thanks. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/8] KVM: Optimize kvm_read_cr[04]_bits()
On 02/05/2010 10:26 AM, Jan Kiszka wrote: Avi Kivity wrote: 'mask' is always a constant, so we can check whether it includes a bit that might be owned by the guest very cheaply, and avoid the decache call. Saves a few hundred bytes of module text. -no-kvm-irqchip -smp 2 is broken for my Linux guests since this commit. Their user space applications receive #UD and things fall apart. Does 2c8232fc help? -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/11] kvm: Introduce kvm_host_page_size
On 01/28/2010 01:37 PM, Joerg Roedel wrote: This patch introduces a generic function to find out the host page size for a given gfn. This function is needed by the kvm iommu code. This patch also simplifies the x86 host_mapping_level function. Applied to kvm.git since this makes sense independently of the rest of your patchset. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/11] kvm: Change kvm_iommu_map_pages to map large pages
On 01/29/2010 12:24 AM, Marcelo Tosatti wrote:
On Thu, Jan 28, 2010 at 12:37:57PM +0100, Joerg Roedel wrote:
This patch changes the implementation of of
kvm_iommu_map_pages to map the pages with the host page size
into the io virtual address space.
Signed-off-by: Joerg Roedeljoerg.roe...@amd.com
---
virt/kvm/iommu.c | 106 ++---
1 files changed, 84 insertions(+), 22 deletions(-)
diff --git a/virt/kvm/iommu.c b/virt/kvm/iommu.c
index 65a5143..92a434d 100644
--- a/virt/kvm/iommu.c
+++ b/virt/kvm/iommu.c
@@ -32,12 +32,27 @@ static int kvm_iommu_unmap_memslots(struct kvm *kvm);
static void kvm_iommu_put_pages(struct kvm *kvm,
gfn_t base_gfn, unsigned long npages);
+static pfn_t kvm_pin_pages(struct kvm *kvm, struct kvm_memory_slot *slot,
+ gfn_t gfn, unsigned long size)
+{
+ gfn_t end_gfn;
+ pfn_t pfn;
+
+ pfn = gfn_to_pfn_memslot(kvm, slot, gfn);
If gfn_to_pfn_memslot returns pfn of bad_page, you might create a
large iommu translation for it?
How could it return a bad_page? The whole thing is called for a valid slot.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/11] kvm: Change kvm_iommu_map_pages to map large pages
On 02/05/2010 01:01 PM, Joerg Roedel wrote: Yes, addresses the concern. Are there any further objections against this patchset? If not it would be cool if you could give me some acks for the kvm specific parts of this patchset. There are two ways we can get the kvm bits in: - you publish a git tree excluding the kvm patches, I merge your tree, then apply the kvm specific patches. This is best for avoiding merge-time conflicts if I get other patches for the same area. - you push everything including the kvm bits. I'm fine with both, though prefer the former. If you choose the latter, ACK for the kvm patches. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/8] KVM: Activate fpu on clts
On 02/04/2010 07:56 PM, Avi Kivity wrote: vmx.c doesn't initialize kvm_x86_ops-fpu_activate as far as I see. Gaak. Well, that's obviously unintended. I committed a patch to fix this. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/18] KVM: PPC: Enable MMIO to do 64 bits, fprs and qprs
On 02/04/2010 05:55 PM, Alexander Graf wrote:
Right now MMIO access can only happen for GPRs and is at most 32 bit wide.
That's actually enough for almost all types of hardware out there.
Unfortunately, the guest I was using used FPU writes to MMIO regions, so
it ended up writing 64 bit MMIOs using FPRs and QPRs.
So let's add code to handle those odd cases too.
Signed-off-by: Alexander Grafag...@suse.de
---
arch/powerpc/include/asm/kvm.h |7 +++
arch/powerpc/include/asm/kvm_ppc.h |2 +-
arch/powerpc/kvm/powerpc.c | 24 ++--
3 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm.h b/arch/powerpc/include/asm/kvm.h
index 81f3b0b..548376c 100644
--- a/arch/powerpc/include/asm/kvm.h
+++ b/arch/powerpc/include/asm/kvm.h
@@ -77,4 +77,11 @@ struct kvm_debug_exit_arch {
struct kvm_guest_debug_arch {
};
+#define REG_MASK 0x001f
+#define REG_EXT_MASK 0xffe0
+#define REG_GPR0x
+#define REG_FPR0x0020
+#define REG_QPR0x0040
+#define REG_FQPR 0x0060
These names seem too generic to belong in asm/kvm.h - some application
could use the same names. Please add a KVM_ prefix.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/18] KVM: PPC: Teach MMIO Signedness
On 02/04/2010 05:55 PM, Alexander Graf wrote:
The guest I was trying to get to run uses the LHA and LHAU instructions.
Those instructions basically do a load, but also sign extend the result.
Since we need to fill our registers by hand when doing MMIO, we also need
to sign extend manually.
This patch implements sign extended MMIO and the LHA(U) instructions.
@@ -300,6 +300,25 @@ static void kvmppc_complete_mmio_load(struct kvm_vcpu
*vcpu,
}
}
+ if (vcpu-arch.mmio_sign_extend) {
+ switch (run-mmio.len) {
+#ifdef CONFIG_PPC64
+ case 4:
+ if (gpr 0x8000)
+ gpr |= 0xULL;
+ break;
Wouldn't
gpr = (s64)(gpr 32) 32;
work? Not sure if is guaranteed to sign extend.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/8] KVM: Optimize kvm_read_cr[04]_bits()
Avi Kivity wrote: On 02/05/2010 10:26 AM, Jan Kiszka wrote: Avi Kivity wrote: 'mask' is always a constant, so we can check whether it includes a bit that might be owned by the guest very cheaply, and avoid the decache call. Saves a few hundred bytes of module text. -no-kvm-irqchip -smp 2 is broken for my Linux guests since this commit. Their user space applications receive #UD and things fall apart. Does 2c8232fc help? Nope, unfortunately. Jan signature.asc Description: OpenPGP digital signature
Re: [PATCH 7/8] KVM: Optimize kvm_read_cr[04]_bits()
On 02/07/2010 02:33 PM, Jan Kiszka wrote: Avi Kivity wrote: On 02/05/2010 10:26 AM, Jan Kiszka wrote: Avi Kivity wrote: 'mask' is always a constant, so we can check whether it includes a bit that might be owned by the guest very cheaply, and avoid the decache call. Saves a few hundred bytes of module text. -no-kvm-irqchip -smp 2 is broken for my Linux guests since this commit. Their user space applications receive #UD and things fall apart. Does 2c8232fc help? Nope, unfortunately. Which specific guests exhibit the behaviour? -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/11] kvm: Change kvm_iommu_map_pages to map large pages
On Sun, Feb 07, 2010 at 02:22:35PM +0200, Avi Kivity wrote: On 02/05/2010 01:01 PM, Joerg Roedel wrote: Yes, addresses the concern. Are there any further objections against this patchset? If not it would be cool if you could give me some acks for the kvm specific parts of this patchset. There are two ways we can get the kvm bits in: - you publish a git tree excluding the kvm patches, I merge your tree, then apply the kvm specific patches. This is best for avoiding merge-time conflicts if I get other patches for the same area. - you push everything including the kvm bits. I'm fine with both, though prefer the former. If you choose the latter, ACK for the kvm patches. Hmm, the patch set is self-contained and hard to split. We had the same problem with the initial iommu-api merge. Since I have further updates for the AMD IOMMU driver I think its best to send the these patches and my updates directly to Linus after the KVM updates are merged in the next merge window. Thanks for your ACKs :-) Joerg -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 18/18] KVM: PPC: Implement Paired Single emulation
On 02/04/2010 05:55 PM, Alexander Graf wrote:
The one big thing about the Gekko is paired singles.
Paired singles are an extension to the instruction set, that adds 32 single
precision floating point registers (qprs), some SPRs to modify the behavior
of paired singled operations and instructions to deal with qprs to the
instruction set.
Unfortunately, it also changes semantics of existing operations that affect
single values in FPRs. In most cases they get mirrored to the coresponding
QPR.
Thanks to that we need to emulate all FPU operations and all the new paired
single operations too.
In order to achieve that, we take the guest's instruction, rip out the
parameters, put in our own and execute the very same instruction, but also
fix up the QPR values along the way.
That way we can execute paired single FPU operations without implementing a
soft fpu.
A little frightening. How many instructions are there? Maybe we can
just have an array of all of them followed by a return instruction, so
we don't jit code.
static void call_fpu_inst(u32 inst, u64 *out, u64 *in1, u64 *in2, u64 *in3,
+ u32 *cr, u32 *fpscr)
+{
+ u32 cr_val = 0;
+ u32 *call_stack;
+ u64 inout[5] = { 0, 0, 0, 0, 0 };
+
+ if (fpscr)
+ inout[0] = *fpscr;
+ if (in1)
+ inout[1] = *in1;
+ if (in2)
+ inout[2] = *in2;
+ if (in3)
+ inout[3] = *in3;
+ if (cr)
+ cr_val = *cr;
+
+ dprintk(KERN_INFO FPU Emulator 0x%x ( 0x%llx, 0x%llx, 0x%llx ), inst,
+ inout[1], inout[2], inout[3]);
+
+ call_stack =kvmppc_call_stack[(smp_processor_id() * 2)];
+ call_stack[0] = inst;
+ /* call_stack[1] is INS_BLR */
+
Would be easier on the cache to do this per-cpu?
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] KVM: PPC: Virtualize Gekko guests
On 02/04/2010 05:55 PM, Alexander Graf wrote: In an effort to get KVM on PPC more useful for other userspace users than Qemu, I figured it'd be a nice idea to implement virtualization of the Gekko CPU. The Gekko is the CPU used in the GameCube. In a slightly more modern fashion it lives on in the Wii today. Using this patch set and a modified version of Dolphin, I was able to virtualize simple GameCube demos on a 970MP system. As always, while getting this to run I stumbled across several broken parts and fixed them as they came up. So expect some bug fixes in this patch set too. This is halfway into emulation rather than virtualization. What does performance look like when running fpu intensive applications? I might have missed it, but I didn't see the KVM_CAP and save/restore support for this. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 01/21] qemu-kvm: Drop vmport changes
On 02/03/2010 10:53 AM, Jan Kiszka wrote: This attempt to make vmport KVM compatible is half-broken and is scheduled to be replaced by proper upstream support. Does scheduled mean you have patches for adding cpu_synchronize_state() to vmport? -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/8] KVM: Optimize kvm_read_cr[04]_bits()
Avi Kivity wrote: On 02/07/2010 02:33 PM, Jan Kiszka wrote: Avi Kivity wrote: On 02/05/2010 10:26 AM, Jan Kiszka wrote: Avi Kivity wrote: 'mask' is always a constant, so we can check whether it includes a bit that might be owned by the guest very cheaply, and avoid the decache call. Saves a few hundred bytes of module text. -no-kvm-irqchip -smp 2 is broken for my Linux guests since this commit. Their user space applications receive #UD and things fall apart. Does 2c8232fc help? Nope, unfortunately. Which specific guests exhibit the behaviour? 64-bit Linux, various kernels from 2.6.27 to 32. x86-32 appears to be unaffected. Jan signature.asc Description: OpenPGP digital signature
Re: [PATCH v2 14/21] qemu-kvm: Rework VCPU state writeback API
On 02/03/2010 10:53 AM, Jan Kiszka wrote: This grand cleanup drops all reset and vmsave/load related synchronization points in favor of four(!) generic hooks: - cpu_synchronize_all_states in qemu_savevm_state_complete (initial sync from kernel before vmsave) - cpu_synchronize_all_post_init in qemu_loadvm_state (writeback after vmload) - cpu_synchronize_all_post_init in main after machine init - cpu_synchronize_all_post_reset in qemu_system_reset (writeback after system reset) These writeback points + the existing one of VCPU exec after cpu_synchronize_state map on three levels of writeback: - KVM_PUT_ASYNC_STATE (during runtime, other VCPUs continue to run) Wouldn't that be SYNC_STATE (state that is modified by the current vcpu only)? - KVM_PUT_RESET_STATE (on synchronous system reset, all VCPUs stopped) - KVM_PUT_FULL_STATE (on init or vmload, all VCPUs stopped as well) This level is passed to the arch-specific VCPU state writing function that will decide which concrete substates need to be written. That way, no writer of load, save or reset functions that interact with in-kernel KVM states will ever have to worry about synchronization again. That also means that a lot of reasons for races, segfaults and deadlocks are eliminated. cpu_synchronize_state remains untouched, just as Anthony suggested. We continue to need it before reading or writing of VCPU states that are also tracked by in-kernel KVM subsystems. Consequently, this patch removes many cpu_synchronize_state calls that are now redundant, just like remaining explicit register syncs. It does not touch qemu-kvm's special hooks for mpstate, vcpu_events, or tsc loading. They will be cleaned up by individual patches. I'm uneasy about this. What are the rules for putting cpu_synchronize_state() now? -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 14/21] qemu-kvm: Rework VCPU state writeback API
Avi Kivity wrote: On 02/03/2010 10:53 AM, Jan Kiszka wrote: This grand cleanup drops all reset and vmsave/load related synchronization points in favor of four(!) generic hooks: - cpu_synchronize_all_states in qemu_savevm_state_complete (initial sync from kernel before vmsave) - cpu_synchronize_all_post_init in qemu_loadvm_state (writeback after vmload) - cpu_synchronize_all_post_init in main after machine init - cpu_synchronize_all_post_reset in qemu_system_reset (writeback after system reset) These writeback points + the existing one of VCPU exec after cpu_synchronize_state map on three levels of writeback: - KVM_PUT_ASYNC_STATE (during runtime, other VCPUs continue to run) Wouldn't that be SYNC_STATE (state that is modified by the current vcpu only)? It's async /wrt other VCPUs. They continue to run and may interact with this VCPU while updating its state. - KVM_PUT_RESET_STATE (on synchronous system reset, all VCPUs stopped) - KVM_PUT_FULL_STATE (on init or vmload, all VCPUs stopped as well) This level is passed to the arch-specific VCPU state writing function that will decide which concrete substates need to be written. That way, no writer of load, save or reset functions that interact with in-kernel KVM states will ever have to worry about synchronization again. That also means that a lot of reasons for races, segfaults and deadlocks are eliminated. cpu_synchronize_state remains untouched, just as Anthony suggested. We continue to need it before reading or writing of VCPU states that are also tracked by in-kernel KVM subsystems. Consequently, this patch removes many cpu_synchronize_state calls that are now redundant, just like remaining explicit register syncs. It does not touch qemu-kvm's special hooks for mpstate, vcpu_events, or tsc loading. They will be cleaned up by individual patches. I'm uneasy about this. What are the rules for putting cpu_synchronize_state() now? As before for code that accesses the state during runtime: Before you read or write some bit of it, call cpu_synchronize_state(). Only reset and save/restore handlers do not have to worry about synchronization anymore. It makes no sense to overload them with arch-specific KVM knowledge about what shall be written and when. Jan signature.asc Description: OpenPGP digital signature
Re: [PATCH v2 01/21] qemu-kvm: Drop vmport changes
Avi Kivity wrote: On 02/03/2010 10:53 AM, Jan Kiszka wrote: This attempt to make vmport KVM compatible is half-broken and is scheduled to be replaced by proper upstream support. Does scheduled mean you have patches for adding cpu_synchronize_state() to vmport? See patch 2 in this series, and Marcelo already queued that one for upstream. Jan signature.asc Description: OpenPGP digital signature
Re: [PATCH v2 14/21] qemu-kvm: Rework VCPU state writeback API
On 02/07/2010 03:51 PM, Jan Kiszka wrote: Avi Kivity wrote: On 02/03/2010 10:53 AM, Jan Kiszka wrote: This grand cleanup drops all reset and vmsave/load related synchronization points in favor of four(!) generic hooks: - cpu_synchronize_all_states in qemu_savevm_state_complete (initial sync from kernel before vmsave) - cpu_synchronize_all_post_init in qemu_loadvm_state (writeback after vmload) - cpu_synchronize_all_post_init in main after machine init - cpu_synchronize_all_post_reset in qemu_system_reset (writeback after system reset) These writeback points + the existing one of VCPU exec after cpu_synchronize_state map on three levels of writeback: - KVM_PUT_ASYNC_STATE (during runtime, other VCPUs continue to run) Wouldn't that be SYNC_STATE (state that is modified by the current vcpu only)? It's async /wrt other VCPUs. They continue to run and may interact with this VCPU while updating its state. Well, to me it makes more sense to name them from the point of view of the vcpu that is doing the update. I'm uneasy about this. What are the rules for putting cpu_synchronize_state() now? As before for code that accesses the state during runtime: Before you read or write some bit of it, call cpu_synchronize_state(). Only reset and save/restore handlers do not have to worry about synchronization anymore. It makes no sense to overload them with arch-specific KVM knowledge about what shall be written and when. OK. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/11] kvm: Introduce kvm_host_page_size
On Sun, Feb 07, 2010 at 02:09:36PM +0200, Avi Kivity wrote: On 01/28/2010 01:37 PM, Joerg Roedel wrote: This patch introduces a generic function to find out the host page size for a given gfn. This function is needed by the kvm iommu code. This patch also simplifies the x86 host_mapping_level function. Applied to kvm.git since this makes sense independently of the rest of your patchset. Yes, makes sense for this patch. I will rebase my branch once you pushed it out. Joerg -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 14/21] qemu-kvm: Rework VCPU state writeback API
Avi Kivity wrote: On 02/07/2010 03:51 PM, Jan Kiszka wrote: Avi Kivity wrote: On 02/03/2010 10:53 AM, Jan Kiszka wrote: This grand cleanup drops all reset and vmsave/load related synchronization points in favor of four(!) generic hooks: - cpu_synchronize_all_states in qemu_savevm_state_complete (initial sync from kernel before vmsave) - cpu_synchronize_all_post_init in qemu_loadvm_state (writeback after vmload) - cpu_synchronize_all_post_init in main after machine init - cpu_synchronize_all_post_reset in qemu_system_reset (writeback after system reset) These writeback points + the existing one of VCPU exec after cpu_synchronize_state map on three levels of writeback: - KVM_PUT_ASYNC_STATE (during runtime, other VCPUs continue to run) Wouldn't that be SYNC_STATE (state that is modified by the current vcpu only)? It's async /wrt other VCPUs. They continue to run and may interact with this VCPU while updating its state. Well, to me it makes more sense to name them from the point of view of the vcpu that is doing the update. I'm open for a better name - except for sync as writebacks are always synchronous from the POV of the modified VCPU. Is KVM_PUT_RUNTIME_STATE clearer? Jan signature.asc Description: OpenPGP digital signature
Re: [PATCH v2 14/21] qemu-kvm: Rework VCPU state writeback API
On 02/07/2010 04:26 PM, Jan Kiszka wrote: Well, to me it makes more sense to name them from the point of view of the vcpu that is doing the update. I'm open for a better name - except for sync as writebacks are always synchronous from the POV of the modified VCPU. I meant that the state itself is synchronous from the POV of the vcpu. That is, rax can only be changed by the core, but INIT state may be changed by the other cores. Is KVM_PUT_RUNTIME_STATE clearer? They're all runtime. I guess this issue will always be confusing, so best to slap a comment on top of the define to explain it. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] KVM: PPC: Virtualize Gekko guests
Am 07.02.2010 um 13:54 schrieb Avi Kivity a...@redhat.com: On 02/04/2010 05:55 PM, Alexander Graf wrote: In an effort to get KVM on PPC more useful for other userspace users than Qemu, I figured it'd be a nice idea to implement virtualization of the Gekko CPU. The Gekko is the CPU used in the GameCube. In a slightly more modern fashion it lives on in the Wii today. Using this patch set and a modified version of Dolphin, I was able to virtualize simple GameCube demos on a 970MP system. As always, while getting this to run I stumbled across several broken parts and fixed them as they came up. So expect some bug fixes in this patch set too. This is halfway into emulation rather than virtualization. What does performance look like when running fpu intensive applications? It is for the FPU. It is not for whatever runs on the CPU. I haven't benchmarked things so far, The only two choices I have to get this running is in-kernel emulation or userspace emulation. According to how x86 deals with things I suppose full state transition to userspace and continuing emulation there isn't considered a good idea. So I went with in-kernel. I might have missed it, but I didn't see the KVM_CAP and save/ restore support for this. Ah, cap again. Right. Mind if I send an patch on top of the set? As far as save/restore goes, the ioctl to get/set fprs isn't even implemented (yet)! We're really off full state migration to/from userspace yet. Alex -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/18] KVM: PPC: Teach MMIO Signedness
Am 07.02.2010 um 13:32 schrieb Avi Kivity a...@redhat.com:
On 02/04/2010 05:55 PM, Alexander Graf wrote:
The guest I was trying to get to run uses the LHA and LHAU
instructions.
Those instructions basically do a load, but also sign extend the
result.
Since we need to fill our registers by hand when doing MMIO, we
also need
to sign extend manually.
This patch implements sign extended MMIO and the LHA(U) instructions.
@@ -300,6 +300,25 @@ static void kvmppc_complete_mmio_load(struct
kvm_vcpu *vcpu,
}
}
+if (vcpu-arch.mmio_sign_extend) {
+switch (run-mmio.len) {
+#ifdef CONFIG_PPC64
+case 4:
+if (gpr 0x8000)
+gpr |= 0xULL;
+break;
Wouldn't
gpr = (s64)(gpr 32) 32;
work? Not sure if is guaranteed to sign extend.
Not sure either. The code as is is rather obvious imho, so I wouldn't
want to replace it with anything that's even remotely magical.
Alex
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/18] KVM: PPC: Enable MMIO to do 64 bits, fprs and qprs
Am 07.02.2010 um 13:29 schrieb Avi Kivity a...@redhat.com:
On 02/04/2010 05:55 PM, Alexander Graf wrote:
Right now MMIO access can only happen for GPRs and is at most 32
bit wide.
That's actually enough for almost all types of hardware out there.
Unfortunately, the guest I was using used FPU writes to MMIO
regions, so
it ended up writing 64 bit MMIOs using FPRs and QPRs.
So let's add code to handle those odd cases too.
Signed-off-by: Alexander Grafag...@suse.de
---
arch/powerpc/include/asm/kvm.h |7 +++
arch/powerpc/include/asm/kvm_ppc.h |2 +-
arch/powerpc/kvm/powerpc.c | 24 ++--
3 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm.h b/arch/powerpc/include/
asm/kvm.h
index 81f3b0b..548376c 100644
--- a/arch/powerpc/include/asm/kvm.h
+++ b/arch/powerpc/include/asm/kvm.h
@@ -77,4 +77,11 @@ struct kvm_debug_exit_arch {
struct kvm_guest_debug_arch {
};
+#define REG_MASK0x001f
+#define REG_EXT_MASK0xffe0
+#define REG_GPR0x
+#define REG_FPR0x0020
+#define REG_QPR0x0040
+#define REG_FQPR0x0060
These names seem too generic to belong in asm/kvm.h - some
application could use the same names. Please add a KVM_ prefix.
Yes, will do.
Alex
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 18/18] KVM: PPC: Implement Paired Single emulation
Am 07.02.2010 um 13:50 schrieb Avi Kivity a...@redhat.com:
On 02/04/2010 05:55 PM, Alexander Graf wrote:
The one big thing about the Gekko is paired singles.
Paired singles are an extension to the instruction set, that adds
32 single
precision floating point registers (qprs), some SPRs to modify the
behavior
of paired singled operations and instructions to deal with qprs to
the
instruction set.
Unfortunately, it also changes semantics of existing operations
that affect
single values in FPRs. In most cases they get mirrored to the
coresponding
QPR.
Thanks to that we need to emulate all FPU operations and all the
new paired
single operations too.
In order to achieve that, we take the guest's instruction, rip out
the
parameters, put in our own and execute the very same instruction,
but also
fix up the QPR values along the way.
That way we can execute paired single FPU operations without
implementing a
soft fpu.
A little frightening. How many instructions are there? Maybe we
can just have an array of all of them followed by a return
instruction, so we don't jit code.
There's all the instructions in the list, most can have the rc
(compare) bit set to modify CC and iirc there were a couple ones with
immediate values.
But maybe you're right. I probably could just always set rc and either
ignore the result or use it. I could maybe find alternatives to
immediate using instructions. Let me check this on the bus trip back
from brussels.
static void call_fpu_inst(u32 inst, u64 *out, u64 *in1, u64 *in2,
u64 *in3,
+ u32 *cr, u32 *fpscr)
+{
+u32 cr_val = 0;
+u32 *call_stack;
+u64 inout[5] = { 0, 0, 0, 0, 0 };
+
+if (fpscr)
+inout[0] = *fpscr;
+if (in1)
+inout[1] = *in1;
+if (in2)
+inout[2] = *in2;
+if (in3)
+inout[3] = *in3;
+if (cr)
+cr_val = *cr;
+
+dprintk(KERN_INFO FPU Emulator 0x%x ( 0x%llx, 0x%llx, 0x
%llx ), inst,
+inout[1], inout[2], inout[3]);
+
+call_stack =kvmppc_call_stack[(smp_processor_id() * 2)];
+call_stack[0] = inst;
+/* call_stack[1] is INS_BLR */
+
Would be easier on the cache to do this per-cpu?
It is per-cpu. Or do you mean to actually use the PER_CPU definition?
Is that guaranteed to be executable?
Alex
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/18] KVM: PPC: Teach MMIO Signedness
On 02/07/2010 05:51 PM, Alexander Graf wrote:
+if (vcpu-arch.mmio_sign_extend) {
+switch (run-mmio.len) {
+#ifdef CONFIG_PPC64
+case 4:
+if (gpr 0x8000)
+gpr |= 0xULL;
+break;
Wouldn't
gpr = (s64)(gpr 32) 32;
work? Not sure if is guaranteed to sign extend.
Not sure either. The code as is is rather obvious imho, so I wouldn't
want to replace it with anything that's even remotely magical.
That's fair.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 18/18] KVM: PPC: Implement Paired Single emulation
On 02/07/2010 05:57 PM, Alexander Graf wrote:+ +dprintk(KERN_INFO FPU Emulator 0x%x ( 0x%llx, 0x%llx, 0x%llx ), inst, +inout[1], inout[2], inout[3]); + +call_stack =kvmppc_call_stack[(smp_processor_id() * 2)]; +call_stack[0] = inst; +/* call_stack[1] is INS_BLR */ + Would be easier on the cache to do this per-cpu? It is per-cpu. Or do you mean to actually use the PER_CPU definition? Is that guaranteed to be executable? I meant, per-cpu vmalloc area, but it should be enough to have a per-cpu cache line. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] KVM: PPC: Virtualize Gekko guests
On 02/07/2010 05:49 PM, Alexander Graf wrote: Am 07.02.2010 um 13:54 schrieb Avi Kivity a...@redhat.com: On 02/04/2010 05:55 PM, Alexander Graf wrote: In an effort to get KVM on PPC more useful for other userspace users than Qemu, I figured it'd be a nice idea to implement virtualization of the Gekko CPU. The Gekko is the CPU used in the GameCube. In a slightly more modern fashion it lives on in the Wii today. Using this patch set and a modified version of Dolphin, I was able to virtualize simple GameCube demos on a 970MP system. As always, while getting this to run I stumbled across several broken parts and fixed them as they came up. So expect some bug fixes in this patch set too. This is halfway into emulation rather than virtualization. What does performance look like when running fpu intensive applications? It is for the FPU. It is not for whatever runs on the CPU. I haven't benchmarked things so far, The only two choices I have to get this running is in-kernel emulation or userspace emulation. According to how x86 deals with things I suppose full state transition to userspace and continuing emulation there isn't considered a good idea. So I went with in-kernel. It's not a good idea for the kernel either, if it happens all the time. If a typical Gekko application uses the fpu and the emulated instructions intensively, performance will suck badly (as in: qemu/tcg will be faster). -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm 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] [PATCH] Add assignment operation to config file parser..
On 02/06/2010 12:59 PM, john cooper wrote: This patch reworks support for both assignment and append in the config file parser. It was motivated by comments received on the cpu model config file format. Commit dc9ca4ba27be4fe6a0284061b8f056c4364fb0d9 changed the behavior of = from assign to append. This patch preserves the ability to append to an option (however now via +=), reverts = to its previous behavior, and allows both to interoperate. Signed-off-by: john cooperjohn.coo...@redhat.com This deviates from standard ini syntax which makes me a big uncomfortable with it. Gerd, do you have an opinion? Regards, Anthony Liguori -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/18] KVM: PPC: Teach MMIO Signedness
On 02/07/2010 06:32 AM, Avi Kivity wrote:
On 02/04/2010 05:55 PM, Alexander Graf wrote:
The guest I was trying to get to run uses the LHA and LHAU instructions.
Those instructions basically do a load, but also sign extend the result.
Since we need to fill our registers by hand when doing MMIO, we also
need
to sign extend manually.
This patch implements sign extended MMIO and the LHA(U) instructions.
@@ -300,6 +300,25 @@ static void kvmppc_complete_mmio_load(struct
kvm_vcpu *vcpu,
}
}
+if (vcpu-arch.mmio_sign_extend) {
+switch (run-mmio.len) {
+#ifdef CONFIG_PPC64
+case 4:
+if (gpr 0x8000)
+gpr |= 0xULL;
+break;
Wouldn't
gpr = (s64)(gpr 32) 32;
work? Not sure if is guaranteed to sign extend.
It's technically implementation dependent but I don't know of an
implementation that doesn't sign extend.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM test: Ensure multiple pre/post commands can run
- Lucas Meneghel Rodrigues l...@redhat.com wrote: The way tests are currently defined, running unattended install + hugepages will allways skip unattended install setup step (coincidentally the tests on our test farm were working because previous executions of the unattended install script ran, leaving the environment prepared for unattended install). So, make sure pre_commands on default tests.cfg file are additive, and the preprocessor splits the pre_command string, and executes pre/post commands in sequence. Signed-off-by: Lucas Meneghel Rodrigues l...@redhat.com Why not just append ';' to each command? For example: pre_command = scripts/unattended.py; ... pre_command += scripts/hugepage.py; (the quotes can be omitted) IMO this is simpler. Also, by using .split() you're not allowing commands that contain spaces. --- client/tests/kvm/kvm_preprocessing.py | 29 - client/tests/kvm/tests_base.cfg.sample |4 ++-- 2 files changed, 18 insertions(+), 15 deletions(-) diff --git a/client/tests/kvm/kvm_preprocessing.py b/client/tests/kvm/kvm_preprocessing.py index 8a0c151..2e35d9f 100644 --- a/client/tests/kvm/kvm_preprocessing.py +++ b/client/tests/kvm/kvm_preprocessing.py @@ -126,7 +126,7 @@ def postprocess_vm(test, params, env, name): vm.destroy(gracefully = params.get(kill_vm_gracefully) == yes) -def process_command(test, params, env, command, command_timeout, +def process_command(test, params, env, commands, command_timeout, command_noncritical): Pre- or post- custom commands to be executed before/after a test is run @@ -134,22 +134,23 @@ def process_command(test, params, env, command, command_timeout, @param test: An Autotest test object. @param params: A dict containing all VM and image parameters. @param env: The environment (a dict-like object). -@param command: Command to be run. +@param commands: List of commands to be run. @param command_timeout: Timeout for command execution. @param command_noncritical: If True test will not fail if command fails. # Export environment vars for k in params.keys(): os.putenv(KVM_TEST_%s % k, str(params[k])) -# Execute command -try: -utils.system(cd %s; %s % (test.bindir, command)) -except error.CmdError, e: -logging.warn(Custom processing command '%s' failed, output is: %s, - command, str(e)) -if not command_noncritical: -raise error.TestError(Custom processing command failed: %s % - str(e)) +# Execute commands +for command in commands: +try: +utils.system(cd %s; %s % (test.bindir, command)) +except error.CmdError, e: +logging.warn(Custom processing command '%s' failed, output is: %s, + command, str(e)) +if not command_noncritical: +raise error.TestError(Custom processing command failed: %s % + str(e)) def process(test, params, env, image_func, vm_func): @@ -220,7 +221,8 @@ def preprocess(test, params, env): # Execute any pre_commands if params.get(pre_command): -process_command(test, params, env, params.get(pre_command), +pre_commands = params.get(pre_command).spit() +process_command(test, params, env, pre_commands, int(params.get(pre_command_timeout, 600)), params.get(pre_command_noncritical) == yes) @@ -296,7 +298,8 @@ def postprocess(test, params, env): # Execute any post_commands if params.get(post_command): -process_command(test, params, env, params.get(post_command), +post_commands = params.get(post_command).split() +process_command(test, params, env, post_commands, int(params.get(post_command_timeout, 600)), params.get(post_command_noncritical) == yes) diff --git a/client/tests/kvm/tests_base.cfg.sample b/client/tests/kvm/tests_base.cfg.sample index 91daf48..8f88f3b 100644 --- a/client/tests/kvm/tests_base.cfg.sample +++ b/client/tests/kvm/tests_base.cfg.sample @@ -66,7 +66,7 @@ variants: kill_vm_gracefully = yes kill_vm_on_error = yes force_create_image = yes -pre_command = scripts/unattended.py +pre_command += scripts/unattended.py floppy = images/floppy.img extra_params += -boot d nic_mode = user @@ -953,7 +953,7 @@ variants: variants: - @smallpages: - hugepages: -pre_command = /usr/bin/python scripts/hugepage.py /mnt/kvm_hugepage +pre_command += scripts/hugepage.py extra_params += -mem-path /mnt/kvm_hugepage -- 1.6.6 -- To unsubscribe from this list:
Re: [PATCH] KVM: tests_base.cfg: major guest OS cleanup
- Lucas Meneghel Rodrigues l...@redhat.com wrote: Major update and cleanup on guest OS definition: * Fedora 8, 9, 10 dropped * RHEL versions bumped to the latest stable versions * Windows 2008, Vista and 7 bumped to the last versions * Some duplicate information re-organized Looks like you dropped all step file tests, and I don't think this is a good idea. Keeping them is harmless, so I don't think they should be dropped unless they're completely useless. If you don't want them to run, keep them out of the sample test sets, but by removing them entirely from the sample config file, you're making it much harder for those who use them to keep using them. Of course, if we become quite confident that no one will ever want to use step files again, getting rid of them isn't bad. I do however think that some people will keep using them, and I even think it's a good idea to run a quick step file test as part of our daily routine on autotest.virt.bos, just to make sure KVM displays stuff properly and responds to keyboard input. Regarding reorganizing duplicate information: You don't need to get rid of step file tests in order to avoid config code duplication. You can reuse information like this: - 11.32: image_name = fc11-32 ... (common stuff) ... install: steps = Fedora-11-32.steps (install specific stuff) unattended_install: unattended_file = unattended/something (unattended_install specific stuff) Regarding version bumping: Since bumping guest OS versions breaks step file installs, I think we should either keep the old versions next to the new ones in the same config file, and exclude them from sample test sets, or keep them in a separate config file, e.g. tests_base_old.cfg.sample (or tests_base.cfg.sample.old?). In any case, I don't think we should remove the old versions. This also applies to the old Fedoras. Signed-off-by: Lucas Meneghel Rodrigues l...@redhat.com --- client/tests/kvm/tests_base.cfg.sample | 286 --- client/tests/kvm/unattended/winxp64.sif | 73 2 files changed, 149 insertions(+), 210 deletions(-) create mode 100644 client/tests/kvm/unattended/winxp64.sif diff --git a/client/tests/kvm/tests_base.cfg.sample b/client/tests/kvm/tests_base.cfg.sample index 8f88f3b..110be98 100644 --- a/client/tests/kvm/tests_base.cfg.sample +++ b/client/tests/kvm/tests_base.cfg.sample @@ -311,47 +311,8 @@ variants: shell_prompt = ^\[.*\][\#\$]\s*$ variants: -- 8.32: -no setup -image_name = fc8-32 -install: -steps = Fedora-8-i386.steps -cdrom = linux/Fedora-8-i386-DVD.iso -md5sum = dd6c79fddfff36d409d02242e7b10189 -md5sum_1m = dabae451bb69fbbad0e505b25144b1f9 - -- 8.64: -no setup -image_name = fc8-64 -install: -steps = Fedora-8-64.steps -cdrom = linux/Fedora-8-x86_64-DVD.iso -md5sum = 2cb231a86709dec413425fd2f8bf5295 -md5sum_1m = 145f6414e19492649a56c89f0a45e719 - -- 9.32: -image_name = fc9-32 -install: -steps = Fedora-9-i386.steps -cdrom = linux/Fedora-9-i386-DVD.iso -md5sum = 72601f685ea8c808c303353d8bf4d307 -md5sum_1m = f24fa25689e5863f1b99984c6feb787f - -- 9.64: -image_name = fc9-64 -install: -steps = Fedora-9-64.steps -cdrom = linux/Fedora-9-x86_64-DVD.iso -md5sum = 05b2ebeed273ec54d6f9ed3d61ea4c96 -md5sum_1m = 9822ab5097e37e8fe306ef2192727db4 - - 11.32: image_name = fc11-32 -install: -steps = Fedora-11-32.steps -cdrom = linux/Fedora-11-i386-DVD.iso -md5sum = e3b1e2d1ba42aa4705fa5f41771b3927 -md5sum_1m = dc8ddf90648c247339c721395aa49714 unattended_install: cdrom = linux/Fedora-11-i386-DVD.iso md5sum = e3b1e2d1ba42aa4705fa5f41771b3927 @@ -363,12 +324,6 @@ variants: - 11.64: image_name = fc11-64 -install: -cdrom = linux/Fedora-11-x86_64-DVD.iso -
Re: [PATCH 06/11] kvm: Change kvm_iommu_map_pages to map large pages
On Sun, Feb 07, 2010 at 02:18:19PM +0200, Avi Kivity wrote:
On 01/29/2010 12:24 AM, Marcelo Tosatti wrote:
On Thu, Jan 28, 2010 at 12:37:57PM +0100, Joerg Roedel wrote:
This patch changes the implementation of of
kvm_iommu_map_pages to map the pages with the host page size
into the io virtual address space.
Signed-off-by: Joerg Roedeljoerg.roe...@amd.com
---
virt/kvm/iommu.c | 106
++---
1 files changed, 84 insertions(+), 22 deletions(-)
diff --git a/virt/kvm/iommu.c b/virt/kvm/iommu.c
index 65a5143..92a434d 100644
--- a/virt/kvm/iommu.c
+++ b/virt/kvm/iommu.c
@@ -32,12 +32,27 @@ static int kvm_iommu_unmap_memslots(struct kvm *kvm);
static void kvm_iommu_put_pages(struct kvm *kvm,
gfn_t base_gfn, unsigned long npages);
+static pfn_t kvm_pin_pages(struct kvm *kvm, struct kvm_memory_slot *slot,
+ gfn_t gfn, unsigned long size)
+{
+ gfn_t end_gfn;
+ pfn_t pfn;
+
+ pfn = gfn_to_pfn_memslot(kvm, slot, gfn);
If gfn_to_pfn_memslot returns pfn of bad_page, you might create a
large iommu translation for it?
How could it return a bad_page? The whole thing is called for a valid slot.
Userspace can pass a valid slot with a read-only vma, for example.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] emulate accessed bit for EPT
On Fri, Feb 05, 2010 at 07:14:13PM +0100, Andrea Arcangeli wrote: On Fri, Feb 05, 2010 at 03:34:23PM -0200, Marcelo Tosatti wrote: But perhaps a module parameter to turn accessed bit emulation off might be handy in the future? Maybe, but somebody should show that this can overall become a downside, which I doubt... I think if it does, the VM is to blame for calling page_referenced when there is no point to do so just yet. Agreed. ACK. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/18] KVM: PPC: Teach MMIO Signedness
Am 07.02.2010 um 17:27 schrieb Anthony Liguori anth...@codemonkey.ws:
On 02/07/2010 06:32 AM, Avi Kivity wrote:
On 02/04/2010 05:55 PM, Alexander Graf wrote:
The guest I was trying to get to run uses the LHA and LHAU
instructions.
Those instructions basically do a load, but also sign extend the
result.
Since we need to fill our registers by hand when doing MMIO, we
also need
to sign extend manually.
This patch implements sign extended MMIO and the LHA(U)
instructions.
@@ -300,6 +300,25 @@ static void kvmppc_complete_mmio_load(struct
kvm_vcpu *vcpu,
}
}
+if (vcpu-arch.mmio_sign_extend) {
+switch (run-mmio.len) {
+#ifdef CONFIG_PPC64
+case 4:
+if (gpr 0x8000)
+gpr |= 0xULL;
+break;
Wouldn't
gpr = (s64)(gpr 32) 32;
work? Not sure if is guaranteed to sign extend.
It's technically implementation dependent but I don't know of an
implementation that doesn't sign extend.
Hrm, would
gpr = (s64)(s32)gpr;
work? :)
Alex
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] KVM: PPC: Virtualize Gekko guests
Avi Kivity wrote: On 02/07/2010 05:49 PM, Alexander Graf wrote: Am 07.02.2010 um 13:54 schrieb Avi Kivity a...@redhat.com: On 02/04/2010 05:55 PM, Alexander Graf wrote: In an effort to get KVM on PPC more useful for other userspace users than Qemu, I figured it'd be a nice idea to implement virtualization of the Gekko CPU. The Gekko is the CPU used in the GameCube. In a slightly more modern fashion it lives on in the Wii today. Using this patch set and a modified version of Dolphin, I was able to virtualize simple GameCube demos on a 970MP system. As always, while getting this to run I stumbled across several broken parts and fixed them as they came up. So expect some bug fixes in this patch set too. This is halfway into emulation rather than virtualization. What does performance look like when running fpu intensive applications? It is for the FPU. It is not for whatever runs on the CPU. I haven't benchmarked things so far, The only two choices I have to get this running is in-kernel emulation or userspace emulation. According to how x86 deals with things I suppose full state transition to userspace and continuing emulation there isn't considered a good idea. So I went with in-kernel. It's not a good idea for the kernel either, if it happens all the time. If a typical Gekko application uses the fpu and the emulated instructions intensively, performance will suck badly (as in: qemu/tcg will be faster). Yeah, I haven't really gotten far enough to run full-blown guests yet. So far I'm on demos and they look pretty good. But as far as intercept speed goes - I just tried running this little piece of code in kvmctl: .global _start _start: lir3, 42 mtsprg0, r3 mfsprgr4, 0 b_start and measured the amount of exits I get on my test machine: processor: 0 cpu: PPC970MP, altivec supported clock: 2500.00MHz revision: 1.1 (pvr 0044 0101) --- exits 1811108 I have no idea how we manage to get that many exits, but apparently we are. So I'm less concerned about the speed of the FPU rerouting at the moment. If it really gets unusably slow, I'd rather binary patch the guest on the fly in KVM according to rules set by the userspace client. But we'll get there when it turns out to be too slow. For now I'd rather like to have something working at all and then improve speed :-). Alex -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/18] KVM: PPC: Teach MMIO Signedness
On 02/07/2010 03:35 PM, Alexander Graf wrote: It's technically implementation dependent but I don't know of an implementation that doesn't sign extend. Hrm, would gpr = (s64)(s32)gpr; work? :) Yes. Integer promotion does guarantee sign extension. Regards, Anthony Liguori Alex -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: tests_base.cfg: major guest OS cleanup
On Sun, 2010-02-07 at 13:24 -0500, Michael Goldish wrote: Let me explain the reasoning behind this: Looks like you dropped all step file tests, and I don't think this is a good idea. Keeping them is harmless, so I don't think they should be dropped unless they're completely useless. If you don't want them to run, keep them out of the sample test sets, but by removing them entirely from the sample config file, you're making it much harder for those who use them to keep using them. Good point, I didn't mean to do it just for the sake of not having them anymore: * In the vast majority of the cases, I have downloaded and tested the latest ISOS from the OS vendors, and tested it with the unattended files. I do admit that I didn't try the step files, but I assumed they wouldn't work so that's why I dropped them. * Removing older versions of distributions like Fedora have good reason: The support cycle of them is very short (18 months), by their very nature (Fedora is a technology preview, we are allways moving on). So it's not reasonable to keep testing guest OS that might have bugs that no one will care to fix. * As for the longer living versions of OS, like windows and RHEL, there's a clear version for using the latest versions as well: The OS vendors usually provide the updates (I mean inside a same family of that OS, like RHEL 3.X, or windows2008) and they strongly advise System Adminsitrators to allways use the latest version when installing new systems. In other words, let's say we find a bug on RHEL 5.3. The very first thing we'll be asked to is to try reproducing the problem on 5.4, and if it doesn't, the bug will be closed (same if you are using windows [version] SP X, they will allways ask you to try the latest SP). So IMHO it's important to focus our testing resources on the versions of the OS that will be used on new installs by the general IT public. So I looked after the latest ISOS that the vendors had to offer and tested only with step install, since I didn't have to change the unattended files for doing so. Of course, if we become quite confident that no one will ever want to use step files again, getting rid of them isn't bad. I do however think that some people will keep using them, and I even think it's a good idea to run a quick step file test as part of our daily routine on autotest.virt.bos, just to make sure KVM displays stuff properly and responds to keyboard input. Yes, I do think step installs are important: * Good method to verify input and image display, like you just mentioned; * They are truly a universal way to get OSs installed. So if the given OS has no reasonable unattended install system, we have step file based install ready to rescue us. So in terms of maintance, we are better of keeping unattended installs for the OSs we know how to do it, but keep up to date step files for the guest OSs that we can't use with unattended. Like, bump the versions for all the OSs that we can't do unattended version, and have up to date step files for those. Regarding reorganizing duplicate information: You don't need to get rid of step file tests in order to avoid config code duplication. You can reuse information like this: - 11.32: image_name = fc11-32 ... (common stuff) ... install: steps = Fedora-11-32.steps (install specific stuff) unattended_install: unattended_file = unattended/something (unattended_install specific stuff) Sure, most of step file removals were due to the fact that I introduced new ISOs, like I explained before. Regarding version bumping: Since bumping guest OS versions breaks step file installs, I think we should either keep the old versions next to the new ones in the same config file, and exclude them from sample test sets, or keep them in a separate config file, e.g. tests_base_old.cfg.sample (or tests_base.cfg.sample.old?). In any case, I don't think we should remove the old versions. This also applies to the old Fedoras. We could keep them, but like I've said, we should focus our testing resources using the latest versions provided by the OS vendors. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: tests_base.cfg: major guest OS cleanup
On Sun, Feb 07, 2010 at 09:26:21PM -0200, Lucas Meneghel Rodrigues wrote: On Sun, 2010-02-07 at 13:24 -0500, Michael Goldish wrote: Let me explain the reasoning behind this: Looks like you dropped all step file tests, and I don't think this is a good idea. Keeping them is harmless, so I don't think they should be dropped unless they're completely useless. If you don't want them to run, keep them out of the sample test sets, but by removing them entirely from the sample config file, you're making it much harder for those who use them to keep using them. Good point, I didn't mean to do it just for the sake of not having them anymore: * In the vast majority of the cases, I have downloaded and tested the latest ISOS from the OS vendors, and tested it with the unattended files. I do admit that I didn't try the step files, but I assumed they wouldn't work so that's why I dropped them. * Removing older versions of distributions like Fedora have good reason: The support cycle of them is very short (18 months), by their very nature (Fedora is a technology preview, we are allways moving on). So it's not reasonable to keep testing guest OS that might have bugs that no one will care to fix. Disagree. Testing of older guests can trigger KVM bugs which are not seen during testing of newer ones. * As for the longer living versions of OS, like windows and RHEL, there's a clear version for using the latest versions as well: The OS vendors usually provide the updates (I mean inside a same family of that OS, like RHEL 3.X, or windows2008) and they strongly advise System Adminsitrators to allways use the latest version when installing new systems. In other words, let's say we find a bug on RHEL 5.3. The very first thing we'll be asked to is to try reproducing the problem on 5.4, and if it doesn't, the bug will be closed (same if you are using windows [version] SP X, they will allways ask you to try the latest SP). Not really. If the test succeeded before, and it regresses after qemu or KVM changes, its a bug we should care about. So IMHO it's important to focus our testing resources on the versions of the OS that will be used on new installs by the general IT public. So I looked after the latest ISOS that the vendors had to offer and tested only with step install, since I didn't have to change the unattended files for doing so. Of course, if we become quite confident that no one will ever want to use step files again, getting rid of them isn't bad. I do however think that some people will keep using them, and I even think it's a good idea to run a quick step file test as part of our daily routine on autotest.virt.bos, just to make sure KVM displays stuff properly and responds to keyboard input. Yes, I do think step installs are important: * Good method to verify input and image display, like you just mentioned; * They are truly a universal way to get OSs installed. So if the given OS has no reasonable unattended install system, we have step file based install ready to rescue us. So in terms of maintance, we are better of keeping unattended installs for the OSs we know how to do it, but keep up to date step files for the guest OSs that we can't use with unattended. Like, bump the versions for all the OSs that we can't do unattended version, and have up to date step files for those. Why don't keep both? Regarding reorganizing duplicate information: You don't need to get rid of step file tests in order to avoid config code duplication. You can reuse information like this: - 11.32: image_name = fc11-32 ... (common stuff) ... install: steps = Fedora-11-32.steps (install specific stuff) unattended_install: unattended_file = unattended/something (unattended_install specific stuff) Sure, most of step file removals were due to the fact that I introduced new ISOs, like I explained before. Regarding version bumping: Since bumping guest OS versions breaks step file installs, I think we should either keep the old versions next to the new ones in the same config file, and exclude them from sample test sets, or keep them in a separate config file, e.g. tests_base_old.cfg.sample (or tests_base.cfg.sample.old?). In any case, I don't think we should remove the old versions. This also applies to the old Fedoras. We could keep them, but like I've said, we should focus our testing resources using the latest versions provided by the OS vendors. Agree, but please keep the old step file method around in the reposity for all guests. Not only they can be useful if problems arise with unattended install, but the screen comparison method that is used can find bugs that unattended install cannot (issues that involves drawing the screen). -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to
Re: [PATCH] KVM test: Ensure multiple pre/post commands can run
On Sun, 2010-02-07 at 12:59 -0500, Michael Goldish wrote: - Lucas Meneghel Rodrigues l...@redhat.com wrote: The way tests are currently defined, running unattended install + hugepages will allways skip unattended install setup step (coincidentally the tests on our test farm were working because previous executions of the unattended install script ran, leaving the environment prepared for unattended install). So, make sure pre_commands on default tests.cfg file are additive, and the preprocessor splits the pre_command string, and executes pre/post commands in sequence. Signed-off-by: Lucas Meneghel Rodrigues l...@redhat.com Why not just append ';' to each command? For example: pre_command = scripts/unattended.py; ... pre_command += scripts/hugepage.py; (the quotes can be omitted) IMO this is simpler. Yes, agreed. Will revert the patch and fix this. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1 net-next] virtio_net: remove send queue
On Wed, 3 Feb 2010 08:18:51 am Shirley Ma wrote: Use detach buffers API in virtio to free unused buffers in send queue when shutting down virtio_net to avoid maintaining skb link list for each transmit packet. Signed-off-by: Shirley Ma x...@us.ibm.com Hi Shirley, Nice cleanup. Please cc: net...@vger.kernel.org for net patches... Your comment could be slightly enhanced to indicate that the API is new, eg; Now we have a virtio detach API (in commit XX), we don't need to track xmit skbs in the driver. Acked-by: Rusty Russell ru...@rustcorp.com.au Thanks! Rusty. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: tests_base.cfg: major guest OS cleanup
On Sun, 2010-02-07 at 22:44 -0200, Marcelo Tosatti wrote: On Sun, Feb 07, 2010 at 09:26:21PM -0200, Lucas Meneghel Rodrigues wrote: * Removing older versions of distributions like Fedora have good reason: The support cycle of them is very short (18 months), by their very nature (Fedora is a technology preview, we are allways moving on). So it's not reasonable to keep testing guest OS that might have bugs that no one will care to fix. Disagree. Testing of older guests can trigger KVM bugs which are not seen during testing of newer ones. Ok, that's a fair concern, we need to make sure that bugs found on older guests will get enough attention though. So in terms of maintance, we are better of keeping unattended installs for the OSs we know how to do it, but keep up to date step files for the guest OSs that we can't use with unattended. Like, bump the versions for all the OSs that we can't do unattended version, and have up to date step files for those. Why don't keep both? Mostly because it was my understanding that we only cared about bugs on the latest versions of each supported OS, given that premise it made sense to me to keep only unattended install, which depends less on OS details (for example, the same kickstart and answer files could be used verbatim to both old and new versions of the OSes). But now I see your point and Michael's, sorry, will bring back all the step file install parameters back. We could keep them, but like I've said, we should focus our testing resources using the latest versions provided by the OS vendors. Agree, but please keep the old step file method around in the reposity for all guests. Not only they can be useful if problems arise with unattended install, but the screen comparison method that is used can find bugs that unattended install cannot (issues that involves drawing the screen). All righty, will get them all back during the morning! Lucas -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] qemu-kvm: Speed up of the dirty-bitmap-traveling
Sounds logical - do you have numbers on the improvement? Sure. The patch showed approximately 3-7 times speed up when measured with rdtsc. The test environment and detailed results are described below. --- tmp = rdtsc(); /* function of original code*/ t1 += rdtsc() - tmp; tmp = rdtsc(); /* function of this patch */ t2 += rdtsc() - tmp; --- Test Envirionment: CPU: 4x Intel Xeon Quad Core 2.66GHz Mem size: 6GB kvm version: 2.6.31-17-server qemu version: commit ed880109f74f0a4dd5b7ec09e6a2d9ba4903d9a5 Host OS: Ubuntu 9.10 (kernel 2.6.31) Guest OS: Debian/GNU Linux lenny (kernel 2.6.26) Guest Mem size: 512MB We executed live migration three times. This data shows, how many times the function is called (#called), runtime of original (orig.), runtime of this patch (patch), speedup ratio (ratio), when live migration run. Experimental results: Test1: Guest OS read 3GB file, which is bigger than memory. #called orig.(msec) patch(msec) ratio 114 1.000.156.76 132 1.570.256.26 96 1.000.166.27 Test2: Guest OS read/write 3GB file, which is bigger than memory. #called orig.(msec) patch(msec) ratio 219638.110.63.59 225639.610.83.68 211236.310.33.53 Would be great if you could provide a version for upstream as well because it will likely replace this qemu-kvm code on day. O.K. We'll prepare it. We'll also post a patch set to quicken dirty pages checking in ram_save_block and ram_save_live soon. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
vnc mouse trouble; -usbdevice tablet no help
I have been unable to get the real mouse and the virtualized mouse to stay together when using kvm with linux host, guest and client. Previous advice (to me and others) was to use -usbdevice tablet. I've tried that, and a variety of kvm/qemu versions, but no luck. Can anyone suggest what to do, or how to diagnose it? vnc and the mouse work OK for Windows XP guests. Host system: Intel(R) Xeon(R) CPU E5420 @ 2.50GHz, 8 cores qemu-kvm 0.12.2, built from source linux 2.6.32-trunk-amd64 (stock Debian kernel) guest linux 2.6.26-2-amd64 Invoked with sudo vdeq bin/qemu-system-x86_64 -net nic,vlan=1,macaddr=52:54:a0:14:01:01 \ -name Lenny BCU Server \ -vga std -vnc localhost:5 -usb -usbdevice tablet \ -net vde,vlan=1,sock=/var/run/vde2/tap0.ctl \ -boot c \ -hda /dev/turtle/Lenny06BCU \ -soundhw es1370 -m 1G -smp 2 I've tried without the -usb; I added it hoping it would help. It didn't. My client has been either the host system or 32 bit linux system. Mostly I've used krdc. All systems basically Debian Lenny, with bits from later releases (e.g., the kernel on the host). -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/18] KVM: PPC: Enable MMIO to do 64 bits, fprs and qprs
On 02/04/2010 05:55 PM, Alexander Graf wrote:
Right now MMIO access can only happen for GPRs and is at most 32 bit wide.
That's actually enough for almost all types of hardware out there.
Unfortunately, the guest I was using used FPU writes to MMIO regions, so
it ended up writing 64 bit MMIOs using FPRs and QPRs.
So let's add code to handle those odd cases too.
Signed-off-by: Alexander Grafag...@suse.de
---
arch/powerpc/include/asm/kvm.h |7 +++
arch/powerpc/include/asm/kvm_ppc.h |2 +-
arch/powerpc/kvm/powerpc.c | 24 ++--
3 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm.h b/arch/powerpc/include/asm/kvm.h
index 81f3b0b..548376c 100644
--- a/arch/powerpc/include/asm/kvm.h
+++ b/arch/powerpc/include/asm/kvm.h
@@ -77,4 +77,11 @@ struct kvm_debug_exit_arch {
struct kvm_guest_debug_arch {
};
+#define REG_MASK 0x001f
+#define REG_EXT_MASK 0xffe0
+#define REG_GPR0x
+#define REG_FPR0x0020
+#define REG_QPR0x0040
+#define REG_FQPR 0x0060
These names seem too generic to belong in asm/kvm.h - some application
could use the same names. Please add a KVM_ prefix.
--
error compiling committee.c: too many arguments to function
--
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: [PATCH 03/18] KVM: PPC: Teach MMIO Signedness
On 02/04/2010 05:55 PM, Alexander Graf wrote:
The guest I was trying to get to run uses the LHA and LHAU instructions.
Those instructions basically do a load, but also sign extend the result.
Since we need to fill our registers by hand when doing MMIO, we also need
to sign extend manually.
This patch implements sign extended MMIO and the LHA(U) instructions.
@@ -300,6 +300,25 @@ static void kvmppc_complete_mmio_load(struct kvm_vcpu
*vcpu,
}
}
+ if (vcpu-arch.mmio_sign_extend) {
+ switch (run-mmio.len) {
+#ifdef CONFIG_PPC64
+ case 4:
+ if (gpr 0x8000)
+ gpr |= 0xULL;
+ break;
Wouldn't
gpr = (s64)(gpr 32) 32;
work? Not sure if is guaranteed to sign extend.
--
error compiling committee.c: too many arguments to function
--
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: [PATCH 18/18] KVM: PPC: Implement Paired Single emulation
On 02/04/2010 05:55 PM, Alexander Graf wrote:
The one big thing about the Gekko is paired singles.
Paired singles are an extension to the instruction set, that adds 32 single
precision floating point registers (qprs), some SPRs to modify the behavior
of paired singled operations and instructions to deal with qprs to the
instruction set.
Unfortunately, it also changes semantics of existing operations that affect
single values in FPRs. In most cases they get mirrored to the coresponding
QPR.
Thanks to that we need to emulate all FPU operations and all the new paired
single operations too.
In order to achieve that, we take the guest's instruction, rip out the
parameters, put in our own and execute the very same instruction, but also
fix up the QPR values along the way.
That way we can execute paired single FPU operations without implementing a
soft fpu.
A little frightening. How many instructions are there? Maybe we can
just have an array of all of them followed by a return instruction, so
we don't jit code.
static void call_fpu_inst(u32 inst, u64 *out, u64 *in1, u64 *in2, u64 *in3,
+ u32 *cr, u32 *fpscr)
+{
+ u32 cr_val = 0;
+ u32 *call_stack;
+ u64 inout[5] = { 0, 0, 0, 0, 0 };
+
+ if (fpscr)
+ inout[0] = *fpscr;
+ if (in1)
+ inout[1] = *in1;
+ if (in2)
+ inout[2] = *in2;
+ if (in3)
+ inout[3] = *in3;
+ if (cr)
+ cr_val = *cr;
+
+ dprintk(KERN_INFO FPU Emulator 0x%x ( 0x%llx, 0x%llx, 0x%llx ), inst,
+ inout[1], inout[2], inout[3]);
+
+ call_stack =kvmppc_call_stack[(smp_processor_id() * 2)];
+ call_stack[0] = inst;
+ /* call_stack[1] is INS_BLR */
+
Would be easier on the cache to do this per-cpu?
--
error compiling committee.c: too many arguments to function
--
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: [PATCH 00/18] KVM: PPC: Virtualize Gekko guests
On 02/04/2010 05:55 PM, Alexander Graf wrote: In an effort to get KVM on PPC more useful for other userspace users than Qemu, I figured it'd be a nice idea to implement virtualization of the Gekko CPU. The Gekko is the CPU used in the GameCube. In a slightly more modern fashion it lives on in the Wii today. Using this patch set and a modified version of Dolphin, I was able to virtualize simple GameCube demos on a 970MP system. As always, while getting this to run I stumbled across several broken parts and fixed them as they came up. So expect some bug fixes in this patch set too. This is halfway into emulation rather than virtualization. What does performance look like when running fpu intensive applications? I might have missed it, but I didn't see the KVM_CAP and save/restore support for this. -- error compiling committee.c: too many arguments to function -- 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
