RE: [PATCH] qemu-kvm: fix unmatched RAM alloction/free
-Original Message- From: Michael Tokarev [mailto:m...@tls.msk.ru] Sent: Wednesday, May 29, 2013 2:34 AM To: Hao, Xudong Cc: kvm@vger.kernel.org; g...@redhat.com; pbonz...@redhat.com; qemu-de...@nongnu.org Subject: Re: [PATCH] qemu-kvm: fix unmatched RAM alloction/free Um, something's wrong with the Date. Care to resend with that fixed? Because the similar fix are already in qemu upstream, seems we need not this patch longer. Thanks, /mjt 18.01.2009 02:13, Xudong Hao wrote: mmap is used in qemu_vmalloc function instead of qemu_memalign(commit 7dda5dc8), so it should change qemu_vfree to munmap to fix a unmatched issue. [...] -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] qemu-kvm: fix unmatched RAM alloction/free
-Original Message-
From: Paolo Bonzini [mailto:pbonz...@redhat.com]
Sent: Friday, May 24, 2013 1:13 AM
To: Hao, Xudong
Cc: kvm@vger.kernel.org; g...@redhat.com; qemu-de...@nongnu.org
Subject: Re: [PATCH] qemu-kvm: fix unmatched RAM alloction/free
mmap is used in qemu_vmalloc function instead of qemu_memalign(commit
7dda5dc8), so it should change qemu_vfree to munmap to fix a unmatched
issue.
This issue appears when a PCI device is being assigned to KVM guest,
failure to read PCI rom file will bring RAM free, then the incorrect
qemu_vfree calling will cause a segment fault.
Signed-off-by: Xudong Hao xudong@intel.com
---
exec.c |6 +-
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/exec.c b/exec.c
index fa1e0c3..d40d237 100644
--- a/exec.c
+++ b/exec.c
@@ -1152,15 +1152,11 @@ void qemu_ram_free(ram_addr_t addr)
abort();
#endif
} else {
-#if defined(TARGET_S390X) defined(CONFIG_KVM)
-munmap(block-host, block-length);
-#else
if (xen_enabled()) {
xen_invalidate_map_cache_entry(block-host);
} else {
-qemu_vfree(block-host);
+munmap(block-host, block-length);
}
-#endif
}
g_free(block);
break;
Just git pull. :) This is very similar to commit e7a09b9 (osdep: introduce
qemu_anon_ram_free to free qemu_anon_ram_alloc-ed memory, 2013-05-13)
OK, this commit do the same thing as my patch, I did not notice qemu upstream
tree, just take a look at qemu-kvm tree, but I think this commit should be
backport to qemu-kvm tree, because many user are using qemu-kvm for KVM.
Anyway please ignore this patch.
Thanks,
-Xudong
N�r��yb�X��ǧv�^�){.n�+h����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?��)ߢf
RE: [PATCH v2] qemu-kvm/pci-assign: 64 bits bar emulation
-Original Message-
From: Alex Williamson [mailto:alex.william...@redhat.com]
Sent: Thursday, December 20, 2012 12:06 AM
To: Hao, Xudong
Cc: qemu-de...@nongnu.org; mtosa...@redhat.com; g...@redhat.com;
kvm@vger.kernel.org
Subject: Re: [PATCH v2] qemu-kvm/pci-assign: 64 bits bar emulation
On Wed, 2012-12-19 at 16:47 +0800, Xudong Hao wrote:
Enable 64 bits bar emulation.
v2 changes from v1:
- Change 0lx% to 0x%016 when print a 64 bit variable.
Test pass with the current seabios which already support 64bit pci bars.
Signed-off-by: Xudong Hao xudong@intel.com
---
hw/kvm/pci-assign.c | 22 ++
1 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/hw/kvm/pci-assign.c b/hw/kvm/pci-assign.c
index 7a0998c..fb58ca9 100644
--- a/hw/kvm/pci-assign.c
+++ b/hw/kvm/pci-assign.c
@@ -46,6 +46,7 @@
#define IORESOURCE_IRQ 0x0400
#define IORESOURCE_DMA 0x0800
#define IORESOURCE_PREFETCH 0x2000 /* No side effects */
+#define IORESOURCE_MEM_64 0x0010
//#define DEVICE_ASSIGNMENT_DEBUG
@@ -442,9 +443,13 @@ static int assigned_dev_register_regions(PCIRegion
*io_regions,
/* handle memory io regions */
if (cur_region-type IORESOURCE_MEM) {
-int t = cur_region-type IORESOURCE_PREFETCH
-? PCI_BASE_ADDRESS_MEM_PREFETCH
-: PCI_BASE_ADDRESS_SPACE_MEMORY;
+int t = PCI_BASE_ADDRESS_SPACE_MEMORY;
+if (cur_region-type IORESOURCE_PREFETCH) {
+t |= PCI_BASE_ADDRESS_MEM_PREFETCH;
+}
+if (cur_region-type IORESOURCE_MEM_64) {
+t |= PCI_BASE_ADDRESS_MEM_TYPE_64;
+}
/* map physical memory */
pci_dev-v_addrs[i].u.r_virtbase = mmap(NULL,
cur_region-size,
@@ -468,10 +473,10 @@ static int
assigned_dev_register_regions(PCIRegion *io_regions,
(cur_region-base_addr 0xFFF);
if (cur_region-size 0xFFF) {
-error_report(PCI region %d at address 0x% PRIx64
has
- size 0x% PRIx64 , which is not a
multiple of
- 4K. You might experience some
performance hit
- due to that.,
+error_report(PCI region %d at address 0x%016 PRIx64
has
+ size 0x%016 PRIx64 , which is not a
multiple
+ of 4K. You might experience some
performance
+ hit due to that.,
nit, these changes to %016 don't make sense. If the size is not a
multiple of 4k, then it's less than 4k, so adding leading zeros is just
a waste. Also, are BARs that small likely to be 64bit? Seems like not,
so more unnecessary zeros. Thanks,
Alex,
You're right for this error_report print less than 4k. So your comments is
removing 016 and just remain the original code is fine, right?
RE: [PATCH v2] qemu-kvm/pci-assign: 64 bits bar emulation
-Original Message-
From: Alex Williamson [mailto:alex.william...@redhat.com]
Sent: Thursday, December 20, 2012 10:39 AM
To: Hao, Xudong
Cc: qemu-de...@nongnu.org; mtosa...@redhat.com; g...@redhat.com;
kvm@vger.kernel.org
Subject: Re: [PATCH v2] qemu-kvm/pci-assign: 64 bits bar emulation
On Thu, 2012-12-20 at 01:52 +, Hao, Xudong wrote:
-Original Message-
From: Alex Williamson [mailto:alex.william...@redhat.com]
Sent: Thursday, December 20, 2012 12:06 AM
To: Hao, Xudong
Cc: qemu-de...@nongnu.org; mtosa...@redhat.com; g...@redhat.com;
kvm@vger.kernel.org
Subject: Re: [PATCH v2] qemu-kvm/pci-assign: 64 bits bar emulation
On Wed, 2012-12-19 at 16:47 +0800, Xudong Hao wrote:
Enable 64 bits bar emulation.
v2 changes from v1:
- Change 0lx% to 0x%016 when print a 64 bit variable.
Test pass with the current seabios which already support 64bit pci bars.
Signed-off-by: Xudong Hao xudong@intel.com
---
hw/kvm/pci-assign.c | 22 ++
1 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/hw/kvm/pci-assign.c b/hw/kvm/pci-assign.c
index 7a0998c..fb58ca9 100644
--- a/hw/kvm/pci-assign.c
+++ b/hw/kvm/pci-assign.c
@@ -46,6 +46,7 @@
#define IORESOURCE_IRQ 0x0400
#define IORESOURCE_DMA 0x0800
#define IORESOURCE_PREFETCH 0x2000 /* No side effects */
+#define IORESOURCE_MEM_64 0x0010
//#define DEVICE_ASSIGNMENT_DEBUG
@@ -442,9 +443,13 @@ static int
assigned_dev_register_regions(PCIRegion
*io_regions,
/* handle memory io regions */
if (cur_region-type IORESOURCE_MEM) {
-int t = cur_region-type IORESOURCE_PREFETCH
-? PCI_BASE_ADDRESS_MEM_PREFETCH
-: PCI_BASE_ADDRESS_SPACE_MEMORY;
+int t = PCI_BASE_ADDRESS_SPACE_MEMORY;
+if (cur_region-type IORESOURCE_PREFETCH) {
+t |= PCI_BASE_ADDRESS_MEM_PREFETCH;
+}
+if (cur_region-type IORESOURCE_MEM_64) {
+t |= PCI_BASE_ADDRESS_MEM_TYPE_64;
+}
/* map physical memory */
pci_dev-v_addrs[i].u.r_virtbase = mmap(NULL,
cur_region-size,
@@ -468,10 +473,10 @@ static int
assigned_dev_register_regions(PCIRegion *io_regions,
(cur_region-base_addr 0xFFF);
if (cur_region-size 0xFFF) {
-error_report(PCI region %d at address 0x% PRIx64
has
- size 0x% PRIx64 , which is not a
multiple of
- 4K. You might experience some
performance hit
- due to that.,
+error_report(PCI region %d at address 0x%016
PRIx64
has
+ size 0x%016 PRIx64 , which is not
a
multiple
+ of 4K. You might experience some
performance
+ hit due to that.,
nit, these changes to %016 don't make sense. If the size is not a
multiple of 4k, then it's less than 4k, so adding leading zeros is just
a waste. Also, are BARs that small likely to be 64bit? Seems like not,
so more unnecessary zeros. Thanks,
Alex,
You're right for this error_report print less than 4k. So your comments is
removing 016 and just remain the original code is fine, right?
Yes, I'd just drop that chunk and leave the original error string.
I'll send next version to remove it.
Thanks,
Alex
RE: [PATCH v5] kvm/fpu: Enable fully eager restore kvm FPU
-Original Message-
From: Marcelo Tosatti [mailto:mtosa...@redhat.com]
Sent: Wednesday, November 21, 2012 6:00 AM
To: Hao, Xudong
Cc: a...@redhat.com; kvm@vger.kernel.org
Subject: Re: [PATCH v5] kvm/fpu: Enable fully eager restore kvm FPU
On Wed, Nov 07, 2012 at 10:01:11AM +0800, Xudong Hao wrote:
Romove fpu lazy restore logic, using eager restore totally.
v5 changes from v4:
- remove lazy fpu restore totally, fpu eager restore does not have
performance
regression and simple the code.
v4 changes from v3:
- Wrap up some confused code with a clear function lazy_fpu_allowed()
- Update fpu while update cr4 too.
v3 changes from v2:
- Make fpu active explicitly while guest xsave is enabling and non-lazy
xstate
bit exist.
v2 changes from v1:
- Expand KVM_XSTATE_LAZY to 64 bits before negating it.
Signed-off-by: Xudong Hao xudong@intel.com
---
arch/x86/kvm/vmx.c | 9 ++---
arch/x86/kvm/x86.c | 8 +---
include/linux/kvm_host.h | 1 -
3 files changed, 3 insertions(+), 15 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 6599e45..c1fd2e1 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -1197,7 +1197,7 @@ static void update_exception_bitmap(struct
kvm_vcpu *vcpu)
u32 eb;
eb = (1u PF_VECTOR) | (1u UD_VECTOR) | (1u MC_VECTOR) |
-(1u NM_VECTOR) | (1u DB_VECTOR);
+(1u DB_VECTOR);
if ((vcpu-guest_debug
(KVM_GUESTDBG_ENABLE | KVM_GUESTDBG_USE_SW_BP)) ==
(KVM_GUESTDBG_ENABLE | KVM_GUESTDBG_USE_SW_BP))
Please remove the code entirely, including:
if (is_no_device(intr_info)) {
vmx_fpu_activate(vcpu);
return 1;
}
and clts handling.
fpu_active/fpu_deactivate callbacks become unused, don't they?
Also remove fpu_active variable.
Okay, will remove all of these.
--
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] seabios/pci: enable 64 bit bar on seabios
-Original Message- From: Gerd Hoffmann [mailto:kra...@redhat.com] Sent: Monday, November 05, 2012 5:08 PM To: Hao, Xudong Cc: ke...@koconnor.net; seab...@seabios.org; kvm@vger.kernel.org; a...@redhat.com Subject: Re: [PATCH] seabios/pci: enable 64 bit bar on seabios Hi, I just want to enable 64 bit bars for KVM usage, seabios 1.7.0 is used in current qemu-kvm, which not handle 64 bit bars yet. I cloned seabios code from kernel.org(seems no 64 bit bars supporting), but I was not taking notice of the tree on http://git.qemu.org/, yes it has already done 64 bit bars handling. So you may ignore this patch. Btw, when will the latest seabios(especially 64 bits bars) be involved qemu-kvm? qemu 1.2.0 has it (seabios 1.7.1, a git snapshot very close to it to be exact), and qemu-kvm 1.2.0 should have it too. Got it, thanks. -Xudong -- 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] seabios/pci: enable 64 bit bar on seabios
-Original Message-
From: Gerd Hoffmann [mailto:kra...@redhat.com]
Sent: Friday, November 02, 2012 5:00 PM
To: Hao, Xudong
Cc: ke...@koconnor.net; seab...@seabios.org; kvm@vger.kernel.org;
a...@redhat.com
Subject: Re: [PATCH] seabios/pci: enable 64 bit bar on seabios
On 11/02/12 06:42, Xudong Hao wrote:
64 bit bar sizing and MMIO allocation. The 64 bit window is placed above
high
memory, top down from the end of guest physical address space.
What problem you are trying to fix? The existing code should handle
64bit bars just fine. By default they are placed below 4G though for
compatibility reasons (make old 32bit guests happy). When running out
of address space seabios will try map them above 4G though to make room
below 4G.
I just want to enable 64 bit bars for KVM usage, seabios 1.7.0 is used in
current qemu-kvm, which not handle 64 bit bars yet.
I cloned seabios code from kernel.org(seems no 64 bit bars supporting), but I
was not taking notice of the tree on http://git.qemu.org/, yes it has already
done 64 bit bars handling. So you may ignore this patch.
Btw, when will the latest seabios(especially 64 bits bars) be involved qemu-kvm?
Mapping your 64bit PCI bars above 4G unconditionally (for testing or
other reasons) can simply be done this way:
--- a/src/pciinit.c
+++ b/src/pciinit.c
@@ -599,7 +599,7 @@ static void pci_bios_map_devices(struct pci_bus
*busses)
{
pcimem_start = RamSize;
-if (pci_bios_init_root_regions(busses)) {
+if (1 /* pci_bios_init_root_regions(busses) */) {
struct pci_region r64_mem, r64_pref;
r64_mem.list = NULL;
r64_pref.list = NULL;
We might want add a config option for this.
cheers,
Gerd
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] qemu-kvm/cpuid: fix a emulation of guest physical address space
-Original Message-
From: Jan Kiszka [mailto:jan.kis...@web.de]
Sent: Saturday, November 03, 2012 6:55 PM
To: Hao, Xudong
Cc: qemu-de...@nongnu.org; a...@redhat.com; kvm@vger.kernel.org
Subject: Re: [PATCH 1/2] qemu-kvm/cpuid: fix a emulation of guest physical
address space
On 2012-11-02 06:38, Xudong Hao wrote:
For 64 bit processor, emulate 40 bits physical address if the host physical
address space = 40bits, else guest physical is same as host.
Signed-off-by: Xudong Hao xudong@intel.com
---
target-i386/cpu.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 423e009..3a78881 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -1584,7 +1584,10 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t
index, uint32_t count,
if (env-cpuid_ext2_features CPUID_EXT2_LM) {
/* 64 bit processor */
/* XXX: The physical address space is limited to 42 bits in exec.c. */
-*eax = 0x3028; /* 48 bits virtual, 40 bits physical */
+/* XXX: 40 bits physical if host physical address space = 40 bits */
+uint32_t a, b, c, d;
+host_cpuid(0x8008, 0, a, b, c, d);
+*eax = a 0x3028 ? a : 0x3028;
This variation will not only affect -cpu host, right? That can create
problems when migrating between hosts with different address widths, and
then we will need some control knob to adjust what it reported to the guest.
Oh, I did not consider migrating to different platform(addr widths).
But I think the fixed value 40 bits may cause problem: in VT-d case, when a
host support GAW 40 bits, and qemu emulate 40 bits guest physical address
space, will bring bug on:
drivers/iommu/intel-iommu.c
static struct dma_pte *pfn_to_dma_pte(struct dmar_domain *domain,
unsigned long pfn, int target_level)
{
int addr_width = agaw_to_width(domain-agaw) - VTD_PAGE_SHIFT;
...
BUG_ON(!domain-pgd);
BUG_ON(addr_width BITS_PER_LONG pfn addr_width);
Jan
} else {
if (env-cpuid_features CPUID_PSE36)
*eax = 0x0024; /* 36 bits physical */
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] qemu-kvm/cpuid: fix a emulation of guest physical address space
-Original Message-
From: Jan Kiszka [mailto:jan.kis...@web.de]
Sent: Sunday, November 04, 2012 8:55 PM
To: Hao, Xudong
Cc: qemu-de...@nongnu.org; a...@redhat.com; kvm@vger.kernel.org
Subject: Re: [PATCH 1/2] qemu-kvm/cpuid: fix a emulation of guest physical
address space
On 2012-11-04 13:15, Hao, Xudong wrote:
-Original Message-
From: Jan Kiszka [mailto:jan.kis...@web.de]
Sent: Saturday, November 03, 2012 6:55 PM
To: Hao, Xudong
Cc: qemu-de...@nongnu.org; a...@redhat.com; kvm@vger.kernel.org
Subject: Re: [PATCH 1/2] qemu-kvm/cpuid: fix a emulation of guest physical
address space
On 2012-11-02 06:38, Xudong Hao wrote:
For 64 bit processor, emulate 40 bits physical address if the host
physical
address space = 40bits, else guest physical is same as host.
Signed-off-by: Xudong Hao xudong@intel.com
---
target-i386/cpu.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 423e009..3a78881 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -1584,7 +1584,10 @@ void cpu_x86_cpuid(CPUX86State *env,
uint32_t
index, uint32_t count,
if (env-cpuid_ext2_features CPUID_EXT2_LM) {
/* 64 bit processor */
/* XXX: The physical address space is limited to 42 bits in exec.c. */
-*eax = 0x3028; /* 48 bits virtual, 40 bits physical
*/
+/* XXX: 40 bits physical if host physical address space = 40 bits */
+uint32_t a, b, c, d;
+host_cpuid(0x8008, 0, a, b, c, d);
+*eax = a 0x3028 ? a : 0x3028;
This variation will not only affect -cpu host, right? That can create
problems when migrating between hosts with different address widths, and
then we will need some control knob to adjust what it reported to the
guest.
Oh, I did not consider migrating to different platform(addr widths).
But I think the fixed value 40 bits may cause problem: in VT-d case, when a
host support GAW 40 bits, and qemu emulate 40 bits guest physical address
space, will bring bug on:
drivers/iommu/intel-iommu.c
static struct dma_pte *pfn_to_dma_pte(struct dmar_domain *domain,
unsigned long pfn, int target_level)
{
int addr_width = agaw_to_width(domain-agaw) - VTD_PAGE_SHIFT;
...
BUG_ON(!domain-pgd);
BUG_ON(addr_width BITS_PER_LONG pfn addr_width);
Does it mean that buggy or malicious user space can trigger a kernel
bug? Then this must be fixed of course.
Probably yes, when guest RAM is large enough or allocate MMIO to very high
address.
Jan, I'm not familiar the migration, do you have interest to add the migration
part fixing?
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [Qemu-devel] [PATCH 2/2] qemu-kvm/pci-assign: 64 bits bar emulation
-Original Message-
From: Blue Swirl [mailto:blauwir...@gmail.com]
Sent: Saturday, November 03, 2012 6:44 PM
To: Hao, Xudong
Cc: qemu-de...@nongnu.org; a...@redhat.com; kvm@vger.kernel.org
Subject: Re: [Qemu-devel] [PATCH 2/2] qemu-kvm/pci-assign: 64 bits bar
emulation
On Fri, Nov 2, 2012 at 5:38 AM, Xudong Hao xudong@intel.com wrote:
Enable 64 bits bar emulation.
Signed-off-by: Xudong Hao xudong@intel.com
---
hw/kvm/pci-assign.c | 18 --
1 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/hw/kvm/pci-assign.c b/hw/kvm/pci-assign.c
index 05b93d9..f1f8d1e 100644
--- a/hw/kvm/pci-assign.c
+++ b/hw/kvm/pci-assign.c
@@ -46,6 +46,7 @@
#define IORESOURCE_IRQ 0x0400
#define IORESOURCE_DMA 0x0800
#define IORESOURCE_PREFETCH 0x2000 /* No side effects */
+#define IORESOURCE_MEM_64 0x0010
//#define DEVICE_ASSIGNMENT_DEBUG
@@ -442,9 +443,13 @@ static int assigned_dev_register_regions(PCIRegion
*io_regions,
/* handle memory io regions */
if (cur_region-type IORESOURCE_MEM) {
-int t = cur_region-type IORESOURCE_PREFETCH
-? PCI_BASE_ADDRESS_MEM_PREFETCH
-: PCI_BASE_ADDRESS_SPACE_MEMORY;
+int t = PCI_BASE_ADDRESS_SPACE_MEMORY;
+if (cur_region-type IORESOURCE_PREFETCH) {
+t |= PCI_BASE_ADDRESS_MEM_PREFETCH;
+}
+if (cur_region-type IORESOURCE_MEM_64) {
+t |= PCI_BASE_ADDRESS_MEM_TYPE_64;
+}
/* map physical memory */
pci_dev-v_addrs[i].u.r_virtbase = mmap(NULL,
cur_region-size,
@@ -468,8 +473,8 @@ static int assigned_dev_register_regions(PCIRegion
*io_regions,
(cur_region-base_addr 0xFFF);
if (cur_region-size 0xFFF) {
-error_report(PCI region %d at address 0x% PRIx64
has
- size 0x% PRIx64 , which is not a
multiple of
+error_report(PCI region %d at address 0lx% PRIx64
has
+ size 0lx% PRIx64 , which is not a
multiple of
Adding 'l' to '0x' prefix does not make sense.
Thanks review it, changes to:
+error_report(PCI region %d at address 0x%016 PRIx64 has
+ size 0x%016 PRIx64 , which is not a multiple
of
RE: [PATCH v4] kvm/fpu: Enable fully eager restore kvm FPU
-Original Message- From: Avi Kivity [mailto:a...@redhat.com] Sent: Thursday, September 27, 2012 6:12 PM To: Hao, Xudong Cc: kvm@vger.kernel.org; Zhang, Xiantao Subject: Re: [PATCH v4] kvm/fpu: Enable fully eager restore kvm FPU On 09/26/2012 07:54 AM, Hao, Xudong wrote: -Original Message- From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf Of Avi Kivity Sent: Tuesday, September 25, 2012 4:16 PM To: Hao, Xudong Cc: kvm@vger.kernel.org; Zhang, Xiantao Subject: Re: [PATCH v4] kvm/fpu: Enable fully eager restore kvm FPU On 09/25/2012 04:32 AM, Hao, Xudong wrote: btw, it is clear that long term the fpu will always be eagerly loaded, as hosts and guests (and hardware) are updated. At that time it will make sense to remove the lazy fpu code entirely. But maybe that time is here already, since exits are rare and so the guest has a lot of chance to use the fpu, so eager fpu saves the #NM vmexit. Can you check a kernel compile on a westmere system? If eager fpu is faster there than lazy fpu, we can just make the fpu always eager and remove quite a bit of code. I remember westmere does not support Xsave, do you want performance of fxsave/fresotr ? Yes. If a westmere is fast enough then we can probably justify it. If you can run tests on Sandy/Ivy Bridge, even better. Run kernel compile on westmere, eager fpu is about 0.4% faster, seems eager does not benefit it too much, so remain lazy fpu for lazy_allowed fpu state? Why not make it eager all the time then? It will simplify the code quite a bit, no? The code will simple if make it eager, I'll remove the lazy logic. -- 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 v4] kvm/fpu: Enable fully eager restore kvm FPU
-Original Message- From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf Of Avi Kivity Sent: Tuesday, September 25, 2012 4:16 PM To: Hao, Xudong Cc: kvm@vger.kernel.org; Zhang, Xiantao Subject: Re: [PATCH v4] kvm/fpu: Enable fully eager restore kvm FPU On 09/25/2012 04:32 AM, Hao, Xudong wrote: btw, it is clear that long term the fpu will always be eagerly loaded, as hosts and guests (and hardware) are updated. At that time it will make sense to remove the lazy fpu code entirely. But maybe that time is here already, since exits are rare and so the guest has a lot of chance to use the fpu, so eager fpu saves the #NM vmexit. Can you check a kernel compile on a westmere system? If eager fpu is faster there than lazy fpu, we can just make the fpu always eager and remove quite a bit of code. I remember westmere does not support Xsave, do you want performance of fxsave/fresotr ? Yes. If a westmere is fast enough then we can probably justify it. If you can run tests on Sandy/Ivy Bridge, even better. Run kernel compile on westmere, eager fpu is about 0.4% faster, seems eager does not benefit it too much, so remain lazy fpu for lazy_allowed fpu state? -Xudong -- 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 v4] kvm/fpu: Enable fully eager restore kvm FPU
-Original Message-
From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On
Behalf Of Avi Kivity
Sent: Monday, September 24, 2012 10:17 PM
To: Hao, Xudong
Cc: kvm@vger.kernel.org; Zhang, Xiantao
Subject: Re: [PATCH v4] kvm/fpu: Enable fully eager restore kvm FPU
On 09/24/2012 05:28 AM, Xudong Hao wrote:
Enable KVM FPU fully eager restore, if there is other FPU state which isn't
tracked by CR0.TS bit.
v4 changes from v3:
- Wrap up some confused code with a clear functio lazy_fpu_allowed()
- Update fpu while update cr4 too.
v3 changes from v2:
- Make fpu active explicitly while guest xsave is enabling and non-lazy
xstate
bit exist.
v2 changes from v1:
- Expand KVM_XSTATE_LAZY to 64 bits before negating it.
int kvm_get_msr_common(struct kvm_vcpu *vcpu, u32 msr, u64 *pdata);
int kvm_set_msr_common(struct kvm_vcpu *vcpu, u32 msr, u64 data);
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 818fceb..fbdb44a 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -2941,6 +2941,7 @@ static int cr_interception(struct vcpu_svm *svm)
break;
case 4:
err = kvm_set_cr4(svm-vcpu, val);
+ update_lazy_fpu(vcpu);
break;
case 8:
err = kvm_set_cr8(svm-vcpu, val);
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 30bcb95..b3880c0 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -4488,6 +4488,7 @@ static int handle_cr(struct kvm_vcpu *vcpu)
return 1;
case 4:
err = handle_set_cr4(vcpu, val);
+ update_lazy_fpu(vcpu);
kvm_complete_insn_gp(vcpu, err);
return 1;
Why not in kvm_set_cr4()?
case 8: {
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index fc2a0a1..2e14cec 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -544,6 +544,31 @@ void kvm_lmsw(struct kvm_vcpu *vcpu, unsigned
long msw)
}
EXPORT_SYMBOL_GPL(kvm_lmsw);
+/*
+ * KVM trigger FPU restore by #NM (via CR0.TS),
+ * only XCR0.bit0, XCR0.bit1, XCR0.bit2 is tracked
+ * by TS bit, there might be other FPU state is not tracked
+ * by TS bit.
+ * This function lazy_fpu_allowed() return true with any of
+ * the following cases: 1)xsave isn't enabled in guest;
+ * 2)all guest FPU states can be tracked by TS bit.
+ */
+static bool lazy_fpu_allowed(struct kvm_vcpu *vcpu)
+{
+ return !!(!kvm_read_cr4_bits(vcpu, X86_CR4_OSXSAVE) ||
+ !(vcpu-arch.xcr0 ~((u64)KVM_XSTATE_LAZY)));
+}
!! is !needed, bool conversion takes care of it.
+
+void update_lazy_fpu(struct kvm_vcpu *vcpu)
+{
+ if (lazy_fpu_allowed(vcpu)) {
+ vcpu-fpu_active = 0;
+ kvm_x86_ops-fpu_deactivate(vcpu);
+ }
There is no need to deactivate the fpu here. We try to deactivate the
fpu as late as possible, preempt notifiers or vcpu_put will do that for us.
+ else
+ kvm_x86_ops-fpu_activate(vcpu);
+}
+
int __kvm_set_xcr(struct kvm_vcpu *vcpu, u32 index, u64 xcr)
{
u64 xcr0;
@@ -571,6 +596,7 @@ int kvm_set_xcr(struct kvm_vcpu *vcpu, u32 index,
u64 xcr)
kvm_inject_gp(vcpu, 0);
return 1;
}
+ update_lazy_fpu(vcpu);
return 0;
}
EXPORT_SYMBOL_GPL(kvm_set_xcr);
@@ -5985,7 +6011,11 @@ void kvm_put_guest_fpu(struct kvm_vcpu *vcpu)
vcpu-guest_fpu_loaded = 0;
fpu_save_init(vcpu-arch.guest_fpu);
++vcpu-stat.fpu_reload;
- kvm_make_request(KVM_REQ_DEACTIVATE_FPU, vcpu);
+ /*
+* Make deactivate request while allow fpu lazy restore.
+*/
+ if (lazy_fpu_allowed(vcpu))
+ kvm_make_request(KVM_REQ_DEACTIVATE_FPU, vcpu);
trace_kvm_fpu(0);
}
btw, it is clear that long term the fpu will always be eagerly loaded,
as hosts and guests (and hardware) are updated. At that time it will
make sense to remove the lazy fpu code entirely. But maybe that time is
here already, since exits are rare and so the guest has a lot of chance
to use the fpu, so eager fpu saves the #NM vmexit.
Can you check a kernel compile on a westmere system? If eager fpu is
faster there than lazy fpu, we can just make the fpu always eager and
remove quite a bit of code.
I remember westmere does not support Xsave, do you want performance of
fxsave/fresotr ?
It will slow down guests not using in-kernel apic, or guests that just
process interrupts in the kernel and then HLT, or maybe i386 guests, but
I think it's worth it.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe
RE: [PATCH v3] kvm/fpu: Enable fully eager restore kvm FPU
-Original Message- From: Avi Kivity [mailto:a...@redhat.com] Sent: Thursday, September 20, 2012 5:20 PM To: Hao, Xudong Cc: Marcelo Tosatti; kvm@vger.kernel.org; Zhang, Xiantao Subject: Re: [PATCH v3] kvm/fpu: Enable fully eager restore kvm FPU On guest entry: if (!lazy_fpu_allowed(vcpu)) kvm_x86_ops-fpu_activate(vcpu); But we already have that: if (vcpu-fpu_active) kvm_load_guest_fpu(vcpu); so why not manage fpu_active to be always set when needed? I don't want more checks in the entry path. I means add fpu_active() in kvm_set_xcr(), not in guest entry. Then the fpu_active will be set always when guest initialize xstate. @@ -574,6 +574,9 @@ int kvm_set_xcr(struct kvm_vcpu *vcpu, u32 index, u64 xcr) kvm_inject_gp(vcpu, 0); return 1; } + if (!lazy_fpu_allowed(vcpu)) + kvm_x86_ops-fpu_activate(vcpu); return 0; And of course on cr4 update. So a function update_lazy_fpu() to be called from both places is needed. Complete consideration, thanks. So I will define a function update_lazy_fpu(), insert it into kvm_set_xcr() and handle_cr(). Comments? -- 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 v3] kvm/fpu: Enable fully eager restore kvm FPU
-Original Message-
From: Avi Kivity [mailto:a...@redhat.com]
Sent: Wednesday, September 19, 2012 6:24 PM
To: Hao, Xudong
Cc: Marcelo Tosatti; kvm@vger.kernel.org; Zhang, Xiantao
Subject: Re: [PATCH v3] kvm/fpu: Enable fully eager restore kvm FPU
That may be:
static bool lazy_fpu_allowed()
{
return !(vcpu-arch.xcr0 ~((u64)KVM_XSTATE_LAZY));
}
Shouldn't it depend on cr4.osxsave as well?
It do need to check cr4.osxsave due to a separate function.
static bool lazy_fpu_allowed(struct kvm_vcpu *vcpu)
{
return !kvm_read_cr4_bits(vcpu, X86_CR4_OSXSAVE) ||
!(vcpu-arch.xcr0 ~((u64)KVM_XSTATE_LAZY));
}
On guest entry:
if (!lazy_fpu_allowed(vcpu))
kvm_x86_ops-fpu_activate(vcpu);
But we already have that:
if (vcpu-fpu_active)
kvm_load_guest_fpu(vcpu);
so why not manage fpu_active to be always set when needed? I don't want
more checks in the entry path.
I means add fpu_active() in kvm_set_xcr(), not in guest entry. Then the
fpu_active will be set always when guest initialize xstate.
@@ -574,6 +574,9 @@ int kvm_set_xcr(struct kvm_vcpu *vcpu, u32 index, u64 xcr)
kvm_inject_gp(vcpu, 0);
return 1;
}
+ if (!lazy_fpu_allowed(vcpu))
+ kvm_x86_ops-fpu_activate(vcpu);
return 0;
--
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 v3] kvm/fpu: Enable fully eager restore kvm FPU
-Original Message-
From: Marcelo Tosatti [mailto:mtosa...@redhat.com]
Sent: Monday, September 17, 2012 9:31 PM
To: Hao, Xudong
Cc: Avi Kivity; kvm@vger.kernel.org; Zhang, Xiantao
Subject: Re: [PATCH v3] kvm/fpu: Enable fully eager restore kvm FPU
On Mon, Sep 17, 2012 at 02:07:43AM +, Hao, Xudong wrote:
-Original Message-
From: Avi Kivity [mailto:a...@redhat.com]
Sent: Friday, September 14, 2012 12:40 AM
To: Marcelo Tosatti
Cc: Hao, Xudong; kvm@vger.kernel.org; Zhang, Xiantao
Subject: Re: [PATCH v3] kvm/fpu: Enable fully eager restore kvm FPU
On 09/13/2012 07:29 PM, Marcelo Tosatti wrote:
On Thu, Sep 13, 2012 at 01:26:36PM -0300, Marcelo Tosatti wrote:
On Wed, Sep 12, 2012 at 04:10:24PM +0800, Xudong Hao wrote:
Enable KVM FPU fully eager restore, if there is other FPU state which
isn't
tracked by CR0.TS bit.
v3 changes from v2:
- Make fpu active explicitly while guest xsave is enabling and
non-lazy
xstate bit
exist.
How about a guest_xcr0_can_lazy_saverestore bool to control this?
It only needs to be updated when guest xcr0 is updated.
That seems cleaner. Avi?
Reasoning below.
v2 changes from v1:
- Expand KVM_XSTATE_LAZY to 64 bits before negating it.
Signed-off-by: Xudong Hao xudong@intel.com
---
arch/x86/include/asm/kvm.h |4
arch/x86/kvm/vmx.c |2 ++
arch/x86/kvm/x86.c | 15 ++-
3 files changed, 20 insertions(+), 1 deletions(-)
diff --git a/arch/x86/include/asm/kvm.h b/arch/x86/include/asm/kvm.h
index 521bf25..4c27056 100644
--- a/arch/x86/include/asm/kvm.h
+++ b/arch/x86/include/asm/kvm.h
@@ -8,6 +8,8 @@
#include linux/types.h
#include linux/ioctl.h
+#include asm/user.h
+#include asm/xsave.h
/* Select x86 specific features in linux/kvm.h */
#define __KVM_HAVE_PIT
@@ -30,6 +32,8 @@
/* Architectural interrupt line count. */
#define KVM_NR_INTERRUPTS 256
+#define KVM_XSTATE_LAZY (XSTATE_FP | XSTATE_SSE |
XSTATE_YMM)
+
struct kvm_memory_alias {
__u32 slot; /* this has a different namespace than memory
slots */
__u32 flags;
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 248c2b4..853e875 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -3028,6 +3028,8 @@ static void vmx_set_cr0(struct kvm_vcpu
*vcpu,
unsigned long cr0)
if (!vcpu-fpu_active)
hw_cr0 |= X86_CR0_TS | X86_CR0_MP;
+else
+hw_cr0 = ~(X86_CR0_TS | X86_CR0_MP);
vmcs_writel(CR0_READ_SHADOW, cr0);
vmcs_writel(GUEST_CR0, hw_cr0);
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 20f2266..183cf60 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -560,6 +560,8 @@ int __kvm_set_xcr(struct kvm_vcpu *vcpu,
u32
index, u64 xcr)
return 1;
if (xcr0 ~host_xcr0)
return 1;
+if (xcr0 ~((u64)KVM_XSTATE_LAZY))
+vcpu-fpu_active = 1;
This is confusing. The variable allows to decrease the number of places
the decision is made.
Better to have a helper function (lazy_fpu_allowed(), for example).
Variables raise the question of whether they are maintained correctly.
I realized to modifying the fpu_active variable is incorrect, it must update
exception bitmap.
To avoid the cr0 and xcrs setting order for live migrate case, how about
calling fpu_activate() in kvm_set_xcr()? I can add code comments in this
function calling.
The objective of the change is to disable lazy fpu loading (that is,
host fpu loaded in guest and vice-versa), when some bit except the
initial tree bits set in guest XCR0 (initial tree being XSTATE_FP|XSTATE_SSE|
XSTATE_YMM). Yes?
Yes, it's just the object.
If i get that right, then the suggestion seems to be:
static bool lazy_fpu_allowed()
{
return (vcpu-arch.xcr0 ~((u64)KVM_XSTATE_LAZY));
}
That may be:
static bool lazy_fpu_allowed()
{
return !(vcpu-arch.xcr0 ~((u64)KVM_XSTATE_LAZY));
}
On guest entry:
if (!lazy_fpu_allowed(vcpu))
kvm_x86_ops-fpu_activate(vcpu);
Yes, we can add it into guest entry: kvm_set_xcr(). Avi, other comments?
if (vcpu-fpu_active)
kvm_load_guest_fpu(vcpu);
Does that make sense?
--
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 v3] kvm/fpu: Enable fully eager restore kvm FPU
-Original Message-
From: Avi Kivity [mailto:a...@redhat.com]
Sent: Friday, September 14, 2012 12:40 AM
To: Marcelo Tosatti
Cc: Hao, Xudong; kvm@vger.kernel.org; Zhang, Xiantao
Subject: Re: [PATCH v3] kvm/fpu: Enable fully eager restore kvm FPU
On 09/13/2012 07:29 PM, Marcelo Tosatti wrote:
On Thu, Sep 13, 2012 at 01:26:36PM -0300, Marcelo Tosatti wrote:
On Wed, Sep 12, 2012 at 04:10:24PM +0800, Xudong Hao wrote:
Enable KVM FPU fully eager restore, if there is other FPU state which
isn't
tracked by CR0.TS bit.
v3 changes from v2:
- Make fpu active explicitly while guest xsave is enabling and non-lazy
xstate bit
exist.
How about a guest_xcr0_can_lazy_saverestore bool to control this?
It only needs to be updated when guest xcr0 is updated.
That seems cleaner. Avi?
Reasoning below.
v2 changes from v1:
- Expand KVM_XSTATE_LAZY to 64 bits before negating it.
Signed-off-by: Xudong Hao xudong@intel.com
---
arch/x86/include/asm/kvm.h |4
arch/x86/kvm/vmx.c |2 ++
arch/x86/kvm/x86.c | 15 ++-
3 files changed, 20 insertions(+), 1 deletions(-)
diff --git a/arch/x86/include/asm/kvm.h b/arch/x86/include/asm/kvm.h
index 521bf25..4c27056 100644
--- a/arch/x86/include/asm/kvm.h
+++ b/arch/x86/include/asm/kvm.h
@@ -8,6 +8,8 @@
#include linux/types.h
#include linux/ioctl.h
+#include asm/user.h
+#include asm/xsave.h
/* Select x86 specific features in linux/kvm.h */
#define __KVM_HAVE_PIT
@@ -30,6 +32,8 @@
/* Architectural interrupt line count. */
#define KVM_NR_INTERRUPTS 256
+#define KVM_XSTATE_LAZY (XSTATE_FP | XSTATE_SSE | XSTATE_YMM)
+
struct kvm_memory_alias {
__u32 slot; /* this has a different namespace than memory
slots */
__u32 flags;
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 248c2b4..853e875 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -3028,6 +3028,8 @@ static void vmx_set_cr0(struct kvm_vcpu *vcpu,
unsigned long cr0)
if (!vcpu-fpu_active)
hw_cr0 |= X86_CR0_TS | X86_CR0_MP;
+else
+hw_cr0 = ~(X86_CR0_TS | X86_CR0_MP);
vmcs_writel(CR0_READ_SHADOW, cr0);
vmcs_writel(GUEST_CR0, hw_cr0);
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 20f2266..183cf60 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -560,6 +560,8 @@ int __kvm_set_xcr(struct kvm_vcpu *vcpu, u32
index, u64 xcr)
return 1;
if (xcr0 ~host_xcr0)
return 1;
+if (xcr0 ~((u64)KVM_XSTATE_LAZY))
+vcpu-fpu_active = 1;
This is confusing. The variable allows to decrease the number of places
the decision is made.
Better to have a helper function (lazy_fpu_allowed(), for example).
Variables raise the question of whether they are maintained correctly.
I realized to modifying the fpu_active variable is incorrect, it must update
exception bitmap.
To avoid the cr0 and xcrs setting order for live migrate case, how about
calling fpu_activate() in kvm_set_xcr()? I can add code comments in this
function calling.
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index be6d549..e4646d9 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -574,6 +574,9 @@ int kvm_set_xcr(struct kvm_vcpu *vcpu, u32 index, u64 xcr)
kvm_inject_gp(vcpu, 0);
return 1;
}
+ if (xcr ~((u64)KVM_XSTATE_LAZY))
+ /* Allow fpu eager restore */
+ kvm_x86_ops-fpu_activate(vcpu);
return 0;
}
Thanks,
-Xudong
--
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 v3] kvm/fpu: Enable fully eager restore kvm FPU
-Original Message- From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf Of Avi Kivity Sent: Friday, September 14, 2012 12:39 AM To: Hao, Xudong Cc: kvm@vger.kernel.org; Zhang, Xiantao Subject: Re: [PATCH v3] kvm/fpu: Enable fully eager restore kvm FPU On 09/12/2012 11:10 AM, Xudong Hao wrote: Enable KVM FPU fully eager restore, if there is other FPU state which isn't tracked by CR0.TS bit. v3 changes from v2: - Make fpu active explicitly while guest xsave is enabling and non-lazy xstate bit exist. v2 changes from v1: - Expand KVM_XSTATE_LAZY to 64 bits before negating it. diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index 248c2b4..853e875 100644 --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -3028,6 +3028,8 @@ static void vmx_set_cr0(struct kvm_vcpu *vcpu, unsigned long cr0) if (!vcpu-fpu_active) hw_cr0 |= X86_CR0_TS | X86_CR0_MP; + else + hw_cr0 = ~(X86_CR0_TS | X86_CR0_MP); Why? The guest may wish to receive #NM faults. Hmm, I wanted to clear TS bit to avoid vmexit if fpu_active=1, but missing to consider the guest inside. vmcs_writel(CR0_READ_SHADOW, cr0); vmcs_writel(GUEST_CR0, hw_cr0); diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 20f2266..183cf60 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -560,6 +560,8 @@ int __kvm_set_xcr(struct kvm_vcpu *vcpu, u32 index, u64 xcr) return 1; if (xcr0 ~host_xcr0) return 1; + if (xcr0 ~((u64)KVM_XSTATE_LAZY)) + vcpu-fpu_active = 1; vcpu-arch.xcr0 = xcr0; vcpu-guest_xcr0_loaded = 0; return 0; @@ -5969,7 +5971,18 @@ void kvm_put_guest_fpu(struct kvm_vcpu *vcpu) vcpu-guest_fpu_loaded = 0; fpu_save_init(vcpu-arch.guest_fpu); ++vcpu-stat.fpu_reload; - kvm_make_request(KVM_REQ_DEACTIVATE_FPU, vcpu); + /* +* Currently KVM trigger FPU restore by #NM (via CR0.TS), +* till now only XCR0.bit0, XCR0.bit1, XCR0.bit2 is tracked currently, till now, don't tell someone reading the code in six months anything. Just say how the code works. Okay. -- 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 v3] kvm/fpu: Enable fully eager restore kvm FPU
-Original Message-
From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On
Behalf Of Marcelo Tosatti
Sent: Friday, September 14, 2012 12:29 AM
To: Hao, Xudong; Avi Kivity
Cc: kvm@vger.kernel.org; Zhang, Xiantao
Subject: Re: [PATCH v3] kvm/fpu: Enable fully eager restore kvm FPU
On Thu, Sep 13, 2012 at 01:26:36PM -0300, Marcelo Tosatti wrote:
On Wed, Sep 12, 2012 at 04:10:24PM +0800, Xudong Hao wrote:
Enable KVM FPU fully eager restore, if there is other FPU state which
isn't
tracked by CR0.TS bit.
v3 changes from v2:
- Make fpu active explicitly while guest xsave is enabling and non-lazy
xstate
bit
exist.
How about a guest_xcr0_can_lazy_saverestore bool to control this?
It only needs to be updated when guest xcr0 is updated.
That seems cleaner. Avi?
Reasoning below.
v2 changes from v1:
- Expand KVM_XSTATE_LAZY to 64 bits before negating it.
Signed-off-by: Xudong Hao xudong@intel.com
---
arch/x86/include/asm/kvm.h |4
arch/x86/kvm/vmx.c |2 ++
arch/x86/kvm/x86.c | 15 ++-
3 files changed, 20 insertions(+), 1 deletions(-)
diff --git a/arch/x86/include/asm/kvm.h b/arch/x86/include/asm/kvm.h
index 521bf25..4c27056 100644
--- a/arch/x86/include/asm/kvm.h
+++ b/arch/x86/include/asm/kvm.h
@@ -8,6 +8,8 @@
#include linux/types.h
#include linux/ioctl.h
+#include asm/user.h
+#include asm/xsave.h
/* Select x86 specific features in linux/kvm.h */
#define __KVM_HAVE_PIT
@@ -30,6 +32,8 @@
/* Architectural interrupt line count. */
#define KVM_NR_INTERRUPTS 256
+#define KVM_XSTATE_LAZY (XSTATE_FP | XSTATE_SSE | XSTATE_YMM)
+
struct kvm_memory_alias {
__u32 slot; /* this has a different namespace than memory slots */
__u32 flags;
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 248c2b4..853e875 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -3028,6 +3028,8 @@ static void vmx_set_cr0(struct kvm_vcpu *vcpu,
unsigned long cr0)
if (!vcpu-fpu_active)
hw_cr0 |= X86_CR0_TS | X86_CR0_MP;
+ else
+ hw_cr0 = ~(X86_CR0_TS | X86_CR0_MP);
vmcs_writel(CR0_READ_SHADOW, cr0);
vmcs_writel(GUEST_CR0, hw_cr0);
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 20f2266..183cf60 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -560,6 +560,8 @@ int __kvm_set_xcr(struct kvm_vcpu *vcpu, u32
index, u64 xcr)
return 1;
if (xcr0 ~host_xcr0)
return 1;
+ if (xcr0 ~((u64)KVM_XSTATE_LAZY))
+ vcpu-fpu_active = 1;
This is confusing. The variable allows to decrease the number of places
the decision is made.
Hi, Marcelo, What does it mean?
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2] kvm/fpu: Enable fully eager restore kvm FPU
-Original Message-
From: Avi Kivity [mailto:a...@redhat.com]
Sent: Monday, September 10, 2012 4:07 PM
To: Hao, Xudong
Cc: kvm@vger.kernel.org; Zhang, Xiantao; joerg.roe...@amd.com
Subject: Re: [PATCH v2] kvm/fpu: Enable fully eager restore kvm FPU
Avi, I'm not sure if I fully understand of you. Do you mean enter guest
with a
fpu_active=0 and then fpu does not restore?
Yes.
If so, I will add fpu_active=1 in the no-lazy case.
- kvm_make_request(KVM_REQ_DEACTIVATE_FPU, vcpu);
+ if (kvm_read_cr4_bits(vcpu, X86_CR4_OSXSAVE)
+ (vcpu-arch.xcr0 ~((u64)KVM_XSTATE_LAZY))) {
+ kvm_x86_ops-fpu_activate(vcpu);
+ vcpu-fpu_active=1;
+ }
+ else
+ kvm_make_request(KVM_REQ_DEACTIVATE_FPU, vcpu);
It doesn't help here.
1 guest boot
2 kvm_userspace_exit (deactivates fpu)
3 XSETBV exit that sets xcr0.new_bit
4 kvm_enter
There is no call to kvm_put_guest_fpu() between 3 and 4, you need
something in __kvm_set_xcr() to activate the fpu.
Yes, it's code path when enable xsave in guest, I'll add fpu activate there and
remain v2 patch in kvm_put_guest_fpu().
@@ -554,6 +554,8 @@ int __kvm_set_xcr(struct kvm_vcpu *vcpu, u32 index, u64 xcr)
xcr0 = xcr;
if (kvm_x86_ops-get_cpl(vcpu) != 0)
return 1;
+ if (xcr0 ~((u64)KVM_XSTATE_LAZY))
+ kvm_x86_ops-fpu_activate(vcpu);
if (!(xcr0 XSTATE_FP))
return 1;
if ((xcr0 XSTATE_YMM) !(xcr0 XSTATE_SSE))
Note you also need to consider writes to xcr0 and cr4 that happen in the
reverse order due to live migration.
I'm confused of this, doesn't setting cr4 firstly then xcr0?
Do you mean current live migration has a reverse order, or it must be a reverse
order with my eager restore patch?
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2] kvm/fpu: Enable fully eager restore kvm FPU
-Original Message-
From: Avi Kivity [mailto:a...@redhat.com]
Sent: Tuesday, September 11, 2012 3:54 PM
To: Hao, Xudong
Cc: kvm@vger.kernel.org; Zhang, Xiantao; joerg.roe...@amd.com
Subject: Re: [PATCH v2] kvm/fpu: Enable fully eager restore kvm FPU
On 09/11/2012 09:43 AM, Hao, Xudong wrote:
-Original Message-
From: Avi Kivity [mailto:a...@redhat.com]
Sent: Monday, September 10, 2012 4:07 PM
To: Hao, Xudong
Cc: kvm@vger.kernel.org; Zhang, Xiantao; joerg.roe...@amd.com
Subject: Re: [PATCH v2] kvm/fpu: Enable fully eager restore kvm FPU
Avi, I'm not sure if I fully understand of you. Do you mean enter guest
with
a
fpu_active=0 and then fpu does not restore?
Yes.
If so, I will add fpu_active=1 in the no-lazy case.
- kvm_make_request(KVM_REQ_DEACTIVATE_FPU, vcpu);
+ if (kvm_read_cr4_bits(vcpu, X86_CR4_OSXSAVE)
+ (vcpu-arch.xcr0 ~((u64)KVM_XSTATE_LAZY))) {
+ kvm_x86_ops-fpu_activate(vcpu);
+ vcpu-fpu_active=1;
+ }
+ else
+ kvm_make_request(KVM_REQ_DEACTIVATE_FPU, vcpu);
It doesn't help here.
1 guest boot
2 kvm_userspace_exit (deactivates fpu)
3 XSETBV exit that sets xcr0.new_bit
4 kvm_enter
There is no call to kvm_put_guest_fpu() between 3 and 4, you need
something in __kvm_set_xcr() to activate the fpu.
Yes, it's code path when enable xsave in guest, I'll add fpu activate there
and
remain v2 patch in kvm_put_guest_fpu().
@@ -554,6 +554,8 @@ int __kvm_set_xcr(struct kvm_vcpu *vcpu, u32 index,
u64 xcr)
xcr0 = xcr;
if (kvm_x86_ops-get_cpl(vcpu) != 0)
return 1;
+ if (xcr0 ~((u64)KVM_XSTATE_LAZY))
+ kvm_x86_ops-fpu_activate(vcpu);
if (!(xcr0 XSTATE_FP))
return 1;
if ((xcr0 XSTATE_YMM) !(xcr0 XSTATE_SSE))
Note you also need to consider writes to xcr0 and cr4 that happen in the
reverse order due to live migration.
I'm confused of this, doesn't setting cr4 firstly then xcr0?
Do you mean current live migration has a reverse order, or it must be a
reverse order with my eager restore patch?
I mean I want the code to work regardless of whether KVM_SET_SREGS or
KVM_SET_XCRS is called first.
Okay, I got it.
fpu_active(vcpu) in __kvm_set_xcr () read guest cr0, so KVM_SET_XCRS depends on
KVM_SET_SREGS in live migration case.
Here only set fpu_active=1 in __kvm_set_xcr(), and clear TS bit in set_cr0
should solve this issue.
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -3028,6 +3028,8 @@ static void vmx_set_cr0(struct kvm_vcpu *vcpu, unsigned
long cr0)
if (!vcpu-fpu_active)
hw_cr0 |= X86_CR0_TS | X86_CR0_MP;
+ else
+ hw_cr0 = ~(X86_CR0_TS | X86_CR0_MP);
vmcs_writel(CR0_READ_SHADOW, cr0);
vmcs_writel(GUEST_CR0, hw_cr0);
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 20f2266..183cf60 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -560,6 +560,8 @@ int __kvm_set_xcr(struct kvm_vcpu *vcpu, u32 index, u64 xcr)
return 1;
if (xcr0 ~host_xcr0)
return 1;
+ if (xcr0 ~((u64)KVM_XSTATE_LAZY))
+ vcpu-fpu_active = 1;
vcpu-arch.xcr0 = xcr0;
vcpu-guest_xcr0_loaded = 0;
return 0;
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2] kvm/fpu: Enable fully eager restore kvm FPU
-Original Message-
From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On
Behalf Of Avi Kivity
Sent: Thursday, September 06, 2012 4:16 PM
To: Hao, Xudong
Cc: kvm@vger.kernel.org; Zhang, Xiantao; joerg.roe...@amd.com
Subject: Re: [PATCH v2] kvm/fpu: Enable fully eager restore kvm FPU
On 09/06/2012 05:13 AM, Hao, Xudong wrote:
-Original Message-
From: Avi Kivity [mailto:a...@redhat.com]
Sent: Wednesday, September 05, 2012 9:13 PM
To: Hao, Xudong
Cc: kvm@vger.kernel.org; Zhang, Xiantao; joerg.roe...@amd.com
Subject: Re: [PATCH v2] kvm/fpu: Enable fully eager restore kvm FPU
On 09/05/2012 04:26 AM, Xudong Hao wrote:
Enable KVM FPU fully eager restore, if there is other FPU state which
isn't
tracked by CR0.TS bit.
Changes from v1:
Expand KVM_XSTATE_LAZY to 64 bits before negating it.
Signed-off-by: Xudong Hao xudong@intel.com
---
arch/x86/include/asm/kvm.h |4
arch/x86/kvm/x86.c | 13 -
2 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/arch/x86/include/asm/kvm.h b/arch/x86/include/asm/kvm.h
index 521bf25..4c27056 100644
--- a/arch/x86/include/asm/kvm.h
+++ b/arch/x86/include/asm/kvm.h
@@ -8,6 +8,8 @@
#include linux/types.h
#include linux/ioctl.h
+#include asm/user.h
+#include asm/xsave.h
/* Select x86 specific features in linux/kvm.h */
#define __KVM_HAVE_PIT
@@ -30,6 +32,8 @@
/* Architectural interrupt line count. */
#define KVM_NR_INTERRUPTS 256
+#define KVM_XSTATE_LAZY (XSTATE_FP | XSTATE_SSE | XSTATE_YMM)
+
struct kvm_memory_alias {
__u32 slot; /* this has a different namespace than memory
slots */
__u32 flags;
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 20f2266..a632042 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -5969,7 +5969,18 @@ void kvm_put_guest_fpu(struct kvm_vcpu
*vcpu)
vcpu-guest_fpu_loaded = 0;
fpu_save_init(vcpu-arch.guest_fpu);
++vcpu-stat.fpu_reload;
-kvm_make_request(KVM_REQ_DEACTIVATE_FPU, vcpu);
+/*
+ * Currently KVM trigger FPU restore by #NM (via CR0.TS),
+ * till now only XCR0.bit0, XCR0.bit1, XCR0.bit2 is tracked
+ * by TS bit, there might be other FPU state is not tracked
+ * by TS bit. Here it only make FPU deactivate request and do
+ * FPU lazy restore for these cases: 1)xsave isn't enabled
+ * in guest, 2)all guest FPU states can be tracked by TS bit.
+ * For others, doing fully FPU eager restore.
+ */
+if (!kvm_read_cr4_bits(vcpu, X86_CR4_OSXSAVE) ||
+!(vcpu-arch.xcr0 ~((u64)KVM_XSTATE_LAZY)))
+kvm_make_request(KVM_REQ_DEACTIVATE_FPU, vcpu);
trace_kvm_fpu(0);
}
I think something is missing. This patch prevents
KVM_REQ_DEACTIVATE_FPU, but the fpu may not be active when non-lazy
bits
are added to xcr0 (or cr4.osxsave is enabled). I think you need to
activate the fpu at that time as well.
Mmh, I thought fpu is active by default, but it's better to make fpu active
explicitly here.
If the following patch is fine, I'll make it another version.
It is, but a previous pass through kvm_put_guest_fpu() could have
deactivated it.
- kvm_make_request(KVM_REQ_DEACTIVATE_FPU, vcpu);
+ if (kvm_read_cr4_bits(vcpu, X86_CR4_OSXSAVE)
+ (vcpu-arch.xcr0 ~((u64)KVM_XSTATE_LAZY)))
+ kvm_x86_ops-fpu_activate(vcpu);
+ else
+ kvm_make_request(KVM_REQ_DEACTIVATE_FPU, vcpu);
Doesn't help. We can have:
host: deactivate fpu for some reason
guest: set cr4.osxsave, xcr0.bit3
host: enter guest with deactivated fpu
guest: touch fpu
result: host fpu corrupted.
Avi, I'm not sure if I fully understand of you. Do you mean enter guest with a
fpu_active=0 and then fpu does not restore? If so, I will add fpu_active=1 in
the no-lazy case.
- kvm_make_request(KVM_REQ_DEACTIVATE_FPU, vcpu);
+ if (kvm_read_cr4_bits(vcpu, X86_CR4_OSXSAVE)
+ (vcpu-arch.xcr0 ~((u64)KVM_XSTATE_LAZY))) {
+ kvm_x86_ops-fpu_activate(vcpu);
+ vcpu-fpu_active=1;
+ }
+ else
+ kvm_make_request(KVM_REQ_DEACTIVATE_FPU, vcpu);
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2] kvm/fpu: Enable fully eager restore kvm FPU
-Original Message-
From: Avi Kivity [mailto:a...@redhat.com]
Sent: Wednesday, September 05, 2012 9:13 PM
To: Hao, Xudong
Cc: kvm@vger.kernel.org; Zhang, Xiantao; joerg.roe...@amd.com
Subject: Re: [PATCH v2] kvm/fpu: Enable fully eager restore kvm FPU
On 09/05/2012 04:26 AM, Xudong Hao wrote:
Enable KVM FPU fully eager restore, if there is other FPU state which isn't
tracked by CR0.TS bit.
Changes from v1:
Expand KVM_XSTATE_LAZY to 64 bits before negating it.
Signed-off-by: Xudong Hao xudong@intel.com
---
arch/x86/include/asm/kvm.h |4
arch/x86/kvm/x86.c | 13 -
2 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/arch/x86/include/asm/kvm.h b/arch/x86/include/asm/kvm.h
index 521bf25..4c27056 100644
--- a/arch/x86/include/asm/kvm.h
+++ b/arch/x86/include/asm/kvm.h
@@ -8,6 +8,8 @@
#include linux/types.h
#include linux/ioctl.h
+#include asm/user.h
+#include asm/xsave.h
/* Select x86 specific features in linux/kvm.h */
#define __KVM_HAVE_PIT
@@ -30,6 +32,8 @@
/* Architectural interrupt line count. */
#define KVM_NR_INTERRUPTS 256
+#define KVM_XSTATE_LAZY(XSTATE_FP | XSTATE_SSE | XSTATE_YMM)
+
struct kvm_memory_alias {
__u32 slot; /* this has a different namespace than memory slots */
__u32 flags;
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 20f2266..a632042 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -5969,7 +5969,18 @@ void kvm_put_guest_fpu(struct kvm_vcpu *vcpu)
vcpu-guest_fpu_loaded = 0;
fpu_save_init(vcpu-arch.guest_fpu);
++vcpu-stat.fpu_reload;
- kvm_make_request(KVM_REQ_DEACTIVATE_FPU, vcpu);
+ /*
+* Currently KVM trigger FPU restore by #NM (via CR0.TS),
+* till now only XCR0.bit0, XCR0.bit1, XCR0.bit2 is tracked
+* by TS bit, there might be other FPU state is not tracked
+* by TS bit. Here it only make FPU deactivate request and do
+* FPU lazy restore for these cases: 1)xsave isn't enabled
+* in guest, 2)all guest FPU states can be tracked by TS bit.
+* For others, doing fully FPU eager restore.
+*/
+ if (!kvm_read_cr4_bits(vcpu, X86_CR4_OSXSAVE) ||
+ !(vcpu-arch.xcr0 ~((u64)KVM_XSTATE_LAZY)))
+ kvm_make_request(KVM_REQ_DEACTIVATE_FPU, vcpu);
trace_kvm_fpu(0);
}
I think something is missing. This patch prevents
KVM_REQ_DEACTIVATE_FPU, but the fpu may not be active when non-lazy bits
are added to xcr0 (or cr4.osxsave is enabled). I think you need to
activate the fpu at that time as well.
Mmh, I thought fpu is active by default, but it's better to make fpu active
explicitly here.
If the following patch is fine, I'll make it another version.
- kvm_make_request(KVM_REQ_DEACTIVATE_FPU, vcpu);
+ if (kvm_read_cr4_bits(vcpu, X86_CR4_OSXSAVE)
+ (vcpu-arch.xcr0 ~((u64)KVM_XSTATE_LAZY)))
+ kvm_x86_ops-fpu_activate(vcpu);
+ else
+ kvm_make_request(KVM_REQ_DEACTIVATE_FPU, vcpu);
Thanks,
-Xudong
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] kvm/fpu: Enable fully eager restore kvm FPU
-Original Message- From: Avi Kivity [mailto:a...@redhat.com] Sent: Monday, September 03, 2012 5:23 PM To: Hao, Xudong Cc: Roedel, Joerg; kvm@vger.kernel.org; Zhang, Xiantao Subject: Re: [PATCH] kvm/fpu: Enable fully eager restore kvm FPU On 08/23/2012 11:51 AM, Hao, Xudong wrote: -Original Message- From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf Of Avi Kivity Sent: Monday, August 20, 2012 6:43 PM To: Roedel, Joerg Cc: Hao, Xudong; kvm@vger.kernel.org; Zhang, Xiantao Subject: Re: [PATCH] kvm/fpu: Enable fully eager restore kvm FPU On 08/20/2012 01:14 PM, Roedel, Joerg wrote: On Mon, Aug 20, 2012 at 01:08:14PM +0300, Avi Kivity wrote: On 08/20/2012 12:24 PM, Roedel, Joerg wrote: So it was broken all along? Yikes. There is no LWP support in the kernel and thus KVM can't expose it to guests. So for now nothing should be broken, no? Oh, we mask out xcr0 bits not supported by the host. So it's broken in another way: it isn't exposed. Pity, it's such a nice feature. Hi, Avi/Joerg What's the decision for it? I don't understand LWP, so how about this patch? It's fine (Joerg can send the LWP change), but there was a truncation issue that needs fixing, no? Yes, I think you means to expand KVM_XSTATE_LAZY to 64-bits, I'll send another version patch. Thanks, -Xudong -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] kvm/fpu: Enable fully eager restore kvm FPU
-Original Message- From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf Of Avi Kivity Sent: Monday, August 20, 2012 6:43 PM To: Roedel, Joerg Cc: Hao, Xudong; kvm@vger.kernel.org; Zhang, Xiantao Subject: Re: [PATCH] kvm/fpu: Enable fully eager restore kvm FPU On 08/20/2012 01:14 PM, Roedel, Joerg wrote: On Mon, Aug 20, 2012 at 01:08:14PM +0300, Avi Kivity wrote: On 08/20/2012 12:24 PM, Roedel, Joerg wrote: So it was broken all along? Yikes. There is no LWP support in the kernel and thus KVM can't expose it to guests. So for now nothing should be broken, no? Oh, we mask out xcr0 bits not supported by the host. So it's broken in another way: it isn't exposed. Pity, it's such a nice feature. Hi, Avi/Joerg What's the decision for it? I don't understand LWP, so how about this patch? -- 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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] kvm/fpu: Enable fully eager restore kvm FPU
-Original Message-
From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On
Behalf Of Avi Kivity
Sent: Thursday, August 16, 2012 5:08 PM
To: Hao, Xudong
Cc: kvm@vger.kernel.org; Zhang, Xiantao
Subject: Re: [PATCH] kvm/fpu: Enable fully eager restore kvm FPU
On 08/16/2012 08:14 AM, Xudong Hao wrote:
Enable KVM FPU fully eager restore, if there is other FPU state which isn't
tracked by
CR0.TS bit.
Tested with these cases:
1) SpecCPU2000 workload( 1 VM, 2 VMs)
2) Program for floating point caculate
Is the motivation performance or correctness?
It's not performance improvement, it could be treated as a correctness. I do
not say current code has issue, but just as code comment, it's for the other
FPU state.
+
struct kvm_memory_alias {
__u32 slot; /* this has a different namespace than memory slots */
__u32 flags;
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index b6379e5..2e628e5 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -5966,7 +5966,18 @@ void kvm_put_guest_fpu(struct kvm_vcpu *vcpu)
vcpu-guest_fpu_loaded = 0;
fpu_save_init(vcpu-arch.guest_fpu);
++vcpu-stat.fpu_reload;
- kvm_make_request(KVM_REQ_DEACTIVATE_FPU, vcpu);
+ /*
+* Currently KVM trigger FPU restore by #NM (via CR0.TS),
+* till now only XCR0.bit0, XCR0.bit1, XCR0.bit2 is tracked
+* by TS bit, there might be other FPU state is not tracked
+* by TS bit.
Which state is that?
Except the last 3 bits, other bit are these state.
Here it only make FPU deactivate request and do
+* FPU lazy restore for these cases: 1)xsave isn't enabled
+* in guest, 2)all guest FPU states can be tracked by TS bit.
+* For others, doing fully FPU eager restore.
+*/
+ if (!kvm_read_cr4_bits(vcpu, X86_CR4_OSXSAVE) ||
+ !(vcpu-arch.xcr0 ~KVM_XSTATE_LAZY))
+ kvm_make_request(KVM_REQ_DEACTIVATE_FPU, vcpu);
trace_kvm_fpu(0);
}
Is there no way to track accesses to this extended state?
Because I can't define the extended state now, so using this method. But just
as I say, the extended state are NO-LAZY except the last 3 bit.
Although I expect that on modern hardware which exits rarely, eager fpu
reload might be more performant.
--
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
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] kvm/fpu: Enable fully eager restore kvm FPU
-Original Message-
From: Avi Kivity [mailto:a...@redhat.com]
Sent: Thursday, August 16, 2012 6:59 PM
To: Hao, Xudong
Cc: kvm@vger.kernel.org; Zhang, Xiantao; Roedel, Joerg
Subject: Re: [PATCH] kvm/fpu: Enable fully eager restore kvm FPU
On 08/16/2012 12:48 PM, Hao, Xudong wrote:
-Original Message-
From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On
Behalf Of Avi Kivity
Sent: Thursday, August 16, 2012 5:08 PM
To: Hao, Xudong
Cc: kvm@vger.kernel.org; Zhang, Xiantao
Subject: Re: [PATCH] kvm/fpu: Enable fully eager restore kvm FPU
On 08/16/2012 08:14 AM, Xudong Hao wrote:
Enable KVM FPU fully eager restore, if there is other FPU state which
isn't
tracked by
CR0.TS bit.
Tested with these cases:
1) SpecCPU2000 workload( 1 VM, 2 VMs)
2) Program for floating point caculate
Is the motivation performance or correctness?
It's not performance improvement, it could be treated as a correctness. I do
not say current code has issue, but just as code comment, it's for the other
FPU
state.
+
struct kvm_memory_alias {
__u32 slot; /* this has a different namespace than memory
slots */
__u32 flags;
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index b6379e5..2e628e5 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -5966,7 +5966,18 @@ void kvm_put_guest_fpu(struct kvm_vcpu
*vcpu)
vcpu-guest_fpu_loaded = 0;
fpu_save_init(vcpu-arch.guest_fpu);
++vcpu-stat.fpu_reload;
-kvm_make_request(KVM_REQ_DEACTIVATE_FPU, vcpu);
+/*
+ * Currently KVM trigger FPU restore by #NM (via CR0.TS),
+ * till now only XCR0.bit0, XCR0.bit1, XCR0.bit2 is tracked
+ * by TS bit, there might be other FPU state is not tracked
+ * by TS bit.
Which state is that?
Except the last 3 bits, other bit are these state.
Here it only make FPU deactivate request and do
+ * FPU lazy restore for these cases: 1)xsave isn't enabled
+ * in guest, 2)all guest FPU states can be tracked by TS bit.
+ * For others, doing fully FPU eager restore.
+ */
+if (!kvm_read_cr4_bits(vcpu, X86_CR4_OSXSAVE) ||
+!(vcpu-arch.xcr0 ~KVM_XSTATE_LAZY))
+kvm_make_request(KVM_REQ_DEACTIVATE_FPU, vcpu);
trace_kvm_fpu(0);
}
Is there no way to track accesses to this extended state?
Because I can't define the extended state now, so using this method. But
just
as I say, the extended state are NO-LAZY except the last 3 bit.
Ok. Please check that ~KVM_XSTATE_LAZY expands to 64-bits correctly,
maybe we need to cast it to u64 before negating it.
Thanks.
+ if (!kvm_read_cr4_bits(vcpu, X86_CR4_OSXSAVE) ||
+ !(vcpu-arch.xcr0 ~((u64)KVM_XSTATE_LAZY)))
+ kvm_make_request(KVM_REQ_DEACTIVATE_FPU, vcpu);
Note that we limit xcr0 to the bits allowed by the host, so the currect
kernel is safe even on hardware with state that isn't tracked by cr0.ts.
But it's better to be safe here.
Joerg, IIRC LWP uses one of these bits? Should it be added to the mask?
Bit 62? Maybe LWP should change to eager too, I'm not sure. Joerg?
--
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: [PATCHv3 RFC 0/2] kvm: direct msix injection
Hi, Michael/Alex, do you have progress for device assignment issue fixing? https://bugzilla.kernel.org/show_bug.cgi?id=43328 Thanks, -Xudong -Original Message- From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf Of Alex Williamson Sent: Tuesday, July 03, 2012 1:08 AM To: Jan Kiszka Cc: Michael S. Tsirkin; kvm@vger.kernel.org Subject: Re: [PATCHv3 RFC 0/2] kvm: direct msix injection On Mon, 2012-06-25 at 11:32 +0200, Jan Kiszka wrote: On 2012-06-11 13:19, Michael S. Tsirkin wrote: We can deliver certain interrupts, notably MSIX, from atomic context. Here's an untested patch to do this (compiled only). Changes from v2: Don't inject broadcast interrupts directly Changes from v1: Tried to address comments from v1, except unifying with kvm_set_irq: passing flags to it looks too ugly. Added a comment. Jan, you said you can test this? Michael S. Tsirkin (2): kvm: implement kvm_set_msi_inatomic kvm: deliver msix interrupts from irq handler include/linux/kvm_host.h | 3 ++ virt/kvm/assigned-dev.c | 31 ++-- virt/kvm/irq_comm.c | 75 3 files changed, 102 insertions(+), 7 deletions(-) Finally-tested-by: Jan Kiszka jan.kis...@siemens.com Michael, we need either this or the simple oneshot patch to get device assignment working again for 3.5. Are you planning to push this for 3.5? Thanks, Alex -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] KVM: change PT_FIRST_AVAIL_BITS_SHIFT to avoid conflict with EPT Dirty bit
Hi, Avi What's your opinion of this patch? Thanks, -Xudong -Original Message- From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf Of Hao, Xudong Sent: Monday, June 11, 2012 9:10 AM To: a...@redhat.com Cc: kvm@vger.kernel.org; Zhang, Xiantao Subject: RE: [PATCH] KVM: change PT_FIRST_AVAIL_BITS_SHIFT to avoid conflict with EPT Dirty bit Hi, Avi Do you have comments for this patch? Thanks, -Xudong -Original Message- From: Hao, Xudong Sent: Thursday, June 07, 2012 6:26 PM To: a...@redhat.com Cc: kvm@vger.kernel.org; Hao, Xudong; Zhang, Xiantao Subject: [PATCH] KVM: change PT_FIRST_AVAIL_BITS_SHIFT to avoid conflict with EPT Dirty bit EPT Dirty bit use bit 9 as Intel SDM definition, to avoid conflict, change PT_FIRST_AVAIL_BITS_SHIFT to 10. Signed-off-by: Xudong Hao xudong@intel.com Signed-off-by: Xiantao Zhang xiantao.zh...@intel.com --- arch/x86/kvm/mmu.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c index 24dd43d..f5b996a 100644 --- a/arch/x86/kvm/mmu.c +++ b/arch/x86/kvm/mmu.c @@ -90,7 +90,7 @@ module_param(dbg, bool, 0644); #define PTE_PREFETCH_NUM 8 -#define PT_FIRST_AVAIL_BITS_SHIFT 9 +#define PT_FIRST_AVAIL_BITS_SHIFT 10 #define PT64_SECOND_AVAIL_BITS_SHIFT 52 #define PT64_LEVEL_BITS 9 -- 1.5.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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] KVM: change PT_FIRST_AVAIL_BITS_SHIFT to avoid conflict with EPT Dirty bit
Hi, Avi Do you have comments for this patch? Thanks, -Xudong -Original Message- From: Hao, Xudong Sent: Thursday, June 07, 2012 6:26 PM To: a...@redhat.com Cc: kvm@vger.kernel.org; Hao, Xudong; Zhang, Xiantao Subject: [PATCH] KVM: change PT_FIRST_AVAIL_BITS_SHIFT to avoid conflict with EPT Dirty bit EPT Dirty bit use bit 9 as Intel SDM definition, to avoid conflict, change PT_FIRST_AVAIL_BITS_SHIFT to 10. Signed-off-by: Xudong Hao xudong@intel.com Signed-off-by: Xiantao Zhang xiantao.zh...@intel.com --- arch/x86/kvm/mmu.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c index 24dd43d..f5b996a 100644 --- a/arch/x86/kvm/mmu.c +++ b/arch/x86/kvm/mmu.c @@ -90,7 +90,7 @@ module_param(dbg, bool, 0644); #define PTE_PREFETCH_NUM 8 -#define PT_FIRST_AVAIL_BITS_SHIFT 9 +#define PT_FIRST_AVAIL_BITS_SHIFT 10 #define PT64_SECOND_AVAIL_BITS_SHIFT 52 #define PT64_LEVEL_BITS 9 -- 1.5.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: [PATCH 1/1] Enable LTR/OBFF before device is used by driver
-Original Message-
From: Bjorn Helgaas [mailto:bhelg...@google.com]
Sent: Saturday, May 19, 2012 9:20 AM
To: Xudong Hao
Cc: linux-...@vger.kernel.org; linux-ker...@vger.kernel.org;
kvm@vger.kernel.org; a...@redhat.com; alex.william...@redhat.com; Zhang,
Xiantao; Hao, Xudong
Subject: Re: [PATCH 1/1] Enable LTR/OBFF before device is used by driver
On Sun, May 13, 2012 at 8:48 PM, Xudong Hao xudong@linux.intel.com
wrote:
Enable LTR(Latency tolerance reporting) and OBFF(optimized buffer
flush/fill)
in
pci_enable_device(), so that they are enabled before the device is used by
driver.
Please split this into two patches (one for LTR and another for OBFF)
so they can be reverted individually if they cause trouble.
OK.
It would
be nice if you bundled these together with your other save/restore
max Latency Value patch so they were all together on the mailing
list.
Sure, I'll modify the save/restore patch and bundle them together.
I read the LTR sections of the PCIe spec, but I can't figure out how
it's supposed to work. It says power management policies ... can be
implemented to consider Endpoint service requirements. Does that
mean there's some OS software that might be involved, or is this just
a matter of software flipping the LTR-enable bit and the hardware
doing everything else? How confident can we be that enabling this is
safe?
Software only set the LTR-enable bit, then hardware/chipset/device do
everything else. There are one thing that software can be involved: software
can configure maximum latency tolerance.
For OBFF, is there some OS piece not included here that tells a Root
Complex that now is a good time for Endpoints to do something, e.g.,
the spec mentions an operating system timer tick. Is there some
benefit to this patch without that piece? I don't understand the big
picture yet.
As like LTR, OBFF do not need OS do additional changes, just set obff-enable
bit.
Signed-off-by: Xudong Hao xudong@intel.com
---
drivers/pci/pci.c | 29 +
1 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 111569c..2369883 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -1134,6 +1134,31 @@ int pci_load_and_free_saved_state(struct
pci_dev *dev,
}
EXPORT_SYMBOL_GPL(pci_load_and_free_saved_state);
+static void pci_enable_dev_caps(struct pci_dev *dev)
+{
+ /* set default value */
+ unsigned long type = PCI_EXP_OBFF_SIGNAL_ALWAYS;
There's only one use of this value, so skip the variable and just use
PCI_EXP_OBFF_SIGNAL_ALWAYS in the call.
Ok.
The comment at pci_enable_obff() says PCI_OBFF_SIGNAL_L0 is the
preferred type, so please explain why you're not using that.
Yes, here it's better to set PCI_OBFF_SIGNAL_L0 by default.
+
+ /* LTR(Latency tolerance reporting) allows devices to send
+ * messages to the root complex indicating their latency
+ * tolerance for snooped unsnooped memory transactions.
+ */
Follow Linux comment style, i.e.,
/*
* LTR ...
*/
Will modify, Thanks.
+ pci_enable_ltr(dev);
+
+ /* OBFF (optimized buffer flush/fill), where supported,
+ * can help improve energy efficiency by giving devices
+ * information about when interrupts and other activity
+ * will have a reduced power impact.
+ */
+ pci_enable_obff(dev, type);
+}
+
+static void pci_disable_dev_caps(struct pci_dev *dev)
+{
+ pci_disable_obff(dev);
+ pci_disable_ltr(dev);
+}
+
static int do_pci_enable_device(struct pci_dev *dev, int bars)
{
int err;
@@ -1146,6 +1171,9 @@ static int do_pci_enable_device(struct pci_dev
*dev, int bars)
return err;
pci_fixup_device(pci_fixup_enable, dev);
+ /* Enable some device capibility before it's used by driver. */
+ pci_enable_dev_caps(dev);
Why is this here? It seems similar to what's already in
pci_init_capabilities(). Is there a reason to do this in the
pci_enable_device() path rather than in the pci_device_add() path?
pci_enable_device is called by any pci driver including kvm driver, Considering
such a case in kvm, when device is assigned to guest(the device will be reset),
we want not host lose those advanced PM feature, so add it in pci_enable_device
so that kvm driver call it.
+
return 0;
}
@@ -1361,6 +1389,7 @@ static void do_pci_disable_device(struct pci_dev
*dev)
}
pcibios_disable_device(dev);
+ pci_disable_dev_caps(dev);
}
/**
--
1.6.0.rc1
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/1] Enable LTR/OBFF before device is used by driver
-Original Message-
From: Don Dutile [mailto:ddut...@redhat.com]
Sent: Thursday, May 31, 2012 12:13 AM
To: Xudong Hao
Cc: bhelg...@google.com; linux-...@vger.kernel.org;
linux-ker...@vger.kernel.org; kvm@vger.kernel.org; a...@redhat.com;
alex.william...@redhat.com; Zhang, Xiantao; Hao, Xudong
Subject: Re: [PATCH 1/1] Enable LTR/OBFF before device is used by driver
While you are making the other recommended fixes, could
you add/create a pci_obff_supported() function, like the pci_ltr_supported()
function, and more importantly, add it to the pci_disable_obff() function?
The latter does not check that DEVCAP2 is supported, and thus, could be
writing to non-existent (potentially private) cap space (i.e., a V1 CAP
device,
which do exist in the marketplace).
The [enable,disable]_ltr functions do a good job of doing pci_ltr_supported()
checks, but the obff enable,disable functions should have similar calls.
Yeah, it's a good suggestion, I'll add pci_obff_supported() function.
On 05/13/2012 10:48 PM, Xudong Hao wrote:
Enable LTR(Latency tolerance reporting) and OBFF(optimized buffer
flush/fill)
in
pci_enable_device(), so that they are enabled before the device is used by
driver.
Signed-off-by: Xudong Haoxudong@intel.com
---
drivers/pci/pci.c | 29 +
1 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 111569c..2369883 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -1134,6 +1134,31 @@ int pci_load_and_free_saved_state(struct
pci_dev *dev,
}
EXPORT_SYMBOL_GPL(pci_load_and_free_saved_state);
+static void pci_enable_dev_caps(struct pci_dev *dev)
+{
+ /* set default value */
+ unsigned long type = PCI_EXP_OBFF_SIGNAL_ALWAYS;
+
+ /* LTR(Latency tolerance reporting) allows devices to send
+* messages to the root complex indicating their latency
+* tolerance for snooped unsnooped memory transactions.
+*/
+ pci_enable_ltr(dev);
+
+ /* OBFF (optimized buffer flush/fill), where supported,
+* can help improve energy efficiency by giving devices
+* information about when interrupts and other activity
+* will have a reduced power impact.
+*/
+ pci_enable_obff(dev, type);
+}
+
+static void pci_disable_dev_caps(struct pci_dev *dev)
+{
+ pci_disable_obff(dev);
+ pci_disable_ltr(dev);
+}
+
static int do_pci_enable_device(struct pci_dev *dev, int bars)
{
int err;
@@ -1146,6 +1171,9 @@ static int do_pci_enable_device(struct pci_dev
*dev, int bars)
return err;
pci_fixup_device(pci_fixup_enable, dev);
+ /* Enable some device capibility before it's used by driver. */
+ pci_enable_dev_caps(dev);
+
return 0;
}
@@ -1361,6 +1389,7 @@ static void do_pci_disable_device(struct pci_dev
*dev)
}
pcibios_disable_device(dev);
+ pci_disable_dev_caps(dev);
}
/**
--
1.6.0.rc1
--
To unsubscribe from this list: send the line unsubscribe linux-pci 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: [PATCH v3 4/4] Enabling Access bit when doing memory swapping
-Original Message-
From: Hao, Xudong
Sent: Wednesday, May 23, 2012 9:31 PM
To: a...@redhat.com
Cc: kvm@vger.kernel.org; linux-ker...@vger.kernel.org; mtosa...@redhat.com;
takuya.yoshik...@gmail.com; Zhang, Xiantao; Shan, Haitao
Subject: RE: [PATCH v3 4/4] Enabling Access bit when doing memory swapping
Hi, Avi
Will these patches be accepted if no other comments?
Thanks,
-Xudong
-Original Message-
From: Hao, Xudong
Sent: Tuesday, May 22, 2012 11:23 AM
To: a...@redhat.com
Cc: kvm@vger.kernel.org; linux-ker...@vger.kernel.org;
mtosa...@redhat.com;
takuya.yoshik...@gmail.com; Zhang, Xiantao; Hao, Xudong; Shan, Haitao
Subject: [PATCH v3 4/4] Enabling Access bit when doing memory swapping
Re-send
Enabling Access bit when doing memory swapping.
Changes from v2:
-Still using claer_bit() function to make sure it's atomic operation.
Signed-off-by: Haitao Shan haitao.s...@intel.com
Signed-off-by: Xudong Hao xudong@intel.com
---
arch/x86/kvm/mmu.c | 14 --
arch/x86/kvm/vmx.c |6 --
2 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 72102e0..c2fef8e 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -1242,7 +1242,8 @@ static int kvm_age_rmapp(struct kvm *kvm,
unsigned long *rmapp,
int young = 0;
/*
-* Emulate the accessed bit for EPT, by checking if this page has
+* In case of absence of EPT Access and Dirty Bits supports,
+* emulate the accessed bit for EPT, by checking if this page has
* an EPT mapping, and clearing it if it does. On the next access,
* a new EPT mapping will be established.
* This has some overhead, but not as much as the cost of swapping
@@ -1253,11 +1254,12 @@ static int kvm_age_rmapp(struct kvm *kvm,
unsigned long *rmapp,
for (sptep = rmap_get_first(*rmapp, iter); sptep;
sptep = rmap_get_next(iter)) {
- BUG_ON(!(*sptep PT_PRESENT_MASK));
+ BUG_ON(!is_shadow_present_pte(*sptep));
- if (*sptep PT_ACCESSED_MASK) {
+ if (*sptep shadow_accessed_mask) {
young = 1;
- clear_bit(PT_ACCESSED_SHIFT, (unsigned long *)sptep);
+ clear_bit((ffs(shadow_accessed_mask) - 1),
+(unsigned long *)sptep);
}
}
@@ -1281,9 +1283,9 @@ static int kvm_test_age_rmapp(struct kvm *kvm,
unsigned long *rmapp,
for (sptep = rmap_get_first(*rmapp, iter); sptep;
sptep = rmap_get_next(iter)) {
- BUG_ON(!(*sptep PT_PRESENT_MASK));
+ BUG_ON(!is_shadow_present_pte(*sptep));
- if (*sptep PT_ACCESSED_MASK) {
+ if (*sptep shadow_accessed_mask) {
young = 1;
break;
}
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 32eb588..ea6390e 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -7275,8 +7275,10 @@ static int __init vmx_init(void)
vmx_disable_intercept_for_msr(MSR_IA32_SYSENTER_EIP, false);
if (enable_ept) {
- kvm_mmu_set_mask_ptes(0ull, 0ull, 0ull, 0ull,
- VMX_EPT_EXECUTABLE_MASK);
+ kvm_mmu_set_mask_ptes(0ull,
+ (enable_ept_ad_bits) ? VMX_EPT_ACCESS_BIT : 0ull,
+ (enable_ept_ad_bits) ? VMX_EPT_DIRTY_BIT : 0ull,
+ 0ull, VMX_EPT_EXECUTABLE_MASK);
ept_set_mmio_spte_mask();
kvm_enable_tdp();
} else
--
1.5.6
Hi, Avi
Do you have other comments for this series of patches?
--
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 v3 4/4] Enabling Access bit when doing memory swapping
-Original Message- From: Avi Kivity [mailto:a...@redhat.com] Sent: Monday, May 28, 2012 6:37 PM To: Hao, Xudong Cc: kvm@vger.kernel.org; linux-ker...@vger.kernel.org; mtosa...@redhat.com; takuya.yoshik...@gmail.com; Zhang, Xiantao; Shan, Haitao Subject: Re: [PATCH v3 4/4] Enabling Access bit when doing memory swapping On 05/23/2012 04:31 PM, Hao, Xudong wrote: Hi, Avi Will these patches be accepted if no other comments? I can't see the other patches (use git send-email if possible) but this one looks fine. Ok, I sent other 3 patches just now. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 4/4] Enabling Access bit when doing memory swapping
Hi, Avi
Will these patches be accepted if no other comments?
Thanks,
-Xudong
-Original Message-
From: Hao, Xudong
Sent: Tuesday, May 22, 2012 11:23 AM
To: a...@redhat.com
Cc: kvm@vger.kernel.org; linux-ker...@vger.kernel.org; mtosa...@redhat.com;
takuya.yoshik...@gmail.com; Zhang, Xiantao; Hao, Xudong; Shan, Haitao
Subject: [PATCH v3 4/4] Enabling Access bit when doing memory swapping
Re-send
Enabling Access bit when doing memory swapping.
Changes from v2:
-Still using claer_bit() function to make sure it's atomic operation.
Signed-off-by: Haitao Shan haitao.s...@intel.com
Signed-off-by: Xudong Hao xudong@intel.com
---
arch/x86/kvm/mmu.c | 14 --
arch/x86/kvm/vmx.c |6 --
2 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 72102e0..c2fef8e 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -1242,7 +1242,8 @@ static int kvm_age_rmapp(struct kvm *kvm,
unsigned long *rmapp,
int young = 0;
/*
- * Emulate the accessed bit for EPT, by checking if this page has
+ * In case of absence of EPT Access and Dirty Bits supports,
+ * emulate the accessed bit for EPT, by checking if this page has
* an EPT mapping, and clearing it if it does. On the next access,
* a new EPT mapping will be established.
* This has some overhead, but not as much as the cost of swapping
@@ -1253,11 +1254,12 @@ static int kvm_age_rmapp(struct kvm *kvm,
unsigned long *rmapp,
for (sptep = rmap_get_first(*rmapp, iter); sptep;
sptep = rmap_get_next(iter)) {
- BUG_ON(!(*sptep PT_PRESENT_MASK));
+ BUG_ON(!is_shadow_present_pte(*sptep));
- if (*sptep PT_ACCESSED_MASK) {
+ if (*sptep shadow_accessed_mask) {
young = 1;
- clear_bit(PT_ACCESSED_SHIFT, (unsigned long *)sptep);
+ clear_bit((ffs(shadow_accessed_mask) - 1),
+ (unsigned long *)sptep);
}
}
@@ -1281,9 +1283,9 @@ static int kvm_test_age_rmapp(struct kvm *kvm,
unsigned long *rmapp,
for (sptep = rmap_get_first(*rmapp, iter); sptep;
sptep = rmap_get_next(iter)) {
- BUG_ON(!(*sptep PT_PRESENT_MASK));
+ BUG_ON(!is_shadow_present_pte(*sptep));
- if (*sptep PT_ACCESSED_MASK) {
+ if (*sptep shadow_accessed_mask) {
young = 1;
break;
}
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 32eb588..ea6390e 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -7275,8 +7275,10 @@ static int __init vmx_init(void)
vmx_disable_intercept_for_msr(MSR_IA32_SYSENTER_EIP, false);
if (enable_ept) {
- kvm_mmu_set_mask_ptes(0ull, 0ull, 0ull, 0ull,
- VMX_EPT_EXECUTABLE_MASK);
+ kvm_mmu_set_mask_ptes(0ull,
+ (enable_ept_ad_bits) ? VMX_EPT_ACCESS_BIT : 0ull,
+ (enable_ept_ad_bits) ? VMX_EPT_DIRTY_BIT : 0ull,
+ 0ull, VMX_EPT_EXECUTABLE_MASK);
ept_set_mmio_spte_mask();
kvm_enable_tdp();
} else
--
1.5.6
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 4/4] Enabling Access bit when doing memory swapping
-Original Message-
From: Avi Kivity [mailto:a...@redhat.com]
Sent: Monday, May 21, 2012 4:32 PM
To: Hao, Xudong
Cc: Marcelo Tosatti; Xudong Hao; kvm@vger.kernel.org;
linux-ker...@vger.kernel.org; Shan, Haitao; Zhang, Xiantao
Subject: Re: [PATCH 4/4] Enabling Access bit when doing memory swapping
On 05/21/2012 06:22 AM, Hao, Xudong wrote:
-Original Message-
From: Marcelo Tosatti [mailto:mtosa...@redhat.com]
Sent: Friday, May 18, 2012 10:23 AM
To: Xudong Hao
Cc: a...@redhat.com; kvm@vger.kernel.org; linux-ker...@vger.kernel.org;
Shan, Haitao; Zhang, Xiantao; Hao, Xudong
Subject: Re: [PATCH 4/4] Enabling Access bit when doing memory swapping
On Wed, May 16, 2012 at 09:12:30AM +0800, Xudong Hao wrote:
Enabling Access bit when doing memory swapping.
Signed-off-by: Haitao Shan haitao.s...@intel.com
Signed-off-by: Xudong Hao xudong@intel.com
---
arch/x86/kvm/mmu.c | 13 +++--
arch/x86/kvm/vmx.c |6 --
2 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index ff053ca..5f55f98 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -1166,7 +1166,8 @@ static int kvm_age_rmapp(struct kvm *kvm,
unsigned long *rmapp,
int young = 0;
/*
-* Emulate the accessed bit for EPT, by checking if this page has
+* In case of absence of EPT Access and Dirty Bits supports,
+* emulate the accessed bit for EPT, by checking if this page has
* an EPT mapping, and clearing it if it does. On the next access,
* a new EPT mapping will be established.
* This has some overhead, but not as much as the cost of swapping
@@ -1179,11 +1180,11 @@ static int kvm_age_rmapp(struct kvm *kvm,
unsigned long *rmapp,
while (spte) {
int _young;
u64 _spte = *spte;
- BUG_ON(!(_spte PT_PRESENT_MASK));
- _young = _spte PT_ACCESSED_MASK;
+ BUG_ON(!is_shadow_present_pte(_spte));
+ _young = _spte shadow_accessed_mask;
if (_young) {
young = 1;
- clear_bit(PT_ACCESSED_SHIFT, (unsigned long *)spte);
+ *spte = ~shadow_accessed_mask;
}
Now a dirty bit can be lost. Is there a reason to remove the clear_bit?
The clear_bit() is called in shadown and EPT A/D mode, because
PT_ACCESSED_SHIFT does not make sense for EPT A/D bit, so use the code
shadow_accessed_mask to mask the bit for both of them.
That doesn't answer the question. An atomic operation is now non-atomic.
You can calculate shadow_accessed_bit and keep on using clear_bit(), or
switch to cmpxchg64(), but don't just drop the dirty bit here.
I know your meaning. How about this changes:
...
young = 1;
+if (enable_ept_ad_bits)
+clear_bit(ffs(shadow_accessed_mask), (unsigned long *)spte);
clear_bit(PT_ACCESSED_SHIFT, (unsigned long *)spte);
...
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 4/4] Enabling Access bit when doing memory swapping
-Original Message- From: Avi Kivity [mailto:a...@redhat.com] Sent: Monday, May 21, 2012 6:48 PM To: Hao, Xudong Cc: Marcelo Tosatti; Xudong Hao; kvm@vger.kernel.org; linux-ker...@vger.kernel.org; Shan, Haitao; Zhang, Xiantao Subject: Re: [PATCH 4/4] Enabling Access bit when doing memory swapping On 05/21/2012 01:35 PM, Hao, Xudong wrote: That doesn't answer the question. An atomic operation is now non-atomic. You can calculate shadow_accessed_bit and keep on using clear_bit(), or switch to cmpxchg64(), but don't just drop the dirty bit here. I know your meaning. How about this changes: ... young = 1; +if (enable_ept_ad_bits) +clear_bit(ffs(shadow_accessed_mask), (unsigned long *)spte); ffs() returns an off-by-one result, so this needs to be adjusted. Yes, it need to decrease 1, I'll send v3 version for patch4, any other comments? IIRC bsfl is slow, but this shouldn't be a problem here. I do not know the story... -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 4/4] Enabling Access bit when doing memory swapping
-Original Message-
From: Marcelo Tosatti [mailto:mtosa...@redhat.com]
Sent: Friday, May 18, 2012 10:23 AM
To: Xudong Hao
Cc: a...@redhat.com; kvm@vger.kernel.org; linux-ker...@vger.kernel.org;
Shan, Haitao; Zhang, Xiantao; Hao, Xudong
Subject: Re: [PATCH 4/4] Enabling Access bit when doing memory swapping
On Wed, May 16, 2012 at 09:12:30AM +0800, Xudong Hao wrote:
Enabling Access bit when doing memory swapping.
Signed-off-by: Haitao Shan haitao.s...@intel.com
Signed-off-by: Xudong Hao xudong@intel.com
---
arch/x86/kvm/mmu.c | 13 +++--
arch/x86/kvm/vmx.c |6 --
2 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index ff053ca..5f55f98 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -1166,7 +1166,8 @@ static int kvm_age_rmapp(struct kvm *kvm,
unsigned long *rmapp,
int young = 0;
/*
-* Emulate the accessed bit for EPT, by checking if this page has
+* In case of absence of EPT Access and Dirty Bits supports,
+* emulate the accessed bit for EPT, by checking if this page has
* an EPT mapping, and clearing it if it does. On the next access,
* a new EPT mapping will be established.
* This has some overhead, but not as much as the cost of swapping
@@ -1179,11 +1180,11 @@ static int kvm_age_rmapp(struct kvm *kvm,
unsigned long *rmapp,
while (spte) {
int _young;
u64 _spte = *spte;
- BUG_ON(!(_spte PT_PRESENT_MASK));
- _young = _spte PT_ACCESSED_MASK;
+ BUG_ON(!is_shadow_present_pte(_spte));
+ _young = _spte shadow_accessed_mask;
if (_young) {
young = 1;
- clear_bit(PT_ACCESSED_SHIFT, (unsigned long *)spte);
+ *spte = ~shadow_accessed_mask;
}
Now a dirty bit can be lost. Is there a reason to remove the clear_bit?
The clear_bit() is called in shadown and EPT A/D mode, because
PT_ACCESSED_SHIFT does not make sense for EPT A/D bit, so use the code
shadow_accessed_mask to mask the bit for both of them.
--
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/4] KVM: Enable EPT access bit feature
-Original Message- From: Avi Kivity [mailto:a...@redhat.com] Sent: Wednesday, May 16, 2012 9:44 PM To: Takuya Yoshikawa Cc: Xudong Hao; kvm@vger.kernel.org; linux-ker...@vger.kernel.org; Shan, Haitao; Zhang, Xiantao; Hao, Xudong Subject: Re: [PATCH 0/4] KVM: Enable EPT access bit feature On 05/16/2012 04:35 PM, Takuya Yoshikawa wrote: On Wed, 16 May 2012 12:21:53 +0300 Avi Kivity a...@redhat.com wrote: On 05/16/2012 04:04 AM, Xudong Hao wrote: EPT A/D bits enable VMMs to efficiently implement memory management and page classification algorithms to optimize VM memory operations such as de-fragmentation, paging, live-migration, and check-pointing. The series of patches enable the EPT access bit in KVM. PATCH 1: Add EPT A/D bits definition. PATCH 2: Add kernel parameter to control EPT A/D bits support, the feature is on by default. PATCH 3: Enable EPT A/D bits if supported by turning on relevant bit in EPTP. PATCH 4: Enabling Access bit when doing memory swapping. Minor comment on patch 2, but otherwise looks good. Except for being white space damaged and based on old kvm.git? Ugh, I didn't notice that. Xudong, please rebase on kvm.git 'next', and repost using git send-email. Oh, my patch is based on 'master' branch, I saw some changes in mmu.c by Takuya which will conflict patch 4, I'll rebase on 'next' branch. Anyway, I'll send whole four patches as v2 of 'next' branch. BTW, we can use this for dirty logging as you suggested. Although we need to traverse each spte from rmap That should be cheap. Also, we might be able to cheat for direct-mapped pages: if all pages in a 2M area are mapped just once, in a direct-mapped page, we can skip rmap and iterate over the page directly. We can store this hint in lpage_info. There's a chance that this optimization will gain nothing since the processor may be able to unroll the loop and hide the rmap costs for the next spte behind the atomic access cost for the current spte. and sync with dirty bitmap, I think it will work well by using with range based GET_DIRTY_LOG to restrict the cost for one call. I'm in favour of that as well (even more, since the install base will be dominated by non-AD-capable hosts for some time). -- 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 2/4] Add parameter to control A/D bits support
-Original Message- From: Avi Kivity [mailto:a...@redhat.com] Sent: Wednesday, May 16, 2012 5:15 PM To: Xudong Hao Cc: kvm@vger.kernel.org; linux-ker...@vger.kernel.org; Shan, Haitao; Zhang, Xiantao; Hao, Xudong Subject: Re: [PATCH 2/4] Add parameter to control A/D bits support On 05/16/2012 04:08 AM, Xudong Hao wrote: Add kernel parameter to control A/D bits support, it's on by default. Signed-off-by: Haitao Shan haitao.s...@intel.com Signed-off-by: Xudong Hao xudong@intel.com --- arch/x86/kvm/vmx.c | 12 1 files changed, 12 insertions(+), 0 deletions(-) diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index d2bd719..811a61e 100644 --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -64,6 +64,9 @@ static bool __read_mostly enable_unrestricted_guest = 1; module_param_named(unrestricted_guest, enable_unrestricted_guest, bool, S_IRUGO); +static int __read_mostly enable_ept_ad_bits = 1; +module_param_named(ept_ad_bits, enable_ept_ad_bits, bool, S_IRUGO); Please use bool. And call the external name 'eptad', for easier use. OK, will modify them in patch v2. Thanks, -Xudong -- 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] kvm: Enable device LTR/OBFF capibility before doing guest device assignment
-Original Message-
From: Alex Williamson [mailto:alex.william...@redhat.com]
Sent: Wednesday, May 09, 2012 10:34 AM
To: Hao, Xudong
Cc: Avi Kivity; Xudong Hao; mtosa...@redhat.com; kvm@vger.kernel.org;
linux-ker...@vger.kernel.org; Zhang, Xiantao
Subject: RE: [PATCH] kvm: Enable device LTR/OBFF capibility before doing guest
device assignment
On Wed, 2012-05-09 at 01:18 +, Hao, Xudong wrote:
-Original Message-
From: Alex Williamson [mailto:alex.william...@redhat.com]
Sent: Tuesday, May 08, 2012 11:18 PM
To: Hao, Xudong
Cc: Avi Kivity; Xudong Hao; mtosa...@redhat.com; kvm@vger.kernel.org;
linux-ker...@vger.kernel.org; Zhang, Xiantao
Subject: RE: [PATCH] kvm: Enable device LTR/OBFF capibility before doing
guest
device assignment
On Tue, 2012-05-08 at 09:16 +, Hao, Xudong wrote:
-Original Message-
From: Alex Williamson [mailto:alex.william...@redhat.com]
Sent: Tuesday, May 08, 2012 12:16 AM
To: Hao, Xudong
Cc: Avi Kivity; Xudong Hao; mtosa...@redhat.com;
kvm@vger.kernel.org;
linux-ker...@vger.kernel.org; Zhang, Xiantao
Subject: RE: [PATCH] kvm: Enable device LTR/OBFF capibility before
doing
guest
device assignment
On Mon, 2012-05-07 at 07:58 +, Hao, Xudong wrote:
-Original Message-
From: Avi Kivity [mailto:a...@redhat.com]
Sent: Sunday, May 06, 2012 11:34 PM
To: Xudong Hao
Cc: mtosa...@redhat.com; kvm@vger.kernel.org;
linux-ker...@vger.kernel.org;
Zhang, Xiantao; Hao, Xudong; Alex Williamson
Subject: Re: [PATCH] kvm: Enable device LTR/OBFF capibility before
doing
guest
device assignment
On 05/06/2012 06:24 PM, Xudong Hao wrote:
Enable device LTR/OBFF capibility before do device assignment,
so
that
guest
can benefit from them.
cc += Alex
@@ -166,6 +166,10 @@ int kvm_assign_device(struct kvm *kvm,
if (pdev == NULL)
return -ENODEV;
+ /* Enable some device capibility before do device
assignment,
+* so that guest can benefit from them.
+*/
+ kvm_iommu_enable_dev_caps(pdev);
r = iommu_attach_device(domain, pdev-dev);
Suppose we fail here. Do we need to disable_dev_caps()?
If kvm_assign_device() fails we'll try to restore the state we saved
in
kvm_vm_ioctl_assign_device(), so ltr/obff should be brought back to
initial state.
Right, more clear.
I don't think so. When a device will be assigned to guest, it's be
owned by a pci-stub driver, attach_device fail here do not affect
everything. If host want to use it, host device driver has its own
enable/disable dev_caps.
Why is device assignment unique here? If there's a default value
that's
known to be safe, why doesn't pci_enable_device set it for everyone?
Host drivers can fine tune the value later if they want.
If host did not have this device driver or host did not load the
driver, who will enable them? Guest? But in guest, it really need qemu
PCIe support.
The kvm driver does pci_enable_device(), just like any other PCI driver.
If there's a safe default value, why isn't it set there?
OK, I saw it. Seems it's reasonable to enable them in pci_enable_device(). I'll
re-write patches there.
if (r) {
printk(KERN_ERR assign device %x:%x:%x.%x failed,
@@ -228,6 +232,7 @@ int kvm_deassign_device(struct kvm
*kvm,
PCI_SLOT(assigned_dev-host_devfn),
PCI_FUNC(assigned_dev-host_devfn));
+ kvm_iommu_disable_dev_caps(pdev);
return 0;
}
@@ -351,3 +356,30 @@ int kvm_iommu_unmap_guest(struct
kvm
*kvm)
iommu_domain_free(domain);
return 0;
}
+
+static void kvm_iommu_enable_dev_caps(struct pci_dev *pdev)
+{
+ /* set default value */
+ unsigned long type = PCI_EXP_OBFF_SIGNAL_ALWAYS;
+ int snoop_lat_ns = 1024, nosnoop_lat_ns = 1024;
Where does this magic number come from?
The number is the max value that register support, set it as default
here, we did not have any device here, and we do not know what's the
proper value, so it set a default value firstly.
The register is composed of latency scale and latency value fields.
1024 is simply the largest value the latency value can hold (+1). The
scale field allows latencies up to 34,326,183,936ns to be specified,
so
please explain how 1024 is a universal default.
Since each platform will have its own max supported latency, I think
the best way is setting the value to 0 because we have such a device
now.
What's the benefit
RE: [PATCH] PCI: save/restore max Latency Value for device LTR
-Original Message-
From: Bjorn Helgaas [mailto:bhelg...@google.com]
}
This doesn't make any sense to me. pos is the offset of the PCI
Express Capability (identifier 10h). LTR is a separate extended
capability (identifier 18h), so you at least have to look up its
offset.
Sorry paste a wrong patch...
How about this patch, not a formal patch.
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 111569c..eced407 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -910,6 +910,45 @@ static void pci_restore_pcie_state(struct pci_dev *dev)
pci_write_config_word(dev, pos + PCI_EXP_SLTCTL2, cap[i++]);
}
+static int pci_save_ltr_value(struct pci_dev *dev)
+{
+ int i = 0, pos;
+ struct pci_cap_saved_state *save_state;
+ u16 *cap;
+
+ pos = pci_find_ext_capability(dev, PCI_EXT_CAP_ID_LTR);
+ if (!pos)
+ return -ENOTSUPP;
+
+ save_state = pci_find_saved_cap(dev, PCI_EXT_CAP_ID_LTR);
+ if (!save_state) {
+ dev_err(dev-dev, buffer not found in %s\n, __func__);
+ return -ENOMEM;
+ }
+ cap = (u16 *)save_state-cap.ltr_data[0];
+
+ pci_read_config_word(dev, pos + PCI_LTR_MAX_SNOOP_LAT, cap[i++]);
+ pci_read_config_word(dev, pos + PCI_LTR_MAX_NOSNOOP_LAT, cap[i++]);
+}
+
+static void pci_restore_ltr_value(struct pci_dev *dev)
+{
+ int i = 0, pos;
+ struct pci_cap_saved_state *save_state;
+ u16 *cap;
+
+ if (!pci_ltr_supported(dev))
+ return;
+
+ save_state = pci_find_saved_cap(dev, PCI_EXT_CAP_ID_LTR);
+ pos = pci_find_ext_capability(dev, PCI_EXT_CAP_ID_LTR);
+ if (!save_state || !pos)
+ return;
+ cap = (u16 *)save_state-cap.ltr_data[0];
+
+ pci_write_config_word(dev, pos + PCI_LTR_MAX_SNOOP_LAT, cap[i++]);
+ pci_write_config_word(dev, pos + PCI_LTR_MAX_NOSNOOP_LAT, cap[i++]);
+}
static int pci_save_pcix_state(struct pci_dev *dev)
{
@@ -964,6 +1003,10 @@ pci_save_state(struct pci_dev *dev)
return i;
if ((i = pci_save_pcix_state(dev)) != 0)
return i;
+
+ if (pci_ltr_supported(dev))
+ return pci_save_ltr_value(dev);
+
return 0;
}
@@ -1032,6 +1075,7 @@ void pci_restore_state(struct pci_dev *dev)
pci_restore_pcix_state(dev);
pci_restore_msi_state(dev);
pci_restore_iov_state(dev);
+ pci_restore_ltr_value(dev);
dev-state_saved = false;
}
diff --git a/include/linux/pci.h b/include/linux/pci.h
index e444f5b..6343aeb 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -220,6 +220,7 @@ struct pci_cap_saved_data {
char cap_nr;
unsigned int size;
u32 data[0];
+ u32 ltr_data[0];
};
struct pci_cap_saved_state {
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] kvm: Enable device LTR/OBFF capibility before doing guest device assignment
-Original Message-
From: Alex Williamson [mailto:alex.william...@redhat.com]
Sent: Tuesday, May 08, 2012 12:16 AM
To: Hao, Xudong
Cc: Avi Kivity; Xudong Hao; mtosa...@redhat.com; kvm@vger.kernel.org;
linux-ker...@vger.kernel.org; Zhang, Xiantao
Subject: RE: [PATCH] kvm: Enable device LTR/OBFF capibility before doing guest
device assignment
On Mon, 2012-05-07 at 07:58 +, Hao, Xudong wrote:
-Original Message-
From: Avi Kivity [mailto:a...@redhat.com]
Sent: Sunday, May 06, 2012 11:34 PM
To: Xudong Hao
Cc: mtosa...@redhat.com; kvm@vger.kernel.org;
linux-ker...@vger.kernel.org;
Zhang, Xiantao; Hao, Xudong; Alex Williamson
Subject: Re: [PATCH] kvm: Enable device LTR/OBFF capibility before doing
guest
device assignment
On 05/06/2012 06:24 PM, Xudong Hao wrote:
Enable device LTR/OBFF capibility before do device assignment, so that
guest
can benefit from them.
cc += Alex
@@ -166,6 +166,10 @@ int kvm_assign_device(struct kvm *kvm,
if (pdev == NULL)
return -ENODEV;
+ /* Enable some device capibility before do device assignment,
+* so that guest can benefit from them.
+*/
+ kvm_iommu_enable_dev_caps(pdev);
r = iommu_attach_device(domain, pdev-dev);
Suppose we fail here. Do we need to disable_dev_caps()?
If kvm_assign_device() fails we'll try to restore the state we saved in
kvm_vm_ioctl_assign_device(), so ltr/obff should be brought back to
initial state.
Right, more clear.
I don't think so. When a device will be assigned to guest, it's be
owned by a pci-stub driver, attach_device fail here do not affect
everything. If host want to use it, host device driver has its own
enable/disable dev_caps.
Why is device assignment unique here? If there's a default value that's
known to be safe, why doesn't pci_enable_device set it for everyone?
Host drivers can fine tune the value later if they want.
if (r) {
printk(KERN_ERR assign device %x:%x:%x.%x failed,
@@ -228,6 +232,7 @@ int kvm_deassign_device(struct kvm *kvm,
PCI_SLOT(assigned_dev-host_devfn),
PCI_FUNC(assigned_dev-host_devfn));
+ kvm_iommu_disable_dev_caps(pdev);
return 0;
}
@@ -351,3 +356,30 @@ int kvm_iommu_unmap_guest(struct kvm *kvm)
iommu_domain_free(domain);
return 0;
}
+
+static void kvm_iommu_enable_dev_caps(struct pci_dev *pdev)
+{
+ /* set default value */
+ unsigned long type = PCI_EXP_OBFF_SIGNAL_ALWAYS;
+ int snoop_lat_ns = 1024, nosnoop_lat_ns = 1024;
Where does this magic number come from?
The number is the max value that register support, set it as default
here, we did not have any device here, and we do not know what's the
proper value, so it set a default value firstly.
The register is composed of latency scale and latency value fields.
1024 is simply the largest value the latency value can hold (+1). The
scale field allows latencies up to 34,326,183,936ns to be specified, so
please explain how 1024 is a universal default.
Since each platform will have its own max supported latency, I think the best
way is setting the value to 0 because we have such a device now.
+
+ /* LTR(Latency tolerance reporting) allows devices to send
+* messages to the root complex indicating their latency
+* tolerance for snooped unsnooped memory transactions.
+*/
+ pci_enable_ltr(pdev);
+ pci_set_ltr(pdev, snoop_lat_ns, nosnoop_lat_ns);
+
+ /* OBFF (optimized buffer flush/fill), where supported,
+* can help improve energy efficiency by giving devices
+* information about when interrupts and other activity
+* will have a reduced power impact.
+*/
+ pci_enable_obff(pdev, type);
+}
+
+static void kvm_iommu_disable_dev_caps(struct pci_dev *pdev)
+{
+ pci_disble_obff(pdev);
+ pci_disble_ltr(pdev);
+}
Do we need to communicate something about these capabilities to the
guest?
I guess you means that here host don't know if guest want to enable them,
right?
The ltr/obff new feature are supposed to enabled by guest if platform and
device supported.
It looks like ltr is a two part mechanism, the capability and enable
lives in the pci express capability, but the tuning registers live in
extended capability space. The guest doesn't yet have access to the
latter since we don't have an express chipset. The capability and
enable are read-only to the guest currently, same for obff. Thanks,
Alex
N�r��yb�X��ǧv�^�){.n�+h����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?��)ߢf
RE: [PATCH] kvm: Enable device LTR/OBFF capibility before doing guest device assignment
-Original Message-
From: Alex Williamson [mailto:alex.william...@redhat.com]
Sent: Tuesday, May 08, 2012 11:18 PM
To: Hao, Xudong
Cc: Avi Kivity; Xudong Hao; mtosa...@redhat.com; kvm@vger.kernel.org;
linux-ker...@vger.kernel.org; Zhang, Xiantao
Subject: RE: [PATCH] kvm: Enable device LTR/OBFF capibility before doing guest
device assignment
On Tue, 2012-05-08 at 09:16 +, Hao, Xudong wrote:
-Original Message-
From: Alex Williamson [mailto:alex.william...@redhat.com]
Sent: Tuesday, May 08, 2012 12:16 AM
To: Hao, Xudong
Cc: Avi Kivity; Xudong Hao; mtosa...@redhat.com; kvm@vger.kernel.org;
linux-ker...@vger.kernel.org; Zhang, Xiantao
Subject: RE: [PATCH] kvm: Enable device LTR/OBFF capibility before doing
guest
device assignment
On Mon, 2012-05-07 at 07:58 +, Hao, Xudong wrote:
-Original Message-
From: Avi Kivity [mailto:a...@redhat.com]
Sent: Sunday, May 06, 2012 11:34 PM
To: Xudong Hao
Cc: mtosa...@redhat.com; kvm@vger.kernel.org;
linux-ker...@vger.kernel.org;
Zhang, Xiantao; Hao, Xudong; Alex Williamson
Subject: Re: [PATCH] kvm: Enable device LTR/OBFF capibility before
doing
guest
device assignment
On 05/06/2012 06:24 PM, Xudong Hao wrote:
Enable device LTR/OBFF capibility before do device assignment, so
that
guest
can benefit from them.
cc += Alex
@@ -166,6 +166,10 @@ int kvm_assign_device(struct kvm *kvm,
if (pdev == NULL)
return -ENODEV;
+ /* Enable some device capibility before do device assignment,
+* so that guest can benefit from them.
+*/
+ kvm_iommu_enable_dev_caps(pdev);
r = iommu_attach_device(domain, pdev-dev);
Suppose we fail here. Do we need to disable_dev_caps()?
If kvm_assign_device() fails we'll try to restore the state we saved in
kvm_vm_ioctl_assign_device(), so ltr/obff should be brought back to
initial state.
Right, more clear.
I don't think so. When a device will be assigned to guest, it's be
owned by a pci-stub driver, attach_device fail here do not affect
everything. If host want to use it, host device driver has its own
enable/disable dev_caps.
Why is device assignment unique here? If there's a default value that's
known to be safe, why doesn't pci_enable_device set it for everyone?
Host drivers can fine tune the value later if they want.
If host did not have this device driver or host did not load the driver, who
will enable them? Guest? But in guest, it really need qemu PCIe support.
if (r) {
printk(KERN_ERR assign device %x:%x:%x.%x failed,
@@ -228,6 +232,7 @@ int kvm_deassign_device(struct kvm *kvm,
PCI_SLOT(assigned_dev-host_devfn),
PCI_FUNC(assigned_dev-host_devfn));
+ kvm_iommu_disable_dev_caps(pdev);
return 0;
}
@@ -351,3 +356,30 @@ int kvm_iommu_unmap_guest(struct kvm
*kvm)
iommu_domain_free(domain);
return 0;
}
+
+static void kvm_iommu_enable_dev_caps(struct pci_dev *pdev)
+{
+ /* set default value */
+ unsigned long type = PCI_EXP_OBFF_SIGNAL_ALWAYS;
+ int snoop_lat_ns = 1024, nosnoop_lat_ns = 1024;
Where does this magic number come from?
The number is the max value that register support, set it as default
here, we did not have any device here, and we do not know what's the
proper value, so it set a default value firstly.
The register is composed of latency scale and latency value fields.
1024 is simply the largest value the latency value can hold (+1). The
scale field allows latencies up to 34,326,183,936ns to be specified, so
please explain how 1024 is a universal default.
Since each platform will have its own max supported latency, I think
the best way is setting the value to 0 because we have such a device
now.
What's the benefit to that device vs the risk to other devices?
Default value 0 does not affect any device, right?
Again,
if there's a safe default value for both LTR and OBFF, why isn't PCI
core setting it for everyone? I'm inclined to wait for qemu express
support and expose LTR/OBFF control to the guest if and only if we can
enable it on the root complex and intermediate switches. Thanks,
Alex, do you means you're working on the qemu express support and ltr/obff
exposing? If so, when will this support finish?
Thanks
Xudong
N�r��yb�X��ǧv�^�){.n�+h����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?��)ߢf
RE: [PATCH] kvm: Enable device LTR/OBFF capibility before doing guest device assignment
-Original Message-
From: Avi Kivity [mailto:a...@redhat.com]
Sent: Sunday, May 06, 2012 11:34 PM
To: Xudong Hao
Cc: mtosa...@redhat.com; kvm@vger.kernel.org; linux-ker...@vger.kernel.org;
Zhang, Xiantao; Hao, Xudong; Alex Williamson
Subject: Re: [PATCH] kvm: Enable device LTR/OBFF capibility before doing guest
device assignment
On 05/06/2012 06:24 PM, Xudong Hao wrote:
Enable device LTR/OBFF capibility before do device assignment, so that guest
can benefit from them.
cc += Alex
@@ -166,6 +166,10 @@ int kvm_assign_device(struct kvm *kvm,
if (pdev == NULL)
return -ENODEV;
+ /* Enable some device capibility before do device assignment,
+* so that guest can benefit from them.
+*/
+ kvm_iommu_enable_dev_caps(pdev);
r = iommu_attach_device(domain, pdev-dev);
Suppose we fail here. Do we need to disable_dev_caps()?
I don't think so. When a device will be assigned to guest, it's be owned by a
pci-stub driver, attach_device fail here do not affect everything. If host want
to use it, host device driver has its own enable/disable dev_caps.
if (r) {
printk(KERN_ERR assign device %x:%x:%x.%x failed,
@@ -228,6 +232,7 @@ int kvm_deassign_device(struct kvm *kvm,
PCI_SLOT(assigned_dev-host_devfn),
PCI_FUNC(assigned_dev-host_devfn));
+ kvm_iommu_disable_dev_caps(pdev);
return 0;
}
@@ -351,3 +356,30 @@ int kvm_iommu_unmap_guest(struct kvm *kvm)
iommu_domain_free(domain);
return 0;
}
+
+static void kvm_iommu_enable_dev_caps(struct pci_dev *pdev)
+{
+ /* set default value */
+ unsigned long type = PCI_EXP_OBFF_SIGNAL_ALWAYS;
+ int snoop_lat_ns = 1024, nosnoop_lat_ns = 1024;
Where does this magic number come from?
The number is the max value that register support, set it as default here, we
did not have any device here, and we do not know what's the proper value, so it
set a default value firstly.
+
+ /* LTR(Latency tolerance reporting) allows devices to send
+* messages to the root complex indicating their latency
+* tolerance for snooped unsnooped memory transactions.
+*/
+ pci_enable_ltr(pdev);
+ pci_set_ltr(pdev, snoop_lat_ns, nosnoop_lat_ns);
+
+ /* OBFF (optimized buffer flush/fill), where supported,
+* can help improve energy efficiency by giving devices
+* information about when interrupts and other activity
+* will have a reduced power impact.
+*/
+ pci_enable_obff(pdev, type);
+}
+
+static void kvm_iommu_disable_dev_caps(struct pci_dev *pdev)
+{
+ pci_disble_obff(pdev);
+ pci_disble_ltr(pdev);
+}
Do we need to communicate something about these capabilities to the guest?
I guess you means that here host don't know if guest want to enable them,
right?
The ltr/obff new feature are supposed to enabled by guest if platform and
device supported.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2] intel-iommu: Add device info into list before doing context mapping
Hi, David
Any other comments for this patch? Or can you check-in it in your iommu tree?
Thanks,
-Xudong
-Original Message-
From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On
Behalf Of Hao, Xudong
Sent: Thursday, December 22, 2011 5:18 PM
To: Chris Wright
Cc: dw...@infradead.org; io...@lists.linux-foundation.org;
linux-ker...@vger.kernel.org; Zhang, Xiantao; kvm@vger.kernel.org
Subject: [PATCH v2] intel-iommu: Add device info into list before doing
context
mapping
Add device info into list before do context mapping, because device info will
be
used by iommu_enable_dev_iotlb function, in this function, pci_enable_ats
would not be called without this patch.
Signed-off-by: Xudong Hao xudong@intel.com
Signed-off-by: Xiantao Zhang xiantao.zh...@intel.com
Acked-by: Chris Wright chr...@sous-sol.org
---
drivers/iommu/intel-iommu.c | 17 +++--
1 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c index
bdc447f..ccf347f 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -2267,12 +2267,6 @@ static int domain_add_dev_info(struct
dmar_domain *domain,
if (!info)
return -ENOMEM;
- ret = domain_context_mapping(domain, pdev, translation);
- if (ret) {
- free_devinfo_mem(info);
- return ret;
- }
-
info-segment = pci_domain_nr(pdev-bus);
info-bus = pdev-bus-number;
info-devfn = pdev-devfn;
@@ -2285,6 +2279,17 @@ static int domain_add_dev_info(struct
dmar_domain *domain,
pdev-dev.archdata.iommu = info;
spin_unlock_irqrestore(device_domain_lock, flags);
+ ret = domain_context_mapping(domain, pdev, translation);
+ if (ret) {
+ spin_lock_irqsave(device_domain_lock, flags);
+ list_del(info-link);
+ list_del(info-global);
+ pdev-dev.archdata.iommu = NULL;
+ spin_unlock_irqrestore(device_domain_lock, flags);
+ free_devinfo_mem(info);
+ return ret;
+ }
+
return 0;
}
--
1.6.0.rc1
--
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
[PATCH V4] Quirk for IVB graphics FLR errata
For IvyBridge Mobile platform, a system hang may occur if a FLR(Function Level
Reset) is asserted to internal graphics.
This quirk patch is workaround for the IVB FLR errata issue.
We are disabling the FLR reset handshake between the PCH and CPU display, then
manually powering down the panel power sequencing and resetting the PCH display.
Changes from v3:
- add X86 configuration to avoid compile problem in other architecture.
Signed-off-by: Xudong Hao xudong@intel.com
Signed-off-by: Kay, Allen M allen.m@intel.com
Reviewed-by: Xiantao Zhang xiantao.zh...@intel.com
---
drivers/pci/quirks.c | 59 ++
1 files changed, 59 insertions(+), 0 deletions(-)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index 6476547..63e8b70
100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -3069,11 +3069,70 @@ static int reset_intel_82599_sfp_virtfn(struct pci_dev
*dev, int probe)
return 0;
}
+#ifdef CONFIG_X86
+
+#include ../gpu/drm/i915/i915_reg.h
+#define MSG_CTL0x45010
+
+static const int op_timeout = 10; /* set timeout 10 seconds */
+static int reset_ivb_igd(struct pci_dev *dev, int probe) {
+ u8 *mmio_base;
+ u32 val;
+ cycles_t cyc_op_timeout = tsc_khz*op_timeout*1000;
+
+ if (probe)
+ return 0;
+
+ mmio_base = ioremap_nocache(pci_resource_start(dev, 0),
+pci_resource_len(dev, 0));
+ if (!mmio_base)
+ return -ENOMEM;
+
+ /* Work Around */
+ *((u32 *)(mmio_base + MSG_CTL)) = 0x0002;
+ /* Clobbering SOUTH_CHICKEN2 register is fine only if the next
+* driver loaded sets the right bits. However, this's a reset and
+* the bits have been set by i915 previously, so we clobber
+* SOUTH_CHICKEN2 register directly here.
+*/
+ *((u32 *)(mmio_base + SOUTH_CHICKEN2)) = 0x0005;
+ val = *((u32 *)(mmio_base + PCH_PP_CONTROL)) 0xfffe;
+ *((u32 *)(mmio_base + PCH_PP_CONTROL)) = val;
+ do {
+ cycles_t start_time = get_cycles();
+ while (1) {
+ val = *((u32 *)(mmio_base + PCH_PP_STATUS));
+ if (((val 0x8000) == 0)
+((val 0x3000) == 0))
+ break;
+ if (cyc_op_timeout (get_cycles() - start_time))
+ break;
+ cpu_relax();
+ }
+ } while (0);
+ *((u32 *)(mmio_base + 0xd0100)) = 0x0002;
+
+ iounmap(pci_resource_start(dev, 0));
+ return 0;
+}
+#else
+static int reset_ivb_igd(struct pci_dev *dev, int probe) { }
+#endif /* CONFIG_X86 */
+
#define PCI_DEVICE_ID_INTEL_82599_SFP_VF 0x10ed
+#define PCI_DEVICE_ID_INTEL_IVB_M_VGA 0x0156
+#define PCI_DEVICE_ID_INTEL_IVB_M2_VGA 0x0166
static const struct pci_dev_reset_methods pci_dev_reset_methods[] = {
{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82599_SFP_VF,
reset_intel_82599_sfp_virtfn },
+ { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_IVB_M_VGA,
+ reset_ivb_igd },
+ { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_IVB_M2_VGA,
+ reset_ivb_igd },
{ PCI_VENDOR_ID_INTEL, PCI_ANY_ID,
reset_intel_generic_dev },
{ 0 }
--
1.6.0.rc1
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH V2] Quirk for IVB graphics FLR errata
-Original Message-
From: Jesse Barnes [mailto:jbar...@virtuousgeek.org]
Sent: Thursday, March 01, 2012 2:32 AM
To: Hao, Xudong
Cc: linux-...@vger.kernel.org; linux-ker...@vger.kernel.org;
kvm@vger.kernel.org; Kay, Allen M; Zhang, Xiantao
Subject: Re: [PATCH V2] Quirk for IVB graphics FLR errata
On Wed, 29 Feb 2012 03:11:24 +
Hao, Xudong xudong@intel.com wrote:
For IvyBridge Mobile platform, a system hang may occur if a
FLR(Function Level Reset) is asserted to internal graphics.
This quirk patch is workaround for the IVB FLR errata issue.
We are disabling the FLR reset handshake between the PCH and CPU
display, then manually powering down the panel power sequencing and
resetting the PCH display.
Signed-off-by: Xudong Hao xudong@intel.com
Signed-off-by: Kay, Allen M allen.m@intel.com
---
drivers/pci/quirks.c | 49
+ 1 files changed,
49
insertions(+), 0 deletions(-)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index
6476547..5223b80 100644 --- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -29,6 +29,11 @@
#include asm/dma.h /* isa_dma_bridge_buggy */
#include pci.h
+#include ../gpu/drm/i915/i915_reg.h
Ugg... this is ugly. Should probably go near the definition of the quirk at
any
rate.
OK, I'll move it just above the reset_ivb_igd function.
+#include asm/tsc.h
+/* 10 seconds */
+#define IGD_OPERATION_TIMEOUT ((cycles_t) tsc_khz*10*1000)
+
Same here, the asm/tsc.h can go at the top, but the timeout definition should
go near the reset function.
May as well make it a static const cycles_t as well.
Will modify it.
+#define MSG_CTL0x45010
+
+static int reset_ivb_igd(struct pci_dev *dev, int probe) {
+ u8 *mmio_base;
+ u32 val;
+
+ if (probe)
+ return 0;
+
+ mmio_base = ioremap_nocache(pci_resource_start(dev, 0),
+pci_resource_len(dev, 0));
+ if (!mmio_base)
+ return -ENOMEM;
+
+ /* Work Around */
+ *((u32 *)(mmio_base + MSG_CTL)) = 0x0002;
+ *((u32 *)(mmio_base + SOUTH_CHICKEN2)) = 0x0005;
+ val = *((u32 *)(mmio_base + PCH_PP_CONTROL)) 0xfffe;
+ *((u32 *)(mmio_base + PCH_PP_CONTROL)) = val;
These clobber existing values. Since we're doing a reset, clobbering
PCH_PP_CONTROL should be ok, but clobbering SOUTH_CHICKEN2 is only ok if
the next driver that loads sets the right bits (if i915 was previously using
the
device, it would have set a couple of bits).
But again since it's it a reset that's probably ok, but you should put a
comment
indicating as much.
I'll add comment here, thanks Jesse.
+ do {
+ cycles_t start_time = get_cycles();
+ while (1) {
+ val = *((u32 *)(mmio_base + PCH_PP_STATUS));
+ if (((val 0x8000) == 0)
+((val 0x3000) == 0))
+ break;
+ if (IGD_OPERATION_TIMEOUT (get_cycles() -
start_time))
+ break;
+ cpu_relax();
+ }
+ } while (0);
+ *((u32 *)(mmio_base + 0xd0100)) = 0x0002;
+
+ iounmap(pci_resource_start(dev, 0));
+ return 0;
+}
+
#define PCI_DEVICE_ID_INTEL_82599_SFP_VF 0x10ed
+#define PCI_DEVICE_ID_INTEL_IVB_M_VGA 0x0156
+#define PCI_DEVICE_ID_INTEL_IVB_M2_VGA 0x0166
static const struct pci_dev_reset_methods pci_dev_reset_methods[] = {
{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82599_SFP_VF,
reset_intel_82599_sfp_virtfn },
+ { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_IVB_M_VGA,
+ reset_ivb_igd },
+ { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_IVB_M2_VGA,
+ reset_ivb_igd },
{ PCI_VENDOR_ID_INTEL, PCI_ANY_ID,
reset_intel_generic_dev },
{ 0 }
Looks ok otherwise, thanks.
Jesse
--
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 V3] Quirk for IVB graphics FLR errata
For IvyBridge Mobile platform, a system hang may occur if a FLR(Function Level
Reset) is asserted to internal graphics.
This quirk patch is workaround for the IVB FLR errata issue.
We are disabling the FLR reset handshake between the PCH and CPU display, then
manually powering down the panel power sequencing and resetting the PCH display.
Signed-off-by: Xudong Hao xudong@intel.com
Signed-off-by: Kay, Allen M allen.m@intel.com
Reviewed-by: Xiantao Zhang xiantao.zh...@intel.com
---
drivers/pci/quirks.c | 53 ++
1 files changed, 53 insertions(+), 0 deletions(-)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index 6476547..c687218
100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -27,6 +27,7 @@
#include linux/pci-aspm.h
#include linux/ioport.h
#include asm/dma.h /* isa_dma_bridge_buggy */
+#include asm/tsc.h
#include pci.h
/*
@@ -3069,11 +3070,63 @@ static int reset_intel_82599_sfp_virtfn(struct pci_dev
*dev, int probe)
return 0;
}
+#include ../gpu/drm/i915/i915_reg.h
+#define MSG_CTL0x45010
+static const int op_timeout = 10; /* set timeout 10 seconds */
+
+static int reset_ivb_igd(struct pci_dev *dev, int probe) {
+ u8 *mmio_base;
+ u32 val;
+ cycles_t cyc_op_timeout = tsc_khz*op_timeout*1000;
+
+ if (probe)
+ return 0;
+
+ mmio_base = ioremap_nocache(pci_resource_start(dev, 0),
+pci_resource_len(dev, 0));
+ if (!mmio_base)
+ return -ENOMEM;
+
+ /* Work Around */
+ *((u32 *)(mmio_base + MSG_CTL)) = 0x0002;
+ /* Clobbering SOUTH_CHICKEN2 register is fine only if the next
+* driver loaded sets the right bits. However, this's a reset and
+* the bits have been set by i915 previously, so we clobber
+* SOUTH_CHICKEN2 register directly here.
+*/
+ *((u32 *)(mmio_base + SOUTH_CHICKEN2)) = 0x0005;
+ val = *((u32 *)(mmio_base + PCH_PP_CONTROL)) 0xfffe;
+ *((u32 *)(mmio_base + PCH_PP_CONTROL)) = val;
+ do {
+ cycles_t start_time = get_cycles();
+ while (1) {
+ val = *((u32 *)(mmio_base + PCH_PP_STATUS));
+ if (((val 0x8000) == 0)
+((val 0x3000) == 0))
+ break;
+ if (cyc_op_timeout (get_cycles() - start_time))
+ break;
+ cpu_relax();
+ }
+ } while (0);
+ *((u32 *)(mmio_base + 0xd0100)) = 0x0002;
+
+ iounmap(pci_resource_start(dev, 0));
+ return 0;
+}
+
#define PCI_DEVICE_ID_INTEL_82599_SFP_VF 0x10ed
+#define PCI_DEVICE_ID_INTEL_IVB_M_VGA 0x0156
+#define PCI_DEVICE_ID_INTEL_IVB_M2_VGA 0x0166
static const struct pci_dev_reset_methods pci_dev_reset_methods[] = {
{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82599_SFP_VF,
reset_intel_82599_sfp_virtfn },
+ { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_IVB_M_VGA,
+ reset_ivb_igd },
+ { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_IVB_M2_VGA,
+ reset_ivb_igd },
{ PCI_VENDOR_ID_INTEL, PCI_ANY_ID,
reset_intel_generic_dev },
{ 0 }
--
1.6.0.rc1
--
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 V2] Quirk for IVB graphics FLR errata
For IvyBridge Mobile platform, a system hang may occur if a FLR(Function Level
Reset) is asserted to internal graphics.
This quirk patch is workaround for the IVB FLR errata issue.
We are disabling the FLR reset handshake between the PCH and CPU display,
then manually powering down the panel power sequencing and resetting the PCH
display.
Signed-off-by: Xudong Hao xudong@intel.com
Signed-off-by: Kay, Allen M allen.m@intel.com
---
drivers/pci/quirks.c | 49 +
1 files changed, 49 insertions(+), 0 deletions(-)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index 6476547..5223b80
100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -29,6 +29,11 @@
#include asm/dma.h /* isa_dma_bridge_buggy */
#include pci.h
+#include ../gpu/drm/i915/i915_reg.h
+#include asm/tsc.h
+/* 10 seconds */
+#define IGD_OPERATION_TIMEOUT ((cycles_t) tsc_khz*10*1000)
+
/*
* This quirk function disables memory decoding and releases memory resources
* of the device specified by kernel's boot parameter
'pci=resource_alignment='.
@@ -3069,11 +3074,55 @@ static int reset_intel_82599_sfp_virtfn(struct pci_dev
*dev, int probe)
return 0;
}
+#define MSG_CTL0x45010
+
+static int reset_ivb_igd(struct pci_dev *dev, int probe) {
+ u8 *mmio_base;
+ u32 val;
+
+ if (probe)
+ return 0;
+
+ mmio_base = ioremap_nocache(pci_resource_start(dev, 0),
+pci_resource_len(dev, 0));
+ if (!mmio_base)
+ return -ENOMEM;
+
+ /* Work Around */
+ *((u32 *)(mmio_base + MSG_CTL)) = 0x0002;
+ *((u32 *)(mmio_base + SOUTH_CHICKEN2)) = 0x0005;
+ val = *((u32 *)(mmio_base + PCH_PP_CONTROL)) 0xfffe;
+ *((u32 *)(mmio_base + PCH_PP_CONTROL)) = val;
+ do {
+ cycles_t start_time = get_cycles();
+ while (1) {
+ val = *((u32 *)(mmio_base + PCH_PP_STATUS));
+ if (((val 0x8000) == 0)
+((val 0x3000) == 0))
+ break;
+ if (IGD_OPERATION_TIMEOUT (get_cycles() - start_time))
+ break;
+ cpu_relax();
+ }
+ } while (0);
+ *((u32 *)(mmio_base + 0xd0100)) = 0x0002;
+
+ iounmap(pci_resource_start(dev, 0));
+ return 0;
+}
+
#define PCI_DEVICE_ID_INTEL_82599_SFP_VF 0x10ed
+#define PCI_DEVICE_ID_INTEL_IVB_M_VGA 0x0156
+#define PCI_DEVICE_ID_INTEL_IVB_M2_VGA 0x0166
static const struct pci_dev_reset_methods pci_dev_reset_methods[] = {
{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82599_SFP_VF,
reset_intel_82599_sfp_virtfn },
+ { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_IVB_M_VGA,
+ reset_ivb_igd },
+ { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_IVB_M2_VGA,
+ reset_ivb_igd },
{ PCI_VENDOR_ID_INTEL, PCI_ANY_ID,
reset_intel_generic_dev },
{ 0 }
--
1.6.0.rc1
--
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] Quirk for IVB graphics FLR errata
For IvyBridge Mobile platform, a system hang may occur if a FLR(Function Level
Reset) is asserted to internal graphics.
This quirk patch is workaround for the IVB FLR errata issue.
Signed-off-by: Xudong Hao xudong@intel.com
Signed-off-by: Kay, Allen M allen.m@intel.com
---
drivers/pci/quirks.c | 46 ++
1 files changed, 46 insertions(+), 0 deletions(-)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 6476547..8bf5b88 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -29,6 +29,10 @@
#include asm/dma.h /* isa_dma_bridge_buggy */
#include pci.h
+#include asm/tsc.h
+/* 10 seconds */
+#define IGD_OPERATION_TIMEOUT ((cycles_t) tsc_khz*10*1000)
+
/*
* This quirk function disables memory decoding and releases memory resources
* of the device specified by kernel's boot parameter
'pci=resource_alignment='.
@@ -3069,11 +3073,53 @@ static int reset_intel_82599_sfp_virtfn(struct pci_dev
*dev, int probe)
return 0;
}
+static int reset_ivb_igd(struct pci_dev *dev, int probe)
+{
+ u8 *mmio_base;
+ u32 val;
+
+ if (probe)
+ return 0;
+
+ mmio_base = ioremap_nocache(pci_resource_start(dev, 0),
+pci_resource_len(dev, 0));
+ if (!mmio_base)
+ return -ENOMEM;
+
+ /* work around */
+ *((u32 *)(mmio_base + 0x45010)) = 0x0002;
+ *((u32 *)(mmio_base + 0xc2004)) = 0x0005;
+ val = *((u32 *)(mmio_base + 0xc7204)) 0xfffe;
+ *((u32 *)(mmio_base + 0xc7204)) = val;
+ do {
+ cycles_t start_time = get_cycles();
+ while (1) {
+ val = *((u32 *)(mmio_base + 0xc7200));
+ if (((val 0x8000) == 0)
+((val 0x3000) == 0))
+ break;
+ if (IGD_OPERATION_TIMEOUT (get_cycles() - start_time))
+ break;
+ cpu_relax();
+ }
+ } while (0);
+ *((u32 *)(mmio_base + 0xd0100)) = 0x0002;
+
+ iounmap(pci_resource_start(dev, 0));
+ return 0;
+}
+
#define PCI_DEVICE_ID_INTEL_82599_SFP_VF 0x10ed
+#define PCI_DEVICE_ID_INTEL_IVB_M_VGA 0x0156
+#define PCI_DEVICE_ID_INTEL_IVB_M2_VGA 0x0166
static const struct pci_dev_reset_methods pci_dev_reset_methods[] = {
{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82599_SFP_VF,
reset_intel_82599_sfp_virtfn },
+ { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_IVB_M_VGA,
+ reset_ivb_igd },
+ { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_IVB_M2_VGA,
+ reset_ivb_igd },
{ PCI_VENDOR_ID_INTEL, PCI_ANY_ID,
reset_intel_generic_dev },
{ 0 }
--
1.6.0.rc1
--
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 v2] intel-iommu: Add device info into list before doing context mapping
Add device info into list before do context mapping, because device info will
be used by iommu_enable_dev_iotlb function, in this function, pci_enable_ats
would not be called without this patch.
Signed-off-by: Xudong Hao xudong@intel.com
Signed-off-by: Xiantao Zhang xiantao.zh...@intel.com
Acked-by: Chris Wright chr...@sous-sol.org
---
drivers/iommu/intel-iommu.c | 17 +++--
1 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c index
bdc447f..ccf347f 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -2267,12 +2267,6 @@ static int domain_add_dev_info(struct dmar_domain
*domain,
if (!info)
return -ENOMEM;
- ret = domain_context_mapping(domain, pdev, translation);
- if (ret) {
- free_devinfo_mem(info);
- return ret;
- }
-
info-segment = pci_domain_nr(pdev-bus);
info-bus = pdev-bus-number;
info-devfn = pdev-devfn;
@@ -2285,6 +2279,17 @@ static int domain_add_dev_info(struct dmar_domain
*domain,
pdev-dev.archdata.iommu = info;
spin_unlock_irqrestore(device_domain_lock, flags);
+ ret = domain_context_mapping(domain, pdev, translation);
+ if (ret) {
+ spin_lock_irqsave(device_domain_lock, flags);
+ list_del(info-link);
+ list_del(info-global);
+ pdev-dev.archdata.iommu = NULL;
+ spin_unlock_irqrestore(device_domain_lock, flags);
+ free_devinfo_mem(info);
+ return ret;
+ }
+
return 0;
}
--
1.6.0.rc1
--
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] PCI: Enable ATS at the device state restore
Hi, Jesse
Do you have any comments for this fix patch?
Thanks,
-Xudong
-Original Message-
From: Hao, Xudong
Sent: Saturday, December 17, 2011 9:25 PM
To: 'jbar...@virtuousgeek.org'; 'linux-...@vger.kernel.org'
Cc: linux-ker...@vger.kernel.org; kvm@vger.kernel.org; Zhang, Xiantao
Subject: [PATCH] PCI: Enable ATS at the device state restore
When system go to S3 or S4 sleep and then return, some register of PCI device
does not be restored correctly, such as ATS capability. The same problem
happen on pci reset function.
This patch enables ATS at the device state restore if PCI device has ATS
capability.
Signed-off-by: Xudong Hao xudong@intel.com
Signed-off-by: Xiantao Zhang xiantao.zh...@intel.com
---
drivers/pci/ats.c | 17 +
drivers/pci/pci.c |1 +
drivers/pci/pci.h |8
3 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/drivers/pci/ats.c b/drivers/pci/ats.c index 7ec56fb..a6c2b35
100644
--- a/drivers/pci/ats.c
+++ b/drivers/pci/ats.c
@@ -127,6 +127,23 @@ void pci_disable_ats(struct pci_dev *dev) }
EXPORT_SYMBOL_GPL(pci_disable_ats);
+void pci_restore_ats_state(struct pci_dev *dev) {
+ u16 ctrl;
+
+ if (!pci_ats_enabled(dev))
+ return;
+ if (!pci_find_ext_capability(dev, PCI_EXT_CAP_ID_ATS))
+ BUG();
+
+ ctrl = PCI_ATS_CTRL_ENABLE;
+ if (!dev-is_virtfn)
+ ctrl |= PCI_ATS_CTRL_STU(dev-ats-stu - PCI_ATS_MIN_STU);
+
+ pci_write_config_word(dev, dev-ats-pos + PCI_ATS_CTRL, ctrl); }
+EXPORT_SYMBOL_GPL(pci_restore_ats_state);
+
/**
* pci_ats_queue_depth - query the ATS Invalidate Queue Depth
* @dev: the PCI device
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index 6f45a73..6dafc1d
100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -956,6 +956,7 @@ void pci_restore_state(struct pci_dev *dev)
/* PCI Express register must be restored first */
pci_restore_pcie_state(dev);
+ pci_restore_ats_state(dev);
/*
* The Base Address register should be programmed before the command
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h index b74084e..a4f3140
100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -249,6 +249,14 @@ struct pci_sriov {
u8 __iomem *mstate; /* VF Migration State Array */
};
+#ifdef CONFIG_PCI_ATS
+extern void pci_restore_ats_state(struct pci_dev *dev); #else static
+inline void pci_restore_ats_state(struct pci_dev *dev) { } #endif /*
+CONFIG_PCI_ATS */
+
#ifdef CONFIG_PCI_IOV
extern int pci_iov_init(struct pci_dev *dev); extern void
pci_iov_release(struct pci_dev *dev);
--
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] intel-iommu: Add device info into list before doing context mapping
Hi, David
Do you have any comments for this patch?
Thanks,
-Xudong
-Original Message-
From: Hao, Xudong
Sent: Saturday, December 17, 2011 9:07 PM
To: 'io...@lists.linux-foundation.org'; 'dw...@infradead.org'
Cc: 'linux-ker...@vger.kernel.org'; 'kvm@vger.kernel.org'; Zhang, Xiantao
Subject: [PATCH] intel-iommu: Add device info into list before doing context
mapping
This patch add device info into list before do context mapping. Because device
info will be used by iommu_enable_dev_iotlb function, in this function,
pci_enable_ats would not be called without this patch, so ATS did not enable
while a PCI device which has ATS capability is assigned to a guest.
Signed-off-by: Xudong Hao xudong@intel.com
Signed-off-by: Xiantao Zhang xiantao.zh...@intel.com
---
drivers/iommu/intel-iommu.c | 14 --
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c index
c0c7820..f0b5d38 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -2264,12 +2264,6 @@ static int domain_add_dev_info(struct
dmar_domain *domain,
if (!info)
return -ENOMEM;
- ret = domain_context_mapping(domain, pdev, translation);
- if (ret) {
- free_devinfo_mem(info);
- return ret;
- }
-
info-segment = pci_domain_nr(pdev-bus);
info-bus = pdev-bus-number;
info-devfn = pdev-devfn;
@@ -2282,6 +2276,14 @@ static int domain_add_dev_info(struct
dmar_domain *domain,
pdev-dev.archdata.iommu = info;
spin_unlock_irqrestore(device_domain_lock, flags);
+ ret = domain_context_mapping(domain, pdev, translation);
+ if (ret) {
+ list_del(info-link);
+ list_del(info-global);
+ free_devinfo_mem(info);
+ return ret;
+ }
+
return 0;
}
--
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] intel-iommu: Add device info into list before doing context mapping
Yes, Chris, thanks your comments.
How about this one?
---
drivers/iommu/intel-iommu.c | 16 ++--
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index a004c39..0fc5efd 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -2264,12 +2264,6 @@ static int domain_add_dev_info(struct dmar_domain
*domain,
if (!info)
return -ENOMEM;
- ret = domain_context_mapping(domain, pdev, translation);
- if (ret) {
- free_devinfo_mem(info);
- return ret;
- }
-
info-segment = pci_domain_nr(pdev-bus);
info-bus = pdev-bus-number;
info-devfn = pdev-devfn;
@@ -2282,6 +2276,16 @@ static int domain_add_dev_info(struct dmar_domain
*domain,
pdev-dev.archdata.iommu = info;
spin_unlock_irqrestore(device_domain_lock, flags);
+ ret = domain_context_mapping(domain, pdev, translation);
+ if (ret) {
+ spin_lock_irqsave(device_domain_lock, flags);
+ list_del(info-link);
+ list_del(info-global);
+ spin_unlock_irqrestore(device_domain_lock, flags);
+ free_devinfo_mem(info);
+ return ret;
+ }
+
return 0;
}
-Original Message-
From: Chris Wright [mailto:chr...@sous-sol.org]
Sent: Wednesday, December 21, 2011 12:08 AM
To: Hao, Xudong
Cc: io...@lists.linux-foundation.org; dw...@infradead.org; Zhang, Xiantao;
linux-ker...@vger.kernel.org; kvm@vger.kernel.org
Subject: Re: [PATCH] intel-iommu: Add device info into list before doing
context
mapping
* Hao, Xudong (xudong@intel.com) wrote:
@@ -2282,6 +2276,14 @@ static int domain_add_dev_info(struct
dmar_domain *domain,
pdev-dev.archdata.iommu = info;
spin_unlock_irqrestore(device_domain_lock, flags);
+ ret = domain_context_mapping(domain, pdev, translation);
+ if (ret) {
+ list_del(info-link);
+ list_del(info-global);
At the very least, this is not correct locking.
+ free_devinfo_mem(info);
+ return ret;
+ }
+
--
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] intel-iommu: Add device info into list before doing context mapping
This patch add device info into list before do context mapping. Because device
info will be used by iommu_enable_dev_iotlb function, in this function,
pci_enable_ats would not be called without this patch, so ATS did not enable
while a PCI device which has ATS capability is assigned to a guest.
Signed-off-by: Xudong Hao xudong@intel.com
Signed-off-by: Xiantao Zhang xiantao.zh...@intel.com
---
drivers/iommu/intel-iommu.c | 14 --
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index c0c7820..f0b5d38 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -2264,12 +2264,6 @@ static int domain_add_dev_info(struct dmar_domain
*domain,
if (!info)
return -ENOMEM;
- ret = domain_context_mapping(domain, pdev, translation);
- if (ret) {
- free_devinfo_mem(info);
- return ret;
- }
-
info-segment = pci_domain_nr(pdev-bus);
info-bus = pdev-bus-number;
info-devfn = pdev-devfn;
@@ -2282,6 +2276,14 @@ static int domain_add_dev_info(struct dmar_domain
*domain,
pdev-dev.archdata.iommu = info;
spin_unlock_irqrestore(device_domain_lock, flags);
+ ret = domain_context_mapping(domain, pdev, translation);
+ if (ret) {
+ list_del(info-link);
+ list_del(info-global);
+ free_devinfo_mem(info);
+ return ret;
+ }
+
return 0;
}
--
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] PCI: Enable ATS at the device state restore
When system go to S3 or S4 sleep and then return, some register of PCI device
does not be restored correctly, such as ATS capability. The same problem happen
on pci reset function.
This patch enables ATS at the device state restore if PCI device has ATS
capability.
Signed-off-by: Xudong Hao xudong@intel.com
Signed-off-by: Xiantao Zhang xiantao.zh...@intel.com
---
drivers/pci/ats.c | 17 +
drivers/pci/pci.c |1 +
drivers/pci/pci.h |8
3 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/drivers/pci/ats.c b/drivers/pci/ats.c
index 7ec56fb..a6c2b35 100644
--- a/drivers/pci/ats.c
+++ b/drivers/pci/ats.c
@@ -127,6 +127,23 @@ void pci_disable_ats(struct pci_dev *dev)
}
EXPORT_SYMBOL_GPL(pci_disable_ats);
+void pci_restore_ats_state(struct pci_dev *dev)
+{
+ u16 ctrl;
+
+ if (!pci_ats_enabled(dev))
+ return;
+ if (!pci_find_ext_capability(dev, PCI_EXT_CAP_ID_ATS))
+ BUG();
+
+ ctrl = PCI_ATS_CTRL_ENABLE;
+ if (!dev-is_virtfn)
+ ctrl |= PCI_ATS_CTRL_STU(dev-ats-stu - PCI_ATS_MIN_STU);
+
+ pci_write_config_word(dev, dev-ats-pos + PCI_ATS_CTRL, ctrl);
+}
+EXPORT_SYMBOL_GPL(pci_restore_ats_state);
+
/**
* pci_ats_queue_depth - query the ATS Invalidate Queue Depth
* @dev: the PCI device
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 6f45a73..6dafc1d 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -956,6 +956,7 @@ void pci_restore_state(struct pci_dev *dev)
/* PCI Express register must be restored first */
pci_restore_pcie_state(dev);
+ pci_restore_ats_state(dev);
/*
* The Base Address register should be programmed before the command
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index b74084e..a4f3140 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -249,6 +249,14 @@ struct pci_sriov {
u8 __iomem *mstate; /* VF Migration State Array */
};
+#ifdef CONFIG_PCI_ATS
+extern void pci_restore_ats_state(struct pci_dev *dev);
+#else
+static inline void pci_restore_ats_state(struct pci_dev *dev)
+{
+}
+#endif /* CONFIG_PCI_ATS */
+
#ifdef CONFIG_PCI_IOV
extern int pci_iov_init(struct pci_dev *dev);
extern void pci_iov_release(struct pci_dev *dev);
--
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 Test report, kernel a685b38... qemu 671d89d...
Hi, all, This is KVM test result against kvm.git a685b38e272587e644fedd37269ddb82df21c052, and qemu-kvm.git 671d89d6411655bb4f8058ce6eb86bb0bb8ec978. Currently qemu-kvm can build successfully on RHEL5, and Qcow image create failure issue also got fixed, our nightly testing resumed. One VT-d device assignment issue opened on latest KVM. New issue: 1. [VT-d] VT-d device passthrough fail to guest https://bugzilla.kernel.org/show_bug.cgi?id=29232 Fixed issues: 1. [KVM] Noacpi Windows guest can not boot up on 32bit KVM host https://bugzilla.kernel.org/show_bug.cgi?id=21402 2. [Qemu-kvm] qemu-img fail to create qcow image https://bugs.launchpad.net/bugs/706766 Three old Issues: 1. ltp diotest running time is 2.54 times than before https://sourceforge.net/tracker/?func=detailaid=2723366group_id=180599atid=893831 2. 32bits Rhel5/FC6 guest may fail to reboot after installation https://sourceforge.net/tracker/?func=detailatid=893831aid=1991647group_id=180599 3. perfctr wrmsr warning when booting 64bit RHEl5.3 https://sourceforge.net/tracker/?func=detailaid=2721640group_id=180599atid=893831 Best Regards, Xudong Hao -- 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
Qemu-kvm Build fail with function 'cirrus_bitblt_start' on RHEL5 system
Qemu-kvm commit 92d675d1c1f23f3617e24b63c825074a1d1da44b changed sx, dx and others variables into a judgement, there was a build failure on RHEL5 system. ... CCx86_64-softmmu/debugcon.o cc1: warnings being treated as errors /workspace/ia32-pae/nightly/qemu-kvm/hw/cirrus_vga.c: In function 'cirrus_bitblt_start': /workspace/ia32-pae/nightly/qemu-kvm/hw/cirrus_vga.c:678: warning: 'dx' may be used uninitialized in this function /workspace/ia32-pae/nightly/qemu-kvm/hw/cirrus_vga.c:677: warning: 'sx' may be used uninitialized in this function /workspace/ia32-pae/nightly/qemu-kvm/hw/cirrus_vga.c:679: warning: 'depth' may be used uninitialized in this function /workspace/ia32-pae/nightly/qemu-kvm/hw/cirrus_vga.c:678: warning: 'dy' may be used uninitialized in this function /workspace/ia32-pae/nightly/qemu-kvm/hw/cirrus_vga.c:677: warning: 'sy' may be used uninitialized in this function CCx86_64-softmmu/multiboot.o make[1]: *** [cirrus_vga.o] Error 1 make[1]: *** Waiting for unfinished jobs make: *** [subdir-x86_64-softmmu] Error 2 Best Regards, Xudong Hao -- 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 Test report, kernel d335b15... qemu cb1983b8...
Avi Kivity wrote: On 12/15/2010 08:05 AM, Hao, Xudong wrote: Hi, all, This is KVM test result against kvm.git d335b156f9fafd177d0606cf845d9a2df2dc5431, and qemu-kvm.git cb1983b8809d0e06a97384a40bad1194a32fc814. Currently qemu-kvm build fail on RHEL5 with a undeclared PCI_PM_CTRL_NO_SOFT_RST error. I saw there already were fix patch in mail list. There are 2 bugs got fixed. Fixed issues: 1. Guest qemu processor will be defunct process by be killed https://bugzilla.kernel.org/show_bug.cgi?id=23612 Good to see it was indeed fixed by -rc5. 2. [SR] qemu return form migrate command spend long time https://sourceforge.net/tracker/?func=detailaid=2942079group_id=180599atid=893831 Juan, Luiz, any idea what fixed this? I saw it too. Xudong, please open qemu bugs on launchpad (https://launchpad.net/qemu), not on sourceforge. Kernel bugs go to the kernel bugzilla as usual. We'll retire the sourceforge bug tracker. Yes, We already open new qemu bug on launchpad, this bug is an old report before we determine to migrate to launchpad. We just left the old bug in sourceforge. Thanks, Xudong-- 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 Test report, kernel d335b15... qemu cb1983b8...
Hi, all, This is KVM test result against kvm.git d335b156f9fafd177d0606cf845d9a2df2dc5431, and qemu-kvm.git cb1983b8809d0e06a97384a40bad1194a32fc814. Currently qemu-kvm build fail on RHEL5 with a undeclared PCI_PM_CTRL_NO_SOFT_RST error. I saw there already were fix patch in mail list. There are 2 bugs got fixed. Fixed issues: 1. Guest qemu processor will be defunct process by be killed https://bugzilla.kernel.org/show_bug.cgi?id=23612 2. [SR] qemu return form migrate command spend long time https://sourceforge.net/tracker/?func=detailaid=2942079group_id=180599atid=893831 Four old Issues: 1. ltp diotest running time is 2.54 times than before https://sourceforge.net/tracker/?func=detailaid=2723366group_id=180599atid=893831 2. 32bits Rhel5/FC6 guest may fail to reboot after installation https://sourceforge.net/tracker/?func=detailatid=893831aid=1991647group_id=180599 3. perfctr wrmsr warning when booting 64bit RHEl5.3 https://sourceforge.net/tracker/?func=detailaid=2721640group_id=180599atid=893831 4. [KVM] Noacpi Windows guest can not boot up on 32bit KVM host https://bugzilla.kernel.org/show_bug.cgi?id=21402 Best Regards, Xudong Hao-- 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 Test report, kernel 9ee00410... qemu b377474e...
Hi, all, This is KVM test result against kvm.git 9ee00410d82a7c5cab5ae347d97fbf8a95c55506 based on kernel 2.6.37-rc2, and qemu-kvm.git b377474e589e5a1fe2abc7b13fafa8bad802637a. We found a new bug which qemu processor will be defunct process by be killed, this bug block nightly testing, we got comments it would be fixed on 2.6.37-rc4. So there will not nightly testing until rc4. New issue: 1. Guest qemu processor will be defunct process by be killed https://bugzilla.kernel.org/show_bug.cgi?id=23612 Five old Issues: 1. ltp diotest running time is 2.54 times than before https://sourceforge.net/tracker/?func=detailaid=2723366group_id=180599atid=893831 2. 32bits Rhel5/FC6 guest may fail to reboot after installation https://sourceforge.net/tracker/?func=detailatid=893831aid=1991647group_id=180599 3. perfctr wrmsr warning when booting 64bit RHEl5.3 https://sourceforge.net/tracker/?func=detailaid=2721640group_id=180599atid=893831 4. [SR] qemu return form migrate command spend long time https://sourceforge.net/tracker/?func=detailaid=2942079group_id=180599atid=893831 5. [KVM] Noacpi Windows guest can not boot up on 32bit KVM host https://bugzilla.kernel.org/show_bug.cgi?id=21402 Best Regards, Xudong Hao-- 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 Test report, kernel 1414115... qemu 013ddf74...
9 8 0 01
:one_pcie_up_64_g32e 1 1 0 00
:lm_pcie_smp_64_g32e 2 1 0 01
:hp_pcie_smp_nomsi_64_g3 1 1 0 00
:one_pcie_scp_64_g32e 1 1 0 00
:one_pcie_smp_nomsi_64_g 1 1 0 00
:hp_pcie_smp_64_g32e 1 1 0 00
:one_pcie_smp_64_g32e 1 1 0 00
:hp_pcie_up_64_g32e1 1 0 00
gtest_ept_vpid 11 10 1 00
:boot_up_acpi_64_g32e 1 1 0 00
:boot_base_kernel_64_g32 1 1 0 00
:boot_up_acpi_win2k3_64_ 1 1 0 00
:kb_nightly_64_g32e1 1 0 00
:boot_up_vista_64_g32e 1 1 0 00
:ltp_nightly_64_g32e 1 0 1 00
:boot_smp_win2008_64_g32 1 1 0 00
:boot_up_acpi_xp_64_g32e 1 1 0 00
:boot_smp_acpi_win2k3_64 1 1 0 00
:boot_smp_win7_ent_64_g3 1 1 0 00
:boot_smp_acpi_xp_64_g32 1 1 0 00
sriov_ept_vpid 5 5 0 00
:one_vf_up_64_g32e 1 1 0 00
:hp_vf_up_64_g32e 1 1 0 00
:hp_vf_smp_64_g32e 1 1 0 00
:one_vf_smp_64_g32e1 1 0 00
:two_dev_smp_64_g32e 1 1 0 00
=
Total 52 50 1 01
Best Regards,
Xudong Hao
---BeginMessage---
(Add CC to k...@vger)
(2010/10/12 10:52), Hao, Xudong wrote:
Hi,
Currently qemu-kvm build fail on RHEL5 with gcc 4.1.2, build can pass on
Fedora11 with gcc 4.4.1, can anybody look on RHEL5 system?
Gcc: 4.1.2
system: RHEL5.1
qemu-kvm: 85566812a4f8cae721fea0224e05a7e75c08c5dd
...
LINK qemu-img
LINK qemu-io
CClibhw64/virtio-9p-local.o
cc1: warnings being treated as errors
/home/source/qemu-kvm/hw/virtio-9p-local.c: In function 'local_utimensat':
/home/source/qemu-kvm/hw/virtio-9p-local.c:479: warning: implicit declaration
of function 'utimensat'
/home/source/qemu-kvm/hw/virtio-9p-local.c:479: warning: nested extern
declaration of 'utimensat'
make[1]: *** [virtio-9p-local.o] Error 1
make: *** [subdir-libhw64] Error 2
Best Regards,
Xudong Hao
It seems that this issue is caused by the old glibc.
Though I don't know well about virtio-9p and suppose there
should be better fix, I confirmed that following change
removed the warnings.
Thanks,
H.Seto
=
[PATCH] virtio-9p: fix build on !CONFIG_UTIMENSAT
This removes following warnings on RHEL5, which has utimensat syscall
but has old glibc that doesn't have support for it:
hw/virtio-9p-local.c: In function 'local_utimensat':
hw/virtio-9p-local.c:479: warning: implicit declaration of function 'utimensat'
hw/virtio-9p-local.c:479: warning: nested extern declaration of 'utimensat'
and
hw/virtio-9p.c: In function 'v9fs_setattr_post_chmod':
hw/virtio-9p.c:1410: error: 'UTIME_NOW' undeclared (first use in this function)
hw/virtio-9p.c:1410: error: (Each undeclared identifier is reported only once
hw/virtio-9p.c:1410: error: for each function it appears in.)
hw/virtio-9p.c:1413: error: 'UTIME_OMIT' undeclared (first use in this function)
hw/virtio-9p.c: In function 'v9fs_wstat_post_chmod':
hw/virtio-9p.c:2905: error: 'UTIME_OMIT' undeclared (first use in this function)
Signed-off-by: Hidetoshi Seto seto.hideto...@jp.fujitsu.com
---
hw/virtio-9p-local.c |8
hw/virtio-9p.c |9 +
2 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/hw/virtio-9p-local.c b/hw/virtio-9p-local.c
index 57f9243..e075c27 100644
--- a/hw/virtio-9p-local.c
+++ b/hw/virtio-9p-local.c
@@ -18,6 +18,9 @@
#include sys/socket.h
#include sys/un.h
#include attr/xattr.h
+#ifndef CONFIG_UTIMENSAT
+#include syscall.h
+#endif
static const char *rpath(FsContext *ctx, const char *path)
{
@@ -476,7 +479,12 @@ static int local_chown(FsContext *fs_ctx, const char
*path, FsCred *credp)
static int local_utimensat(FsContext *s, const char *path,
const struct timespec *buf)
{
+#ifndef CONFIG_UTIMENSAT
+return syscall(SYS_utimensat, AT_FDCWD, rpath(s, path), buf,
+ AT_SYMLINK_NOFOLLOW);
+#else
return utimensat(AT_FDCWD, rpath(s, path), buf, AT_SYMLINK_NOFOLLOW);
+#endif
}
static int local_remove(FsContext *ctx, const char *path)
diff --git a/hw/virtio-9p.c b/hw/virtio-9p.c
index 32fa3bc..efe5c51 100644
--- a/hw/virtio-9p.c
+++ b/hw/virtio-9p.c
@@ -1393,6 +1393,15 @@ out:
qemu_free(vs
RE: [Qemu-devel] qemu-kvm build issue on RHEL5.1
Hidetoshi Seto wrote:
(Add CC to k...@vger)
(2010/10/12 10:52), Hao, Xudong wrote:
Hi,
Currently qemu-kvm build fail on RHEL5 with gcc 4.1.2, build can
pass on Fedora11 with gcc 4.4.1, can anybody look on RHEL5 system?
Gcc: 4.1.2
system: RHEL5.1
qemu-kvm: 85566812a4f8cae721fea0224e05a7e75c08c5dd
...
LINK qemu-img
LINK qemu-io
CClibhw64/virtio-9p-local.o
cc1: warnings being treated as errors
/home/source/qemu-kvm/hw/virtio-9p-local.c: In function
'local_utimensat': /home/source/qemu-kvm/hw/virtio-9p-local.c:479:
warning: implicit declaration of function 'utimensat'
/home/source/qemu-kvm/hw/virtio-9p-local.c:479: warning: nested
extern declaration of 'utimensat'
make[1]: *** [virtio-9p-local.o] Error 1
make: *** [subdir-libhw64] Error 2
Best Regards,
Xudong Hao
It seems that this issue is caused by the old glibc.
Though I don't know well about virtio-9p and suppose there
should be better fix, I confirmed that following change
removed the warnings.
Thanks,
H.Seto
=
[PATCH] virtio-9p: fix build on !CONFIG_UTIMENSAT
This removes following warnings on RHEL5, which has utimensat syscall
but has old glibc that doesn't have support for it:
hw/virtio-9p-local.c: In function 'local_utimensat':
hw/virtio-9p-local.c:479: warning: implicit declaration of function
'utimensat' hw/virtio-9p-local.c:479: warning: nested extern
declaration of 'utimensat'
and
hw/virtio-9p.c: In function 'v9fs_setattr_post_chmod':
hw/virtio-9p.c:1410: error: 'UTIME_NOW' undeclared (first use in this
function) hw/virtio-9p.c:1410: error: (Each undeclared identifier is
reported only once hw/virtio-9p.c:1410: error: for each function it
appears in.)
hw/virtio-9p.c:1413: error: 'UTIME_OMIT' undeclared (first use in
this function) hw/virtio-9p.c: In function 'v9fs_wstat_post_chmod':
hw/virtio-9p.c:2905: error: 'UTIME_OMIT' undeclared (first use in
this function)
Signed-off-by: Hidetoshi Seto seto.hideto...@jp.fujitsu.com
---
hw/virtio-9p-local.c |8
hw/virtio-9p.c |9 +
2 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/hw/virtio-9p-local.c b/hw/virtio-9p-local.c
index 57f9243..e075c27 100644
--- a/hw/virtio-9p-local.c
+++ b/hw/virtio-9p-local.c
@@ -18,6 +18,9 @@
#include sys/socket.h
#include sys/un.h
#include attr/xattr.h
+#ifndef CONFIG_UTIMENSAT
+#include syscall.h
+#endif
static const char *rpath(FsContext *ctx, const char *path)
{
@@ -476,7 +479,12 @@ static int local_chown(FsContext *fs_ctx, const
char *path, FsCred *credp) static int local_utimensat(FsContext *s,
const char *path, const struct timespec *buf)
{
+#ifndef CONFIG_UTIMENSAT
+return syscall(SYS_utimensat, AT_FDCWD, rpath(s, path), buf,
+ AT_SYMLINK_NOFOLLOW);
+#else
return utimensat(AT_FDCWD, rpath(s, path), buf,
AT_SYMLINK_NOFOLLOW); +#endif
}
static int local_remove(FsContext *ctx, const char *path)
diff --git a/hw/virtio-9p.c b/hw/virtio-9p.c
index 32fa3bc..efe5c51 100644
--- a/hw/virtio-9p.c
+++ b/hw/virtio-9p.c
@@ -1393,6 +1393,15 @@ out:
qemu_free(vs);
}
+#ifndef CONFIG_UTIMENSAT
+#ifndef UTIME_NOW
+# define UTIME_NOW ((1l 30) - 1l)
+#endif
+#ifndef UTIME_OMIT
+# define UTIME_OMIT ((1l 30) - 2l)
+#endif
+#endif
+
static void v9fs_setattr_post_chmod(V9fsState *s, V9fsSetattrState
*vs, int err) {
if (err == -1) {
Seto, your patch works fine for me, verified on my RHEL5 system.
Thanks,
Xudong--
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 Test report, kernel e6a9246... qemu 94f964d...
Avi Kivity wrote: On 09/06/2010 06:05 AM, Hao, Xudong wrote: New issue 1. [KVM] Linux guest is too slow to boot up https://bugzilla.kernel.org/show_bug.cgi?id=17882 I'll take a look. What kernel is running in the guest? What distribution? Guest run on RHEL5u3 with it's default kernel 2.6.18. Thanks, Xudong-- 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 Test report, kernel e6a9246... qemu 94f964d...
Avi Kivity wrote: On 09/06/2010 09:59 AM, Hao, Xudong wrote: Avi Kivity wrote: On 09/06/2010 06:05 AM, Hao, Xudong wrote: New issue 1. [KVM] Linux guest is too slow to boot up https://bugzilla.kernel.org/show_bug.cgi?id=17882 I'll take a look. What kernel is running in the guest? What distribution? Guest run on RHEL5u3 with it's default kernel 2.6.18. Unable to reproduce - R5u3 i386 guest installed and booted, x86_64 booted from cd, all as expected. Do you use EPT or shadow mode? This issue only exist on shadow mode. But if we assign one pci device to guest, both EPT and shadow mode can reproduce. Thanks, Xudong-- 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 Test report, kernel e6a9246... qemu 94f964d...
Avi Kivity wrote: On 09/06/2010 11:08 AM, Hao, Xudong wrote: Unable to reproduce - R5u3 i386 guest installed and booted, x86_64 booted from cd, all as expected. Do you use EPT or shadow mode? This issue only exist on shadow mode. Shadow. What's your command line? qemu-system-x86_64 -m 1024 -smp 1 -hda /imagepath/RHEL5u3.img Thanks, Xudong-- 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] ivshmem: remove unnecessary checks for unsigned
Avi Kivity wrote: On 09/03/2010 05:54 AM, Hidetoshi Seto wrote: Oops, since I've registered qemu-kvm ML but not qemu-devel ML, I could not noticed that Jes have already posted same patch to qemu-devel. Now build of ivshmem is enabled only on KVM systems, please apply this patch to qemu-kvm.git asap. This was already applied to qemu.git; I'll pull it into qemu-kvm.git to fix the build. Qemu-kvm 6ee63ef38696aa3b0518f6aa6b85bc111ba7ca4e can build successfully now, thanks all. -Xudong -- 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 Test report, kernel e6a9246... qemu 94f964d...
Hi, all, This is KVM test result against kvm.git: e6a9246aa397aaced11f3870bfd0766ab48075c4 and qemu-kvm.git: 94f964d08ebdcc74999d4cff74bc5f7aee84fc5. We found a regression issue that linux guest is very slow to boot up(about 20 minutes). and I checked with a old kvm commit 61e45fb2806b3615ede47013c06fa2e95192e660 and new qemu-kvm, the linux guest boot fine. Fixed issues: 1. [KVM VT-d] Guest fail to boot up with one additional device assignment https://bugzilla.kernel.org/show_bug.cgi?id=16437 2. 32PAE Windows guest is slow to boot with acpi on shadow https://sourceforge.net/tracker/?func=detailaid=2976863group_id=180599atid=893831 New issue 1. [KVM] Linux guest is too slow to boot up https://bugzilla.kernel.org/show_bug.cgi?id=17882 Five old Issues: 1. ltp diotest running time is 2.54 times than before https://sourceforge.net/tracker/?func=detailaid=2723366group_id=180599atid=893831 2. 32bits Rhel5/FC6 guest may fail to reboot after installation https://sourceforge.net/tracker/?func=detailatid=893831aid=1991647group_id=180599 3. perfctr wrmsr warning when booting 64bit RHEl5.3 https://sourceforge.net/tracker/?func=detailaid=2721640group_id=180599atid=893831 4. [SR] qemu return form migrate command spend long time https://sourceforge.net/tracker/?func=detailaid=2942079group_id=180599atid=893831 Test environment Platform A Westmere-EP CPU 8 Memory size 12G = Total PassFailNoResult Crash = control_panel_ept_vpid 12 12 0 00 control_panel_vpid 3 0 3 00 control_panel 3 0 3 00 control_panel_ept 4 4 0 00 gtest_vpid 1 0 1 00 gtest_ept 1 1 0 00 gtest 3 2 1 00 vtd_ept_vpid8 0 8 00 gtest_ept_vpid 11 11 0 00 sriov_ept_vpid 5 0 5 00 = control_panel_ept_vpid 12 12 0 00 :KVM_LM_Continuity_64_g3 1 1 0 00 :KVM_four_dguest_64_g32e 1 1 0 00 :KVM_1500M_guest_64_gPAE 1 1 0 00 :KVM_LM_SMP_64_g32e1 1 0 00 :KVM_SR_SMP_64_g32e1 1 0 00 :KVM_linux_win_64_g32e 1 1 0 00 :KVM_1500M_guest_64_g32e 1 1 0 00 :KVM_two_winxp_64_g32e 1 1 0 00 :KVM_256M_guest_64_gPAE1 1 0 00 :KVM_SR_Continuity_64_g3 1 1 0 00 :KVM_256M_guest_64_g32e1 1 0 00 :KVM_four_sguest_64_g32e 1 1 0 00 control_panel_vpid 3 0 3 00 :KVM_linux_win_64_g32e 1 0 1 00 :KVM_1500M_guest_64_g32e 1 0 1 00 :KVM_1500M_guest_64_gPAE 1 0 1 00 control_panel 3 0 3 00 :KVM_1500M_guest_64_g32e 1 0 1 00 :KVM_1500M_guest_64_gPAE 1 0 1 00 :KVM_LM_SMP_64_g32e1 0 1 00 control_panel_ept 4 4 0 00 :KVM_linux_win_64_g32e 1 1 0 00 :KVM_1500M_guest_64_g32e 1 1 0 00 :KVM_1500M_guest_64_gPAE 1 1 0 00 :KVM_LM_SMP_64_g32e1 1 0 00 gtest_vpid 1 0 1 00 :boot_smp_win7_ent_64_g3 1 0 1 00 gtest_ept 1 1 0 00 :boot_smp_win7_ent_64_g3 1 1 0 00 gtest 3 2 1 00 :boot_smp_win2008_64_g32 1 1 0 00 :boot_smp_win7_ent_64_gP 1 0 1 00 :boot_smp_vista_64_g32e1 1 0 00 vtd_ept_vpid8 0 8 00 :one_pcie_up_64_g32e 1 0 1 00 :hp_pcie_smp_nomsi_64_g3 1 0 1 00 :lm_pcie_smp_64_g32e 1 0 1 00 :one_pcie_scp_64_g32e 1 0 1 00
qemu-kvm build fail
Hi, Latest qemu-kvm build fail with a merge 4813f440385bfc751d1c91752709b4457ed803e2. The error happen on commit 6cbf4c8c6416237e9c323661b87d60792a9d51af. gcc version 4.1.2 ... CCx86_64-softmmu/monitor.o CCx86_64-softmmu/vl.o CCx86_64-softmmu/ivshmem.o cc1: warnings being treated as errors /home/qemu-kvm/hw/ivshmem.c: In function 'ivshmem_io_writel': /home/qemu-kvm/hw/ivshmem.c:202: warning: comparison is always false due to limited range of data type /home/qemu-kvm/hw/ivshmem.c:208: warning: comparison is always true due to limited range of data type make[1]: *** [ivshmem.o] Error 1 make: *** [subdir-x86_64-softmmu] Error 2 Best Regards, Xudong Hao -- 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: latest KVM tree build fail on 32bit system
Avi Kivity wrote: On 08/26/2010 08:42 AM, Hao, Xudong wrote: Hi, did anyone see latest kvm build fail on 32bit system? kvm commit: 152d921348ee2ac7bb73d599c5796a027f0a660c gcc version 4.1.2 ... LD arch/x86/boot/setup.elf OBJCOPY arch/x86/boot/setup.bin OBJCOPY arch/x86/boot/vmlinux.bin BUILD arch/x86/boot/bzImage Root device is (8, 2) Setup is 14008 bytes (padded to 14336 bytes). System is 2565 kB CRC 72558b30 Kernel: arch/x86/boot/bzImage is ready (#3) Building modules, stage 2. MODPOST 958 modules WARNING: drivers/block/cpqarray.o(.devinit.text+0x20d): Section mismatch in reference from the function cpqarray_register_ctlr() to the function .init.text:ida_procinit() The function __devinit cpqarray_register_ctlr() references a function __init ida_procinit(). If ida_procinit is only used by cpqarray_register_ctlr then annotate ida_procinit with a matching annotation. WARNING: net/bluetooth/rfcomm/rfcomm.o(.init.text+0xac): Section mismatch in reference from the function init_module() to the function .exit.text:rfcomm_cleanup_ttys() The function __init init_module() references a function __exit rfcomm_cleanup_ttys(). This is often seen when error handling in the init function uses functionality in the exit path. The fix is often to remove the __exit annotation of rfcomm_cleanup_ttys() so it may be used outside an exit section. ERROR: __udivdi3 [arch/x86/kvm/kvm.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 It's a bug in the new TSC stuff. I'll post a patch. Great, thanks. -Xudong-- 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
latest KVM tree build fail on 32bit system
Hi, did anyone see latest kvm build fail on 32bit system? kvm commit: 152d921348ee2ac7bb73d599c5796a027f0a660c gcc version 4.1.2 ... LD arch/x86/boot/setup.elf OBJCOPY arch/x86/boot/setup.bin OBJCOPY arch/x86/boot/vmlinux.bin BUILD arch/x86/boot/bzImage Root device is (8, 2) Setup is 14008 bytes (padded to 14336 bytes). System is 2565 kB CRC 72558b30 Kernel: arch/x86/boot/bzImage is ready (#3) Building modules, stage 2. MODPOST 958 modules WARNING: drivers/block/cpqarray.o(.devinit.text+0x20d): Section mismatch in reference from the function cpqarray_register_ctlr() to the function .init.text:ida_procinit() The function __devinit cpqarray_register_ctlr() references a function __init ida_procinit(). If ida_procinit is only used by cpqarray_register_ctlr then annotate ida_procinit with a matching annotation. WARNING: net/bluetooth/rfcomm/rfcomm.o(.init.text+0xac): Section mismatch in reference from the function init_module() to the function .exit.text:rfcomm_cleanup_ttys() The function __init init_module() references a function __exit rfcomm_cleanup_ttys(). This is often seen when error handling in the init function uses functionality in the exit path. The fix is often to remove the __exit annotation of rfcomm_cleanup_ttys() so it may be used outside an exit section. ERROR: __udivdi3 [arch/x86/kvm/kvm.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 Best Regards, Xudong Hao -- 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] build fail on i386 RHEL5u4
Avi Kivity wrote: On 08/16/2010 11:46 AM, Avi Kivity wrote: On 08/16/2010 04:27 AM, Hao, Xudong wrote: Appears to be a gcc bug. I opened https://bugzilla.redhat.com/show_bug.cgi?id=624279 to track this. Meanwhile, installing the gcc44 package and building with it (./configure --cc=gcc44) appears to work. Avi, Gcc44 works for me. I saw Jakub marked this bug closed with only i486 support that, but RHEL5 use -march=i386, so do we have ongoing fix on qemu-kvm? Should be easy to add a ./configure test for this. Or, just use --extra-cflags=-march=i686 or similar. Yes, both of two methods can work. Thanks, Xudong-- 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] build fail on i386 RHEL5u4
Avi Kivity wrote: On 08/11/2010 04:49 AM, Hao, Xudong wrote: Hi, Recently I build qemu-kvm on 32bit RHEL5u4/RHEL5u5, it will fail on fuction vhost_dev_sync_region. But RHEL5u1 system is fine to build. Did anyone meet similar issue? qemu-kvm commit: 59d71ddb432db04b57ee2658ce50a3e35d7db97e build error: ... CCx86_64-softmmu/i8254.o CCx86_64-softmmu/i8254-kvm.o CCx86_64-softmmu/device-assignment.o LINK x86_64-softmmu/qemu-system-x86_64 vhost.o: In function `vhost_dev_sync_region': /home/source/qemu-kvm/hw/vhost.c:47: undefined reference to `__sync_fetch_and_and_4' collect2: ld returned 1 exit status make[1]: *** [qemu-system-x86_64] Error 1 make: *** [subdir-x86_64-softmmu] Error 2 Appears to be a gcc bug. I opened https://bugzilla.redhat.com/show_bug.cgi?id=624279 to track this. Meanwhile, installing the gcc44 package and building with it (./configure --cc=gcc44) appears to work. Avi, Gcc44 works for me. I saw Jakub marked this bug closed with only i486 support that, but RHEL5 use -march=i386, so do we have ongoing fix on qemu-kvm? Thanks, Xudong-- 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
[qemu-kvm] build fail on i386 RHEL5u4
Hi, Recently I build qemu-kvm on 32bit RHEL5u4/RHEL5u5, it will fail on fuction vhost_dev_sync_region. But RHEL5u1 system is fine to build. Did anyone meet similar issue? qemu-kvm commit: 59d71ddb432db04b57ee2658ce50a3e35d7db97e build error: ... CCx86_64-softmmu/i8254.o CCx86_64-softmmu/i8254-kvm.o CCx86_64-softmmu/device-assignment.o LINK x86_64-softmmu/qemu-system-x86_64 vhost.o: In function `vhost_dev_sync_region': /home/source/qemu-kvm/hw/vhost.c:47: undefined reference to `__sync_fetch_and_and_4' collect2: ld returned 1 exit status make[1]: *** [qemu-system-x86_64] Error 1 make: *** [subdir-x86_64-softmmu] Error 2 Best Regards, Xudong Hao -- 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: pci_add after migration
Qemu-kvm tree has already fixed this issue: commit 4cf3e6f3d85492f20a773dd6c9068ab89ba24a18 Author: Alex Williamson alex.william...@redhat.com Date: Wed Jun 2 10:58:29 2010 -0600 acpi_piix4: save gpe and pci hotplug slot status PCI hotplug currently doesn't work after a migration because we don't migrate the enable bits of the GPE state. Pull hotplug structs into vmstate. Signed-off-by: Alex Williamson alex.william...@redhat.com Signed-off-by: Anthony Liguori aligu...@us.ibm.com Hunter Pitelka wrote: Hi, I'm trying to resume a VM from a migration and hotplug a PCI device, however I can't get it working. PCI hotplugging after booting the guest works fine, but if I migrate the guest, I can no longer hotplug. I'm using qemu/kvm out of the ubuntu 10.4 repositories. I am migrating using `migrate exec: dd of=statefile.dd` and resuming with -incoming exec: dd if=statefile.dd on the command line. The pci_add command Im running is `pci_add auto storage file=file.img,if=scsi,media=disk,snapshot=off` Which reports 'OK' always, but running `lspci` in the guest after a migration shows no new devices. I've been banging my head against the wall about this for a while now, so any help is appreciated. Thanks. ~Hunter Thanks, Xudong-- 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: VT-d regression issue
Alex Williamson wrote: On Sat, 2010-07-31 at 16:33 +0800, Hao, Xudong wrote: Alex Williamson wrote: On Thu, 2010-07-22 at 16:03 +0300, Gleb Natapov wrote: On Thu, Jul 22, 2010 at 08:32:31PM +0800, Hao, Xudong wrote: Well, this patch works fine for me. Looks like userspace problem then. Userspace relied on something that was not guarantied by the kernel (access to read only page forwarded to userspace as MMOI). I just submitted a set of patches that should fix this using the slow mapping path for option ROMs. Thanks, Alex, I saw your PCI option ROM fixes patches in kvm. Does qemu-kvm have corresponding fix for this issue either? kvm userspace and qemu-kvm are the same thing. Device assignment currently only lives in the kvm userspace, it it not merged into upstream qemu. Thanks, Alex Ok, I got it, your patch is for userspace. Thanks, Xudong-- 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: VT-d regression issue
Alex Williamson wrote: On Thu, 2010-07-22 at 16:03 +0300, Gleb Natapov wrote: On Thu, Jul 22, 2010 at 08:32:31PM +0800, Hao, Xudong wrote: Well, this patch works fine for me. Looks like userspace problem then. Userspace relied on something that was not guarantied by the kernel (access to read only page forwarded to userspace as MMOI). I just submitted a set of patches that should fix this using the slow mapping path for option ROMs. Thanks, Alex, I saw your PCI option ROM fixes patches in kvm. Does qemu-kvm have corresponding fix for this issue either? Thanks, Xudong-- 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 Test report, kernel 14e84ff... qemu 9237b2c...
Hi, all, This is KVM test result against kvm.git: 14e84ff8459416648f4f789e7665f6a8e95e and qemu-kvm.git: 9237b2c094a2813324b1cff75c8b8d4653a8b508. We found a VT-d regression issue, KVM guest can not boot with additional NIC device assigned. Gleb has helped to root caused it to qemu-kvm userspace issue, his patch works fine for this issue. Fixed issues: 1. host panic on kernel 2.6.34 https://bugzilla.kernel.org/show_bug.cgi?id=16082 2. qemu fail to parse command line with -pcidevice B:D.F https://bugs.launchpad.net/qemu/+bug/597932 3. qemu fail to parse command -net none https://bugs.launchpad.net/qemu/+bug/599617 New issue(regression) 1. [KVM VT-d] Guest fail to boot up with one additional device assignment https://bugzilla.kernel.org/show_bug.cgi?id=16437 [Comments from Gleb]: Seems like userspace problem then. Userspace relied on something that was not guarantied by the kernel (access to read only page forwarded to userspace as MMOI) Five old Issues: 1. 32PAE Windows guest is slow to boot with acpi on shadow https://sourceforge.net/tracker/?func=detailaid=2976863group_id=180599atid=893831 2. ltp diotest running time is 2.54 times than before https://sourceforge.net/tracker/?func=detailaid=2723366group_id=180599atid=893831 3. 32bits Rhel5/FC6 guest may fail to reboot after installation https://sourceforge.net/tracker/?func=detailatid=893831aid=1991647group_id=180599 4. perfctr wrmsr warning when booting 64bit RHEl5.3 https://sourceforge.net/tracker/?func=detailaid=2721640group_id=180599atid=893831 5. [SR] qemu return form migrate command spend long time https://sourceforge.net/tracker/?func=detailaid=2942079group_id=180599atid=893831 Test environment Platform A Stoakley/Clovertown CPU 4 Memory size 8G Total PassFailNoResult Crash = control_panel 17 15 2 00 gtest 23 18 5 00 = control_panel 17 15 2 00 :KVM_4G_guest_64_g32e 1 1 0 00 :KVM_four_sguest_64_gPAE 1 1 0 00 :KVM_LM_SMP_64_g32e1 1 0 00 :KVM_linux_win_64_gPAE 1 1 0 00 :KVM_LM_SMP_64_gPAE1 1 0 00 :KVM_SR_Continuity_64_gP 1 1 0 00 :KVM_four_sguest_64_g32e 1 1 0 00 :KVM_four_dguest_64_gPAE 1 1 0 00 :KVM_SR_SMP_64_gPAE1 1 0 00 :KVM_LM_Continuity_64_g3 1 0 1 00 :KVM_1500M_guest_64_gPAE 1 1 0 00 :KVM_LM_Continuity_64_gP 1 1 0 00 :KVM_1500M_guest_64_g32e 1 1 0 00 :KVM_SR_Continuity_64_g3 1 0 1 00 :KVM_two_winxp_64_gPAE 1 1 0 00 :KVM_256M_guest_64_gPAE1 1 0 00 :KVM_256M_guest_64_g32e1 1 0 00 gtest 23 18 5 00 :boot_up_acpi_64_gPAE 1 1 0 00 :boot_up_noacpi_xp_64_gP 1 1 0 00 :boot_base_kernel_64_gPA 1 1 0 00 :boot_up_vista_64_g32e 1 1 0 00 :boot_smp_acpi_win2k3_64 1 0 1 00 :kb_nightly_64_gPAE1 1 0 00 :boot_up_acpi_xp_64_g32e 1 1 0 00 :boot_smp_win7_ent_64_g3 1 1 0 00 :boot_smp_acpi_xp_64_gPA 1 0 1 00 :boot_smp_acpi_xp_64_g32 1 1 0 00 :boot_smp_vista_64_gPAE1 1 0 00 :boot_up_acpi_64_g32e 1 1 0 00 :boot_base_kernel_64_g32 1 1 0 00 :kb_nightly_64_g32e1 1 0 00 :boot_up_acpi_win2k3_64_ 1 1 0 00 :boot_up_win2008_64_gPAE 1 0 1 00 :ltp_nightly_64_g32e 1 0 1 00 :boot_smp_win2008_64_g32 1 1 0 00 :boot_up_vista_64_gPAE 1 1 0 00 :ltp_nightly_64_gPAE 1 0 1 00 :boot_smp_acpi_win2k3_64 1 1 0 00 :boot_up_noacpi_win2k3_6 1 1 0 00 :boot_smp_win7_ent_64_gP 1 1 0 00
VT-d regression issue
Hi, all On KVM commit cb7eaecb3389c7fa2490ea1bee8f10cfa5df30d4, I met a kvm_run return fasle when assign additional NIC device to KVM guest, but onboard NIC works fine. command: qemu-system-x86_64 -m 256 -smp 2 -device pci-assign,host=01:00.0 -net none -hda /image/path/guest.img host print: kvm_run: Bad address kvm_run returned -14 platform: Westmere-HEDT NIC device: 01:00.0 Ethernet controller: Intel Corporation 82572EI Gigabit Ethernet Controller (Copper) (rev 06) VT-d works fine on KVM commit 8dea5648467102184c65d61cf2be6e0fbfa41060 and new qemu-kvm. https://bugzilla.kernel.org/show_bug.cgi?id=16437 Best Regards, Xudong Hao -- 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: VT-d regression issue
[r...@vt-nhm1 ~]# lspci -vv -s 01:00.0 01:00.0 Ethernet controller: Intel Corporation 82572EI Gigabit Ethernet Controller (Copper) (rev 06) Subsystem: Intel Corporation PRO/1000 PT Desktop Adapter Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Interrupt: pin A routed to IRQ 16 Region 0: Memory at d3c2 (32-bit, non-prefetchable) [size=128K] Region 1: Memory at d3c0 (32-bit, non-prefetchable) [size=128K] Region 2: I/O ports at 5000 [size=32] Expansion ROM at d3e0 [size=128K] Capabilities: [c8] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=1 PME- Capabilities: [d0] MSI: Mask- 64bit+ Count=1/1 Enable- Address: fee00418 Data: Capabilities: [e0] Express (v1) Endpoint, MSI 00 DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s 512ns, L1 64us ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Latency L0 4us, L1 64us ClockPM- Surprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- Capabilities: [100] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq+ ACSViol- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr- CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr- AERCap: First Error Pointer: 14, GenCap- CGenEn- ChkCap- ChkEn- Capabilities: [140] Device Serial Number 82-ff-04-ff-ff-21-1b-00 Kernel driver in use: pci-stub Kernel modules: e1000e Gleb Natapov wrote: On Thu, Jul 22, 2010 at 03:57:55PM +0800, Hao, Xudong wrote: Hi, all On KVM commit cb7eaecb3389c7fa2490ea1bee8f10cfa5df30d4, I met a kvm_run return fasle when assign additional NIC device to KVM guest, but onboard NIC works fine. command: qemu-system-x86_64 -m 256 -smp 2 -device pci-assign,host=01:00.0 -net none -hda /image/path/guest.img Which version of qemu-kvm is this? host print: kvm_run: Bad address kvm_run returned -14 platform: Westmere-HEDT NIC device: 01:00.0 Ethernet controller: Intel Corporation 82572EI Gigabit Ethernet Controller (Copper) (rev 06) lspci -vv -s 01:00.0? VT-d works fine on KVM commit 8dea5648467102184c65d61cf2be6e0fbfa41060 and new qemu-kvm. https://bugzilla.kernel.org/show_bug.cgi?id=16437 Best Regards, Xudong Hao -- 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 Thanks, Xudong-- 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: VT-d regression issue
Patch did not work, qemu stoped @
Can you try this patch for qemu-kvm please?
diff --git a/hw/device-assignment.c b/hw/device-assignment.c
index 2bba22f..7240985 100644
--- a/hw/device-assignment.c
+++ b/hw/device-assignment.c
@@ -238,9 +238,10 @@ static void
assigned_dev_iomem_map_slow(PCIDevice *pci_dev, int region_num,
DEBUG(%s, slow map\n); if (region_num == PCI_ROM_SLOT)
m = cpu_register_io_memory(slow_bar_read, NULL, region);
-else
+else {
m = cpu_register_io_memory(slow_bar_read, slow_bar_write,
region); -cpu_register_physical_memory(e_phys, e_size, m);
+cpu_register_physical_memory(e_phys, e_size, m);
+}
/* MSI-X MMIO page */
if ((e_size 0)
Thanks,
Xudong--
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: VT-d regression issue
Gleb,
This patch does not work either, qemu stoped @ Starting Seabios.
Can you try this patch for qemu-kvm please?
diff --git a/hw/device-assignment.c b/hw/device-assignment.c
index 2bba22f..7240985 100644
--- a/hw/device-assignment.c
+++ b/hw/device-assignment.c
@@ -238,9 +238,10 @@ static void
assigned_dev_iomem_map_slow(PCIDevice *pci_dev, int region_num,
DEBUG(%s, slow map\n); if (region_num == PCI_ROM_SLOT)
m = cpu_register_io_memory(slow_bar_read, NULL, region);
-else
+else {
m = cpu_register_io_memory(slow_bar_read, slow_bar_write,
region); -cpu_register_physical_memory(e_phys, e_size, m);
+cpu_register_physical_memory(e_phys, e_size, m);
+}
/* MSI-X MMIO page */
if ((e_size 0)
Thanks,
Xudong--
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: VT-d regression issue
Well, this patch works fine for me.
Gleb Natapov wrote:
On Thu, Jul 22, 2010 at 07:11:34PM +0800, Hao, Xudong wrote:
Gleb,
This patch does not work either, qemu stoped @ Starting Seabios.
And this one?
diff --git a/hw/device-assignment.c b/hw/device-assignment.c
index 2bba22f..b7e7dc0 100644
--- a/hw/device-assignment.c
+++ b/hw/device-assignment.c
@@ -238,9 +238,10 @@ static void
assigned_dev_iomem_map_slow(PCIDevice *pci_dev, int region_num,
DEBUG(%s, slow map\n); if (region_num == PCI_ROM_SLOT)
m = cpu_register_io_memory(slow_bar_read, NULL, region);
-else
+else {
m = cpu_register_io_memory(slow_bar_read, slow_bar_write,
region); -cpu_register_physical_memory(e_phys, e_size, m);
+cpu_register_physical_memory(e_phys, e_size, m);
+}
/* MSI-X MMIO page */
if ((e_size 0)
@@ -272,7 +273,8 @@ static void assigned_dev_iomem_map(PCIDevice
*pci_dev, int region_num, if (region_num == PCI_ROM_SLOT)
flags |= IO_MEM_ROM;
-cpu_register_physical_memory(e_phys, e_size,
region-memory_index | flags); +if (region_num !=
PCI_ROM_SLOT) + cpu_register_physical_memory(e_phys, e_size,
region-memory_index | flags);
/* deal with MSI-X MMIO page */
if (real_region-base_addr = r_dev-msix_table_addr
Thanks,
Xudong--
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
Biweekly KVM Test report, kernel cfe149e... qemu bc3a9cc...
Hi, all, This is KVM biweekly test result against kvm.git: cfe149e91b823a75eb7a86e81bfa7c6fce42c744 and qemu-kvm.git: bc3a9ccc5ddea4c0c713ef6fb3c11d9a88cec169. There is 2 qemu issues found, the first one is qemu fail to parse B:D.F with old qemu command; the other is qemu fail to parse -net none. 2 old bugs got fixed. Fixed issues: 1. qemu segmentation fault when create qcow2 image with qemu-img command https://bugs.launchpad.net/qemu/+bug/592056 2. Hot-added device is not visible in guest after migration https://sourceforge.net/tracker/?func=detailatid=893831aid=2832416group_id=180599 New issues: 1. qemu fail to parse command line with -pcidevice B:D.F https://bugs.launchpad.net/qemu/+bug/597932 2. qemu fail to parse command -net none https://bugs.launchpad.net/qemu/+bug/599617 Six old Issues: 1. 32PAE Windows guest is slow to boot with acpi on shadow https://sourceforge.net/tracker/?func=detailaid=2976863group_id=180599atid=893831 2. ltp diotest running time is 2.54 times than before https://sourceforge.net/tracker/?func=detailaid=2723366group_id=180599atid=893831 3. 32bits Rhel5/FC6 guest may fail to reboot after installation https://sourceforge.net/tracker/?func=detailatid=893831aid=1991647group_id=180599 4. perfctr wrmsr warning when booting 64bit RHEl5.3 https://sourceforge.net/tracker/?func=detailaid=2721640group_id=180599atid=893831 5. [SR] qemu return form migrate command spend long time https://sourceforge.net/tracker/?func=detailaid=2942079group_id=180599atid=893831 6. host panic on kernel 2.6.34 https://bugzilla.kernel.org/show_bug.cgi?id=16082 Test environment Platform A Stoakley/Clovertown CPU 4 Memory size 8G = Total PassFailNoResult Crash = control_panel 17 16 1 00 gtest 23 20 3 00 = control_panel 17 16 1 00 :KVM_4G_guest_64_g32e 1 1 0 00 :KVM_four_sguest_64_gPAE 1 1 0 00 :KVM_LM_SMP_64_g32e1 1 0 00 :KVM_linux_win_64_gPAE 1 1 0 00 :KVM_LM_SMP_64_gPAE1 1 0 00 :KVM_SR_Continuity_64_gP 1 1 0 00 :KVM_four_sguest_64_g32e 1 1 0 00 :KVM_four_dguest_64_gPAE 1 1 0 00 :KVM_SR_SMP_64_gPAE1 1 0 00 :KVM_LM_Continuity_64_g3 1 1 0 00 :KVM_1500M_guest_64_gPAE 1 1 0 00 :KVM_LM_Continuity_64_gP 1 0 1 00 :KVM_1500M_guest_64_g32e 1 1 0 00 :KVM_SR_Continuity_64_g3 1 1 0 00 :KVM_two_winxp_64_gPAE 1 1 0 00 :KVM_256M_guest_64_gPAE1 1 0 00 :KVM_256M_guest_64_g32e1 1 0 00 gtest 23 20 3 00 :boot_up_acpi_64_gPAE 1 1 0 00 :boot_up_noacpi_xp_64_gP 1 1 0 00 :boot_base_kernel_64_gPA 1 1 0 00 :boot_up_vista_64_g32e 1 1 0 00 :boot_smp_acpi_win2k3_64 1 0 1 00 :kb_nightly_64_gPAE1 1 0 00 :boot_up_acpi_xp_64_g32e 1 1 0 00 :boot_smp_win7_ent_64_g3 1 1 0 00 :boot_smp_acpi_xp_64_gPA 1 0 1 00 :boot_smp_acpi_xp_64_g32 1 1 0 00 :boot_smp_vista_64_gPAE1 1 0 00 :boot_up_acpi_64_g32e 1 1 0 00 :boot_base_kernel_64_g32 1 1 0 00 :kb_nightly_64_g32e1 1 0 00 :boot_up_acpi_win2k3_64_ 1 1 0 00 :boot_up_win2008_64_gPAE 1 0 1 00 :ltp_nightly_64_g32e 1 1 0 00 :boot_smp_win2008_64_g32 1 1 0 00 :boot_up_vista_64_gPAE 1 1 0 00 :ltp_nightly_64_gPAE 1 1 0 00 :boot_smp_acpi_win2k3_64 1 1 0 00 :boot_up_noacpi_win2k3_6 1 1 0 00 :boot_smp_win7_ent_64_gP 1 1 0 00
RE: qemu fail to parse command line with -pcidevice 00:19.0
Thanks, Mark. -Original Message- From: Markus Armbruster [mailto:arm...@redhat.com] Sent: 2010年6月25日 12:58 To: Hao, Xudong Cc: qemu-de...@nongnu.org; aligu...@us.ibm.com; kvm@vger.kernel.org Subject: Re: qemu fail to parse command line with -pcidevice 00:19.0 Hao, Xudong xudong@intel.com writes: Work-around: -device pci-assign,host=00:19.1 OK, this new way can work when create guest with static assignment. But how to hot add a pci device to guest? the old hot add command pci_add pci_addr=auto host host=00:19.0 has the same parse error. Command line's -device becomes monitor's device_add: device_add pci-assign,host=00:19.1 BTW: if we use add -net none in qemu command, guest can not be created and nothing error printed. Do you have plan to fix this parse issue? Separate issue. Fix posted: Subject: [Qemu-devel] [PATCH] net: Fix VM start with '-net none' Date: Tue, 15 Jun 2010 13:30:39 +0530 Message-Id: 22a96312232a0458fc04268b79d17828c824df42.1276588830.git.amit.s...@redhat.com You could have found this yourself :)
RE: qemu fail to parse command line with -pcidevice 00:19.0
Work-around: -device pci-assign,host=00:19.1 OK, this new way can work when create guest with static assignment. But how to hot add a pci device to guest? the old hot add command pci_add pci_addr=auto host host=00:19.0 has the same parse error. BTW: if we use add -net none in qemu command, guest can not be created and nothing error printed. Do you have plan to fix this parse issue? Thanks, Xudong -Original Message- From: Markus Armbruster [mailto:arm...@redhat.com] Sent: 2010年6月24日 14:08 To: Hao, Xudong Cc: qemu-de...@nongnu.org; aligu...@us.ibm.com; kvm@vger.kernel.org Subject: Re: qemu fail to parse command line with -pcidevice 00:19.0 Note to qemu-devel: this issue is qemu-kvm only. Hao, Xudong xudong@intel.com writes: When assign one PCI device, qemu fail to parse the command line: qemu-system_x86 -smp 2 -m 1024 -hda /path/to/img -pcidevice host=00:19.0 Error: qemu-system-x86_64: Parameter 'id' expects an identifier Identifiers consist of letters, digits, '-', '.', '_', starting with a letter. pcidevice argument parse error; please check the help text for usage Could not add assigned device host=00:19.0 https://bugs.launchpad.net/qemu/+bug/597932 This issue caused by qemu-kvm commit b560a9ab9be06afcbb78b3791ab836dad208a239. The bug is in add_assigned_device(): r = get_param_value(id, sizeof(id), id, arg); if (!r) r = get_param_value(id, sizeof(id), name, arg); if (!r) r = get_param_value(id, sizeof(id), host, arg); We end up with invalid ID 00:19.0. Is there a technical reason why we must have an ID? I doubt it. Work-around: -device pci-assign,host=00:19.1 See the last section of docs/qdev-device-use.txt for details.
qemu fail to parse command line with -pcidevice 00:19.0
When assign one PCI device, qemu fail to parse the command line: qemu-system_x86 -smp 2 -m 1024 -hda /path/to/img -pcidevice host=00:19.0 Error: qemu-system-x86_64: Parameter 'id' expects an identifier Identifiers consist of letters, digits, '-', '.', '_', starting with a letter. pcidevice argument parse error; please check the help text for usage Could not add assigned device host=00:19.0 https://bugs.launchpad.net/qemu/+bug/597932 This issue caused by qemu-kvm commit b560a9ab9be06afcbb78b3791ab836dad208a239. Best Regards, Xudong Hao -- 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 Test report, kernel f7ebf25e... qemu 02152f7...
Hi, all, This is KVM biweekly test result against kvm.git: f7ebf25e0c1e6cd8ff31f56a076908a169044090 and qemu-kvm.git: 02152f7275ebede652360c3840cf45fe240d34f0, based on kernel 2.6.35-rc2+. Two new issues found recently, one is kernel panic if start kvm sometimes. The other is qemu segmentation fault when use qemu-img create qcow image. New issues: 1. host panic on kernel 2.6.34 https://bugzilla.kernel.org/show_bug.cgi?id=16082 [Update]: kernel 2.6.34 and 2.6.35 has this issue. 2. qemu segmentation fault when create qcow2 image with qemu-img command https://bugs.launchpad.net/qemu/+bug/592056 [Update]: Kevin Wolf has a fix patch for it in qemu-devel mail list. Six Old Issues: 1. 32PAE Windows guest is slow to boot with acpi on shadow https://sourceforge.net/tracker/?func=detailaid=2976863group_id=180599atid=893831 2. Hot-added device is not visible in guest after migration https://sourceforge.net/tracker/?func=detailatid=893831aid=2832416group_id=180599 [Update]: Alex Williamson has a fix in qemu upstream tree. 3. ltp diotest running time is 2.54 times than before https://sourceforge.net/tracker/?func=detailaid=2723366group_id=180599atid=893831 4. 32bits Rhel5/FC6 guest may fail to reboot after installation https://sourceforge.net/tracker/?func=detailatid=893831aid=1991647group_id=180599 5. perfctr wrmsr warning when booting 64bit RHEl5.3 https://sourceforge.net/tracker/?func=detailaid=2721640group_id=180599atid=893831 6. [SR] qemu return form migrate command spend long time https://sourceforge.net/tracker/?func=detailaid=2942079group_id=180599atid=893831 Test environment Platform A Stoakley/Clovertown CPU 4 Memory size 8G Summary Test Report of Last Session = Total PassFailNoResult Crash = control_panel17 15 2 00 gtest 23 20 3 00 = control_panel17 15 2 00 :KVM_4G_guest_64_g32e 1 1 0 00 :KVM_four_sguest_64_gPAE1 1 0 00 :KVM_LM_SMP_64_g32e 1 0 1 00 :KVM_linux_win_64_gPAE 1 1 0 00 :KVM_LM_SMP_64_gPAE 1 1 0 00 :KVM_SR_Continuity_64_gP1 1 0 00 :KVM_four_sguest_64_g32e1 1 0 00 :KVM_four_dguest_64_gPAE1 1 0 00 :KVM_SR_SMP_64_gPAE1 1 0 00 :KVM_LM_Continuity_64_g31 1 0 00 :KVM_1500M_guest_64_gPAE 1 1 0 00 :KVM_LM_Continuity_64_gP1 0 1 00 :KVM_1500M_guest_64_g32e 1 1 0 00 :KVM_SR_Continuity_64_g3 1 1 0 00 :KVM_two_winxp_64_gPAE 1 1 0 00 :KVM_256M_guest_64_gPAE1 1 0 00 :KVM_256M_guest_64_g32e1 1 0 00 gtest 23 20 3 00 :boot_up_acpi_64_gPAE1 1 0 00 :boot_up_noacpi_xp_64_gP 1 1 0 00 :boot_base_kernel_64_gPA 1 1 0 00 :boot_up_vista_64_g32e 1 1 0 00 :boot_smp_acpi_win2k3_641 0 1 00 :kb_nightly_64_gPAE 1 1 0 00 :boot_up_acpi_xp_64_g32e 1 1 0 00 :boot_smp_win7_ent_64_g31 1 0 00 :boot_smp_acpi_xp_64_gPA1 0 1 00 :boot_smp_acpi_xp_64_g321 1 0 00 :boot_smp_vista_64_gPAE 1 1 0 00 :boot_up_acpi_64_g32e 1 1 0 00 :boot_base_kernel_64_g321 1 0 00 :kb_nightly_64_g32e 1 1 0 00 :boot_up_acpi_win2k3_64_1 1 0 00 :boot_up_win2008_64_gPAE 1 0 1 00 :ltp_nightly_64_g32e 1 1 0 00 :boot_smp_win2008_64_g32 1 1 0 00 :boot_up_vista_64_gPAE 1 1 0 00 :ltp_nightly_64_gPAE 1 1 0 00 :boot_smp_acpi_win2k3_641 1 0 00 :boot_up_noacpi_win2k3_61 1 0 00 :boot_smp_win7_ent_64_gP 1 1 0
RE: host panic on kernel 2.6.34
Maciej Rutecki wrote: On poniedziałek, 24 maja 2010 o 10:23:11 Hao, Xudong wrote: Hi all I build latest kvm 37dec075a7854f0f550540bf3b9bbeef37c11e2a, based on kernel 2.6.34, after kvm and kvm_intel module loaded, then /etc/init.d/kvm start, a few minutes later, the system will panic. I created a Bugzilla entry at https://bugzilla.kernel.org/show_bug.cgi?id=16082 for your bug report, please add your address to the CC list in there, thanks! Thanks, Maciej. I register a account and CC myself in there. -Xudong-- 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
host panic on kernel 2.6.34
Hi all I build latest kvm 37dec075a7854f0f550540bf3b9bbeef37c11e2a, based on kernel 2.6.34, after kvm and kvm_intel module loaded, then /etc/init.d/kvm start, a few minutes later, the system will panic. kernel: 2.6.34 kvm: 37dec075a7854f0f550540bf3b9bbeef37c11e2a qemu-kvm: 69dd59a66aaf56d1e8e4c96d0a0923c9cf8f79a0 BUG: unable to handle kernel NULL pointer dereference at 0018 IP: [f914c05b] br_mdb_ip_get+0x2e/0x1aa [bridge] *pdpt = 35fbb001 *pde = Oops: [#1] SMP last sysfs file: /sys/devices/system/cpu/cpu7/cache/index2/shared_cpu_map Modules linked in: bridge stp autofs4 hidp rfcomm l2cap crc16 bluetooth rfkill ] Pid: 0, comm: swapper Not tainted 2.6.34 #1 X7DWA/X7DWA EIP: 0060:[f914c05b] EFLAGS: 00010246 CPU: 0 EIP is at br_mdb_ip_get+0x2e/0x1aa [bridge] EAX: c5801d40 EBX: c5801d40 ECX: faef EDX: ESI: f67e03c0 EDI: f5249200 EBP: c5801c94 ESP: c5801c80 DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 Process swapper (pid: 0, ti=c5801000 task=c07f2fe0 task.ti=c07de000) Stack: c5801d40 c5801d40 f67e03c0 f5249200 c5801cb0 f914c6fd fff90006 0 f67e0940 f6326740 f627e064 f67e03c0 c5801d78 f914dd0c f76af140 f6326740 0 f5249200 f67e03c0 0014 f6326758 c5801d54 c08eb440 c5801cf4 c5801d00 Call Trace: [f914c6fd] ? br_multicast_leave_group+0x52/0x128 [bridge] [f914dd0c] ? br_multicast_rcv+0x6dc/0xe90 [bridge] [c0650420] ? fib_lookup+0x2c/0x3a [c064cd15] ? fib_validate_source+0x29d/0x2b4 [c0621175] ? nf_hook_slow+0x3b/0x92 [f9147b39] ? br_handle_frame_finish+0x53/0x17e [bridge] [f914b880] ? br_nf_pre_routing_finish+0x264/0x27c [bridge] [c0621175] ? nf_hook_slow+0x3b/0x92 [f914b61c] ? br_nf_pre_routing_finish+0x0/0x27c [bridge] [f914bf6f] ? br_nf_pre_routing+0x553/0x570 [bridge] [c0621107] ? nf_iterate+0x2f/0x62 [f9147ae6] ? br_handle_frame_finish+0x0/0x17e [bridge] [c0621175] ? nf_hook_slow+0x3b/0x92 [f9147ae6] ? br_handle_frame_finish+0x0/0x17e [bridge] [f9147dda] ? br_handle_frame+0x176/0x198 [bridge] [f9147ae6] ? br_handle_frame_finish+0x0/0x17e [bridge] [c060643b] ? __netif_receive_skb+0x29a/0x37e [c0607023] ? dev_gro_receive+0xfd/0x1d2 [c0606e03] ? netif_receive_skb+0x61/0x67 [c0607199] ? __napi_gro_receive+0xa1/0xba [c0606e7e] ? napi_skb_finish+0x1e/0x33 [c0607201] ? napi_gro_receive+0x20/0x24 [f8867cfc] ? igb_poll+0x706/0xa39 [igb] [c06093b2] ? net_rx_action+0x97/0x13b [c0430641] ? __do_softirq+0x80/0xf4 [c04305c1] ? __do_softirq+0x0/0xf4 IRQ [c04305bf] ? irq_exit+0x29/0x2b [c040373e] ? do_IRQ+0x85/0x9b [c0402ca9] ? common_interrupt+0x29/0x30 [c0407c4f] ? mwait_idle+0x4c/0x52 [c0401a08] ? cpu_idle+0x3a/0x4e [c066cf16] ? rest_init+0x62/0x64 [c08248dd] ? start_kernel+0x2c2/0x2c7 [c08240b3] ? i386_start_kernel+0xb3/0xb8 Code: 57 56 53 83 ec 08 89 45 f0 89 55 ec 8b 42 10 66 83 f8 08 74 0e 31 db 66 3 EIP: [f914c05b] br_mdb_ip_get+0x2e/0x1aa [bridge] SS:ESP 0068:c5801c80 CR2: 0018 ---[ end trace 907f878ab4cd8031 ]--- Kernel panic - not syncing: Fatal exception in interrupt
Biweekly KVM Test report, kernel f1bf31e... qemu 1c596c5...
Hi, all, This is KVM biweekly test result against kvm.git: f1bf31ef946581de4dbc44b3d5e4e39200a0ef62 and qemu-kvm.git: 1c596c54fd5cdce8d65f5a0c3f800567857e6a58, based on kernel 2.6.34-rc6. There are no new issue found in the past two weeks. The 32pae Windows guest will cost about 9 minute to boot up. Six Old Issues: 1. 32PAE Windows guest is slow to boot with acpi on shadow https://sourceforge.net/tracker/?func=detailaid=2976863group_id=180599atid=893831 2. Hot-added device is not visible in guest after migration https://sourceforge.net/tracker/?func=detailatid=893831aid=2832416group_id=180599 3. ltp diotest running time is 2.54 times than before https://sourceforge.net/tracker/?func=detailaid=2723366group_id=180599atid=893831 4. 32bits Rhel5/FC6 guest may fail to reboot after installation https://sourceforge.net/tracker/?func=detailatid=893831aid=1991647group_id=180599 5. perfctr wrmsr warning when booting 64bit RHEl5.3 https://sourceforge.net/tracker/?func=detailaid=2721640group_id=180599atid=893831 6. [SR] qemu return form migrate command spend long time https://sourceforge.net/tracker/?func=detailaid=2942079group_id=180599atid=893831 Test environment Platform A Stoakley/Clovertown CPU 4 Memory size 8G Summary Test Report of Last Session = Total PassFailNoResult Crash = control_panel 17 16 1 00 gtest 23 21 2 00 = control_panel 17 16 1 00 :KVM_4G_guest_64_g32e 1 1 0 00 :KVM_four_sguest_64_gPAE 1 1 0 00 :KVM_LM_SMP_64_g32e1 1 0 00 :KVM_linux_win_64_gPAE 1 1 0 00 :KVM_LM_SMP_64_gPAE1 1 0 00 :KVM_SR_Continuity_64_gP 1 1 0 00 :KVM_four_sguest_64_g32e 1 1 0 00 :KVM_four_dguest_64_gPAE 1 1 0 00 :KVM_SR_SMP_64_gPAE1 1 0 00 :KVM_LM_Continuity_64_g3 1 1 0 00 :KVM_1500M_guest_64_gPAE 1 1 0 00 :KVM_LM_Continuity_64_gP 1 0 1 00 :KVM_1500M_guest_64_g32e 1 1 0 00 :KVM_SR_Continuity_64_g3 1 1 0 00 :KVM_two_winxp_64_gPAE 1 1 0 00 :KVM_256M_guest_64_gPAE1 1 0 00 :KVM_256M_guest_64_g32e1 1 0 00 gtest 23 21 2 00 :boot_up_acpi_64_gPAE 1 1 0 00 :boot_up_noacpi_xp_64_gP 1 1 0 00 :boot_base_kernel_64_gPA 1 1 0 00 :boot_up_vista_64_g32e 1 1 0 00 :boot_smp_acpi_win2k3_64 1 0 1 00 :kb_nightly_64_gPAE1 1 0 00 :boot_up_acpi_xp_64_g32e 1 1 0 00 :boot_smp_win7_ent_64_g3 1 1 0 00 :boot_smp_acpi_xp_64_gPA 1 0 1 00 :boot_smp_acpi_xp_64_g32 1 1 0 00 :boot_smp_vista_64_gPAE1 1 0 00 :boot_up_acpi_64_g32e 1 1 0 00 :boot_base_kernel_64_g32 1 1 0 00 :kb_nightly_64_g32e1 1 0 00 :boot_up_acpi_win2k3_64_ 1 1 0 00 :boot_up_win2008_64_gPAE 1 1 0 00 :ltp_nightly_64_g32e 1 1 0 00 :boot_smp_win2008_64_g32 1 1 0 00 :boot_up_vista_64_gPAE 1 1 0 00 :ltp_nightly_64_gPAE 1 1 0 00 :boot_smp_acpi_win2k3_64 1 1 0 00 :boot_up_noacpi_win2k3_6 1 1 0 00 :boot_smp_win7_ent_64_gP 1 1 0 00 = Total 40 37 3 00 Test environment Platform B Nehalem CPU 8 Memory size 4G Report summary of IA32E on vt-NHM1: Summary Test Report of Last Session =
Biweekly KVM Test report, kernel 069c71e... qemu 5c78106...
Hi, all, This is KVM biweekly test result against kvm.git: 172e7dcac723d224563de4d437736dcac39a36d7 and qemu-kvm.git: a1b705841caa33fca0b95928505c01d5105b706f. There are no new issue found in the past two weeks. The 32pae Windows guest will cost about 9 minute to boot up, but it did not BSOD. Six Old Issues: 1. 32PAE Windows guest blue screen when booting with apci on https://sourceforge.net/tracker/?func=detailaid=2976863group_id=180599atid=893831 2. Hot-added device is not visible in guest after migration https://sourceforge.net/tracker/?func=detailatid=893831aid=2832416group_id=180599 3. ltp diotest running time is 2.54 times than before https://sourceforge.net/tracker/?func=detailaid=2723366group_id=180599atid=893831 4. 32bits Rhel5/FC6 guest may fail to reboot after installation https://sourceforge.net/tracker/?func=detailatid=893831aid=1991647group_id=180599 5. perfctr wrmsr warning when booting 64bit RHEl5.3 https://sourceforge.net/tracker/?func=detailaid=2721640group_id=180599atid=893831 6. [SR] qemu return form migrate command spend long time https://sourceforge.net/tracker/?func=detailaid=2942079group_id=180599atid=893831 Test environment Platform A Stoakley/Clovertown CPU 4 Memory size 8G Summary Test Report of Last Session = Total PassFailNoResult Crash = control_panel 17 17 0 00 gtest 23 20 3 00 = control_panel 17 17 0 00 :KVM_4G_guest_64_g32e 1 1 0 00 :KVM_four_sguest_64_gPAE 1 1 0 00 :KVM_LM_SMP_64_g32e1 1 0 00 :KVM_linux_win_64_gPAE 1 1 0 00 :KVM_LM_SMP_64_gPAE1 1 0 00 :KVM_SR_Continuity_64_gP 1 1 0 00 :KVM_four_sguest_64_g32e 1 1 0 00 :KVM_four_dguest_64_gPAE 1 1 0 00 :KVM_SR_SMP_64_gPAE1 1 0 00 :KVM_LM_Continuity_64_g3 1 1 0 00 :KVM_1500M_guest_64_gPAE 1 1 0 00 :KVM_LM_Continuity_64_gP1 1 0 00 :KVM_1500M_guest_64_g32e 1 1 0 00 :KVM_SR_Continuity_64_g3 1 1 0 00 :KVM_two_winxp_64_gPAE 1 1 0 00 :KVM_256M_guest_64_gPAE1 1 0 00 :KVM_256M_guest_64_g32e1 1 0 00 gtest23 20 3 00 :boot_up_acpi_64_gPAE 1 1 0 00 :boot_up_noacpi_xp_64_gP1 1 0 00 :boot_base_kernel_64_gPA1 1 0 00 :boot_up_vista_64_g32e 1 1 0 00 :boot_smp_acpi_win2k3_64 1 0 1 00 :kb_nightly_64_gPAE 1 1 0 00 :boot_up_acpi_xp_64_g32e1 1 0 00 :boot_smp_win7_ent_64_g3 1 1 0 00 :boot_smp_acpi_xp_64_gPA 1 0 1 00 :boot_smp_acpi_xp_64_g32 1 1 0 00 :boot_smp_vista_64_gPAE1 1 0 00 :boot_up_acpi_64_g32e 1 1 0 00 :boot_base_kernel_64_g321 1 0 00 :kb_nightly_64_g32e 1 1 0 00 :boot_up_acpi_win2k3_64_1 1 0 00 :boot_up_win2008_64_gPAE 1 1 0 00 :ltp_nightly_64_g32e 1 1 0 00 :boot_smp_win2008_64_g32 1 1 0 00 :boot_up_vista_64_gPAE 1 1 0 00 :ltp_nightly_64_gPAE 1 0 1 00 :boot_smp_acpi_win2k3_641 1 0 00 :boot_up_noacpi_win2k3_61 1 0 00 :boot_smp_win7_ent_64_gP 1 1 0 00 = Total 40 37 3 00 Test environment Platform B Nehalem CPU 8 Memory size 4G Report summary of IA32E on vt-NHM1: Summary Test Report of Last Session
Biweekly KVM Test report, kernel 069c71e... qemu 5c78106...
Hi, all, This is KVM biweekly test result against kvm.git: 069c71e7a5e5f968099ca551f68e5dfe5a3f71bc and qemu-kvm.git: 5c781061a45abe1855ad0a95d834336da574703c. In the past two weeks, there is no new issues found. The issue that 32PAE Windows guest can not boot up with BSOD still exist. Six Old Issues: 1. 32PAE Windows guest blue screen when booting with apci on https://sourceforge.net/tracker/?func=detailaid=2976863group_id=180599atid=893831 2. Hot-added device is not visible in guest after migration https://sourceforge.net/tracker/?func=detailatid=893831aid=2832416group_id=180599 3. ltp diotest running time is 2.54 times than before https://sourceforge.net/tracker/?func=detailaid=2723366group_id=180599atid=893831 4. 32bits Rhel5/FC6 guest may fail to reboot after installation https://sourceforge.net/tracker/?func=detailatid=893831aid=1991647group_id=180599 5. perfctr wrmsr warning when booting 64bit RHEl5.3 https://sourceforge.net/tracker/?func=detailaid=2721640group_id=180599atid=893831 6. [SR] qemu return form migrate command spend long time https://sourceforge.net/tracker/?func=detailaid=2942079group_id=180599atid=893831 Test environment Platform A Stoakley/Clovertown CPU 4 Memory size 8G Summary Test Report of Last Session = Total PassFailNoResult Crash = control_panel 17 16 1 00 gtest 23 21 2 00 = control_panel 17 16 1 00 :KVM_4G_guest_64_g32e1 1 0 00 :KVM_four_sguest_64_gPAE 1 1 0 00 :KVM_LM_SMP_64_g32e 1 0 1 00 :KVM_linux_win_64_gPAE 1 1 0 00 :KVM_LM_SMP_64_gPAE 1 1 0 00 :KVM_SR_Continuity_64_gP1 1 0 00 :KVM_four_sguest_64_g32e1 1 0 00 :KVM_four_dguest_64_gPAE1 1 0 00 :KVM_SR_SMP_64_gPAE1 1 0 00 :KVM_LM_Continuity_64_g31 1 0 00 :KVM_1500M_guest_64_gPAE 1 1 0 00 :KVM_LM_Continuity_64_gP1 1 0 00 :KVM_1500M_guest_64_g32e 1 1 0 00 :KVM_SR_Continuity_64_g3 1 1 0 00 :KVM_two_winxp_64_gPAE 1 1 0 00 :KVM_256M_guest_64_gPAE1 1 0 00 :KVM_256M_guest_64_g32e1 1 0 00 gtest23 21 2 00 :boot_up_acpi_64_gPAE 1 1 0 00 :boot_up_noacpi_xp_64_gP1 1 0 00 :boot_base_kernel_64_gPA1 1 0 00 :boot_up_vista_64_g32e 1 1 0 00 :boot_smp_acpi_win2k3_641 0 1 00 :kb_nightly_64_gPAE 1 1 0 00 :boot_up_acpi_xp_64_g32e1 1 0 00 :boot_smp_win7_ent_64_g3 1 1 0 00 :boot_smp_acpi_xp_64_gPA1 0 1 00 :boot_smp_acpi_xp_64_g321 1 0 00 :boot_smp_vista_64_gPAE 1 1 0 00 :boot_up_acpi_64_g32e 1 1 0 00 :boot_base_kernel_64_g321 1 0 00 :kb_nightly_64_g32e 1 1 0 00 :boot_up_acpi_win2k3_64_1 1 0 00 :boot_up_win2008_64_gPAE 1 1 0 00 :ltp_nightly_64_g32e 1 1 0 00 :boot_smp_win2008_64_g32 1 1 0 00 :boot_up_vista_64_gPAE 1 1 0 00 :ltp_nightly_64_gPAE 1 1 0 00 :boot_smp_acpi_win2k3_641 1 0 00 :boot_up_noacpi_win2k3_61 1 0 00 :boot_smp_win7_ent_64_gP 1 1 0 00 = Total 40 37 3 00 Test environment Platform B Nehalem CPU 8 Memory size 4G Report summary of IA32E on vt-NHM1: Summary Test Report of Last Session =
RE: KVM Test report, kernel 647e9e... qemu 7811d4...
Avi Kivity wrote: You need to fold the -hda parameter into -driver, so the whole command line becomes qemu-system-x86_64 -m 512 -smp 4 -net nic,macaddr=00:16:3e:79:0c:db,model=rtl8139 -net tap,script=/etc/kvm/qemu-ifup -drive file=/share/ltp_guest.img,cache=writeback -hda is deprecated, it forces cache=writethrough. Okay, cache=writeback can improve 28% performance of diotest, it cost 135 seconds which cost 182 sconds with cache=writethrough. But in the report of bug, there was 2.53 times downgrade performance than before, so maybe still need somewhere tuning. Thanks, Xudong-- 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
Biweekly KVM Test report, kernel 0e8e9adf... qemu 79fdb98...
Hi, all, This is KVM biweekly test result against kvm.git: 0e8e9adf792446859d6906af7f09249e4d0971d7 and qemu-kvm.git: 79fdb980fa4fe40c3fba9391b83b655045af030f. Lastest KVM based on kernel 2.6.34-rc2. There is one issue that 32PAE Windows guest can not boot up with acpi on. New issue: 1. 32PAE Windows guest blue screen when booting with apci on https://sourceforge.net/tracker/?func=detailaid=2976863group_id=180599atid=893831 Five Old Issues: 1. Hot-added device is not visible in guest after migration https://sourceforge.net/tracker/?func=detailatid=893831aid=2832416group_id=180599 2. ltp diotest running time is 2.54 times than before https://sourceforge.net/tracker/?func=detailaid=2723366group_id=180599atid=893831 3. 32bits Rhel5/FC6 guest may fail to reboot after installation https://sourceforge.net/tracker/?func=detailatid=893831aid=1991647group_id=180599 4. perfctr wrmsr warning when booting 64bit RHEl5.3 https://sourceforge.net/tracker/?func=detailaid=2721640group_id=180599atid=893831 5. [SR] qemu return form migrate command spend long time https://sourceforge.net/tracker/?func=detailaid=2942079group_id=180599atid=893831 Test environment Platform A Stoakley/Clovertown CPU 4 Memory size 8G Details: Summary Test Report of Last Session = Total Pass Fail NoResult Crash = control_panel 17 16 1 0 0 gtest 23 21 2 0 0 = control_panel 17 16 1 0 0 :KVM_4G_guest_64_g32e 1 1 0 0 0 :KVM_four_sguest_64_gPAE 1 1 0 0 0 :KVM_LM_SMP_64_g32e 1 1 0 0 0 :KVM_linux_win_64_gPAE 1 1 0 0 0 :KVM_LM_SMP_64_gPAE 1 1 0 0 0 :KVM_SR_Continuity_64_gP 1 1 0 0 0 :KVM_four_sguest_64_g32e 1 1 0 0 0 :KVM_four_dguest_64_gPAE 1 1 0 0 0 :KVM_SR_SMP_64_gPAE 1 1 0 0 0 :KVM_LM_Continuity_64_g3 1 1 0 0 0 :KVM_1500M_guest_64_gPAE 1 1 0 0 0 :KVM_LM_Continuity_64_gP 1 1 0 0 0 :KVM_1500M_guest_64_g32e 1 1 0 0 0 :KVM_SR_Continuity_64_g3 1 1 0 0 0 :KVM_two_winxp_64_gPAE 1 0 1 0 0 :KVM_256M_guest_64_gPAE 1 1 0 0 0 :KVM_256M_guest_64_g32e 1 1 0 0 0 gtest 23 21 2 0 0 :boot_up_acpi_64_gPAE 1 1 0 0 0 :boot_up_noacpi_xp_64_gP 1 1 0 0 0 :boot_base_kernel_64_gPA 1 1 0 0 0 :boot_up_vista_64_g32e 1 1 0 0 0 :boot_smp_acpi_win2k3_64 1 0 1 0 0 :kb_nightly_64_gPAE 1 1 0 0 0 :boot_up_acpi_xp_64_g32e 1 1 0 0 0 :boot_smp_win7_ent_64_g3 1 1 0 0 0 :boot_smp_acpi_xp_64_gPA 1 0 1 0 0 :boot_smp_acpi_xp_64_g32 1 1 0 0 0 :boot_smp_vista_64_gPAE 1 1 0 0 0 :boot_up_acpi_64_g32e 1 1 0 0 0 :boot_base_kernel_64_g32 1 1 0 0 0 :kb_nightly_64_g32e 1 1 0 0 0 :boot_up_acpi_win2k3_64_ 1 1 0 0 0 :boot_up_win2008_64_gPAE 1 1 0 0 0 :ltp_nightly_64_g32e 1 1 0 0 0 :boot_smp_win2008_64_g32 1 1 0 0 0 :boot_up_vista_64_gPAE 1 1 0 0 0 :ltp_nightly_64_gPAE 1 1 0 0 0 :boot_smp_acpi_win2k3_64 1 1 0 0 0 :boot_up_noacpi_win2k3_6 1 1 0 0 0 :boot_smp_win7_ent_64_gP 1 1 0 0 0 = Total 40 7 3 0 0 Test environment Platform B Nehalem CPU 8 Memory size 4G Report summary of IA32E on vt-NHM1: Summary Test Report of Last Session
RE: KVM Test report, kernel 647e9e... qemu 7811d4...
Avi Kivity wrote: 2. ltp diotest running time is 2.54 times than before https://sourceforge.net/tracker/?func=detailaid=2723366group_id=180599atid=893831 Can you check the performance of this with cache=writeback? The common on the report referring to cache=writethrough is incorrect (I think?) Hi, Avi I checked cache=writeback parameter, the diotest performance is much worse than no this parameter(about 20 times). Followed qemu help, my command is qemu-system-x86_64 -m 512 -smp 4 -net nic,macaddr=00:16:3e:79:0c:db,model=rtl8139 -net tap,script=/etc/kvm/qemu-ifup -hda /share/ltp_guest.img -drive cache=writeback, is it right? When booting guest with cache=writeback, there are some hdb drive Error printed in guest, and guest booting very slow. Thanks, Xudong-- 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: host panic based on kernel 2.6.34-RC1
David Miller wrote: From: Hao, Xudong xudong@intel.com Date: Wed, 17 Mar 2010 10:14:50 +0800 I installed a latest kvm based on kernel 2.6.34-rc1, after I load kvm kvm_i= ntel module, and start /etc/init.d/kvm, a few minutes later, the system wil= l panic. The panic is easy to reproduce when I use tcpdump in host. However, if I stop /etc/init.d/kvm, everything is OK, host works fine. Does= anyone met similar issue? any hint? This is fixed in Linus's GIT tree already. Thanks David. Thanks, Xudong-- 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 Test report, kernel 647e9e... qemu 7811d4...
Hi, all, This is KVM biweekly test result against kvm.git: 647e9ec3b543ea04d49a7323dfe0070682ed8465 and qemu-kvm.git: 7811d4e8ec057d25db68f900be1f09a142faca49. In the last month, KVM testing was blocked by one qemu-img issue and two qemu build issues. Now the qemu build issue and qemu-img bug all get fixed. One issue got fixed: 1. new Qemu-img can not create qcow image on read-only image https://sourceforge.net/tracker/?func=detailaid=2942075group_id=180599atid=893831 Four Old Issues: 1. Hot-added device is not visible in guest after migration https://sourceforge.net/tracker/?func=detailatid=893831aid=2832416group_id=180599 2. ltp diotest running time is 2.54 times than before https://sourceforge.net/tracker/?func=detailaid=2723366group_id=180599atid=893831 3. 32bits Rhel5/FC6 guest may fail to reboot after installation https://sourceforge.net/tracker/?func=detailatid=893831aid=1991647group_id=180599 4. perfctr wrmsr warning when booting 64bit RHEl5.3 https://sourceforge.net/tracker/?func=detailaid=2721640group_id=180599atid=893831 5. [SR] qemu return form migrate command spend long time https://sourceforge.net/tracker/?func=detailaid=2942079group_id=180599atid=893831 Test environment Platform A Stoakley/Clovertown CPU 4 Memory size 8G Details == Summary Test Report of Last Session = Total PassFailNoResult Crash = control_panel 17 13 4 00 gtest 23 21 2 00 = control_panel 17 13 4 00 :KVM_4G_guest_64_g32e 1 1 0 00 :KVM_four_sguest_64_gPAE 1 1 0 00 :KVM_LM_SMP_64_g32e1 1 0 00 :KVM_linux_win_64_gPAE 1 1 0 00 :KVM_LM_SMP_64_gPAE1 1 0 00 :KVM_SR_Continuity_64_gP 1 0 1 00 :KVM_four_sguest_64_g32e 1 1 0 00 :KVM_four_dguest_64_gPAE 1 1 0 00 :KVM_SR_SMP_64_gPAE1 0 1 00 :KVM_LM_Continuity_64_g3 1 1 0 00 :KVM_1500M_guest_64_gPAE 1 1 0 00 :KVM_LM_Continuity_64_gP 1 1 0 00 :KVM_1500M_guest_64_g32e 1 1 0 00 :KVM_SR_Continuity_64_g3 1 0 1 00 :KVM_two_winxp_64_gPAE 1 0 1 00 :KVM_256M_guest_64_gPAE1 1 0 00 :KVM_256M_guest_64_g32e1 1 0 00 gtest 23 21 2 00 :boot_up_acpi_64_gPAE 1 1 0 00 :boot_up_noacpi_xp_64_gP 1 1 0 00 :boot_base_kernel_64_gPA 1 1 0 00 :boot_up_vista_64_g32e 1 1 0 00 :boot_smp_acpi_win2k3_64 1 0 1 00 :kb_nightly_64_gPAE1 1 0 00 :boot_up_acpi_xp_64_g32e 1 1 0 00 :boot_smp_win7_ent_64_g3 1 1 0 00 :boot_smp_acpi_xp_64_gPA 1 0 1 00 :boot_smp_acpi_xp_64_g32 1 1 0 00 :boot_smp_vista_64_gPAE1 1 0 00 :boot_up_acpi_64_g32e 1 1 0 00 :boot_base_kernel_64_g32 1 1 0 00 :kb_nightly_64_g32e1 1 0 00 :boot_up_acpi_win2k3_64_ 1 1 0 00 :boot_up_win2008_64_gPAE 1 1 0 00 :ltp_nightly_64_g32e 1 1 0 00 :boot_smp_win2008_64_g32 1 1 0 00 :boot_up_vista_64_gPAE 1 1 0 00 :ltp_nightly_64_gPAE 1 1 0 00 :boot_smp_acpi_win2k3_64 1 1 0 00 :boot_up_noacpi_win2k3_6 1 1 0 00 :boot_smp_win7_ent_64_gP 1 1 0 00 = Total 40 34 6 00 Test environment Platform B Nehalem CPU 8 Memory size 4G Report
RE: How to disable KVM start at boot
sati...@pacific.net.hk wrote: Quoting Hao, Xudong xudong@intel.com: sati...@pacific.net.hk wrote: Quoting Hao, Xudong xudong@intel.com: # chkconfig --level 35 kvm off error reading information on service kvm: No such file or directory I'm not try F12 maybe some pakeage missed. just googled then find answer. so if you get this error also and you have a redhat centos or fedora core linux distribution just send this command to install dovecot yum install dovecot http://www.wallpaperama.com/forums/error-reading-information-on-service-dovecot-no-such-file-or-directory-t6073.html Hi Hao, Sorry I don't follow. Does dovecot has connection with KVM? Googled result, but not sure it's useful for you. But Yolkfull's suggestion is good for you to not load kvm module when boot system. Add the two line in /etc/modprobe.d/blacklist.conf according to your system, then reboot. blacklist kvm blacklist kvm_amd Thanks, Xudong B.R. Stephen -- 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
