[COMMIT master] device assignment: default requires IOMMU
From: Chris Wright chr...@sous-sol.org
The default mode for device assignment is to rely on an IOMMU for
proper translations and a functioning device in the guest. The current
logic makes this requirement advisory, and simply disables the request
for IOMMU if one is not found on the host. This makes for a confused
user when the device assignment appears to work, but the device in the
guest is not functioning (I've seen about a half-dozen reports with
this failure mode).
Change the logic such that the default requires the IOMMU. Period.
If the host does not have an IOMMU, device assignment will fail.
This is a user visible change, however I think the current situation is
simply broken.
And, of course, disabling the IOMMU requirement using the old:
-pcidevice host=[addr],dma=none
or the newer:
-device pci-assign,host=[addr],iommu=0
will do what it always did (not require an IOMMU, and fail to work
properly).
Cc: Alexander Graf ag...@suse.de
Cc: Dmitri Seletski drj...@gmail.com
Cc: Sheng Yang sh...@linux.intel.com
Signed-off-by: Chris Wright chr...@redhat.com
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/hw/device-assignment.c b/hw/device-assignment.c
index c103cf4..110fd37 100644
--- a/hw/device-assignment.c
+++ b/hw/device-assignment.c
@@ -817,14 +817,15 @@ static int assign_device(AssignedDevice *dev)
assigned_dev_data.devfn = dev-h_devfn;
#ifdef KVM_CAP_IOMMU
-/* We always enable the IOMMU if present
- * (or when not disabled on the command line)
- */
-r = kvm_check_extension(kvm_state, KVM_CAP_IOMMU);
-if (!r)
-dev-use_iommu = 0;
-if (dev-use_iommu)
- assigned_dev_data.flags |= KVM_DEV_ASSIGN_ENABLE_IOMMU;
+/* We always enable the IOMMU unless disabled on the command line */
+if (dev-use_iommu) {
+if (!kvm_check_extension(kvm_state, KVM_CAP_IOMMU)) {
+fprintf(stderr, No IOMMU found. Unable to assign device
\%s\\n,
+dev-dev.qdev.id);
+return -ENODEV;
+}
+assigned_dev_data.flags |= KVM_DEV_ASSIGN_ENABLE_IOMMU;
+}
#else
dev-use_iommu = 0;
#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] remove references of roms/pcbios from configure
From: Marcelo Tosatti mtosa...@redhat.com Signed-off-by: Marcelo Tosatti mtosa...@redhat.com diff --git a/configure b/configure index cbbf9d0..48816e1 100755 --- a/configure +++ b/configure @@ -2781,12 +2781,12 @@ done # for target in $targets # build tree in object directory if source path is different from current one if test $source_path_used = yes ; then DIRS=tests tests/cris slirp audio block net pc-bios/optionrom -DIRS=$DIRS roms/pcbios roms/seabios roms/vgabios +DIRS=$DIRS roms/seabios roms/vgabios FILES=Makefile tests/Makefile FILES=$FILES tests/cris/Makefile tests/cris/.gdbinit FILES=$FILES tests/test-mmap.c FILES=$FILES pc-bios/optionrom/Makefile pc-bios/keymaps pc-bios/video.x -FILES=$FILES roms/pcbios/Makefile roms/seabios/Makefile roms/vgabios/Makefile +FILES=$FILES roms/seabios/Makefile roms/vgabios/Makefile for bios_file in $source_path/pc-bios/*.bin $source_path/pc-bios/*.dtb $source_path/pc-bios/openbios-*; do FILES=$FILES pc-bios/`basename $bios_file` done @@ -2801,7 +2801,7 @@ if test $source_path_used = yes ; then fi # temporary config to build submodules -for rom in seabios vgabios pcbios; do +for rom in seabios vgabios; do config_mak=roms/$rom/config.mak echo # Automatically generated by configure - do not modify $config_mak echo SRC_PATH=$source_path/roms/$rom $config_mak -- 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 build failure with DEVICE_ASSIGNMENT_DEBUG.
From: Kusanagi Kouichi sl...@ac.auone-net.jp
If DEVICE_ASSIGNMENT_DEBUG is defined, build fails.
Signed-off-by: Kusanagi Kouichi sl...@ac.auone-net.jp
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/hw/device-assignment.c b/hw/device-assignment.c
index 110fd37..f4a1e32 100644
--- a/hw/device-assignment.c
+++ b/hw/device-assignment.c
@@ -232,7 +232,7 @@ static void assigned_dev_iomem_map_slow(PCIDevice *pci_dev,
int region_num,
PCIRegion *real_region = r_dev-real_device.regions[region_num];
int m;
-DEBUG(slow map\n);
+DEBUG(%s, slow map\n);
if (region_num == PCI_ROM_SLOT)
m = cpu_register_io_memory(slow_bar_read, NULL, region);
else
@@ -261,7 +261,7 @@ static void assigned_dev_iomem_map(PCIDevice *pci_dev, int
region_num,
int first_map = (region-e_size == 0);
int ret = 0;
-DEBUG(e_phys=%08x r_virt=%p type=%d len=%08x region_num=%d \n,
+DEBUG(e_phys=%08 FMT_PCIBUS r_virt=%p type=%d len=%08 FMT_PCIBUS
region_num=%d \n,
e_phys, region-u.r_virtbase, type, e_size, region_num);
region-e_physbase = e_phys;
@@ -310,7 +310,7 @@ static void assigned_dev_ioport_map(PCIDevice *pci_dev, int
region_num,
region-e_physbase = addr;
region-e_size = size;
-DEBUG(e_phys=0x%x r_baseport=%x type=0x%x len=%d region_num=%d \n,
+DEBUG(e_phys=0x% FMT_PCIBUS r_baseport=%x type=0x%x len=% FMT_PCIBUS
region_num=%d \n,
addr, region-u.r_baseport, type, size, region_num);
if (first_map) {
@@ -1267,7 +1267,7 @@ static void msix_mmio_writel(void *opaque,
unsigned int offset = addr 0xfff;
void *page = adev-msix_table_page;
-DEBUG(write to MSI-X entry table mmio offset 0x%lx, val 0x%lx\n,
+DEBUG(write to MSI-X entry table mmio offset 0x%lx, val 0x%x\n,
addr, val);
memcpy((void *)((char *)page + offset), val, 4);
}
--
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: (72 commits) Drop --whole-archive and static libraries vnc: Fix artifacts in hextile decoding Cocoa: Use optimized drawing for the window Cocoa: Suppress window resize animation Cocoa: Shutdown when window is closed Cocoa: Don't unconditionally show the window Cocoa: Redraw the View asynchronously Cocoa: Mark the View as opaque Cocoa: Fix compilation on Mac OS X v10.4 and earlier Cocoa: Silence type warning Cocoa: Silence warning on Big Endian host Cocoa: Silence warning for cocoa_keycode_to_qemu Cocoa: ppc64 host support sparc64: clear exception_index with -1 value pass env to raise_exception if called outside of op_helper code sparc64: switch to MMU global registers in more MMU related traps target-i386: Fix call im on x86_64 when executing 32-bit code loader: don't call realloc(non_null, 0) when no symbols are present Sparc64: split DPRINTF into CPUIRQ and EBUS versions Sparc64: fix compile with DEBUG_IRQ enabled ... 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] configure: Remote cap from kvm options
From: Avi Kivity a...@redhat.com Signed-off-by: Avi Kivity a...@redhat.com diff --git a/configure b/configure index 08430e8..20c374a 100755 --- a/configure +++ b/configure @@ -540,13 +540,13 @@ for opt do ;; --enable-kvm) kvm=yes ;; - --disable-kvm-cap-pit) kvm_cap_pit=no + --disable-kvm-pit) kvm_cap_pit=no ;; - --enable-kvm-cap-pit) kvm_cap_pit=yes + --enable-kvm-pit) kvm_cap_pit=yes ;; - --disable-kvm-cap-device-assignment) kvm_cap_device_assignment=no + --disable-kvm-device-assignment) kvm_cap_device_assignment=no ;; - --enable-kvm-cap-device-assignment) kvm_cap_device_assignment=yes + --enable-kvm-device-assignment) kvm_cap_device_assignment=yes ;; --enable-profiler) profiler=yes ;; @@ -756,10 +756,10 @@ echo --disable-bluez disable bluez stack connectivity echo --enable-bluez enable bluez stack connectivity echo --disable-kvmdisable KVM acceleration support echo --enable-kvm enable KVM acceleration support -echo --disable-kvm-cap-pitdisable KVM pit support -echo --enable-kvm-cap-pit enable KVM pit support -echo --disable-kvm-cap-device-assignmentdisable KVM device assignment support -echo --enable-kvm-cap-device-assignment enable KVM device assignment support +echo --disable-kvm-pitdisable KVM pit support +echo --enable-kvm-pit enable KVM pit support +echo --disable-kvm-device-assignment disable KVM device assignment support +echo --enable-kvm-device-assignment enable KVM device assignment support echo --disable-nptl disable usermode NPTL support echo --enable-nptlenable usermode NPTL support echo --enable-system enable all system emulation targets -- 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] configure: Correct KVM options in help output
From: Pierre Riteau pierre.rit...@irisa.fr Signed-off-by: Pierre Riteau pierre.rit...@irisa.fr Signed-off-by: Marcelo Tosatti mtosa...@redhat.com diff --git a/configure b/configure index 81c44e8..4254485 100755 --- a/configure +++ b/configure @@ -756,10 +756,10 @@ echo --disable-bluez disable bluez stack connectivity echo --enable-bluez enable bluez stack connectivity echo --disable-kvmdisable KVM acceleration support echo --enable-kvm enable KVM acceleration support -echo --disable-cap-kvm-pitdisable KVM pit support -echo --enable-cap-kvm-pit enable KVM pit support -echo --disable-cap-device-assignmentdisable KVM device assignment support -echo --enable-cap-device-assignment enable KVM device assignment support +echo --disable-kvm-cap-pitdisable KVM pit support +echo --enable-kvm-cap-pit enable KVM pit support +echo --disable-kvm-cap-device-assignmentdisable KVM device assignment support +echo --enable-kvm-cap-device-assignment enable KVM device assignment support echo --disable-nptl disable usermode NPTL support echo --enable-nptlenable usermode NPTL support echo --enable-system enable all system emulation targets -- 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] pci.h: remove duplicate PCI_SLOT/PCI_FUNC defines
From: Marcelo Tosatti mtosa...@redhat.com Signed-off-by: Marcelo Tosatti mtosa...@redhat.com diff --git a/hw/pci.h b/hw/pci.h index bf63912..8c37f14 100644 --- a/hw/pci.h +++ b/hw/pci.h @@ -10,10 +10,6 @@ struct kvm_irq_routing_entry; /* PCI includes legacy ISA access. */ #include isa.h -/* imported from linux/pci.h */ -#define PCI_SLOT(devfn) (((devfn) 3) 0x1f) -#define PCI_FUNC(devfn) ((devfn) 0x07) - /* PCI bus */ #define PCI_DEVFN(slot, func) slot) 0x1f) 3) | ((func) 0x07)) -- 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: (23 commits) target-arm: fix strexd linux-user: fix build with gcc-4.1 linuxboot.bin is a generated file qemu-nbd: fix OpenBSD linker warning e1000: add link to data sheet qemu-io: suppress a warning with gcc 4.0.2 Compile qemu-nbd also on OpenBSD and Solaris USB: Improve usbdevice error messages target-alpha: Initialize fpcr tcg-sparc: Implement brcond2. tcg-sparc: Use TCG_TARGET_REG_BITS in conditional compilation. tcg-sparc: Improve tcg_out_movi for sparc64. tcg-sparc: Fix imm13 check in movi. ARM PBX-A9 memory map tweaks LAN9118 improvements PPC: Make DCR uint32_t PPC64: Fix alternate timebase PPC64: Fix timebase target-alpha: Emit tcg debug_insn_start. linux-user: Add aliases for some Alpha syscalls ... 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: trivial document fixes
From: Wu Fengguang fengguang...@intel.com
Signed-off-by: Wu Fengguang fengguang...@intel.com
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/Documentation/kvm/api.txt b/Documentation/kvm/api.txt
index 2811e45..c6416a3 100644
--- a/Documentation/kvm/api.txt
+++ b/Documentation/kvm/api.txt
@@ -23,12 +23,12 @@ of a virtual machine. The ioctls belong to three classes
Only run vcpu ioctls from the same thread that was used to create the
vcpu.
-2. File descritpors
+2. File descriptors
The kvm API is centered around file descriptors. An initial
open(/dev/kvm) obtains a handle to the kvm subsystem; this handle
can be used to issue system ioctls. A KVM_CREATE_VM ioctl on this
-handle will create a VM file descripror which can be used to issue VM
+handle will create a VM file descriptor which can be used to issue VM
ioctls. A KVM_CREATE_VCPU ioctl on a VM fd will create a virtual cpu
and return a file descriptor pointing to it. Finally, ioctls on a vcpu
fd can be used to control the vcpu, including the important task of
@@ -643,7 +643,7 @@ Type: vm ioctl
Parameters: struct kvm_clock_data (in)
Returns: 0 on success, -1 on error
-Sets the current timestamp of kvmclock to the valued specific in its parameter.
+Sets the current timestamp of kvmclock to the value specified in its parameter.
In conjunction with KVM_GET_CLOCK, it is used to ensure monotonicity on
scenarios
such as migration.
@@ -795,11 +795,11 @@ Unused.
__u64 data_offset; /* relative to kvm_run start */
} io;
-If exit_reason is KVM_EXIT_IO_IN or KVM_EXIT_IO_OUT, then the vcpu has
+If exit_reason is KVM_EXIT_IO, then the vcpu has
executed a port I/O instruction which could not be satisfied by kvm.
data_offset describes where the data is located (KVM_EXIT_IO_OUT) or
where kvm expects application code to place the data for the next
-KVM_RUN invocation (KVM_EXIT_IO_IN). Data format is a patcked array.
+KVM_RUN invocation (KVM_EXIT_IO_IN). Data format is a packed array.
struct {
struct kvm_debug_exit_arch arch;
@@ -815,7 +815,7 @@ Unused.
__u8 is_write;
} mmio;
-If exit_reason is KVM_EXIT_MMIO or KVM_EXIT_IO_OUT, then the vcpu has
+If exit_reason is KVM_EXIT_MMIO, then the vcpu has
executed a memory-mapped I/O instruction which could not be satisfied
by kvm. The 'data' member contains the written data if 'is_write' is
true, and should be filled by application code otherwise.
--
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: modify alias layout in x86s struct kvm_arch
From: Marcelo Tosatti mtosa...@redhat.com
Have a pointer to an allocated region inside x86's kvm_arch.
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 fe4df46..7cdcb3d 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -370,9 +370,13 @@ struct kvm_mem_alias {
gfn_t target_gfn;
};
-struct kvm_arch{
- int naliases;
+struct kvm_mem_aliases {
struct kvm_mem_alias aliases[KVM_ALIAS_SLOTS];
+ int naliases;
+};
+
+struct kvm_arch {
+ struct kvm_mem_aliases *aliases;
unsigned int n_free_mmu_pages;
unsigned int n_requested_mmu_pages;
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 11059cc..414b4f5 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -2228,9 +2228,10 @@ gfn_t unalias_gfn(struct kvm *kvm, gfn_t gfn)
{
int i;
struct kvm_mem_alias *alias;
+ struct kvm_mem_aliases *aliases = kvm-arch.aliases;
- for (i = 0; i kvm-arch.naliases; ++i) {
- alias = kvm-arch.aliases[i];
+ for (i = 0; i aliases-naliases; ++i) {
+ alias = aliases-aliases[i];
if (gfn = alias-base_gfn
gfn alias-base_gfn + alias-npages)
return alias-target_gfn + gfn - alias-base_gfn;
@@ -2248,6 +2249,7 @@ static int kvm_vm_ioctl_set_memory_alias(struct kvm *kvm,
{
int r, n;
struct kvm_mem_alias *p;
+ struct kvm_mem_aliases *aliases;
r = -EINVAL;
/* General sanity checks */
@@ -2267,15 +2269,17 @@ static int kvm_vm_ioctl_set_memory_alias(struct kvm
*kvm,
down_write(kvm-slots_lock);
spin_lock(kvm-mmu_lock);
- p = kvm-arch.aliases[alias-slot];
+ aliases = kvm-arch.aliases;
+
+ p = aliases-aliases[alias-slot];
p-base_gfn = alias-guest_phys_addr PAGE_SHIFT;
p-npages = alias-memory_size PAGE_SHIFT;
p-target_gfn = alias-target_phys_addr PAGE_SHIFT;
for (n = KVM_ALIAS_SLOTS; n 0; --n)
- if (kvm-arch.aliases[n - 1].npages)
+ if (aliases-aliases[n - 1].npages)
break;
- kvm-arch.naliases = n;
+ aliases-naliases = n;
spin_unlock(kvm-mmu_lock);
kvm_mmu_zap_all(kvm);
@@ -5157,6 +5161,12 @@ struct kvm *kvm_arch_create_vm(void)
if (!kvm)
return ERR_PTR(-ENOMEM);
+ kvm-arch.aliases = kzalloc(sizeof(struct kvm_mem_aliases), GFP_KERNEL);
+ if (!kvm-arch.aliases) {
+ kfree(kvm);
+ return ERR_PTR(-ENOMEM);
+ }
+
INIT_LIST_HEAD(kvm-arch.active_mmu_pages);
INIT_LIST_HEAD(kvm-arch.assigned_dev_head);
@@ -5213,6 +5223,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);
+ kfree(kvm-arch.aliases);
kfree(kvm);
}
--
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 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: split kvm_arch_set_memory_region into prepare and commit
From: Marcelo Tosatti mtosa...@redhat.com
Required for SRCU convertion later.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/arch/ia64/kvm/kvm-ia64.c b/arch/ia64/kvm/kvm-ia64.c
index 5fdeec5..4e05dae 100644
--- a/arch/ia64/kvm/kvm-ia64.c
+++ b/arch/ia64/kvm/kvm-ia64.c
@@ -1576,15 +1576,14 @@ out:
return r;
}
-int kvm_arch_set_memory_region(struct kvm *kvm,
- struct kvm_userspace_memory_region *mem,
+int kvm_arch_prepare_memory_region(struct kvm *kvm,
+ struct kvm_memory_slot *memslot,
struct kvm_memory_slot old,
int user_alloc)
{
unsigned long i;
unsigned long pfn;
- int npages = mem-memory_size PAGE_SHIFT;
- struct kvm_memory_slot *memslot = kvm-memslots[mem-slot];
+ int npages = memslot-npages;
unsigned long base_gfn = memslot-base_gfn;
if (base_gfn + npages (KVM_MAX_MEM_SIZE PAGE_SHIFT))
@@ -1608,6 +1607,14 @@ int kvm_arch_set_memory_region(struct kvm *kvm,
return 0;
}
+void kvm_arch_commit_memory_region(struct kvm *kvm,
+ struct kvm_userspace_memory_region *mem,
+ struct kvm_memory_slot old,
+ int user_alloc)
+{
+ return;
+}
+
void kvm_arch_flush_shadow(struct kvm *kvm)
{
kvm_flush_remote_tlbs(kvm);
diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
index f8bcaef..f6bbd45 100644
--- a/arch/s390/kvm/kvm-s390.c
+++ b/arch/s390/kvm/kvm-s390.c
@@ -689,10 +689,10 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
}
/* Section: memory related */
-int kvm_arch_set_memory_region(struct kvm *kvm,
- struct kvm_userspace_memory_region *mem,
- struct kvm_memory_slot old,
- int user_alloc)
+int kvm_arch_prepare_memory_region(struct kvm *kvm,
+ struct kvm_userspace_memory_region *mem,
+ struct kvm_memory_slot old,
+ int user_alloc)
{
int i;
struct kvm_vcpu *vcpu;
@@ -719,14 +719,20 @@ int kvm_arch_set_memory_region(struct kvm *kvm,
if (!user_alloc)
return -EINVAL;
+ return 0;
+}
+
+int kvm_arch_commit_memory_region(struct kvm *kvm,
+ struct kvm_userspace_memory_region *mem,
+ struct kvm_memory_slot old,
+ int user_alloc)
+{
/* request update of sie control block for all available vcpus */
kvm_for_each_vcpu(i, vcpu, kvm) {
if (test_and_set_bit(KVM_REQ_MMU_RELOAD, vcpu-requests))
continue;
kvm_s390_inject_sigp_stop(vcpu, ACTION_RELOADVCPU_ON_STOP);
}
-
- return 0;
}
void kvm_arch_flush_shadow(struct kvm *kvm)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 414b4f5..5a7d8ee 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -5227,13 +5227,12 @@ void kvm_arch_destroy_vm(struct kvm *kvm)
kfree(kvm);
}
-int kvm_arch_set_memory_region(struct kvm *kvm,
- struct kvm_userspace_memory_region *mem,
+int kvm_arch_prepare_memory_region(struct kvm *kvm,
+ struct kvm_memory_slot *memslot,
struct kvm_memory_slot old,
int user_alloc)
{
- int npages = mem-memory_size PAGE_SHIFT;
- struct kvm_memory_slot *memslot = kvm-memslots-memslots[mem-slot];
+ int npages = memslot-npages;
/*To keep backward compatibility with older userspace,
*x86 needs to hanlde !user_alloc case.
@@ -5253,26 +5252,35 @@ int kvm_arch_set_memory_region(struct kvm *kvm,
if (IS_ERR((void *)userspace_addr))
return PTR_ERR((void *)userspace_addr);
- /* set userspace_addr atomically for kvm_hva_to_rmapp */
- spin_lock(kvm-mmu_lock);
memslot-userspace_addr = userspace_addr;
- spin_unlock(kvm-mmu_lock);
- } else {
- if (!old.user_alloc old.rmap) {
- int ret;
-
- down_write(current-mm-mmap_sem);
- ret = do_munmap(current-mm, old.userspace_addr,
- old.npages * PAGE_SIZE);
- up_write(current-mm-mmap_sem);
- if (ret 0)
- printk(KERN_WARNING
- kvm_vm_ioctl_set_memory_region:
- failed to munmap memory\n);
- }
}
}
+
+ return 0;
+}
+
+void kvm_arch_commit_memory_region(struct kvm *kvm,
+
[COMMIT master] KVM: use gfn_to_pfn_memslot in kvm_iommu_map_pages
From: Marcelo Tosatti mtosa...@redhat.com
So its possible to iommu map a memslot before making it visible to
kvm.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index f59233f..7780cce 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -439,8 +439,7 @@ void kvm_free_irq_source_id(struct kvm *kvm, int
irq_source_id);
#define KVM_IOMMU_CACHE_COHERENCY 0x1
#ifdef CONFIG_IOMMU_API
-int kvm_iommu_map_pages(struct kvm *kvm, gfn_t base_gfn,
- unsigned long npages);
+int kvm_iommu_map_pages(struct kvm *kvm, struct kvm_memory_slot *slot);
int kvm_iommu_map_guest(struct kvm *kvm);
int kvm_iommu_unmap_guest(struct kvm *kvm);
int kvm_assign_device(struct kvm *kvm,
diff --git a/virt/kvm/iommu.c b/virt/kvm/iommu.c
index bc697a6..cf567d8 100644
--- a/virt/kvm/iommu.c
+++ b/virt/kvm/iommu.c
@@ -32,10 +32,10 @@ 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);
-int kvm_iommu_map_pages(struct kvm *kvm,
- gfn_t base_gfn, unsigned long npages)
+int kvm_iommu_map_pages(struct kvm *kvm, struct kvm_memory_slot *slot)
{
- gfn_t gfn = base_gfn;
+ gfn_t gfn = slot-base_gfn;
+ unsigned long npages = slot-npages;
pfn_t pfn;
int i, r = 0;
struct iommu_domain *domain = kvm-arch.iommu_domain;
@@ -54,7 +54,7 @@ int kvm_iommu_map_pages(struct kvm *kvm,
if (iommu_iova_to_phys(domain, gfn_to_gpa(gfn)))
continue;
- pfn = gfn_to_pfn(kvm, gfn);
+ pfn = gfn_to_pfn_memslot(kvm, slot, gfn);
r = iommu_map_range(domain,
gfn_to_gpa(gfn),
pfn_to_hpa(pfn),
@@ -69,7 +69,7 @@ int kvm_iommu_map_pages(struct kvm *kvm,
return 0;
unmap_pages:
- kvm_iommu_put_pages(kvm, base_gfn, i);
+ kvm_iommu_put_pages(kvm, slot-base_gfn, i);
return r;
}
@@ -81,8 +81,7 @@ static int kvm_iommu_map_memslots(struct kvm *kvm)
slots = kvm-memslots;
for (i = 0; i slots-nmemslots; i++) {
- r = kvm_iommu_map_pages(kvm, slots-memslots[i].base_gfn,
- slots-memslots[i].npages);
+ r = kvm_iommu_map_pages(kvm, slots-memslots[i]);
if (r)
break;
}
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 27671de..f77d992 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -684,7 +684,7 @@ skip_lpage:
spin_unlock(kvm-mmu_lock);
#ifdef CONFIG_DMAR
/* map the pages in iommu page table */
- r = kvm_iommu_map_pages(kvm, base_gfn, npages);
+ r = kvm_iommu_map_pages(kvm, memslot);
if (r)
goto out;
#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] KVM: use SRCU for dirty log
From: Marcelo Tosatti mtosa...@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 5a7d8ee..030ddef 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -2416,27 +2416,60 @@ static int kvm_vm_ioctl_reinject(struct kvm *kvm,
int kvm_vm_ioctl_get_dirty_log(struct kvm *kvm,
struct kvm_dirty_log *log)
{
- int r;
- int n;
+ int r, n, i;
struct kvm_memory_slot *memslot;
- int is_dirty = 0;
+ unsigned long is_dirty = 0;
+ unsigned long *dirty_bitmap = NULL;
down_write(kvm-slots_lock);
- r = kvm_get_dirty_log(kvm, log, is_dirty);
- if (r)
+ r = -EINVAL;
+ if (log-slot = KVM_MEMORY_SLOTS)
+ goto out;
+
+ memslot = kvm-memslots-memslots[log-slot];
+ r = -ENOENT;
+ if (!memslot-dirty_bitmap)
+ goto out;
+
+ n = ALIGN(memslot-npages, BITS_PER_LONG) / 8;
+
+ r = -ENOMEM;
+ dirty_bitmap = vmalloc(n);
+ if (!dirty_bitmap)
goto out;
+ memset(dirty_bitmap, 0, n);
+
+ for (i = 0; !is_dirty i n/sizeof(long); i++)
+ is_dirty = memslot-dirty_bitmap[i];
/* If nothing is dirty, don't bother messing with page tables. */
if (is_dirty) {
+ struct kvm_memslots *slots, *old_slots;
+
spin_lock(kvm-mmu_lock);
kvm_mmu_slot_remove_write_access(kvm, log-slot);
spin_unlock(kvm-mmu_lock);
- memslot = kvm-memslots-memslots[log-slot];
- n = ALIGN(memslot-npages, BITS_PER_LONG) / 8;
- memset(memslot-dirty_bitmap, 0, n);
+
+ slots = kzalloc(sizeof(struct kvm_memslots), GFP_KERNEL);
+ if (!slots)
+ goto out_free;
+
+ memcpy(slots, kvm-memslots, sizeof(struct kvm_memslots));
+ slots-memslots[log-slot].dirty_bitmap = dirty_bitmap;
+
+ old_slots = kvm-memslots;
+ rcu_assign_pointer(kvm-memslots, slots);
+ synchronize_srcu_expedited(kvm-srcu);
+ dirty_bitmap = old_slots-memslots[log-slot].dirty_bitmap;
+ kfree(old_slots);
}
+
r = 0;
+ if (copy_to_user(log-dirty_bitmap, dirty_bitmap, n))
+ r = -EFAULT;
+out_free:
+ vfree(dirty_bitmap);
out:
up_write(kvm-slots_lock);
return r;
--
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 gfn_to_pfn_memslot
From: Marcelo Tosatti mtosa...@redhat.com
Which takes a memslot pointer instead of using kvm-memslots.
To be used by SRCU convertion later.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 6c61833..f59233f 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -272,6 +272,8 @@ void kvm_set_page_dirty(struct page *page);
void kvm_set_page_accessed(struct page *page);
pfn_t gfn_to_pfn(struct kvm *kvm, gfn_t gfn);
+pfn_t gfn_to_pfn_memslot(struct kvm *kvm,
+struct kvm_memory_slot *slot, gfn_t gfn);
void kvm_release_pfn_dirty(pfn_t);
void kvm_release_pfn_clean(pfn_t pfn);
void kvm_set_pfn_dirty(pfn_t pfn);
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 22bacfc..27671de 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -835,21 +835,14 @@ unsigned long gfn_to_hva(struct kvm *kvm, gfn_t gfn)
}
EXPORT_SYMBOL_GPL(gfn_to_hva);
-pfn_t gfn_to_pfn(struct kvm *kvm, gfn_t gfn)
+static pfn_t hva_to_pfn(struct kvm *kvm, unsigned long addr)
{
struct page *page[1];
- unsigned long addr;
int npages;
pfn_t pfn;
might_sleep();
- addr = gfn_to_hva(kvm, gfn);
- if (kvm_is_error_hva(addr)) {
- get_page(bad_page);
- return page_to_pfn(bad_page);
- }
-
npages = get_user_pages_fast(addr, 1, 1, page);
if (unlikely(npages != 1)) {
@@ -874,8 +867,32 @@ pfn_t gfn_to_pfn(struct kvm *kvm, gfn_t gfn)
return pfn;
}
+pfn_t gfn_to_pfn(struct kvm *kvm, gfn_t gfn)
+{
+ unsigned long addr;
+
+ addr = gfn_to_hva(kvm, gfn);
+ if (kvm_is_error_hva(addr)) {
+ get_page(bad_page);
+ return page_to_pfn(bad_page);
+ }
+
+ return hva_to_pfn(kvm, addr);
+}
EXPORT_SYMBOL_GPL(gfn_to_pfn);
+static unsigned long gfn_to_hva_memslot(struct kvm_memory_slot *slot, gfn_t
gfn)
+{
+ return (slot-userspace_addr + (gfn - slot-base_gfn) * PAGE_SIZE);
+}
+
+pfn_t gfn_to_pfn_memslot(struct kvm *kvm,
+struct kvm_memory_slot *slot, gfn_t gfn)
+{
+ unsigned long addr = gfn_to_hva_memslot(slot, gfn);
+ return hva_to_pfn(kvm, addr);
+}
+
struct page *gfn_to_page(struct kvm *kvm, gfn_t gfn)
{
pfn_t pfn;
--
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: Fill out ftrace exit reason strings
From: Avi Kivity a...@redhat.com
Some exit reasons missed their strings; fill out the table.
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 5fd28f5..455984a 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -3992,29 +3992,49 @@ static u64 vmx_get_mt_mask(struct kvm_vcpu *vcpu, gfn_t
gfn, bool is_mmio)
return ret;
}
+#define _ER(x) { EXIT_REASON_##x, #x }
+
static const struct trace_print_flags vmx_exit_reasons_str[] = {
- { EXIT_REASON_EXCEPTION_NMI, exception },
- { EXIT_REASON_EXTERNAL_INTERRUPT, ext_irq },
- { EXIT_REASON_TRIPLE_FAULT,triple_fault },
- { EXIT_REASON_NMI_WINDOW, nmi_window },
- { EXIT_REASON_IO_INSTRUCTION, io_instruction },
- { EXIT_REASON_CR_ACCESS, cr_access },
- { EXIT_REASON_DR_ACCESS, dr_access },
- { EXIT_REASON_CPUID, cpuid },
- { EXIT_REASON_MSR_READ,rdmsr },
- { EXIT_REASON_MSR_WRITE, wrmsr },
- { EXIT_REASON_PENDING_INTERRUPT, interrupt_window },
- { EXIT_REASON_HLT, halt },
- { EXIT_REASON_INVLPG, invlpg },
- { EXIT_REASON_VMCALL, hypercall },
- { EXIT_REASON_TPR_BELOW_THRESHOLD, tpr_below_thres },
- { EXIT_REASON_APIC_ACCESS, apic_access },
- { EXIT_REASON_WBINVD, wbinvd },
- { EXIT_REASON_TASK_SWITCH, task_switch },
- { EXIT_REASON_EPT_VIOLATION, ept_violation },
+ _ER(EXCEPTION_NMI),
+ _ER(EXTERNAL_INTERRUPT),
+ _ER(TRIPLE_FAULT),
+ _ER(PENDING_INTERRUPT),
+ _ER(NMI_WINDOW),
+ _ER(TASK_SWITCH),
+ _ER(CPUID),
+ _ER(HLT),
+ _ER(INVLPG),
+ _ER(RDPMC),
+ _ER(RDTSC),
+ _ER(VMCALL),
+ _ER(VMCLEAR),
+ _ER(VMLAUNCH),
+ _ER(VMPTRLD),
+ _ER(VMPTRST),
+ _ER(VMREAD),
+ _ER(VMRESUME),
+ _ER(VMWRITE),
+ _ER(VMOFF),
+ _ER(VMON),
+ _ER(CR_ACCESS),
+ _ER(DR_ACCESS),
+ _ER(IO_INSTRUCTION),
+ _ER(MSR_READ),
+ _ER(MSR_WRITE),
+ _ER(MWAIT_INSTRUCTION),
+ _ER(MONITOR_INSTRUCTION),
+ _ER(PAUSE_INSTRUCTION),
+ _ER(MCE_DURING_VMENTRY),
+ _ER(TPR_BELOW_THRESHOLD),
+ _ER(APIC_ACCESS),
+ _ER(EPT_VIOLATION),
+ _ER(EPT_MISCONFIG),
+ _ER(WBINVD),
{ -1, NULL }
};
+#undef _ER
+
static bool vmx_gb_page_enable(void)
{
return false;
--
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-srcu and convert kvm_set_memory_region to SRCU update
From: Marcelo Tosatti mtosa...@redhat.com
Use two steps for memslot deletion: mark the slot invalid (which stops
instantiation of new shadow pages for that slot, but allows destruction),
then instantiate the new empty slot.
Also simplifies kvm_handle_hva locking.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/arch/ia64/kvm/kvm-ia64.c b/arch/ia64/kvm/kvm-ia64.c
index 4e05dae..3526eb6 100644
--- a/arch/ia64/kvm/kvm-ia64.c
+++ b/arch/ia64/kvm/kvm-ia64.c
@@ -1834,6 +1834,7 @@ int kvm_vm_ioctl_get_dirty_log(struct kvm *kvm,
struct kvm_memory_slot *memslot;
int is_dirty = 0;
+ down_write(kvm-slots_lock);
spin_lock(kvm-arch.dirty_log_lock);
r = kvm_ia64_sync_dirty_log(kvm, log);
@@ -1853,6 +1854,7 @@ int kvm_vm_ioctl_get_dirty_log(struct kvm *kvm,
}
r = 0;
out:
+ up_write(kvm-slots_lock);
spin_unlock(kvm-arch.dirty_log_lock);
return r;
}
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index eac8f90..51a2d05 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -29,6 +29,7 @@
#include linux/swap.h
#include linux/hugetlb.h
#include linux/compiler.h
+#include linux/srcu.h
#include asm/page.h
#include asm/cmpxchg.h
@@ -809,21 +810,15 @@ static int kvm_handle_hva(struct kvm *kvm, unsigned long
hva,
{
int i, j;
int retval = 0;
- struct kvm_memslots *slots = kvm-memslots;
+ struct kvm_memslots *slots;
+
+ slots = rcu_dereference(kvm-memslots);
- /*
-* If mmap_sem isn't taken, we can look the memslots with only
-* the mmu_lock by skipping over the slots with userspace_addr == 0.
-*/
for (i = 0; i slots-nmemslots; i++) {
struct kvm_memory_slot *memslot = slots-memslots[i];
unsigned long start = memslot-userspace_addr;
unsigned long end;
- /* mmu_lock protects userspace_addr */
- if (!start)
- continue;
-
end = start + (memslot-npages PAGE_SHIFT);
if (hva = start hva end) {
gfn_t gfn_offset = (hva - start) PAGE_SHIFT;
@@ -1619,7 +1614,7 @@ static void mmu_unshadow(struct kvm *kvm, gfn_t gfn)
static void page_header_update_slot(struct kvm *kvm, void *pte, gfn_t gfn)
{
- int slot = memslot_id(kvm, gfn_to_memslot(kvm, gfn));
+ int slot = memslot_id(kvm, gfn);
struct kvm_mmu_page *sp = page_header(__pa(pte));
__set_bit(slot, sp-slot_bitmap);
@@ -3023,9 +3018,11 @@ unsigned int kvm_mmu_calculate_mmu_pages(struct kvm *kvm)
int i;
unsigned int nr_mmu_pages;
unsigned int nr_pages = 0;
+ struct kvm_memslots *slots;
- for (i = 0; i kvm-memslots-nmemslots; i++)
- nr_pages += kvm-memslots-memslots[i].npages;
+ slots = rcu_dereference(kvm-memslots);
+ for (i = 0; i slots-nmemslots; i++)
+ nr_pages += slots-memslots[i].npages;
nr_mmu_pages = nr_pages * KVM_PERMILLE_MMU_PAGES / 1000;
nr_mmu_pages = max(nr_mmu_pages,
@@ -3295,10 +3292,12 @@ static void audit_mappings(struct kvm_vcpu *vcpu)
static int count_rmaps(struct kvm_vcpu *vcpu)
{
int nmaps = 0;
- int i, j, k;
+ int i, j, k, idx;
+ idx = srcu_read_lock(kvm-srcu);
+ slots = rcu_dereference(kvm-memslots);
for (i = 0; i KVM_MEMORY_SLOTS; ++i) {
- struct kvm_memory_slot *m = vcpu-kvm-memslots-memslots[i];
+ struct kvm_memory_slot *m = slots-memslots[i];
struct kvm_rmap_desc *d;
for (j = 0; j m-npages; ++j) {
@@ -3321,6 +3320,7 @@ static int count_rmaps(struct kvm_vcpu *vcpu)
}
}
}
+ srcu_read_unlock(kvm-srcu, idx);
return nmaps;
}
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 489939a..3dd849c 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -1503,7 +1503,11 @@ static void enter_pmode(struct kvm_vcpu *vcpu)
static gva_t rmode_tss_base(struct kvm *kvm)
{
if (!kvm-arch.tss_addr) {
- gfn_t base_gfn = kvm-memslots-memslots[0].base_gfn +
+ struct kvm_memslots *slots;
+ gfn_t base_gfn;
+
+ slots = rcu_dereference(kvm-memslots);
+ base_gfn = kvm-memslots-memslots[0].base_gfn +
kvm-memslots-memslots[0].npages - 3;
return base_gfn PAGE_SHIFT;
}
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index a24de0b..f2feef6 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -103,7 +103,7 @@ struct kvm_userspace_memory_region {
/* for kvm_memory_region::flags */
#define KVM_MEM_LOG_DIRTY_PAGES 1UL
-
+#define KVM_MEMSLOT_INVALID (1UL 1)
/* for KVM_IRQ_LINE */
struct kvm_irq_level {
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index
[COMMIT master] KVM: switch vcpu context to use SRCU
From: Marcelo Tosatti mtosa...@redhat.com
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/arch/ia64/kvm/kvm-ia64.c b/arch/ia64/kvm/kvm-ia64.c
index f67a541..28b44cd 100644
--- a/arch/ia64/kvm/kvm-ia64.c
+++ b/arch/ia64/kvm/kvm-ia64.c
@@ -636,12 +636,9 @@ static void kvm_vcpu_post_transition(struct kvm_vcpu *vcpu)
static int __vcpu_run(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run)
{
union context *host_ctx, *guest_ctx;
- int r;
+ int r, idx;
- /*
-* down_read() may sleep and return with interrupts enabled
-*/
- down_read(vcpu-kvm-slots_lock);
+ idx = srcu_read_lock(vcpu-kvm-srcu);
again:
if (signal_pending(current)) {
@@ -663,7 +660,7 @@ again:
if (r 0)
goto vcpu_run_fail;
- up_read(vcpu-kvm-slots_lock);
+ srcu_read_unlock(vcpu-kvm-srcu, idx);
kvm_guest_enter();
/*
@@ -687,7 +684,7 @@ again:
kvm_guest_exit();
preempt_enable();
- down_read(vcpu-kvm-slots_lock);
+ idx = srcu_read_lock(vcpu-kvm-srcu);
r = kvm_handle_exit(kvm_run, vcpu);
@@ -697,10 +694,10 @@ again:
}
out:
- up_read(vcpu-kvm-slots_lock);
+ srcu_read_unlock(vcpu-kvm-srcu, idx);
if (r 0) {
kvm_resched(vcpu);
- down_read(vcpu-kvm-slots_lock);
+ idx = srcu_read_lock(vcpu-kvm-srcu);
goto again;
}
diff --git a/arch/s390/kvm/kvm-s390.h b/arch/s390/kvm/kvm-s390.h
index 06cce82..46777ff 100644
--- a/arch/s390/kvm/kvm-s390.h
+++ b/arch/s390/kvm/kvm-s390.h
@@ -67,10 +67,14 @@ static inline long kvm_s390_vcpu_get_memsize(struct
kvm_vcpu *vcpu)
static inline void kvm_s390_vcpu_set_mem(struct kvm_vcpu *vcpu)
{
+ int idx;
struct kvm_memory_slot *mem;
+ struct kvm_memory_slots *memslots;
- down_read(vcpu-kvm-slots_lock);
- mem = vcpu-kvm-memslots[0];
+ idx = srcu_read_lock(vcpu-kvm-srcu);
+ memslots = rcu_dereference(vcpu-kvm-memslots);
+
+ mem = memslots-memslots[0];
vcpu-arch.sie_block-gmsor = mem-userspace_addr;
vcpu-arch.sie_block-gmslm =
@@ -78,7 +82,7 @@ static inline void kvm_s390_vcpu_set_mem(struct kvm_vcpu
*vcpu)
(mem-npages PAGE_SHIFT) +
VIRTIODESCSPACE - 1ul;
- up_read(vcpu-kvm-slots_lock);
+ srcu_read_unlock(vcpu-kvm-srcu, idx);
}
/* implemented in priv.c */
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 51a2d05..ed4f1a3 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -2935,10 +2935,9 @@ static int mmu_shrink(int nr_to_scan, gfp_t gfp_mask)
spin_lock(kvm_lock);
list_for_each_entry(kvm, vm_list, vm_list) {
- int npages;
+ int npages, idx;
- if (!down_read_trylock(kvm-slots_lock))
- continue;
+ idx = srcu_read_lock(kvm-srcu);
spin_lock(kvm-mmu_lock);
npages = kvm-arch.n_alloc_mmu_pages -
kvm-arch.n_free_mmu_pages;
@@ -2951,7 +2950,7 @@ static int mmu_shrink(int nr_to_scan, gfp_t gfp_mask)
nr_to_scan--;
spin_unlock(kvm-mmu_lock);
- up_read(kvm-slots_lock);
+ srcu_read_unlock(kvm-srcu, idx);
}
if (kvm_freed)
list_move_tail(kvm_freed-vm_list, vm_list);
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 3dd849c..3fb4434 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2477,10 +2477,10 @@ static int vmx_vcpu_reset(struct kvm_vcpu *vcpu)
{
struct vcpu_vmx *vmx = to_vmx(vcpu);
u64 msr;
- int ret;
+ int ret, idx;
vcpu-arch.regs_avail = ~((1 VCPU_REGS_RIP) | (1 VCPU_REGS_RSP));
- down_read(vcpu-kvm-slots_lock);
+ idx = srcu_read_lock(vcpu-kvm-srcu);
if (!init_rmode(vmx-vcpu.kvm)) {
ret = -ENOMEM;
goto out;
@@ -2588,7 +2588,7 @@ static int vmx_vcpu_reset(struct kvm_vcpu *vcpu)
vmx-emulation_required = 0;
out:
- up_read(vcpu-kvm-slots_lock);
+ srcu_read_unlock(vcpu-kvm-srcu, idx);
return ret;
}
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index f263c8f..92e4d81 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1307,15 +1307,15 @@ static int __msr_io(struct kvm_vcpu *vcpu, struct
kvm_msrs *msrs,
int (*do_msr)(struct kvm_vcpu *vcpu,
unsigned index, u64 *data))
{
- int i;
+ int i, idx;
vcpu_load(vcpu);
- down_read(vcpu-kvm-slots_lock);
+ idx = srcu_read_lock(vcpu-kvm-srcu);
for (i = 0; i msrs-nmsrs; ++i)
if (do_msr(vcpu, entries[i].index, entries[i].data))
break;
- up_read(vcpu-kvm-slots_lock);
+ srcu_read_unlock(vcpu-kvm-srcu, idx);
vcpu_put(vcpu);
@@ -3901,14
[COMMIT master] KVM: Fix race between APIC TMR and IRR
From: Avi Kivity a...@redhat.com
When we queue an interrupt to the local apic, we set the IRR before the TMR.
The vcpu can pick up the IRR and inject the interrupt before setting the TMR,
and perhaps even EOI it, causing incorrect behaviour.
The race is really insignificant since it can only occur on the first
interrupt (usually following interrupts will not change TMR), but it's better
closed than open.
Fixed by reordering setting the TMR vs IRR.
Signed-off-by: Avi Kivity a...@redhat.com
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 3063a0c..ba8c045 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -373,6 +373,12 @@ static int __apic_accept_irq(struct kvm_lapic *apic, int
delivery_mode,
if (unlikely(!apic_enabled(apic)))
break;
+ if (trig_mode) {
+ apic_debug(level trig mode for vector %d, vector);
+ apic_set_vector(vector, apic-regs + APIC_TMR);
+ } else
+ apic_clear_vector(vector, apic-regs + APIC_TMR);
+
result = !apic_test_and_set_irr(vector, apic);
trace_kvm_apic_accept_irq(vcpu-vcpu_id, delivery_mode,
trig_mode, vector, !result);
@@ -383,11 +389,6 @@ static int __apic_accept_irq(struct kvm_lapic *apic, int
delivery_mode,
break;
}
- if (trig_mode) {
- apic_debug(level trig mode for vector %d, vector);
- apic_set_vector(vector, apic-regs + APIC_TMR);
- } else
- apic_clear_vector(vector, apic-regs + APIC_TMR);
kvm_vcpu_kick(vcpu);
break;
--
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: Adjust memory slot accesses to SRCU changes
From: Alexander Graf ag...@suse.de
Commit 18657960237322b8f6ba84938d27524634212aaf apparently broke PPC Book3S
compilation. This patch fixes it.
Signed-off-by: Alexander Graf ag...@suse.de
Reported-by: Giuseppe Falsetti giuse...@czero.it
CC: Marcelo Tosatti mtosa...@redhat.com
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index 803505d..492dcc1 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -857,7 +857,7 @@ int kvm_vm_ioctl_get_dirty_log(struct kvm *kvm,
int is_dirty = 0;
int r, n;
- down_write(kvm-slots_lock);
+ mutex_lock(kvm-slots_lock);
r = kvm_get_dirty_log(kvm, log, is_dirty);
if (r)
@@ -865,7 +865,7 @@ int kvm_vm_ioctl_get_dirty_log(struct kvm *kvm,
/* If nothing is dirty, don't bother messing with page tables. */
if (is_dirty) {
- memslot = kvm-memslots[log-slot];
+ memslot = kvm-memslots-memslots[log-slot];
ga = memslot-base_gfn PAGE_SHIFT;
ga_end = ga + (memslot-npages PAGE_SHIFT);
@@ -879,7 +879,7 @@ int kvm_vm_ioctl_get_dirty_log(struct kvm *kvm,
r = 0;
out:
- up_write(kvm-slots_lock);
+ mutex_unlock(kvm-slots_lock);
return r;
}
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index f06cf93..5ba1865 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -165,14 +165,23 @@ long kvm_arch_dev_ioctl(struct file *filp,
return -EINVAL;
}
-int kvm_arch_set_memory_region(struct kvm *kvm,
- struct kvm_userspace_memory_region *mem,
- struct kvm_memory_slot old,
- int user_alloc)
+int kvm_arch_prepare_memory_region(struct kvm *kvm,
+ struct kvm_memory_slot *memslot,
+ struct kvm_memory_slot old,
+ int user_alloc)
{
return 0;
}
+void kvm_arch_commit_memory_region(struct kvm *kvm,
+ struct kvm_userspace_memory_region *mem,
+ struct kvm_memory_slot old,
+ int user_alloc)
+{
+ return;
+}
+
+
void kvm_arch_flush_shadow(struct kvm *kvm)
{
}
--
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: switch kvm_set_memory_alias to SRCU update
From: Marcelo Tosatti mtosa...@redhat.com
Using a similar two-step procedure as for memslots.
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 7cdcb3d..6c8c7c5 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -368,8 +368,12 @@ struct kvm_mem_alias {
gfn_t base_gfn;
unsigned long npages;
gfn_t target_gfn;
+#define KVM_ALIAS_INVALID 1UL
+ unsigned long flags;
};
+#define KVM_ARCH_HAS_UNALIAS_INSTANTIATION
+
struct kvm_mem_aliases {
struct kvm_mem_alias aliases[KVM_ALIAS_SLOTS];
int naliases;
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 030ddef..4d3ee75 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -38,6 +38,7 @@
#include linux/intel-iommu.h
#include linux/cpufreq.h
#include linux/user-return-notifier.h
+#include linux/srcu.h
#include trace/events/kvm.h
#undef TRACE_INCLUDE_FILE
#define CREATE_TRACE_POINTS
@@ -2224,11 +2225,32 @@ static int kvm_vm_ioctl_get_nr_mmu_pages(struct kvm
*kvm)
return kvm-arch.n_alloc_mmu_pages;
}
+gfn_t unalias_gfn_instantiation(struct kvm *kvm, gfn_t gfn)
+{
+ int i;
+ struct kvm_mem_alias *alias;
+ struct kvm_mem_aliases *aliases;
+
+ aliases = rcu_dereference(kvm-arch.aliases);
+
+ for (i = 0; i aliases-naliases; ++i) {
+ alias = aliases-aliases[i];
+ if (alias-flags KVM_ALIAS_INVALID)
+ continue;
+ if (gfn = alias-base_gfn
+gfn alias-base_gfn + alias-npages)
+ return alias-target_gfn + gfn - alias-base_gfn;
+ }
+ return gfn;
+}
+
gfn_t unalias_gfn(struct kvm *kvm, gfn_t gfn)
{
int i;
struct kvm_mem_alias *alias;
- struct kvm_mem_aliases *aliases = kvm-arch.aliases;
+ struct kvm_mem_aliases *aliases;
+
+ aliases = rcu_dereference(kvm-arch.aliases);
for (i = 0; i aliases-naliases; ++i) {
alias = aliases-aliases[i];
@@ -2249,7 +2271,7 @@ static int kvm_vm_ioctl_set_memory_alias(struct kvm *kvm,
{
int r, n;
struct kvm_mem_alias *p;
- struct kvm_mem_aliases *aliases;
+ struct kvm_mem_aliases *aliases, *old_aliases;
r = -EINVAL;
/* General sanity checks */
@@ -2266,28 +2288,48 @@ static int kvm_vm_ioctl_set_memory_alias(struct kvm
*kvm,
alias-target_phys_addr)
goto out;
+ r = -ENOMEM;
+ aliases = kzalloc(sizeof(struct kvm_mem_aliases), GFP_KERNEL);
+ if (!aliases)
+ goto out;
+
down_write(kvm-slots_lock);
- spin_lock(kvm-mmu_lock);
- aliases = kvm-arch.aliases;
+ /* invalidate any gfn reference in case of deletion/shrinking */
+ memcpy(aliases, kvm-arch.aliases, sizeof(struct kvm_mem_aliases));
+ aliases-aliases[alias-slot].flags |= KVM_ALIAS_INVALID;
+ old_aliases = kvm-arch.aliases;
+ rcu_assign_pointer(kvm-arch.aliases, aliases);
+ synchronize_srcu_expedited(kvm-srcu);
+ kvm_mmu_zap_all(kvm);
+ kfree(old_aliases);
+
+ r = -ENOMEM;
+ aliases = kzalloc(sizeof(struct kvm_mem_aliases), GFP_KERNEL);
+ if (!aliases)
+ goto out_unlock;
+
+ memcpy(aliases, kvm-arch.aliases, sizeof(struct kvm_mem_aliases));
p = aliases-aliases[alias-slot];
p-base_gfn = alias-guest_phys_addr PAGE_SHIFT;
p-npages = alias-memory_size PAGE_SHIFT;
p-target_gfn = alias-target_phys_addr PAGE_SHIFT;
+ p-flags = ~(KVM_ALIAS_INVALID);
for (n = KVM_ALIAS_SLOTS; n 0; --n)
if (aliases-aliases[n - 1].npages)
break;
aliases-naliases = n;
- spin_unlock(kvm-mmu_lock);
- kvm_mmu_zap_all(kvm);
+ old_aliases = kvm-arch.aliases;
+ rcu_assign_pointer(kvm-arch.aliases, aliases);
+ synchronize_srcu_expedited(kvm-srcu);
+ kfree(old_aliases);
+ r = 0;
+out_unlock:
up_write(kvm-slots_lock);
-
- return 0;
-
out:
return r;
}
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index b8e21b6..06e3286 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -265,6 +265,8 @@ void kvm_arch_commit_memory_region(struct kvm *kvm,
void kvm_disable_largepages(void);
void kvm_arch_flush_shadow(struct kvm *kvm);
gfn_t unalias_gfn(struct kvm *kvm, gfn_t gfn);
+gfn_t unalias_gfn_instantiation(struct kvm *kvm, gfn_t gfn);
+
struct page *gfn_to_page(struct kvm *kvm, gfn_t gfn);
unsigned long gfn_to_hva(struct kvm *kvm, gfn_t gfn);
void kvm_release_page_clean(struct page *page);
@@ -538,6 +540,10 @@ static inline int mmu_notifier_retry(struct kvm_vcpu
*vcpu, unsigned long mmu_se
}
#endif
+#ifndef KVM_ARCH_HAS_UNALIAS_INSTANTIATION
+#define unalias_gfn_instantiation unalias_gfn
+#endif
+
#ifdef
[COMMIT master] KVM: Bump maximum vcpu count to 64
From: Avi Kivity a...@redhat.com With slots_lock converted to rcu, the entire kvm hotpath on modern processors (with npt or ept) now scales beautifully. Increase the maximum vcpu count to 64 to reflect this. 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 6c8c7c5..741b897 100644 --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -25,7 +25,7 @@ #include asm/mtrr.h #include asm/msr-index.h -#define KVM_MAX_VCPUS 16 +#define KVM_MAX_VCPUS 64 #define KVM_MEMORY_SLOTS 32 /* memory slots that does not exposed to userspace */ #define KVM_PRIVATE_MEM_SLOTS 4 -- 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: Moving PT_*_LEVEL to mmu.h
From: Sheng Yang sh...@linux.intel.com We can use them in x86.c and vmx.c now... Signed-off-by: Sheng Yang sh...@linux.intel.com Signed-off-by: Marcelo Tosatti mtosa...@redhat.com diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c index ed4f1a3..ed40755 100644 --- a/arch/x86/kvm/mmu.c +++ b/arch/x86/kvm/mmu.c @@ -143,10 +143,6 @@ module_param(oos_shadow, bool, 0644); #define PFERR_RSVD_MASK (1U 3) #define PFERR_FETCH_MASK (1U 4) -#define PT_PDPE_LEVEL 3 -#define PT_DIRECTORY_LEVEL 2 -#define PT_PAGE_TABLE_LEVEL 1 - #define RMAP_EXT 4 #define ACC_EXEC_MASK1 diff --git a/arch/x86/kvm/mmu.h b/arch/x86/kvm/mmu.h index 4567d80..ff58342 100644 --- a/arch/x86/kvm/mmu.h +++ b/arch/x86/kvm/mmu.h @@ -38,6 +38,10 @@ #define PT32_ROOT_LEVEL 2 #define PT32E_ROOT_LEVEL 3 +#define PT_PDPE_LEVEL 3 +#define PT_DIRECTORY_LEVEL 2 +#define PT_PAGE_TABLE_LEVEL 1 + int kvm_mmu_get_spte_hierarchy(struct kvm_vcpu *vcpu, u64 addr, u64 sptes[4]); static inline void kvm_mmu_free_some_pages(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: PPC: Fix typo in rebolting code
From: Alexander Graf ag...@suse.de When we're loading bolted entries into the SLB again, we're checking if an entry is in use and only slbmte it when it is. Unfortunately, the check always goes to the skip label of the first entry, resulting in an endless loop when it actually gets triggered. Signed-off-by: Alexander Graf ag...@suse.de Signed-off-by: Marcelo Tosatti mtosa...@redhat.com diff --git a/arch/powerpc/kvm/book3s_64_slb.S b/arch/powerpc/kvm/book3s_64_slb.S index ecd237a..8e44788 100644 --- a/arch/powerpc/kvm/book3s_64_slb.S +++ b/arch/powerpc/kvm/book3s_64_slb.S @@ -31,7 +31,7 @@ #define REBOLT_SLB_ENTRY(num) \ ld r10, SHADOW_SLB_ESID(num)(r11); \ cmpdi r10, 0; \ - beq slb_exit_skip_1; \ + beq slb_exit_skip_ ## num; \ orisr10, r10, slb_esi...@h; \ ld r9, SHADOW_SLB_VSID(num)(r11); \ slbmte r9, r10; \ -- 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 host_mapping_level()
From: Sheng Yang sh...@linux.intel.com
When found a error hva, should not return PAGE_SIZE but the level...
Also clean up the coding style of the following loop.
Cc: sta...@kernel.org
Signed-off-by: Sheng Yang sh...@linux.intel.com
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index ed40755..12ccf14 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -474,7 +474,7 @@ static int host_mapping_level(struct kvm *kvm, gfn_t gfn)
addr = gfn_to_hva(kvm, gfn);
if (kvm_is_error_hva(addr))
- return page_size;
+ return PT_PAGE_TABLE_LEVEL;
down_read(current-mm-mmap_sem);
vma = find_vma(current-mm, addr);
@@ -512,11 +512,9 @@ static int mapping_level(struct kvm_vcpu *vcpu, gfn_t
large_gfn)
if (host_level == PT_PAGE_TABLE_LEVEL)
return host_level;
- for (level = PT_DIRECTORY_LEVEL; level = host_level; ++level) {
-
+ for (level = PT_DIRECTORY_LEVEL; level = host_level; ++level)
if (has_wrprotected_page(vcpu-kvm, large_gfn, level))
break;
- }
return level - 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: PPC: Add helpers for CR, XER
From: Alexander Graf ag...@suse.de
We now have helpers for the GPRs, so let's also add some for CR and XER.
Having them in the PACA simplifies code a lot, as we don't need to care
about where to store CC or not to overflow any integers.
Signed-off-by: Alexander Graf ag...@suse.de
Signed-off-by: Avi Kivity a...@redhat.com
diff --git a/arch/powerpc/include/asm/kvm_ppc.h
b/arch/powerpc/include/asm/kvm_ppc.h
index ba01b9c..d60b2f0 100644
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -108,6 +108,26 @@ static inline ulong kvmppc_get_gpr(struct kvm_vcpu *vcpu,
int num)
return vcpu-arch.gpr[num];
}
+static inline void kvmppc_set_cr(struct kvm_vcpu *vcpu, u32 val)
+{
+ vcpu-arch.cr = val;
+}
+
+static inline u32 kvmppc_get_cr(struct kvm_vcpu *vcpu)
+{
+ return vcpu-arch.cr;
+}
+
+static inline void kvmppc_set_xer(struct kvm_vcpu *vcpu, u32 val)
+{
+ vcpu-arch.xer = val;
+}
+
+static inline u32 kvmppc_get_xer(struct kvm_vcpu *vcpu)
+{
+ return vcpu-arch.xer;
+}
+
#else
static inline void kvmppc_set_gpr(struct kvm_vcpu *vcpu, int num, ulong val)
@@ -120,6 +140,26 @@ static inline ulong kvmppc_get_gpr(struct kvm_vcpu *vcpu,
int num)
return vcpu-arch.gpr[num];
}
+static inline void kvmppc_set_cr(struct kvm_vcpu *vcpu, u32 val)
+{
+ vcpu-arch.cr = val;
+}
+
+static inline u32 kvmppc_get_cr(struct kvm_vcpu *vcpu)
+{
+ return vcpu-arch.cr;
+}
+
+static inline void kvmppc_set_xer(struct kvm_vcpu *vcpu, u32 val)
+{
+ vcpu-arch.xer = val;
+}
+
+static inline u32 kvmppc_get_xer(struct kvm_vcpu *vcpu)
+{
+ return vcpu-arch.xer;
+}
+
#endif
#endif /* __POWERPC_KVM_PPC_H__ */
diff --git a/arch/powerpc/kvm/44x_tlb.c b/arch/powerpc/kvm/44x_tlb.c
index 8b37736..2570fcc 100644
--- a/arch/powerpc/kvm/44x_tlb.c
+++ b/arch/powerpc/kvm/44x_tlb.c
@@ -506,10 +506,12 @@ int kvmppc_44x_emul_tlbsx(struct kvm_vcpu *vcpu, u8 rt,
u8 ra, u8 rb, u8 rc)
gtlb_index = kvmppc_44x_tlb_index(vcpu, ea, pid, as);
if (rc) {
+ u32 cr = kvmppc_get_cr(vcpu);
+
if (gtlb_index 0)
- vcpu-arch.cr = ~0x2000;
+ kvmppc_set_cr(vcpu, cr ~0x2000);
else
- vcpu-arch.cr |= 0x2000;
+ kvmppc_set_cr(vcpu, cr | 0x2000);
}
kvmppc_set_gpr(vcpu, rt, gtlb_index);
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index 574b24f..09ba8db 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -717,10 +717,10 @@ int kvm_arch_vcpu_ioctl_get_regs(struct kvm_vcpu *vcpu,
struct kvm_regs *regs)
int i;
regs-pc = vcpu-arch.pc;
- regs-cr = vcpu-arch.cr;
+ regs-cr = kvmppc_get_cr(vcpu);
regs-ctr = vcpu-arch.ctr;
regs-lr = vcpu-arch.lr;
- regs-xer = vcpu-arch.xer;
+ regs-xer = kvmppc_get_xer(vcpu);
regs-msr = vcpu-arch.msr;
regs-srr0 = vcpu-arch.srr0;
regs-srr1 = vcpu-arch.srr1;
@@ -744,10 +744,10 @@ int kvm_arch_vcpu_ioctl_set_regs(struct kvm_vcpu *vcpu,
struct kvm_regs *regs)
int i;
vcpu-arch.pc = regs-pc;
- vcpu-arch.cr = regs-cr;
+ kvmppc_set_cr(vcpu, regs-cr);
vcpu-arch.ctr = regs-ctr;
vcpu-arch.lr = regs-lr;
- vcpu-arch.xer = regs-xer;
+ kvmppc_set_xer(vcpu, regs-xer);
kvmppc_set_msr(vcpu, regs-msr);
vcpu-arch.srr0 = regs-srr0;
vcpu-arch.srr1 = regs-srr1;
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index 49af80e..338baf9 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -449,10 +449,10 @@ int kvm_arch_vcpu_ioctl_get_regs(struct kvm_vcpu *vcpu,
struct kvm_regs *regs)
int i;
regs-pc = vcpu-arch.pc;
- regs-cr = vcpu-arch.cr;
+ regs-cr = kvmppc_get_cr(vcpu);
regs-ctr = vcpu-arch.ctr;
regs-lr = vcpu-arch.lr;
- regs-xer = vcpu-arch.xer;
+ regs-xer = kvmppc_get_xer(vcpu);
regs-msr = vcpu-arch.msr;
regs-srr0 = vcpu-arch.srr0;
regs-srr1 = vcpu-arch.srr1;
@@ -476,10 +476,10 @@ int kvm_arch_vcpu_ioctl_set_regs(struct kvm_vcpu *vcpu,
struct kvm_regs *regs)
int i;
vcpu-arch.pc = regs-pc;
- vcpu-arch.cr = regs-cr;
+ kvmppc_set_cr(vcpu, regs-cr);
vcpu-arch.ctr = regs-ctr;
vcpu-arch.lr = regs-lr;
- vcpu-arch.xer = regs-xer;
+ kvmppc_set_xer(vcpu, regs-xer);
kvmppc_set_msr(vcpu, regs-msr);
vcpu-arch.srr0 = regs-srr0;
vcpu-arch.srr1 = regs-srr1;
--
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 the explanation of write_emulated
From: Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp
The explanation of write_emulated is confused with
that of read_emulated. This patch fix it.
Signed-off-by: Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/arch/x86/include/asm/kvm_emulate.h
b/arch/x86/include/asm/kvm_emulate.h
index 7c18e12..9b697c2 100644
--- a/arch/x86/include/asm/kvm_emulate.h
+++ b/arch/x86/include/asm/kvm_emulate.h
@@ -74,7 +74,7 @@ struct x86_emulate_ops {
struct kvm_vcpu *vcpu);
/*
-* write_emulated: Read bytes from emulated/special memory area.
+* write_emulated: Write bytes to emulated/special memory area.
* @addr: [IN ] Linear address to which to write.
* @val: [IN ] Value to write to memory (low-order bytes used as
*required).
--
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: Implement 'skip instruction' mode
From: Alexander Graf ag...@suse.de To fetch the last instruction we were interrupted on, we enable DR in early exit code, where we are still in a very transitional phase between guest and host state. Most of the time this seemed to work, but another CPU can easily flush our TLB and HTAB which makes us go in the Linux page fault handler which totally breaks because we still use the guest's SLB entries. To work around that, let's introduce a second KVM guest mode that defines that whenever we get a trap, we don't call the Linux handler or go into the KVM exit code, but just jump over the faulting instruction. That way a potentially bad lwz doesn't trigger any faults and we can later on interpret the invalid instruction we fetched as fetch didn't work. Signed-off-by: Alexander Graf ag...@suse.de Signed-off-by: Avi Kivity a...@redhat.com diff --git a/arch/powerpc/include/asm/kvm_asm.h b/arch/powerpc/include/asm/kvm_asm.h index af2abe7..aadf2dd 100644 --- a/arch/powerpc/include/asm/kvm_asm.h +++ b/arch/powerpc/include/asm/kvm_asm.h @@ -97,4 +97,10 @@ #define RESUME_HOST RESUME_FLAG_HOST #define RESUME_HOST_NV (RESUME_FLAG_HOST|RESUME_FLAG_NV) +#define KVM_GUEST_MODE_NONE0 +#define KVM_GUEST_MODE_GUEST 1 +#define KVM_GUEST_MODE_SKIP2 + +#define KVM_INST_FETCH_FAILED -1 + #endif /* __POWERPC_KVM_ASM_H__ */ diff --git a/arch/powerpc/kvm/book3s_64_rmhandlers.S b/arch/powerpc/kvm/book3s_64_rmhandlers.S index cd9f0b6..9ad1c26 100644 --- a/arch/powerpc/kvm/book3s_64_rmhandlers.S +++ b/arch/powerpc/kvm/book3s_64_rmhandlers.S @@ -49,7 +49,7 @@ kvmppc_trampoline_\intno: mfcrr12 stw r12, PACA_KVM_SCRATCH1(r13) lbz r12, PACA_KVM_IN_GUEST(r13) - cmpwi r12, 0 + cmpwi r12, KVM_GUEST_MODE_NONE bne ..kvmppc_handler_hasmagic_\intno /* No KVM guest? Then jump back to the Linux handler! */ lwz r12, PACA_KVM_SCRATCH1(r13) @@ -60,6 +60,11 @@ kvmppc_trampoline_\intno: /* Now we know we're handling a KVM guest */ ..kvmppc_handler_hasmagic_\intno: + + /* Should we just skip the faulting instruction? */ + cmpwi r12, KVM_GUEST_MODE_SKIP + beq kvmppc_handler_skip_ins + /* Let's store which interrupt we're handling */ li r12, \intno @@ -86,6 +91,38 @@ INTERRUPT_TRAMPOLINE BOOK3S_INTERRUPT_ALTIVEC INTERRUPT_TRAMPOLINE BOOK3S_INTERRUPT_VSX /* + * Bring us back to the faulting code, but skip the + * faulting instruction. + * + * This is a generic exit path from the interrupt + * trampolines above. + * + * Input Registers: + * + * R12 = free + * R13 = PACA + * PACA.KVM.SCRATCH0 = guest R12 + * PACA.KVM.SCRATCH1 = guest CR + * SPRG_SCRATCH0 = guest R13 + * + */ +kvmppc_handler_skip_ins: + + /* Patch the IP to the next instruction */ + mfsrr0 r12 + addir12, r12, 4 + mtsrr0 r12 + + /* Clean up all state */ + lwz r12, PACA_KVM_SCRATCH1(r13) + mtcrr12 + ld r12, PACA_KVM_SCRATCH0(r13) + mfspr r13, SPRN_SPRG_SCRATCH0 + + /* And get back into the code */ + RFI + +/* * This trampoline brings us back to a real mode handler * * Input Registers: diff --git a/arch/powerpc/kvm/book3s_64_slb.S b/arch/powerpc/kvm/book3s_64_slb.S index 7188c11..d07b886 100644 --- a/arch/powerpc/kvm/book3s_64_slb.S +++ b/arch/powerpc/kvm/book3s_64_slb.S @@ -212,10 +212,6 @@ kvmppc_handler_trampoline_exit: mfdar r5 mfdsisr r6 - /* Unset guest state */ - li r9, 0 - stb r9, PACA_KVM_IN_GUEST(r13) - /* * In order for us to easily get the last instruction, * we got the #vmexit at, we exploit the fact that the @@ -233,18 +229,28 @@ kvmppc_handler_trampoline_exit: ld_last_inst: /* Save off the guest instruction we're at */ + + /* Set guest mode to 'jump over instruction' so if lwz faults +* we'll just continue at the next IP. */ + li r9, KVM_GUEST_MODE_SKIP + stb r9, PACA_KVM_IN_GUEST(r13) + /*1) enable paging for data */ mfmsr r9 ori r11, r9, MSR_DR /* Enable paging for data */ mtmsr r11 /*2) fetch the instruction */ - /* XXX implement PACA_KVM_IN_GUEST=2 path to safely jump over this */ + li r0, KVM_INST_FETCH_FAILED /* In case lwz faults */ lwz r0, 0(r3) /*3) disable paging again */ mtmsr r9 no_ld_last_inst: + /* Unset guest mode */ + li r9, KVM_GUEST_MODE_NONE + stb r9, PACA_KVM_IN_GUEST(r13) + /* Restore bolted entries from the shadow and fix it along the way */ /* We don't store anything in entry 0, so we don't need to take care of it */ diff --git a/arch/powerpc/kvm/emulate.c b/arch/powerpc/kvm/emulate.c index 38219af..04e317c 100644 --- a/arch/powerpc/kvm/emulate.c +++
[COMMIT master] KVM: PPC: Get rid of unnecessary RFI
From: Alexander Graf ag...@suse.de Using an RFI in IR=1 is dangerous. We need to set two SRRs and then do an RFI without getting interrupted at all, because every interrupt could potentially overwrite the SRR values. Fortunately, we don't need to RFI in at least this particular case of the code, so we can just replace it with an mtmsr and b. Signed-off-by: Alexander Graf ag...@suse.de Signed-off-by: Avi Kivity a...@redhat.com diff --git a/arch/powerpc/kvm/book3s_64_interrupts.S b/arch/powerpc/kvm/book3s_64_interrupts.S index 66e3b11..3c0ba55 100644 --- a/arch/powerpc/kvm/book3s_64_interrupts.S +++ b/arch/powerpc/kvm/book3s_64_interrupts.S @@ -221,15 +221,8 @@ no_dcbz32_off: mflrr5 std r5, VCPU_LR(r7) - /* XXX convert to safe function call */ - /* Restore host msr - SRR1 */ ld r6, VCPU_HOST_MSR(r7) - mtsrr1 r6 - - /* Restore host IP - SRR0 */ - ld r5, VCPU_HOST_RETIP(r7) - mtsrr0 r5 /* * For some interrupts, we need to call the real Linux @@ -246,8 +239,9 @@ no_dcbz32_off: cmpwi r12, BOOK3S_INTERRUPT_DECREMENTER beq call_linux_handler - /* Back to Interruptable Mode! (goto kvm_return_point) */ - RFI + /* Back to EE=1 */ + mtmsr r6 + b kvm_return_point call_linux_handler: @@ -260,10 +254,16 @@ call_linux_handler: * interrupt handler! * * R3 still contains the exit code, -* R6 VCPU_HOST_RETIP and -* R7 VCPU_HOST_MSR +* R5 VCPU_HOST_RETIP and +* R6 VCPU_HOST_MSR */ + /* Restore host IP - SRR0 */ + ld r5, VCPU_HOST_RETIP(r7) + + /* XXX Better move to a safe function? +* What if we get an HTAB flush in between mtsrr0 and mtsrr1? */ + mtlrr12 ld r4, VCPU_TRAMPOLINE_LOWMEM(r7) -- 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: Fix HID5 setting code
From: Alexander Graf ag...@suse.de The code to unset HID5.dcbz32 is broken. This patch makes it do the right rotate magic. Signed-off-by: Alexander Graf ag...@suse.de Reported-by: Benjamin Herrenschmidt b...@kernel.crashing.org Signed-off-by: Avi Kivity a...@redhat.com diff --git a/arch/powerpc/kvm/book3s_64_interrupts.S b/arch/powerpc/kvm/book3s_64_interrupts.S index 33aef53..2ff0b21 100644 --- a/arch/powerpc/kvm/book3s_64_interrupts.S +++ b/arch/powerpc/kvm/book3s_64_interrupts.S @@ -177,8 +177,9 @@ kvmppc_handler_highmem: rldicl. r5, r5, 0, 63 /* CR = ((r5 1) == 0) */ beq no_dcbz32_off + li r4, 0 mfspr r5,SPRN_HID5 - rldimi r5,r5,6,56 + rldimi r5,r4,6,56 mtspr SPRN_HID5,r5 no_dcbz32_off: -- 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: Rename gb_page_enable() to get_lpage_level() in kvm_x86_ops
From: Sheng Yang sh...@linux.intel.com
Then the callback can provide the maximum supported large page level, which
is more flexible.
Also move the gb page support into x86_64 specific.
Signed-off-by: Sheng Yang sh...@linux.intel.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 741b897..a4de557 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -528,7 +528,7 @@ struct kvm_x86_ops {
int (*set_tss_addr)(struct kvm *kvm, unsigned int addr);
int (*get_tdp_level)(void);
u64 (*get_mt_mask)(struct kvm_vcpu *vcpu, gfn_t gfn, bool is_mmio);
- bool (*gb_page_enable)(void);
+ int (*get_lpage_level)(void);
bool (*rdtscp_supported)(void);
const struct trace_print_flags *exit_reasons_str;
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index b373ae6..cf64fc0 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -2911,9 +2911,9 @@ static const struct trace_print_flags
svm_exit_reasons_str[] = {
{ -1, NULL }
};
-static bool svm_gb_page_enable(void)
+static int svm_get_lpage_level(void)
{
- return true;
+ return PT_PDPE_LEVEL;
}
static bool svm_rdtscp_supported(void)
@@ -2986,7 +2986,7 @@ static struct kvm_x86_ops svm_x86_ops = {
.get_mt_mask = svm_get_mt_mask,
.exit_reasons_str = svm_exit_reasons_str,
- .gb_page_enable = svm_gb_page_enable,
+ .get_lpage_level = svm_get_lpage_level,
.cpuid_update = svm_cpuid_update,
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 455984a..7733235 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -4035,9 +4035,9 @@ static const struct trace_print_flags
vmx_exit_reasons_str[] = {
#undef _ER
-static bool vmx_gb_page_enable(void)
+static int vmx_get_lpage_level(void)
{
- return false;
+ return PT_DIRECTORY_LEVEL;
}
static inline u32 bit(int bitno)
@@ -4130,7 +4130,7 @@ static struct kvm_x86_ops vmx_x86_ops = {
.get_mt_mask = vmx_get_mt_mask,
.exit_reasons_str = vmx_exit_reasons_str,
- .gb_page_enable = vmx_gb_page_enable,
+ .get_lpage_level = vmx_get_lpage_level,
.cpuid_update = vmx_cpuid_update,
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index adc8597..6811e5e 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1642,10 +1642,12 @@ static void do_cpuid_ent(struct kvm_cpuid_entry2
*entry, u32 function,
u32 index, int *nent, int maxnent)
{
unsigned f_nx = is_efer_nx() ? F(NX) : 0;
- unsigned f_gbpages = kvm_x86_ops-gb_page_enable() ? F(GBPAGES) : 0;
#ifdef CONFIG_X86_64
+ unsigned f_gbpages = (kvm_x86_ops-get_lpage_level() == PT_PDPE_LEVEL)
+ ? F(GBPAGES) : 0;
unsigned f_lm = F(LM);
#else
+ unsigned f_gbpages = 0;
unsigned f_lm = 0;
#endif
unsigned f_rdtscp = kvm_x86_ops-rdtscp_supported() ? F(RDTSCP) : 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: VMX: Enable EPT 1GB page support
From: Sheng Yang sh...@linux.intel.com
Signed-off-by: Sheng Yang sh...@linux.intel.com
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/arch/x86/include/asm/vmx.h b/arch/x86/include/asm/vmx.h
index 713ed9a..43f1e9b 100644
--- a/arch/x86/include/asm/vmx.h
+++ b/arch/x86/include/asm/vmx.h
@@ -364,6 +364,7 @@ enum vmcs_field {
#define VMX_EPTP_UC_BIT(1ull 8)
#define VMX_EPTP_WB_BIT(1ull 14)
#define VMX_EPT_2MB_PAGE_BIT (1ull 16)
+#define VMX_EPT_1GB_PAGE_BIT (1ull 17)
#define VMX_EPT_EXTENT_INDIVIDUAL_BIT (1ull 24)
#define VMX_EPT_EXTENT_CONTEXT_BIT (1ull 25)
#define VMX_EPT_EXTENT_GLOBAL_BIT (1ull 26)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 12ccf14..4f5508c 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -500,8 +500,7 @@ out:
static int mapping_level(struct kvm_vcpu *vcpu, gfn_t large_gfn)
{
struct kvm_memory_slot *slot;
- int host_level;
- int level = PT_PAGE_TABLE_LEVEL;
+ int host_level, level, max_level;
slot = gfn_to_memslot(vcpu-kvm, large_gfn);
if (slot slot-dirty_bitmap)
@@ -512,7 +511,10 @@ static int mapping_level(struct kvm_vcpu *vcpu, gfn_t
large_gfn)
if (host_level == PT_PAGE_TABLE_LEVEL)
return host_level;
- for (level = PT_DIRECTORY_LEVEL; level = host_level; ++level)
+ max_level = kvm_x86_ops-get_lpage_level() host_level ?
+ kvm_x86_ops-get_lpage_level() : host_level;
+
+ for (level = PT_DIRECTORY_LEVEL; level = max_level; ++level)
if (has_wrprotected_page(vcpu-kvm, large_gfn, level))
break;
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 7733235..92c2f9a 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -318,6 +318,11 @@ static inline bool cpu_has_vmx_ept_2m_page(void)
return !!(vmx_capability.ept VMX_EPT_2MB_PAGE_BIT);
}
+static inline bool cpu_has_vmx_ept_1g_page(void)
+{
+ return !!(vmx_capability.ept VMX_EPT_1GB_PAGE_BIT);
+}
+
static inline int cpu_has_vmx_invept_individual_addr(void)
{
return !!(vmx_capability.ept VMX_EPT_EXTENT_INDIVIDUAL_BIT);
@@ -4037,7 +4042,11 @@ static const struct trace_print_flags
vmx_exit_reasons_str[] = {
static int vmx_get_lpage_level(void)
{
- return PT_DIRECTORY_LEVEL;
+ if (enable_ept !cpu_has_vmx_ept_1g_page())
+ return PT_DIRECTORY_LEVEL;
+ else
+ /* For shadow and EPT supported 1GB page */
+ return PT_PDPE_LEVEL;
}
static inline u32 bit(int bitno)
--
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: Use PACA backed shadow vcpu
From: Alexander Graf ag...@suse.de
We're being horribly racy right now. All the entry and exit code hijacks
random fields from the PACA that could easily be used by different code in
case we get interrupted, for example by a #MC or even page fault.
After discussing this with Ben, we figured it's best to reserve some more
space in the PACA and just shove off some vcpu state to there.
That way we can drastically improve the readability of the code, make it
less racy and less complex.
Signed-off-by: Alexander Graf ag...@suse.de
Signed-off-by: Avi Kivity a...@redhat.com
diff --git a/arch/powerpc/include/asm/kvm_book3s.h
b/arch/powerpc/include/asm/kvm_book3s.h
index 74b7369..f192017 100644
--- a/arch/powerpc/include/asm/kvm_book3s.h
+++ b/arch/powerpc/include/asm/kvm_book3s.h
@@ -23,6 +23,7 @@
#include linux/types.h
#include linux/kvm_host.h
#include asm/kvm_ppc.h
+#include asm/kvm_book3s_64_asm.h
struct kvmppc_slb {
u64 esid;
@@ -69,6 +70,7 @@ struct kvmppc_sid_map {
struct kvmppc_vcpu_book3s {
struct kvm_vcpu vcpu;
+ struct kvmppc_book3s_shadow_vcpu shadow_vcpu;
struct kvmppc_sid_map sid_map[SID_MAP_NUM];
struct kvmppc_slb slb[64];
struct {
diff --git a/arch/powerpc/include/asm/kvm_book3s_64_asm.h
b/arch/powerpc/include/asm/kvm_book3s_64_asm.h
index 2e06ee8..fca9404 100644
--- a/arch/powerpc/include/asm/kvm_book3s_64_asm.h
+++ b/arch/powerpc/include/asm/kvm_book3s_64_asm.h
@@ -20,6 +20,8 @@
#ifndef __ASM_KVM_BOOK3S_ASM_H__
#define __ASM_KVM_BOOK3S_ASM_H__
+#ifdef __ASSEMBLY__
+
#ifdef CONFIG_KVM_BOOK3S_64_HANDLER
#include asm/kvm_asm.h
@@ -55,4 +57,21 @@ kvmppc_resume_\intno:
#endif /* CONFIG_KVM_BOOK3S_64_HANDLER */
+#else /*__ASSEMBLY__ */
+
+struct kvmppc_book3s_shadow_vcpu {
+ ulong gpr[14];
+ u32 cr;
+ u32 xer;
+ ulong host_r1;
+ ulong host_r2;
+ ulong handler;
+ ulong scratch0;
+ ulong scratch1;
+ ulong vmhandler;
+ ulong rmhandler;
+};
+
+#endif /*__ASSEMBLY__ */
+
#endif /* __ASM_KVM_BOOK3S_ASM_H__ */
diff --git a/arch/powerpc/include/asm/kvm_host.h
b/arch/powerpc/include/asm/kvm_host.h
index 1201f62..d615fa8 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -175,10 +175,13 @@ struct kvm_vcpu_arch {
ulong gpr[32];
ulong pc;
- u32 cr;
ulong ctr;
ulong lr;
+
+#ifdef CONFIG_BOOKE
ulong xer;
+ u32 cr;
+#endif
ulong msr;
#ifdef CONFIG_PPC64
diff --git a/arch/powerpc/include/asm/kvm_ppc.h
b/arch/powerpc/include/asm/kvm_ppc.h
index d60b2f0..89c5d79 100644
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -98,34 +98,42 @@ extern void kvmppc_core_destroy_mmu(struct kvm_vcpu *vcpu);
#ifdef CONFIG_PPC_BOOK3S
+/* We assume we're always acting on the current vcpu */
+
static inline void kvmppc_set_gpr(struct kvm_vcpu *vcpu, int num, ulong val)
{
- vcpu-arch.gpr[num] = val;
+ if ( num 14 )
+ get_paca()-shadow_vcpu.gpr[num] = val;
+ else
+ vcpu-arch.gpr[num] = val;
}
static inline ulong kvmppc_get_gpr(struct kvm_vcpu *vcpu, int num)
{
- return vcpu-arch.gpr[num];
+ if ( num 14 )
+ return get_paca()-shadow_vcpu.gpr[num];
+ else
+ return vcpu-arch.gpr[num];
}
static inline void kvmppc_set_cr(struct kvm_vcpu *vcpu, u32 val)
{
- vcpu-arch.cr = val;
+ get_paca()-shadow_vcpu.cr = val;
}
static inline u32 kvmppc_get_cr(struct kvm_vcpu *vcpu)
{
- return vcpu-arch.cr;
+ return get_paca()-shadow_vcpu.cr;
}
static inline void kvmppc_set_xer(struct kvm_vcpu *vcpu, u32 val)
{
- vcpu-arch.xer = val;
+ get_paca()-shadow_vcpu.xer = val;
}
static inline u32 kvmppc_get_xer(struct kvm_vcpu *vcpu)
{
- return vcpu-arch.xer;
+ return get_paca()-shadow_vcpu.xer;
}
#else
diff --git a/arch/powerpc/include/asm/paca.h b/arch/powerpc/include/asm/paca.h
index 5e9b4ef..d8a6931 100644
--- a/arch/powerpc/include/asm/paca.h
+++ b/arch/powerpc/include/asm/paca.h
@@ -19,6 +19,9 @@
#include asm/mmu.h
#include asm/page.h
#include asm/exception-64e.h
+#ifdef CONFIG_KVM_BOOK3S_64_HANDLER
+#include asm/kvm_book3s_64_asm.h
+#endif
register struct paca_struct *local_paca asm(r13);
@@ -135,6 +138,8 @@ struct paca_struct {
u64 esid;
u64 vsid;
} kvm_slb[64]; /* guest SLB */
+ /* We use this to store guest state in */
+ struct kvmppc_book3s_shadow_vcpu shadow_vcpu;
u8 kvm_slb_max; /* highest used guest slb entry */
u8 kvm_in_guest;/* are we inside the guest? */
#endif
diff --git a/arch/powerpc/kernel/asm-offsets.c
b/arch/powerpc/kernel/asm-offsets.c
index a6c2b63..1501e77 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -194,6 +194,32
[COMMIT master] KVM: PPC: Use accessor functions for GPR access
From: Alexander Graf ag...@suse.de
All code in PPC KVM currently accesses gprs in the vcpu struct directly.
While there's nothing wrong with that wrt the current way gprs are stored
and loaded, it doesn't suffice for the PACA acceleration that will follow
in this patchset.
So let's just create little wrapper inline functions that we call whenever
a GPR needs to be read from or written to. The compiled code shouldn't really
change at all for now.
Signed-off-by: Alexander Graf ag...@suse.de
Signed-off-by: Avi Kivity a...@redhat.com
diff --git a/arch/powerpc/include/asm/kvm_ppc.h
b/arch/powerpc/include/asm/kvm_ppc.h
index abfd0c4..ba01b9c 100644
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -96,4 +96,30 @@ extern void kvmppc_booke_exit(void);
extern void kvmppc_core_destroy_mmu(struct kvm_vcpu *vcpu);
+#ifdef CONFIG_PPC_BOOK3S
+
+static inline void kvmppc_set_gpr(struct kvm_vcpu *vcpu, int num, ulong val)
+{
+ vcpu-arch.gpr[num] = val;
+}
+
+static inline ulong kvmppc_get_gpr(struct kvm_vcpu *vcpu, int num)
+{
+ return vcpu-arch.gpr[num];
+}
+
+#else
+
+static inline void kvmppc_set_gpr(struct kvm_vcpu *vcpu, int num, ulong val)
+{
+ vcpu-arch.gpr[num] = val;
+}
+
+static inline ulong kvmppc_get_gpr(struct kvm_vcpu *vcpu, int num)
+{
+ return vcpu-arch.gpr[num];
+}
+
+#endif
+
#endif /* __POWERPC_KVM_PPC_H__ */
diff --git a/arch/powerpc/kvm/44x_emulate.c b/arch/powerpc/kvm/44x_emulate.c
index 61af58f..65ea083 100644
--- a/arch/powerpc/kvm/44x_emulate.c
+++ b/arch/powerpc/kvm/44x_emulate.c
@@ -65,13 +65,14 @@ int kvmppc_core_emulate_op(struct kvm_run *run, struct
kvm_vcpu *vcpu,
*/
switch (dcrn) {
case DCRN_CPR0_CONFIG_ADDR:
- vcpu-arch.gpr[rt] = vcpu-arch.cpr0_cfgaddr;
+ kvmppc_set_gpr(vcpu, rt,
vcpu-arch.cpr0_cfgaddr);
break;
case DCRN_CPR0_CONFIG_DATA:
local_irq_disable();
mtdcr(DCRN_CPR0_CONFIG_ADDR,
vcpu-arch.cpr0_cfgaddr);
- vcpu-arch.gpr[rt] =
mfdcr(DCRN_CPR0_CONFIG_DATA);
+ kvmppc_set_gpr(vcpu, rt,
+ mfdcr(DCRN_CPR0_CONFIG_DATA));
local_irq_enable();
break;
default:
@@ -93,11 +94,11 @@ int kvmppc_core_emulate_op(struct kvm_run *run, struct
kvm_vcpu *vcpu,
/* emulate some access in kernel */
switch (dcrn) {
case DCRN_CPR0_CONFIG_ADDR:
- vcpu-arch.cpr0_cfgaddr = vcpu-arch.gpr[rs];
+ vcpu-arch.cpr0_cfgaddr = kvmppc_get_gpr(vcpu,
rs);
break;
default:
run-dcr.dcrn = dcrn;
- run-dcr.data = vcpu-arch.gpr[rs];
+ run-dcr.data = kvmppc_get_gpr(vcpu, rs);
run-dcr.is_write = 1;
vcpu-arch.dcr_needed = 1;
kvmppc_account_exit(vcpu, DCR_EXITS);
@@ -146,13 +147,13 @@ int kvmppc_core_emulate_mtspr(struct kvm_vcpu *vcpu, int
sprn, int rs)
switch (sprn) {
case SPRN_PID:
- kvmppc_set_pid(vcpu, vcpu-arch.gpr[rs]); break;
+ kvmppc_set_pid(vcpu, kvmppc_get_gpr(vcpu, rs)); break;
case SPRN_MMUCR:
- vcpu-arch.mmucr = vcpu-arch.gpr[rs]; break;
+ vcpu-arch.mmucr = kvmppc_get_gpr(vcpu, rs); break;
case SPRN_CCR0:
- vcpu-arch.ccr0 = vcpu-arch.gpr[rs]; break;
+ vcpu-arch.ccr0 = kvmppc_get_gpr(vcpu, rs); break;
case SPRN_CCR1:
- vcpu-arch.ccr1 = vcpu-arch.gpr[rs]; break;
+ vcpu-arch.ccr1 = kvmppc_get_gpr(vcpu, rs); break;
default:
emulated = kvmppc_booke_emulate_mtspr(vcpu, sprn, rs);
}
@@ -167,13 +168,13 @@ int kvmppc_core_emulate_mfspr(struct kvm_vcpu *vcpu, int
sprn, int rt)
switch (sprn) {
case SPRN_PID:
- vcpu-arch.gpr[rt] = vcpu-arch.pid; break;
+ kvmppc_set_gpr(vcpu, rt, vcpu-arch.pid); break;
case SPRN_MMUCR:
- vcpu-arch.gpr[rt] = vcpu-arch.mmucr; break;
+ kvmppc_set_gpr(vcpu, rt, vcpu-arch.mmucr); break;
case SPRN_CCR0:
- vcpu-arch.gpr[rt] = vcpu-arch.ccr0; break;
+ kvmppc_set_gpr(vcpu, rt, vcpu-arch.ccr0); break;
case SPRN_CCR1:
- vcpu-arch.gpr[rt] = vcpu-arch.ccr1; break;
+ kvmppc_set_gpr(vcpu, rt, vcpu-arch.ccr1); break;
default:
[COMMIT master] KVM: PPC: Emulate trap SRR1 flags properly
From: Alexander Graf ag...@suse.de
Book3S needs some flags in SRR1 to get to know details about an interrupt.
One such example is the trap instruction. It tells the guest kernel that
a program interrupt is due to a trap using a bit in SRR1.
This patch implements above behavior, making WARN_ON behave like WARN_ON.
Signed-off-by: Alexander Graf ag...@suse.de
Signed-off-by: Avi Kivity a...@redhat.com
diff --git a/arch/powerpc/include/asm/kvm_book3s.h
b/arch/powerpc/include/asm/kvm_book3s.h
index c91be0f..79ab8fa 100644
--- a/arch/powerpc/include/asm/kvm_book3s.h
+++ b/arch/powerpc/include/asm/kvm_book3s.h
@@ -91,6 +91,7 @@ struct kvmppc_vcpu_book3s {
u64 vsid_next;
u64 vsid_max;
int context_id;
+ ulong prog_flags; /* flags to inject when giving a 700 trap */
};
#define CONTEXT_HOST 0
diff --git a/arch/powerpc/include/asm/kvm_ppc.h
b/arch/powerpc/include/asm/kvm_ppc.h
index 89c5d79..09816da 100644
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -80,7 +80,7 @@ extern void kvmppc_core_vcpu_put(struct kvm_vcpu *vcpu);
extern void kvmppc_core_deliver_interrupts(struct kvm_vcpu *vcpu);
extern int kvmppc_core_pending_dec(struct kvm_vcpu *vcpu);
-extern void kvmppc_core_queue_program(struct kvm_vcpu *vcpu);
+extern void kvmppc_core_queue_program(struct kvm_vcpu *vcpu, ulong flags);
extern void kvmppc_core_queue_dec(struct kvm_vcpu *vcpu);
extern void kvmppc_core_dequeue_dec(struct kvm_vcpu *vcpu);
extern void kvmppc_core_queue_external(struct kvm_vcpu *vcpu,
diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index bc8dd53..5572e86 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -426,6 +426,10 @@
#define SRR1_WAKEMT 0x0028 /* mtctrl */
#define SRR1_WAKEDEC 0x0018 /* Decrementer interrupt */
#define SRR1_WAKETHERM 0x0010 /* Thermal management interrupt */
+#define SRR1_PROGFPE 0x0010 /* Floating Point Enabled */
+#define SRR1_PROGPRIV0x0004 /* Privileged instruction */
+#define SRR1_PROGTRAP0x0002 /* Trap */
+#define SRR1_PROGADDR0x0001 /* SRR0 contains subsequent
addr */
#define SPRN_HSRR0 0x13A /* Save/Restore Register 0 */
#define SPRN_HSRR1 0x13B /* Save/Restore Register 1 */
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index 1317392..66b5924 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -168,8 +168,9 @@ void kvmppc_book3s_queue_irqprio(struct kvm_vcpu *vcpu,
unsigned int vec)
}
-void kvmppc_core_queue_program(struct kvm_vcpu *vcpu)
+void kvmppc_core_queue_program(struct kvm_vcpu *vcpu, ulong flags)
{
+ to_book3s(vcpu)-prog_flags = flags;
kvmppc_book3s_queue_irqprio(vcpu, BOOK3S_INTERRUPT_PROGRAM);
}
@@ -198,6 +199,7 @@ int kvmppc_book3s_irqprio_deliver(struct kvm_vcpu *vcpu,
unsigned int priority)
{
int deliver = 1;
int vec = 0;
+ ulong flags = 0ULL;
switch (priority) {
case BOOK3S_IRQPRIO_DECREMENTER:
@@ -231,6 +233,7 @@ int kvmppc_book3s_irqprio_deliver(struct kvm_vcpu *vcpu,
unsigned int priority)
break;
case BOOK3S_IRQPRIO_PROGRAM:
vec = BOOK3S_INTERRUPT_PROGRAM;
+ flags = to_book3s(vcpu)-prog_flags;
break;
case BOOK3S_IRQPRIO_VSX:
vec = BOOK3S_INTERRUPT_VSX;
@@ -261,7 +264,7 @@ int kvmppc_book3s_irqprio_deliver(struct kvm_vcpu *vcpu,
unsigned int priority)
#endif
if (deliver)
- kvmppc_inject_interrupt(vcpu, vec, 0ULL);
+ kvmppc_inject_interrupt(vcpu, vec, flags);
return deliver;
}
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index 338baf9..e283e44 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -82,8 +82,9 @@ static void kvmppc_booke_queue_irqprio(struct kvm_vcpu *vcpu,
set_bit(priority, vcpu-arch.pending_exceptions);
}
-void kvmppc_core_queue_program(struct kvm_vcpu *vcpu)
+void kvmppc_core_queue_program(struct kvm_vcpu *vcpu, ulong flags)
{
+ /* BookE does flags in ESR, so ignore those we get here */
kvmppc_booke_queue_irqprio(vcpu, BOOKE_IRQPRIO_PROGRAM);
}
diff --git a/arch/powerpc/kvm/emulate.c b/arch/powerpc/kvm/emulate.c
index 04e317c..8b0ba0b 100644
--- a/arch/powerpc/kvm/emulate.c
+++ b/arch/powerpc/kvm/emulate.c
@@ -154,7 +154,7 @@ int kvmppc_emulate_instruction(struct kvm_run *run, struct
kvm_vcpu *vcpu)
#else
vcpu-arch.esr |= ESR_PTR;
#endif
- kvmppc_core_queue_program(vcpu);
+ kvmppc_core_queue_program(vcpu, SRR1_PROGTRAP);
advance = 0;
break;
--
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
Re: [PATCH 0/2] eventfd: new EFD_STATE flag
On Thu, Jan 07, 2010 at 12:36:01PM +0200, Michael S. Tsirkin wrote: Or if I do it the other way: remove_wait_queue(irqfd-wqh, irqfd-wait); - eventfd_read_ctx(irqfd-eventfd, ucnt); now, if device signals eventfd at point marked by -, it will not be sent but counter will be cleared, so we will loose a message. May be I am missing something here, but why doing it like that is a problem? Event delivery races with interrupt masking so making masking succeed before event delivery is OK. Event generation is asynchronous anyway and could have happened jiffy latter anyway. -- 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 0/2] eventfd: new EFD_STATE flag
On Mon, Jan 11, 2010 at 11:01:27AM +0200, Gleb Natapov wrote: On Thu, Jan 07, 2010 at 12:36:01PM +0200, Michael S. Tsirkin wrote: Or if I do it the other way: remove_wait_queue(irqfd-wqh, irqfd-wait); - eventfd_read_ctx(irqfd-eventfd, ucnt); now, if device signals eventfd at point marked by -, it will not be sent but counter will be cleared, so we will loose a message. May be I am missing something here, but why doing it like that is a problem? Event delivery races with interrupt masking so making masking succeed before event delivery is OK. Event generation is asynchronous anyway and could have happened jiffy latter anyway. -- Gleb. No, event generation would only trigger a single interrupt. This race generates two interrupts for a single event. This can never happen with real hardware. eventfd_ctx_remove_wait_queue would solve this problem. -- MST -- 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 0/2] eventfd: new EFD_STATE flag
On Mon, Jan 11, 2010 at 11:02:27AM +0200, Michael S. Tsirkin wrote: On Mon, Jan 11, 2010 at 11:01:27AM +0200, Gleb Natapov wrote: On Thu, Jan 07, 2010 at 12:36:01PM +0200, Michael S. Tsirkin wrote: Or if I do it the other way: remove_wait_queue(irqfd-wqh, irqfd-wait); - eventfd_read_ctx(irqfd-eventfd, ucnt); now, if device signals eventfd at point marked by -, it will not be sent but counter will be cleared, so we will loose a message. May be I am missing something here, but why doing it like that is a problem? Event delivery races with interrupt masking so making masking succeed before event delivery is OK. Event generation is asynchronous anyway and could have happened jiffy latter anyway. -- Gleb. No, event generation would only trigger a single interrupt. This race generates two interrupts for a single event. This can never happen with real hardware. eventfd_ctx_remove_wait_queue would solve this problem. In quoted test above you are saying that we will loose a message. So how does it generates two interrupts when we loose a message? -- 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 0/2] eventfd: new EFD_STATE flag
On Mon, Jan 11, 2010 at 11:08:38AM +0200, Gleb Natapov wrote: On Mon, Jan 11, 2010 at 11:02:27AM +0200, Michael S. Tsirkin wrote: On Mon, Jan 11, 2010 at 11:01:27AM +0200, Gleb Natapov wrote: On Thu, Jan 07, 2010 at 12:36:01PM +0200, Michael S. Tsirkin wrote: Or if I do it the other way: remove_wait_queue(irqfd-wqh, irqfd-wait); - eventfd_read_ctx(irqfd-eventfd, ucnt); now, if device signals eventfd at point marked by -, it will not be sent but counter will be cleared, so we will loose a message. May be I am missing something here, but why doing it like that is a problem? Event delivery races with interrupt masking so making masking succeed before event delivery is OK. Event generation is asynchronous anyway and could have happened jiffy latter anyway. -- Gleb. No, event generation would only trigger a single interrupt. This race generates two interrupts for a single event. This can never happen with real hardware. eventfd_ctx_remove_wait_queue would solve this problem. In quoted test above you are saying that we will loose a message. So how does it generates two interrupts when we loose a message? -- Gleb. Right, sorry. I think what you miss is the fact that this is done during interrupt vector masking/unmasking, so events signalled while eventfd is not assigned to interrupt must not be lost, they should be pending and delivered later when interrupt vector is unmasked, that is when eventfd is reassigned to an interrupt. So this implementation really loses an interrupt: remove_wait_queue(irqfd-wqh, irqfd-wait); - at this point vector is masked: we are not polling eventfd anymore, event triggered at this point should cause interrupt after vector is unmasked, but the only thing is causes is counter increment in eventfd. eventfd_read_ctx(irqfd-eventfd, ucnt); - the above call would clear the counter, so we won't get an interrupt when vector is later unmasked. -- MST -- 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: CPU hotplug add seems broken
2010/1/10 Gleb Natapov g...@redhat.com: On Sun, Jan 10, 2010 at 05:33:02PM +0900, Ryota Ozaki wrote: [...] I see. Anyway I think we need some workaround to avoid segfault. Disabling cpu_set command for qemu-kvm-0.12 is good enough workaround. Agree. I'll send a patch. but ACPI code that handles CPU host-plug was not ported to SeaBIOS when it replaces BOCH BIOS. Yeah, I confirmed it during memory hotplug work... So I'd like to know when cpu hotplug comes back? I didn't see it in qemu-0.13 feature requests. May I ask what do you need it for? Oh sorry, actually I have not so strong desire on cpu hotplug but I have on memory hotplug and just want to learn stuffs to implement it from cpu's one. Honestly said I'm not sure someone want it. The problem is that there is no standard way to hotplug CPUs in a PC. Linux implements the way UNISYS happen to do it, but no other system do it like that. Windows implements it differently and in the way that conflicts with Linux, so you can't have working Linux implementation and pass Microsoft SVVP test at the same time for instance. Could I ask you what's the difference between the two implementations? Don't we have a possibility to have different implementations in qemu-kvm (and SeaBIOS)? And also I want to ask that the problem can be applied to memory hotplug case? Thanks, ozaki-r -- 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: CPU hotplug add seems broken
On Mon, Jan 11, 2010 at 06:24:32PM +0900, Ryota Ozaki wrote: 2010/1/10 Gleb Natapov g...@redhat.com: On Sun, Jan 10, 2010 at 05:33:02PM +0900, Ryota Ozaki wrote: [...] I see. Anyway I think we need some workaround to avoid segfault. Disabling cpu_set command for qemu-kvm-0.12 is good enough workaround. Agree. I'll send a patch. Thanks. but ACPI code that handles CPU host-plug was not ported to SeaBIOS when it replaces BOCH BIOS. Yeah, I confirmed it during memory hotplug work... So I'd like to know when cpu hotplug comes back? I didn't see it in qemu-0.13 feature requests. May I ask what do you need it for? Oh sorry, actually I have not so strong desire on cpu hotplug but I have on memory hotplug and just want to learn stuffs to implement it from cpu's one. Honestly said I'm not sure someone want it. Hmm, everybody want it, but nobody can't say why. Looks like it just sounds cool :) The problem is that there is no standard way to hotplug CPUs in a PC. Linux implements the way UNISYS happen to do it, but no other system do it like that. Windows implements it differently and in the way that conflicts with Linux, so you can't have working Linux implementation and pass Microsoft SVVP test at the same time for instance. Could I ask you what's the difference between the two implementations? I have no idea how it works in Windows. It seems that some kind of driver is required for hot-plugging cpu there. Don't we have a possibility to have different implementations in qemu-kvm (and SeaBIOS)? What do you mean by different implementation? Different one for Windows and Linux and have a switch to choose one? Possible, but not desirable. Different from what we had in BOCHS BIOS? Also possible, but will require changes to Linux kernel and older Kernel will not work. And also I want to ask that the problem can be applied to memory hotplug case? AFAIK memory hotplug is part of ACPI spec and if implemented correctly should not cause any problems. -- 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 0/2] eventfd: new EFD_STATE flag
On Mon, Jan 11, 2010 at 11:19:19AM +0200, Michael S. Tsirkin wrote: On Mon, Jan 11, 2010 at 11:08:38AM +0200, Gleb Natapov wrote: On Mon, Jan 11, 2010 at 11:02:27AM +0200, Michael S. Tsirkin wrote: On Mon, Jan 11, 2010 at 11:01:27AM +0200, Gleb Natapov wrote: On Thu, Jan 07, 2010 at 12:36:01PM +0200, Michael S. Tsirkin wrote: Or if I do it the other way: remove_wait_queue(irqfd-wqh, irqfd-wait); - eventfd_read_ctx(irqfd-eventfd, ucnt); now, if device signals eventfd at point marked by -, it will not be sent but counter will be cleared, so we will loose a message. May be I am missing something here, but why doing it like that is a problem? Event delivery races with interrupt masking so making masking succeed before event delivery is OK. Event generation is asynchronous anyway and could have happened jiffy latter anyway. -- Gleb. No, event generation would only trigger a single interrupt. This race generates two interrupts for a single event. This can never happen with real hardware. eventfd_ctx_remove_wait_queue would solve this problem. In quoted test above you are saying that we will loose a message. So how does it generates two interrupts when we loose a message? -- Gleb. Right, sorry. I think what you miss is the fact that this is done during interrupt vector masking/unmasking, so events signalled while eventfd is not assigned to interrupt must not be lost, they should be pending and delivered later when interrupt vector is unmasked, that is when eventfd is reassigned to an interrupt. Is this how MSI works? If interrupt is triggered while it is masked it is reasserted after unmasking? This is certainly no true for interrupt masking on irq chip level. So this implementation really loses an interrupt: remove_wait_queue(irqfd-wqh, irqfd-wait); - at this point vector is masked: we are not polling eventfd anymore, event triggered at this point should cause interrupt after vector is unmasked, but the only thing is causes is counter increment in eventfd. eventfd_read_ctx(irqfd-eventfd, ucnt); - the above call would clear the counter, so we won't get an interrupt when vector is later unmasked. Don't you going to use ucnt to set interrupt status bit? Can't you re-trigger the interrupt after unmasking if status bit is set? -- 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 0/2] eventfd: new EFD_STATE flag
On Mon, Jan 11, 2010 at 11:36:16AM +0200, Gleb Natapov wrote: On Mon, Jan 11, 2010 at 11:19:19AM +0200, Michael S. Tsirkin wrote: On Mon, Jan 11, 2010 at 11:08:38AM +0200, Gleb Natapov wrote: On Mon, Jan 11, 2010 at 11:02:27AM +0200, Michael S. Tsirkin wrote: On Mon, Jan 11, 2010 at 11:01:27AM +0200, Gleb Natapov wrote: On Thu, Jan 07, 2010 at 12:36:01PM +0200, Michael S. Tsirkin wrote: Or if I do it the other way: remove_wait_queue(irqfd-wqh, irqfd-wait); - eventfd_read_ctx(irqfd-eventfd, ucnt); now, if device signals eventfd at point marked by -, it will not be sent but counter will be cleared, so we will loose a message. May be I am missing something here, but why doing it like that is a problem? Event delivery races with interrupt masking so making masking succeed before event delivery is OK. Event generation is asynchronous anyway and could have happened jiffy latter anyway. -- Gleb. No, event generation would only trigger a single interrupt. This race generates two interrupts for a single event. This can never happen with real hardware. eventfd_ctx_remove_wait_queue would solve this problem. In quoted test above you are saying that we will loose a message. So how does it generates two interrupts when we loose a message? -- Gleb. Right, sorry. I think what you miss is the fact that this is done during interrupt vector masking/unmasking, so events signalled while eventfd is not assigned to interrupt must not be lost, they should be pending and delivered later when interrupt vector is unmasked, that is when eventfd is reassigned to an interrupt. Is this how MSI works? If interrupt is triggered while it is masked it is reasserted after unmasking? This is certainly no true for interrupt masking on irq chip level. Yes. So this implementation really loses an interrupt: remove_wait_queue(irqfd-wqh, irqfd-wait); - at this point vector is masked: we are not polling eventfd anymore, event triggered at this point should cause interrupt after vector is unmasked, but the only thing is causes is counter increment in eventfd. eventfd_read_ctx(irqfd-eventfd, ucnt); - the above call would clear the counter, so we won't get an interrupt when vector is later unmasked. Don't you going to use ucnt to set interrupt status bit? Can't you re-trigger the interrupt after unmasking if status bit is set? Yes, this is what Davidel suggested originally. There's nowhere to save the ucnt though because event is being deasserted. -- 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: qemu-kvm.git build problem
Lucas Meneghel Rodrigues wrote: On Mon, 2009-12-28 at 16:40 -0200, Lucas Meneghel Rodrigues wrote: Hi, we've had a problem on today's git testing when trying to build from latest upstream qemu-kvm.git repo: 12/28 13:39:18 DEBUG| utils:0069| Running 'make -j 2' 12/28 13:39:18 DEBUG| utils:0101| [stdout] make -C /lib/modules/2.6.31.6-166.fc12.x86_64/build M=`pwd` \ 12/28 13:39:18 DEBUG| utils:0101| [stdout] LINUXINCLUDE=-I`pwd`/include -Iinclude \ 12/28 13:39:18 DEBUG| utils:0101| [stdout] -Iarch/x86/include -I`pwd`/include-compat -I`pwd`/x86 \ 12/28 13:39:18 DEBUG| utils:0101| [stdout] -include include/linux/autoconf.h \ 12/28 13:39:18 DEBUG| utils:0101| [stdout] -include `pwd`/x86/external-module-compat.h \ 12/28 13:39:18 DEBUG| utils:0101| [stdout] $@ 12/28 13:39:18 DEBUG| utils:0101| [stdout] make[1]: Entering directory `/usr/src/kernels/2.6.31.6-166.fc12.x86_64' 12/28 13:39:19 DEBUG| utils:0101| [stdout] LD /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/built-in.o 12/28 13:39:19 DEBUG| utils:0101| [stdout] CC [M] /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/svm.o 12/28 13:39:19 DEBUG| utils:0101| [stdout] CC [M] /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/vmx.o 12/28 13:39:22 ERROR| utils:0101| [stderr] /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/vmx.c:271: error: ‘MSR_TSC_AUX’ undeclared here (not in a function) 12/28 13:39:22 ERROR| utils:0101| [stderr] /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/vmx.c: In function ‘setup_msrs’: 12/28 13:39:22 ERROR| utils:0101| [stderr] /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/vmx.c:985: warning: passing argument 2 of ‘__find_msr_index’ makes integer from pointer without a cast 12/28 13:39:22 ERROR| utils:0101| [stderr] /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/vmx.c:424: note: expected ‘u32’ but argument is of type ‘const u32 *’ 12/28 13:39:22 ERROR| utils:0101| [stderr] make[3]: *** [/usr/local/autotest/tests/kvm/src/kvm_kmod/x86/vmx.o] Error 1 12/28 13:39:22 ERROR| utils:0101| [stderr] make[3]: *** Waiting for unfinished jobs 12/28 13:39:23 ERROR| utils:0101| [stderr] make[2]: *** [/usr/local/autotest/tests/kvm/src/kvm_kmod/x86] Error 2 12/28 13:39:23 DEBUG| utils:0101| [stdout] make[1]: Leaving directory `/usr/src/kernels/2.6.31.6-166.fc12.x86_64' 12/28 13:39:23 ERROR| utils:0101| [stderr] make[1]: *** [_module_/usr/local/autotest/tests/kvm/src/kvm_kmod] Error 2 12/28 13:39:23 ERROR| utils:0101| [stderr] make: *** [all] Error 2 This might be a problem on kvm-kmod, I am just making sure you guys are aware of this. Hi folks, as of today this build problem hasn't been fixed (just a friendly reminder). I'm aware of the issues, already fixed some of them, but were unable to fully test during vacation + the KVM tree moved on. Hope I'll find some time to push a complete solution the next days. BTW, does anybody know how to back-port synchronize_srcu_expedited best? It looked like a simple mapping to synchronize_srcu was not sufficient to achieve the same performance as with the pre-srcu locking (e.g. guesthost stalled during guest's framebuffer setup). Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- 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
-next Jan 11 : s390/kvm build failure
Today's next build on s390 failed with: In file included from arch/s390/kvm/kvm-s390.c:30: arch/s390/kvm/kvm-s390.h: In function 'kvm_s390_vcpu_set_mem': arch/s390/kvm/kvm-s390.h:75: warning: assignment from incompatible pointer type arch/s390/kvm/kvm-s390.h:77: error: dereferencing pointer to incomplete type arch/s390/kvm/kvm-s390.c: At top level: arch/s390/kvm/kvm-s390.c:692: error: conflicting types for 'kvm_arch_prepare_memory_region' include/linux/kvm_host.h:258: error: previous declaration of 'kvm_arch_prepare_memory_region' was here arch/s390/kvm/kvm-s390.c: In function 'kvm_arch_prepare_memory_region': arch/s390/kvm/kvm-s390.c:698: warning: unused variable 'vcpu' arch/s390/kvm/kvm-s390.c:697: warning: unused variable 'i' arch/s390/kvm/kvm-s390.c: At top level: arch/s390/kvm/kvm-s390.c:725: error: conflicting types for 'kvm_arch_commit_memory_region' include/linux/kvm_host.h:262: error: previous declaration of 'kvm_arch_commit_memory_region' was here arch/s390/kvm/kvm-s390.c: In function 'kvm_arch_commit_memory_region': arch/s390/kvm/kvm-s390.c:731: error: 'i' undeclared (first use in this function) arch/s390/kvm/kvm-s390.c:731: error: (Each undeclared identifier is reported only once arch/s390/kvm/kvm-s390.c:731: error: for each function it appears in.) arch/s390/kvm/kvm-s390.c:731: error: 'vcpu' undeclared (first use in this function) arch/s390/kvm/kvm-s390.c:731: warning: left-hand operand of comma expression has no effect and few more In file included from arch/s390/kvm/intercept.c:20: arch/s390/kvm/kvm-s390.h: In function 'kvm_s390_vcpu_set_mem': arch/s390/kvm/kvm-s390.h:75: warning: assignment from incompatible pointer type arch/s390/kvm/kvm-s390.h:77: error: dereferencing pointer to incomplete type make[1]: *** [arch/s390/kvm/intercept.o] Error 1 Probable cause could be the following commits : commit a94db899e8e5b7c4d47e42982800243dcdc69a38 KVM: split kvm_arch_set_memory_region into prepare and commit commit fe7701e1daa1ad09d5d271897b6cc65697d33db2 KVM: switch vcpu context to use SRCU Thanks -Sachin -- - Sachin Sant IBM Linux Technology Center India Systems and Technology Labs Bangalore, India - -- 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-kvm.git build problem
On 01/11/2010 12:13 PM, Jan Kiszka wrote: BTW, does anybody know how to back-port synchronize_srcu_expedited best? It looked like a simple mapping to synchronize_srcu was not sufficient to achieve the same performance as with the pre-srcu locking (e.g. guesthost stalled during guest's framebuffer setup). Isn't it sufficient to backport kernel/srcu.c? I thought no sched.c changes were necessary. -- 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
[ kvm-Bugs-2907597 ] qemu vnc server clips at 2560x1600
Bugs item #2907597, was opened at 2009-12-02 18:57 Message generated for change (Settings changed) made by avik You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2907597group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: qemu Group: None Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Matthew Colyer (mcsoccer) Assigned to: Nobody/Anonymous (nobody) Summary: qemu vnc server clips at 2560x1600 Initial Comment: So I am running using the VESA driver to run an Ubuntu 9.10 guest at 2560x1600 (I had to modify the xserver-video-vesa package to remove an internal screen limit of 2048x2048 in the xorg vesa driver) and everything works great except that the qemu vnc server appears to clip at this resolution. The problem goes away if I run 1900x1200 and it doesn't change if I run 16bit depth or 24bit depth. I have attached two screenshots, the first is vncing directly into qemu (which exhibits the problem) and the second is vncing to a vnc server I have running in the guest which doesn't have the problem. I poked around in vnc.c and couldn't see any limits but I feel like its a buffer limit of some kind. Also if you look very closely at the first image you can see that the first row is drawn correctly all the way across but subsequent rows are not. If you need more information doesn't hesitate to ask. -- Comment By: Avi Kivity (avik) Date: 2010-01-11 12:19 Message: Can you try changing VNC_MAX_WIDTH in vnc.h? -- Comment By: Avi Kivity (avik) Date: 2010-01-10 18:26 Message: Confirmed with vncviewer and vinagre, so unlikely to be a client problem. -- Comment By: Avi Kivity (avik) Date: 2010-01-10 16:17 Message: The cropping is 512 pixels wide, the correct area is 2048 pixels wide, so it does look like some kind of limit. -- Comment By: SourceForge Robot (sf-robot) Date: 2009-12-28 04:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). -- Comment By: Matthew Colyer (mcsoccer) Date: 2009-12-17 05:18 Message: The blocks do not show up when run in SDL mode. So I believe the problem is still somehow related to the VNC server. -- Comment By: Avi Kivity (avik) Date: 2009-12-13 12:29 Message: Does it work well with SDL? Maybe the problem is not vnc related. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2907597group_id=180599 -- 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: CPU hotplug add seems broken
On Mon, Jan 11, 2010 at 6:32 PM, Gleb Natapov g...@redhat.com wrote: On Mon, Jan 11, 2010 at 06:24:32PM +0900, Ryota Ozaki wrote: 2010/1/10 Gleb Natapov g...@redhat.com: [...] May I ask what do you need it for? Oh sorry, actually I have not so strong desire on cpu hotplug but I have on memory hotplug and just want to learn stuffs to implement it from cpu's one. Honestly said I'm not sure someone want it. Hmm, everybody want it, but nobody can't say why. Looks like it just sounds cool :) I cannot disclaim that :) If we have textbookish answers, they will be somewhat We have a physical machine could have multiple VMs and the number of VMs dynamically varies, so we need to change the number of VCPUs of the VMs on the fly to gain maximum throughput or A migrated VM may have an opportunity to get more VCPUs so far because the destination physical machine has more number of CPUs than source one., however, I have not ever faced such situations. The problem is that there is no standard way to hotplug CPUs in a PC. Linux implements the way UNISYS happen to do it, but no other system do it like that. Windows implements it differently and in the way that conflicts with Linux, so you can't have working Linux implementation and pass Microsoft SVVP test at the same time for instance. Could I ask you what's the difference between the two implementations? I have no idea how it works in Windows. It seems that some kind of driver is required for hot-plugging cpu there. I see. Thanks. I'll check it and also VMware case that likely supports the function. Don't we have a possibility to have different implementations in qemu-kvm (and SeaBIOS)? What do you mean by different implementation? Different one for Windows and Linux and have a switch to choose one? Possible, but not desirable. Different from what we had in BOCHS BIOS? Also possible, but will require changes to Linux kernel and older Kernel will not work. I mean the former one. I think it'd be a way to have cpu hotplug supports for both Linxu and Windows (and others), but yes, it's the case only if the supports are really really desired. So I want to hear the comments by someones using CPU hotplug functions in real use if exist. And also I want to ask that the problem can be applied to memory hotplug case? AFAIK memory hotplug is part of ACPI spec and if implemented correctly should not cause any problems. That makes me happy ;-) Thank you for telling me! ozaki-r -- 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: qemu-kvm.git build problem
Avi Kivity wrote: On 01/11/2010 12:13 PM, Jan Kiszka wrote: BTW, does anybody know how to back-port synchronize_srcu_expedited best? It looked like a simple mapping to synchronize_srcu was not sufficient to achieve the same performance as with the pre-srcu locking (e.g. guesthost stalled during guest's framebuffer setup). Isn't it sufficient to backport kernel/srcu.c? I thought no sched.c changes were necessary. Haven't looked yet, but if that's the case, it would indeed be straightforward. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- 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: CPU hotplug add seems broken
On 01/11/2010 11:24 AM, Ryota Ozaki wrote: The problem is that there is no standard way to hotplug CPUs in a PC. Linux implements the way UNISYS happen to do it, but no other system do it like that. Windows implements it differently and in the way that conflicts with Linux, so you can't have working Linux implementation and pass Microsoft SVVP test at the same time for instance. Could I ask you what's the difference between the two implementations? Don't we have a possibility to have different implementations in qemu-kvm (and SeaBIOS)? IMO we should stick with the unisys-derived implementation, port it to SeaBIOS, and write a Windows driver for it. It has the advantage of having support in Linux, and of being somewhat tested. -- 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: CPU hotplug add seems broken
On Mon, Jan 11, 2010 at 12:23:05PM +0200, Avi Kivity wrote: On 01/11/2010 11:24 AM, Ryota Ozaki wrote: The problem is that there is no standard way to hotplug CPUs in a PC. Linux implements the way UNISYS happen to do it, but no other system do it like that. Windows implements it differently and in the way that conflicts with Linux, so you can't have working Linux implementation and pass Microsoft SVVP test at the same time for instance. Could I ask you what's the difference between the two implementations? Don't we have a possibility to have different implementations in qemu-kvm (and SeaBIOS)? IMO we should stick with the unisys-derived implementation, port it to SeaBIOS, and write a Windows driver for it. It has the advantage of having support in Linux, and of being somewhat tested. That cool, but SVVP complains. -- 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: CPU hotplug add seems broken
On 01/11/2010 12:24 PM, Gleb Natapov wrote: IMO we should stick with the unisys-derived implementation, port it to SeaBIOS, and write a Windows driver for it. It has the advantage of having support in Linux, and of being somewhat tested. That cool, but SVVP complains. What's the complaint? Maybe we can fix it instead of rewriting things. -- 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: CPU hotplug add seems broken
On Mon, Jan 11, 2010 at 7:23 PM, Avi Kivity a...@redhat.com wrote: On 01/11/2010 11:24 AM, Ryota Ozaki wrote: The problem is that there is no standard way to hotplug CPUs in a PC. Linux implements the way UNISYS happen to do it, but no other system do it like that. Windows implements it differently and in the way that conflicts with Linux, so you can't have working Linux implementation and pass Microsoft SVVP test at the same time for instance. Could I ask you what's the difference between the two implementations? Don't we have a possibility to have different implementations in qemu-kvm (and SeaBIOS)? IMO we should stick with the unisys-derived implementation, port it to SeaBIOS, and write a Windows driver for it. It has the advantage of having support in Linux, and of being somewhat tested. Oh, pleasure to hear it ;-) ozaki-r -- 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: -next Jan 11 : s390/kvm build failure
On 01/11/2010 12:15 PM, Sachin Sant wrote: Probable cause could be the following commits : commit a94db899e8e5b7c4d47e42982800243dcdc69a38 KVM: split kvm_arch_set_memory_region into prepare and commit commit fe7701e1daa1ad09d5d271897b6cc65697d33db2 KVM: switch vcpu context to use SRCU Yes. Marcelo? ia64 suffers from the same issue. -- 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 0/6 v2] Lazy fpu for svm/npt
On Sun, Jan 10, 2010 at 12:31:23PM +0200, Avi Kivity wrote: This patchset (on top of the previous cr0 patchset) brings lazy fpu to npt. For the cases where guest and host cr0 match (the majority) it will disable intercepts for cr0.ts once the guest fpu is loaded, so the guest can to its own lazy fpu without trapping. Looks good to me. Acked-by: Joerg Roedel joerg.roe...@amd.com -- 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 0/6 v2] Lazy fpu for svm/npt
On 01/11/2010 12:32 PM, Joerg Roedel wrote: On Sun, Jan 10, 2010 at 12:31:23PM +0200, Avi Kivity wrote: This patchset (on top of the previous cr0 patchset) brings lazy fpu to npt. For the cases where guest and host cr0 match (the majority) it will disable intercepts for cr0.ts once the guest fpu is loaded, so the guest can to its own lazy fpu without trapping. Looks good to me. Acked-by: Joerg Roedeljoerg.roe...@amd.com Now merged, along with the earlier vmx-related bits. -- 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: CPU hotplug add seems broken
On Mon, Jan 11, 2010 at 12:25:52PM +0200, Avi Kivity wrote: On 01/11/2010 12:24 PM, Gleb Natapov wrote: IMO we should stick with the unisys-derived implementation, port it to SeaBIOS, and write a Windows driver for it. It has the advantage of having support in Linux, and of being somewhat tested. That cool, but SVVP complains. What's the complaint? Maybe we can fix it instead of rewriting things. https://bugzilla.redhat.com/show_bug.cgi?id=49584://bugzilla.redhat.com/show_bug.cgi?id=495844 Hope it accessible to everyone but if not SVVP complains: Run Signed Driver check of SVVP testing, the (Qemu virtual CPU verison 0.9.1) has error. The only why to fix it that I can see is to not present disabled MADT entries for Windows and that will require us to provide some kind of flag to QEMU. The cleanest way is to create disabled MADT entries only if max-cpus != startup cpus and run Windows only with max-cpus == startup cpus. The problem is 1) you have to know what is your guest at startup time 2) will require creation of SSDT for Processors() on the fly (or precompile them for every value of max-cpus and load dynamically). Actually there is a third solution that I just thought about but I need to test it first :). Anyway all those solution do not guaranty that we will be able to do cpu hotplug on Windows since we don't yet know what Windows expects. -- 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: CPU hotplug add seems broken
On 01/11/2010 12:42 PM, Gleb Natapov wrote: That cool, but SVVP complains. What's the complaint? Maybe we can fix it instead of rewriting things. https://bugzilla.redhat.com/show_bug.cgi?id=49584://bugzilla.redhat.com/show_bug.cgi?id=495844 Hope it accessible to everyone but if not SVVP complains: Run Signed Driver check of SVVP testing, the (Qemu virtual CPU verison 0.9.1) has error. The only why to fix it that I can see is to not present disabled MADT entries for Windows and that will require us to provide some kind of flag to QEMU. The cleanest way is to create disabled MADT entries only if max-cpus != startup cpus and run Windows only with max-cpus == startup cpus. The problem is 1) you have to know what is your guest at startup time 2) will require creation of SSDT for Processors() on the fly (or precompile them for every value of max-cpus and load dynamically). Actually there is a third solution that I just thought about but I need to test it first :). Perhaps loading a processor driver will fix this issue (which driver can also perform the hotplug). Anyway all those solution do not guaranty that we will be able to do cpu hotplug on Windows since we don't yet know what Windows expects. I'm sure we'll be able to eventually. -- 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: CPU hotplug add seems broken
On Mon, Jan 11, 2010 at 12:50:05PM +0200, Avi Kivity wrote: On 01/11/2010 12:42 PM, Gleb Natapov wrote: That cool, but SVVP complains. What's the complaint? Maybe we can fix it instead of rewriting things. https://bugzilla.redhat.com/show_bug.cgi?id=49584://bugzilla.redhat.com/show_bug.cgi?id=495844 Hope it accessible to everyone but if not SVVP complains: Run Signed Driver check of SVVP testing, the (Qemu virtual CPU verison 0.9.1) has error. The only why to fix it that I can see is to not present disabled MADT entries for Windows and that will require us to provide some kind of flag to QEMU. The cleanest way is to create disabled MADT entries only if max-cpus != startup cpus and run Windows only with max-cpus == startup cpus. The problem is 1) you have to know what is your guest at startup time 2) will require creation of SSDT for Processors() on the fly (or precompile them for every value of max-cpus and load dynamically). Actually there is a third solution that I just thought about but I need to test it first :). Perhaps loading a processor driver will fix this issue (which driver can also perform the hotplug). Perhaps, perhaps not, who are looking into it? I know the problem I don't know solution. Anyway all those solution do not guaranty that we will be able to do cpu hotplug on Windows since we don't yet know what Windows expects. I'm sure we'll be able to eventually. Eventually yes, but can you say now that it will not require DSDT changes or command line parameter? -- 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: CPU hotplug add seems broken
On 01/11/2010 12:53 PM, Gleb Natapov wrote: Anyway all those solution do not guaranty that we will be able to do cpu hotplug on Windows since we don't yet know what Windows expects. I'm sure we'll be able to eventually. Eventually yes, but can you say now that it will not require DSDT changes or command line parameter? No, but I'm not really worried about that. -- 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: CPU hotplug add seems broken
On Mon, Jan 11, 2010 at 12:58:24PM +0200, Avi Kivity wrote: On 01/11/2010 12:53 PM, Gleb Natapov wrote: Anyway all those solution do not guaranty that we will be able to do cpu hotplug on Windows since we don't yet know what Windows expects. I'm sure we'll be able to eventually. Eventually yes, but can you say now that it will not require DSDT changes or command line parameter? No, but I'm not really worried about that. So you want to introduce something that we know upset Windows without looking into alternatives. And as far as I remember upstream position on the UNISYS way was negative, did this change? -- 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: CPU hotplug add seems broken
On 01/11/2010 01:03 PM, Gleb Natapov wrote: No, but I'm not really worried about that. So you want to introduce something that we know upset Windows without looking into alternatives. I don't want to drop support for existing guests unless I have to. And as far as I remember upstream position on the UNISYS way was negative, did this change? I don't see anything fundamentally wrong with the unisys implementation. True, it's not written to any spec, but neither is anything we can come up with (unless we find a spec for cpu hotplug). -- 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
Hang up: qemu-system-ppc creates a ppc VM on a x86_64 host with OS Fedora12.
HI, guys, when qemu-system-ppc creates a f12 ppc VM on a f12 x86_64 host, qemu hangs on the command line of openbios such as: Welcome to OpenBIOS v1.0 built on Dec 7 2009 17:11 0 While qemu creates a RH5.4 ppc VM, the output is such as: cd:0,\ppc\chrp\yaboot.conf: Unknown or corrupt filesystem Can anyone also encounter the same issue or know how to solve it? It will be apprieciated for any help or comment from you. Cheers, Zhiyong Wu -- 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: Hang up: qemu-system-ppc creates a ppc VM on a x86_64 host with OS Fedora12.
Am 11.01.2010 um 12:22 schrieb Zhiyong Wu zwu.ker...@gmail.com: HI, guys, when qemu-system-ppc creates a f12 ppc VM on a f12 x86_64 host, qemu hangs on the command line of openbios such as: Welcome to OpenBIOS v1.0 built on Dec 7 2009 17:11 0 How do you start qemu? To boot from CD you need to pass -boot d. 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: CPU hotplug add seems broken
On Mon, Jan 11, 2010 at 01:06:24PM +0200, Avi Kivity wrote: On 01/11/2010 01:03 PM, Gleb Natapov wrote: No, but I'm not really worried about that. So you want to introduce something that we know upset Windows without looking into alternatives. I don't want to drop support for existing guests unless I have to. Neither do I and I would be happy with what we had if SVVP wouldn't complain. So we need some kind of fix, or exception for the test. And as far as I remember upstream position on the UNISYS way was negative, did this change? I don't see anything fundamentally wrong with the unisys implementation. True, it's not written to any spec, but neither is anything we can come up with (unless we find a spec for cpu hotplug). -- 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: [Qemu-devel] cpuid problem in upstream qemu with kvm
Avi Kivity a...@redhat.com writes: On 01/07/2010 02:33 PM, Anthony Liguori wrote: There's another option. Make cpuid information part of live migration protocol, and then support something like -cpu Xeon-3550. We would remember the exact cpuid mask we present to the guest and then we could validate that we can obtain the same mask on the destination. Currently, our policy is to only migrate dynamic (from the guest's point of view) state, and specify static state on the command line [1]. I think your suggestion makes a lot of sense, but I'd like to expand it to move all guest state, whether dynamic or static. So '-m 1G' would be migrated as well (but not -mem-path). Similarly, in -drive file=...,if=ide,index=1, everything but file=... would be migrated. Becomes a bit clearer with the new way to configure stuff: -drive if=none,id=DRIVE-ID,...--- host, don't migrate -device ide=drive,drive=DRIVE-ID,... --- guest, do migrate [...] -- 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-Bugs-2907597 ] qemu vnc server clips at 2560x1600
On 01/10/2010 10:30 AM, Avi Kivity wrote: On 01/10/2010 06:26 PM, SourceForge.net wrote: Initial Comment: So I am running using the VESA driver to run an Ubuntu 9.10 guest at 2560x1600 (I had to modify the xserver-video-vesa package to remove an internal screen limit of 2048x2048 in the xorg vesa driver) and everything works great except that the qemu vnc server appears to clip at this resolution. The problem goes away if I run 1900x1200 and it doesn't change if I run 16bit depth or 24bit depth. I have attached two screenshots, the first is vncing directly into qemu (which exhibits the problem) and the second is vncing to a vnc server I have running in the guest which doesn't have the problem. I poked around in vnc.c and couldn't see any limits but I feel like its a buffer limit of some kind. Also if you look very closely at the first image you can see that the first row is drawn correctly all the way across but subsequent rows are not. If you need more information doesn't hesitate to ask. Anthony, can you take a look at this? Seems like a serious issue, could find nothing obvious in vnc.c. VNC_MAX_WIDTH and VNC_MAX_HEIGHT in vnc.h are currently defined to 2048. We do dirty tracking with a bitmap and that bitmap is currently a fixed size. 2048 is bigger than any physical screen that I know of so I assume this is a multiple monitor scenario. Long term, I think exposing multiple monitors to the guest is a better approach for this kind of functionality. Since these resolutions for a single screen don't really exist, this is largely an untested path within the guest. 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: CPU hotplug add seems broken
On 01/11/2010 04:50 AM, Avi Kivity wrote: On 01/11/2010 12:42 PM, Gleb Natapov wrote: That cool, but SVVP complains. What's the complaint? Maybe we can fix it instead of rewriting things. https://bugzilla.redhat.com/show_bug.cgi?id=49584://bugzilla.redhat.com/show_bug.cgi?id=495844 Hope it accessible to everyone but if not SVVP complains: Run Signed Driver check of SVVP testing, the (Qemu virtual CPU verison 0.9.1) has error. The only why to fix it that I can see is to not present disabled MADT entries for Windows and that will require us to provide some kind of flag to QEMU. The cleanest way is to create disabled MADT entries only if max-cpus != startup cpus and run Windows only with max-cpus == startup cpus. The problem is 1) you have to know what is your guest at startup time 2) will require creation of SSDT for Processors() on the fly (or precompile them for every value of max-cpus and load dynamically). Actually there is a third solution that I just thought about but I need to test it first :). Perhaps loading a processor driver will fix this issue (which driver can also perform the hotplug). Anyway all those solution do not guaranty that we will be able to do cpu hotplug on Windows since we don't yet know what Windows expects. I'm sure we'll be able to eventually. win2k8 supports CPU hotplug with VMware. I'd suggest someone fire up VMware and dump the ACPI tables to try and see how they're doing it. Otherwise, if someone has a physical machine that is known to do CPU hotplug with win2k8, an acpi dump would be useful there. I think it's easier to make sure Linux works with what Windows currently supports than vice versa. 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: [ kvm-Bugs-2907597 ] qemu vnc server clips at 2560x1600
On 01/11/2010 03:53 PM, Anthony Liguori wrote: Anthony, can you take a look at this? Seems like a serious issue, could find nothing obvious in vnc.c. VNC_MAX_WIDTH and VNC_MAX_HEIGHT in vnc.h are currently defined to 2048. We do dirty tracking with a bitmap and that bitmap is currently a fixed size. 2048 is bigger than any physical screen that I know of so I assume this is a multiple monitor scenario. Long term, I think exposing multiple monitors to the guest is a better approach for this kind of functionality. Since these resolutions for a single screen don't really exist, this is largely an untested path within the guest. Google suggests such screens do exist, and -vga std (at least in qemu-kvm) supports them. I've asked the reporter to play with VNC_MAX_WIDTH. -- 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: CPU hotplug add seems broken
On 01/11/2010 03:57 PM, Anthony Liguori wrote: win2k8 supports CPU hotplug with VMware. I'd suggest someone fire up VMware and dump the ACPI tables to try and see how they're doing it. Otherwise, if someone has a physical machine that is known to do CPU hotplug with win2k8, an acpi dump would be useful there. I think it's easier to make sure Linux works with what Windows currently supports than vice versa. Gleb found some presentation that describes Windows cpu hotplug as something very similar to what we do today, so hopefully the whole issue is just a bug or missing feature in the implementation. -- 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
Ubuntu 8.04 LTS guest running slowly
Hello: I am trying to install an Ubuntu 8.04 LTS guest on my CentOS 5.4 server running KVM. If I use the accelerate option to virt-install, the guest crashes during the install. If I add model type='virtio'/ to the XML configuration file after installing, the system locks at times when it is accessing the network. I ran the same guest on Xen and it runs very fast. Any suggestions on how to fix this? Thanks, Neil -- Neil Aggarwal, (281)846-8957, http://UnmeteredVPS.net Host Joomla!, Wordpress, phpBB, or vBulletin for $25/mo Unmetered bandwidth = no overage charges, 7 day free trial -- 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
MS Window virtio drivers certification status
Hi, I'm looking to find some information about the current status of the Windows virtio drivers. Are they certified by Microsoft? Is there a timeline for this? Will the drivers be included in future MS operating system DVD distribution? Thanks, Saul -- 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: Ubuntu 8.04 LTS guest running slowly
On 01/11/2010 04:46 PM, Neil Aggarwal wrote: Hello: I am trying to install an Ubuntu 8.04 LTS guest on my CentOS 5.4 server running KVM. If I use the accelerate option to virt-install, the guest crashes during the install. Well, without kvm it will definitely run slowly. I think the install problem is due to the grub splash screen, if you disable that the install should proceed. If I addmodel type='virtio'/ to the XML configuration file after installing, the system locks at times when it is accessing the network. What kernel does the guest use? -- 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: Ubuntu 8.04 LTS guest running slowly
Avi: I think the install problem is due to the grub splash screen, if you disable that the install should proceed. What kernel does the guest use? I am running the TunkeyLinux LAMP appliance found here: http://www.turnkeylinux.org/lamp I downloaded the ISO file from the web site. Then, I used this command to intall it: virt-install -n v1067 -r 512 --vcpus=1 --os-type=linux --os-variant=ubuntuhardy -v --accelerate -c /tmp/turnkey-lamp-2009.10-hardy-x86.iso -f /var/lib/libvirt/images/v1067.img -s 15 -b br0 --vnc --noautoconsole When I connect to the VNC console, I get the Turnkey linux options screen. I select Install to hard disk from there and it seems to start the install but crashes during the installer startup. If I install it without the accelerate option, it installs, but runs very slowly. When I login to the server and run uname -a, I get this back: Linux lamp 2.6.24-24-generic #1 SMP Sat Aug 22 01:06:14 UTC 2009 i686 GNU/Linux Any ideas? Thanks, Neil -- Neil Aggarwal, (281)846-8957, http://UnmeteredVPS.net CentOS 5.4 VPS with unmetered bandwidth only $25/month! No overage charges, 7 day free trial, PayPal, Google Checkout -- 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
[ANNOUNCE] kvm-kmod-2.6.32.3
Yet another update of the current kvm-kmod stable series. It pulls in the kernel changes between 2.6.32.2 and 2.6.32.3. Find this new version at: https://sourceforge.net/projects/kvm/files/kvm-kmod/2.6.32.2/kvm-kmod-2.6.32.3.tar.bz2/download KVM changes since kvm-kmod-2.6.32.2: - LAPIC: make sure IRR bitmap is scanned after vm load (fixes migration issues) - MMU: remove prefault from invlpg handler (unbreaks Windows 2008 R2) -- 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: Ubuntu 8.04 LTS guest running slowly
Avi: Here is something strange: I was testing the command I used to see if I could identify where the crash occurred. I did a virsh destroy and virsh undefine on the guest and issued the command to install it with the accelerate option. The installation was fast and ran through the entire install perfectly. I then destroyed the guest, undefined the guest, and removed the disk file for it. After that, I tried an install with the accelerate option and it crashed. It seems to have something to do with the disk file being present. I am testing to see if this is repeatable. If so, there has to be a way to debug it. Any ideas/suggestions? Thanks, Neil -- Neil Aggarwal, (281)846-8957, http://UnmeteredVPS.net CentOS 5.4 VPS with unmetered bandwidth only $25/month! No overage charges, 7 day free trial, PayPal, Google Checkout -Original Message- From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf Of Neil Aggarwal Sent: Monday, January 11, 2010 9:04 AM To: kvm@vger.kernel.org Subject: RE: Ubuntu 8.04 LTS guest running slowly Avi: I think the install problem is due to the grub splash screen, if you disable that the install should proceed. What kernel does the guest use? I am running the TunkeyLinux LAMP appliance found here: http://www.turnkeylinux.org/lamp I downloaded the ISO file from the web site. Then, I used this command to intall it: virt-install -n v1067 -r 512 --vcpus=1 --os-type=linux --os-variant=ubuntuhardy -v --accelerate -c /tmp/turnkey-lamp-2009.10-hardy-x86.iso -f /var/lib/libvirt/images/v1067.img -s 15 -b br0 --vnc --noautoconsole When I connect to the VNC console, I get the Turnkey linux options screen. I select Install to hard disk from there and it seems to start the install but crashes during the installer startup. If I install it without the accelerate option, it installs, but runs very slowly. When I login to the server and run uname -a, I get this back: Linux lamp 2.6.24-24-generic #1 SMP Sat Aug 22 01:06:14 UTC 2009 i686 GNU/Linux Any ideas? Thanks, Neil -- Neil Aggarwal, (281)846-8957, http://UnmeteredVPS.net CentOS 5.4 VPS with unmetered bandwidth only $25/month! No overage charges, 7 day free trial, PayPal, Google Checkout -- 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 -- 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: New kvm-related qemu patch queue
On 01/10/2010 06:02 AM, Avi Kivity wrote: In order to improve qemu.git kvm integration quality wrt performance, features, and reliability Marcelo and I will begin to maintain a patch queue based on qemu.git containing kvm-related patches. We will review and apply patches to this queue, test them using the same test suite that is used for qemu-kvm.git, and regularly submit them for inclusion in qemu.git, mimicking the relationship between kvm.git and Linus' linux-2.6.git. Thanks for setting this up Avi! I just want to stress that everyone continue CC'ing qemu-devel on all KVM patches. Even if the patch is qemu-kvm specific for the moment, I think it's important for qemu-devel to be exposed to the refactoring work. It might be good to prefix qemu-kvm.git patches in some manner to make it clear which repository they belong to. 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: MS Window virtio drivers certification status
-Original Message- From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf Of Saul Tamari Sent: Monday, January 11, 2010 4:50 PM To: kvm Subject: MS Window virtio drivers certification status Hi, I'm looking to find some information about the current status of the Windows virtio drivers. Are they certified by Microsoft? [YV] Drivers that were released with RHEL 5.4 are certified by MS for Windows XP, Windows 2003, Windows 2008 and Window 2008 R2. Drivers that will be released with RHEL 5.5 will also include Windows 7 certification. Is there a timeline for this? [YV] We are also working to push certified drivers as part of Fedora 13. Will the drivers be included in future MS operating system DVD distribution? [YV] No timeline for this. We definitely would like this to happen, but the process is in its beginning. Some additional comments regarding MS certification (might be different from things accustomed in open source community): Driver certification is per specific binary and not for the code base. So there is specific binary version of the driver that got MS certification. Thanks, Saul -- 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 -- 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: Ubuntu 8.04 LTS guest running slowly
Avi: It seems to have something to do with the disk file being present. Unfortunately, it crashed when I tried to do an install this time, even with the disk file present. It must have been a fluke. When I look at the screen, it seems to be crashing at the same point in the installation process which looks to be right after it prints a message about input4. Looking at dmesg on the running system, I see these lines: [218721.046402] input: ImExPS/2 Generic Explorer Mouse as /devices/platform/i8042/serio1/input/input4 [218722.372199] Adding 706820k swap on /dev/sda5. Priority:-1 extents:1 across:706820k [218722.446108] EXT3 FS on sda1, internal journal [218723.218838] NET: Registered protocol family 10 [218723.219309] lo: Disabled Privacy Extensions [218733.554734] eth0: no IPv6 routers present [218760.283624] eth0: link up, 100Mbps, full-duplex, lpa 0x05E1 [218770.434167] eth0: no IPv6 routers present [218932.632286] Clocksource tsc unstable (delta = -135864080 ns) [218932.708238] Time: acpi_pm clocksource has been installed. The next line after input4 is setting up swap on the disk. Again, this seems to be related to disk. The crash is repeatable. There has to be a way to diagnose it. Is there any way to get more information on what happened so we can debug it? Thanks, Neil -- Neil Aggarwal, (281)846-8957, http://UnmeteredVPS.net CentOS 5.4 VPS with unmetered bandwidth only $25/month! No overage charges, 7 day free trial, PayPal, Google Checkout -- 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
Install a new guest remotely?
Hello I am going crazy trying to figure out a way to do a fedora install on our kvm server... Ubuntu installs are easy I dont need X, but fedora is a pain I'm using virt-install but I need X installed, we do not install X on our servers at all, and will rather not to. So can I do this remotely from my linux desktop with X? if so do I need to mount a partition on both the host and my desktop computer? I have try to do a remote install but keeps complaining about the storage place.. PS: any way to do a fedora12 install with out a stupid GUI? Thanks Chris F. -- 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
[ kvm-Bugs-2907597 ] qemu vnc server clips at 2560x1600
Bugs item #2907597, was opened at 2009-12-02 16:57 Message generated for change (Settings changed) made by mcsoccer You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2907597group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: qemu Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matthew Colyer (mcsoccer) Assigned to: Nobody/Anonymous (nobody) Summary: qemu vnc server clips at 2560x1600 Initial Comment: So I am running using the VESA driver to run an Ubuntu 9.10 guest at 2560x1600 (I had to modify the xserver-video-vesa package to remove an internal screen limit of 2048x2048 in the xorg vesa driver) and everything works great except that the qemu vnc server appears to clip at this resolution. The problem goes away if I run 1900x1200 and it doesn't change if I run 16bit depth or 24bit depth. I have attached two screenshots, the first is vncing directly into qemu (which exhibits the problem) and the second is vncing to a vnc server I have running in the guest which doesn't have the problem. I poked around in vnc.c and couldn't see any limits but I feel like its a buffer limit of some kind. Also if you look very closely at the first image you can see that the first row is drawn correctly all the way across but subsequent rows are not. If you need more information doesn't hesitate to ask. -- Comment By: Matthew Colyer (mcsoccer) Date: 2010-01-11 16:17 Message: Changing VNC_MAX_WIDTH to 2560 works. Thanks for figuring that out, would you be able to commit that change? -- Comment By: Avi Kivity (avik) Date: 2010-01-11 10:19 Message: Can you try changing VNC_MAX_WIDTH in vnc.h? -- Comment By: Avi Kivity (avik) Date: 2010-01-10 16:26 Message: Confirmed with vncviewer and vinagre, so unlikely to be a client problem. -- Comment By: Avi Kivity (avik) Date: 2010-01-10 14:17 Message: The cropping is 512 pixels wide, the correct area is 2048 pixels wide, so it does look like some kind of limit. -- Comment By: SourceForge Robot (sf-robot) Date: 2009-12-28 02:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). -- Comment By: Matthew Colyer (mcsoccer) Date: 2009-12-17 03:18 Message: The blocks do not show up when run in SDL mode. So I believe the problem is still somehow related to the VNC server. -- Comment By: Avi Kivity (avik) Date: 2009-12-13 10:29 Message: Does it work well with SDL? Maybe the problem is not vnc related. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2907597group_id=180599 -- 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: Install a new guest remotely?
Hello: is a pain I'm using virt-install but I need X installed, we do not install X on our servers at all, and will rather not to. So can I do Our KVM servers are remote and do not have X installed. When we install a guest, we tell it to use vnc by adding --vnc --noautoconsole to the virt-install command. Then use virsh vncdisplay to get the port on the server to connect your VNC viewer. We use an SSH tunnel for the connection to ensure security. Neil -- Neil Aggarwal, (281)846-8957, http://UnmeteredVPS.net CentOS 5.4 VPS with unmetered bandwidth only $25/month! No overage charges, 7 day free trial, PayPal, Google Checkout -- 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-Bugs-2907597 ] qemu vnc server clips at 2560x1600
On 01/11/2010 04:30 PM, Avi Kivity wrote: VNC_MAX_WIDTH and VNC_MAX_HEIGHT in vnc.h are currently defined to 2048. We do dirty tracking with a bitmap and that bitmap is currently a fixed size. 2048 is bigger than any physical screen that I know of so I assume this is a multiple monitor scenario. Long term, I think exposing multiple monitors to the guest is a better approach for this kind of functionality. Since these resolutions for a single screen don't really exist, this is largely an untested path within the guest. Google suggests such screens do exist, and -vga std (at least in qemu-kvm) supports them. I've asked the reporter to play with VNC_MAX_WIDTH. The reporter confirms that increasing V_M_W fixes the problem. -- 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: MS Window virtio drivers certification status
Hi, Are you talking about both network block drivers? Thanks, Saul On Mon, Jan 11, 2010 at 5:49 PM, Yan Vugenfirer yvuge...@redhat.com wrote: -Original Message- From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf Of Saul Tamari Sent: Monday, January 11, 2010 4:50 PM To: kvm Subject: MS Window virtio drivers certification status Hi, I'm looking to find some information about the current status of the Windows virtio drivers. Are they certified by Microsoft? [YV] Drivers that were released with RHEL 5.4 are certified by MS for Windows XP, Windows 2003, Windows 2008 and Window 2008 R2. Drivers that will be released with RHEL 5.5 will also include Windows 7 certification. Is there a timeline for this? [YV] We are also working to push certified drivers as part of Fedora 13. Will the drivers be included in future MS operating system DVD distribution? [YV] No timeline for this. We definitely would like this to happen, but the process is in its beginning. Some additional comments regarding MS certification (might be different from things accustomed in open source community): Driver certification is per specific binary and not for the code base. So there is specific binary version of the driver that got MS certification. Thanks, Saul -- 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 -- 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: Install a new guest remotely?
On Mon, Jan 11, 2010 at 10:20:02AM -0600, Neil Aggarwal wrote: Hello: is a pain I'm using virt-install but I need X installed, we do not install X on our servers at all, and will rather not to. So can I do Our KVM servers are remote and do not have X installed. When we install a guest, we tell it to use vnc by adding --vnc --noautoconsole to the virt-install command. Yep, that is the best way to run virt-install on a head-less machine Then use virsh vncdisplay to get the port on the server to connect your VNC viewer. We use an SSH tunnel for the connection to ensure security. You can also use virt-viewer to automate that bit of the process virt-viewer --connect qemu+ssh://r...@servername/system GUESTNAME and virt-viewer will connect to libvirt on the remote host, query the VNC port and setup an SSH tunnel for the VNC connection. It is essentially a VNC client that knows about libvirt. It can do TLS or SASL security instead of SSH tunnels too if desired Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- 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: Install a new guest remotely?
Then use virsh vncdisplay to get the port on the server to
connect
your VNC viewer. We use an SSH tunnel for the connection to
ensure
security.
Neil
ok so I must to be doing something wrong..
here is my line:
virt-install --connect qemu:///system -n fedora_core12 -r 1048576
--vcpus=2 -f /var/kvm_image
s_local/fedora_core12.qcow2 -s 20 -c ~/Fedora-12-x86_64-netinst.iso
--os-type linux --acce
lerate --vnc --noautoconsole --network=bridge:br0 --hvm
then I get:
Starting install...
monitor socket did not show up.: Connection refused
Domain installation may not have been
successful. If it was, you can restart your domain
by running 'virsh start fedora_core12'; otherwise, please
restart your installation.
ERRORmonitor socket did not show up.: Connection refused
Traceback (most recent call last):
File /usr/bin/virt-install, line 780, in module
main()
File /usr/bin/virt-install, line 678, in main
start_time, guest.start_install)
File /usr/bin/virt-install, line 733, in do_install
dom = install_func(conscb, progresscb, wait=(not wait))
File /usr/lib/python2.6/dist-packages/virtinst/Guest.py, line 541,
in start_install
return self._do_install(consolecb, meter, removeOld, wait)
File /usr/lib/python2.6/dist-packages/virtinst/Guest.py, line 633,
in _do_install
self.domain = self.conn.createLinux(install_xml, 0)
File /usr/lib/python2.6/dist-packages/libvirt.py, line 1077, in
createLinux
if ret is None:raise libvirtError('virDomainCreateLinux() failed',
conn=self)
libvirtError: monitor socket did not show up.: Connection refused
Thanks.
--
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: Install a new guest remotely?
On Mon, Jan 11, 2010 at 11:37:25AM -0500, rek2 wrote: Then use virsh vncdisplay to get the port on the server to connect your VNC viewer. We use an SSH tunnel for the connection to ensure security. Neil ok so I must to be doing something wrong.. here is my line: virt-install --connect qemu:///system -n fedora_core12 -r 1048576 --vcpus=2 -f /var/kvm_image s_local/fedora_core12.qcow2 -s 20 -c ~/Fedora-12-x86_64-netinst.iso --os-type linux --acce lerate --vnc --noautoconsole --network=bridge:br0 --hvm then I get: Starting install... monitor socket did not show up.: Connection refused Domain installation may not have been successful. If it was, you can restart your domain by running 'virsh start fedora_core12'; otherwise, please restart your installation. [snip] libvirtError: monitor socket did not show up.: Connection refused This all basically says the KVM guest failed to start. Check the log file in /var/log/libvirt/qemu/$NAME.log for possible further details Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- 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: MS Window virtio drivers certification status
-Original Message- From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf Of Saul Tamari Sent: Monday, January 11, 2010 6:26 PM To: Yan Vugenfirer Cc: kvm Subject: Re: MS Window virtio drivers certification status Hi, Are you talking about both network block drivers? [YV] Yes. Only difference for block - Windows XP certified driver wasn't release with RHEL5.4. It should be in RHEL 5.5. Thanks, Saul On Mon, Jan 11, 2010 at 5:49 PM, Yan Vugenfirer yvuge...@redhat.com wrote: -Original Message- From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf Of Saul Tamari Sent: Monday, January 11, 2010 4:50 PM To: kvm Subject: MS Window virtio drivers certification status Hi, I'm looking to find some information about the current status of the Windows virtio drivers. Are they certified by Microsoft? [YV] Drivers that were released with RHEL 5.4 are certified by MS for Windows XP, Windows 2003, Windows 2008 and Window 2008 R2. Drivers that will be released with RHEL 5.5 will also include Windows 7 certification. Is there a timeline for this? [YV] We are also working to push certified drivers as part of Fedora 13. Will the drivers be included in future MS operating system DVD distribution? [YV] No timeline for this. We definitely would like this to happen, but the process is in its beginning. Some additional comments regarding MS certification (might be different from things accustomed in open source community): Driver certification is per specific binary and not for the code base. So there is specific binary version of the driver that got MS certification. Thanks, Saul -- 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 -- 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 -- 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: Install a new guest remotely?
libvirtError: monitor socket did not show up.: Connection refused This all basically says the KVM guest failed to start. Check the log file in /var/log/libvirt/qemu/$NAME.log for possible further details Regards, Daniel Thanks but this is the only info I got in the log cat fedora_core12.log LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin /usr/bin/kvm -S -M pc-0.11 -m 1048576 -smp 2 -name fedora_core12 -uuid f1038428-1cda-764b-f35c-f5270f8022cb -monitor unix:/var/run/libvirt/qemu/fedora_core12.monitor,server,nowait -no-reboot -boot d -drive file=/var/kvm_images_local/fedora_core12.qcow2,if=ide,index=0 -drive file=/root/Fedora-12-x86_64-netinst.iso,if=ide,media=cdrom,index=2 -net nic,macaddr=54:52:00:03:63:c4,vlan=0,name=nic.0 -net tap,fd=19,vlan=0,name=tap.0 -serial pty -parallel none -usb -vnc 127.0.0.1:4 -k en-us -vga cirrus char device redirected to /dev/pts/5 -- 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: Install a new guest remotely?
Thanks but this is the only info I got in the log cat fedora_core12.log LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin /usr/bin/kvm -S -M pc-0.11 -m 1048576 -smp 2 -name fedora_core12 -uuid f1038428-1cda-764b-f35c-f5270f8022cb -monitor unix:/var/run/libvirt/qemu/fedora_core12.monitor,server,nowait -no-reboot -boot d -drive file=/var/kvm_images_local/fedora_core12.qcow2,if=ide,index=0 -drive file=/root/Fedora-12-x86_64-netinst.iso,if=ide,media=cdrom,index=2 -net nic,macaddr=54:52:00:03:63:c4,vlan=0,name=nic.0 -net tap,fd=19,vlan=0,name=tap.0 -serial pty -parallel none -usb -vnc 127.0.0.1:4 -k en-us -vga cirrus char device redirected to /dev/pts/5 -- 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 ok found this on syslog qemudDomainLookupByName:2677 : Domain not found: no domain with matching name 'fedora_core12' I have 4 guest running on this server with no issues why is telling me it cant find a domain? -- 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: Install a new guest remotely?
ok so I must to be doing something wrong.. here is my line: virt-install --connect qemu:///system -n fedora_core12 -r 1048576 --vcpus=2 -f /var/kvm_images_local/fedora_core12.qcow2 -s 20 -c ~/Fedora-12-x86_64-netinst.iso --os-type linux --accelerate --vnc --noautoconsole --network=bridge:br0 --hvm I dont know about the command you are using. I usually use a command like this: virt-install -n v1067 -r 512 --vcpus=1 --os-type=linux --os-variant=ubuntuhardy -v --accelerate -c /tmp/turnkey-lamp-2009.10-hardy-x86.iso -f /var/lib/libvirt/images/v1067.img -s 15 -b br0 --vnc --noautoconsole Also, if I understand correctly, the -r command is in megabytes so you are allocating a very large amount of ram to your guest. Neil -- Neil Aggarwal, (281)846-8957, http://UnmeteredVPS.net http://unmeteredvps.net/ Host Joomla!, Wordpress, phpBB, or vBulletin for $25/mo Unmetered bandwidth = no overage charges, 7 day free trial -- 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
KVM: fix S390/IA-64 build failures introduced by memslot changes
Fix build failures introduced by memslot changes.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/arch/ia64/kvm/kvm-ia64.c b/arch/ia64/kvm/kvm-ia64.c
index b10f2ef..e6ac549 100644
--- a/arch/ia64/kvm/kvm-ia64.c
+++ b/arch/ia64/kvm/kvm-ia64.c
@@ -1374,12 +1374,14 @@ static void free_kvm(struct kvm *kvm)
static void kvm_release_vm_pages(struct kvm *kvm)
{
+ struct kvm_memslots *slots;
struct kvm_memory_slot *memslot;
int i, j;
unsigned long base_gfn;
- for (i = 0; i kvm-nmemslots; i++) {
- memslot = kvm-memslots[i];
+ slots = rcu_dereference(kvm-memslots);
+ for (i = 0; i slots-nmemslots; i++) {
+ memslot = slots-memslots[i];
base_gfn = memslot-base_gfn;
for (j = 0; j memslot-npages; j++) {
@@ -1576,6 +1578,7 @@ out:
int kvm_arch_prepare_memory_region(struct kvm *kvm,
struct kvm_memory_slot *memslot,
struct kvm_memory_slot old,
+ struct kvm_userspace_memory_region *mem,
int user_alloc)
{
unsigned long i;
@@ -1806,7 +1809,7 @@ static int kvm_ia64_sync_dirty_log(struct kvm *kvm,
if (log-slot = KVM_MEMORY_SLOTS)
goto out;
- memslot = kvm-memslots[log-slot];
+ memslot = kvm-memslots-memslots[log-slot];
r = -ENOENT;
if (!memslot-dirty_bitmap)
goto out;
@@ -1845,7 +1848,7 @@ int kvm_vm_ioctl_get_dirty_log(struct kvm *kvm,
/* If nothing is dirty, don't bother messing with page tables. */
if (is_dirty) {
kvm_flush_remote_tlbs(kvm);
- memslot = kvm-memslots[log-slot];
+ memslot = kvm-memslots-memslots[log-slot];
n = ALIGN(memslot-npages, BITS_PER_LONG) / 8;
memset(memslot-dirty_bitmap, 0, n);
}
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 5ba1865..4633e78 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -168,6 +168,7 @@ long kvm_arch_dev_ioctl(struct file *filp,
int kvm_arch_prepare_memory_region(struct kvm *kvm,
struct kvm_memory_slot *memslot,
struct kvm_memory_slot old,
+ struct kvm_userspace_memory_region *mem,
int user_alloc)
{
return 0;
diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
index f6bbd45..8bedd31 100644
--- a/arch/s390/kvm/kvm-s390.c
+++ b/arch/s390/kvm/kvm-s390.c
@@ -690,13 +690,11 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
/* Section: memory related */
int kvm_arch_prepare_memory_region(struct kvm *kvm,
- struct kvm_userspace_memory_region *mem,
+ struct kvm_memory_slot *memslot,
struct kvm_memory_slot old,
+ struct kvm_userspace_memory_region *mem,
int user_alloc)
{
- int i;
- struct kvm_vcpu *vcpu;
-
/* A few sanity checks. We can have exactly one memory slot which has
to start at guest virtual zero and which has to be located at a
page boundary in userland and which has to end at a page boundary.
@@ -722,11 +720,14 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
return 0;
}
-int kvm_arch_commit_memory_region(struct kvm *kvm,
+void kvm_arch_commit_memory_region(struct kvm *kvm,
struct kvm_userspace_memory_region *mem,
struct kvm_memory_slot old,
int user_alloc)
{
+ int i;
+ struct kvm_vcpu *vcpu;
+
/* request update of sie control block for all available vcpus */
kvm_for_each_vcpu(i, vcpu, kvm) {
if (test_and_set_bit(KVM_REQ_MMU_RELOAD, vcpu-requests))
diff --git a/arch/s390/kvm/kvm-s390.h b/arch/s390/kvm/kvm-s390.h
index 46777ff..60f09ab 100644
--- a/arch/s390/kvm/kvm-s390.h
+++ b/arch/s390/kvm/kvm-s390.h
@@ -69,7 +69,7 @@ static inline void kvm_s390_vcpu_set_mem(struct kvm_vcpu
*vcpu)
{
int idx;
struct kvm_memory_slot *mem;
- struct kvm_memory_slots *memslots;
+ struct kvm_memslots *memslots;
idx = srcu_read_lock(vcpu-kvm-srcu);
memslots = rcu_dereference(vcpu-kvm-memslots);
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 6811e5e..915a826 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -5313,6 +5313,7 @@ void kvm_arch_destroy_vm(struct kvm *kvm)
int kvm_arch_prepare_memory_region(struct kvm *kvm,
struct kvm_memory_slot *memslot,
struct kvm_memory_slot old,
+ struct kvm_userspace_memory_region *mem,
int user_alloc)
{
int
Re: Install a new guest remotely?
86.iso -f /var/lib/libvirt/images/v1067.img -s 15 -b br0 --vnc --noautoconsole Also, if I understand correctly, the -r command is in megabytes so you are allocating a very large amount of ram to your guest. Neil you got it!!! it was the ram.. thanks so much: Domain installation still in progress. You can reconnect to the console to complete the installation process. so now I can use virt-viewer --connect qemu+ssh://r...@servername/system GUESTNAME going to try this. thanks again -- 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
[PATCH][STABLE-0.12] qemu-kvm: Disable cpu_set command to avoid segfault
CPU hotplug feature is lost in this version. Even worse cpu_set qemu command may cause segfault. This patch fix the problem by just disabling it. It is enough for the stable branch. Signed-off-by: Ryota Ozaki ozaki.ry...@gmail.com Cc: Gleb Natapov g...@redhat.com --- monitor.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/monitor.c b/monitor.c index 6ff6e1f..4b566d2 100644 --- a/monitor.c +++ b/monitor.c @@ -829,7 +829,9 @@ static void do_cpu_set_nr(Monitor *mon, const QDict *qdict) return; } #if defined(TARGET_I386) || defined(TARGET_X86_64) -qemu_system_cpu_hot_add(value, state); +//qemu_system_cpu_hot_add(value, state); +monitor_printf(mon, The feature is not avaiable in this version. +It will be back in a future version.\n); #endif } -- 1.6.5.2 -- 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: Install a new guest remotely?
rek2 r...@binaryfreedom.info : I have 4 guest running on this server with no issues why is telling me it cant find a domain? virsh list --all -- Architecte Informatique chez Blueline/Gulfsat: Administration Systeme, Recherche Developpement +261 34 29 155 34 / +261 33 11 207 36 -- 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 2/2] virtio_net: Defer skb allocation in receive path
On Mon, 2010-01-04 at 23:14 +0200, Michael S. Tsirkin wrote: so it will never return NULL unless no more buffers? breaking here ad BUG_ON(vi-num) as Amit suggests seems cleaner than looping forever if there's a bug. Agree. I will change to break as Amit suggested and put BUG_ON and resubmit the patch. Thanks Shirley -- 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 0/2] eventfd: new EFD_STATE flag
On Mon, 11 Jan 2010, Michael S. Tsirkin wrote: Yes, I think this will work. Will test and report. Thanks! If you ever happen to find a solution in KVM that does not require eventfd changes, that'd be even better :) Otherwise ping me when you tested, that I'll puch this to Andrew. - Davide -- 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 0/2] eventfd: new EFD_STATE flag
On Mon, Jan 11, 2010 at 11:14:14AM -0800, Davide Libenzi wrote: On Mon, 11 Jan 2010, Michael S. Tsirkin wrote: Yes, I think this will work. Will test and report. Thanks! If you ever happen to find a solution in KVM that does not require eventfd changes, that'd be even better :) Otherwise ping me when you tested, that I'll puch this to Andrew. - Davide Hmm, the fix also needs changes in kvm driver to call the new API. To simplify dependencies, can we merge this patch through Avi's kvm tree as well? -- 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] [PATCHv2] Add KVM paravirt cpuid leaf
On 01/07/2010 10:24 AM, Gleb Natapov wrote: diff --git a/target-i386/kvm.c b/target-i386/kvm.c index 4084503..6a841de 100644 --- a/target-i386/kvm.c +++ b/target-i386/kvm.c @@ -17,6 +17,7 @@ #includesys/mman.h #includelinux/kvm.h +#includelinux/kvm_para.h This breaks the build on a default F12 install because while kvm.h is present, kvm_para.h is not. This is a hard one to fix. We can default the kvm search path to /lib/modules/$(uname -r)/build, we can fix the glibc headers and live with it, or we can pull in the kvm headers into qemu. Avi/Marcelo/Jan, any thoughts from the qemu-kvm side? 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: MS Window virtio drivers certification status
2010/1/11 Yan Vugenfirer yvuge...@redhat.com: -Original Message- From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf Of Saul Tamari Sent: Monday, January 11, 2010 6:26 PM To: Yan Vugenfirer Cc: kvm Subject: Re: MS Window virtio drivers certification status Hi, Are you talking about both network block drivers? [YV] Yes. Only difference for block - Windows XP certified driver wasn't release with RHEL5.4. It should be in RHEL 5.5. Will these block drivers for XP be optimized in terms of performance or will they, like the current ones, still be slower than the regular IDE emulated block devices? [1] [1] http://article.gmane.org/gmane.comp.emulators.kvm.devel/40762 Best Regards Kenni -- 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
