[RFC PATCH 0/2] Hyper-V timers
This RFC series adds support for two Hyper-V timer services - a per-partition reference time counter, and a partition reference time enlightenmen. Vadim Rozenfeld (2): hyper-v reference counter Hyper-V iTSC handler arch/x86/include/asm/kvm_host.h| 2 ++ arch/x86/include/uapi/asm/hyperv.h | 13 + arch/x86/kvm/x86.c | 33 - include/uapi/linux/kvm.h | 1 + 4 files changed, 48 insertions(+), 1 deletion(-) -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 1/2] Hyper-H reference counter
Signed-off: Peter Lieven
Signed-off: Gleb Natapov
Signed-off: Vadim Rozenfeld
The following patch allows to activate Hyper-V
reference time counter
---
arch/x86/include/asm/kvm_host.h| 2 ++
arch/x86/include/uapi/asm/hyperv.h | 3 +++
arch/x86/kvm/x86.c | 25 -
3 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 3741c65..f0fee35 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -575,6 +575,8 @@ struct kvm_arch {
/* fields used by HYPER-V emulation */
u64 hv_guest_os_id;
u64 hv_hypercall;
+ u64 hv_ref_count;
+ u64 hv_tsc_page;
#ifdef CONFIG_KVM_MMU_AUDIT
int audit_point;
diff --git a/arch/x86/include/uapi/asm/hyperv.h
b/arch/x86/include/uapi/asm/hyperv.h
index b80420b..9711819 100644
--- a/arch/x86/include/uapi/asm/hyperv.h
+++ b/arch/x86/include/uapi/asm/hyperv.h
@@ -136,6 +136,9 @@
/* MSR used to read the per-partition time reference counter */
#define HV_X64_MSR_TIME_REF_COUNT 0x4020
+/* A partition's reference time stamp counter (TSC) page */
+#define HV_X64_MSR_REFERENCE_TSC 0x4021
+
/* Define the virtual APIC registers */
#define HV_X64_MSR_EOI 0x4070
#define HV_X64_MSR_ICR 0x4071
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 094b5d9..1a4036d 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -843,7 +843,7 @@ EXPORT_SYMBOL_GPL(kvm_rdpmc);
static u32 msrs_to_save[] = {
MSR_KVM_SYSTEM_TIME, MSR_KVM_WALL_CLOCK,
MSR_KVM_SYSTEM_TIME_NEW, MSR_KVM_WALL_CLOCK_NEW,
- HV_X64_MSR_GUEST_OS_ID, HV_X64_MSR_HYPERCALL,
+ HV_X64_MSR_GUEST_OS_ID, HV_X64_MSR_HYPERCALL,HV_X64_MSR_TIME_REF_COUNT,
HV_X64_MSR_APIC_ASSIST_PAGE, MSR_KVM_ASYNC_PF_EN, MSR_KVM_STEAL_TIME,
MSR_KVM_PV_EOI_EN,
MSR_IA32_SYSENTER_CS, MSR_IA32_SYSENTER_ESP, MSR_IA32_SYSENTER_EIP,
@@ -1764,6 +1764,8 @@ static bool kvm_hv_msr_partition_wide(u32 msr)
switch (msr) {
case HV_X64_MSR_GUEST_OS_ID:
case HV_X64_MSR_HYPERCALL:
+ case HV_X64_MSR_REFERENCE_TSC:
+ case HV_X64_MSR_TIME_REF_COUNT:
r = true;
break;
}
@@ -1803,6 +1805,21 @@ static int set_msr_hyperv_pw(struct kvm_vcpu *vcpu, u32
msr, u64 data)
if (__copy_to_user((void __user *)addr, instructions, 4))
return 1;
kvm->arch.hv_hypercall = data;
+ kvm->arch.hv_ref_count = get_kernel_ns();
+ break;
+ }
+ case HV_X64_MSR_REFERENCE_TSC: {
+ u64 gfn;
+ unsigned long addr;
+ u32 tsc_ref;
+ gfn = data >> HV_X64_MSR_HYPERCALL_PAGE_ADDRESS_SHIFT;
+ addr = gfn_to_hva(kvm, gfn);
+ if (kvm_is_error_hva(addr))
+ return 1;
+ tsc_ref = 0;
+ if(__copy_to_user((void __user *)addr, &tsc_ref,
sizeof(tsc_ref)))
+ return 1;
+ kvm->arch.hv_tsc_page = data;
break;
}
default:
@@ -2229,6 +2246,12 @@ static int get_msr_hyperv_pw(struct kvm_vcpu *vcpu, u32
msr, u64 *pdata)
case HV_X64_MSR_HYPERCALL:
data = kvm->arch.hv_hypercall;
break;
+ case HV_X64_MSR_TIME_REF_COUNT:
+ data = div_u64(get_kernel_ns() - kvm->arch.hv_ref_count,100);
+ break;
+ case HV_X64_MSR_REFERENCE_TSC:
+ data = kvm->arch.hv_tsc_page;
+ break;
default:
vcpu_unimpl(vcpu, "Hyper-V unhandled rdmsr: 0x%x\n", msr);
return 1;
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 2/2] Hyper-V iTSC handler
Signed-off: Vadim Rozenfeld
The following patch allows to activate a partition reference
time enlightenment that is based on the host platform's support
for an Invariant Time Stamp Counter (iTSC).
NOTE: This code will survive migration due to lack of VM stop/resume
handlers.
---
arch/x86/include/uapi/asm/hyperv.h | 10 ++
arch/x86/kvm/x86.c | 18 +-
include/uapi/linux/kvm.h | 1 +
3 files changed, 24 insertions(+), 5 deletions(-)
diff --git a/arch/x86/include/uapi/asm/hyperv.h
b/arch/x86/include/uapi/asm/hyperv.h
index 9711819..2d9e666 100644
--- a/arch/x86/include/uapi/asm/hyperv.h
+++ b/arch/x86/include/uapi/asm/hyperv.h
@@ -182,6 +182,9 @@
#define HV_X64_MSR_APIC_ASSIST_PAGE_ADDRESS_MASK \
(~((1ull << HV_X64_MSR_APIC_ASSIST_PAGE_ADDRESS_SHIFT) - 1))
+#define HV_X64_MSR_TSC_REFERENCE_ENABLE0x0001
+#define HV_X64_MSR_TSC_REFERENCE_ADDRESS_SHIFT 12
+
#define HV_PROCESSOR_POWER_STATE_C00
#define HV_PROCESSOR_POWER_STATE_C11
#define HV_PROCESSOR_POWER_STATE_C22
@@ -194,4 +197,11 @@
#define HV_STATUS_INVALID_ALIGNMENT4
#define HV_STATUS_INSUFFICIENT_BUFFERS 19
+typedef struct _HV_REFERENCE_TSC_PAGE {
+ uint32_t TscSequence;
+ uint32_t Rserved1;
+ uint64_t TscScale;
+ int64_t TscOffset;
+} HV_REFERENCE_TSC_PAGE, * PHV_REFERENCE_TSC_PAGE;
+
#endif
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 1a4036d..5788e8f 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1809,14 +1809,21 @@ static int set_msr_hyperv_pw(struct kvm_vcpu *vcpu, u32
msr, u64 data)
break;
}
case HV_X64_MSR_REFERENCE_TSC: {
- u64 gfn;
unsigned long addr;
- u32 tsc_ref;
- gfn = data >> HV_X64_MSR_HYPERCALL_PAGE_ADDRESS_SHIFT;
- addr = gfn_to_hva(kvm, gfn);
+ HV_REFERENCE_TSC_PAGE tsc_ref;
+ tsc_ref.TscSequence =
+ boot_cpu_has(X86_FEATURE_CONSTANT_TSC) ? 1 : 0;
+ tsc_ref.TscScale =
+ ((1LL << 32) /vcpu->arch.virtual_tsc_khz) << 32;
+ tsc_ref.TscOffset = 0;
+ if (!(data & HV_X64_MSR_TSC_REFERENCE_ENABLE)) {
+ kvm->arch.hv_tsc_page = data;
+ break;
+ }
+ addr = gfn_to_hva(vcpu->kvm, data >>
+ HV_X64_MSR_TSC_REFERENCE_ADDRESS_SHIFT);
if (kvm_is_error_hva(addr))
return 1;
- tsc_ref = 0;
if(__copy_to_user((void __user *)addr, &tsc_ref,
sizeof(tsc_ref)))
return 1;
kvm->arch.hv_tsc_page = data;
@@ -2553,6 +2560,7 @@ int kvm_dev_ioctl_check_extension(long ext)
case KVM_CAP_HYPERV:
case KVM_CAP_HYPERV_VAPIC:
case KVM_CAP_HYPERV_SPIN:
+ case KVM_CAP_HYPERV_TSC:
case KVM_CAP_PCI_SEGMENT:
case KVM_CAP_DEBUGREGS:
case KVM_CAP_X86_ROBUST_SINGLESTEP:
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index a5c86fc..8eff540 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -666,6 +666,7 @@ struct kvm_ppc_smmu_info {
#define KVM_CAP_IRQ_MPIC 90
#define KVM_CAP_PPC_RTAS 91
#define KVM_CAP_IRQ_XICS 92
+#define KVM_CAP_HYPERV_TSC 93
#ifdef KVM_CAP_IRQ_ROUTING
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/2] Hyper-H reference counter
On Mon, 2013-05-13 at 16:30 -0700, Eric Northup wrote:
> On Mon, May 13, 2013 at 4:45 AM, Vadim Rozenfeld wrote:
> > Signed-off: Peter Lieven
> > Signed-off: Gleb Natapov
> > Signed-off: Vadim Rozenfeld
> >
> > The following patch allows to activate Hyper-V
> > reference time counter
> > ---
> > arch/x86/include/asm/kvm_host.h| 2 ++
> > arch/x86/include/uapi/asm/hyperv.h | 3 +++
> > arch/x86/kvm/x86.c | 25 -
> > 3 files changed, 29 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/x86/include/asm/kvm_host.h
> > b/arch/x86/include/asm/kvm_host.h
> > index 3741c65..f0fee35 100644
> > --- a/arch/x86/include/asm/kvm_host.h
> > +++ b/arch/x86/include/asm/kvm_host.h
> > @@ -575,6 +575,8 @@ struct kvm_arch {
> > /* fields used by HYPER-V emulation */
> > u64 hv_guest_os_id;
> > u64 hv_hypercall;
> > + u64 hv_ref_count;
> > + u64 hv_tsc_page;
> >
> > #ifdef CONFIG_KVM_MMU_AUDIT
> > int audit_point;
> > diff --git a/arch/x86/include/uapi/asm/hyperv.h
> > b/arch/x86/include/uapi/asm/hyperv.h
> > index b80420b..9711819 100644
> > --- a/arch/x86/include/uapi/asm/hyperv.h
> > +++ b/arch/x86/include/uapi/asm/hyperv.h
> > @@ -136,6 +136,9 @@
> > /* MSR used to read the per-partition time reference counter */
> > #define HV_X64_MSR_TIME_REF_COUNT 0x4020
> >
> > +/* A partition's reference time stamp counter (TSC) page */
> > +#define HV_X64_MSR_REFERENCE_TSC 0x4021
> > +
> > /* Define the virtual APIC registers */
> > #define HV_X64_MSR_EOI 0x4070
> > #define HV_X64_MSR_ICR 0x4071
> > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > index 094b5d9..1a4036d 100644
> > --- a/arch/x86/kvm/x86.c
> > +++ b/arch/x86/kvm/x86.c
> > @@ -843,7 +843,7 @@ EXPORT_SYMBOL_GPL(kvm_rdpmc);
> > static u32 msrs_to_save[] = {
> > MSR_KVM_SYSTEM_TIME, MSR_KVM_WALL_CLOCK,
> > MSR_KVM_SYSTEM_TIME_NEW, MSR_KVM_WALL_CLOCK_NEW,
> > - HV_X64_MSR_GUEST_OS_ID, HV_X64_MSR_HYPERCALL,
> > + HV_X64_MSR_GUEST_OS_ID,
> > HV_X64_MSR_HYPERCALL,HV_X64_MSR_TIME_REF_COUNT,
> > HV_X64_MSR_APIC_ASSIST_PAGE, MSR_KVM_ASYNC_PF_EN,
> > MSR_KVM_STEAL_TIME,
> > MSR_KVM_PV_EOI_EN,
> > MSR_IA32_SYSENTER_CS, MSR_IA32_SYSENTER_ESP, MSR_IA32_SYSENTER_EIP,
> > @@ -1764,6 +1764,8 @@ static bool kvm_hv_msr_partition_wide(u32 msr)
> > switch (msr) {
> > case HV_X64_MSR_GUEST_OS_ID:
> > case HV_X64_MSR_HYPERCALL:
> > + case HV_X64_MSR_REFERENCE_TSC:
> > + case HV_X64_MSR_TIME_REF_COUNT:
> > r = true;
> > break;
> > }
> > @@ -1803,6 +1805,21 @@ static int set_msr_hyperv_pw(struct kvm_vcpu *vcpu,
> > u32 msr, u64 data)
> > if (__copy_to_user((void __user *)addr, instructions, 4))
> > return 1;
> > kvm->arch.hv_hypercall = data;
> > + kvm->arch.hv_ref_count = get_kernel_ns();
> > + break;
> > + }
> > + case HV_X64_MSR_REFERENCE_TSC: {
> > + u64 gfn;
> > + unsigned long addr;
> > + u32 tsc_ref;
> > + gfn = data >> HV_X64_MSR_HYPERCALL_PAGE_ADDRESS_SHIFT;
> > + addr = gfn_to_hva(kvm, gfn);
> > + if (kvm_is_error_hva(addr))
> > + return 1;
> > + tsc_ref = 0;
> > + if(__copy_to_user((void __user *)addr, &tsc_ref,
> > sizeof(tsc_ref)))
>
> Does this do the right thing when we're migrating? How does usermode
> learn that the guest page has been dirtied?
>
No, it shouldn't be a problem for this patch. Guest allocates a page
from nonpaged physical memory, maps it to the system address space, gets
physical address and sends it to KVM. KVM sets the first DWORD
(TscSequence) to zero, which means that guest will use reference time
counter as a timestamp source even after migration.
> > + return 1;
> > + kvm->arch.hv_tsc_page = data;
> > break;
> > }
> > default:
> > @@ -2229,6 +2246,12 @@ static int get_msr_hyperv_pw(struct kvm_vcpu *vcpu,
> > u32 msr, u64 *pdata)
> > case HV_X64_MSR_HYPERCALL:
> > data = kvm->arch.hv_hypercall
Re: [RFC PATCH 1/2] Hyper-H reference counter
On Tue, 2013-05-14 at 16:14 +0200, Peter Lieven wrote:
> On 13.05.2013 13:45, Vadim Rozenfeld wrote:
> > Signed-off: Peter Lieven
> > Signed-off: Gleb Natapov
> > Signed-off: Vadim Rozenfeld
> >
> > The following patch allows to activate Hyper-V
> > reference time counter
> > ---
> > arch/x86/include/asm/kvm_host.h| 2 ++
> > arch/x86/include/uapi/asm/hyperv.h | 3 +++
> > arch/x86/kvm/x86.c | 25 -
> > 3 files changed, 29 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/x86/include/asm/kvm_host.h
> > b/arch/x86/include/asm/kvm_host.h
> > index 3741c65..f0fee35 100644
> > --- a/arch/x86/include/asm/kvm_host.h
> > +++ b/arch/x86/include/asm/kvm_host.h
> > @@ -575,6 +575,8 @@ struct kvm_arch {
> > /* fields used by HYPER-V emulation */
> > u64 hv_guest_os_id;
> > u64 hv_hypercall;
> > + u64 hv_ref_count;
> > + u64 hv_tsc_page;
> >
> > #ifdef CONFIG_KVM_MMU_AUDIT
> > int audit_point;
> > diff --git a/arch/x86/include/uapi/asm/hyperv.h
> > b/arch/x86/include/uapi/asm/hyperv.h
> > index b80420b..9711819 100644
> > --- a/arch/x86/include/uapi/asm/hyperv.h
> > +++ b/arch/x86/include/uapi/asm/hyperv.h
> > @@ -136,6 +136,9 @@
> > /* MSR used to read the per-partition time reference counter */
> > #define HV_X64_MSR_TIME_REF_COUNT 0x4020
> >
> > +/* A partition's reference time stamp counter (TSC) page */
> > +#define HV_X64_MSR_REFERENCE_TSC 0x4021
> > +
> > /* Define the virtual APIC registers */
> > #define HV_X64_MSR_EOI0x4070
> > #define HV_X64_MSR_ICR0x4071
> > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > index 094b5d9..1a4036d 100644
> > --- a/arch/x86/kvm/x86.c
> > +++ b/arch/x86/kvm/x86.c
> > @@ -843,7 +843,7 @@ EXPORT_SYMBOL_GPL(kvm_rdpmc);
> > static u32 msrs_to_save[] = {
> > MSR_KVM_SYSTEM_TIME, MSR_KVM_WALL_CLOCK,
> > MSR_KVM_SYSTEM_TIME_NEW, MSR_KVM_WALL_CLOCK_NEW,
> > - HV_X64_MSR_GUEST_OS_ID, HV_X64_MSR_HYPERCALL,
> > + HV_X64_MSR_GUEST_OS_ID, HV_X64_MSR_HYPERCALL,HV_X64_MSR_TIME_REF_COUNT,
> > HV_X64_MSR_APIC_ASSIST_PAGE, MSR_KVM_ASYNC_PF_EN, MSR_KVM_STEAL_TIME,
> > MSR_KVM_PV_EOI_EN,
> > MSR_IA32_SYSENTER_CS, MSR_IA32_SYSENTER_ESP, MSR_IA32_SYSENTER_EIP,
> > @@ -1764,6 +1764,8 @@ static bool kvm_hv_msr_partition_wide(u32 msr)
> > switch (msr) {
> > case HV_X64_MSR_GUEST_OS_ID:
> > case HV_X64_MSR_HYPERCALL:
> > + case HV_X64_MSR_REFERENCE_TSC:
> > + case HV_X64_MSR_TIME_REF_COUNT:
> > r = true;
> > break;
> > }
> > @@ -1803,6 +1805,21 @@ static int set_msr_hyperv_pw(struct kvm_vcpu *vcpu,
> > u32 msr, u64 data)
> > if (__copy_to_user((void __user *)addr, instructions, 4))
> > return 1;
> > kvm->arch.hv_hypercall = data;
> > + kvm->arch.hv_ref_count = get_kernel_ns();
> > + break;
> > + }
> > + case HV_X64_MSR_REFERENCE_TSC: {
> > + u64 gfn;
> > + unsigned long addr;
> > + u32 tsc_ref;
> > + gfn = data >> HV_X64_MSR_HYPERCALL_PAGE_ADDRESS_SHIFT;
> > + addr = gfn_to_hva(kvm, gfn);
> > + if (kvm_is_error_hva(addr))
> > + return 1;
> > + tsc_ref = 0;
> > + if(__copy_to_user((void __user *)addr, &tsc_ref,
> > sizeof(tsc_ref)))
> > + return 1;
> > + kvm->arch.hv_tsc_page = data;
> > break;
> > }
> > default:
> > @@ -2229,6 +2246,12 @@ static int get_msr_hyperv_pw(struct kvm_vcpu *vcpu,
> > u32 msr, u64 *pdata)
> > case HV_X64_MSR_HYPERCALL:
> > data = kvm->arch.hv_hypercall;
> > break;
> > + case HV_X64_MSR_TIME_REF_COUNT:
> > + data = div_u64(get_kernel_ns() - kvm->arch.hv_ref_count,100);
> > + break;
>
>
> in an earlier version of this patch I have the following:
>
> + case HV_X64_MSR_TIME_REF_COUNT: {
> + u64 now_ns;
> + local_irq_disable();
> + now_ns = get_kernel_ns();
> + data = div_u64(now_ns + kvm->arch.kvmclock_offset -
> kvm->arch.hv_ref_count,100);
> + local_irq_enable();
> + break;
> + }
>
> I do not know if this is right, but I can report that this one is working
> without any flaws
> since approx. 1.5 years.
Hi Peter,
I created this patch based on the original code posted
in thread http://marc.info/?l=kvm&m=133278705514826
But please feel free to send your version, if you see any problem
in the current code.
Best regards,
Vadim.
> Peter
--
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: [RFC PATCH 1/2] Hyper-H reference counter
On Thu, 2013-05-16 at 11:18 +0300, Gleb Natapov wrote:
> On Tue, May 14, 2013 at 07:46:36PM +1000, Vadim Rozenfeld wrote:
> > On Mon, 2013-05-13 at 16:30 -0700, Eric Northup wrote:
> > > On Mon, May 13, 2013 at 4:45 AM, Vadim Rozenfeld
> > > wrote:
> > > > Signed-off: Peter Lieven
> > > > Signed-off: Gleb Natapov
> > > > Signed-off: Vadim Rozenfeld
> > > >
> > > > The following patch allows to activate Hyper-V
> > > > reference time counter
> > > > ---
> > > > arch/x86/include/asm/kvm_host.h| 2 ++
> > > > arch/x86/include/uapi/asm/hyperv.h | 3 +++
> > > > arch/x86/kvm/x86.c | 25 -
> > > > 3 files changed, 29 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/arch/x86/include/asm/kvm_host.h
> > > > b/arch/x86/include/asm/kvm_host.h
> > > > index 3741c65..f0fee35 100644
> > > > --- a/arch/x86/include/asm/kvm_host.h
> > > > +++ b/arch/x86/include/asm/kvm_host.h
> > > > @@ -575,6 +575,8 @@ struct kvm_arch {
> > > > /* fields used by HYPER-V emulation */
> > > > u64 hv_guest_os_id;
> > > > u64 hv_hypercall;
> > > > + u64 hv_ref_count;
> > > > + u64 hv_tsc_page;
> > > >
> > > > #ifdef CONFIG_KVM_MMU_AUDIT
> > > > int audit_point;
> > > > diff --git a/arch/x86/include/uapi/asm/hyperv.h
> > > > b/arch/x86/include/uapi/asm/hyperv.h
> > > > index b80420b..9711819 100644
> > > > --- a/arch/x86/include/uapi/asm/hyperv.h
> > > > +++ b/arch/x86/include/uapi/asm/hyperv.h
> > > > @@ -136,6 +136,9 @@
> > > > /* MSR used to read the per-partition time reference counter */
> > > > #define HV_X64_MSR_TIME_REF_COUNT 0x4020
> > > >
> > > > +/* A partition's reference time stamp counter (TSC) page */
> > > > +#define HV_X64_MSR_REFERENCE_TSC 0x4021
> > > > +
> > > > /* Define the virtual APIC registers */
> > > > #define HV_X64_MSR_EOI 0x4070
> > > > #define HV_X64_MSR_ICR 0x4071
> > > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > > > index 094b5d9..1a4036d 100644
> > > > --- a/arch/x86/kvm/x86.c
> > > > +++ b/arch/x86/kvm/x86.c
> > > > @@ -843,7 +843,7 @@ EXPORT_SYMBOL_GPL(kvm_rdpmc);
> > > > static u32 msrs_to_save[] = {
> > > > MSR_KVM_SYSTEM_TIME, MSR_KVM_WALL_CLOCK,
> > > > MSR_KVM_SYSTEM_TIME_NEW, MSR_KVM_WALL_CLOCK_NEW,
> > > > - HV_X64_MSR_GUEST_OS_ID, HV_X64_MSR_HYPERCALL,
> > > > + HV_X64_MSR_GUEST_OS_ID,
> > > > HV_X64_MSR_HYPERCALL,HV_X64_MSR_TIME_REF_COUNT,
> > > > HV_X64_MSR_APIC_ASSIST_PAGE, MSR_KVM_ASYNC_PF_EN,
> > > > MSR_KVM_STEAL_TIME,
> > > > MSR_KVM_PV_EOI_EN,
> > > > MSR_IA32_SYSENTER_CS, MSR_IA32_SYSENTER_ESP,
> > > > MSR_IA32_SYSENTER_EIP,
> > > > @@ -1764,6 +1764,8 @@ static bool kvm_hv_msr_partition_wide(u32 msr)
> > > > switch (msr) {
> > > > case HV_X64_MSR_GUEST_OS_ID:
> > > > case HV_X64_MSR_HYPERCALL:
> > > > + case HV_X64_MSR_REFERENCE_TSC:
> > > > + case HV_X64_MSR_TIME_REF_COUNT:
> > > > r = true;
> > > > break;
> > > > }
> > > > @@ -1803,6 +1805,21 @@ static int set_msr_hyperv_pw(struct kvm_vcpu
> > > > *vcpu, u32 msr, u64 data)
> > > > if (__copy_to_user((void __user *)addr, instructions,
> > > > 4))
> > > > return 1;
> > > > kvm->arch.hv_hypercall = data;
> > > > + kvm->arch.hv_ref_count = get_kernel_ns();
> > > > + break;
> > > > + }
> > > > + case HV_X64_MSR_REFERENCE_TSC: {
> > > > + u64 gfn;
> > > > + unsigned long addr;
> > > > + u32 tsc_ref;
> > > > + gfn = data >> HV_X64_MSR_HYPERCALL_PAGE_ADDRESS_SHIFT;
> > > > + addr = gfn_to_hva(kvm, gfn);
> > > > + if (kvm_is_error_hva(addr))
> > > > + return 1;
> > > > + tsc_ref = 0;
> > > > + if(__copy_to_user((void __user *)addr, &tsc_ref,
> > > > sizeof(tsc_ref)))
> > >
> > > Does this do the right thing when we're migrating? How does usermode
> > > learn that the guest page has been dirtied?
> > >
> >
> > No, it shouldn't be a problem for this patch. Guest allocates a page
> > from nonpaged physical memory, maps it to the system address space, gets
> > physical address and sends it to KVM. KVM sets the first DWORD
> > (TscSequence) to zero, which means that guest will use reference time
> > counter as a timestamp source even after migration.
> >
> Eric is right, we need mark_page_dirty() here and in HV_X64_MSR_HYPERCALL
> too. Without it QEMU will not know that content of the page has changed
> and will not migrate it.
OK. Will fix it.
>
> --
> Gleb.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 2/2] Hyper-V iTSC handler
On Thu, 2013-05-16 at 11:33 +0300, Gleb Natapov wrote:
> On Mon, May 13, 2013 at 09:45:17PM +1000, Vadim Rozenfeld wrote:
> > Signed-off: Vadim Rozenfeld
> >
> > The following patch allows to activate a partition reference
> > time enlightenment that is based on the host platform's support
> > for an Invariant Time Stamp Counter (iTSC).
> > NOTE: This code will survive migration due to lack of VM stop/resume
> > handlers.
> >
> Do you mean "will _not_ survive migration"?
Sorry for typo. Yes, it will not,
because offset, scale and sequence must be
readjusted.
>
> > ---
> > arch/x86/include/uapi/asm/hyperv.h | 10 ++
> > arch/x86/kvm/x86.c | 18 +-
> > include/uapi/linux/kvm.h | 1 +
> > 3 files changed, 24 insertions(+), 5 deletions(-)
> >
> > diff --git a/arch/x86/include/uapi/asm/hyperv.h
> > b/arch/x86/include/uapi/asm/hyperv.h
> > index 9711819..2d9e666 100644
> > --- a/arch/x86/include/uapi/asm/hyperv.h
> > +++ b/arch/x86/include/uapi/asm/hyperv.h
> > @@ -182,6 +182,9 @@
> > #define HV_X64_MSR_APIC_ASSIST_PAGE_ADDRESS_MASK \
> > (~((1ull << HV_X64_MSR_APIC_ASSIST_PAGE_ADDRESS_SHIFT) - 1))
> >
> > +#define HV_X64_MSR_TSC_REFERENCE_ENABLE0x0001
> > +#define HV_X64_MSR_TSC_REFERENCE_ADDRESS_SHIFT 12
> > +
> > #define HV_PROCESSOR_POWER_STATE_C00
> > #define HV_PROCESSOR_POWER_STATE_C11
> > #define HV_PROCESSOR_POWER_STATE_C22
> > @@ -194,4 +197,11 @@
> > #define HV_STATUS_INVALID_ALIGNMENT4
> > #define HV_STATUS_INSUFFICIENT_BUFFERS 19
> >
> > +typedef struct _HV_REFERENCE_TSC_PAGE {
> > + uint32_t TscSequence;
> > + uint32_t Rserved1;
> > + uint64_t TscScale;
> > + int64_t TscOffset;
> > +} HV_REFERENCE_TSC_PAGE, * PHV_REFERENCE_TSC_PAGE;
> > +
> Use kernel types: __u32/__u64/__s64.
>
> > #endif
> > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > index 1a4036d..5788e8f 100644
> > --- a/arch/x86/kvm/x86.c
> > +++ b/arch/x86/kvm/x86.c
> > @@ -1809,14 +1809,21 @@ static int set_msr_hyperv_pw(struct kvm_vcpu *vcpu,
> > u32 msr, u64 data)
> > break;
> > }
> > case HV_X64_MSR_REFERENCE_TSC: {
> > - u64 gfn;
> > unsigned long addr;
> > - u32 tsc_ref;
> > - gfn = data >> HV_X64_MSR_HYPERCALL_PAGE_ADDRESS_SHIFT;
> > - addr = gfn_to_hva(kvm, gfn);
> > + HV_REFERENCE_TSC_PAGE tsc_ref;
> > + tsc_ref.TscSequence =
> > + boot_cpu_has(X86_FEATURE_CONSTANT_TSC) ? 1 : 0;
> > + tsc_ref.TscScale =
> > + ((1LL << 32) /vcpu->arch.virtual_tsc_khz) << 32;
> > + tsc_ref.TscOffset = 0;
> > + if (!(data & HV_X64_MSR_TSC_REFERENCE_ENABLE)) {
> > + kvm->arch.hv_tsc_page = data;
> > + break;
> > + }
> > + addr = gfn_to_hva(vcpu->kvm, data >>
> > + HV_X64_MSR_TSC_REFERENCE_ADDRESS_SHIFT);
> > if (kvm_is_error_hva(addr))
> > return 1;
> > - tsc_ref = 0;
> > if(__copy_to_user((void __user *)addr, &tsc_ref,
> > sizeof(tsc_ref)))
> > return 1;
> > kvm->arch.hv_tsc_page = data;
> > @@ -2553,6 +2560,7 @@ int kvm_dev_ioctl_check_extension(long ext)
> > case KVM_CAP_HYPERV:
> > case KVM_CAP_HYPERV_VAPIC:
> > case KVM_CAP_HYPERV_SPIN:
> > + case KVM_CAP_HYPERV_TSC:
> > case KVM_CAP_PCI_SEGMENT:
> > case KVM_CAP_DEBUGREGS:
> > case KVM_CAP_X86_ROBUST_SINGLESTEP:
> > diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> > index a5c86fc..8eff540 100644
> > --- a/include/uapi/linux/kvm.h
> > +++ b/include/uapi/linux/kvm.h
> > @@ -666,6 +666,7 @@ struct kvm_ppc_smmu_info {
> > #define KVM_CAP_IRQ_MPIC 90
> > #define KVM_CAP_PPC_RTAS 91
> > #define KVM_CAP_IRQ_XICS 92
> > +#define KVM_CAP_HYPERV_TSC 93
> >
> > #ifdef KVM_CAP_IRQ_ROUTING
> >
> > --
> > 1.8.1.2
>
> --
> Gleb.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/2] Hyper-H reference counter
On Thu, 2013-05-16 at 11:34 +0300, Gleb Natapov wrote:
> On Mon, May 13, 2013 at 09:45:16PM +1000, Vadim Rozenfeld wrote:
> > Signed-off: Peter Lieven
> > Signed-off: Gleb Natapov
> > Signed-off: Vadim Rozenfeld
> >
> > The following patch allows to activate Hyper-V
> > reference time counter
> > ---
> > arch/x86/include/asm/kvm_host.h| 2 ++
> > arch/x86/include/uapi/asm/hyperv.h | 3 +++
> > arch/x86/kvm/x86.c | 25 -
> > 3 files changed, 29 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/x86/include/asm/kvm_host.h
> > b/arch/x86/include/asm/kvm_host.h
> > index 3741c65..f0fee35 100644
> > --- a/arch/x86/include/asm/kvm_host.h
> > +++ b/arch/x86/include/asm/kvm_host.h
> > @@ -575,6 +575,8 @@ struct kvm_arch {
> > /* fields used by HYPER-V emulation */
> > u64 hv_guest_os_id;
> > u64 hv_hypercall;
> > + u64 hv_ref_count;
> > + u64 hv_tsc_page;
> >
> > #ifdef CONFIG_KVM_MMU_AUDIT
> > int audit_point;
> > diff --git a/arch/x86/include/uapi/asm/hyperv.h
> > b/arch/x86/include/uapi/asm/hyperv.h
> > index b80420b..9711819 100644
> > --- a/arch/x86/include/uapi/asm/hyperv.h
> > +++ b/arch/x86/include/uapi/asm/hyperv.h
> > @@ -136,6 +136,9 @@
> > /* MSR used to read the per-partition time reference counter */
> > #define HV_X64_MSR_TIME_REF_COUNT 0x4020
> >
> > +/* A partition's reference time stamp counter (TSC) page */
> > +#define HV_X64_MSR_REFERENCE_TSC 0x4021
> > +
> > /* Define the virtual APIC registers */
> > #define HV_X64_MSR_EOI 0x4070
> > #define HV_X64_MSR_ICR 0x4071
> > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > index 094b5d9..1a4036d 100644
> > --- a/arch/x86/kvm/x86.c
> > +++ b/arch/x86/kvm/x86.c
> > @@ -843,7 +843,7 @@ EXPORT_SYMBOL_GPL(kvm_rdpmc);
> > static u32 msrs_to_save[] = {
> > MSR_KVM_SYSTEM_TIME, MSR_KVM_WALL_CLOCK,
> > MSR_KVM_SYSTEM_TIME_NEW, MSR_KVM_WALL_CLOCK_NEW,
> > - HV_X64_MSR_GUEST_OS_ID, HV_X64_MSR_HYPERCALL,
> > + HV_X64_MSR_GUEST_OS_ID, HV_X64_MSR_HYPERCALL,HV_X64_MSR_TIME_REF_COUNT,
> > HV_X64_MSR_APIC_ASSIST_PAGE, MSR_KVM_ASYNC_PF_EN, MSR_KVM_STEAL_TIME,
> > MSR_KVM_PV_EOI_EN,
> > MSR_IA32_SYSENTER_CS, MSR_IA32_SYSENTER_ESP, MSR_IA32_SYSENTER_EIP,
> > @@ -1764,6 +1764,8 @@ static bool kvm_hv_msr_partition_wide(u32 msr)
> > switch (msr) {
> > case HV_X64_MSR_GUEST_OS_ID:
> > case HV_X64_MSR_HYPERCALL:
> > + case HV_X64_MSR_REFERENCE_TSC:
> > + case HV_X64_MSR_TIME_REF_COUNT:
> > r = true;
> > break;
> > }
> > @@ -1803,6 +1805,21 @@ static int set_msr_hyperv_pw(struct kvm_vcpu *vcpu,
> > u32 msr, u64 data)
> > if (__copy_to_user((void __user *)addr, instructions, 4))
> > return 1;
> > kvm->arch.hv_hypercall = data;
> > + kvm->arch.hv_ref_count = get_kernel_ns();
> > + break;
> > + }
> > + case HV_X64_MSR_REFERENCE_TSC: {
> > + u64 gfn;
> > + unsigned long addr;
> > + u32 tsc_ref;
> > + gfn = data >> HV_X64_MSR_HYPERCALL_PAGE_ADDRESS_SHIFT;
> Shouldn't you check HV_X64_MSR_TSC_REFERENCE_ENABLE here?
Yes, I have this check added in the second patch.
>
> > + addr = gfn_to_hva(kvm, gfn);
> > + if (kvm_is_error_hva(addr))
> > + return 1;
> > + tsc_ref = 0;
> > + if(__copy_to_user((void __user *)addr, &tsc_ref,
> > sizeof(tsc_ref)))
> > + return 1;
> > + kvm->arch.hv_tsc_page = data;
> > break;
> > }
> > default:
> > @@ -2229,6 +2246,12 @@ static int get_msr_hyperv_pw(struct kvm_vcpu *vcpu,
> > u32 msr, u64 *pdata)
> > case HV_X64_MSR_HYPERCALL:
> > data = kvm->arch.hv_hypercall;
> > break;
> > + case HV_X64_MSR_TIME_REF_COUNT:
> > + data = div_u64(get_kernel_ns() - kvm->arch.hv_ref_count,100);
> > + break;
> > + case HV_X64_MSR_REFERENCE_TSC:
> > + data = kvm->arch.hv_tsc_page;
> > + break;
> > default:
> > vcpu_unimpl(vcpu, "Hyper-V unhandled rdmsr: 0x%x\n", msr);
> > return 1;
> > --
> > 1.8.1.2
>
> --
> Gleb.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/2] Hyper-H reference counter
On Thu, 2013-05-16 at 12:21 +0300, Gleb Natapov wrote:
> On Thu, May 16, 2013 at 07:13:41PM +1000, Vadim Rozenfeld wrote:
> > On Thu, 2013-05-16 at 11:34 +0300, Gleb Natapov wrote:
> > > On Mon, May 13, 2013 at 09:45:16PM +1000, Vadim Rozenfeld wrote:
> > > > Signed-off: Peter Lieven
> > > > Signed-off: Gleb Natapov
> > > > Signed-off: Vadim Rozenfeld
> > > >
> > > > The following patch allows to activate Hyper-V
> > > > reference time counter
> > > > ---
> > > > arch/x86/include/asm/kvm_host.h| 2 ++
> > > > arch/x86/include/uapi/asm/hyperv.h | 3 +++
> > > > arch/x86/kvm/x86.c | 25 -
> > > > 3 files changed, 29 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/arch/x86/include/asm/kvm_host.h
> > > > b/arch/x86/include/asm/kvm_host.h
> > > > index 3741c65..f0fee35 100644
> > > > --- a/arch/x86/include/asm/kvm_host.h
> > > > +++ b/arch/x86/include/asm/kvm_host.h
> > > > @@ -575,6 +575,8 @@ struct kvm_arch {
> > > > /* fields used by HYPER-V emulation */
> > > > u64 hv_guest_os_id;
> > > > u64 hv_hypercall;
> > > > + u64 hv_ref_count;
> > > > + u64 hv_tsc_page;
> > > >
> > > > #ifdef CONFIG_KVM_MMU_AUDIT
> > > > int audit_point;
> > > > diff --git a/arch/x86/include/uapi/asm/hyperv.h
> > > > b/arch/x86/include/uapi/asm/hyperv.h
> > > > index b80420b..9711819 100644
> > > > --- a/arch/x86/include/uapi/asm/hyperv.h
> > > > +++ b/arch/x86/include/uapi/asm/hyperv.h
> > > > @@ -136,6 +136,9 @@
> > > > /* MSR used to read the per-partition time reference counter */
> > > > #define HV_X64_MSR_TIME_REF_COUNT 0x4020
> > > >
> > > > +/* A partition's reference time stamp counter (TSC) page */
> > > > +#define HV_X64_MSR_REFERENCE_TSC 0x4021
> > > > +
> > > > /* Define the virtual APIC registers */
> > > > #define HV_X64_MSR_EOI 0x4070
> > > > #define HV_X64_MSR_ICR 0x4071
> > > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > > > index 094b5d9..1a4036d 100644
> > > > --- a/arch/x86/kvm/x86.c
> > > > +++ b/arch/x86/kvm/x86.c
> > > > @@ -843,7 +843,7 @@ EXPORT_SYMBOL_GPL(kvm_rdpmc);
> > > > static u32 msrs_to_save[] = {
> > > > MSR_KVM_SYSTEM_TIME, MSR_KVM_WALL_CLOCK,
> > > > MSR_KVM_SYSTEM_TIME_NEW, MSR_KVM_WALL_CLOCK_NEW,
> > > > - HV_X64_MSR_GUEST_OS_ID, HV_X64_MSR_HYPERCALL,
> > > > + HV_X64_MSR_GUEST_OS_ID,
> > > > HV_X64_MSR_HYPERCALL,HV_X64_MSR_TIME_REF_COUNT,
> > > > HV_X64_MSR_APIC_ASSIST_PAGE, MSR_KVM_ASYNC_PF_EN,
> > > > MSR_KVM_STEAL_TIME,
> > > > MSR_KVM_PV_EOI_EN,
> > > > MSR_IA32_SYSENTER_CS, MSR_IA32_SYSENTER_ESP,
> > > > MSR_IA32_SYSENTER_EIP,
> > > > @@ -1764,6 +1764,8 @@ static bool kvm_hv_msr_partition_wide(u32 msr)
> > > > switch (msr) {
> > > > case HV_X64_MSR_GUEST_OS_ID:
> > > > case HV_X64_MSR_HYPERCALL:
> > > > + case HV_X64_MSR_REFERENCE_TSC:
> > > > + case HV_X64_MSR_TIME_REF_COUNT:
> > > > r = true;
> > > > break;
> > > > }
> > > > @@ -1803,6 +1805,21 @@ static int set_msr_hyperv_pw(struct kvm_vcpu
> > > > *vcpu, u32 msr, u64 data)
> > > > if (__copy_to_user((void __user *)addr, instructions,
> > > > 4))
> > > > return 1;
> > > > kvm->arch.hv_hypercall = data;
> > > > + kvm->arch.hv_ref_count = get_kernel_ns();
> > > > + break;
> > > > + }
> > > > + case HV_X64_MSR_REFERENCE_TSC: {
> > > > + u64 gfn;
> > > > + unsigned long addr;
> > > > + u32 tsc_ref;
> > > > + gfn = data >> HV_X64_MSR_HYPERCALL_PAGE_ADDRESS_SHIFT;
> > > Shouldn't you check HV_X64_MSR_TSC_REFERENCE_ENABLE here?
> >
> > Yes, I have this check added in the second patch.
> >
> Move it here please
Re: [RFC PATCH 1/2] Hyper-H reference counter
On Thu, 2013-05-16 at 15:37 +0200, Paolo Bonzini wrote:
> Il 16/05/2013 11:28, Vadim Rozenfeld ha scritto:
> >>>>> > > > > + case HV_X64_MSR_REFERENCE_TSC: {
> >>>>> > > > > + u64 gfn;
> >>>>> > > > > + unsigned long addr;
> >>>>> > > > > + u32 tsc_ref;
> >>>>> > > > > + gfn = data >>
> >>>>> > > > > HV_X64_MSR_HYPERCALL_PAGE_ADDRESS_SHIFT;
> >>>> > > > Shouldn't you check HV_X64_MSR_TSC_REFERENCE_ENABLE here?
> >>> > >
> >>> > > Yes, I have this check added in the second patch.
> >>> > >
> >> > Move it here please.
> > OK, will do it.
> >> >
> >>>> > > >
> >>>>> > > > > + addr = gfn_to_hva(kvm, gfn);
> >>>>> > > > > + if (kvm_is_error_hva(addr))
> >>>>> > > > > + return 1;
> >>>>> > > > > + tsc_ref = 0;
>
> This should write 0x.
This should write 0
Vadim.
>
> Paolo
--
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: [RFC PATCH 1/2] Hyper-H reference counter
On Thu, 2013-05-16 at 15:44 +0200, Paolo Bonzini wrote:
> Il 16/05/2013 11:28, Vadim Rozenfeld ha scritto:
> > On Thu, 2013-05-16 at 12:21 +0300, Gleb Natapov wrote:
> >> On Thu, May 16, 2013 at 07:13:41PM +1000, Vadim Rozenfeld wrote:
> >>> On Thu, 2013-05-16 at 11:34 +0300, Gleb Natapov wrote:
> >>>> On Mon, May 13, 2013 at 09:45:16PM +1000, Vadim Rozenfeld wrote:
> >>>>> Signed-off: Peter Lieven
> >>>>> Signed-off: Gleb Natapov
> >>>>> Signed-off: Vadim Rozenfeld
> >>>>>
> >>>>> The following patch allows to activate Hyper-V
> >>>>> reference time counter
> >>>>> ---
> >>>>> arch/x86/include/asm/kvm_host.h| 2 ++
> >>>>> arch/x86/include/uapi/asm/hyperv.h | 3 +++
> >>>>> arch/x86/kvm/x86.c | 25 -
> >>>>> 3 files changed, 29 insertions(+), 1 deletion(-)
> >>>>>
> >>>>> diff --git a/arch/x86/include/asm/kvm_host.h
> >>>>> b/arch/x86/include/asm/kvm_host.h
> >>>>> index 3741c65..f0fee35 100644
> >>>>> --- a/arch/x86/include/asm/kvm_host.h
> >>>>> +++ b/arch/x86/include/asm/kvm_host.h
> >>>>> @@ -575,6 +575,8 @@ struct kvm_arch {
> >>>>> /* fields used by HYPER-V emulation */
> >>>>> u64 hv_guest_os_id;
> >>>>> u64 hv_hypercall;
> >>>>> + u64 hv_ref_count;
> >>>>> + u64 hv_tsc_page;
> >>>>>
> >>>>> #ifdef CONFIG_KVM_MMU_AUDIT
> >>>>> int audit_point;
> >>>>> diff --git a/arch/x86/include/uapi/asm/hyperv.h
> >>>>> b/arch/x86/include/uapi/asm/hyperv.h
> >>>>> index b80420b..9711819 100644
> >>>>> --- a/arch/x86/include/uapi/asm/hyperv.h
> >>>>> +++ b/arch/x86/include/uapi/asm/hyperv.h
> >>>>> @@ -136,6 +136,9 @@
> >>>>> /* MSR used to read the per-partition time reference counter */
> >>>>> #define HV_X64_MSR_TIME_REF_COUNT 0x4020
> >>>>>
> >>>>> +/* A partition's reference time stamp counter (TSC) page */
> >>>>> +#define HV_X64_MSR_REFERENCE_TSC 0x4021
> >>>>> +
> >>>>> /* Define the virtual APIC registers */
> >>>>> #define HV_X64_MSR_EOI 0x4070
> >>>>> #define HV_X64_MSR_ICR 0x4071
> >>>>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> >>>>> index 094b5d9..1a4036d 100644
> >>>>> --- a/arch/x86/kvm/x86.c
> >>>>> +++ b/arch/x86/kvm/x86.c
> >>>>> @@ -843,7 +843,7 @@ EXPORT_SYMBOL_GPL(kvm_rdpmc);
> >>>>> static u32 msrs_to_save[] = {
> >>>>> MSR_KVM_SYSTEM_TIME, MSR_KVM_WALL_CLOCK,
> >>>>> MSR_KVM_SYSTEM_TIME_NEW, MSR_KVM_WALL_CLOCK_NEW,
> >>>>> - HV_X64_MSR_GUEST_OS_ID, HV_X64_MSR_HYPERCALL,
> >>>>> + HV_X64_MSR_GUEST_OS_ID,
> >>>>> HV_X64_MSR_HYPERCALL,HV_X64_MSR_TIME_REF_COUNT,
> >>>>> HV_X64_MSR_APIC_ASSIST_PAGE, MSR_KVM_ASYNC_PF_EN,
> >>>>> MSR_KVM_STEAL_TIME,
> >>>>> MSR_KVM_PV_EOI_EN,
> >>>>> MSR_IA32_SYSENTER_CS, MSR_IA32_SYSENTER_ESP,
> >>>>> MSR_IA32_SYSENTER_EIP,
> >>>>> @@ -1764,6 +1764,8 @@ static bool kvm_hv_msr_partition_wide(u32 msr)
> >>>>> switch (msr) {
> >>>>> case HV_X64_MSR_GUEST_OS_ID:
> >>>>> case HV_X64_MSR_HYPERCALL:
> >>>>> + case HV_X64_MSR_REFERENCE_TSC:
> >>>>> + case HV_X64_MSR_TIME_REF_COUNT:
> >>>>> r = true;
> >>>>> break;
> >>>>> }
> >>>>> @@ -1803,6 +1805,21 @@ static int set_msr_hyperv_pw(struct kvm_vcpu
> >>>>> *vcpu, u32 msr, u64 data)
> >>>>> if (__copy_to_user((void __user *)addr, instructions,
> >>>>> 4))
> >>>>> return 1;
> >>>>> kvm->arch.hv_hypercall = data;
> >>>>> + kvm->arch.hv_ref_count = get
Re: Performance issue
On Tuesday, November 27, 2012 04:54:47 PM Gleb Natapov wrote: > On Tue, Nov 27, 2012 at 02:29:20PM +0200, George-Cristian Bîrzan wrote: > > On Tue, Nov 27, 2012 at 2:20 PM, Gleb Natapov wrote: > > > On Mon, Nov 26, 2012 at 09:31:19PM +0200, George-Cristian Bîrzan wrote: > > >> On Sun, Nov 25, 2012 at 6:17 PM, George-Cristian Bîrzan > > >> wrote: > > >> > On Sun, Nov 25, 2012 at 5:19 PM, Gleb Natapov wrote: > > >> >> What Windows is this? Can you try changing "-cpu host" to "-cpu > > >> >> host,+hv_relaxed"? > > >> > > > >> > This is on Windows Server 2008 R2 (sorry, forgot to mention that I > > >> > guess), and I can try it tomorrow (US time), as getting a stream my > > >> > way depends on complicated stuff. I will though, and let you know > > >> > how it goes. > > >> > > >> I changed that, no difference. > > > > > > Heh, I forgot that the part that should make difference is not yet > > > upstream :( > > > > We can try recompiling kvm/qemu with some patches, if that'd help. At > > this point, anything is on the table except changing Windows and the > > hardware :-) > > Vadim do you have Hyper-v reference timer patches for KVM to try? I have some code which do both reference time and invariant TSC but it will not work after migration. I will send it later today. Vadim. > > > Also, it might be that the software doing the actual work is not well > > written, but even so... > > > > -- > > George-Cristian Bîrzan > > -- > Gleb. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Performance issue
On Tuesday, November 27, 2012 11:13:12 PM George-Cristian Bîrzan wrote:
> On Tue, Nov 27, 2012 at 10:38 PM, Vadim Rozenfeld
wrote:
> > I have some code which do both reference time and invariant TSC but it
> > will not work after migration. I will send it later today.
>
> Do you mean migrating guests? This is not an issue for us.
OK, but don't say I didn't warn you :)
There are two patches, one for kvm and another one for qemu.
you will probably need to rebase them.
Add "hv_tsc" cpu parameter to activate this feature.
you will probably need to deactivate hpet by adding "-no-hpet"
parameter as well.
best regards,
Vadim.
>
> Also, it would be much appreciated!
>
> --
> George-Cristian Bîrzan
diff --git a/arch/x86/include/asm/hyperv.h b/arch/x86/include/asm/hyperv.h
index b80420b..9c5ffef 100644
--- a/arch/x86/include/asm/hyperv.h
+++ b/arch/x86/include/asm/hyperv.h
@@ -136,6 +136,9 @@
/* MSR used to read the per-partition time reference counter */
#define HV_X64_MSR_TIME_REF_COUNT 0x4020
+/* A partition's reference time stamp counter (TSC) page */
+#define HV_X64_MSR_REFERENCE_TSC 0x4021
+
/* Define the virtual APIC registers */
#define HV_X64_MSR_EOI0x4070
#define HV_X64_MSR_ICR0x4071
@@ -179,6 +182,10 @@
#define HV_X64_MSR_APIC_ASSIST_PAGE_ADDRESS_MASK \
(~((1ull << HV_X64_MSR_APIC_ASSIST_PAGE_ADDRESS_SHIFT) - 1))
+#define HV_X64_MSR_TSC_REFERENCE_ENABLE 0x0001
+#define HV_X64_MSR_TSC_REFERENCE_ADDRESS_SHIFT 12
+
+
#define HV_PROCESSOR_POWER_STATE_C0 0
#define HV_PROCESSOR_POWER_STATE_C1 1
#define HV_PROCESSOR_POWER_STATE_C2 2
@@ -191,4 +198,11 @@
#define HV_STATUS_INVALID_ALIGNMENT 4
#define HV_STATUS_INSUFFICIENT_BUFFERS 19
+typedef struct _HV_REFERENCE_TSC_PAGE {
+uint32_t TscSequence;
+uint32_t Rserved1;
+uint64_t TscScale;
+int64_t TscOffset;
+} HV_REFERENCE_TSC_PAGE, * PHV_REFERENCE_TSC_PAGE;
+
#endif
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index b2e11f4..63ee09e 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -565,6 +565,8 @@ struct kvm_arch {
/* fields used by HYPER-V emulation */
u64 hv_guest_os_id;
u64 hv_hypercall;
+ u64 hv_ref_count;
+ u64 hv_tsc_page;
#ifdef CONFIG_KVM_MMU_AUDIT
int audit_point;
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 4f76417..4538295 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -813,7 +813,7 @@ EXPORT_SYMBOL_GPL(kvm_rdpmc);
static u32 msrs_to_save[] = {
MSR_KVM_SYSTEM_TIME, MSR_KVM_WALL_CLOCK,
MSR_KVM_SYSTEM_TIME_NEW, MSR_KVM_WALL_CLOCK_NEW,
- HV_X64_MSR_GUEST_OS_ID, HV_X64_MSR_HYPERCALL,
+ HV_X64_MSR_GUEST_OS_ID, HV_X64_MSR_HYPERCALL, HV_X64_MSR_REFERENCE_TSC,
HV_X64_MSR_APIC_ASSIST_PAGE, MSR_KVM_ASYNC_PF_EN, MSR_KVM_STEAL_TIME,
MSR_KVM_PV_EOI_EN,
MSR_IA32_SYSENTER_CS, MSR_IA32_SYSENTER_ESP, MSR_IA32_SYSENTER_EIP,
@@ -1428,6 +1428,8 @@ static bool kvm_hv_msr_partition_wide(u32 msr)
switch (msr) {
case HV_X64_MSR_GUEST_OS_ID:
case HV_X64_MSR_HYPERCALL:
+ case HV_X64_MSR_TIME_REF_COUNT:
+ case HV_X64_MSR_REFERENCE_TSC:
r = true;
break;
}
@@ -1438,6 +1440,7 @@ static bool kvm_hv_msr_partition_wide(u32 msr)
static int set_msr_hyperv_pw(struct kvm_vcpu *vcpu, u32 msr, u64 data)
{
struct kvm *kvm = vcpu->kvm;
+ unsigned long addr;
switch (msr) {
case HV_X64_MSR_GUEST_OS_ID:
@@ -1467,6 +1470,27 @@ static int set_msr_hyperv_pw(struct kvm_vcpu *vcpu, u32 msr, u64 data)
if (__copy_to_user((void __user *)addr, instructions, 4))
return 1;
kvm->arch.hv_hypercall = data;
+ kvm->arch.hv_ref_count = get_kernel_ns();
+ break;
+ }
+ case HV_X64_MSR_REFERENCE_TSC: {
+ HV_REFERENCE_TSC_PAGE tsc_ref;
+ tsc_ref.TscSequence =
+ boot_cpu_has(X86_FEATURE_CONSTANT_TSC) ? 1 : 0;
+ tsc_ref.TscScale =
+ ((1LL << 32) /vcpu->arch.virtual_tsc_khz) << 32;
+ tsc_ref.TscOffset = 0;
+ if (!(data & HV_X64_MSR_TSC_REFERENCE_ENABLE)) {
+ kvm->arch.hv_tsc_page = data;
+ break;
+ }
+ addr = gfn_to_hva(vcpu->kvm, data >>
+ HV_X64_MSR_TSC_REFERENCE_ADDRESS_SHIFT);
+ if (kvm_is_error_hva(addr))
+ return 1;
+ if(__copy_to_user((void __user *)addr, &tsc_ref, sizeof(tsc_ref)))
+ return 1;
+ kvm->arch.hv_tsc_page = data;
break;
}
default:
@@ -1881,6 +1905,13 @@ static int get_msr_hyperv_pw(struct kvm_vcpu *vcpu, u32 msr, u64 *pdata)
case HV_X64_MSR_HYPERCALL:
data = kvm->arch.hv_hypercall;
break;
+ case HV_X64_MSR_TIME_REF_COUNT:
+ data = get_kernel_ns() - kvm->arch.hv_ref_count;
+ do_div(data, 100);
+ break;
+ case HV_X64_MSR_REFERENCE_TSC:
+ data = kvm->arch.hv_tsc_page;
+ break;
default:
vcpu_unimpl(vcpu, "Hyper-V unhandled rdmsr: 0x%x\n", msr);
return 1;
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index f3708e6..ad77b72 100644
---
Re: Performance issue
On Wednesday, November 28, 2012 09:09:29 PM George-Cristian Bîrzan wrote: > On Wed, Nov 28, 2012 at 1:39 PM, Vadim Rozenfeld wrote: > > On Tuesday, November 27, 2012 11:13:12 PM George-Cristian Bîrzan wrote: > >> On Tue, Nov 27, 2012 at 10:38 PM, Vadim Rozenfeld > > > > wrote: > >> > I have some code which do both reference time and invariant TSC but it > >> > will not work after migration. I will send it later today. > >> > >> Do you mean migrating guests? This is not an issue for us. > > > > OK, but don't say I didn't warn you :) > > > > There are two patches, one for kvm and another one for qemu. > > you will probably need to rebase them. > > Add "hv_tsc" cpu parameter to activate this feature. > > you will probably need to deactivate hpet by adding "-no-hpet" > > parameter as well. > > I've also added +hv_relaxed since then, but this is the command I'm I would suggest activating relaxed timing for all W2K8R2/Win7 guests. > using now and there's no change: > > /usr/bin/qemu-kvm -name b691546e-79f8-49c6-a293-81067503a6ad -S -M > pc-1.2 -enable-kvm -m 16384 -smp 9,sockets=1,cores=9,threads=1 -uuid > b691546e-79f8-49c6-a293-81067503a6ad -no-user-config -nodefaults > -chardev > socket,id=charmonitor,path=/var/lib/libvirt/qemu/b691546e-79f8-49c6-a293-8 > 1067503a6ad.monitor,server,nowait -mon > chardev=charmonitor,id=monitor,mode=control -rtc base=utc > -no-hpet -no-shutdown -device > piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive > file=/var/lib/libvirt/images/dis-magnetics-2-223101/d8b233c6-8424-4de9-ae3c > -7c9a60288514,if=none,id=drive-virtio-disk0,format=qcow2,cache=writeback,ai > o=native -device > virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=vir > tio-disk0,bootindex=1 -netdev tap,fd=35,id=hostnet0,vhost=on,vhostfd=36 > -device > virtio-net-pci,netdev=hostnet0,id=net0,mac=22:2e:fb:a2:36:be,bus=pci.0,addr > =0x3 -netdev tap,fd=40,id=hostnet1,vhost=on,vhostfd=41 -device > virtio-net-pci,netdev=hostnet1,id=net1,mac=22:94:44:5a:cb:24,bus=pci.0,addr > =0x4 -vnc 127.0.0.1:0,password -vga cirrus -device > virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 -cpu host,hv_tsc > > I compiled qemu-1.2.0-24 after applying your patch, used the head for > KVM, and I see no difference. I've tried setting windows' > useplatformclock on and off, no change either. > > > Other than that, was looking into a profiling trace of the software > running and a lot of time (60%?) is spent calling two functions from > hal.dll, HalpGetPmTimerSleepModePerfCounter when I disable HPET, and > HalpHPETProgramRolloverTimer which do point at something related to > the timers. > It means that hyper-v time stamp source was not activated. > Any other thing I can try? > > > -- > George-Cristian Bîrzan -- 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: Performance issue
On Thursday, November 29, 2012 03:56:10 PM Gleb Natapov wrote: > On Thu, Nov 29, 2012 at 03:45:52PM +0200, George-Cristian Bîrzan wrote: > > On Thu, Nov 29, 2012 at 1:56 PM, Vadim Rozenfeld wrote: > > >> I've also added +hv_relaxed since then, but this is the command I'm > > > > > > I would suggest activating relaxed timing for all W2K8R2/Win7 guests. > > > > Is there any place I can read up on the downsides of this for Linux, > > or is Just Better? > > You shouldn't use hyper-v flags for Linux guests. In theory Linux should > just ignore them, in practice there may be bugs that will prevent Linux > from detecting that it runs as a guest and disable optimizations. > As Gleb said, hyper-v flag are relevant to the Windows guests only. IIRC spinlocks and vapic should work for Vista and higher. Relaxed timing and partition reference time work for Win7/W2K8R2. > > >>>> Other than that, was looking into a profiling trace of the software > > >> > > >> running and a lot of time (60%?) is spent calling two functions from > > >> hal.dll, HalpGetPmTimerSleepModePerfCounter when I disable HPET, and > > >> HalpHPETProgramRolloverTimer which do point at something related to > > >> the timers. > > > > > > It means that hyper-v time stamp source was not activated. > > > > I recompiled the whole kernel, with your patch, and while I cannot > > check at 70Mbps now, a test stream of 20 seems to do better. Also, now > > I don't see any of those functions, which used to account ~60% of the > > time spent by the program. I'm waiting for the customer to come back > > and start the 'real' stream, but from my tests, time spent in hal.dll > > is now an order of magnitude smaller. > > > > -- > > George-Cristian Bîrzan > > -- > Gleb. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] [PATCH RFC v2 2/2] hyper-v: initialize Hyper-V CPUID leaves.
On Thu, 2011-12-01 at 15:52 +0100, Jan Kiszka wrote:
> On 2011-10-23 17:39, Vadim Rozenfeld wrote:
> > ---
> > target-i386/kvm.c | 73
> > +++-
> > 1 files changed, 71 insertions(+), 2 deletions(-)
> >
> > diff --git a/target-i386/kvm.c b/target-i386/kvm.c
> > index 82fec8c..c061e3b 100644
> > --- a/target-i386/kvm.c
> > +++ b/target-i386/kvm.c
> > @@ -29,6 +29,7 @@
> > #include "hw/pc.h"
> > #include "hw/apic.h"
> > #include "ioport.h"
> > +#include "hyperv.h"
> >
> > //#define DEBUG_KVM
> >
> > @@ -380,11 +381,16 @@ int kvm_arch_init_vcpu(CPUState *env)
> > cpuid_i = 0;
> >
> > /* Paravirtualization CPUIDs */
> > -memcpy(signature, "KVMKVMKVM\0\0\0", 12);
> > c = &cpuid_data.entries[cpuid_i++];
> > memset(c, 0, sizeof(*c));
> > c->function = KVM_CPUID_SIGNATURE;
> > -c->eax = 0;
> > +if (!hyperv_enabled()) {
> > +memcpy(signature, "KVMKVMKVM\0\0\0", 12);
> > +c->eax = 0;
> > +} else {
> > +memcpy(signature, "Microsoft Hv", 12);
> > +c->eax = HYPERV_CPUID_MIN;
> > +}
> > c->ebx = signature[0];
> > c->ecx = signature[1];
> > c->edx = signature[2];
> > @@ -395,6 +401,54 @@ int kvm_arch_init_vcpu(CPUState *env)
> > c->eax = env->cpuid_kvm_features &
> > kvm_arch_get_supported_cpuid(s, KVM_CPUID_FEATURES, 0, R_EAX);
> >
> > +if (hyperv_enabled()) {
> > +memcpy(signature, "Hv#1\0\0\0\0\0\0\0\0", 12);
> > +c->eax = signature[0];
> > +
> > +c = &cpuid_data.entries[cpuid_i++];
> > +memset(c, 0, sizeof(*c));
> > +c->function = HYPERV_CPUID_VERSION;
> > +c->eax = 0x1bbc;
> > +c->ebx = 0x00060001;
> > +
> > +c = &cpuid_data.entries[cpuid_i++];
> > +memset(c, 0, sizeof(*c));
> > +c->function = HYPERV_CPUID_FEATURES;
> > +if (hyperv_relaxed_timing_enabled()) {
> > +c->eax |= HV_X64_MSR_HYPERCALL_AVAILABLE;
> > +}
> > +if (hyperv_vapic_recommended()) {
> > +c->eax |= HV_X64_MSR_HYPERCALL_AVAILABLE;
> > +c->eax |= HV_X64_MSR_APIC_ACCESS_AVAILABLE;
> > +}
> > +
> > +c = &cpuid_data.entries[cpuid_i++];
> > +memset(c, 0, sizeof(*c));
> > +c->function = HYPERV_CPUID_ENLIGHTMENT_INFO;
> > +if (hyperv_relaxed_timing_enabled()) {
> > +c->eax |= HV_X64_RELAXED_TIMING_RECOMMENDED;
> > +}
> > +if (hyperv_vapic_recommended()) {
> > +c->eax |= HV_X64_APIC_ACCESS_RECOMMENDED;
> > +}
> > +c->ebx = hyperv_get_spinlock_retries();
> > +
> > +c = &cpuid_data.entries[cpuid_i++];
> > +memset(c, 0, sizeof(*c));
> > +c->function = HYPERV_CPUID_IMPLEMENT_LIMITS;
> > +c->eax = 0x40;
> > +c->ebx = 0x40;
> > +
> > +c = &cpuid_data.entries[cpuid_i++];
> > +memset(c, 0, sizeof(*c));
> > +c->function = KVM_CPUID_SIGNATURE_NEXT;
> > +memcpy(signature, "KVMKVMKVM\0\0\0", 12);
> > +c->eax = 0;
> > +c->ebx = signature[0];
> > +c->ecx = signature[1];
> > +c->edx = signature[2];
> > +}
> > +
> > has_msr_async_pf_en = c->eax & (1 << KVM_FEATURE_ASYNC_PF);
> >
> > cpu_x86_cpuid(env, 0, 0, &limit, &unused, &unused, &unused);
> > @@ -953,6 +1007,13 @@ static int kvm_put_msrs(CPUState *env, int level)
> > kvm_msr_entry_set(&msrs[n++], MSR_KVM_ASYNC_PF_EN,
> >env->async_pf_en_msr);
> > }
> > +if (hyperv_hypercall_available()) {
> > +kvm_msr_entry_set(&msrs[n++], HV_X64_MSR_GUEST_OS_ID, 0);
> > +kvm_msr_entry_set(&msrs[n++], HV_X64_MSR_HYPERCALL, 0);
> > +}
> > +if (hyperv_vapic_recommended()) {
> > +kvm_msr_entry_set(&msrs[n++], HV_X64_MSR_APIC_ASSIST_PAGE, 0);
> > +}
> > }
> > if (env->mcg_cap) {
> > int i;
> > @@ -1190,6 +1251,14 @@ static int kvm_get_msrs(CPUState *env)
> > msrs[n++].index
[PATCH RFC v3 0/2] Initial support for Microsoft Hyper-V.
With the following series of patches we are starting to implement some basic Microsoft Hyper-V Enlightenment functionality. This series is mostly about adding support for relaxed timing, spinlock, and virtual apic. For more Hyper-V related information please see: "Hypervisor Functional Specification v2.0: For Windows Server 2008 R2" at http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=18673 Changelog: v3->v2 - fix indention, - drop reading HV MSRs inside of kvm_get_msrs routine. v2->v1 - remove KVM_CAP_IRQCHIP ifdef, - remove CONFIG_HYPERV config option, - move KVM leaves to new location (0x4100), - cosmetic changes. v0->v1 - move hyper-v parameters under cpu category, - move hyper-v stuff to target-i386 directory, - make CONFIG_HYPERV enabled by default for i386-softmmu and x86_64-softmmu configurations, - rearrange the patches from v0, - set HV_X64_MSR_HYPERCALL, HV_X64_MSR_GUEST_OS_ID, and HV_X64_MSR_APIC_ASSIST_PAGE to 0 on system reset. Vadim Rozenfeld (2): hyper-v: introduce Hyper-V support infrastructure. hyper-v: initialize Hyper-V CPUID leaves. Makefile.target |2 + target-i386/cpuid.c | 14 ++ target-i386/hyperv.c | 65 ++ target-i386/hyperv.h | 37 target-i386/kvm.c| 65 - 5 files changed, 181 insertions(+), 2 deletions(-) create mode 100644 target-i386/hyperv.c create mode 100644 target-i386/hyperv.h -- 1.7.4.4 -- 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 RFC v3 1/2] hyper-v: introduce Hyper-V support infrastructure.
---
Makefile.target |2 +
target-i386/cpuid.c | 14 ++
target-i386/hyperv.c | 65 ++
target-i386/hyperv.h | 37
4 files changed, 118 insertions(+), 0 deletions(-)
create mode 100644 target-i386/hyperv.c
create mode 100644 target-i386/hyperv.h
diff --git a/Makefile.target b/Makefile.target
index 6e742c2..6245796 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -209,6 +209,8 @@ obj-$(CONFIG_NO_KVM) += kvm-stub.o
obj-y += memory.o
LIBS+=-lz
+obj-i386-y +=hyperv.o
+
QEMU_CFLAGS += $(VNC_TLS_CFLAGS)
QEMU_CFLAGS += $(VNC_SASL_CFLAGS)
QEMU_CFLAGS += $(VNC_JPEG_CFLAGS)
diff --git a/target-i386/cpuid.c b/target-i386/cpuid.c
index 1e8bcff..4193df1 100644
--- a/target-i386/cpuid.c
+++ b/target-i386/cpuid.c
@@ -27,6 +27,8 @@
#include "qemu-option.h"
#include "qemu-config.h"
+#include "hyperv.h"
+
/* feature flags taken from "Intel Processor Identification and the CPUID
* Instruction" and AMD's "CPUID Specification". In cases of disagreement
* between feature naming conventions, aliases may be added.
@@ -716,6 +718,14 @@ static int cpu_x86_find_by_name(x86_def_t *x86_cpu_def,
const char *cpu_model)
goto error;
}
x86_cpu_def->tsc_khz = tsc_freq / 1000;
+} else if (!strcmp(featurestr, "hv_spinlocks")) {
+char *err;
+numvalue = strtoul(val, &err, 0);
+if (!*val || *err) {
+fprintf(stderr, "bad numerical value %s\n", val);
+goto error;
+}
+hyperv_set_spinlock_retries(numvalue);
} else {
fprintf(stderr, "unrecognized feature %s\n", featurestr);
goto error;
@@ -724,6 +734,10 @@ static int cpu_x86_find_by_name(x86_def_t *x86_cpu_def,
const char *cpu_model)
check_cpuid = 1;
} else if (!strcmp(featurestr, "enforce")) {
check_cpuid = enforce_cpuid = 1;
+} else if (!strcmp(featurestr, "hv_relaxed")) {
+hyperv_enable_relaxed_timing(true);
+} else if (!strcmp(featurestr, "hv_vapic")) {
+hyperv_enable_vapic_recommended(true);
} else {
fprintf(stderr, "feature string `%s' not in format
(+feature|-feature|feature=xyz)\n", featurestr);
goto error;
diff --git a/target-i386/hyperv.c b/target-i386/hyperv.c
new file mode 100644
index 000..b2e57ad
--- /dev/null
+++ b/target-i386/hyperv.c
@@ -0,0 +1,65 @@
+/*
+ * QEMU Hyper-V support
+ *
+ * Copyright Red Hat, Inc. 2011
+ *
+ * Author: Vadim Rozenfeld
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#include "hyperv.h"
+
+static bool hyperv_vapic;
+static bool hyperv_relaxed_timing;
+static int hyperv_spinlock_attempts = HYPERV_SPINLOCK_NEVER_RETRY;
+
+void hyperv_enable_vapic_recommended(bool val)
+{
+hyperv_vapic = val;
+}
+
+void hyperv_enable_relaxed_timing(bool val)
+{
+hyperv_relaxed_timing = val;
+}
+
+void hyperv_set_spinlock_retries(int val)
+{
+hyperv_spinlock_attempts = val;
+if (hyperv_spinlock_attempts < 0xFFF) {
+hyperv_spinlock_attempts = 0xFFF;
+}
+}
+
+bool hyperv_enabled(void)
+{
+return hyperv_hypercall_available() || hyperv_relaxed_timing_enabled();
+}
+
+bool hyperv_hypercall_available(void)
+{
+if (hyperv_vapic ||
+(hyperv_spinlock_attempts != HYPERV_SPINLOCK_NEVER_RETRY)) {
+ return true;
+}
+return false;
+}
+
+bool hyperv_vapic_recommended(void)
+{
+return hyperv_vapic;
+}
+
+bool hyperv_relaxed_timing_enabled(void)
+{
+return hyperv_relaxed_timing;
+}
+
+int hyperv_get_spinlock_retries(void)
+{
+return hyperv_spinlock_attempts;
+}
+
diff --git a/target-i386/hyperv.h b/target-i386/hyperv.h
new file mode 100644
index 000..0d742f8
--- /dev/null
+++ b/target-i386/hyperv.h
@@ -0,0 +1,37 @@
+/*
+ * QEMU Hyper-V support
+ *
+ * Copyright Red Hat, Inc. 2011
+ *
+ * Author: Vadim Rozenfeld
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#ifndef QEMU_HW_HYPERV_H
+#define QEMU_HW_HYPERV_H 1
+
+#include "qemu-common.h"
+#include
+
+#ifndef HYPERV_SPINLOCK_NEVER_RETRY
+#define HYPERV_SPINLOCK_NEVER_RETRY 0x
+#endif
+
+#ifndef KVM_CPUID_SIGNATURE_NEXT
+#define KVM_CPUID_SIGNATURE_NEXT0x4100
+#endif
+
+void hyperv_enable_vapic_recommended(bool val);
+void hyperv_enable_relaxed_timing(bool val);
+void hyperv_set_spinlock_retries(int val);
+
+bool hyperv_enabled(void);
+bool hyperv_hypercall_available(void);
+bool hyperv_vapic_recommende
[PATCH RFC v3 2/2] hyper-v: initialize Hyper-V CPUID leaves.
---
target-i386/kvm.c | 65 +++-
1 files changed, 63 insertions(+), 2 deletions(-)
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 9080996..731cc8d 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -29,6 +29,7 @@
#include "hw/pc.h"
#include "hw/apic.h"
#include "ioport.h"
+#include "hyperv.h"
//#define DEBUG_KVM
@@ -381,11 +382,16 @@ int kvm_arch_init_vcpu(CPUState *env)
cpuid_i = 0;
/* Paravirtualization CPUIDs */
-memcpy(signature, "KVMKVMKVM\0\0\0", 12);
c = &cpuid_data.entries[cpuid_i++];
memset(c, 0, sizeof(*c));
c->function = KVM_CPUID_SIGNATURE;
-c->eax = 0;
+if (!hyperv_enabled()) {
+memcpy(signature, "KVMKVMKVM\0\0\0", 12);
+c->eax = 0;
+} else {
+memcpy(signature, "Microsoft Hv", 12);
+c->eax = HYPERV_CPUID_MIN;
+}
c->ebx = signature[0];
c->ecx = signature[1];
c->edx = signature[2];
@@ -396,6 +402,54 @@ int kvm_arch_init_vcpu(CPUState *env)
c->eax = env->cpuid_kvm_features &
kvm_arch_get_supported_cpuid(s, KVM_CPUID_FEATURES, 0, R_EAX);
+if (hyperv_enabled()) {
+memcpy(signature, "Hv#1\0\0\0\0\0\0\0\0", 12);
+c->eax = signature[0];
+
+c = &cpuid_data.entries[cpuid_i++];
+memset(c, 0, sizeof(*c));
+c->function = HYPERV_CPUID_VERSION;
+c->eax = 0x1bbc;
+c->ebx = 0x00060001;
+
+c = &cpuid_data.entries[cpuid_i++];
+memset(c, 0, sizeof(*c));
+c->function = HYPERV_CPUID_FEATURES;
+if (hyperv_relaxed_timing_enabled()) {
+c->eax |= HV_X64_MSR_HYPERCALL_AVAILABLE;
+}
+if (hyperv_vapic_recommended()) {
+c->eax |= HV_X64_MSR_HYPERCALL_AVAILABLE;
+c->eax |= HV_X64_MSR_APIC_ACCESS_AVAILABLE;
+}
+
+c = &cpuid_data.entries[cpuid_i++];
+memset(c, 0, sizeof(*c));
+c->function = HYPERV_CPUID_ENLIGHTMENT_INFO;
+if (hyperv_relaxed_timing_enabled()) {
+c->eax |= HV_X64_RELAXED_TIMING_RECOMMENDED;
+}
+if (hyperv_vapic_recommended()) {
+c->eax |= HV_X64_APIC_ACCESS_RECOMMENDED;
+}
+c->ebx = hyperv_get_spinlock_retries();
+
+c = &cpuid_data.entries[cpuid_i++];
+memset(c, 0, sizeof(*c));
+c->function = HYPERV_CPUID_IMPLEMENT_LIMITS;
+c->eax = 0x40;
+c->ebx = 0x40;
+
+c = &cpuid_data.entries[cpuid_i++];
+memset(c, 0, sizeof(*c));
+c->function = KVM_CPUID_SIGNATURE_NEXT;
+memcpy(signature, "KVMKVMKVM\0\0\0", 12);
+c->eax = 0;
+c->ebx = signature[0];
+c->ecx = signature[1];
+c->edx = signature[2];
+}
+
has_msr_async_pf_en = c->eax & (1 << KVM_FEATURE_ASYNC_PF);
cpu_x86_cpuid(env, 0, 0, &limit, &unused, &unused, &unused);
@@ -962,6 +1016,13 @@ static int kvm_put_msrs(CPUState *env, int level)
kvm_msr_entry_set(&msrs[n++], MSR_KVM_ASYNC_PF_EN,
env->async_pf_en_msr);
}
+if (hyperv_hypercall_available()) {
+kvm_msr_entry_set(&msrs[n++], HV_X64_MSR_GUEST_OS_ID, 0);
+kvm_msr_entry_set(&msrs[n++], HV_X64_MSR_HYPERCALL, 0);
+}
+if (hyperv_vapic_recommended()) {
+kvm_msr_entry_set(&msrs[n++], HV_X64_MSR_APIC_ASSIST_PAGE, 0);
+}
}
if (env->mcg_cap) {
int i;
--
1.7.4.4
--
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 call agenda for Tuesday 3
On Tue, 2012-01-03 at 13:12 +, Stefan Hajnoczi wrote: > On Tue, Jan 3, 2012 at 12:15 PM, Dor Laor wrote: > > On 01/03/2012 10:33 AM, Stefan Hajnoczi wrote: > >> > >> On Mon, Jan 02, 2012 at 01:09:40PM +0100, Juan Quintela wrote: > >>> > >>> Please send in any agenda items you are interested in covering. > >> > >> > >> Status of virtio drivers for Windows: > >> * Unsupported in community today > > > > > > Why? > > Because there is no one around to answer questions or look into bugs > in a timely manner. > > I'm not saying that virtio Windows drivers are unsupported, I'm saying > that the _QEMU community_ isn't supporting them if you look at the > mailing list and bug tracker activity. Perhaps we should direct > questions about the virtio drivers to some place? I've already been > CCing and bouncing questions from users to Vadim for several months. > > >> * Bugs languish on bug tracker/mailing list > > > > > > There are 1.2 developers on them and Vadim does the enlightenment support > > for kvm too. I don't see plenty of issues that are currently actively, open, > > can you point us to such? > > Yes, this is exactly the point. Vadim is doing a great job but he's > only 1 person. Having 1.2 people that handle virtio Windows driver > means the bus factor is dangerous and we cannot scale. > > The bug that brought this to mind again: > https://bugs.launchpad.net/qemu/+bug/818673 > > Another email thread on virtio-balloon driver issues (looks unsolved): > http://lists.gnu.org/archive/html/qemu-devel/2011-10/msg01240.html > > > There is a legal issue w/ WHQL drivers but self sign is not a probably and I > > believe that's what we have today. > > For a user anything other than first-class native drivers is a red > flag that this software may work poorly - on modern Windows that means > properly signed drivers. > > Although signing might seem like a secondary issue I think it's what > actually has stopped us from growing a community around the virtio > Windows drivers. There are very few people who can help because a > development environment where you can only contribute patches but not > build the code fully takes the fun away. > > Basically I'm asking: is there a way we can do the virtio Windows > driver development more in public, in the community, so that we will > grow stronger in KVM Windows guest support? > More QA resources for WHQL testing against upstream QEMU and KVM, and different distributions, including Fedora, Ubuntu, etc. And one more Software Engineer/Software Engineer In Test who will be in touch with community. Cheers, Vadim. > How do we bootstrap this into more than 1.2 people who can hack on and > help with guest drivers? > > My suggestions are for those already involved to actively join IRC, > mailing list, and bug tracker so they can pass on their knowledge and > watch for questions. Also, if there are known bugs and TODOs then > please post them so folks with time and interest can help get them > fixed. > > Stefan -- 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] hyper-v. Fix broken build due to missing references. All credits go to Jan Kiszka, who reported and fixed this issue.
---
target-i386/hyperv.h |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/target-i386/hyperv.h b/target-i386/hyperv.h
index 0d742f8..15467bf 100644
--- a/target-i386/hyperv.h
+++ b/target-i386/hyperv.h
@@ -24,9 +24,15 @@
#define KVM_CPUID_SIGNATURE_NEXT0x4100
#endif
+#ifndef CONFIG_USER_ONLY
void hyperv_enable_vapic_recommended(bool val);
void hyperv_enable_relaxed_timing(bool val);
void hyperv_set_spinlock_retries(int val);
+#else
+static inline void hyperv_enable_vapic_recommended(bool val) { }
+static inline void hyperv_enable_relaxed_timing(bool val) { }
+static inline void hyperv_set_spinlock_retries(int val) { }
+#endif
bool hyperv_enabled(void);
bool hyperv_hypercall_available(void);
--
1.7.4.4
--
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
[RFC PATCH 0/7] Initial support for Microsoft Hyper-V
Enable some basic Hyper-V enlightenment functionalites, including relaxed timing, spinlock, and virtual APIC. Vadim Rozenfeld (7): [hyper-v] Add hyper-v parameters block. [hyper-v] add hyper-v placeholders. [hyper-v] make Hyper-V option configurable. [hyper-v] hyper-v parameters [hyper-v] hyper-v helper functions [hyper-v] parse hyper-v parameters. [hyper-v] init hyper-v cpuid leafs Makefile.target |1 + configure | 11 + hyperv.c | 63 + hyperv.h | 19 qemu-config.c | 19 qemu-config.h |1 + qemu-options.hx | 23 +++ target-i386/kvm.c | 53 +++- vl.c | 12 ++ 9 files changed, 201 insertions(+), 1 deletions(-) create mode 100644 hyperv.c create mode 100644 hyperv.h -- 1.7.4.4 -- 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
[RFC PATCH 1/7] [hyper-v] Add hyper-v parameters block.
---
qemu-options.hx | 23 +++
vl.c|2 ++
2 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/qemu-options.hx b/qemu-options.hx
index 3a13533..9f60059 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -2483,6 +2483,29 @@ DEF("kvm-shadow-memory", HAS_ARG,
QEMU_OPTION_kvm_shadow_memory,
"allocate MEGABYTES for kvm mmu shadowing\n",
QEMU_ARCH_I386)
+DEF("hyperv", HAS_ARG, QEMU_OPTION_hyperv,
+"-hyperv [vapic=on|off][,spinlock=retries][,wd=on|off]\n"
+"enable Hyper-V Enlightenment\n",
+QEMU_ARCH_ALL)
+STEXI
+@item -hyperv
+@findex -hyperv
+@item vapic=@var{vapic}
+@var{vapic} is "on" or "off" and allows for using virtual APIC.
+Default is "off".
+@findex vapic
+@item spinlock=@var{spinlock}
+@var{spinlock} is a recommended number of attempts to retry
+a spinlock failure befor notifying the hypervisor.
+Default is 0x (never to retry).
+@findex spinlock
+:@item wd=@var{wd}
+@var{wd} is "on" or "off" and recommends using relaxed timing.
+Default is "off"
+@findex wd
+Simulate Hyper-V Enlightenment. Disable by default.
+ETEXI
+
HXCOMM This is the last statement. Insert new options before this line!
STEXI
@end table
diff --git a/vl.c b/vl.c
index b0358e9..a6d1fc0 100644
--- a/vl.c
+++ b/vl.c
@@ -3185,6 +3185,8 @@ int main(int argc, char **argv, char **envp)
fclose(fp);
break;
}
+case QEMU_OPTION_hyperv:
+break;
default:
os_parse_cmd_args(popt->index, optarg);
}
--
1.7.4.4
--
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
[RFC PATCH 2/7] [hyper-v] add hyper-v placeholders.
--- hyperv.c |3 +++ hyperv.h | 10 ++ 2 files changed, 13 insertions(+), 0 deletions(-) create mode 100644 hyperv.c create mode 100644 hyperv.h diff --git a/hyperv.c b/hyperv.c new file mode 100644 index 000..968ce89 --- /dev/null +++ b/hyperv.c @@ -0,0 +1,3 @@ +#include "hyperv.h" +#include "qemu-common.h" + diff --git a/hyperv.h b/hyperv.h new file mode 100644 index 000..a15ba90 --- /dev/null +++ b/hyperv.h @@ -0,0 +1,10 @@ +#ifndef QEMU_HW_HYPERV_H +#define QEMU_HW_HYPERV_H 1 +/* + * public hyper-v header + */ + +#include + +#endif /* QEMU_HW_HYPERV_H */ + -- 1.7.4.4 -- 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
[RFC PATCH 3/7] [hyper-v] make Hyper-V option configurable.
---
Makefile.target |1 +
configure | 11 +++
2 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/Makefile.target b/Makefile.target
index f84d8cb..3581480 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -199,6 +199,7 @@ obj-$(CONFIG_VHOST_NET) += vhost.o
obj-$(CONFIG_REALLY_VIRTFS) += 9pfs/virtio-9p-device.o
obj-$(CONFIG_KVM) += kvm.o kvm-all.o
obj-$(CONFIG_NO_KVM) += kvm-stub.o
+obj-$(CONFIG_HYPERV) += hyperv.o
obj-y += memory.o
LIBS+=-lz
diff --git a/configure b/configure
index 94c7d31..f5ecfd7 100755
--- a/configure
+++ b/configure
@@ -150,6 +150,7 @@ debug="no"
strip_opt="yes"
bigendian="no"
mingw32="no"
+hyperv="no"
EXESUF=""
prefix="/usr/local"
mandir="\${prefix}/share/man"
@@ -762,6 +763,10 @@ for opt do
;;
--enable-vhost-net) vhost_net="yes"
;;
+ --disable-hyperv) hyperv="no"
+ ;;
+ --enable-hyperv) hyperv="yes"
+ ;;
--disable-opengl) opengl="no"
;;
--enable-opengl) opengl="yes"
@@ -1062,6 +1067,8 @@ echo " --enable-docsenable documentation
build"
echo " --disable-docs disable documentation build"
echo " --disable-vhost-net disable vhost-net acceleration support"
echo " --enable-vhost-net enable vhost-net acceleration support"
+echo " --enable-hyperv enable Hyper-V support"
+echo " --disable-hyperv disable Hyper-V support"
echo " --enable-trace-backend=B Set trace backend"
echo " Available backends:"
$("$source_path"/scripts/tracetool --list-backends)
echo " --with-trace-file=NAME Full PATH,NAME of file to store traces"
@@ -2737,6 +2744,7 @@ echo "madvise $madvise"
echo "posix_madvise $posix_madvise"
echo "uuid support $uuid"
echo "vhost-net support $vhost_net"
+echo "Hyper-V support $hyperv"
echo "Trace backend $trace_backend"
echo "Trace output file $trace_file-"
echo "spice support $spice"
@@ -3424,6 +3432,9 @@ case "$target_arch2" in
if test $kvm_cap_device_assignment = "yes" ; then
echo "CONFIG_KVM_DEVICE_ASSIGNMENT=y" >> $config_target_mak
fi
+ if test "$hyperv" = "yes" ; then
+echo "CONFIG_HYPERV=y" >> $config_target_mak
+ fi
fi
esac
if test "$target_bigendian" = "yes" ; then
--
1.7.4.4
--
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
[RFC PATCH 4/7] [hyper-v] hyper-v parameters
---
hyperv.c | 16
hyperv.h |2 ++
qemu-config.c | 19 +++
qemu-config.h |1 +
4 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/hyperv.c b/hyperv.c
index 968ce89..a17f879 100644
--- a/hyperv.c
+++ b/hyperv.c
@@ -1,3 +1,19 @@
#include "hyperv.h"
#include "qemu-common.h"
+#include "qemu-option.h"
+#include "qemu-config.h"
+void hyperv_init(void)
+{
+QemuOpts *opts = QTAILQ_FIRST(&qemu_hyperv_opts.head);
+
+if (!opts) {
+return;
+}
+}
+
+static void hyperv_initialize(void)
+{
+hyperv_init();
+}
+device_init(hyperv_initialize);
diff --git a/hyperv.h b/hyperv.h
index a15ba90..eaf974a 100644
--- a/hyperv.h
+++ b/hyperv.h
@@ -6,5 +6,7 @@
#include
+void hyperv_init(void);
+
#endif /* QEMU_HW_HYPERV_H */
diff --git a/qemu-config.c b/qemu-config.c
index acab438..a1f9689 100644
--- a/qemu-config.c
+++ b/qemu-config.c
@@ -512,6 +512,24 @@ QemuOptsList qemu_boot_opts = {
},
};
+QemuOptsList qemu_hyperv_opts = {
+.name = "hyperv",
+.head = QTAILQ_HEAD_INITIALIZER(qemu_hyperv_opts.head),
+.desc = {
+{
+.name = "vapic",
+.type = QEMU_OPT_BOOL,
+}, {
+.name = "wd",
+.type = QEMU_OPT_BOOL,
+}, {
+.name = "spinlock",
+.type = QEMU_OPT_NUMBER,
+},
+{ /* end of list */ }
+},
+};
+
static QemuOptsList *vm_config_groups[32] = {
&qemu_drive_opts,
&qemu_chardev_opts,
@@ -526,6 +544,7 @@ static QemuOptsList *vm_config_groups[32] = {
&qemu_option_rom_opts,
&qemu_machine_opts,
&qemu_boot_opts,
+&qemu_hyperv_opts,
NULL,
};
diff --git a/qemu-config.h b/qemu-config.h
index 20d707f..c7d57d4 100644
--- a/qemu-config.h
+++ b/qemu-config.h
@@ -4,6 +4,7 @@
extern QemuOptsList qemu_fsdev_opts;
extern QemuOptsList qemu_virtfs_opts;
extern QemuOptsList qemu_spice_opts;
+extern QemuOptsList qemu_hyperv_opts;
QemuOptsList *qemu_find_opts(const char *group);
void qemu_add_opts(QemuOptsList *list);
--
1.7.4.4
--
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
[RFC PATCH 5/7] [hyper-v] hyper-v helper functions
---
hyperv.c | 44
hyperv.h |7 +++
2 files changed, 51 insertions(+), 0 deletions(-)
diff --git a/hyperv.c b/hyperv.c
index a17f879..57915b9 100644
--- a/hyperv.c
+++ b/hyperv.c
@@ -3,6 +3,10 @@
#include "qemu-option.h"
#include "qemu-config.h"
+static int hyperv_apic;
+static int hyperv_wd;
+static int hyperv_spinlock_attempts = HYPERV_SPINLOCK_NEVER_RETRY;
+
void hyperv_init(void)
{
QemuOpts *opts = QTAILQ_FIRST(&qemu_hyperv_opts.head);
@@ -10,6 +14,46 @@ void hyperv_init(void)
if (!opts) {
return;
}
+
+hyperv_spinlock_attempts = qemu_opt_get_number(opts, "spinlock",
+ HYPERV_SPINLOCK_NEVER_RETRY
+ );
+hyperv_wd = qemu_opt_get_bool(opts, "wd", 0);
+hyperv_apic = qemu_opt_get_bool(opts, "vapic", 0);
+
+}
+
+int hyperv_enabled(void)
+{
+return hyperv_hypercall_available() | hyperv_relaxed_timing();
+}
+
+int hyperv_hypercall_available(void)
+{
+if (hyperv_apic ||
+(hyperv_spinlock_attempts != HYPERV_SPINLOCK_NEVER_RETRY)) {
+ return 1;
+}
+return 0;
+}
+
+int hyperv_relaxed_timing(void)
+{
+return !hyperv_wd;
+}
+
+int hyperv_apic_recommended(void)
+{
+#ifdef KVM_CAP_IRQCHIP
+return hyperv_apic;
+#else
+return 0;
+#endif
+}
+
+int hyperv_spinlock_retries(void)
+{
+return hyperv_spinlock_attempts;
}
static void hyperv_initialize(void)
diff --git a/hyperv.h b/hyperv.h
index eaf974a..27d2e6e 100644
--- a/hyperv.h
+++ b/hyperv.h
@@ -6,7 +6,14 @@
#include
+#define HYPERV_SPINLOCK_NEVER_RETRY 0x
+
void hyperv_init(void);
+int hyperv_enabled(void);
+int hyperv_hypercall_available(void);
+int hyperv_relaxed_timing(void);
+int hyperv_apic_recommended(void);
+int hyperv_spinlock_retries(void);
#endif /* QEMU_HW_HYPERV_H */
--
1.7.4.4
--
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
[RFC PATCH 6/7] [hyper-v] parse hyper-v parameters.
---
vl.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/vl.c b/vl.c
index a6d1fc0..d9d4547 100644
--- a/vl.c
+++ b/vl.c
@@ -3186,6 +3186,16 @@ int main(int argc, char **argv, char **envp)
break;
}
case QEMU_OPTION_hyperv:
+olist = qemu_find_opts("hyperv");
+if (!olist) {
+fprintf(stderr, "Hyper-V is not supported by this qemu
build.\n");
+exit(1);
+}
+opts = qemu_opts_parse(olist, optarg, 0);
+if (!opts) {
+fprintf(stderr, "parse error: %s\n", optarg);
+exit(1);
+}
break;
default:
os_parse_cmd_args(popt->index, optarg);
--
1.7.4.4
--
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
[RFC PATCH 7/7] [hyper-v] init hyper-v cpuid leafs
---
target-i386/kvm.c | 53 -
1 files changed, 52 insertions(+), 1 deletions(-)
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 3840255..74fcc9a 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -29,6 +29,7 @@
#include "hw/pc.h"
#include "hw/apic.h"
#include "ioport.h"
+#include "hyperv.h"
//#define DEBUG_KVM
@@ -379,11 +380,21 @@ int kvm_arch_init_vcpu(CPUState *env)
cpuid_i = 0;
/* Paravirtualization CPUIDs */
-memcpy(signature, "KVMKVMKVM\0\0\0", 12);
c = &cpuid_data.entries[cpuid_i++];
memset(c, 0, sizeof(*c));
c->function = KVM_CPUID_SIGNATURE;
+#ifndef CONFIG_HYPERV
+memcpy(signature, "KVMKVMKVM\0\0\0", 12);
c->eax = 0;
+#else
+if (!hyperv_enabled()) {
+memcpy(signature, "KVMKVMKVM\0\0\0", 12);
+c->eax = 0;
+} else {
+memcpy(signature, "Microsoft Hv", 12);
+c->eax = HYPERV_CPUID_MIN;
+}
+#endif
c->ebx = signature[0];
c->ecx = signature[1];
c->edx = signature[2];
@@ -393,6 +404,46 @@ int kvm_arch_init_vcpu(CPUState *env)
c->function = KVM_CPUID_FEATURES;
c->eax = env->cpuid_kvm_features &
kvm_arch_get_supported_cpuid(s, KVM_CPUID_FEATURES, 0, R_EAX);
+#ifdef CONFIG_HYPERV
+if (hyperv_enabled()) {
+memcpy(signature, "Hv#1\0\0\0\0\0\0\0\0", 12);
+c->eax = signature[0];
+
+c = &cpuid_data.entries[cpuid_i++];
+memset(c, 0, sizeof(*c));
+c->function = HYPERV_CPUID_VERSION;
+c->eax = 0x1bbc;
+c->ebx = 0x00060001;
+
+c = &cpuid_data.entries[cpuid_i++];
+memset(c, 0, sizeof(*c));
+c->function = HYPERV_CPUID_FEATURES;
+if (hyperv_relaxed_timing()) {
+c->eax |= HV_X64_MSR_HYPERCALL_AVAILABLE;
+}
+if (hyperv_apic_recommended()) {
+c->eax |= HV_X64_MSR_HYPERCALL_AVAILABLE;
+c->eax |= HV_X64_MSR_APIC_ACCESS_AVAILABLE;
+}
+
+c = &cpuid_data.entries[cpuid_i++];
+memset(c, 0, sizeof(*c));
+c->function = HYPERV_CPUID_ENLIGHTMENT_INFO;
+if (hyperv_relaxed_timing()) {
+c->eax |= HV_X64_RELAXED_TIMING_RECOMMENDED;
+}
+if (hyperv_apic_recommended()) {
+c->eax |= HV_X64_APIC_ACCESS_RECOMMENDED;
+}
+c->ebx = hyperv_spinlock_retries();
+
+c = &cpuid_data.entries[cpuid_i++];
+memset(c, 0, sizeof(*c));
+c->function = HYPERV_CPUID_IMPLEMENT_LIMITS;
+c->eax = 0x40;
+c->ebx = 0x40;
+}
+#endif
has_msr_async_pf_en = c->eax & (1 << KVM_FEATURE_ASYNC_PF);
--
1.7.4.4
--
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: [RFC PATCH 5/7] [hyper-v] hyper-v helper functions
On Sun, 2011-10-09 at 21:01 +0200, Alon Levy wrote:
> On Sun, Oct 09, 2011 at 08:52:53PM +0200, Vadim Rozenfeld wrote:
> > ---
> > hyperv.c | 44
> > hyperv.h |7 +++
> > 2 files changed, 51 insertions(+), 0 deletions(-)
> >
> > diff --git a/hyperv.c b/hyperv.c
> > index a17f879..57915b9 100644
> > --- a/hyperv.c
> > +++ b/hyperv.c
> > @@ -3,6 +3,10 @@
> > #include "qemu-option.h"
> > #include "qemu-config.h"
> >
> > +static int hyperv_apic;
> > +static int hyperv_wd;
> > +static int hyperv_spinlock_attempts = HYPERV_SPINLOCK_NEVER_RETRY;
> > +
> > void hyperv_init(void)
> > {
> > QemuOpts *opts = QTAILQ_FIRST(&qemu_hyperv_opts.head);
> > @@ -10,6 +14,46 @@ void hyperv_init(void)
> > if (!opts) {
> > return;
> > }
> > +
> > +hyperv_spinlock_attempts = qemu_opt_get_number(opts, "spinlock",
> > +
> > HYPERV_SPINLOCK_NEVER_RETRY
> > + );
> > +hyperv_wd = qemu_opt_get_bool(opts, "wd", 0);
> > +hyperv_apic = qemu_opt_get_bool(opts, "vapic", 0);
> > +
> > +}
> > +
> > +int hyperv_enabled(void)
> > +{
> > +return hyperv_hypercall_available() | hyperv_relaxed_timing();
> Shouldn't this be a logical or?
Sure, thanks.
>
> > +}
> > +
> > +int hyperv_hypercall_available(void)
> > +{
> > +if (hyperv_apic ||
> > +(hyperv_spinlock_attempts != HYPERV_SPINLOCK_NEVER_RETRY)) {
> > + return 1;
> > +}
> > +return 0;
> > +}
> > +
> > +int hyperv_relaxed_timing(void)
> > +{
> > +return !hyperv_wd;
> > +}
> > +
> > +int hyperv_apic_recommended(void)
> > +{
> > +#ifdef KVM_CAP_IRQCHIP
> > +return hyperv_apic;
> > +#else
> > +return 0;
> > +#endif
> > +}
> > +
> > +int hyperv_spinlock_retries(void)
> > +{
> > +return hyperv_spinlock_attempts;
> > }
> >
> > static void hyperv_initialize(void)
> > diff --git a/hyperv.h b/hyperv.h
> > index eaf974a..27d2e6e 100644
> > --- a/hyperv.h
> > +++ b/hyperv.h
> > @@ -6,7 +6,14 @@
> >
> > #include
> >
> > +#define HYPERV_SPINLOCK_NEVER_RETRY 0x
> > +
> > void hyperv_init(void);
> > +int hyperv_enabled(void);
> > +int hyperv_hypercall_available(void);
> > +int hyperv_relaxed_timing(void);
> > +int hyperv_apic_recommended(void);
> > +int hyperv_spinlock_retries(void);
> >
> > #endif /* QEMU_HW_HYPERV_H */
> >
> > --
> > 1.7.4.4
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe kvm" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/7] Initial support for Microsoft Hyper-V
On Mon, 2011-10-10 at 08:53 +0200, Jan Kiszka wrote: > On 2011-10-09 20:52, Vadim Rozenfeld wrote: > > Enable some basic Hyper-V enlightenment functionalites, > > including relaxed timing, spinlock, and virtual APIC. > > This targets uq/master, correct? Then you should CC qemu-devel on the > next round. > > I think this series could also be distributed over 3 or 4 patches > without loosing bisectability. And please spend a bit time on commit logs. > OK. > Jan > -- 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: [RFC PATCH 1/7] [hyper-v] Add hyper-v parameters block.
On Mon, 2011-10-10 at 08:54 +0200, Jan Kiszka wrote:
> On 2011-10-09 20:52, Vadim Rozenfeld wrote:
> > ---
> > qemu-options.hx | 23 +++
> > vl.c|2 ++
> > 2 files changed, 25 insertions(+), 0 deletions(-)
> >
> > diff --git a/qemu-options.hx b/qemu-options.hx
> > index 3a13533..9f60059 100644
> > --- a/qemu-options.hx
> > +++ b/qemu-options.hx
> > @@ -2483,6 +2483,29 @@ DEF("kvm-shadow-memory", HAS_ARG,
> > QEMU_OPTION_kvm_shadow_memory,
> > "allocate MEGABYTES for kvm mmu shadowing\n",
> > QEMU_ARCH_I386)
> >
> > +DEF("hyperv", HAS_ARG, QEMU_OPTION_hyperv,
> > +"-hyperv [vapic=on|off][,spinlock=retries][,wd=on|off]\n"
> > +"enable Hyper-V Enlightenment\n",
> > +QEMU_ARCH_ALL)
>
> These are CPU feature, so -cpu +/-hv_vapic,+/-hv_spinlock etc. looks
> more appropriate than a new command line parameter.
>
I would like to keep hyper-v settings apart from cpu features for a very
simple reason: if hyper-v VMBus support will be added one day, it won't
be a CPU only feature anymore.
> BTW, documentation and maybe also option processing should make clear
> that this is limited to KVM mode for now.
>
Will add it.
Vadim
> Jan
>
--
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: [RFC PATCH 7/7] [hyper-v] init hyper-v cpuid leafs
On Tue, 2011-10-11 at 09:38 +0200, Paolo Bonzini wrote:
> On 10/09/2011 08:52 PM, Vadim Rozenfeld wrote:
> > ---
> > target-i386/kvm.c | 53
> > -
> > 1 files changed, 52 insertions(+), 1 deletions(-)
> >
> > diff --git a/target-i386/kvm.c b/target-i386/kvm.c
> > index 3840255..74fcc9a 100644
> > --- a/target-i386/kvm.c
> > +++ b/target-i386/kvm.c
> > @@ -29,6 +29,7 @@
> > #include "hw/pc.h"
> > #include "hw/apic.h"
> > #include "ioport.h"
> > +#include "hyperv.h"
> >
> > //#define DEBUG_KVM
> >
> > @@ -379,11 +380,21 @@ int kvm_arch_init_vcpu(CPUState *env)
> > cpuid_i = 0;
> >
> > /* Paravirtualization CPUIDs */
> > -memcpy(signature, "KVMKVMKVM\0\0\0", 12);
>
> These should not be KVM-specific. You should be able to add
> enlightenments to a TCG VM. At the same time, the KVM leaves could be
> moved to 0x4100 when enlightenments are active, similar to what Xen
> does.
>
IMO, adding Hyper-V features without KVM support has little, if any,
meaning. Relaxed timing is the only one thing, which can be activated
without help from hypervisor.
> Paolo
>
> > c =&cpuid_data.entries[cpuid_i++];
> > memset(c, 0, sizeof(*c));
> > c->function = KVM_CPUID_SIGNATURE;
> > +#ifndef CONFIG_HYPERV
> > +memcpy(signature, "KVMKVMKVM\0\0\0", 12);
> > c->eax = 0;
> > +#else
> > +if (!hyperv_enabled()) {
> > +memcpy(signature, "KVMKVMKVM\0\0\0", 12);
> > +c->eax = 0;
> > +} else {
> > +memcpy(signature, "Microsoft Hv", 12);
> > +c->eax = HYPERV_CPUID_MIN;
> > +}
> > +#endif
> > c->ebx = signature[0];
> > c->ecx = signature[1];
> > c->edx = signature[2];
> > @@ -393,6 +404,46 @@ int kvm_arch_init_vcpu(CPUState *env)
> > c->function = KVM_CPUID_FEATURES;
> > c->eax = env->cpuid_kvm_features&
> > kvm_arch_get_supported_cpuid(s, KVM_CPUID_FEATURES, 0, R_EAX);
> > +#ifdef CONFIG_HYPERV
> > +if (hyperv_enabled()) {
> > +memcpy(signature, "Hv#1\0\0\0\0\0\0\0\0", 12);
> > +c->eax = signature[0];
> > +
> > +c =&cpuid_data.entries[cpuid_i++];
> > +memset(c, 0, sizeof(*c));
> > +c->function = HYPERV_CPUID_VERSION;
> > +c->eax = 0x1bbc;
> > +c->ebx = 0x00060001;
> > +
> > +c =&cpuid_data.entries[cpuid_i++];
> > +memset(c, 0, sizeof(*c));
> > +c->function = HYPERV_CPUID_FEATURES;
> > +if (hyperv_relaxed_timing()) {
> > +c->eax |= HV_X64_MSR_HYPERCALL_AVAILABLE;
> > +}
> > +if (hyperv_apic_recommended()) {
> > +c->eax |= HV_X64_MSR_HYPERCALL_AVAILABLE;
> > +c->eax |= HV_X64_MSR_APIC_ACCESS_AVAILABLE;
> > +}
> > +
> > +c =&cpuid_data.entries[cpuid_i++];
> > +memset(c, 0, sizeof(*c));
> > +c->function = HYPERV_CPUID_ENLIGHTMENT_INFO;
> > +if (hyperv_relaxed_timing()) {
> > +c->eax |= HV_X64_RELAXED_TIMING_RECOMMENDED;
> > +}
> > +if (hyperv_apic_recommended()) {
> > +c->eax |= HV_X64_APIC_ACCESS_RECOMMENDED;
> > +}
> > +c->ebx = hyperv_spinlock_retries();
> > +
> > +c =&cpuid_data.entries[cpuid_i++];
> > +memset(c, 0, sizeof(*c));
> > +c->function = HYPERV_CPUID_IMPLEMENT_LIMITS;
> > +c->eax = 0x40;
> > +c->ebx = 0x40;
> > +}
> > +#endif
> >
> > has_msr_async_pf_en = c->eax& (1<< KVM_FEATURE_ASYNC_PF);
> >
>
> --
> 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: [RFC PATCH 7/7] [hyper-v] init hyper-v cpuid leafs
On Tue, 2011-10-11 at 17:52 +0200, Paolo Bonzini wrote: > On 10/11/2011 03:46 PM, Vadim Rozenfeld wrote: > > > These should not be KVM-specific. You should be able to add > > > enlightenments to a TCG VM. At the same time, the KVM leaves could be > > > moved to 0x4100 when enlightenments are active, similar to what Xen > > > does. > > > > > > > IMO, adding Hyper-V features without KVM support has little, if any, > > meaning. Relaxed timing is the only one thing, which can be activated > > without help from hypervisor. > > Spinlocks too. TCG does its own round-robin scheduling, so having zero How? You need hypercall page for it. Best, Vadim. > retries could be the best setting. But even if it is not useful for > TCG, there's nothing KVM-specific, and that's the important point. > > Paolo -- 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 RFC v1 0/2] Initial support for Microsoft Hyper-V.
With the following series of patches we are starting to implement some basic Microsoft Hyper-V Enlightenment functionality. This series is mostly about adding support for relaxed timing, spinlock, and virtual apic. For more Hyper-V related information please see: "Hypervisor Functional Specification v2.0: For Windows Server 2008 R2" at http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=18673 Changelog: v0->v1 - move hyper-v parameters under cpu category, - move hyper-v stuff to target-i386 directory, - make CONFIG_HYPERV enabled by default for i386-softmmu and x86_64-softmmu configurations, - rearrange the patches from v0, - set HV_X64_MSR_HYPERCALL, HV_X64_MSR_GUEST_OS_ID, and HV_X64_MSR_APIC_ASSIST_PAGE to 0 on system reset. Vadim Rozenfeld (2): hyper-v: introduce Hyper-V support infrastructure. hyper-v: initialize Hyper-V CPUID leafs. Makefile.target|2 + default-configs/i386-softmmu.mak |1 + default-configs/x86_64-softmmu.mak |1 + target-i386/cpuid.c| 14 +++ target-i386/hyperv.c | 69 target-i386/hyperv.h | 30 +++ target-i386/kvm.c | 64 - 7 files changed, 179 insertions(+), 2 deletions(-) create mode 100644 target-i386/hyperv.c create mode 100644 target-i386/hyperv.h -- 1.7.4.4 -- 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 RFC v1 2/2] hyper-v: initialize Hyper-V CPUID leafs.
---
target-i386/kvm.c | 64 +++-
1 files changed, 62 insertions(+), 2 deletions(-)
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 3840255..30b3e85 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -29,6 +29,7 @@
#include "hw/pc.h"
#include "hw/apic.h"
#include "ioport.h"
+#include "hyperv.h"
//#define DEBUG_KVM
@@ -379,11 +380,16 @@ int kvm_arch_init_vcpu(CPUState *env)
cpuid_i = 0;
/* Paravirtualization CPUIDs */
-memcpy(signature, "KVMKVMKVM\0\0\0", 12);
c = &cpuid_data.entries[cpuid_i++];
memset(c, 0, sizeof(*c));
c->function = KVM_CPUID_SIGNATURE;
-c->eax = 0;
+if (!hyperv_enabled()) {
+memcpy(signature, "KVMKVMKVM\0\0\0", 12);
+c->eax = 0;
+} else {
+memcpy(signature, "Microsoft Hv", 12);
+c->eax = HYPERV_CPUID_MIN;
+}
c->ebx = signature[0];
c->ecx = signature[1];
c->edx = signature[2];
@@ -394,6 +400,45 @@ int kvm_arch_init_vcpu(CPUState *env)
c->eax = env->cpuid_kvm_features &
kvm_arch_get_supported_cpuid(s, KVM_CPUID_FEATURES, 0, R_EAX);
+if (hyperv_enabled()) {
+memcpy(signature, "Hv#1\0\0\0\0\0\0\0\0", 12);
+c->eax = signature[0];
+
+c = &cpuid_data.entries[cpuid_i++];
+memset(c, 0, sizeof(*c));
+c->function = HYPERV_CPUID_VERSION;
+c->eax = 0x1bbc;
+c->ebx = 0x00060001;
+
+c = &cpuid_data.entries[cpuid_i++];
+memset(c, 0, sizeof(*c));
+c->function = HYPERV_CPUID_FEATURES;
+if (hyperv_get_relaxed_timing()) {
+c->eax |= HV_X64_MSR_HYPERCALL_AVAILABLE;
+}
+if (hyperv_get_vapic_recommended()) {
+c->eax |= HV_X64_MSR_HYPERCALL_AVAILABLE;
+c->eax |= HV_X64_MSR_APIC_ACCESS_AVAILABLE;
+}
+
+c = &cpuid_data.entries[cpuid_i++];
+memset(c, 0, sizeof(*c));
+c->function = HYPERV_CPUID_ENLIGHTMENT_INFO;
+if (hyperv_get_relaxed_timing()) {
+c->eax |= HV_X64_RELAXED_TIMING_RECOMMENDED;
+}
+if (hyperv_get_vapic_recommended()) {
+c->eax |= HV_X64_APIC_ACCESS_RECOMMENDED;
+}
+c->ebx = hyperv_get_spinlock_retries();
+
+c = &cpuid_data.entries[cpuid_i++];
+memset(c, 0, sizeof(*c));
+c->function = HYPERV_CPUID_IMPLEMENT_LIMITS;
+c->eax = 0x40;
+c->ebx = 0x40;
+}
+
has_msr_async_pf_en = c->eax & (1 << KVM_FEATURE_ASYNC_PF);
cpu_x86_cpuid(env, 0, 0, &limit, &unused, &unused, &unused);
@@ -945,6 +990,13 @@ static int kvm_put_msrs(CPUState *env, int level)
kvm_msr_entry_set(&msrs[n++], MSR_KVM_ASYNC_PF_EN,
env->async_pf_en_msr);
}
+if (hyperv_hypercall_available()) {
+kvm_msr_entry_set(&msrs[n++], HV_X64_MSR_GUEST_OS_ID, 0);
+kvm_msr_entry_set(&msrs[n++], HV_X64_MSR_HYPERCALL, 0);
+}
+if (hyperv_get_vapic_recommended()) {
+kvm_msr_entry_set(&msrs[n++], HV_X64_MSR_APIC_ASSIST_PAGE, 0);
+}
}
if (env->mcg_cap) {
int i;
@@ -1179,6 +1231,14 @@ static int kvm_get_msrs(CPUState *env)
msrs[n++].index = MSR_KVM_ASYNC_PF_EN;
}
+if (hyperv_hypercall_available()) {
+msrs[n++].index = HV_X64_MSR_GUEST_OS_ID;
+msrs[n++].index = HV_X64_MSR_HYPERCALL;
+}
+if (hyperv_get_vapic_recommended()) {
+msrs[n++].index = HV_X64_MSR_APIC_ASSIST_PAGE;
+}
+
if (env->mcg_cap) {
msrs[n++].index = MSR_MCG_STATUS;
msrs[n++].index = MSR_MCG_CTL;
--
1.7.4.4
--
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 RFC v1 1/2] hyper-v: introduce Hyper-V support infrastructure.
with the following series of patches we are starting to implement
some basic Microsoft Hyper-V Enlightenment functionality, like relaxed
timing, spinlock, and virtual apic support.
For more Hyper-V related information please see:
"Hypervisor Functional Specification v2.0: For Windows Server 2008 R2" at
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=18673
---
Makefile.target|2 +
default-configs/i386-softmmu.mak |1 +
default-configs/x86_64-softmmu.mak |1 +
target-i386/cpuid.c| 14 +++
target-i386/hyperv.c | 69
target-i386/hyperv.h | 30 +++
6 files changed, 117 insertions(+), 0 deletions(-)
create mode 100644 target-i386/hyperv.c
create mode 100644 target-i386/hyperv.h
diff --git a/Makefile.target b/Makefile.target
index 40cc592..2c8e1b8 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -202,6 +202,8 @@ obj-$(CONFIG_NO_KVM) += kvm-stub.o
obj-y += memory.o
LIBS+=-lz
+obj-$(CONFIG_HYPERV) += hyperv.o
+
QEMU_CFLAGS += $(VNC_TLS_CFLAGS)
QEMU_CFLAGS += $(VNC_SASL_CFLAGS)
QEMU_CFLAGS += $(VNC_JPEG_CFLAGS)
diff --git a/default-configs/i386-softmmu.mak b/default-configs/i386-softmmu.mak
index 55589fa..ee69a0a 100644
--- a/default-configs/i386-softmmu.mak
+++ b/default-configs/i386-softmmu.mak
@@ -21,3 +21,4 @@ CONFIG_PIIX_PCI=y
CONFIG_SOUND=y
CONFIG_HPET=y
CONFIG_APPLESMC=y
+CONFIG_HYPERV=y
diff --git a/default-configs/x86_64-softmmu.mak
b/default-configs/x86_64-softmmu.mak
index 8895028..35b1c00 100644
--- a/default-configs/x86_64-softmmu.mak
+++ b/default-configs/x86_64-softmmu.mak
@@ -21,3 +21,4 @@ CONFIG_PIIX_PCI=y
CONFIG_SOUND=y
CONFIG_HPET=y
CONFIG_APPLESMC=y
+CONFIG_HYPERV=y
diff --git a/target-i386/cpuid.c b/target-i386/cpuid.c
index 1e8bcff..50b2d0e 100644
--- a/target-i386/cpuid.c
+++ b/target-i386/cpuid.c
@@ -27,6 +27,8 @@
#include "qemu-option.h"
#include "qemu-config.h"
+#include "hyperv.h"
+
/* feature flags taken from "Intel Processor Identification and the CPUID
* Instruction" and AMD's "CPUID Specification". In cases of disagreement
* between feature naming conventions, aliases may be added.
@@ -716,6 +718,14 @@ static int cpu_x86_find_by_name(x86_def_t *x86_cpu_def,
const char *cpu_model)
goto error;
}
x86_cpu_def->tsc_khz = tsc_freq / 1000;
+} else if (!strcmp(featurestr, "hv_spinlocks")) {
+ char* err;
+ numvalue = strtoul(val, &err, 0);
+ if (!*val || *err) {
+fprintf(stderr, "bad numerical value %s\n", val);
+goto error;
+}
+hyperv_set_spinlock_retries(numvalue);
} else {
fprintf(stderr, "unrecognized feature %s\n", featurestr);
goto error;
@@ -724,6 +734,10 @@ static int cpu_x86_find_by_name(x86_def_t *x86_cpu_def,
const char *cpu_model)
check_cpuid = 1;
} else if (!strcmp(featurestr, "enforce")) {
check_cpuid = enforce_cpuid = 1;
+} else if (!strcmp(featurestr, "hv_relaxed")) {
+hyperv_set_relaxed_timing(1);
+} else if (!strcmp(featurestr, "hv_vapic")) {
+hyperv_set_vapic_recommended(1);
} else {
fprintf(stderr, "feature string `%s' not in format
(+feature|-feature|feature=xyz)\n", featurestr);
goto error;
diff --git a/target-i386/hyperv.c b/target-i386/hyperv.c
new file mode 100644
index 000..bed859e
--- /dev/null
+++ b/target-i386/hyperv.c
@@ -0,0 +1,69 @@
+/*
+ * QEMU Hyper-V support
+ *
+ * Copyright Red Hat, Inc. 2011
+ *
+ * Author: Vadim Rozenfeld
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#include "hyperv.h"
+
+static int hyperv_vapic;
+static int hyperv_relaxed_timing;
+static int hyperv_spinlock_attempts = HYPERV_SPINLOCK_NEVER_RETRY;
+
+void hyperv_set_vapic_recommended(int val)
+{
+hyperv_vapic = val;
+}
+
+void hyperv_set_relaxed_timing(int val)
+{
+hyperv_relaxed_timing = val;
+}
+
+void hyperv_set_spinlock_retries(int val)
+{
+hyperv_spinlock_attempts = val;
+if (hyperv_spinlock_attempts < 0xFFF) {
+hyperv_spinlock_attempts = 0xFFF;
+}
+}
+
+int hyperv_enabled(void)
+{
+return hyperv_hypercall_available() || hyperv_get_relaxed_timing();
+}
+
+int hyperv_hypercall_available(void)
+{
+if (hyperv_vapic ||
+(hyperv_spinlock_attempts != HYPERV_SPINLOCK_NEVER_RETRY)) {
+ return 1;
+}
+return 0;
+}
+
+int hyperv_get_vapic_recommended(void)
+{
+#ifdef KVM_CAP_IRQCHIP
+return hyperv_vapic;
+#el
[PATCH RFC v2 0/2] Initial support for Microsoft Hyper-V.
With the following series of patches we are starting to implement some basic Microsoft Hyper-V Enlightenment functionality. This series is mostly about adding support for relaxed timing, spinlock, and virtual apic. For more Hyper-V related information please see: "Hypervisor Functional Specification v2.0: For Windows Server 2008 R2" at http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=18673 Changelog: v2->v1 - remove KVM_CAP_IRQCHIP ifdef, - remove CONFIG_HYPERV config option, - move KVM leaves to new location (0x4100), - cosmetic changes. v0->v1 - move hyper-v parameters under cpu category, - move hyper-v stuff to target-i386 directory, - make CONFIG_HYPERV enabled by default for i386-softmmu and x86_64-softmmu configurations, - rearrange the patches from v0, - set HV_X64_MSR_HYPERCALL, HV_X64_MSR_GUEST_OS_ID, and HV_X64_MSR_APIC_ASSIST_PAGE to 0 on system reset. Vadim Rozenfeld (2): hyper-v: introduce Hyper-V support infrastructure. hyper-v: initialize Hyper-V CPUID leaves. Makefile.target |2 + target-i386/cpuid.c | 14 + target-i386/hyperv.c | 65 target-i386/hyperv.h | 37 + target-i386/kvm.c| 73 - 5 files changed, 189 insertions(+), 2 deletions(-) create mode 100644 target-i386/hyperv.c create mode 100644 target-i386/hyperv.h -- 1.7.4.4 -- 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 1/2] [PATCH RFC v2 1/2] hyper-v: introduce Hyper-V support infrastructure.
---
Makefile.target |2 +
target-i386/cpuid.c | 14 ++
target-i386/hyperv.c | 65 ++
target-i386/hyperv.h | 37
4 files changed, 118 insertions(+), 0 deletions(-)
create mode 100644 target-i386/hyperv.c
create mode 100644 target-i386/hyperv.h
diff --git a/Makefile.target b/Makefile.target
index 325f26e..446fabc 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -202,6 +202,8 @@ obj-$(CONFIG_NO_KVM) += kvm-stub.o
obj-y += memory.o
LIBS+=-lz
+obj-i386-y +=hyperv.o
+
QEMU_CFLAGS += $(VNC_TLS_CFLAGS)
QEMU_CFLAGS += $(VNC_SASL_CFLAGS)
QEMU_CFLAGS += $(VNC_JPEG_CFLAGS)
diff --git a/target-i386/cpuid.c b/target-i386/cpuid.c
index 1e8bcff..261c168 100644
--- a/target-i386/cpuid.c
+++ b/target-i386/cpuid.c
@@ -27,6 +27,8 @@
#include "qemu-option.h"
#include "qemu-config.h"
+#include "hyperv.h"
+
/* feature flags taken from "Intel Processor Identification and the CPUID
* Instruction" and AMD's "CPUID Specification". In cases of disagreement
* between feature naming conventions, aliases may be added.
@@ -716,6 +718,14 @@ static int cpu_x86_find_by_name(x86_def_t *x86_cpu_def,
const char *cpu_model)
goto error;
}
x86_cpu_def->tsc_khz = tsc_freq / 1000;
+} else if (!strcmp(featurestr, "hv_spinlocks")) {
+ char *err;
+ numvalue = strtoul(val, &err, 0);
+ if (!*val || *err) {
+fprintf(stderr, "bad numerical value %s\n", val);
+goto error;
+}
+hyperv_set_spinlock_retries(numvalue);
} else {
fprintf(stderr, "unrecognized feature %s\n", featurestr);
goto error;
@@ -724,6 +734,10 @@ static int cpu_x86_find_by_name(x86_def_t *x86_cpu_def,
const char *cpu_model)
check_cpuid = 1;
} else if (!strcmp(featurestr, "enforce")) {
check_cpuid = enforce_cpuid = 1;
+} else if (!strcmp(featurestr, "hv_relaxed")) {
+hyperv_enable_relaxed_timing(true);
+} else if (!strcmp(featurestr, "hv_vapic")) {
+hyperv_enable_vapic_recommended(true);
} else {
fprintf(stderr, "feature string `%s' not in format
(+feature|-feature|feature=xyz)\n", featurestr);
goto error;
diff --git a/target-i386/hyperv.c b/target-i386/hyperv.c
new file mode 100644
index 000..b2e57ad
--- /dev/null
+++ b/target-i386/hyperv.c
@@ -0,0 +1,65 @@
+/*
+ * QEMU Hyper-V support
+ *
+ * Copyright Red Hat, Inc. 2011
+ *
+ * Author: Vadim Rozenfeld
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#include "hyperv.h"
+
+static bool hyperv_vapic;
+static bool hyperv_relaxed_timing;
+static int hyperv_spinlock_attempts = HYPERV_SPINLOCK_NEVER_RETRY;
+
+void hyperv_enable_vapic_recommended(bool val)
+{
+hyperv_vapic = val;
+}
+
+void hyperv_enable_relaxed_timing(bool val)
+{
+hyperv_relaxed_timing = val;
+}
+
+void hyperv_set_spinlock_retries(int val)
+{
+hyperv_spinlock_attempts = val;
+if (hyperv_spinlock_attempts < 0xFFF) {
+hyperv_spinlock_attempts = 0xFFF;
+}
+}
+
+bool hyperv_enabled(void)
+{
+return hyperv_hypercall_available() || hyperv_relaxed_timing_enabled();
+}
+
+bool hyperv_hypercall_available(void)
+{
+if (hyperv_vapic ||
+(hyperv_spinlock_attempts != HYPERV_SPINLOCK_NEVER_RETRY)) {
+ return true;
+}
+return false;
+}
+
+bool hyperv_vapic_recommended(void)
+{
+return hyperv_vapic;
+}
+
+bool hyperv_relaxed_timing_enabled(void)
+{
+return hyperv_relaxed_timing;
+}
+
+int hyperv_get_spinlock_retries(void)
+{
+return hyperv_spinlock_attempts;
+}
+
diff --git a/target-i386/hyperv.h b/target-i386/hyperv.h
new file mode 100644
index 000..0d742f8
--- /dev/null
+++ b/target-i386/hyperv.h
@@ -0,0 +1,37 @@
+/*
+ * QEMU Hyper-V support
+ *
+ * Copyright Red Hat, Inc. 2011
+ *
+ * Author: Vadim Rozenfeld
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#ifndef QEMU_HW_HYPERV_H
+#define QEMU_HW_HYPERV_H 1
+
+#include "qemu-common.h"
+#include
+
+#ifndef HYPERV_SPINLOCK_NEVER_RETRY
+#define HYPERV_SPINLOCK_NEVER_RETRY 0x
+#endif
+
+#ifndef KVM_CPUID_SIGNATURE_NEXT
+#define KVM_CPUID_SIGNATURE_NEXT0x4100
+#endif
+
+void hyperv_enable_vapic_recommended(bool val);
+void hyperv_enable_relaxed_timing(bool val);
+void hyperv_set_spinlock_retries(int val);
+
+bool hyperv_enabled(void);
+bool hyperv_hypercall_available(void);
+bool hyperv_vapic_recom
[PATCH 2/2] [PATCH RFC v2 2/2] hyper-v: initialize Hyper-V CPUID leaves.
---
target-i386/kvm.c | 73 +++-
1 files changed, 71 insertions(+), 2 deletions(-)
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 82fec8c..c061e3b 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -29,6 +29,7 @@
#include "hw/pc.h"
#include "hw/apic.h"
#include "ioport.h"
+#include "hyperv.h"
//#define DEBUG_KVM
@@ -380,11 +381,16 @@ int kvm_arch_init_vcpu(CPUState *env)
cpuid_i = 0;
/* Paravirtualization CPUIDs */
-memcpy(signature, "KVMKVMKVM\0\0\0", 12);
c = &cpuid_data.entries[cpuid_i++];
memset(c, 0, sizeof(*c));
c->function = KVM_CPUID_SIGNATURE;
-c->eax = 0;
+if (!hyperv_enabled()) {
+memcpy(signature, "KVMKVMKVM\0\0\0", 12);
+c->eax = 0;
+} else {
+memcpy(signature, "Microsoft Hv", 12);
+c->eax = HYPERV_CPUID_MIN;
+}
c->ebx = signature[0];
c->ecx = signature[1];
c->edx = signature[2];
@@ -395,6 +401,54 @@ int kvm_arch_init_vcpu(CPUState *env)
c->eax = env->cpuid_kvm_features &
kvm_arch_get_supported_cpuid(s, KVM_CPUID_FEATURES, 0, R_EAX);
+if (hyperv_enabled()) {
+memcpy(signature, "Hv#1\0\0\0\0\0\0\0\0", 12);
+c->eax = signature[0];
+
+c = &cpuid_data.entries[cpuid_i++];
+memset(c, 0, sizeof(*c));
+c->function = HYPERV_CPUID_VERSION;
+c->eax = 0x1bbc;
+c->ebx = 0x00060001;
+
+c = &cpuid_data.entries[cpuid_i++];
+memset(c, 0, sizeof(*c));
+c->function = HYPERV_CPUID_FEATURES;
+if (hyperv_relaxed_timing_enabled()) {
+c->eax |= HV_X64_MSR_HYPERCALL_AVAILABLE;
+}
+if (hyperv_vapic_recommended()) {
+c->eax |= HV_X64_MSR_HYPERCALL_AVAILABLE;
+c->eax |= HV_X64_MSR_APIC_ACCESS_AVAILABLE;
+}
+
+c = &cpuid_data.entries[cpuid_i++];
+memset(c, 0, sizeof(*c));
+c->function = HYPERV_CPUID_ENLIGHTMENT_INFO;
+if (hyperv_relaxed_timing_enabled()) {
+c->eax |= HV_X64_RELAXED_TIMING_RECOMMENDED;
+}
+if (hyperv_vapic_recommended()) {
+c->eax |= HV_X64_APIC_ACCESS_RECOMMENDED;
+}
+c->ebx = hyperv_get_spinlock_retries();
+
+c = &cpuid_data.entries[cpuid_i++];
+memset(c, 0, sizeof(*c));
+c->function = HYPERV_CPUID_IMPLEMENT_LIMITS;
+c->eax = 0x40;
+c->ebx = 0x40;
+
+c = &cpuid_data.entries[cpuid_i++];
+memset(c, 0, sizeof(*c));
+c->function = KVM_CPUID_SIGNATURE_NEXT;
+memcpy(signature, "KVMKVMKVM\0\0\0", 12);
+c->eax = 0;
+c->ebx = signature[0];
+c->ecx = signature[1];
+c->edx = signature[2];
+}
+
has_msr_async_pf_en = c->eax & (1 << KVM_FEATURE_ASYNC_PF);
cpu_x86_cpuid(env, 0, 0, &limit, &unused, &unused, &unused);
@@ -953,6 +1007,13 @@ static int kvm_put_msrs(CPUState *env, int level)
kvm_msr_entry_set(&msrs[n++], MSR_KVM_ASYNC_PF_EN,
env->async_pf_en_msr);
}
+if (hyperv_hypercall_available()) {
+kvm_msr_entry_set(&msrs[n++], HV_X64_MSR_GUEST_OS_ID, 0);
+kvm_msr_entry_set(&msrs[n++], HV_X64_MSR_HYPERCALL, 0);
+}
+if (hyperv_vapic_recommended()) {
+kvm_msr_entry_set(&msrs[n++], HV_X64_MSR_APIC_ASSIST_PAGE, 0);
+}
}
if (env->mcg_cap) {
int i;
@@ -1190,6 +1251,14 @@ static int kvm_get_msrs(CPUState *env)
msrs[n++].index = MSR_KVM_ASYNC_PF_EN;
}
+if (hyperv_hypercall_available()) {
+msrs[n++].index = HV_X64_MSR_GUEST_OS_ID;
+msrs[n++].index = HV_X64_MSR_HYPERCALL;
+}
+if (hyperv_vapic_recommended()) {
+msrs[n++].index = HV_X64_MSR_APIC_ASSIST_PAGE;
+}
+
if (env->mcg_cap) {
msrs[n++].index = MSR_MCG_STATUS;
msrs[n++].index = MSR_MCG_CTL;
--
1.7.4.4
--
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 RFC] virtio-spec: flexible configuration layout
On Wed, 2011-11-09 at 14:38 +0200, Avi Kivity wrote: > On 11/09/2011 10:46 AM, Sasha Levin wrote: > > > Alternatively we can add new structures with new > > > structure IDs, pointed to from PCI configuration space. > > > > > > As we don't yet have devices or drivers with 64 bit features, > > > I decided we don't need high feature bits in legacy space. > > > This also frees up feature bit 31 as we don't need it > > > to enable high feature bits anymore. > > > > KVM tool actually has support for 64bit features, we can probably remove > > that when Pekka isn't looking :) > > > > What about the Windows drivers? > Probably some small adjustments will be required, but I don't see any major problem here. Vadim. -- 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: performance trouble
- Original Message - From: "Avi Kivity" To: "David Cure" Cc: kvm@vger.kernel.org, "Vadim Rozenfeld" Sent: Tuesday, February 14, 2012 3:32:16 PM Subject: Re: performance trouble On 02/10/2012 12:09 PM, David Cure wrote: > hello, > > Le Sun, Feb 05, 2012 at 11:38:34AM +0200, Avi Kivity ecrivait : > > > > Please post a trace as documented in http://www.linux-kvm.org/page/Tracing. > > I made the trace : started just before the slow function launch > and stoped just after. I start only one VM with 2 vcpus/16G RAM and only one > user connected to the VM to launch the test. > > The trace file is too big to post here, I gzip it and the file > is available here : http://www.roullier.net/report.txt.gz > > I hope you can find something strange. > It's reading the HPET like crazy. There are also tons of interrupts. Please use the windows performance tools to see which devices trigger these interrupts. [VR] +1 Try Microsoft Windows Performance Toolkit from Windows SDK http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=3138 It's really good. The HPET issue will be fixed by the hyper-V enlightenments, but these will take some time to cook. You can also try vhost-net to improve networking latency. -- 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: win7 bad i/o performance, high insn_emulation and exists
- Original Message - From: "Peter Lieven" To: "Gleb Natapov" Cc: qemu-de...@nongnu.org, kvm@vger.kernel.org, vroze...@redhat.com Sent: Tuesday, February 21, 2012 2:05:25 PM Subject: Re: win7 bad i/o performance, high insn_emulation and exists On 21.02.2012 12:46, Gleb Natapov wrote: > On Tue, Feb 21, 2012 at 12:16:16PM +0100, Peter Lieven wrote: >> On 21.02.2012 12:00, Gleb Natapov wrote: >>> On Tue, Feb 21, 2012 at 11:59:23AM +0100, Peter Lieven wrote: On 21.02.2012 11:56, Gleb Natapov wrote: > On Tue, Feb 21, 2012 at 11:50:47AM +0100, Peter Lieven wrote: >>> I hope it will make Windows use TSC instead, but you can't be sure >>> about anything with Windows :( >> Whatever it does now it eates more CPU has almost equal >> number of exits and throughput is about the same (15MB/s). >> If pmtimer is at 0xb008 it still reads it like hell. >> >> I checked with bcedit /v that useplatformclock is set to "No". > Yeah, today I noticed that it is likely virtio drivers that hammer > on PM timer (at least rip of the instruction that access it is > very close to rip of the instruction that access virtio pio). > Vadim, Windows driver developer, is CCed. Ok, I will switch to IDE and e1000 to confirm this? Or does it not make sense? >>> It make perfect sense! Please try it. >> ~10MB/s. still a lot of 0xb008 reads. >> [VR] Could it be that you have Driver Verifier running in you system? > The same amount of reads essentially. So my theory is incorrect. Virtio > driver probably calls Windows function to do IO and the function > happens to be near the function that access PM timer. > > I wonder why time stamps in your traces are so coarse-grained. What do > you see in /sys/bus/clocksource/devices/clocksource0/current_clocksource ? its set to acpi_pm on the host. we changed that from tsc (choosen by kernel) after we encountered a kernel bug which ooops all hosts after approx. 270 days uptime. (https://lkml.org/lkml/2011/7/21/343). i am not sure if this is fixed in 2.6.38 or later kernels and we could go back to tsc. for testing i already checked this, but it doesn't give better performance. peter > -- > Gleb. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: win7 bad i/o performance, high insn_emulation and exists
- Original Message - From: "Peter Lieven" To: "Vadim Rozenfeld" Cc: qemu-de...@nongnu.org, kvm@vger.kernel.org, "Gleb Natapov" Sent: Tuesday, February 21, 2012 4:10:22 PM Subject: Re: win7 bad i/o performance, high insn_emulation and exists On 21.02.2012 14:56, Vadim Rozenfeld wrote: > > - Original Message - > From: "Peter Lieven" > To: "Gleb Natapov" > Cc: qemu-de...@nongnu.org, kvm@vger.kernel.org, vroze...@redhat.com > Sent: Tuesday, February 21, 2012 2:05:25 PM > Subject: Re: win7 bad i/o performance, high insn_emulation and exists > > On 21.02.2012 12:46, Gleb Natapov wrote: >> On Tue, Feb 21, 2012 at 12:16:16PM +0100, Peter Lieven wrote: >>> On 21.02.2012 12:00, Gleb Natapov wrote: >>>> On Tue, Feb 21, 2012 at 11:59:23AM +0100, Peter Lieven wrote: >>>>> On 21.02.2012 11:56, Gleb Natapov wrote: >>>>>> On Tue, Feb 21, 2012 at 11:50:47AM +0100, Peter Lieven wrote: >>>>>>>> I hope it will make Windows use TSC instead, but you can't be sure >>>>>>>> about anything with Windows :( >>>>>>> Whatever it does now it eates more CPU has almost equal >>>>>>> number of exits and throughput is about the same (15MB/s). >>>>>>> If pmtimer is at 0xb008 it still reads it like hell. >>>>>>> >>>>>>> I checked with bcedit /v that useplatformclock is set to "No". >>>>>> Yeah, today I noticed that it is likely virtio drivers that hammer >>>>>> on PM timer (at least rip of the instruction that access it is >>>>>> very close to rip of the instruction that access virtio pio). >>>>>> Vadim, Windows driver developer, is CCed. >>>>> Ok, I will switch to IDE and e1000 to confirm this? Or does it not >>>>> make sense? >>>>> >>>> It make perfect sense! Please try it. >>> ~10MB/s. still a lot of 0xb008 reads. >>> > [VR] > Could it be that you have Driver Verifier running in you system? > unfortunately not. [VR] Then could you try booting into "Safe Mode"? i found the following in an old knowledge base article (http://support.microsoft.com/kb/938448): "Only Windows Server 2003 with Service Pack 2 uniprocessor ACPI HALs use *PMTIMER* for QPC by default. Multiprocessor ACPI HALs will use *PMTIMER* only if *USE_PLATFORM_CLOCK *flag is set by the BIOS or if the */usepmtimer *boot.ini option is used. Other HAL types don’t support *PMTIMER* and will use *TSC* by default for QPC By default, Windows Server 2003 Service Pack 2 (SP2) uses the PM timer for all Advanced Configuration and Power Interface (ACPI) HALs unless one of the following conditions aretrue: * The check process to determine whether the BIOS supports the APIC or ACPI HALs fails. * * Note:* If the BIOS does not support the ACPI HAL, contact the original equipment manufacturer to determine whether a BIOS update is available that will resolve the problem. If a BIOS update is not available, you must use the PM timer by using the */usepmtimer* switch. If you are not running Windows Server 2003 SP2, you must force the AMD computer to use the PM timer by using the */usepmtimer* switch. *Note* The decision to use the PM timer or the TSC timer is made during a check that is performed at startup to query the BIOS and to determine whether the BIOS will support the PM timer functions. This check is not completely accurate on AMD chipsets. Therefore, you must use the */usepmtimer* switch. In Windows Server 2003 SP2, this section of code was rewritten. Therefore, the correct performance monitor data appears on AMD chipsets that have Windows Server 2003 SP2 installed, and you do not have to use the */usepmtimer* switch. For more information about ACPI and APCI hardware support, click the following article number to view the article in the Microsoft Knowledge Base: 309283 <http://support.microsoft.com/kb/309283> HAL options after Windows XP or Windows Server 2003 Setup The third-party products that this article discusses are manufactured by companies that are independent of Microsoft. Microsoft makes no warranty, implied or otherwise, about the performance or reliability of these products." - so it seems windows prefers pmtimer over tsc. has anyone an idea/hack to make the acpi_pm timer fail without disabling acpi completely? thanks, peter -- 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: Virtio Block Device Queue Depth
On Friday, March 09, 2012 11:56:36 AM you wrote: > On Thu, Mar 8, 2012 at 5:48 PM, George Bottas wrote: > > I have a question regarding changing the queue size that is set in > > virtio_blk_init(). The current value is 128, which results in setting > > the queue depth in the Windows guest device to 8. Does anyone know if Actually, it's 6 128/(16+1) - 1 > > changing this value to defined maximum (1024) going to result in any In my experience, enalarging the queueu size doen't leas to any significant performance improvement > > issues? NB, we have also increased the thread pool accordingly. Our > > testing so far has produced a situation where initially we are seeing > > very high read request rates (1500+), and then at some point the reads > > from the Windows guest become serialized, i.e. the Windows guest > > synchronously sends one READ to the host, waits for it to complete, > > sends the next one, etc. Has this ever been seen anywhere else? On Win2K3 and higher, viostor operats in full-duplex mode. Which means that it must be able to process several requests simulteniousle. But if you have 6 requests pending (processing), storport driver will throttle incomming requestss. > > > > Any help on this would be appreciated. > > If you are really limited to 8 requests then the issue is not the > number of vring descriptors since recent virtio-blk has the indirect > vring feature enabled. The indirect vring feature allows the guest to > send 128 parallel requests - much higher than the 8 you mentioned from > Windows. It's true. However, I cannot say that indirect buffers will automaticaly give you a better performance. Inderect buffers should work faster for peretty big data chanks (128K..256K), while for the normal load (4K..64K) they give you almost the same numbers. Vadim. > > CCing Vadim who maintains the Windows virtio-blk driver. > > Stefan -- 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: performance trouble
On Thursday, March 22, 2012 09:53:45 AM Gleb Natapov wrote: > On Wed, Mar 21, 2012 at 06:31:02PM +0100, Peter Lieven wrote: > > On 21.03.2012 12:10, David Cure wrote: > > > hello, > > > > > >Le Tue, Mar 20, 2012 at 02:38:22PM +0200, Gleb Natapov ecrivait : > > >>Try to add to cpu > > >>definition in XML and check command line. > > >> > > > ok I try this but I can't use to map the host cpu > > > > > >(my libvirt is 0.9.8) so I use : > > > > > > > > > Opteron_G3 > > > > > > > > > > > > > > > (the physical server use Opteron CPU). > > > > > > The log is here : > > >http://www.roullier.net/Report/report-3.2-vhost-net-1vcpu-cpu.txt.gz > > > > > > And now with only 1 vcpu, the response time is 8.5s, great > > > > > >improvment. We keep this configuration for production : we check the > > >response time when some other users are connected. > > > > please keep in mind, that setting -hypervisor, disabling hpet and > > only one vcpu > > makes windows use tsc as clocksource. you have to make sure, that your vm > > is not switching between physical sockets on your system and that you > > have constant_tsc feature to have a stable tsc between the cores in the > > same socket. its also likely that the vm will crash when live migrated. > > All true. I asked to try -hypervisor only to verify where we loose > performance. Since you get good result with it frequent access to PM > timer is probably the reason. I do not recommend using -hypervisor for > production! > > > @gleb: do you know whats the state of in-kernel hyper-v timers? > > Vadim is working on it. I'll let him answer. It would be nice to have synthetic timers supported. But, at the moment, I'm only researching this feature. > > > peter > > > > > David. > > > > > >-- > > >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 > > -- > Gleb. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: performance trouble
On Thursday, March 22, 2012 10:52:42 AM Peter Lieven wrote: > On 22.03.2012 09:48, Vadim Rozenfeld wrote: > > On Thursday, March 22, 2012 09:53:45 AM Gleb Natapov wrote: > >> On Wed, Mar 21, 2012 at 06:31:02PM +0100, Peter Lieven wrote: > >>> On 21.03.2012 12:10, David Cure wrote: > >>>> hello, > >>>> > >>>> Le Tue, Mar 20, 2012 at 02:38:22PM +0200, Gleb Natapov ecrivait : > >>>>> Try to add to cpu > >>>>> definition in XML and check command line. > >>>>> > >>>> ok I try this but I can't use to map the host cpu > >>>> > >>>> (my libvirt is 0.9.8) so I use : > >>>> > >>>> > >>>> Opteron_G3 > >>>> > >>>> > >>>> > >>>> > >>>> (the physical server use Opteron CPU). > >>>> > >>>> The log is here : > >>>> http://www.roullier.net/Report/report-3.2-vhost-net-1vcpu-cpu.txt.gz > >>>> > >>>> And now with only 1 vcpu, the response time is 8.5s, great > >>>> > >>>> improvment. We keep this configuration for production : we check the > >>>> response time when some other users are connected. > >>> > >>> please keep in mind, that setting -hypervisor, disabling hpet and > >>> only one vcpu > >>> makes windows use tsc as clocksource. you have to make sure, that your > >>> vm is not switching between physical sockets on your system and that > >>> you have constant_tsc feature to have a stable tsc between the cores > >>> in the same socket. its also likely that the vm will crash when live > >>> migrated. > >> > >> All true. I asked to try -hypervisor only to verify where we loose > >> performance. Since you get good result with it frequent access to PM > >> timer is probably the reason. I do not recommend using -hypervisor for > >> production! > >> > >>> @gleb: do you know whats the state of in-kernel hyper-v timers? > >> > >> Vadim is working on it. I'll let him answer. > > > > It would be nice to have synthetic timers supported. But, at the moment, > > I'm only researching this feature. > > So it will take months at least? I would say weeks. > > What do the others think, would it be feasible to make a proper in-kernel > pmtimer solution in the meantime. > > I think Windows guest performance is very important for the success of KVM. > > Peter > > >>> peter > >>> > >>>> David. > >>>> > >>>> -- > >>>> 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 > >> > >> -- > >> > >>Gleb. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: performance trouble
On Monday, March 26, 2012 07:52:49 PM Gleb Natapov wrote:
> On Mon, Mar 26, 2012 at 07:46:03PM +0200, Vadim Rozenfeld wrote:
> > On Monday, March 26, 2012 07:00:32 PM Peter Lieven wrote:
> > > On 22.03.2012 10:38, Vadim Rozenfeld wrote:
> > > > On Thursday, March 22, 2012 10:52:42 AM Peter Lieven wrote:
> > > >> On 22.03.2012 09:48, Vadim Rozenfeld wrote:
> > > >>> On Thursday, March 22, 2012 09:53:45 AM Gleb Natapov wrote:
> > > >>>> On Wed, Mar 21, 2012 at 06:31:02PM +0100, Peter Lieven wrote:
> > > >>>>> On 21.03.2012 12:10, David Cure wrote:
> > > >>>>>>hello,
> > > >>>>>>
> > > >>>>>> Le Tue, Mar 20, 2012 at 02:38:22PM +0200, Gleb Natapov ecrivait :
> > > >>>>>>> Try to addto
> > > >>>>>>> cpu definition in XML and check command line.
> > > >>>>>>>
> > > >>>>>>ok I try this but I can't useto map the host cpu
> > > >>>>>>
> > > >>>>>> (my libvirt is 0.9.8) so I use :
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> Opteron_G3
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>(the physical server use Opteron CPU).
> > > >>>>>>
> > > >>>>>>The log is here :
> > > >>>>>> http://www.roullier.net/Report/report-3.2-vhost-net-1vcpu-cpu.tx
> > > >>>>>> t.gz
> > > >>>>>>
> > > >>>>>>And now with only 1 vcpu, the response time is 8.5s, great
> > > >>>>>>
> > > >>>>>> improvment. We keep this configuration for production : we check
> > > >>>>>> the response time when some other users are connected.
> > > >>>>>
> > > >>>>> please keep in mind, that setting -hypervisor, disabling hpet and
> > > >>>>> only one vcpu
> > > >>>>> makes windows use tsc as clocksource. you have to make sure, that
> > > >>>>> your vm is not switching between physical sockets on your system
> > > >>>>> and that you have constant_tsc feature to have a stable tsc
> > > >>>>> between the cores in the same socket. its also likely that the
> > > >>>>> vm will crash when live migrated.
> > > >>>>
> > > >>>> All true. I asked to try -hypervisor only to verify where we loose
> > > >>>> performance. Since you get good result with it frequent access to
> > > >>>> PM timer is probably the reason. I do not recommend using
> > > >>>> -hypervisor for production!
> > > >>>>
> > > >>>>> @gleb: do you know whats the state of in-kernel hyper-v timers?
> > > >>>>
> > > >>>> Vadim is working on it. I'll let him answer.
> > > >>>
> > > >>> It would be nice to have synthetic timers supported. But, at the
> > > >>> moment, I'm only researching this feature.
> > > >>
> > > >> So it will take months at least?
> > > >
> > > > I would say weeks.
> > >
> > > Is there a way, we could contribute and help you with this?
> >
> > Hi Peter,
> > You are welcome to add an appropriate handler.
>
> I think Vadim refers to this HV MSR
> http://msdn.microsoft.com/en-us/library/windows/hardware/ff542633%28v=vs.85
> %29.aspx
This one is pretty simple to support. Please see attachments for more details.
I was thinking about synthetic timers http://msdn.microsoft.com/en-
us/library/windows/hardware/ff542758(v=vs.85).aspx
>
> --
> Gleb.
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 74c9edf..fafc8ff 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -535,6 +535,7 @@ struct kvm_arch {
/* fields used by HYPER-V emulation */
u64 hv_guest_os_id;
u64 hv_hypercall;
+u64 hv_ref_count;
atomic_t reader_counter;
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index c9d99e5..4562581 100644
--- a/arch/x86/kvm/x86.c
+++ b/
Re: performance trouble
On Monday, March 26, 2012 07:00:32 PM Peter Lieven wrote: > On 22.03.2012 10:38, Vadim Rozenfeld wrote: > > On Thursday, March 22, 2012 10:52:42 AM Peter Lieven wrote: > >> On 22.03.2012 09:48, Vadim Rozenfeld wrote: > >>> On Thursday, March 22, 2012 09:53:45 AM Gleb Natapov wrote: > >>>> On Wed, Mar 21, 2012 at 06:31:02PM +0100, Peter Lieven wrote: > >>>>> On 21.03.2012 12:10, David Cure wrote: > >>>>>>hello, > >>>>>> > >>>>>> Le Tue, Mar 20, 2012 at 02:38:22PM +0200, Gleb Natapov ecrivait : > >>>>>>> Try to addto cpu > >>>>>>> definition in XML and check command line. > >>>>>>> > >>>>>>ok I try this but I can't useto map the host cpu > >>>>>> > >>>>>> (my libvirt is 0.9.8) so I use : > >>>>>> > >>>>>> > >>>>>> Opteron_G3 > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>(the physical server use Opteron CPU). > >>>>>> > >>>>>>The log is here : > >>>>>> http://www.roullier.net/Report/report-3.2-vhost-net-1vcpu-cpu.txt.gz > >>>>>> > >>>>>>And now with only 1 vcpu, the response time is 8.5s, great > >>>>>> > >>>>>> improvment. We keep this configuration for production : we check the > >>>>>> response time when some other users are connected. > >>>>> > >>>>> please keep in mind, that setting -hypervisor, disabling hpet and > >>>>> only one vcpu > >>>>> makes windows use tsc as clocksource. you have to make sure, that > >>>>> your vm is not switching between physical sockets on your system and > >>>>> that you have constant_tsc feature to have a stable tsc between the > >>>>> cores in the same socket. its also likely that the vm will crash > >>>>> when live migrated. > >>>> > >>>> All true. I asked to try -hypervisor only to verify where we loose > >>>> performance. Since you get good result with it frequent access to PM > >>>> timer is probably the reason. I do not recommend using -hypervisor for > >>>> production! > >>>> > >>>>> @gleb: do you know whats the state of in-kernel hyper-v timers? > >>>> > >>>> Vadim is working on it. I'll let him answer. > >>> > >>> It would be nice to have synthetic timers supported. But, at the > >>> moment, I'm only researching this feature. > >> > >> So it will take months at least? > > > > I would say weeks. > > Is there a way, we could contribute and help you with this? Hi Peter, You are welcome to add an appropriate handler. Best regards, Vadim. > > Peter -- 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: performance trouble
On Monday, March 26, 2012 08:54:50 PM Peter Lieven wrote: > On 26.03.2012 20:36, Vadim Rozenfeld wrote: > > On Monday, March 26, 2012 07:52:49 PM Gleb Natapov wrote: > >> On Mon, Mar 26, 2012 at 07:46:03PM +0200, Vadim Rozenfeld wrote: > >>> On Monday, March 26, 2012 07:00:32 PM Peter Lieven wrote: > >>>> On 22.03.2012 10:38, Vadim Rozenfeld wrote: > >>>>> On Thursday, March 22, 2012 10:52:42 AM Peter Lieven wrote: > >>>>>> On 22.03.2012 09:48, Vadim Rozenfeld wrote: > >>>>>>> On Thursday, March 22, 2012 09:53:45 AM Gleb Natapov wrote: > >>>>>>>> On Wed, Mar 21, 2012 at 06:31:02PM +0100, Peter Lieven wrote: > >>>>>>>>> On 21.03.2012 12:10, David Cure wrote: > >>>>>>>>>>hello, > >>>>>>>>>> > >>>>>>>>>> Le Tue, Mar 20, 2012 at 02:38:22PM +0200, Gleb Natapov ecrivait : > >>>>>>>>>>> Try to add to > >>>>>>>>>>> cpu definition in XML and check command line. > >>>>>>>>>>> > >>>>>>>>>>ok I try this but I can't use to map the host > >>>>>>>>>>cpu > >>>>>>>>>> > >>>>>>>>>> (my libvirt is 0.9.8) so I use : > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>Opteron_G3 > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>(the physical server use Opteron CPU). > >>>>>>>>>> > >>>>>>>>>>The log is here : > >>>>>>>>>> http://www.roullier.net/Report/report-3.2-vhost-net-1vcpu-cpu.tx > >>>>>>>>>> t.gz > >>>>>>>>>> > >>>>>>>>>>And now with only 1 vcpu, the response time is 8.5s, great > >>>>>>>>>> > >>>>>>>>>> improvment. We keep this configuration for production : we check > >>>>>>>>>> the response time when some other users are connected. > >>>>>>>>> > >>>>>>>>> please keep in mind, that setting -hypervisor, disabling hpet and > >>>>>>>>> only one vcpu > >>>>>>>>> makes windows use tsc as clocksource. you have to make sure, that > >>>>>>>>> your vm is not switching between physical sockets on your system > >>>>>>>>> and that you have constant_tsc feature to have a stable tsc > >>>>>>>>> between the cores in the same socket. its also likely that the > >>>>>>>>> vm will crash when live migrated. > >>>>>>>> > >>>>>>>> All true. I asked to try -hypervisor only to verify where we loose > >>>>>>>> performance. Since you get good result with it frequent access to > >>>>>>>> PM timer is probably the reason. I do not recommend using > >>>>>>>> -hypervisor for production! > >>>>>>>> > >>>>>>>>> @gleb: do you know whats the state of in-kernel hyper-v timers? > >>>>>>>> > >>>>>>>> Vadim is working on it. I'll let him answer. > >>>>>>> > >>>>>>> It would be nice to have synthetic timers supported. But, at the > >>>>>>> moment, I'm only researching this feature. > >>>>>> > >>>>>> So it will take months at least? > >>>>> > >>>>> I would say weeks. > >>>> > >>>> Is there a way, we could contribute and help you with this? > >>> > >>> Hi Peter, > >>> You are welcome to add an appropriate handler. > >> > >> I think Vadim refers to this HV MSR > >> http://msdn.microsoft.com/en-us/library/windows/hardware/ff542633%28v=vs > >> .85 %29.aspx > > > > This one is pretty simple to support. Please see attachments for more > > details. I was thinking about synthetic timers > > http://msdn.microsoft.com/en- > > us/library/windows/hardware/ff542758(v=vs.85).aspx > > is this what microsoft qpc uses as clocksource in hyper-v? Yes, it should be enough for Win7 / W2K8R2. Cheers, Vadim. > i will check tomorrow. > > thanks > vadim > > >> -- > >> > >>Gleb. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: performance trouble
On Tuesday, March 27, 2012 10:56:05 AM Gleb Natapov wrote: > On Mon, Mar 26, 2012 at 10:11:43PM +0200, Vadim Rozenfeld wrote: > > On Monday, March 26, 2012 08:54:50 PM Peter Lieven wrote: > > > On 26.03.2012 20:36, Vadim Rozenfeld wrote: > > > > On Monday, March 26, 2012 07:52:49 PM Gleb Natapov wrote: > > > >> On Mon, Mar 26, 2012 at 07:46:03PM +0200, Vadim Rozenfeld wrote: > > > >>> On Monday, March 26, 2012 07:00:32 PM Peter Lieven wrote: > > > >>>> On 22.03.2012 10:38, Vadim Rozenfeld wrote: > > > >>>>> On Thursday, March 22, 2012 10:52:42 AM Peter Lieven wrote: > > > >>>>>> On 22.03.2012 09:48, Vadim Rozenfeld wrote: > > > >>>>>>> On Thursday, March 22, 2012 09:53:45 AM Gleb Natapov wrote: > > > >>>>>>>> On Wed, Mar 21, 2012 at 06:31:02PM +0100, Peter Lieven wrote: > > > >>>>>>>>> On 21.03.2012 12:10, David Cure wrote: > > > >>>>>>>>>>hello, > > > >>>>>>>>>> > > > >>>>>>>>>> Le Tue, Mar 20, 2012 at 02:38:22PM +0200, Gleb Natapov ecrivait : > > > >>>>>>>>>>> Try to add > > > >>>>>>>>>>> to cpu definition in XML and check command line. > > > >>>>>>>>>>> > > > >>>>>>>>>>ok I try this but I can't use to map the > > > >>>>>>>>>>host cpu > > > >>>>>>>>>> > > > >>>>>>>>>> (my libvirt is 0.9.8) so I use : > > > >>>>>>>>>> > > > >>>>>>>>>> > > > >>>>>>>>>>Opteron_G3 > > > >>>>>>>>>> > > > >>>>>>>>>> > > > >>>>>>>>>> > > > >>>>>>>>>> > > > >>>>>>>>>>(the physical server use Opteron CPU). > > > >>>>>>>>>> > > > >>>>>>>>>>The log is here : > > > >>>>>>>>>> http://www.roullier.net/Report/report-3.2-vhost-net-1vcpu-cp > > > >>>>>>>>>> u.tx t.gz > > > >>>>>>>>>> > > > >>>>>>>>>>And now with only 1 vcpu, the response time is 8.5s, > > > >>>>>>>>>> great > > > >>>>>>>>>> > > > >>>>>>>>>> improvment. We keep this configuration for production : we > > > >>>>>>>>>> check the response time when some other users are > > > >>>>>>>>>> connected. > > > >>>>>>>>> > > > >>>>>>>>> please keep in mind, that setting -hypervisor, disabling hpet > > > >>>>>>>>> and only one vcpu > > > >>>>>>>>> makes windows use tsc as clocksource. you have to make sure, > > > >>>>>>>>> that your vm is not switching between physical sockets on > > > >>>>>>>>> your system and that you have constant_tsc feature to have a > > > >>>>>>>>> stable tsc between the cores in the same socket. its also > > > >>>>>>>>> likely that the vm will crash when live migrated. > > > >>>>>>>> > > > >>>>>>>> All true. I asked to try -hypervisor only to verify where we > > > >>>>>>>> loose performance. Since you get good result with it frequent > > > >>>>>>>> access to PM timer is probably the reason. I do not recommend > > > >>>>>>>> using -hypervisor for production! > > > >>>>>>>> > > > >>>>>>>>> @gleb: do you know whats the state of in-kernel hyper-v > > > >>>>>>>>> timers? > > > >>>>>>>> > > > >>>>>>>> Vadim is working on it. I'll let him answer. > > > >>>>>>> > > > >>>>>>> It would be nice to have synthetic timers supported. But, at > > > >>>>>>> the moment, I'm only researching this feature. > > > >>>>>> > > > >>>>>> So it will take months at least? > > > >>>>> > > > >>>>> I would say weeks. > > > >>>> > > > >>>> Is there a way, we could contribute and help you with this? > > > >>> > > > >>> Hi Peter, > > > >>> You are welcome to add an appropriate handler. > > > >> > > > >> I think Vadim refers to this HV MSR > > > >> http://msdn.microsoft.com/en-us/library/windows/hardware/ff542633%28 > > > >> v=vs .85 %29.aspx > > > > > > > > This one is pretty simple to support. Please see attachments for more > > > > details. I was thinking about synthetic timers > > > > http://msdn.microsoft.com/en- > > > > us/library/windows/hardware/ff542758(v=vs.85).aspx > > > > > > is this what microsoft qpc uses as clocksource in hyper-v? > > > > Yes, it should be enough for Win7 / W2K8R2. > > To clarify the thing that microsoft qpc uses is what is implemented by > the patch Vadim attached to his previous email. But I believe that > additional qemu patch is needed for Windows to actually use it. You are right. bits 1 and 9 must be set to on in leaf 0x4003 and HPET should be completely removed from ACPI. > > -- > Gleb. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: performance trouble
On Tuesday, March 27, 2012 11:26:29 AM Peter Lieven wrote: > On 27.03.2012 11:23, Vadim Rozenfeld wrote: > > On Tuesday, March 27, 2012 10:56:05 AM Gleb Natapov wrote: > >> On Mon, Mar 26, 2012 at 10:11:43PM +0200, Vadim Rozenfeld wrote: > >>> On Monday, March 26, 2012 08:54:50 PM Peter Lieven wrote: > >>>> On 26.03.2012 20:36, Vadim Rozenfeld wrote: > >>>>> On Monday, March 26, 2012 07:52:49 PM Gleb Natapov wrote: > >>>>>> On Mon, Mar 26, 2012 at 07:46:03PM +0200, Vadim Rozenfeld wrote: > >>>>>>> On Monday, March 26, 2012 07:00:32 PM Peter Lieven wrote: > >>>>>>>> On 22.03.2012 10:38, Vadim Rozenfeld wrote: > >>>>>>>>> On Thursday, March 22, 2012 10:52:42 AM Peter Lieven wrote: > >>>>>>>>>> On 22.03.2012 09:48, Vadim Rozenfeld wrote: > >>>>>>>>>>> On Thursday, March 22, 2012 09:53:45 AM Gleb Natapov wrote: > >>>>>>>>>>>> On Wed, Mar 21, 2012 at 06:31:02PM +0100, Peter Lieven wrote: > >>>>>>>>>>>>> On 21.03.2012 12:10, David Cure wrote: > >>>>>>>>>>>>>>hello, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Le Tue, Mar 20, 2012 at 02:38:22PM +0200, Gleb Natapov > > > > ecrivait : > >>>>>>>>>>>>>>> Try to add > >>>>>>>>>>>>>>> to cpu definition in XML and check command line. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>ok I try this but I can't use to map the > >>>>>>>>>>>>>>host cpu > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> (my libvirt is 0.9.8) so I use : > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Opteron_G3 > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>(the physical server use Opteron CPU). > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>The log is here : > >>>>>>>>>>>>>> http://www.roullier.net/Report/report-3.2-vhost-net-1vcpu-cp > >>>>>>>>>>>>>> u.tx t.gz > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>And now with only 1 vcpu, the response time is 8.5s, > >>>>>>>>>>>>>> great > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> improvment. We keep this configuration for production : we > >>>>>>>>>>>>>> check the response time when some other users are > >>>>>>>>>>>>>> connected. > >>>>>>>>>>>>> > >>>>>>>>>>>>> please keep in mind, that setting -hypervisor, disabling hpet > >>>>>>>>>>>>> and only one vcpu > >>>>>>>>>>>>> makes windows use tsc as clocksource. you have to make sure, > >>>>>>>>>>>>> that your vm is not switching between physical sockets on > >>>>>>>>>>>>> your system and that you have constant_tsc feature to have a > >>>>>>>>>>>>> stable tsc between the cores in the same socket. its also > >>>>>>>>>>>>> likely that the vm will crash when live migrated. > >>>>>>>>>>>> > >>>>>>>>>>>> All true. I asked to try -hypervisor only to verify where we > >>>>>>>>>>>> loose performance. Since you get good result with it frequent > >>>>>>>>>>>> access to PM timer is probably the reason. I do not recommend > >>>>>>>>>>>> using -hypervisor for production! > >>>>>>>>>>>> > >>>>>>>>>>>>> @gleb: do you know whats the state of in-kernel hyper-v > >>>>>>>>>>>>> timers? > >>>>>>>>>>>> > >>>>>>>>>>>> Vadim is working on it. I'll let him answer. > >>>>>>>>>>> > >>>>>>>>>>> It would be nice to have synthetic timers supported. But, at > >>>>>>>>>>> the moment, I'm only researching this feature. > >>>>>>>>>> > >>>>>>>>>> So it will take months at least? > >>>>>>>>> > >>>>>>>>> I would say weeks. > >>>>>>>> > >>>>>>>> Is there a way, we could contribute and help you with this? > >>>>>>> > >>>>>>> Hi Peter, > >>>>>>> You are welcome to add an appropriate handler. > >>>>>> > >>>>>> I think Vadim refers to this HV MSR > >>>>>> http://msdn.microsoft.com/en-us/library/windows/hardware/ff542633%28 > >>>>>> v=vs .85 %29.aspx > >>>>> > >>>>> This one is pretty simple to support. Please see attachments for more > >>>>> details. I was thinking about synthetic timers > >>>>> http://msdn.microsoft.com/en- > >>>>> us/library/windows/hardware/ff542758(v=vs.85).aspx > >>>> > >>>> is this what microsoft qpc uses as clocksource in hyper-v? > >>> > >>> Yes, it should be enough for Win7 / W2K8R2. > >> > >> To clarify the thing that microsoft qpc uses is what is implemented by > >> the patch Vadim attached to his previous email. But I believe that > >> additional qemu patch is needed for Windows to actually use it. > > > > You are right. > > bits 1 and 9 must be set to on in leaf 0x4003 and HPET > > should be completely removed from ACPI. > > could you advise how to do this and/or make a patch? Gleb mentioned that it properly handled in upstream, otherwise just comment the entire HPET section in acpi-dsdt.dsl file. > > the stuff you send yesterday is for qemu, right? would > it be possible to use it in qemu-kvm also? Yes, but don't forget about kvm patch as well. > > peter > > >> -- > >> > >>Gleb. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: performance trouble
On Tuesday, March 27, 2012 12:49:58 PM Peter Lieven wrote: > On 27.03.2012 12:40, Vadim Rozenfeld wrote: > > On Tuesday, March 27, 2012 11:26:29 AM Peter Lieven wrote: > >> On 27.03.2012 11:23, Vadim Rozenfeld wrote: > >>> On Tuesday, March 27, 2012 10:56:05 AM Gleb Natapov wrote: > >>>> On Mon, Mar 26, 2012 at 10:11:43PM +0200, Vadim Rozenfeld wrote: > >>>>> On Monday, March 26, 2012 08:54:50 PM Peter Lieven wrote: > >>>>>> On 26.03.2012 20:36, Vadim Rozenfeld wrote: > >>>>>>> On Monday, March 26, 2012 07:52:49 PM Gleb Natapov wrote: > >>>>>>>> On Mon, Mar 26, 2012 at 07:46:03PM +0200, Vadim Rozenfeld wrote: > >>>>>>>>> On Monday, March 26, 2012 07:00:32 PM Peter Lieven wrote: > >>>>>>>>>> On 22.03.2012 10:38, Vadim Rozenfeld wrote: > >>>>>>>>>>> On Thursday, March 22, 2012 10:52:42 AM Peter Lieven wrote: > >>>>>>>>>>>> On 22.03.2012 09:48, Vadim Rozenfeld wrote: > >>>>>>>>>>>>> On Thursday, March 22, 2012 09:53:45 AM Gleb Natapov wrote: > >>>>>>>>>>>>>> On Wed, Mar 21, 2012 at 06:31:02PM +0100, Peter Lieven wrote: > >>>>>>>>>>>>>>> On 21.03.2012 12:10, David Cure wrote: > >>>>>>>>>>>>>>>> hello, > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Le Tue, Mar 20, 2012 at 02:38:22PM +0200, Gleb Natapov > >>> > >>> ecrivait : > >>>>>>>>>>>>>>>>> Try to add > >>>>>>>>>>>>>>>>> to cpu definition in XML and check command line. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> ok I try this but I can't use to map the > >>>>>>>>>>>>>>>> host cpu > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> (my libvirt is 0.9.8) so I use : > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Opteron_G3 > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> (the physical server use Opteron CPU). > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> The log is here : > >>>>>>>>>>>>>>>> http://www.roullier.net/Report/report-3.2-vhost-net-1vcpu- > >>>>>>>>>>>>>>>> cp u.tx t.gz > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> And now with only 1 vcpu, the response time is 8.5s, > >>>>>>>>>>>>>>>> great > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> improvment. We keep this configuration for production : we > >>>>>>>>>>>>>>>> check the response time when some other users are > >>>>>>>>>>>>>>>> connected. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> please keep in mind, that setting -hypervisor, disabling > >>>>>>>>>>>>>>> hpet and only one vcpu > >>>>>>>>>>>>>>> makes windows use tsc as clocksource. you have to make > >>>>>>>>>>>>>>> sure, that your vm is not switching between physical > >>>>>>>>>>>>>>> sockets on your system and that you have constant_tsc > >>>>>>>>>>>>>>> feature to have a stable tsc between the cores in the sam
Re: performance trouble
On Tuesday, March 27, 2012 04:44:51 PM Peter Lieven wrote: > On 27.03.2012 13:43, Vadim Rozenfeld wrote: > > On Tuesday, March 27, 2012 12:49:58 PM Peter Lieven wrote: > >> On 27.03.2012 12:40, Vadim Rozenfeld wrote: > >>> On Tuesday, March 27, 2012 11:26:29 AM Peter Lieven wrote: > >>>> On 27.03.2012 11:23, Vadim Rozenfeld wrote: > >>>>> On Tuesday, March 27, 2012 10:56:05 AM Gleb Natapov wrote: > >>>>>> On Mon, Mar 26, 2012 at 10:11:43PM +0200, Vadim Rozenfeld wrote: > >>>>>>> On Monday, March 26, 2012 08:54:50 PM Peter Lieven wrote: > >>>>>>>> On 26.03.2012 20:36, Vadim Rozenfeld wrote: > >>>>>>>>> On Monday, March 26, 2012 07:52:49 PM Gleb Natapov wrote: > >>>>>>>>>> On Mon, Mar 26, 2012 at 07:46:03PM +0200, Vadim Rozenfeld wrote: > >>>>>>>>>>> On Monday, March 26, 2012 07:00:32 PM Peter Lieven wrote: > >>>>>>>>>>>> On 22.03.2012 10:38, Vadim Rozenfeld wrote: > >>>>>>>>>>>>> On Thursday, March 22, 2012 10:52:42 AM Peter Lieven wrote: > >>>>>>>>>>>>>> On 22.03.2012 09:48, Vadim Rozenfeld wrote: > >>>>>>>>>>>>>>> On Thursday, March 22, 2012 09:53:45 AM Gleb Natapov wrote: > >>>>>>>>>>>>>>>> On Wed, Mar 21, 2012 at 06:31:02PM +0100, Peter Lieven wrote: > >>>>>>>>>>>>>>>>> On 21.03.2012 12:10, David Cure wrote: > >>>>>>>>>>>>>>>>>>hello, > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Le Tue, Mar 20, 2012 at 02:38:22PM +0200, Gleb Natapov > >>>>> > >>>>> ecrivait : > >>>>>>>>>>>>>>>>>>> Try to add > >>>>>>>>>>>>>>>>>>> to cpu definition in XML and check command line. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>ok I try this but I can't useto map > > > > the > > > >>>>>>>>>>>>>>>>>>host cpu > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> (my libvirt is 0.9.8) so I use : > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Opteron_G3 > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>(the physical server use Opteron CPU). > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>The log is here : > >>>>>>>>>>>>>>>>>> http://www.roullier.net/Report/report-3.2-vhost-net-1vcp > >>>>>>>>>>>>>>>>>> u- cp u.tx t.gz > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>And now with only 1 vcpu, the response time is 8.5s, > >>>>>>>>>>>>>>>>>>great > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> improvment. We keep this configuration for production : > >>>>>>>>>>>>>>>>>> we check the response time when some other users are > >>>>>>>>>>>>>>>>>> connected. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> please keep in mind, that setting -hypervisor, disabling > >>>>>>>>>
Re: performance trouble
On Tuesday, March 27, 2012 04:06:13 PM Peter Lieven wrote: > On 27.03.2012 14:29, Gleb Natapov wrote: > > On Tue, Mar 27, 2012 at 02:28:04PM +0200, Peter Lieven wrote: > >> On 27.03.2012 14:26, Gleb Natapov wrote: > >>> On Tue, Mar 27, 2012 at 02:20:23PM +0200, Peter Lieven wrote: > >>>> On 27.03.2012 12:00, Gleb Natapov wrote: > >>>>> On Tue, Mar 27, 2012 at 11:26:29AM +0200, Peter Lieven wrote: > >>>>>> On 27.03.2012 11:23, Vadim Rozenfeld wrote: > >>>>>>> On Tuesday, March 27, 2012 10:56:05 AM Gleb Natapov wrote: > >>>>>>>> On Mon, Mar 26, 2012 at 10:11:43PM +0200, Vadim Rozenfeld wrote: > >>>>>>>>> On Monday, March 26, 2012 08:54:50 PM Peter Lieven wrote: > >>>>>>>>>> On 26.03.2012 20:36, Vadim Rozenfeld wrote: > >>>>>>>>>>> On Monday, March 26, 2012 07:52:49 PM Gleb Natapov wrote: > >>>>>>>>>>>> On Mon, Mar 26, 2012 at 07:46:03PM +0200, Vadim Rozenfeld wrote: > >>>>>>>>>>>>> On Monday, March 26, 2012 07:00:32 PM Peter Lieven wrote: > >>>>>>>>>>>>>> On 22.03.2012 10:38, Vadim Rozenfeld wrote: > >>>>>>>>>>>>>>> On Thursday, March 22, 2012 10:52:42 AM Peter Lieven wrote: > >>>>>>>>>>>>>>>> On 22.03.2012 09:48, Vadim Rozenfeld wrote: > >>>>>>>>>>>>>>>>> On Thursday, March 22, 2012 09:53:45 AM Gleb Natapov wrote: > >>>>>>>>>>>>>>>>>> On Wed, Mar 21, 2012 at 06:31:02PM +0100, Peter Lieven wrote: > >>>>>>>>>>>>>>>>>>> On 21.03.2012 12:10, David Cure wrote: > >>>>>>>>>>>>>>>>>>>> hello, > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Le Tue, Mar 20, 2012 at 02:38:22PM +0200, Gleb Natapov > >>>>>>> > >>>>>>> ecrivait : > >>>>>>>>>>>>>>>>>>>>> Try to add >>>>>>>>>>>>>>>>>>>>> name='hypervisor'/> to cpu definition in XML and > >>>>>>>>>>>>>>>>>>>>> check command line. > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> ok I try this but I can't use to > >>>>>>>>>>>>>>>>>>>> map the host cpu > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> (my libvirt is 0.9.8) so I use : > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Opteron_G3 > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> (the physical server use Opteron CPU). > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> The log is here : > >>>>>>>>>>>>>>>>>>>> http://www.roullier.net/Report/report-3.2-vhost-net-1v > >>>>>>>>>>>>>>>>>>>> cpu-cp u.tx t.gz > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> And now with only 1 vcpu, the response time is 8.5s, > >>>>>>>>>>>>>>>>>>>> great > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>&
Re: performance trouble
On Tuesday, March 27, 2012 05:39:10 PM Peter Lieven wrote: > On 27.03.2012 17:37, Vadim Rozenfeld wrote: > > On Tuesday, March 27, 2012 04:44:51 PM Peter Lieven wrote: > >> On 27.03.2012 13:43, Vadim Rozenfeld wrote: > >>> On Tuesday, March 27, 2012 12:49:58 PM Peter Lieven wrote: > >>>> On 27.03.2012 12:40, Vadim Rozenfeld wrote: > >>>>> On Tuesday, March 27, 2012 11:26:29 AM Peter Lieven wrote: > >>>>>> On 27.03.2012 11:23, Vadim Rozenfeld wrote: > >>>>>>> On Tuesday, March 27, 2012 10:56:05 AM Gleb Natapov wrote: > >>>>>>>> On Mon, Mar 26, 2012 at 10:11:43PM +0200, Vadim Rozenfeld wrote: > >>>>>>>>> On Monday, March 26, 2012 08:54:50 PM Peter Lieven wrote: > >>>>>>>>>> On 26.03.2012 20:36, Vadim Rozenfeld wrote: > >>>>>>>>>>> On Monday, March 26, 2012 07:52:49 PM Gleb Natapov wrote: > >>>>>>>>>>>> On Mon, Mar 26, 2012 at 07:46:03PM +0200, Vadim Rozenfeld wrote: > >>>>>>>>>>>>> On Monday, March 26, 2012 07:00:32 PM Peter Lieven wrote: > >>>>>>>>>>>>>> On 22.03.2012 10:38, Vadim Rozenfeld wrote: > >>>>>>>>>>>>>>> On Thursday, March 22, 2012 10:52:42 AM Peter Lieven wrote: > >>>>>>>>>>>>>>>> On 22.03.2012 09:48, Vadim Rozenfeld wrote: > >>>>>>>>>>>>>>>>> On Thursday, March 22, 2012 09:53:45 AM Gleb Natapov wrote: > >>>>>>>>>>>>>>>>>> On Wed, Mar 21, 2012 at 06:31:02PM +0100, Peter Lieven > > > > wrote: > >>>>>>>>>>>>>>>>>>> On 21.03.2012 12:10, David Cure wrote: > >>>>>>>>>>>>>>>>>>>> hello, > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Le Tue, Mar 20, 2012 at 02:38:22PM +0200, Gleb Natapov > >>>>>>> > >>>>>>> ecrivait : > >>>>>>>>>>>>>>>>>>>>> Try to add >>>>>>>>>>>>>>>>>>>>> name='hypervisor'/> to cpu definition in XML and > >>>>>>>>>>>>>>>>>>>>> check command line. > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> ok I try this but I can't use to > >>>>>>>>>>>>>>>>>>>> map > >>> > >>> the > >>> > >>>>>>>>>>>>>>>>>>>> host cpu > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> (my libvirt is 0.9.8) so I use : > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>Opteron_G3 > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>name='hypervisor'/> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> (the physical server use Opteron CPU). > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> The log is here : > >>>>>>>>>>>>>>>>>>>> http://www.roullier.net/Report/report-3.2-vhost-net-1v > >>>>>>>>>>>>>>>>>>>> cp u- cp u.tx t.gz > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>
Re: performance trouble
On Tuesday, March 27, 2012 05:58:01 PM Peter Lieven wrote: > On 27.03.2012 17:44, Vadim Rozenfeld wrote: > > On Tuesday, March 27, 2012 04:06:13 PM Peter Lieven wrote: > >> On 27.03.2012 14:29, Gleb Natapov wrote: > >>> On Tue, Mar 27, 2012 at 02:28:04PM +0200, Peter Lieven wrote: > >>>> On 27.03.2012 14:26, Gleb Natapov wrote: > >>>>> On Tue, Mar 27, 2012 at 02:20:23PM +0200, Peter Lieven wrote: > >>>>>> On 27.03.2012 12:00, Gleb Natapov wrote: > >>>>>>> On Tue, Mar 27, 2012 at 11:26:29AM +0200, Peter Lieven wrote: > >>>>>>>> On 27.03.2012 11:23, Vadim Rozenfeld wrote: > >>>>>>>>> On Tuesday, March 27, 2012 10:56:05 AM Gleb Natapov wrote: > >>>>>>>>>> On Mon, Mar 26, 2012 at 10:11:43PM +0200, Vadim Rozenfeld wrote: > >>>>>>>>>>> On Monday, March 26, 2012 08:54:50 PM Peter Lieven wrote: > >>>>>>>>>>>> On 26.03.2012 20:36, Vadim Rozenfeld wrote: > >>>>>>>>>>>>> On Monday, March 26, 2012 07:52:49 PM Gleb Natapov wrote: > >>>>>>>>>>>>>> On Mon, Mar 26, 2012 at 07:46:03PM +0200, Vadim Rozenfeld > > > > wrote: > >>>>>>>>>>>>>>> On Monday, March 26, 2012 07:00:32 PM Peter Lieven wrote: > >>>>>>>>>>>>>>>> On 22.03.2012 10:38, Vadim Rozenfeld wrote: > >>>>>>>>>>>>>>>>> On Thursday, March 22, 2012 10:52:42 AM Peter Lieven wrote: > >>>>>>>>>>>>>>>>>> On 22.03.2012 09:48, Vadim Rozenfeld wrote: > >>>>>>>>>>>>>>>>>>> On Thursday, March 22, 2012 09:53:45 AM Gleb Natapov > > > > wrote: > >>>>>>>>>>>>>>>>>>>> On Wed, Mar 21, 2012 at 06:31:02PM +0100, Peter Lieven > > > > wrote: > >>>>>>>>>>>>>>>>>>>>> On 21.03.2012 12:10, David Cure wrote: > >>>>>>>>>>>>>>>>>>>>>>hello, > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> Le Tue, Mar 20, 2012 at 02:38:22PM +0200, Gleb > >>>>>>>>>>>>>>>>>>>>>> Natapov > >>>>>>>>> > >>>>>>>>> ecrivait : > >>>>>>>>>>>>>>>>>>>>>>> Try to add >>>>>>>>>>>>>>>>>>>>>>> name='hypervisor'/> to cpu definition in XML and > >>>>>>>>>>>>>>>>>>>>>>> check command line. > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>ok I try this but I can't use > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>to map the host cpu > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> (my libvirt is 0.9.8) so I use : > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> Opteron_G3 > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> name='hypervisor'/> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>(the physical server use Opteron CPU). > >>>>>>>
Re: performance trouble
On Tuesday, March 27, 2012 06:16:11 PM Peter Lieven wrote: > On 27.03.2012 18:12, Vadim Rozenfeld wrote: > > On Tuesday, March 27, 2012 05:58:01 PM Peter Lieven wrote: > >> On 27.03.2012 17:44, Vadim Rozenfeld wrote: > >>> On Tuesday, March 27, 2012 04:06:13 PM Peter Lieven wrote: > >>>> On 27.03.2012 14:29, Gleb Natapov wrote: > >>>>> On Tue, Mar 27, 2012 at 02:28:04PM +0200, Peter Lieven wrote: > >>>>>> On 27.03.2012 14:26, Gleb Natapov wrote: > >>>>>>> On Tue, Mar 27, 2012 at 02:20:23PM +0200, Peter Lieven wrote: > >>>>>>>> On 27.03.2012 12:00, Gleb Natapov wrote: > >>>>>>>>> On Tue, Mar 27, 2012 at 11:26:29AM +0200, Peter Lieven wrote: > >>>>>>>>>> On 27.03.2012 11:23, Vadim Rozenfeld wrote: > >>>>>>>>>>> On Tuesday, March 27, 2012 10:56:05 AM Gleb Natapov wrote: > >>>>>>>>>>>> On Mon, Mar 26, 2012 at 10:11:43PM +0200, Vadim Rozenfeld wrote: > >>>>>>>>>>>>> On Monday, March 26, 2012 08:54:50 PM Peter Lieven wrote: > >>>>>>>>>>>>>> On 26.03.2012 20:36, Vadim Rozenfeld wrote: > >>>>>>>>>>>>>>> On Monday, March 26, 2012 07:52:49 PM Gleb Natapov wrote: > >>>>>>>>>>>>>>>> On Mon, Mar 26, 2012 at 07:46:03PM +0200, Vadim Rozenfeld > >>> > >>> wrote: > >>>>>>>>>>>>>>>>> On Monday, March 26, 2012 07:00:32 PM Peter Lieven wrote: > >>>>>>>>>>>>>>>>>> On 22.03.2012 10:38, Vadim Rozenfeld wrote: > >>>>>>>>>>>>>>>>>>> On Thursday, March 22, 2012 10:52:42 AM Peter Lieven > > > > wrote: > >>>>>>>>>>>>>>>>>>>> On 22.03.2012 09:48, Vadim Rozenfeld wrote: > >>>>>>>>>>>>>>>>>>>>> On Thursday, March 22, 2012 09:53:45 AM Gleb Natapov > >>> > >>> wrote: > >>>>>>>>>>>>>>>>>>>>>> On Wed, Mar 21, 2012 at 06:31:02PM +0100, Peter > >>>>>>>>>>>>>>>>>>>>>> Lieven > >>> > >>> wrote: > >>>>>>>>>>>>>>>>>>>>>>> On 21.03.2012 12:10, David Cure wrote: > >>>>>>>>>>>>>>>>>>>>>>>> hello, > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> Le Tue, Mar 20, 2012 at 02:38:22PM +0200, Gleb > >>>>>>>>>>>>>>>>>>>>>>>> Natapov > >>>>>>>>>>> > >>>>>>>>>>> ecrivait : > >>>>>>>>>>>>>>>>>>>>>>>>> Try to add >>>>>>>>>>>>>>>>>>>>>>>>> name='hypervisor'/> to cpu definition in XML > >>>>>>>>>>>>>>>>>>>>>>>>> and check command line. > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> ok I try this but I can't use > >>>>>>>>>>>>>>>>>>>>>>>> to map the host cpu > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> (my libvirt is 0.9.8) so I use : > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> Opteron_G3 > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Re: Windows XP + Virtio
On Wednesday, May 02, 2012 02:33:49 AM Sean Kennedy wrote: > I am getting crashes (BSoD) when using Virtio for the disk driver in > Windows XP. > > It boots fine, it seems to run okay most of the time, but whenever the disk > begins to get taxed, 9 times out of 10 it will start locking up then > eventually crash with a BSoD about virtio.sys. Hi Sean, Can you tell me the bugcheck code and viostor version? Thank you, Vadim. > > Here is the environment: > > VM Host is a CentOS 6 server running qemu-kvm-0.12.1.2-2.209 with Kernel > version 2.6.32-220.13.1.el6.x86_64. It's a dual quad-core Xeon with 24 > gigs of ram. > > It's connected to backend storage via 2 gigabit ethernet connections. I > have created a raw 20gig LVM block device for this XP machine that is > exported over iSCSI. > > The VM Host is running device-mapper-multipath to utilize both ethernet > connections to the SAN. > > When I run a disk benchmark tool on the XP machine, the ICMP responses from > the box start going through the roof, and even drop off. It usually > bluescreens during the test. > > I have eliminated multipathd and setup the XP virt machine to just use the > iSCSI /dev/disk/by-id/ block directly, and it still behaves this way. > > If I set the machine to use IDE instead of Virtio, it's certainly slower, > but the machine never crashes and when running I/O benchmarks, pings stay > solid as they should, this is while still using multipathd and iSCSI to > the storage server. > > Have I setup virtio incorrectly? How would you go about finding the real > issue? > > Here is the virt machine's XML (using IDE for disk currently): > > > Apollo > d32041b8-853e-e679-edce-2b1f3db55e8a > 4194304 > 4194304 > 2 > > hvm > > > > > > > > > > > destroy > restart > restart > > /usr/libexec/qemu-kvm > > > > > > > > > > > > > > > > >function='0x1'/> > > > > > > >function='0x0'/> > > > > > > > > > > > > > > > > > > >function='0x0'/> > > >function='0x0'/> > > > > > Thanks, > Sean-- > 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: Windows XP + Virtio
On Wednesday, May 02, 2012 05:54:50 PM Sean Kennedy wrote: > On May 2, 2012, at 6:56 AM, Vadim Rozenfeld wrote: > > On Wednesday, May 02, 2012 02:33:49 AM Sean Kennedy wrote: > >> I am getting crashes (BSoD) when using Virtio for the disk driver in > >> Windows XP. > >> > >> It boots fine, it seems to run okay most of the time, but whenever the > >> disk begins to get taxed, 9 times out of 10 it will start locking up > >> then eventually crash with a BSoD about virtio.sys. > > > > Hi Sean, > > Can you tell me the bugcheck code and viostor version? > > Thank you, > > Vadim. > > I'm using virtio-win-0.1-22, it looks like viostor.sys is version > 02/13/2012,51.63.103.2200. > Could you please try the more recent one, available at http://people.redhat.com/vrozenfe/build-26/virtio-win-prewhql-0.1.zip ? > The BSoD is telling me 'IRQL_NOT_LESS_OR_EQUAL'. > > >> Here is the environment: > >> > >> VM Host is a CentOS 6 server running qemu-kvm-0.12.1.2-2.209 with Kernel > >> version 2.6.32-220.13.1.el6.x86_64. It's a dual quad-core Xeon with 24 > >> gigs of ram. > >> > >> It's connected to backend storage via 2 gigabit ethernet connections. I > >> have created a raw 20gig LVM block device for this XP machine that is > >> exported over iSCSI. > >> > >> The VM Host is running device-mapper-multipath to utilize both ethernet > >> connections to the SAN. > >> > >> When I run a disk benchmark tool on the XP machine, the ICMP responses > >> from the box start going through the roof, and even drop off. It > >> usually bluescreens during the test. > >> > >> I have eliminated multipathd and setup the XP virt machine to just use > >> the iSCSI /dev/disk/by-id/ block directly, and it still behaves this > >> way. > >> > >> If I set the machine to use IDE instead of Virtio, it's certainly > >> slower, but the machine never crashes and when running I/O benchmarks, > >> pings stay solid as they should, this is while still using multipathd > >> and iSCSI to the storage server. > >> > >> Have I setup virtio incorrectly? How would you go about finding the > >> real issue? > >> > >> Here is the virt machine's XML (using IDE for disk currently): > >> > >> > >> > >> Apollo > >> d32041b8-853e-e679-edce-2b1f3db55e8a > >> 4194304 > >> 4194304 > >> 2 > >> > >> > >>hvm > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> destroy > >> restart > >> restart > >> > >> > >>/usr/libexec/qemu-kvm > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> >> > >> function='0x1'/> > >> > >> > >> > >> > >> > >> > >> > >> > >> >> > >> function='0x0'/> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> >> > >> function='0x0'/> > >> > >> > >> > >> > >> >> > >> function='0x0'/> > >> > >> > >> > >> > >> > >> > >> Thanks, > >> Sean-- > >> To unsubscribe from this list: send the line "unsubscribe kvm" in > >> the body of a message to majord...@vger.kernel.org > >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > -- > > To unsubscribe from this list: send the line "unsubscribe kvm" in > > the body of a message to majord...@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Using KVM for Windows kernel debugging
On 08/18/2009 01:52 PM, Tom Parkin wrote: 2009/8/17 Tom Parkin: Thanks so much for that, Yan, it looks exactly like what I need. I'll give it a try when I'm back in the office. Having given it a try, I'm having some troubles which I hope someone may be able to assist with ? Here's my configuration : I have two Windows XP hosts running in two virtual machines[0]. One is set up as the "debugee" to export debugging information via. COM1, the other is set up as the "debugger" with the WinDBG kernel debugger installed. I have followed the instructions on the Wiki[1] for creating a virtual serial connection between the two VMs, and I am able to send messages between the two VMs using Hyperterm. However, I am unable to successfully establish a connection between the WinDBG debugger process and the debugee machine. The best I've managed so far is as follows : o Boot the debugger VM and start WinDBG o Boot the debugee VM o The debugee boots to the Windows bootloader screen. Immediately after that it appears to hang with a black screen, and it starts chewing CPU o Wait for a short time (~1-2min), after which the WinDBG process crashes on the debugger VM o Restart WinDBG and wait again for a short time (~1-2min). Again, WinDBG crashes o Restart WinDBG a third time. This time the debugger window shows "Kernel debugger connection established", although the window status bar still shows "Debugee not connected" Try to get MS symbols first. o Wait for some time (~5min), during which some further messages come up in the debugger. Eventually it seems to settle into a loop of "GetContextState failed" with the occasional "Unable to read KTHREAD address". Could be a timing issue. Probably host (WinDbg) and target are running out-of-sync. Try to add /break switch to boot.ini or bcdedit. And that appears to be that. I've left it to run for up to ~15 min, during which time the debugee VM window never comes out of the apparent black screen hang, and the debugee kvm process continues to chew CPU, pretty much pegging one of my cores at 100%. My questions: + The Wiki mentions a patch to the kvm-qemu sources[2]. Looking at the git tree it seems this change may be merged, so possibly this patch isn't required any more. Can anyone confirm this ? + Does anyone have a working Windows guest debugging setup working ? Could you share the details ? Of course, any suggestions on how to debug the entire configuration would be gratefully received ! Thanks, Tom [0]. I'm running ubuntu 9.04 with the distro-provided kvm package version "1:84+dfsg-0ubuntu12.3". I'm at somewhat of a loss to relate this to actual kvm-qemu releases... My kernel version is 2.6.28-14-generic. My cpu is a AMD Turion(tm)X2 Ultra DualCore Mobile ZM-86, and I'm running kvm_amd with the option "npt=0" to avoid kernel oopses when starting VM images. [1]. As provided by Yan previously; http://kvm.qumranet.com/kvmwiki/WindowsGuestDebug [2]. The link in the Wiki is for a private IP (10.0.0.1) but I think the patch is probably the same as the one referenced here: http://www.damogran.de/blog/archives/14-WinDbg-and-QEMU.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: Using KVM for Windows kernel debugging
On 08/18/2009 04:54 PM, Tom Parkin wrote: Hi Vadim, 2009/8/18 Vadim Rozenfeld: Try to download symbols first. Thanks for the tip, it gets me a bit closer -- although still not fully up and running ! With the symbols installed, and the windbg symbol path set, the windbg process doesn't exit, and does print "Connected to Windows XP ..." (although the window status bar still reports "Debuggee not connected"). did you try /break switch in boot.ini? However, other than that I have similar behavior as previously reported -- the target VM hangs on a black screen chewing CPU, and in time the windbg process starts reporting "GetContextState failed...". Furthermore, I tried using kd rather than windbg to attempt to connect to the target machine: kd and WinDbg use the same debug engine the only one difference is in user interface. However, kd is much faster. kd.exe -y -k I get different errors from kd: "Unable to read head of debugger data list, Win32 error 0n56" What is your guest OS? Are you sure you have correct symbols? If you don't need live debugging, you can set up your system to generate crash dump file and use it for post-mortem debugging session. Regards, Vadim Tom -- 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: Using KVM for Windows kernel debugging
On 08/19/2009 01:31 AM, duck wrote: I have never got this to work reliably. Occasionally I can get as far as making a debugger connection at boot-time, IIRC, but have never managed to use the deugger at all. You always seem to end up in some debugger-debuggee deadlock. It works. However, getting into debug session is real pain in the neck. Especially for the first time. I suspect that the serial link simulation is imperfect enough (lost interrupts and thus lost characters?) that you are out of luck for serial-link-based remote debugging, even though userland serial comms, e.g. using Hyperterm, seem to work fine. I was able to get debugging working, a year or two ago, under QEMU using the MIN_CYCLE_COUNT patch (I made a command line option called '-mcc' to allow this to be tuned at run-time) but IIRC this patch is irrelevant when KVM is used. Can anyone suggest a KVM patch which might help, even if it slows the debuggee VM down? Pity SoftICE got killed off :-) You could try http://www.sysersoft.com/ for a one-PC Windows kernel debugging solution. Seems to be a small Beijing software house which just sells on-line. Their product is not free, though there is a free trial. (I haven't tried it under KVM, though they advertise that it works under VxWxxx [censored]). Maybe we can use vm kd extensions project (http://www.nynaeve.net/?page_id=168) as a starting point and fit it into kvm. AFAIK, VmWare and Virtual Box have done it already. -- 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: Use thread debug register storage instead of kvm specific data
On 09/04/2009 08:04 PM, Brian Jackson wrote: On Friday 04 September 2009 11:08:51 am Andrew Theurer wrote: Brian Jackson wrote: On Friday 04 September 2009 09:48:17 am Andrew Theurer wrote: Still not idle=poll, it may shave off 0.2%. Won't this affect SMT in a negative way? (OK, I am not running SMT now, but eventually we will be) A long time ago, we tested P4's with HT, and a polling idle in one thread always negatively impacted performance in the sibling thread. FWIW, I did try idle=halt, and it was slightly worse. I did get a chance to try the latest qemu (master and next heads). I have been running into a problem with virtIO stor driver for windows on anything much newer than kvm-87. I compiled the driver from the new git tree, installed OK, but still had the same error. Finally, I removed the serial number feature in the virtio-blk in qemu, and I can now get the driver to work in Windows. What were the symptoms you were seeing (i.e. define "a problem"). Device manager reports "a problem code 10" occurred, and the driver cannot initialize. Yes! I was getting this after I moved from 0.10.6 to 0.11.0-rc1. Now I know how to fix it. Thank you. Thank you. Vadim Rozenfeld informed me: There is a sanity check in the code, which checks the I/O range and fails if is not equal to 40h. Resent virtio-blk devices have I/O range equal to 0x400 (serial number feature). So, out signed viostor driver will fail on the latest KVMs. This problem was fixed and committed to SVN some time ago. I assumed the fix was to the virtio windows driver, but I could not get the driver I compiled from latest git to work either (only on qemu-kvm-87). So, I just backed out the serial number feature in qemu, and it worked. FWIW, the linux virtio-blk driver never had a problem. There have been very few changes to the viostor windows git repo since it was opened. Unless it was done before they were open sourced. In any case, it doesn't seem to be working with what's publicly available, so I think maybe there is something missing internal to external. I don't believe it was merged to git yet. The signed viostor driver works with qemu-kvm-87 only, otherwise you need to remove SN from the virtio-blk code, or clip IO range to the original size. Cheers, Vadim. So, not really any good news on performance with latest qemu builds. Performance is slightly worse: qemu-kvm-87 user nice system irq softirq guest idle iowait 5.79 0.009.28 0.08 1.00 20.81 58.784.26 total busy: 36.97 qemu-kvm-88-905-g6025b2d (master) user nice system irq softirq guest idle iowait 6.57 0.00 10.86 0.08 1.02 21.35 55.904.21 total busy: 39.89 qemu-kvm-88-910-gbf8a05b (next) user nice system irq softirq guest idle iowait 6.60 0.00 10.91 0.09 1.03 21.35 55.714.31 total busy: 39.98 diff of profiles, p1=qemu-kvm-87, p2=qemu-master 18x more samples for gfn_to_memslot_unali*, 37x for emulator_read_emula*, and more CPU time in guest mode. One other thing I decided to try was some cpu binding. I know this is not practical for production, but I wanted to see if there's any benefit at all. One reason was that a coworker here tried binding the qemu thread for the vcpu and the qemu IO thread to the same cpu. On a networking test, guest->local-host, throughput was up about 2x. Obviously there was a nice effect of being on the same cache. I wondered, even without full bore throughput tests, could we see any benefit here. So, I bound each pair of VMs to a dedicated core. What I saw was about a 6% improvement in performance. For a system which has pretty incredible memory performance and is not that busy, I was surprised that I got 6%. I am not advocating binding, but what I do wonder: on 1-way VMs, if we keep all the qemu threads together on the same CPU, but still allowing the scheduler to move them (all of them at once) to different cpus over time, would we see the same benefit? One other thing: So far I have not been using preadv/pwritev. I assume I need a more recent glibc (on 2.5 now) for qemu to take advantage of this? Getting p(read|write)v working almost doubled my virtio-net throughput in a Linux guest. Not quite as much in Windows guests. Yes you need glibc-2.10. I think some distros might have backported it to 2.9. You will also need some support for it in your system includes. Thanks, I will try a newer glibc, or maybe just move to a newer Linux installation which happens to have a newer glic. Fwiw... In Debian, I had to get glibc from the experimental tree. So some distros might not even have it. -Andrew -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo
[PATCH] viostor driver. Code cleanup. Getting rid of the Registry stuff.
repository: /home/vadimr/shares/kvm-guest-drivers-windows
branch: master
commit c3c87da57dae49911b0634022f8c8eb71cdd2df2
Author: Vadim Rozenfeld
Date: Mon Sep 21 22:05:51 2009 +0300
[PATCH] viostor driver.
Code cleanup. Getting rid of the Registry stuff.
Signed-off-by: Vadim Rozenfeld
diff --git a/viostor/virtio_stor.c b/viostor/virtio_stor.c
index d528ca9..e4acaa0 100644
--- a/viostor/virtio_stor.c
+++ b/viostor/virtio_stor.c
@@ -19,13 +19,6 @@
ULONG RhelDbgLevel = TRACE_LEVEL_NONE;
BOOLEAN IsCrashDumpMode;
-UNICODE_STRING ViostorServicePathUnicode =
-RTL_CONSTANT_STRING(VIOSTOR_SERVICE_NAME);
-
-UNICODE_STRING MaxTransferSizeUnicode =
-RTL_CONSTANT_STRING(MAX_TRANSFER_SIZE);
-
-
BOOLEAN
VirtIoHwInitialize(
IN PVOID DeviceExtension
@@ -98,12 +91,6 @@ CompleteSRB(
IN PSCSI_REQUEST_BLOCK Srb
);
-BOOLEAN
-GetMaxTransferSize(
-IN PVOID DeviceExtension
-);
-
-
ULONG
DriverEntry(
IN PVOID DriverObject,
@@ -292,32 +279,16 @@ VirtIoFindAdapter(
vq_sz = (sizeof(struct vring_virtqueue) + sizeof(PVOID) * pageNum);
if(adaptExt->dump_mode) {
-adaptExt->breaks_number = 8;
-adaptExt->queue_depth = 4;
+ConfigInfo->NumberOfPhysicalBreaks = 8;
} else {
-if(GetMaxTransferSize(DeviceExtension)) {
- adaptExt->breaks_number = (adaptExt->transfer_size / 4);
- if(pageNum <= (adaptExt->breaks_number * 4)) {
- adaptExt->breaks_number = (pageNum / 4);
- }
- adaptExt->breaks_number = min(adaptExt->breaks_number, 64);
- adaptExt->breaks_number = max(adaptExt->breaks_number, 1);
- adaptExt->queue_depth = (pageNum / adaptExt->breaks_number) - 1;
- adaptExt->queue_depth = max(adaptExt->queue_depth, 1);
-} else {
- adaptExt->breaks_number = (pageNum / 2);
- adaptExt->breaks_number = min(adaptExt->breaks_number, 8);
- adaptExt->breaks_number = max(adaptExt->breaks_number, 1);
- adaptExt->queue_depth = 4;
-}
+ConfigInfo->NumberOfPhysicalBreaks = 16;
}
-ConfigInfo->NumberOfPhysicalBreaks = adaptExt->breaks_number;
-ConfigInfo->MaximumTransferLength
-= ConfigInfo->NumberOfPhysicalBreaks * PAGE_SIZE;
+ConfigInfo->MaximumTransferLength = ConfigInfo->NumberOfPhysicalBreaks *
PAGE_SIZE;
+adaptExt->queue_depth = pageNum / ConfigInfo->NumberOfPhysicalBreaks - 1;
RhelDbgPrint(TRACE_LEVEL_INFORMATION, ("breaks_number = %x queue_depth =
%x\n",
-adaptExt->breaks_number,
+ConfigInfo->NumberOfPhysicalBreaks,
adaptExt->queue_depth));
ptr = (ULONG_PTR)ScsiPortGetUncachedExtension(DeviceExtension, ConfigInfo,
(PAGE_SIZE + vr_sz + vq_sz));
@@ -1000,67 +971,3 @@ CompleteSRB(
Srb->Lun);
#endif
}
-
-BOOLEAN
-GetMaxTransferSize(
-IN PVOID DeviceExtension
-)
-{
-
-NTSTATUS status;
-OBJECT_ATTRIBUTES oa;
-HANDLEkeyHandle;
-RHEL_ULONG_VALUE_PARTIAL_INFO ulongValueInfo;
-ULONG ulongValueLength;
-PADAPTER_EXTENSIONadaptExt;
-
-adaptExt = (PADAPTER_EXTENSION)DeviceExtension;
-
-InitializeObjectAttributes(&oa,
- &ViostorServicePathUnicode,
- OBJ_CASE_INSENSITIVE,
- NULL,
- NULL);
-
-status = ZwOpenKey(&keyHandle,
- KEY_READ,
- &oa);
-
-if (!NT_SUCCESS(status)) {
-RhelDbgPrint(TRACE_LEVEL_ERROR,
- ("ReadRegistryValues: Failed to open services key!
0x%x\n",
- status));
-return FALSE;
-}
-
-status = ZwQueryValueKey(keyHandle,
- &MaxTransferSizeUnicode,
- KeyValuePartialInformation,
- &ulongValueInfo,
- sizeof(ulongValueInfo),
- &ulongValueLength);
-
-if (!NT_SUCCESS(status)) {
-RhelDbgPrint(TRACE_LEVEL_ERROR,
- ("ReadRegistryValues: Failed to query %wZ value! 0x%x\n",
- &MaxTransferSizeUnicode, status));
-ZwClose(keyHandle);
-return FALSE;
-}
-
-ASSERT(ulongValueInfo.PartialInfo.Type == REG_SZ);
-
-switch(*ulongValueInfo.PartialInfo.Data) {
-case '0' : adaptExt->transfer_size = 64; break;
-case '1' : adaptExt->transfer_size = 128; break;
-case '2' : adapt
Re: Binary Windows guest drivers are released
On 09/25/2009 12:07 AM, Dor Laor wrote: On 09/24/2009 11:59 PM, Javier Guerra wrote: On Thu, Sep 24, 2009 at 3:38 PM, Kenni Lund wrote: I've done some benchmarking with the drivers on Windows XP SP3 32bit, but it seems like using the VirtIO drivers are slower than the IDE drivers in (almost) all cases. Perhaps I've missed something or does the driver still need optimization? very interesting! it seems that IDE wins on all the performance numbers, but VirtIO always has lower CPU utilization. i guess this is guest CPU %, right? it would also be interesting to compare the CPU usage from the host point of view, since a lower 'off-guest' CPU usage is very important for scaling to many guests doing I/O. Can you re-try it with setting the host ioscheduler to deadline? Virtio backend (thread pool) is sensitive for it. These drivers are mainly tweaked for win2k3 and win2k8. We once had queue depth settings in the driver, not sure we still have it, Vadim, can you add more info? Also virtio should provide IO parallelism as opposed to IDE. I don't think your test test it. Virtio can provide more virtual drives than the max 4 that ide offers. Dor Windows XP 32-bit virtio block driver was created from our mainline code almost for fun. Not like our mainline code, which is STORPORT oriented, it is a SCSIPORT () mini-port driver. SCSIPORT has never been known as I/O optimized storage stack. SCSIPORT architecture is almost dead officially. Windows XP 32-bit has no support for STORPORT or virtual storage stack. Developing monolithic disk driver, which will sit right on top of virtio-blk PCI device, looks like the one way to have some kind of high throughput storage for Windows XP 32-bit. Regards, Vadim. -- 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: Binary Windows guest drivers are released
On 09/25/2009 10:53 AM, Kenni Lund wrote: 2009/9/25 Vadim Rozenfeld: On 09/25/2009 12:07 AM, Dor Laor wrote: On 09/24/2009 11:59 PM, Javier Guerra wrote: On Thu, Sep 24, 2009 at 3:38 PM, Kenni Lundwrote: I've done some benchmarking with the drivers on Windows XP SP3 32bit, but it seems like using the VirtIO drivers are slower than the IDE drivers in (almost) all cases. Perhaps I've missed something or does the driver still need optimization? very interesting! it seems that IDE wins on all the performance numbers, but VirtIO always has lower CPU utilization. i guess this is guest CPU %, right? it would also be interesting to compare the CPU usage from the host point of view, since a lower 'off-guest' CPU usage is very important for scaling to many guests doing I/O. These drivers are mainly tweaked for win2k3 and win2k8. We once had queue depth settings in the driver, not sure we still have it, Vadim, can you add more info? Dor Windows XP 32-bit virtio block driver was created from our mainline code almost for fun. Not like our mainline code, which is STORPORT oriented, it is a SCSIPORT () mini-port driver. SCSIPORT has never been known as I/O optimized storage stack. SCSIPORT architecture is almost dead officially. Windows XP 32-bit has no support for STORPORT or virtual storage stack. Ok, in that case, wouldn't it be better simply not to build the XP driver and instead put a note somewhere (in the wiki?), saying that it doesn't make sense to use VirtIO on XP due to these reasons? I have no idea what was the reason for building and announcing XP 32bit driver. I mean, technically it is possible. You can also expect less CPU consumption by switching to SCSIPORT virtio driver. But please don't expect any significant performance burst. Developing monolithic disk driver, which will sit right on top of virtio-blk PCI device, looks like the one way to have some kind of high throughput storage for Windows XP 32-bit. Ok, since these drivers are targeted Windows Server and XP is getting old, I suppose no efforts will be put into developing such driver, or? I don't know, but why not? It shouldn't be too complicated. Best Regards, Kenni -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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: Freezing Windows 2008 x64bit guest
On Mon, 2010-12-13 at 22:12 +0200, Dor Laor wrote: > On 12/13/2010 09:42 PM, Manfred Heubach wrote: > > > > > > Gleb Natapov redhat.com> writes: > > > >> > >> On Wed, Jul 28, 2010 at 12:53:02AM +0300, Harri Olin wrote: > >>> Gleb Natapov wrote: > On Wed, Jul 21, 2010 at 09:25:31AM +0300, Harri Olin wrote: > > Gleb Natapov kirjoitti: > >> On Mon, Jul 19, 2010 at 10:17:02AM +0300, Harri Olin wrote: > >>> Gleb Natapov kirjoitti: > On Thu, Jul 15, 2010 at 03:19:44PM +0200, Christoph Adomeit wrote: > > But one Windows 2008 64 Bit Server Standard is freezing regularly. > > This happens sometimes 3 times a day, sometimes it takes 2 days > > until freeze. The Windows Machine is a clean fresh install. > >>> I think I have seen same problem occur on my Windows 2008 SBS SP2 > >>> 64bit system, but a bit less often, only like once a week. > >>> Now I haven't seen crashes but only freezes with qemu on 100% and > >>> virtual system unresponsive. > Does sendkey from monitor works? qemu-kvm-0.11.1 is very old and this is > not total freeze which even harder to debug. I don't see anything > extraordinary in your logs. 4643 interrupt per second for 4 cpus is > normal if windows runs multimedia or other app that need hi-res timers. > Does your host swapping? Is there any chance that you can try upstream > > qemu-kvm? > >>> > >>> I tried running qemu-kvm from git but it exhibited the same problem > >>> as 12.x that I tried before, BSODing once in a while, running kernel > >>> 2.6.34.1. > >>> > >> That should be pretty stable config, although it would be nice if you > >> could try running in qemy-kvm.git head. > >> > >>> sample BSOD failure details: > >>> These two with Realtec nic and qemu cpu > >>> 0x0019 (0x0020, 0xf88007e65970, > >>> 0xf88007e65990, 0x0502040f) > >>> 0x0019 (0x0020, 0xf88007a414c0, > >>> 0xf88007a414e0, 0x0502044c) > >>> > >>> These are with e1000 and -cpu host > >>> 0x003b (0xc005, 0xf80001c5d842, > >>> 0xfa60093ddb70, 0x) > >>> 0x003b (0xc005, 0xf80001cb8842, > >>> 0xfa600c94ab70, 0x) > >>> 0x000a (0x0080, 0x000c, > >>> 0x0001, 0xf80001cadefd) > >>> > >> Can you attach screenshots of BSODs? Have you reinstalled your guests or > >> are you running the same images you ran in 11.x? > >> > >>> I'll see if I can analyze minidumps later. > >>> > >>> In addition to these there have been as many reboots that have been > >>> only logged as 'disruptive shutdown'. > >>> > >>> Right now I'm running the problematic guest under Xen > >>> 3.2.1-something from Debian to see if it works better. > >>> > >>> -- > >>> Harri. > >> > > Hello, > > > > is there a solution for that problem? I'm experiencing the same problems > > ever > > since I installed SBS 2008 on KVM. > > > > I was running the host with Ubuntu 10.04 but upgraded to 10.10 - mainly > > because > > of performance problems which were solved by the upgrade. > > > > After the upgrade the system became extremly unstable. It was crashing as > > soon > > as disk io and network io load was growing. 100% reproduceable with windows > > server backup to an iscsi volume. > > > > i had virtio drivers for storage and network installed (redhat/fedora > > 1.1.11). > > Which fedora/rhel release is that? > What's the windows virtio driver version? > > Have you tried using virt-manager/virhs instead of raw cmdline? > About e1000, some windows comes with buggy driver and an update e1000 > from Intel fixes some issues. > > > > At each BSOD I had the following line in the log of the guest: > > > > virtio_ioport_write: unexpected address 0x13 value 0x1 > > > > I changed the network interface back to e1000. What I experience now (and I > > had > > that a the very beginning before i switched to virtio network) are freezes. > > The > > guest doesn't respond anymore (doesn't answer to pings and doesn't interact > > via > > mouse/keyboard anymore). Host CPU usage of the kvm process is 100% on as > > many > > cores as there are virtual cpus (in this case 4). > > Sounds like an interrupt storm to me. Can you try to ping your VM? Anyway the best way to start debugging a stalled system is just to crash it with BSOD. For doing it you will need: - enable NMICrashDump (please see http://support.microsoft.com/kb/927069 for more information - enable Kernel Memory Dump (actually Complete is much better, but it can be too big) http://support.microsoft.com/kb/969028 - you only will need to type "nmi 0" in the qemu monitor to crash the system, when the system hangs next time. Best regards, Vadim. > > I'm a bit frustrated about this. I have 2 windows 2003 32bit, 1 windows xp > > and 3 > > linux guests (2x 32bit, 1x64 bit). They are all running without any problems > > (except that the windows xp guest cann
Re: AW: Freezing Windows 2008 x64bit guest
On Wed, 2010-12-15 at 00:57 +0100, Manfred Heubach wrote: > Vadim Rozenfeld redhat.com> writes: > > > > > On Mon, 2010-12-13 at 22:12 +0200, Dor Laor wrote: > > > On 12/13/2010 09:42 PM, Manfred Heubach wrote: > > > > > > > > I was running the host with Ubuntu 10.04 but upgraded to 10.10 - mainly > because > > > > of performance problems which were solved by the upgrade. > > > > > > > > After the upgrade the system became extremly unstable. It was crashing > > > > as soon > > > > as disk io and network io load was growing. 100% reproduceable with > > > > windows > > > > server backup to an iscsi volume. > > > > > > > > i had virtio drivers for storage and network installed (redhat/fedora > > > > 1.1.11). > > > > > > Which fedora/rhel release is that? > > > The host is Ubuntu 10.10 x64 > > The drivers are from > http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/ 1.1.11-0 > released on 17-Aug-2010 - are there any newer drivers? Yes, they are the most recent drivers at fedoraproject. Our rhel6 drivers are almost the same, except for a few non-critical, WHQL related bug fixes. However, there is one fix related to Large Send Offload (LSO) problem which was fixed in rhel6, but I don't see the relevant changes in fedora kvmnet driver sources http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/src/ > > > > > What's the windows virtio driver version? > > The virtio storage version shown in Windows is 6.0.0.10 > > > > > > > Have you tried using virt-manager/virhs instead of raw cmdline? > > I'm starting it with libvirt/virsh > > cmd-line copied from the log (and some log entries): > > LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin > QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-0.12 -enable-kvm -m 8192 -smp > 4,sockets=4,cores=1,threads=1 -name sbs2008 -uuid > 933c2ef2-e5b0-0b39-db60-016b5d226534 -nodefaults -chardev > socket,id=monitor,path=/var/lib/libvirt/qemu/sbs2008.monitor,server,nowait > -mon > chardev=monitor,mode=readline -rtc base=localtime -boot c -drive > file=/var/lib/libvirt/images/olscanner/virtio-win-1.1.11-0.iso,if=none,media=cdrom, > id=drive-ide0-1-0,readonly=on,format=raw > -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -drive > file=/var/lib/libvirt/images/sbs2008/sbs2008.img,if=none,id=drive-virtio-disk0, > boot=on,format=qcow2 -device > virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 > -drive > file=/dev/volg1/sbsdata,if=none,id=drive-virtio-disk1,format=raw,cache=none > -device > virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk1,id=virtio-disk1 > -drive > file=/dev/volg1/wsus,if=none,id=drive-virtio-disk2,format=raw,cache=none > -device > virtio-blk-pci,bus=pci.0,addr=0x7,drive=drive-virtio-disk2,id=virtio-disk2 > -device e1000,vlan=0,id=net0,mac=52:54:00:8a:bc:c9,bus=pci.0,addr=0x6 -net > tap,fd=107,vlan=0,name=hostnet0 -chardev pty,id=serial0 -device > isa-serial,chardev=serial0 -usb -device usb-tablet,id=input0 -vnc 0.0.0.0:0 -k > de -vga std -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 > 07:12:02.715: debug : qemudInitCpuAffinity:2423 : Setting CPU affinity > 07:12:02.717: debug : qemuSecurityDACSetProcessLabel:547 : Dropping privileges > of VM to 105:114 > char device redirected to /dev/pts/0 > pci_add_option_rom: failed to find romfile "pxe-e1000.bin" > > > > > About e1000, some windows comes with buggy driver and an update e1000 > > > from Intel fixes some issues. > > > > > I'm running latest drivers from Intel: 8.3.15.0 > > > > > > > > At each BSOD I had the following line in the log of the guest: > > > > > > > > virtio_ioport_write: unexpected address 0x13 value 0x1 Seems to be the result of calling PapaNdis_OnBugCheck function > > > > > > > > I changed the network interface back to e1000. What I experience now > > > > (and > I had > > > > that a the very beginning before i switched to virtio network) are > freezes. The > > > > guest doesn't respond anymore (doesn't answer to pings and doesn't > interact via > > > > mouse/keyboard anymore). Host CPU usage of the kvm process is 100% on > > > > as many > > > > cores as there are virtual cpus (in this case 4). > > I had a crash today but no logentry on the host - but that could be because I > had to restart syslog (ran out of diskspace after turning on debug logging ob > libvirtd - didn'
Re: KVM, Entropy and Windows
On Thu, 2011-02-17 at 11:11 +0200, Avi Kivity wrote: > On 02/16/2011 09:54 PM, --[ UxBoD ]-- wrote: > > Hello all, > > > > I believe I am hitting a problem on one of our Windows 2003 KVM guests were > > I believe it is running out of Entropy and causing SSL issues. > > > > I see that there is a module called virtio-rng which I believe passes the > > HW entropy source through to the guest but does this work on Windows > > as-well ? > > > > AFAIK there is no Windows driver for virtio-rng. Seems like a good > idea. Vadim? virtio-rng driver for windows is not a big deal. IMO, the real problem will be to force Windows to use for CriptoApi. > > > If it doesn't any ideas on how I can increase the amount of entropy being > > generated on a headless system ? or even monitor entropy on a Windows > > system ? > > No idea. Maybe you could ask Windows to collect entropy from packet > timings. > -- 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, Entropy and Windows
On Thu, 2011-02-17 at 12:37 +0200, Dor Laor wrote: > On 02/17/2011 12:09 PM, Vadim Rozenfeld wrote: > > On Thu, 2011-02-17 at 11:11 +0200, Avi Kivity wrote: > >> On 02/16/2011 09:54 PM, --[ UxBoD ]-- wrote: > >>> Hello all, > >>> > >>> I believe I am hitting a problem on one of our Windows 2003 KVM guests > >>> were I believe it is running out of Entropy and causing SSL issues. > >>> > >>> I see that there is a module called virtio-rng which I believe passes the > >>> HW entropy source through to the guest but does this work on Windows > >>> as-well ? > >>> > >> > >> AFAIK there is no Windows driver for virtio-rng. Seems like a good > >> idea. Vadim? > > virtio-rng driver for windows is not a big deal. IMO, the real problem > > will be to force Windows to use for CriptoApi. > > What's the implication of it? good or bad? iirc, Vista and higher use a new generation of cryptography API. CriptoApi can be integrated with smart cards sub-system. If we can make Windows virtio-rng driver to be attachable to smart cart devstack, I think we can solve the problem. > Do you know what hyper-v is doing for it? > No idea. > >> > >>> If it doesn't any ideas on how I can increase the amount of entropy being > >>> generated on a headless system ? or even monitor entropy on a Windows > >>> system ? > >> > >> No idea. Maybe you could ask Windows to collect entropy from packet > >> timings. > >> > > > > > > -- > > 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: RFH: Windos 7 64 + VirtIO stalls during installation / crashed with qcow2
On Thu, 2011-02-17 at 13:41 +0200, Gleb Natapov wrote: > On Thu, Feb 17, 2011 at 11:30:25AM +, Stefan Hajnoczi wrote: > > On Thu, Feb 17, 2011 at 10:44 AM, Philipp Hahn wrote: > > > Hello, > > > > > > I tried to install Windows 7 Professional 64 Bit with VirtIO 1.16 on an > > > Debian > > > based system using AMD64 CPUs. During the install, the system froze > > > (progress > > > bar didn't advance) and kvm was slowly eating CPU cycles on the host. > > > > > > $ dpkg-query -W libvirt0 qemu-kvm linux-image-`uname -r` > > > libvirt00.8.7-1.48.201102031226 > > > linux-image-2.6.32-ucs37-amd64 2.6.32-30.37.201102031101 > > > qemu-kvm0.12.4+dfsg-1~bpo50+1.3.201010011432 > > > > > > It was started using virsh, which generated the following command line: > > > /usr/bin/kvm.bin -S \ > > > -M pc-0.12 \ > > > -enable-kvm \ > > > -m 768 \ > > > -smp 1,sockets=1,cores=1,threads=1 \ > > > -name 7-Professional_amd64 \ > > > -uuid 89c82cf9-0797-3da4-62f4-8767e4f59b7e \ > > > -nodefaults \ > > > -chardev > > > socket,id=monitor,path=/var/lib/libvirt/qemu/7-Professional_amd64.monitor,server,nowait > > > \ > > > -mon chardev=monitor,mode=readline \ > > > -rtc base=utc \ > > > -boot dc \ > > > -drive > > > file=/var/lib/libvirt/images/7-Professional_amd64.qcow2,if=none,id=drive-virtio-disk0,boot=on,format=qcow2 > > > -device > > > virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0 > > > \ > > > -drive > > > file=/mnt/omar/vmwares/kvm/iso/windows/win_7_pro_64bit.iso,if=none,media=cdrom,id=drive-ide0-0-1,readonly=on,format=raw > > > -device ide-drive,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 \ > > > -drive > > > file=/mnt/omar/vmwares/kvm/iso/others/virtio-win-1.1.16.iso,if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw > > > -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 \ > > > -device > > > virtio-net-pci,vlan=0,id=net0,mac=52:54:00:f7:da:b5,bus=pci.0,addr=0x3 > > > \ > > > -net tap,fd=20,vlan=0,name=hostnet0 \ > > > -usb \ > > > -device usb-tablet,id=input0 \ > > > -vnc 0.0.0.0:0 \ > > > -k de \ > > > -vga cirrus \ > > > -incoming exec:cat \ > > > -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 \ > > > -no-kvm-irqchip > > > > > > The "-no-kvm-irqchip"-Option was added, because we experienced > > > shutdown/resume > > > problems with other machines, which either received no interrupts anymore > > > or > > > where caught in their interrupt service routine, never being able to > > > acknowledge the interrupts. Adding that option solved that problem, but > > > might > > > be causing other problems now. > > > > > > Using gdb I was able to track down Windows hanging in the following > > > routine, > > > which look like some spin-lock / semaphore aquire() implementation: > > > (gdb) x/20i 0xf8000c485a80 > > > 0xf8000c485a80: mov%rbx,0x8(%rsp) > > > 0xf8000c485a85: push %rdi > > > 0xf8000c485a86: sub$0x20,%rsp > > > 0xf8000c485a8a: mov%rcx,%rdi > > > 0xf8000c485a8d: xor%ebx,%ebx > > > 0xf8000c485a8f: nop > > > 0xf8000c485a90: inc%ebx > > > 0xf8000c485a92: test %ebx,0x274834(%rip)# > > > 0xf8000c6fa2cc > > > 0xf8000c485a98: je 0xf8000c48adad > > > 0xf8000c485a9e: pause > > > 0xf8000c485aa0: mov(%rdi),%rcx > > > 0xf8000c485aa3: test %rcx,%rcx > > > 0xf8000c485aa6: jne0xf8000c485a90 > > > 0xf8000c485aa8: lock btsq $0x0,(%rdi) > > > 0xf8000c485aae: jb 0xf8000c485a90 > > > 0xf8000c485ab0: mov%ebx,%eax > > > 0xf8000c485ab2: mov0x30(%rsp),%rbx > > > 0xf8000c485ab7: add$0x20,%rsp > > > 0xf8000c485abb: pop%rdi > > > 0xf8000c485abc: retq > > > (gdb) x/w 0xf8000c6fa2cc > > > 0xf8000c6fa2cc: 0x > > > (gdb) x/w $rdi > > > 0xfa800131f600: 0x0001 > > > > > > Did someone experience similar problems or does somebody know if there > > > was a > > > fix for such a problem in newer kvm- or Linux-kernel versions? > > > > > > We also encountered problems with some Windows Versions when using VirtIO > > > with > > > Qcow2 images, which were using backing-files for copy-on-write: they just > > > crashed with a blue-screen. Just changing from the CoW-qcow2 to the > > > master-qcow2 file "fixed" the problem, but this isn't satisfactory, since > > > we > > > would like to use the CoW-functionality. Not using VirtIO also fixed the > > > problem, but has performance penalties. > > > > Vadim: Any suggestions for extracting more relevant information in these > > cases? Debugging installation-phase problems on 64-bit platforms is a very complicated thing. If the problem is reproducible on x86 platforms, you can try printing messages (RhelDbgPrint function) to localize the problem. You will need to adjust RhelDbgLevel in virtio_stor.c and build checked (debug)
Re: RFH: Windos 7 64 + VirtIO stalls during installation / crashed with qcow2
On Thu, 2011-02-17 at 14:26 +, Stefan Hajnoczi wrote: > On Thu, Feb 17, 2011 at 12:45 PM, Vadim Rozenfeld wrote: > > On Thu, 2011-02-17 at 13:41 +0200, Gleb Natapov wrote: > >> On Thu, Feb 17, 2011 at 11:30:25AM +, Stefan Hajnoczi wrote: > >> > On Thu, Feb 17, 2011 at 10:44 AM, Philipp Hahn > >> > wrote: > >> > > Hello, > >> > > > >> > > I tried to install Windows 7 Professional 64 Bit with VirtIO 1.16 on > >> > > an Debian > >> > > based system using AMD64 CPUs. During the install, the system froze > >> > > (progress > >> > > bar didn't advance) and kvm was slowly eating CPU cycles on the host. > >> > > > >> > > $ dpkg-query -W libvirt0 qemu-kvm linux-image-`uname -r` > >> > > libvirt00.8.7-1.48.201102031226 > >> > > linux-image-2.6.32-ucs37-amd64 2.6.32-30.37.201102031101 > >> > > qemu-kvm0.12.4+dfsg-1~bpo50+1.3.201010011432 > >> > > > >> > > It was started using virsh, which generated the following command line: > >> > > /usr/bin/kvm.bin -S \ > >> > > -M pc-0.12 \ > >> > > -enable-kvm \ > >> > > -m 768 \ > >> > > -smp 1,sockets=1,cores=1,threads=1 \ > >> > > -name 7-Professional_amd64 \ > >> > > -uuid 89c82cf9-0797-3da4-62f4-8767e4f59b7e \ > >> > > -nodefaults \ > >> > > -chardev > >> > > socket,id=monitor,path=/var/lib/libvirt/qemu/7-Professional_amd64.monitor,server,nowait > >> > > \ > >> > > -mon chardev=monitor,mode=readline \ > >> > > -rtc base=utc \ > >> > > -boot dc \ > >> > > -drive > >> > > file=/var/lib/libvirt/images/7-Professional_amd64.qcow2,if=none,id=drive-virtio-disk0,boot=on,format=qcow2 > >> > > -device > >> > > virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0 > >> > > \ > >> > > -drive > >> > > file=/mnt/omar/vmwares/kvm/iso/windows/win_7_pro_64bit.iso,if=none,media=cdrom,id=drive-ide0-0-1,readonly=on,format=raw > >> > > -device ide-drive,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 \ > >> > > -drive > >> > > file=/mnt/omar/vmwares/kvm/iso/others/virtio-win-1.1.16.iso,if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw > >> > > -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 \ > >> > > -device > >> > > virtio-net-pci,vlan=0,id=net0,mac=52:54:00:f7:da:b5,bus=pci.0,addr=0x3 > >> > > \ > >> > > -net tap,fd=20,vlan=0,name=hostnet0 \ > >> > > -usb \ > >> > > -device usb-tablet,id=input0 \ > >> > > -vnc 0.0.0.0:0 \ > >> > > -k de \ > >> > > -vga cirrus \ > >> > > -incoming exec:cat \ > >> > > -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 \ > >> > > -no-kvm-irqchip > >> > > > >> > > The "-no-kvm-irqchip"-Option was added, because we experienced > >> > > shutdown/resume > >> > > problems with other machines, which either received no interrupts > >> > > anymore or > >> > > where caught in their interrupt service routine, never being able to > >> > > acknowledge the interrupts. Adding that option solved that problem, > >> > > but might > >> > > be causing other problems now. > >> > > > >> > > Using gdb I was able to track down Windows hanging in the following > >> > > routine, > >> > > which look like some spin-lock / semaphore aquire() implementation: > >> > > (gdb) x/20i 0xf8000c485a80 > >> > > 0xf8000c485a80: mov%rbx,0x8(%rsp) > >> > > 0xf8000c485a85: push %rdi > >> > > 0xf8000c485a86: sub$0x20,%rsp > >> > > 0xf8000c485a8a: mov%rcx,%rdi > >> > > 0xf8000c485a8d: xor%ebx,%ebx > >> > > 0xf8000c485a8f: nop > >> > > 0xf8000c485a90: inc%ebx > >> > > 0xf8000c485a92: test %ebx,0x274834(%rip)# > >> > > 0xf8000c6fa2cc > >> > > 0xf8000c485a98: je 0xf8000c48adad > >> > > 0xf8000c485a9e: pause > >> > > 0xf8000c485aa0: mov(%rdi),%rcx > >&
Re: RFH: Windos 7 64 + VirtIO stalls during installation / crashed with qcow2
On Thu, 2011-02-17 at 16:27 +0100, Philipp Hahn wrote: > Hello, > > Am Donnerstag 17 Februar 2011 13:45:34 schrieb Vadim Rozenfeld: > > On Thu, 2011-02-17 at 13:41 +0200, Gleb Natapov wrote: > > > Why is is linked to virtio? Does install on ide work? > > Yes, works without the VirtIO block driver using IDE. > > > > Does install work > > > without -no-kvm-irqchip (which had pretty serious problem till now)? > > > Adding -no-kvm-irqchip usually does not solve problems, but just > > > exchange one set of bugs to the other (and reduces performance > > > drastically). > > I'll try again without -no-kvm-irqchip, newer KVM and newer Kernel, but last > time I tested kvm-0.13 and Linux-2.6.37 with the same results, see > <http://article.gmane.org/gmane.comp.emulators.kvm.devel/66069> > > > Does it work on Win7-32? :) > > I also had problems with Windows XP 32Bit: Installation taking more than 20 > minutes with no noticeable progress, also VirtIO (probably an older version, > I don't have that instance any more) Could you please try "cache=writethrough" on virtio drive? Best regards, Vadim > > BYtE > Philipp -- 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: [COMMIT] [WIN-GUEST-DRIVERS] Balloon - remove WMI usage. Remove wmi.c.
On Sat, 2011-03-19 at 11:28 +0800, ya su wrote: > Yan: > > I have tested the newest balloon driver (from 1.1.16) on windows > server 2003, balloon.sys can not be installed successfully and return > error code 10. have you tested this or any updates? thanks. It has been WHQL tested and signed by MS. code 10 usually indicates a resources allocation problem. Vadim. -- 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: [COMMIT] [WIN-GUEST-DRIVERS] Balloon - remove WMI usage. Remove wmi.c.
On Tue, 2011-03-22 at 06:06 -0400, Yan Vugenfirer wrote:
> Hello Vadim,
>
> Can you check this issues?
>
http://www.mail-archive.com/kvm@vger.kernel.org/msg51061.html
> Thanks,
> Yan.
>
> > -Original Message-
> > From: ya su [mailto:suya94...@gmail.com]
> > Sent: Saturday, March 19, 2011 5:28 AM
> > To: Yan Vugenfirer
> > Cc: kvm@vger.kernel.org
> > Subject: Re: [COMMIT] [WIN-GUEST-DRIVERS] Balloon - remove WMI usage.
> > Remove wmi.c.
> >
> > Yan:
> >
> > I have tested the newest balloon driver (from 1.1.16) on windows
> > server 2003, balloon.sys can not be installed successfully and return
> > error code 10. have you tested this or any updates? thanks.
> >
> > Regards.
> >
> > Green.
> >
> >
> > 2010/2/15 Yan Vugenfirer :
> > > repository: C:/dev/kvm-guest-drivers-windows
> > > branch: master
> > > commit 7ab588f373eda9d08a497e969739019d2075a6d2
> > > Author: Yan Vugenfirer
> > > Date: Mon Feb 15 15:01:36 2010 +0200
> > >
> > >[WIN-GUEST-DRIVERS] Balloon - remove WMI usage. Remove wmi.c.
> > >
> > >Signed-off-by: Vadim Rozenfeld
> > >
> > > diff --git a/Balloon/BalloonWDF/wmi.c b/Balloon/BalloonWDF/wmi.c
> > > deleted file mode 100644
> > > index 70a9270..000
> > > --- a/Balloon/BalloonWDF/wmi.c
> > > +++ /dev/null
> > > @@ -1,90 +0,0 @@
> > > -
> > /**
> > > - * Copyright (c) 2009 Red Hat, Inc.
> > > - *
> > > - * File: device.c
> > > - *
> > > - * Author(s):
> > > - *
> > > - * This file contains WMI support routines
> > > - *
> > > - * This work is licensed under the terms of the GNU GPL, version 2.
> > See
> > > - * the COPYING file in the top-level directory.
> > > - *
> > > -
> > **/
> > > -#include "precomp.h"
> > > -
> > > -#if defined(EVENT_TRACING)
> > > -#include "wmi.tmh"
> > > -#endif
> > > -
> > > -
> > > -#define MOFRESOURCENAME L"MofResourceName"
> > > -
> > > -#ifdef ALLOC_PRAGMA
> > > -#pragma alloc_text(PAGE, WmiRegistration)
> > > -#pragma alloc_text(PAGE, EvtWmiDeviceInfoQueryInstance)
> > > -#endif
> > > -
> > > -NTSTATUS
> > > -WmiRegistration(
> > > -WDFDEVICE Device
> > > -)
> > > -{
> > > -WDF_WMI_PROVIDER_CONFIG providerConfig;
> > > -WDF_WMI_INSTANCE_CONFIG instanceConfig;
> > > -NTSTATUSstatus;
> > > -DECLARE_CONST_UNICODE_STRING(mofRsrcName, MOFRESOURCENAME);
> > > -
> > > -PAGED_CODE();
> > > -
> > > -TraceEvents(TRACE_LEVEL_INFORMATION, DBG_PNP, "-->
> > WmiRegistration\n");
> > > -
> > > -status = WdfDeviceAssignMofResourceName(Device, &mofRsrcName);
> > > -if (!NT_SUCCESS(status)) {
> > > -TraceEvents(TRACE_LEVEL_ERROR, DBG_PNP,
> > > - "WdfDeviceAssignMofResourceName failed 0x%x",
> > status);
> > > -return status;
> > > -}
> > > -
> > > -WDF_WMI_PROVIDER_CONFIG_INIT(&providerConfig,
> > &GUID_DEV_WMI_BALLOON);
> > > -providerConfig.MinInstanceBufferSize = sizeof(ULONGLONG);
> > > -
> > > -WDF_WMI_INSTANCE_CONFIG_INIT_PROVIDER_CONFIG(&instanceConfig,
> > &providerConfig);
> > > -instanceConfig.Register = TRUE;
> > > -instanceConfig.EvtWmiInstanceQueryInstance =
> > EvtWmiDeviceInfoQueryInstance;
> > > -
> > > -status = WdfWmiInstanceCreate(Device,
> > > - &instanceConfig,
> > > - WDF_NO_OBJECT_ATTRIBUTES,
> > > - WDF_NO_HANDLE);
> > > -if (!NT_SUCCESS(status)) {
> > > -TraceEvents(TRACE_LEVEL_ERROR, DBG_PNP,
> > > - "WdfWmiInstanceCreate failed 0x%x", status);
> > > -return status;
> > > -}
> > > -
> > > -TraceEvents(TRACE_LEVEL_INFORMATION, DBG_PNP, "<--
> > WmiRegistration\n");
> > > -return status;
> > > -}
> > > -
> > > -NTSTATUS
> > > -EvtWmiDeviceInfoQueryInstance(
>
Re: Can't make virtio block driver work on Windows 2003
On 10/14/2009 07:52 PM, Asdo wrote: Hi all I have a new installation of Windows 2003 SBS server 32bit which I installed using IDE disk. KVM version is QEMU PC emulator version 0.10.50 (qemu-kvm-devel-86) compiled by myself on kernel 2.6.28-11-server. I have already moved networking from e1000 to virtio (e1000 was performing very sluggishly btw, probably was losing many packets, virtio seems to work) Now I want to move the disk to virtio... This is complex so I thought that first I wanted to see virtio installed and working on another drive. So I tried adding another drive, a virtio one, (a new 100MB file at host side) to the virtual machine and rebooting. A first problem is that Windows does not detect the new device upon boot or Add Hardware scan. Check PCI devices with "info pci". You must have "SCSI controller: PCI device 1af4:1001" device reported. Here is the kvm commandline (it's complex because it comes from libvirt): /usr/local/kvm/bin/qemu-system-x86_64 -S -M pc -m 4096-smp 4 -name winserv2 -uuid -monitor pty -boot c -drive file=/virtual_machines/kvm/nfsimport/winserv2.raw,if=ide,index=0,boot=on -drive file=/virtual_machines/kvm/nfsimport/zerofile,if=virtio,index=1 -net nic,macaddr=xx:xx:xx:xx:xx:xx,vlan=0,model=virtio -net tap,fd=25,vlan=0 -serial none -parallel none -usb -vnc 127.0.0.1:4 Even if Windows couldn't detect the new device I tried to install the driver anyway. On Add Hardware I go through to --> SCSI and RAID controllers --> Have Disk .. and point it to the location of viostor files (windows 2003 x86) downloaded from: http://www.linux-kvm.org/page/WindowsGuestDrivers/Download_Drivers http://people.redhat.com/~yvugenfi/24.09.2009/viostor.zip Windows does install the driver, however at the end it says: The software for this device is now installed, but may not work correctly. This device cannot start. (Code 10) and the new device gets flagged with a yellow exclamation mark in Device Manager. I don't know if it's the same reason as before, that the device is not detected so the driver cannot work, or another reason. Yes, it must be the same problem. Code 10 means that device driver was not able to find or initialize hardware. Regards, Vadim Any idea? Thanks for your help -- 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: Can't make virtio block driver work on Windows 2003
On 10/15/2009 01:42 PM, Asdo wrote: Vadim Rozenfeld wrote: On 10/14/2009 07:52 PM, Asdo wrote: ... So I tried adding another drive, a virtio one, (a new 100MB file at host side) to the virtual machine and rebooting. A first problem is that Windows does not detect the new device upon boot or Add Hardware scan. Check PCI devices with "info pci". You must have "SCSI controller: PCI device 1af4:1001" device reported. It's not there. Does this make it a KVM bug? Looks like virtio-blk device wasn't initialized. Otherwise I cannot explain why 0x1100 device is here. Try to start block device without "index=1" Anyway, if you can, please send "info pci" output from QEMU monitor console. Thank you, Vadim. I'm attaching the PCI32.EXE output at the bottom of this email BTW I would probably be able to switch to virtio anyway on this installation of Windows 2003, if I knew the way to insert the viostor driver into the windows boot image (windows's initrd), because if I set the first disk hda as virtio then kvm really makes it virtio (so maybe it's a configuration with one IDE and one virtio that does not work in KVM) and Windows bluescreens at boot. However I don't know how to insert the viostor driver in the windows boot image. Any suggestions? Here is the kvm commandline (it's complex because it comes from libvirt): /usr/local/kvm/bin/qemu-system-x86_64 -S -M pc -m 4096-smp 4 -name winserv2 -uuid -monitor pty -boot c -drive file=/virtual_machines/kvm/nfsimport/winserv2.raw,if=ide,index=0,boot=on -drive file=/virtual_machines/kvm/nfsimport/zerofile,if=virtio,index=1 -net nic,macaddr=xx:xx:xx:xx:xx:xx,vlan=0,model=virtio -net tap,fd=25,vlan=0 -serial none -parallel none -usb -vnc 127.0.0.1:4 Craig Hart's PCI+AGP bus sniffer, Version 1.6, freeware made in 1996-2005. Searching for Devices using CFG Mechanism 1 [OS: Win 2003 Service Pack 1] Bus 0 (PCI), Device Number 0, Device Function 0 Vendor 8086h Intel Corporation Device 1237h 82441FX 440FX (Natoma) System Controller Rev 2 (SU053) Command h (Bus Access Disabled!!) Status h Revision 02h, Header Type 00h, Bus Latency Timer 00h Self test 00h (Self test not supported) PCI Class Bridge, type PCI to HOST Subsystem ID 11001AF4h Unknown Subsystem Vendor 1AF4h Unknown Bus 0 (PCI), Device Number 1, Device Function 0 Vendor 8086h Intel Corporation Device 7000h 82371SB PIIX3 ISA Bridge Command 0007h (I/O Access, Memory Access, BusMaster) Status 0200h (Medium Timing) Revision 00h, Header Type 80h, Bus Latency Timer 00h Self test 00h (Self test not supported) PCI Class Bridge, type PCI to ISA Subsystem ID 11001AF4h Unknown Subsystem Vendor 1AF4h Unknown Bus 0 (PCI), Device Number 1, Device Function 1 Vendor 8086h Intel Corporation Device 7010h 82371SB PIIX3 EIDE Controller Command 0007h (I/O Access, Memory Access, BusMaster) Status 0280h (Supports Back-To-Back Trans., Medium Timing) Revision 00h, Header Type 00h, Bus Latency Timer 00h Self test 00h (Self test not supported) PCI Class Storage, type IDE (ATA) PCI EIDE Controller Features : BusMaster EIDE is supported Primary Channel is at I/O Port 01F0h and IRQ 14 Secondary Channel is at I/O Port 0170h and IRQ 15 Subsystem ID 11001AF4h Unknown Subsystem Vendor 1AF4h Unknown Address 4 is an I/O Port : C000h Bus 0 (PCI), Device Number 1, Device Function 2 Vendor 8086h Intel Corporation Device 7020h 82371SB PIIX3 USB Controller Rev 1 (SU093) Command 0007h (I/O Access, Memory Access, BusMaster) Status h Revision 01h, Header Type 00h, Bus Latency Timer 00h Self test 00h (Self test not supported) PCI Class Serial, type USB (UHCI) Subsystem ID 11001AF4h Unknown Subsystem Vendor 1AF4h Unknown Address 4 is an I/O Port : C020h System IRQ 11, INT# D Bus 0 (PCI), Device Number 1, Device Function 3 Vendor 8086h Intel Corporation Device 7113h 82371MB PIIX4M Power Management Controller Command h (Bus Access Disabled!!) Status 0280h (Supports Back-To-Back Trans., Medium Timing) Revision 03h, Header Type 00h, Bus Latency Timer 00h Self test 00h (Self test not supported) PCI Class Bridge, type PCI to Other Subsystem ID 11001AF4h Unknown Subsystem Vendor 1AF4h Unknown System IRQ 9, INT# A Bus 0 (PCI), Device Number 2, Device Function 0 Vendor 1013h Cirrus Logic Device 00B8h CL-GD5446 PCI Command 0007h (I/O Access, Memory Access, BusMaster) Status h Revision 00h, Header Type 00h, Bus Latency Timer 00h Self test 00h (Self test not supported) PCI Class Display, type VGA Subsystem ID 11001AF4h Unknown Subsystem Vendor 1AF4h Unknown Address 0 is a Memory Address (anywhere in 0-4Gb, Prefetchable) : F000h Address 1 is a Memory Address (anywhere in 0-4Gb) : F200h Bus 0 (PCI), Device Number 3, Device Function 0 Vendor 1AF4h Unknown Device 1000h Unknown Command 0007h (I/O Access, Memory Access, BusMaster) Status h Revision 00h, Header Type 00h,
Re: Can't make virtio block driver work on Windows 2003
On 10/15/2009 04:23 PM, Asdo wrote: Vadim Rozenfeld wrote: On 10/15/2009 01:42 PM, Asdo wrote: Vadim Rozenfeld wrote: On 10/14/2009 07:52 PM, Asdo wrote: ... So I tried adding another drive, a virtio one, (a new 100MB file at host side) to the virtual machine and rebooting. A first problem is that Windows does not detect the new device upon boot or Add Hardware scan. Check PCI devices with "info pci". You must have "SCSI controller: PCI device 1af4:1001" device reported. It's not there. Does this make it a KVM bug? Looks like virtio-blk device wasn't initialized. Otherwise I cannot explain why 0x1100 device is here. Try to start block device without "index=1" Anyway, if you can, please send "info pci" output from QEMU monitor console. Owh! Ok THAT was "info pci" Ok I am copying by hand before removing index=1 (qemu) info pci Bus 0, device 0, function, 0: Host bridge: PCI device 8086:1237 Bus 0 device 1, function 0: ISA ridge: PCI device 8086:7000 Bos 0 device 1 function 1: IDE controller: PCI device 8086:7010 BAR4: I/O at 0xc000 [0xc00f]. Bus 0 device 1 function 3: Bridge: PCI device 8086:7133 IRQ 9 Bus 0 device 2 function 0: VGA controller: PCI device 1013:00b8 BAR0: 32 but memory at 0xf000 [0xf1ff] BAR1: 32 but memory at 0xf200 [0xf2000fff] Bus 0 device 3 function 0: Ethernet controller PCI device 1af4:1000 IRQ 11 BAR0: I/O at 0xc020 [0xc03f] Bus 0 device 4 function 0 RAM controller: PCI device 1af4:1002 IRQ 11 BAR0 : I/O at 0xc040 (qemu) so it's not there Now I remove index=1: WOW it's there now! ... Bus 0 device 4 function 0: Storage controller: PCI device 1af4:1001 IRQ 11 BAR0: I/O at 0xc040 [0xc07f] (just before the 1002 device) So now windows sees it and I was able to install the viostor drivers (btw Windows was not happy with the previously installed viostor drivers, I had to reinstall those and I got two devices, and the previous one still had the yellow exclamation mark, so I had to uninstall that one. After the procedure I was able to boot on virtio too! Yeah!). Great so yes, I'd say you *DO* have a KVM bug: one has to remove index=1 for the second disk to appear. How did you know that, Vadim, is it a known issue with kvm? I don't know. I think, I've seen it once or twice while debugging viostor on old qemu-kvm. But it definitely works with the recent versions. Regards, Vadim It's better to fix that because libvirt puts "index=n" for all drives so it's impossible to workaround the problem if one uses libvirt. I had to launch manually... Thanks a lot Vadim. Asdo -- 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: lspci says: "SCSI storage controller: Qumranet, Inc. Virtio block device". Is it really?
On 10/19/2009 03:42 PM, Tomasz Chmielewski wrote:
Luca Tettamanti wrote:
So why was "SCSI storage controller" any better than "IDE interface" or
"SATA controller" for virtio block device, if it does not talk SCSI
protocol
(other than "SCSI storage controller" being the first on the list of
subclasses)?
Because both ATA and SATA classes have a generic driver that would try
to bind to that controller (and the whole point of virtio block device
is to avoid emulating a ATA/SATA controller).
Doesn't "80 Mass storage controller" ("0x800x00Other mass
storage
controller") fit better for virtio block device?
Maybe. I guess that are compatibility problem with "other" operating
systems.
Thanks for clarifications.
It makes sense in that case - I don't have any more questions ;)
we need it for windows viostor driver to be WHQL'ed
--
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] viostor driver. Code cleanup. Getting rid of the Registry stuff.
repository: /home/vadimr/shares/kvm-guest-drivers-windows
branch: master
commit f7f53b25857f20732b2eb69f127bb2d9bf369e4e
Author: Vadim Rozenfeld
Date: Mon Sep 21 22:05:51 2009 +0300
[PATCH] viostor driver.
Code cleanup. Getting rid of the Registry stuff.
Signed-off-by: Vadim Rozenfeld
diff --git a/viostor/virtio_stor.c b/viostor/virtio_stor.c
index d528ca9..e4acaa0 100644
--- a/viostor/virtio_stor.c
+++ b/viostor/virtio_stor.c
@@ -19,13 +19,6 @@
ULONG RhelDbgLevel = TRACE_LEVEL_NONE;
BOOLEAN IsCrashDumpMode;
-UNICODE_STRING ViostorServicePathUnicode =
-RTL_CONSTANT_STRING(VIOSTOR_SERVICE_NAME);
-
-UNICODE_STRING MaxTransferSizeUnicode =
-RTL_CONSTANT_STRING(MAX_TRANSFER_SIZE);
-
-
BOOLEAN
VirtIoHwInitialize(
IN PVOID DeviceExtension
@@ -98,12 +91,6 @@ CompleteSRB(
IN PSCSI_REQUEST_BLOCK Srb
);
-BOOLEAN
-GetMaxTransferSize(
-IN PVOID DeviceExtension
-);
-
-
ULONG
DriverEntry(
IN PVOID DriverObject,
@@ -292,32 +279,16 @@ VirtIoFindAdapter(
vq_sz = (sizeof(struct vring_virtqueue) + sizeof(PVOID) * pageNum);
if(adaptExt->dump_mode) {
-adaptExt->breaks_number = 8;
-adaptExt->queue_depth = 4;
+ConfigInfo->NumberOfPhysicalBreaks = 8;
} else {
-if(GetMaxTransferSize(DeviceExtension)) {
- adaptExt->breaks_number = (adaptExt->transfer_size / 4);
- if(pageNum<= (adaptExt->breaks_number * 4)) {
- adaptExt->breaks_number = (pageNum / 4);
- }
- adaptExt->breaks_number = min(adaptExt->breaks_number, 64);
- adaptExt->breaks_number = max(adaptExt->breaks_number, 1);
- adaptExt->queue_depth = (pageNum / adaptExt->breaks_number) - 1;
- adaptExt->queue_depth = max(adaptExt->queue_depth, 1);
-} else {
- adaptExt->breaks_number = (pageNum / 2);
- adaptExt->breaks_number = min(adaptExt->breaks_number, 8);
- adaptExt->breaks_number = max(adaptExt->breaks_number, 1);
- adaptExt->queue_depth = 4;
-}
+ConfigInfo->NumberOfPhysicalBreaks = 16;
}
-ConfigInfo->NumberOfPhysicalBreaks = adaptExt->breaks_number;
-ConfigInfo->MaximumTransferLength
-= ConfigInfo->NumberOfPhysicalBreaks * PAGE_SIZE;
+ConfigInfo->MaximumTransferLength = ConfigInfo->NumberOfPhysicalBreaks *
PAGE_SIZE;
+adaptExt->queue_depth = pageNum / ConfigInfo->NumberOfPhysicalBreaks - 1;
RhelDbgPrint(TRACE_LEVEL_INFORMATION, ("breaks_number = %x queue_depth =
%x\n",
-adaptExt->breaks_number,
+ConfigInfo->NumberOfPhysicalBreaks,
adaptExt->queue_depth));
ptr = (ULONG_PTR)ScsiPortGetUncachedExtension(DeviceExtension, ConfigInfo,
(PAGE_SIZE + vr_sz + vq_sz));
@@ -1000,67 +971,3 @@ CompleteSRB(
Srb->Lun);
#endif
}
-
-BOOLEAN
-GetMaxTransferSize(
-IN PVOID DeviceExtension
-)
-{
-
-NTSTATUS status;
-OBJECT_ATTRIBUTES oa;
-HANDLEkeyHandle;
-RHEL_ULONG_VALUE_PARTIAL_INFO ulongValueInfo;
-ULONG ulongValueLength;
-PADAPTER_EXTENSIONadaptExt;
-
-adaptExt = (PADAPTER_EXTENSION)DeviceExtension;
-
-InitializeObjectAttributes(&oa,
-&ViostorServicePathUnicode,
- OBJ_CASE_INSENSITIVE,
- NULL,
- NULL);
-
-status = ZwOpenKey(&keyHandle,
- KEY_READ,
-&oa);
-
-if (!NT_SUCCESS(status)) {
-RhelDbgPrint(TRACE_LEVEL_ERROR,
- ("ReadRegistryValues: Failed to open services key!
0x%x\n",
- status));
-return FALSE;
-}
-
-status = ZwQueryValueKey(keyHandle,
-&MaxTransferSizeUnicode,
- KeyValuePartialInformation,
-&ulongValueInfo,
- sizeof(ulongValueInfo),
-&ulongValueLength);
-
-if (!NT_SUCCESS(status)) {
-RhelDbgPrint(TRACE_LEVEL_ERROR,
- ("ReadRegistryValues: Failed to query %wZ value! 0x%x\n",
-&MaxTransferSizeUnicode, status));
-ZwClose(keyHandle);
-return FALSE;
-}
-
-ASSERT(ulongValueInfo.PartialInfo.Type == REG_SZ);
-
-switch(*ulongValueInfo.PartialInfo.Data) {
-case '0' : adaptExt->transfer_size = 64; break;
-case '1' : adaptExt->transfer_size = 128; break;
-case '2' : adaptExt->transfer_size = 256; break;
-default : adaptExt->transfer_size = 64; break;
-}
-
-RhelDbgPrint(TRACE_LEVEL_INFORMATION,
- ("%wZ set to %d\n",&MaxTransferSizeUnicode
[PATCH] viostor driver. switch to full-duplex mode.
repository: /home/vadimr/shares/kvm-guest-drivers-windows
branch: master
commit ed4b9ade27b56e9ee37461c2cf72e46d75633e9c
Author: Vadim Rozenfeld
Date: Wed Sep 23 11:28:48 2009 +0300
[PATCH] viostor driver. switch to full-duplex mode.
Signed-off-by: Vadim Rozenfeld
diff --git a/viostor/virtio_stor.c b/viostor/virtio_stor.c
index e4acaa0..297949a 100644
--- a/viostor/virtio_stor.c
+++ b/viostor/virtio_stor.c
@@ -194,6 +194,7 @@ VirtIoFindAdapter(
ConfigInfo->WmiDataProvider= FALSE;
#ifdef USE_STORPORT
ConfigInfo->MapBuffers = STOR_MAP_NON_READ_WRITE_BUFFERS;
+ConfigInfo->SynchronizationModel = StorSynchronizeFullDuplex;
#else
ConfigInfo->MapBuffers = TRUE;
#endif
@@ -323,6 +324,8 @@ VirtIoFindAdapter(
return SP_RETURN_ERROR;
}
+InitializeListHead(&adaptExt->list_head);
+
return SP_RETURN_FOUND;
}
@@ -488,7 +491,7 @@ VirtIoStartIo(
case SCSIOP_WRITE: {
Srb->SrbStatus = SRB_STATUS_PENDING;
if(!RhelDoReadWrite(DeviceExtension, Srb)) {
-Srb->SrbStatus = SRB_STATUS_ABORTED;
+Srb->SrbStatus = SRB_STATUS_BUSY;
CompleteSRB(DeviceExtension, Srb);
}
return TRUE;
@@ -561,7 +564,7 @@ VirtIoInterrupt(
Srb->SrbStatus = SRB_STATUS_ERROR;
break;
}
-
+ RemoveEntryList(&vbr->list_entry);
CompleteSRB(DeviceExtension, Srb);
}
}
diff --git a/viostor/virtio_stor.h b/viostor/virtio_stor.h
index 1c0dbb6..2d98738 100644
--- a/viostor/virtio_stor.h
+++ b/viostor/virtio_stor.h
@@ -78,12 +78,8 @@ typedef struct virtio_blk_outhdr {
u64 sector;
}blk_outhdr, *pblk_outhdr;
-struct list_head {
-struct list_head *next, *prev;
-};
-
typedef struct virtio_blk_req {
-struct list_head list;
+LIST_ENTRY list_entry;
struct request *req;
blk_outhdr out_hdr;
u8 status;
@@ -98,6 +94,7 @@ typedef struct _ADAPTER_EXTENSION {
blk_configinfo;
ULONG queue_depth;
BOOLEAN dump_mode;
+LIST_ENTRYlist_head;
}ADAPTER_EXTENSION, *PADAPTER_EXTENSION;
typedef struct _RHEL_SRB_EXTENSION {
diff --git a/viostor/virtio_stor_hw_helper.c b/viostor/virtio_stor_hw_helper.c
index 43bde5a..3c09259 100644
--- a/viostor/virtio_stor_hw_helper.c
+++ b/viostor/virtio_stor_hw_helper.c
@@ -15,22 +15,33 @@
#include "virtio_stor_hw_helper.h"
#ifdef USE_STORPORT
-BOOLEAN
-RhelDoReadWrite(PVOID DeviceExtension,
-PSCSI_REQUEST_BLOCK Srb)
+BOOLEAN
+SynchronizedAccessRoutine(
+IN PVOID DeviceExtension,
+IN PVOID Context
+)
{
PADAPTER_EXTENSION adaptExt = (PADAPTER_EXTENSION)DeviceExtension;
+PSCSI_REQUEST_BLOCK Srb = (PSCSI_REQUEST_BLOCK) Context;
PRHEL_SRB_EXTENSION srbExt = (PRHEL_SRB_EXTENSION)Srb->SrbExtension;
-
if (adaptExt->pci_vq_info.vq->vq_ops->add_buf(adaptExt->pci_vq_info.vq,
-&srbExt->vbr.sg[0],
- srbExt->out, srbExt->in,
-&srbExt->vbr) == 0) {
+&srbExt->vbr.sg[0],
+ srbExt->out, srbExt->in,
+&srbExt->vbr) == 0){
+InsertTailList(&adaptExt->list_head,&srbExt->vbr.list_entry);
adaptExt->pci_vq_info.vq->vq_ops->kick(adaptExt->pci_vq_info.vq);
return TRUE;
}
+StorPortBusy(DeviceExtension, 10);
return FALSE;
}
+
+BOOLEAN
+RhelDoReadWrite(PVOID DeviceExtension,
+PSCSI_REQUEST_BLOCK Srb)
+{
+return
StorPortSynchronizeAccess(DeviceExtension,SynchronizedAccessRoutine,
(PVOID)Srb);
+}
#else
BOOLEAN
RhelDoReadWrite(PVOID DeviceExtension,
@@ -83,6 +94,8 @@ RhelDoReadWrite(PVOID DeviceExtension,
&srbExt->vbr.sg[0],
srbExt->out, srbExt->in,
&srbExt->vbr) == 0) {
+//FIXME
+InsertTailList(&adaptExt->list_head,&srbExt->vbr.list_entry);
adaptExt->pci_vq_info.vq->vq_ops->kick(adaptExt->pci_vq_info.vq);
return TRUE;
}
diff --git a/viostor/virtio_stor.c b/viostor/virtio_stor.c
index e4acaa0..297949a 100644
--- a/viostor/virtio_stor.c
+++ b/viostor/virtio_stor.c
@@ -194,6 +194,7 @@ VirtIoFindAdapter(
ConfigInfo->WmiDataProvider= FALSE;
#ifdef USE_STORPORT
ConfigInfo->MapBuffers = STOR_MAP_NON_READ_WRITE_BUFFERS;
+ConfigInfo->SynchronizationModel = StorSynchronizeFullDuplex;
#else
ConfigInfo->MapBuffers = TRUE;
#endif
@@ -323,6 +324,8 @@ VirtIoFindAdapter(
return SP_RETURN_ERROR;
}
+InitializeListHead(&adaptExt->list_head);
+
return SP_RETURN_FOUND;
}
@@ -488,7 +491,7 @@ VirtIoStart
[PATCH] viostor driver. Complete SRBs at DPC level
repository: /home/vadimr/shares/kvm-guest-drivers-windows
branch: master
commit c507d6b279010ff1e1939927d2b2e91a59daac3b
Author: Vadim Rozenfeld
Date: Thu Sep 24 22:03:00 2009 +0300
[PATCH] viostor driver. Complete SRBs at DPC level
Signed-off-by: Vadim Rozenfeld
diff --git a/viostor/virtio_stor.c b/viostor/virtio_stor.c
index 297949a..375021b 100644
--- a/viostor/virtio_stor.c
+++ b/viostor/virtio_stor.c
@@ -30,6 +30,14 @@ VirtIoBuildIo(
IN PVOID DeviceExtension,
IN PSCSI_REQUEST_BLOCK Srb
);
+
+VOID
+CompleteDpcRoutine(
+IN PSTOR_DPC Dpc,
+IN PVOID Context,
+IN PVOID SystemArgument1,
+IN PVOID SystemArgument2
+) ;
#endif
BOOLEAN
@@ -91,6 +99,13 @@ CompleteSRB(
IN PSCSI_REQUEST_BLOCK Srb
);
+VOID
+FORCEINLINE
+CompleteDPC(
+IN PVOID DeviceExtension,
+IN pblk_req vbr
+);
+
ULONG
DriverEntry(
IN PVOID DriverObject,
@@ -325,10 +340,28 @@ VirtIoFindAdapter(
}
InitializeListHead(&adaptExt->list_head);
+InitializeListHead(&adaptExt->complete_list);
return SP_RETURN_FOUND;
}
+#ifdef USE_STORPORT
+BOOLEAN
+VirtIoPassiveInitializeRoutine (
+IN PVOID DeviceExtension
+)
+{
+PADAPTER_EXTENSION adaptExt = (PADAPTER_EXTENSION)DeviceExtension;
+
+StorPortInitializeDpc(DeviceExtension,
+&adaptExt->completion_dpc,
+CompleteDpcRoutine);
+
+return TRUE;
+}
+#endif
+
+
BOOLEAN
VirtIoHwInitialize(
IN PVOID DeviceExtension
@@ -400,6 +433,13 @@ VirtIoHwInitialize(
ScsiPortMoveMemory(&adaptExt->inquiry_data.ProductRevisionLevel, "0001",
sizeof("0001"));
ScsiPortMoveMemory(&adaptExt->inquiry_data.VendorSpecific, "0001",
sizeof("0001"));
+#ifdef USE_STORPORT
+if(!adaptExt->dump_mode)
+{
+return StorPortEnablePassiveInitialization(DeviceExtension,
VirtIoPassiveInitializeRoutine);
+}
+#endif
+
return TRUE;
}
@@ -564,8 +604,7 @@ VirtIoInterrupt(
Srb->SrbStatus = SRB_STATUS_ERROR;
break;
}
- RemoveEntryList(&vbr->list_entry);
- CompleteSRB(DeviceExtension, Srb);
+ CompleteDPC(DeviceExtension, vbr);
}
}
RhelDbgPrint(TRACE_LEVEL_VERBOSE, ("%s isInterruptServiced = %d\n",
__FUNCTION__, isInterruptServiced));
@@ -974,3 +1013,63 @@ CompleteSRB(
Srb->Lun);
#endif
}
+
+VOID
+FORCEINLINE
+CompleteDPC(
+IN PVOID DeviceExtension,
+IN pblk_req vbr
+)
+{
+PSCSI_REQUEST_BLOCK Srb = (PSCSI_REQUEST_BLOCK)vbr->req;
+PADAPTER_EXTENSION adaptExt = (PADAPTER_EXTENSION)DeviceExtension;
+
+RemoveEntryList(&vbr->list_entry);
+
+#ifdef USE_STORPORT
+if(!adaptExt->dump_mode) {
+InsertTailList(&adaptExt->complete_list,&vbr->list_entry);
+StorPortIssueDpc(DeviceExtension,
+&adaptExt->completion_dpc,
+ NULL,
+ NULL);
+return;
+}
+#endif
+CompleteSRB(DeviceExtension, Srb);
+}
+
+
+VOID
+CompleteDpcRoutine(
+IN PSTOR_DPC Dpc,
+IN PVOID Context,
+IN PVOID SystemArgument1,
+IN PVOID SystemArgument2
+)
+{
+STOR_LOCK_HANDLE LockHandle;
+PADAPTER_EXTENSION adaptExt = (PADAPTER_EXTENSION)Context;
+
+StorPortAcquireSpinLock ( Context, InterruptLock , NULL,&LockHandle);
+
+while (!IsListEmpty(&adaptExt->complete_list)) {
+PSCSI_REQUEST_BLOCK Srb;
+pblk_req vbr;
+vbr = (pblk_req) RemoveHeadList(&adaptExt->complete_list);
+Srb = (PSCSI_REQUEST_BLOCK)vbr->req;
+
+StorPortReleaseSpinLock (Context,&LockHandle);
+
+ScsiPortNotification(RequestComplete,
+ Context,
+ Srb);
+
+StorPortAcquireSpinLock ( Context, InterruptLock , NULL,&LockHandle);
+
+}
+
+StorPortReleaseSpinLock (Context,&LockHandle);
+
+return;
+}
diff --git a/viostor/virtio_stor.h b/viostor/virtio_stor.h
index 2d98738..2533148 100644
--- a/viostor/virtio_stor.h
+++ b/viostor/virtio_stor.h
@@ -95,6 +95,8 @@ typedef struct _ADAPTER_EXTENSION {
ULONG queue_depth;
BOOLEAN dump_mode;
LIST_ENTRYlist_head;
+LIST_ENTRYcomplete_list;
+STOR_DPC completion_dpc;
}ADAPTER_EXTENSION, *PADAPTER_EXTENSION;
typedef struct _RHEL_SRB_EXTENSION {
--
To unsubscribe from this list: send the line "unsubscribe kvm-commits" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/viostor/virtio_stor.c b/viostor/virtio_stor.c
index 297949a..375021b 100644
--- a/viostor/virtio_stor.c
+++ b/viostor/virtio_stor.c
@@ -30,6 +30,14 @@ VirtIoBuildIo(
IN PVOID DeviceExtension,
IN PSCSI_REQUEST_BLOCK Srb
);
+
[PATCH] viostor driver. add support for serial number.
repository: /home/vadimr/shares/kvm-guest-drivers-windows
branch: master
commit 394ae1879c5818fd0dce4b68b207c8ef6bf5e115
Author: Vadim Rozenfeld
Date: Fri Sep 25 21:15:37 2009 +0300
[PATCH] viostor driver. add support for serial number feature.
Signed-off-by: Vadim Rozenfeld
diff --git a/viostor/virtio_stor.c b/viostor/virtio_stor.c
index 375021b..b972dd2 100644
--- a/viostor/virtio_stor.c
+++ b/viostor/virtio_stor.c
@@ -416,6 +416,14 @@ VirtIoHwInitialize(
RhelDbgPrint(TRACE_LEVEL_INFORMATION, ("VIRTIO_BLK_F_GEOMETRY. cylinders = %d heads
= %d sectors = %d\n", adaptExt->info.geometry.cylinders,
adaptExt->info.geometry.heads, adaptExt->info.geometry.sectors));
}
+if (VirtIODeviceGetHostFeature(DeviceExtension, VIRTIO_BLK_F_IDENTIFY)) {
+VirtIODeviceGet(DeviceExtension, FIELD_OFFSET(blk_config, identify),
+&adaptExt->info.identify, VIRTIO_BLK_ID_LEN);
+adaptExt->has_sn = TRUE;
+RhelDbgPrint(TRACE_LEVEL_INFORMATION, ("VIRTIO_BLK_F_IDENTIFY. \n"));
+}
+
+
VirtIODeviceGet( DeviceExtension, FIELD_OFFSET(blk_config, capacity),
&cap, sizeof(cap));
adaptExt->info.capacity = cap;
@@ -801,8 +809,13 @@ RhelScsiGetInquiryData(
PVPD_SERIAL_NUMBER_PAGE SerialPage;
SerialPage = (PVPD_SERIAL_NUMBER_PAGE)Srb->DataBuffer;
SerialPage->PageCode = VPD_SERIAL_NUMBER;
-SerialPage->PageLength = 1;
-SerialPage->SerialNumber[0] = '0';
+if(adaptExt->has_sn) {
+ SerialPage->PageLength = VIRTIO_BLK_ID_SN_BYTES;
+
ScsiPortMoveMemory(&SerialPage->SerialNumber[0],&adaptExt->info.identify[VIRTIO_BLK_ID_SN],
VIRTIO_BLK_ID_SN_BYTES);
+} else {
+ SerialPage->PageLength = 1;
+ SerialPage->SerialNumber[0] = '0';
+}
Srb->DataTransferLength = sizeof(VPD_SERIAL_NUMBER_PAGE) +
SerialPage->PageLength;
}
else if ((cdb->CDB6INQUIRY3.PageCode == VPD_DEVICE_IDENTIFIERS)&&
diff --git a/viostor/virtio_stor.h b/viostor/virtio_stor.h
index 2533148..dd4728e 100644
--- a/viostor/virtio_stor.h
+++ b/viostor/virtio_stor.h
@@ -36,6 +36,12 @@ typedef struct VirtIOBufferDescriptor VIO_SG, *PVIO_SG;
#define VIRTIO_BLK_F_GEOMETRY 4 /* Legacy geometry available */
#define VIRTIO_BLK_F_RO5 /* Disk is read-only */
#define VIRTIO_BLK_F_BLK_SIZE 6 /* Block size of disk is available*/
+#define VIRTIO_BLK_F_SCSI 7 /* Supports scsi command passthru */
+#define VIRTIO_BLK_F_IDENTIFY 8 /* ATA IDENTIFY supported */
+
+#define VIRTIO_BLK_ID_LEN 256 /* length of identify u16 array */
+#define VIRTIO_BLK_ID_SN10 /* start of char * serial# */
+#define VIRTIO_BLK_ID_SN_BYTES 20 /* length in bytes of serial# */
/* These two define direction. */
#define VIRTIO_BLK_T_IN0
@@ -66,6 +72,7 @@ typedef struct virtio_blk_config {
} geometry;
/* block size of device (if VIRTIO_BLK_F_BLK_SIZE) */
u32 blk_size;
+u16 identify[VIRTIO_BLK_ID_LEN];
}blk_config, *pblk_config;
#pragma pack()
@@ -97,6 +104,7 @@ typedef struct _ADAPTER_EXTENSION {
LIST_ENTRYlist_head;
LIST_ENTRYcomplete_list;
STOR_DPC completion_dpc;
+BOOLEAN has_sn;
}ADAPTER_EXTENSION, *PADAPTER_EXTENSION;
typedef struct _RHEL_SRB_EXTENSION {
--
To unsubscribe from this list: send the line "unsubscribe kvm-commits" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/viostor/virtio_stor.c b/viostor/virtio_stor.c
index 375021b..b972dd2 100644
--- a/viostor/virtio_stor.c
+++ b/viostor/virtio_stor.c
@@ -416,6 +416,14 @@ VirtIoHwInitialize(
RhelDbgPrint(TRACE_LEVEL_INFORMATION, ("VIRTIO_BLK_F_GEOMETRY.
cylinders = %d heads = %d sectors = %d\n", adaptExt->info.geometry.cylinders,
adaptExt->info.geometry.heads, adaptExt->info.geometry.sectors));
}
+if (VirtIODeviceGetHostFeature(DeviceExtension, VIRTIO_BLK_F_IDENTIFY)) {
+VirtIODeviceGet(DeviceExtension, FIELD_OFFSET(blk_config, identify),
+ &adaptExt->info.identify, VIRTIO_BLK_ID_LEN);
+adaptExt->has_sn = TRUE;
+RhelDbgPrint(TRACE_LEVEL_INFORMATION, ("VIRTIO_BLK_F_IDENTIFY. \n"));
+}
+
+
VirtIODeviceGet( DeviceExtension, FIELD_OFFSET(blk_config, capacity),
&cap, sizeof(cap));
adaptExt->info.capacity = cap;
@@ -801,8 +809,13 @@ RhelScsiGetInquiryData(
PVPD_SERIAL_NUMBER_PAGE SerialPage;
SerialPage = (PVPD_SERIAL_NUMBER_PAGE)Srb->DataBuffer;
SerialPage->PageCode = VPD_SERIAL_NUMBER;
-SerialPage->PageLength = 1;
-SerialPage->SerialNumber[
[PATCH] viostor driver. fix broken xp build
repository: /home/vadimr/shares/kvm-guest-drivers-windows
branch: master
commit eca6d92722fc669d5b3fdb99182a0a8e3db6a38b
Author: Vadim Rozenfeld
Date: Sun Oct 25 15:45:17 2009 +0200
[PATCH] viostor driver. fix broken xp build
Signed-off-by: Vadim Rozenfeld
diff --git a/viostor/virtio_stor.c b/viostor/virtio_stor.c
index 4c9fe27..ad7f005 100644
--- a/viostor/virtio_stor.c
+++ b/viostor/virtio_stor.c
@@ -1133,7 +1133,7 @@ CompleteDPC(
CompleteSRB(DeviceExtension, Srb);
}
-
+#ifdef USE_STORPORT
VOID
CompleteDpcRoutine(
IN PSTOR_DPC Dpc,
@@ -1182,3 +1182,4 @@ CompleteDpcRoutine(
}
return;
}
+#endif
diff --git a/viostor/virtio_stor.h b/viostor/virtio_stor.h
index 221c653..063c1d1 100644
--- a/viostor/virtio_stor.h
+++ b/viostor/virtio_stor.h
@@ -103,7 +103,9 @@ typedef struct _ADAPTER_EXTENSION {
BOOLEAN dump_mode;
LIST_ENTRYlist_head;
LIST_ENTRYcomplete_list;
+#ifdef USE_STORPORT
STOR_DPC completion_dpc;
+#endif
BOOLEAN has_sn;
ULONG msix_vectors;
}ADAPTER_EXTENSION, *PADAPTER_EXTENSION;
--
To unsubscribe from this list: send the line "unsubscribe kvm-commits" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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] viostor driver. some steps toward better performance on XP.
repository: /home/vadimr/shares/kvm-guest-drivers-windows
branch: XP
commit 844cc39863ca914cf47a1fe2e8cde4ea1079753b
Author: Vadim Rozenfeld
Date: Thu Oct 29 09:34:19 2009 +0200
[PATCH] viostor driver. some steps toward better performance on XP.
Signed-off-by: Vadim Rozenfeld
diff --git a/viostor/virtio_stor.c b/viostor/virtio_stor.c
index d363909..8b91e62 100644
--- a/viostor/virtio_stor.c
+++ b/viostor/virtio_stor.c
@@ -1131,6 +1131,9 @@ CompleteDPC(
}
#endif
CompleteSRB(DeviceExtension, Srb);
+#ifndef USE_STORPORT
+--adaptExt->requests;
+#endif
}
#ifdef USE_STORPORT
diff --git a/viostor/virtio_stor.h b/viostor/virtio_stor.h
index 456fa0e..c00600c 100644
--- a/viostor/virtio_stor.h
+++ b/viostor/virtio_stor.h
@@ -105,6 +105,8 @@ typedef struct _ADAPTER_EXTENSION {
LIST_ENTRYcomplete_list;
#ifdef USE_STORPORT
STOR_DPC completion_dpc;
+#else
+ULONG requests;
#endif
BOOLEAN has_sn;
ULONG msix_vectors;
diff --git a/viostor/virtio_stor_hw_helper.c b/viostor/virtio_stor_hw_helper.c
index ed6abf7..21d27cd 100644
--- a/viostor/virtio_stor_hw_helper.c
+++ b/viostor/virtio_stor_hw_helper.c
@@ -94,9 +94,11 @@ RhelDoReadWrite(PVOID DeviceExtension,
&srbExt->vbr.sg[0],
srbExt->out, srbExt->in,
&srbExt->vbr) == 0) {
-//FIXME
InsertTailList(&adaptExt->list_head,&srbExt->vbr.list_entry);
adaptExt->pci_vq_info.vq->vq_ops->kick(adaptExt->pci_vq_info.vq);
+if(++adaptExt->requests< adaptExt->queue_depth) {
+ ScsiPortNotification(NextLuRequest, DeviceExtension, Srb->PathId,
Srb->TargetId, Srb->Lun);
+}
return TRUE;
}
return FALSE;
diff --git a/viostor/virtio_stor.c b/viostor/virtio_stor.c
index d363909..8b91e62 100644
--- a/viostor/virtio_stor.c
+++ b/viostor/virtio_stor.c
@@ -1131,6 +1131,9 @@ CompleteDPC(
}
#endif
CompleteSRB(DeviceExtension, Srb);
+#ifndef USE_STORPORT
+--adaptExt->requests;
+#endif
}
#ifdef USE_STORPORT
diff --git a/viostor/virtio_stor.h b/viostor/virtio_stor.h
index 456fa0e..c00600c 100644
--- a/viostor/virtio_stor.h
+++ b/viostor/virtio_stor.h
@@ -105,6 +105,8 @@ typedef struct _ADAPTER_EXTENSION {
LIST_ENTRYcomplete_list;
#ifdef USE_STORPORT
STOR_DPC completion_dpc;
+#else
+ULONG requests;
#endif
BOOLEAN has_sn;
ULONG msix_vectors;
diff --git a/viostor/virtio_stor_hw_helper.c b/viostor/virtio_stor_hw_helper.c
index ed6abf7..21d27cd 100644
--- a/viostor/virtio_stor_hw_helper.c
+++ b/viostor/virtio_stor_hw_helper.c
@@ -94,9 +94,11 @@ RhelDoReadWrite(PVOID DeviceExtension,
&srbExt->vbr.sg[0],
srbExt->out, srbExt->in,
&srbExt->vbr) == 0) {
-//FIXME
InsertTailList(&adaptExt->list_head, &srbExt->vbr.list_entry);
adaptExt->pci_vq_info.vq->vq_ops->kick(adaptExt->pci_vq_info.vq);
+if(++adaptExt->requests < adaptExt->queue_depth) {
+ ScsiPortNotification(NextLuRequest, DeviceExtension, Srb->PathId,
Srb->TargetId, Srb->Lun);
+}
return TRUE;
}
return FALSE;
[PATCH] viostor driver. fix PREfast warnings.
repository: /home/vadimr/shares/kvm-guest-drivers-windows
branch: XP
commit bf13fc498a576236cff8cbc707a4e5a1e70e22fb
Author: Vadim Rozenfeld
Date: Thu Oct 29 10:37:41 2009 +0200
[PATCH] viostor driver. fix PREfast warnings.
Signed-off-by: Vadim Rozenfeld
diff --git a/viostor/virtio_pci.c b/viostor/virtio_pci.c
index a72b019..78a6d29 100644
--- a/viostor/virtio_pci.c
+++ b/viostor/virtio_pci.c
@@ -183,6 +183,10 @@ VirtIODeviceFindVirtualQueue(
// activate the queue
pa = ScsiPortGetPhysicalAddress(DeviceExtension, NULL, info->queue,&dummy);
+if(!pa.QuadPart) {
+ScsiPortWritePortUlong((PULONG)(adaptExt->device_base +
VIRTIO_PCI_QUEUE_PFN),(ULONG)0);
+return NULL;
+}
pageNum = (ULONG)(pa.QuadPart>> PAGE_SHIFT);
RhelDbgPrint(TRACE_LEVEL_FATAL, ("[%s] queue phys.address %08lx:%08lx, pfn
%lx\n", __FUNCTION__, pa.u.HighPart, pa.u.LowPart, pageNum));
ScsiPortWritePortUlong((PULONG)(adaptExt->device_base +
VIRTIO_PCI_QUEUE_PFN),(ULONG)(pageNum));
diff --git a/viostor/virtio_stor.c b/viostor/virtio_stor.c
index 8b91e62..c36b85b 100644
--- a/viostor/virtio_stor.c
+++ b/viostor/virtio_stor.c
@@ -247,29 +247,6 @@ VirtIoFindAdapter(
return SP_RETURN_NOT_FOUND;
}
-if (!ScsiPortValidateRange(DeviceExtension,
- ConfigInfo->AdapterInterfaceType,
- ConfigInfo->SystemIoBusNumber,
- accessRange->RangeStart,
- accessRange->RangeLength,
-
(BOOLEAN)!accessRange->RangeInMemory)) {
-
-ScsiPortLogError(DeviceExtension,
- NULL,
- 0,
- 0,
- 0,
- SP_INTERNAL_ADAPTER_ERROR,
- __LINE__);
-
-RhelDbgPrint(TRACE_LEVEL_FATAL, ("Range validation failed %x for %x
bytes\n",
- (*ConfigInfo->AccessRanges)[0].RangeStart.LowPart,
- (*ConfigInfo->AccessRanges)[0].RangeLength));
-
-return SP_RETURN_ERROR;
-}
-
-
ConfigInfo->NumberOfBuses = 1;
ConfigInfo->MaximumNumberOfTargets = 1;
ConfigInfo->MaximumNumberOfLogicalUnits = 1;
@@ -707,7 +684,7 @@ VirtIoAdapterControl(
RhelDbgPrint(TRACE_LEVEL_VERBOSE, ("ScsiRestartAdapter\n"));
adaptExt->pci_vq_info.vq = NULL;
#ifdef MSI_SUPPORTED
-if(!adaptExt->dump_mode& adaptExt->msix_vectors) {
+if(!adaptExt->dump_mode&& adaptExt->msix_vectors) {
adaptExt->pci_vq_info.vq =
VirtIODeviceFindVirtualQueue(DeviceExtension, 0, adaptExt->msix_vectors);
}
#endif
diff --git a/viostor/virtio_pci.c b/viostor/virtio_pci.c
index a72b019..78a6d29 100644
--- a/viostor/virtio_pci.c
+++ b/viostor/virtio_pci.c
@@ -183,6 +183,10 @@ VirtIODeviceFindVirtualQueue(
// activate the queue
pa = ScsiPortGetPhysicalAddress(DeviceExtension, NULL, info->queue,
&dummy);
+if(!pa.QuadPart) {
+ScsiPortWritePortUlong((PULONG)(adaptExt->device_base +
VIRTIO_PCI_QUEUE_PFN),(ULONG)0);
+return NULL;
+}
pageNum = (ULONG)(pa.QuadPart >> PAGE_SHIFT);
RhelDbgPrint(TRACE_LEVEL_FATAL, ("[%s] queue phys.address %08lx:%08lx, pfn
%lx\n", __FUNCTION__, pa.u.HighPart, pa.u.LowPart, pageNum));
ScsiPortWritePortUlong((PULONG)(adaptExt->device_base +
VIRTIO_PCI_QUEUE_PFN),(ULONG)(pageNum));
diff --git a/viostor/virtio_stor.c b/viostor/virtio_stor.c
index 8b91e62..c36b85b 100644
--- a/viostor/virtio_stor.c
+++ b/viostor/virtio_stor.c
@@ -247,29 +247,6 @@ VirtIoFindAdapter(
return SP_RETURN_NOT_FOUND;
}
-if (!ScsiPortValidateRange(DeviceExtension,
- ConfigInfo->AdapterInterfaceType,
- ConfigInfo->SystemIoBusNumber,
- accessRange->RangeStart,
- accessRange->RangeLength,
-
(BOOLEAN)!accessRange->RangeInMemory)) {
-
-ScsiPortLogError(DeviceExtension,
- NULL,
- 0,
- 0,
- 0,
- SP_INTERNAL_ADAPTER_ERROR,
- __LINE__);
-
-RhelDbgPrint(TRACE_LEVEL_FATAL, ("Range validation failed %x for %x
bytes\n",
- (*ConfigInfo->AccessRanges)[0].RangeStart.LowPart,
- (*ConfigInfo->AccessRanges)[0].RangeLength));
-
-return SP_RETURN_ERROR;
-}
-
-
ConfigInfo->NumberOfBuses = 1;
ConfigInfo->MaximumNumbe
[PATCH] viostor driver.Add memory barrier - synch with fix for Linux guests by Michael S. Tsirkin
repository: /home/vadimr/shares/kvm-guest-drivers-windows branch: XP commit 6906acfc2d5f58df43ebc9c190e1447ff6e63a01 Author: Vadim Rozenfeld Date: Sun Nov 1 11:54:03 2009 +0200 [PATCH] viostor driver.Add memory read barrier - synch with fix for Linux guests by Michael S. Tsirkin Signed-off-by: Vadim Rozenfeld diff --git a/viostor/virtio_ring.c b/viostor/virtio_ring.c index d099bb8..2911cef 100644 --- a/viostor/virtio_ring.c +++ b/viostor/virtio_ring.c @@ -237,6 +237,8 @@ vring_get_buf( return NULL; } +rmb(); + i = vq->vring.used->ring[vq->last_used_idx%vq->vring.num].id; *len = vq->vring.used->ring[vq->last_used_idx%vq->vring.num].len; diff --git a/viostor/virtio_ring.c b/viostor/virtio_ring.c index d099bb8..2911cef 100644 --- a/viostor/virtio_ring.c +++ b/viostor/virtio_ring.c @@ -237,6 +237,8 @@ vring_get_buf( return NULL; } +rmb(); + i = vq->vring.used->ring[vq->last_used_idx%vq->vring.num].id; *len = vq->vring.used->ring[vq->last_used_idx%vq->vring.num].len;
Re: libvirt bug #532480
On 11/03/2009 06:48 PM, Brian Jackson wrote: On Tuesday 03 November 2009 06:02:42 am roma1390 wrote: Lib virt thinks that bug #532480 must be addressed to quemu/kvm team. https://bugzilla.redhat.com/show_bug.cgi?id=532480 For future reference adding some overview to your email instead of making all the devs with arguably limited time go read through a bug report is probably a good idea. Any ideas how to fix this issue? Iirc, it's being worked on. And yes, it is the developers of said drivers responsibility to do the signing. Keep watching the url from the bug for updated drivers. Until then, there are workarounds to this issue also mentioned at that url. http://sourceforge.net/projects/kvm/files/kvm-driver-disc/20080318/kvm-driver-disc-20080318.iso/download doesn't contain viostor.sys (virtual block driver) at all. http://people.redhat.com/~yvugenfi/24.09.2009/viostor.zip drivers are not signed (there are no cat files inside), so you need to do it by yourself. Download and install WDK first, than take a look at Selfsign_example.cmd example. It is pretty self-explaining I think. You can also find tons on information about driver signing by googling on the Internet. btw, as a developer I care about passing the WHQL tests, not about signing. Regards, Vadim -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] viostor driver. XP driver performance improvement.
repository: /home/vadimr/shares/kvm-guest-drivers-windows
branch: XP
commit e58183a0df0fd398e31e3f079b6c301520b2a5a2
Author: Vadim Rozenfeld
Date: Sun Nov 15 22:50:55 2009 +0200
[PATCH] viostor driver. XP driver performance improvement.
Signed-off-by: Vadim Rozenfeld
diff --git a/viostor/virtio_ring.c b/viostor/virtio_ring.c
index 2911cef..de69557 100644
--- a/viostor/virtio_ring.c
+++ b/viostor/virtio_ring.c
@@ -39,7 +39,6 @@ initialize_virtqueue(
IN VOID (*notify)(struct virtqueue *));
-//#define to_vvq(_vq) container_of(_vq, struct vring_virtqueue, vq)
#define to_vvq(_vq) (struct vring_virtqueue *)_vq
static
@@ -119,7 +118,7 @@ vring_add_buf(
RhelDbgPrint(TRACE_LEVEL_VERBOSE, ("%s: Added buffer head %i to %p\n",
__FUNCTION__, head, vq) );
-return 0;
+return vq->num_free;
}
static
diff --git a/viostor/virtio_stor_hw_helper.c b/viostor/virtio_stor_hw_helper.c
index 21d27cd..2e61b30 100644
--- a/viostor/virtio_stor_hw_helper.c
+++ b/viostor/virtio_stor_hw_helper.c
@@ -54,6 +54,8 @@ RhelDoReadWrite(PVOID DeviceExtension,
PVOID DataBuffer;
PADAPTER_EXTENSIONadaptExt;
PRHEL_SRB_EXTENSION srbExt;
+int num_free;
+
cdb = (PCDB)&Srb->Cdb[0];
srbExt = (PRHEL_SRB_EXTENSION)Srb->SrbExtension;
adaptExt = (PADAPTER_EXTENSION)DeviceExtension;
@@ -88,20 +90,21 @@ RhelDoReadWrite(PVOID DeviceExtension,
srbExt->vbr.sg[sgElement].physAddr = ScsiPortGetPhysicalAddress(DeviceExtension,
NULL,&srbExt->vbr.status,&fragLen);
srbExt->vbr.sg[sgElement].ulSize = sizeof(srbExt->vbr.status);
-
-
-if (adaptExt->pci_vq_info.vq->vq_ops->add_buf(adaptExt->pci_vq_info.vq,
+num_free =
adaptExt->pci_vq_info.vq->vq_ops->add_buf(adaptExt->pci_vq_info.vq,
&srbExt->vbr.sg[0],
srbExt->out, srbExt->in,
-&srbExt->vbr) == 0) {
+&srbExt->vbr);
+if ( num_free>= 0) {
InsertTailList(&adaptExt->list_head,&srbExt->vbr.list_entry);
adaptExt->pci_vq_info.vq->vq_ops->kick(adaptExt->pci_vq_info.vq);
-if(++adaptExt->requests< adaptExt->queue_depth) {
+srbExt->call_next = FALSE;
+if(num_free< VIRTIO_MAX_SG) {
+ srbExt->call_next = TRUE;
+} else {
ScsiPortNotification(NextLuRequest, DeviceExtension, Srb->PathId,
Srb->TargetId, Srb->Lun);
}
-return TRUE;
}
-return FALSE;
+return TRUE;
}
#endif
diff --git a/viostor/virtio_ring.c b/viostor/virtio_ring.c
index 2911cef..de69557 100644
--- a/viostor/virtio_ring.c
+++ b/viostor/virtio_ring.c
@@ -39,7 +39,6 @@ initialize_virtqueue(
IN VOID (*notify)(struct virtqueue *));
-//#define to_vvq(_vq) container_of(_vq, struct vring_virtqueue, vq)
#define to_vvq(_vq) (struct vring_virtqueue *)_vq
static
@@ -119,7 +118,7 @@ vring_add_buf(
RhelDbgPrint(TRACE_LEVEL_VERBOSE, ("%s: Added buffer head %i to %p\n",
__FUNCTION__, head, vq) );
-return 0;
+return vq->num_free;
}
static
diff --git a/viostor/virtio_stor_hw_helper.c b/viostor/virtio_stor_hw_helper.c
index 21d27cd..2e61b30 100644
--- a/viostor/virtio_stor_hw_helper.c
+++ b/viostor/virtio_stor_hw_helper.c
@@ -54,6 +54,8 @@ RhelDoReadWrite(PVOID DeviceExtension,
PVOID DataBuffer;
PADAPTER_EXTENSIONadaptExt;
PRHEL_SRB_EXTENSION srbExt;
+int num_free;
+
cdb = (PCDB)&Srb->Cdb[0];
srbExt = (PRHEL_SRB_EXTENSION)Srb->SrbExtension;
adaptExt = (PADAPTER_EXTENSION)DeviceExtension;
@@ -88,20 +90,21 @@ RhelDoReadWrite(PVOID DeviceExtension,
srbExt->vbr.sg[sgElement].physAddr =
ScsiPortGetPhysicalAddress(DeviceExtension, NULL, &srbExt->vbr.status,
&fragLen);
srbExt->vbr.sg[sgElement].ulSize = sizeof(srbExt->vbr.status);
-
-
-if (adaptExt->pci_vq_info.vq->vq_ops->add_buf(adaptExt->pci_vq_info.vq,
+num_free =
adaptExt->pci_vq_info.vq->vq_ops->add_buf(adaptExt->pci_vq_info.vq,
&srbExt->vbr.sg[0],
srbExt->out, srbExt->in,
- &srbExt->vbr) == 0) {
+ &srbExt->vbr);
+if ( num_free >= 0) {
InsertTailList(&adaptExt->list_head, &srbExt->vbr.list_entry);
adaptExt->pci_vq_info.vq->vq_ops->kick(adaptExt->pci_vq_info.vq);
-if(++adaptExt->requests < adaptExt->queue_depth) {
+srbExt->call_next = FALSE;
+if(num_free < VIRTIO_MAX_SG) {
+ srbExt->call_next = TRUE;
+} else {
ScsiPortNotification(NextLuRequest, DeviceExtension, Srb->PathId,
Srb->TargetId, Srb->Lun);
}
-return TRUE;
}
-return FALSE;
+return TRUE;
}
#endif
[PATCH] viostor driver. Xp driver performance.
repository: /home/vadimr/shares/kvm-guest-drivers-windows
branch: XP
commit 3b2926a281a769499944a23cc3c9b905593e6838
Author: Vadim Rozenfeld
Date: Thu Nov 19 09:14:38 2009 +0200
[PATCH] viostor driver. Xp driver performance.
Signed-off-by: Vadim Rozenfeld
diff --git a/viostor/virtio_stor.c b/viostor/virtio_stor.c
index c36b85b..e674dff 100644
--- a/viostor/virtio_stor.c
+++ b/viostor/virtio_stor.c
@@ -215,6 +215,7 @@ VirtIoFindAdapter(
ConfigInfo->Dma32BitAddresses = TRUE;
ConfigInfo->Dma64BitAddresses = TRUE;
ConfigInfo->WmiDataProvider= FALSE;
+
#ifdef USE_STORPORT
ConfigInfo->MapBuffers = STOR_MAP_NON_READ_WRITE_BUFFERS;
ConfigInfo->SynchronizationModel = StorSynchronizeFullDuplex;
@@ -286,7 +287,7 @@ VirtIoFindAdapter(
if(adaptExt->dump_mode) {
ConfigInfo->NumberOfPhysicalBreaks = 8;
} else {
-ConfigInfo->NumberOfPhysicalBreaks = 16;
+ConfigInfo->NumberOfPhysicalBreaks = MAX_PHYS_SEGMENTS-1;
}
ConfigInfo->MaximumTransferLength = ConfigInfo->NumberOfPhysicalBreaks *
PAGE_SIZE;
@@ -316,7 +317,6 @@ VirtIoFindAdapter(
InitializeListHead(&adaptExt->list_head);
InitializeListHead(&adaptExt->complete_list);
-
return SP_RETURN_FOUND;
}
@@ -470,9 +470,7 @@ VirtIoStartIo(
{
PCDB cdb = (PCDB)&Srb->Cdb[0];
-PADAPTER_EXTENSION adaptExt;
-
-adaptExt = (PADAPTER_EXTENSION)DeviceExtension;
+PADAPTER_EXTENSION adaptExt = (PADAPTER_EXTENSION)DeviceExtension;
switch (Srb->Function) {
case SRB_FUNCTION_EXECUTE_SCSI:
@@ -591,7 +589,6 @@ VirtIoStartIo(
return TRUE;
}
-
BOOLEAN
VirtIoInterrupt(
IN PVOID DeviceExtension
@@ -600,12 +597,10 @@ VirtIoInterrupt(
pblk_reqvbr;
unsigned intlen;
unsigned long flags;
-PADAPTER_EXTENSION adaptExt;
+PADAPTER_EXTENSION adaptExt = (PADAPTER_EXTENSION)DeviceExtension;
BOOLEAN isInterruptServiced = FALSE;
PSCSI_REQUEST_BLOCK Srb;
-adaptExt = (PADAPTER_EXTENSION)DeviceExtension;
-
RhelDbgPrint(TRACE_LEVEL_VERBOSE, ("%s (%d)\n", __FUNCTION__,
KeGetCurrentIrql()));
if (VirtIODeviceISR(DeviceExtension)> 0) {
@@ -1019,7 +1014,6 @@ RhelGetLba(
PCDB Cdb
)
{
-
EIGHT_BYTE lba;
switch (Cdb->CDB6GENERIC.OperationCode) {
@@ -1094,7 +1088,7 @@ CompleteDPC(
{
PSCSI_REQUEST_BLOCK Srb = (PSCSI_REQUEST_BLOCK)vbr->req;
PADAPTER_EXTENSION adaptExt = (PADAPTER_EXTENSION)DeviceExtension;
-
+PRHEL_SRB_EXTENSION srbExt = (PRHEL_SRB_EXTENSION)Srb->SrbExtension;
RemoveEntryList(&vbr->list_entry);
#ifdef USE_STORPORT
@@ -1106,13 +1100,22 @@ CompleteDPC(
NULL);
return;
}
-#endif
CompleteSRB(DeviceExtension, Srb);
-#ifndef USE_STORPORT
---adaptExt->requests;
+#else
+ScsiPortNotification(RequestComplete,
+ DeviceExtension,
+ Srb);
+if(srbExt->call_next) {
+ScsiPortNotification(NextLuRequest,
+ DeviceExtension,
+ Srb->PathId,
+ Srb->TargetId,
+ Srb->Lun);
+}
#endif
}
+
#ifdef USE_STORPORT
VOID
CompleteDpcRoutine(
diff --git a/viostor/virtio_stor.h b/viostor/virtio_stor.h
index c00600c..ac143ea 100644
--- a/viostor/virtio_stor.h
+++ b/viostor/virtio_stor.h
@@ -52,7 +52,7 @@ typedef struct VirtIOBufferDescriptor VIO_SG, *PVIO_SG;
#define VIRTIO_BLK_S_UNSUPP2
#define SECTOR_SIZE 512
-#define MAX_PHYS_SEGMENTS 128
+#define MAX_PHYS_SEGMENTS 17 //128
#define VIRTIO_MAX_SG (3+MAX_PHYS_SEGMENTS)
#define IO_PORT_LENGTH 0x40
@@ -105,8 +105,6 @@ typedef struct _ADAPTER_EXTENSION {
LIST_ENTRYcomplete_list;
#ifdef USE_STORPORT
STOR_DPC completion_dpc;
-#else
-ULONG requests;
#endif
BOOLEAN has_sn;
ULONG msix_vectors;
@@ -116,6 +114,10 @@ typedef struct _RHEL_SRB_EXTENSION {
blk_req vbr;
ULONG out;
ULONG in;
+PSCSI_REQUEST_BLOCK srb;
+#ifndef USE_STORPORT
+BOOLEAN call_next;
+#endif
}RHEL_SRB_EXTENSION, *PRHEL_SRB_EXTENSION;
ULONGLONG
diff --git a/viostor/virtio_stor.c b/viostor/virtio_stor.c
index c36b85b..e674dff 100644
--- a/viostor/virtio_stor.c
+++ b/viostor/virtio_stor.c
@@ -215,6 +215,7 @@ VirtIoFindAdapter(
ConfigInfo->Dma32BitAddresses = TRUE;
ConfigInfo->Dma64BitAddresses = TRUE;
ConfigInfo->WmiDataProvider= FALSE;
+
#ifdef USE_STORPORT
ConfigInfo->MapBuffers = STOR_MAP_NON_READ_WRITE_BUFFERS;
ConfigInfo->SynchronizationModel = StorSynchronizeFullDuplex;
@@ -286,7 +287
[PATCH] viostor driver. small fix in startio routine (storport related path).
repository: /home/vadimr/shares/kvm-guest-drivers-windows
branch: XP
commit 7f637876e7f8ef9a18d3baac31a4648034dcedaf
Author: Vadim Rozenfeld
Date: Thu Nov 19 09:50:32 2009 +0200
[PATCH] viostor driver. small fix in startio routine (storport related
path).
Signed-off-by: Vadim Rozenfeld
diff --git a/viostor/virtio_stor_hw_helper.c b/viostor/virtio_stor_hw_helper.c
index 2e61b30..fac9792 100644
--- a/viostor/virtio_stor_hw_helper.c
+++ b/viostor/virtio_stor_hw_helper.c
@@ -27,7 +27,7 @@ SynchronizedAccessRoutine(
if (adaptExt->pci_vq_info.vq->vq_ops->add_buf(adaptExt->pci_vq_info.vq,
&srbExt->vbr.sg[0],
srbExt->out, srbExt->in,
-&srbExt->vbr) == 0){
+&srbExt->vbr)>= 0){
InsertTailList(&adaptExt->list_head,&srbExt->vbr.list_entry);
adaptExt->pci_vq_info.vq->vq_ops->kick(adaptExt->pci_vq_info.vq);
return TRUE;
diff --git a/viostor/virtio_stor_hw_helper.c b/viostor/virtio_stor_hw_helper.c
index 2e61b30..fac9792 100644
--- a/viostor/virtio_stor_hw_helper.c
+++ b/viostor/virtio_stor_hw_helper.c
@@ -27,7 +27,7 @@ SynchronizedAccessRoutine(
if (adaptExt->pci_vq_info.vq->vq_ops->add_buf(adaptExt->pci_vq_info.vq,
&srbExt->vbr.sg[0],
srbExt->out, srbExt->in,
- &srbExt->vbr) == 0){
+ &srbExt->vbr) >= 0){
InsertTailList(&adaptExt->list_head, &srbExt->vbr.list_entry);
adaptExt->pci_vq_info.vq->vq_ops->kick(adaptExt->pci_vq_info.vq);
return TRUE;
Re: Windows XP Viostor driver not building
On Wed, 2009-12-09 at 18:57 -0600, Brian Jackson wrote: > When I try to build it recently I get the following: > > Compiling - virtio_stor_hw_helper.c > 1>errors in directory c:\src\kvm-guest-drivers-windows\viostor > 1>c:\src\kvm-guest-drivers-windows\viostor\virtio_stor_hw_helper.c(99) : > error > C2039: 'requests' : is not a member of '_ADAPTER_EXTENSION' > Compiling - virtio_pci.c > Compiling - virtio_ring.c > Compiling - generating code... > Linking Executable - objfre_wxp_x86\i386\viostor.sys > 1>link : error LNK1181: cannot open input file 'c:\src\kvm-guest-drivers- > windows\viostor\objfre_wxp_x86\i386\virtio_stor_hw_helper.obj' > > > Anybody seen this and know if there's a fix? Will be fixed in a few days. > -- > 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: debugging windows guests
On Wed, 2009-12-16 at 00:39 +0100, Jan Kiszka wrote: > Raindog wrote: > > Hello, > > > > I am researching KVM as a malware analysis platform and had some > > questions about debugging the guest OS. In my case I intend to use > > windows guests. So my questsions are as follows: > > > > Questions: > > > > 1. What instrumentation facilities are their available? > > > > 2. Is it possible to extend the debugging interface so that debugging is > > more transparent to the guest OS? IE: there is still a limit of 4 HW > > breakpoints (which makes me wonder why a LIST is used for them...) > > In accelerated KVM mode, the x86 architecture restricts us to 4 break- > or watchpoints that can be active at the same time. If you switch to > emulation mode, there are no such limits. Actually, I just made use of > this for debugging a subtle stack corruption in a guest, and I had more > than 70 watchpoints active at the same time. It's just "slightly" slower > than KVM... > > > > > 3. I'm not finding any published API for interfacing with KVM/KQEMU/QEMU > > at a low level, for example, for writing custom tracers, etc. Is there > > one? Or is there something similar? > > KVM provides tracepoints for the Linux ftrace framework, see related > documentation of the kernel. If you extend your guest to issue certain > events that the hypervisor sees and traces (e.g. writes to pseudo I/O > ports), you can also trace things inside the guest that are otherwise > invisible to the host. You can WRITE_PORT_BUFFER_UCHAR to com1/com2 port when you are in kernel mode. > I once hacked up an ad-hoc tracing by means of > hypercalls (required some kvm patching). That also worked from guest > userspace - and revealed that even more hypercalls could be called that > way (that's fixed in KVM now). > > > > > > > Bugs: > > > > 1. I hit a bug w/ instruction logging using a RAM based temp folder. If > > I ran w/ the following command line: > > (Version info: QEMU PC emulator version 0.10.50 (qemu-kvm-devel-88)) > > > > qemu-system-x86_64 -hda debian.img -enable-nesting -d in_asm > > -d only works in emulation mode as it relies on dynamic code translation > (TCG). For qemu-kvm, you need to switch to emulation via -no-kvm (for > upstream QEMU, it's the other way around). > > > > > It would successfully log to the tmp log file, but obviously, KVM would > > be disabled. > > > > If I use sudo, it won't log to the file, is this a known issue? > > > > 2. -enable-nesting on AMD hardware using a xen guest OS causes xen to > > GPF somewhere in svm_cpu_up. Is nesting supposed to work w/ Xen based > > guests? > > If your host kernel or kvm-kmod is not 2.6.32 based, update first. A lot > of nested SVM fixes went in recently. If it still fails, put Alex (Graf) > and Joerg (Roedel) on CC. > > Jan > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MS Window virtio drivers certification status
On Mon, 2010-01-11 at 20:43 +0100, Kenni Lund wrote: > 2010/1/11 Yan Vugenfirer : > > > > > >> -Original Message- > >> From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On > >> Behalf Of Saul Tamari > >> Sent: Monday, January 11, 2010 6:26 PM > >> To: Yan Vugenfirer > >> Cc: kvm > >> Subject: Re: MS Window virtio drivers certification status > >> > >> Hi, > >> > >> Are you talking about both network & block drivers? > > > > [YV] Yes. Only difference for block - Windows XP certified driver wasn't > > release with RHEL5.4. It should be in RHEL 5.5. > > Will these block drivers for XP be optimized in terms of performance > or will they, like the current ones, still be slower than the regular > IDE emulated block devices? [1] > > [1] http://article.gmane.org/gmane.comp.emulators.kvm.devel/40762 should be faster. > > Best Regards > Kenni > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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: [PATCHv2 3/4] Add HYPER-V apic access MSRs.
On Sun, 2010-01-17 at 14:20 +0200, Avi Kivity wrote:
> On 01/17/2010 11:03 AM, Gleb Natapov wrote:
>
> > Signed-off-by: Gleb Natapov
> > Signed-off-by: Vadim Rozenfeld
> >
>
> Changelog entry.
>
> >
> > struct kvm_mem_alias {
> > diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> > index ba8c045..4b224f9 100644
> > --- a/arch/x86/kvm/lapic.c
> > +++ b/arch/x86/kvm/lapic.c
> > @@ -1246,3 +1246,34 @@ int kvm_x2apic_msr_read(struct kvm_vcpu *vcpu, u32
> > msr, u64 *data)
> >
> > return 0;
> > }
> > +
> > +int kvm_hv_vapic_msr_write(struct kvm_vcpu *vcpu, u32 reg, u64 data)
> > +{
> > + struct kvm_lapic *apic = vcpu->arch.apic;
> > +
> > + if (!irqchip_in_kernel(vcpu->kvm))
> > + return 1;
> > +
> > + /* if this is ICR write vector before command */
> > + if (reg == APIC_ICR)
> > + apic_reg_write(apic, APIC_ICR2, (u32)(data>> 32));
> > + return apic_reg_write(apic, reg, (u32)data);
> > +}
> > +
> > +int kvm_hv_vapic_msr_read(struct kvm_vcpu *vcpu, u32 reg, u64 *data)
> > +{
> > + struct kvm_lapic *apic = vcpu->arch.apic;
> > + u32 low, high = 0;
> > +
> > + if (!irqchip_in_kernel(vcpu->kvm))
> > + return 1;
> > +
> > + if (apic_reg_read(apic, reg, 4,&low))
> > + return 1;
> > + if (reg == APIC_ICR)
> > + apic_reg_read(apic, APIC_ICR2, 4,&high);
> > +
> > + *data = (((u64)high)<< 32) | low;
> > +
> > + return 0;
> > +}
> >
>
> I prefer putting this in x86.c (maybe later split into hyperv.c).
>
> > diff --git a/arch/x86/kvm/lapic.h b/arch/x86/kvm/lapic.h
> > index 40010b0..d081cb6 100644
> > --- a/arch/x86/kvm/lapic.h
> > +++ b/arch/x86/kvm/lapic.h
> > @@ -48,4 +48,12 @@ void kvm_lapic_sync_to_vapic(struct kvm_vcpu *vcpu);
> >
> > int kvm_x2apic_msr_write(struct kvm_vcpu *vcpu, u32 msr, u64 data);
> > int kvm_x2apic_msr_read(struct kvm_vcpu *vcpu, u32 msr, u64 *data);
> > +
> > +int kvm_hv_vapic_msr_write(struct kvm_vcpu *vcpu, u32 msr, u64 data);
> > +int kvm_hv_vapic_msr_read(struct kvm_vcpu *vcpu, u32 msr, u64 *data);
> > +
> > +static inline bool kvm_hv_vapic_enabled(struct kvm_vcpu *vcpu)
> > +{
> > + return !!(vcpu->arch.hv_vapic& HV_X64_MSR_APIC_ASSIST_PAGE_ENABLE);
> > +}
> >
>
> Are you sure that vapic enabled is equivalent to apic assist page enable?
At least, when it is disable, the EOI interception mechanism won't
work.
>
> !! not required.
>
> > #endif
> > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > index db0b2b1..2fe555c 100644
> > --- a/arch/x86/kvm/x86.c
> > +++ b/arch/x86/kvm/x86.c
> > @@ -632,6 +632,7 @@ static u32 msrs_to_save[] = {
> > #endif
> > MSR_IA32_TSC, MSR_IA32_PERF_STATUS, MSR_IA32_CR_PAT, MSR_VM_HSAVE_PA,
> > HV_X64_MSR_GUEST_OS_ID, HV_X64_MSR_HYPERCALL,
> > + HV_X64_MSR_APIC_ASSIST_PAGE,
> > };
> >
> >
>
> Will be dropped by msr validation.
>
> > static unsigned num_msrs_to_save;
> > @@ -1063,10 +1064,37 @@ static int set_msr_hyperv_pw(struct kvm_vcpu *vcpu,
> > u32 msr, u64 data)
> >
> > static int set_msr_hyperv(struct kvm_vcpu *vcpu, u32 msr, u64 data)
> > {
> > - pr_unimpl(vcpu, "HYPER-V unimplemented wrmsr: 0x%x data 0x%llx\n",
> > - msr, data);
> > + switch (msr) {
> > + case HV_X64_MSR_APIC_ASSIST_PAGE: {
> > + unsigned long vaddr;
> > + void *addr;
> > + struct page *page;
> > + vcpu->arch.hv_vapic = data;
> > + if (!kvm_hv_vapic_enabled(vcpu))
> > + break;
> > + vaddr = gfn_to_hva(vcpu->kvm, data>>
> > + HV_X64_MSR_APIC_ASSIST_PAGE_ADDRESS_SHIFT);
> > + if (kvm_is_error_hva(vaddr))
> > + return 1;
> > + page = virt_to_page(vaddr);
> >
>
> virt_to_page() takes a kernel address, not a user address. This is
> get_user_pages(). But I think the whole thing is done better with
> put_user().
>
> > + addr = kmap_atomic(page, KM_USER0);
> > + clear_user_page(addr, vaddr, page);
> > + kunmap_atomic(addr, KM_USER0);
> >
>
> Surprising that clear_user_page needs kmap_atomic() (but true).
>
--
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: unable to load viostor driver in w2k3 x86
On Wed, 2010-08-04 at 14:53 +0200, Gerrit van der Kolk wrote: > I managed to get libvirtd out of the loop. I'm starting the vm with: > qemu-kvm -S -M fedora-13 -enable-kvm -m 2048 -smp > 2,sockets=1,cores=2,threads=1 -name test -uuid > 5ffc03bf-3562-1c90-9543-a64b2416a4a1 -nodefaults -chardev > socket,id=monitor,path=/var/lib/libvirt/qemu/test.monitor,server,nowait -mon > chardev=monitor,mode=readline -rtc base=localtime -boot dc -drive > file=/var/lib/libvirt/images/test-1.img,if=ide,boot=on,format=raw -chardev > pty,id=serial0 -device isa-serial,chardev=serial0 -usb -device > usb-tablet,id=input0 -vga std -drive > file=/var/lib/libvirt/images/test-3.img,if=virtio,format=raw > > host os is a fully updated fedora13 system with kernel > 2.6.33.6-147.2.4.fc13.x86_64. Guestos is windows 2003 SP2 x86 with miniport > hotfix KB932755 applied. Didn't solve the problem either. > > Anyone out there where the virtio storage does work with windows? I'm a > little out of ideas at the moment. > Hi, Gerrit. Code 10 usually indicates a problem in FindAdapter routine. It could be one of two reasons for that: - invalid HW resources reported to guest; - version mismatch between viostor driver and qemu. Best regards, Vadim. > Regards, > > Gerrit > > -Original Message- > From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf > Of Gerrit van der Kolk > Sent: Monday, August 02, 2010 3:44 PM > To: 'kvm@vger.kernel.org' > Subject: unable to load viostor driver in w2k3 x86 > > Hello, > > I've been trying to use kvm with viostor, but the driver fails to load(Code > 10). I'm using version 4.3.0.17241 of the driver. > > Info pci @ the qemu console gives: (qemu) info pci > info pci > Bus 0, device 0, function 0: > Host bridge: PCI device 8086:1237 > id "" > Bus 0, device 1, function 0: > ISA bridge: PCI device 8086:7000 > id "" > Bus 0, device 1, function 1: > IDE controller: PCI device 8086:7010 > BAR4: I/O at 0xc000 [0xc00f]. > id "" > Bus 0, device 1, function 2: > USB controller: PCI device 8086:7020 > IRQ 11. > BAR4: I/O at 0xc020 [0xc03f]. > id "" > Bus 0, device 1, function 3: > Bridge: PCI device 8086:7113 > IRQ 9. > id "" > Bus 0, device 2, function 0: > VGA controller: PCI device 1234: > BAR0: 32 bit prefetchable memory at 0xf000 [0xf0ff]. > id "" > Bus 0, device 3, function 0: > RAM controller: PCI device 1af4:1002 > IRQ 11. > BAR0: I/O at 0xc040 [0xc05f]. > id "balloon0" > Bus 0, device 4, function 0: > SCSI controller: PCI device 1af4:1001 > IRQ 10. > BAR0: I/O at 0x [0x003e]. > BAR1: 32 bit memory at 0x [0x0ffe]. > id "virtio-disk0" > Bus 0, device 7, function 0: > Ethernet controller: PCI device 1af4:1000 > IRQ 5. > BAR0: I/O at 0xc0c0 [0xc0df]. > BAR1: 32 bit memory at 0xf1001000 [0xf1001fff]. > BAR6: 32 bit memory at 0x [0xfffe]. > id "net0" > > Windows detects the controller and finds the driver automatically. But after > this there is the yellow exclamation mark with the code 10. > I'm using libvirt with kvm. The configuration is: > > > base > d6d143d6-387f-8252-f7b0-419a76d4c609 > 2097152 > 2097152 > 2 > > hvm > > > > > > > > > > core2duo > > > > destroy > restart > restart > > /usr/bin/qemu-kvm > > > > > > > > > > > > > > > > > >function='0x0'/> > > >function='0x1'/> > > > > > > >function='0x0'/> > > > > > > > >function='0x0'/> > > > > > > Does anyone have any idea what is going on here? > > Regards, > > Gerrit van der Kolk > > The information contained in this communication is confidential, intended > solely for the use of the individual or entity to whom it is addressed and > may be legally privileged and protected by professional secrecy. Access to > this message by anyone else is unauthorized. If you are not the intended > recipient, any disclosure, copying, or distribution of the message, or any > action or omission taken by you in reliance on it is prohibited and may be > unlawful. Please immediately contact the sender if you have received this > message in error. This email does not constitute any commitment from Cordys > Holding BV or any of its subsidiaries except when expressly agreed in a > written agreement between the intended recipient and Cordys Holding BV or its > subsidiaries. Cordys is neither liable for the proper and complete > transmission of the information contained in this communication nor for any > delay in its receipt.
Re: [RFC PATCH 1/2] Hyper-H reference counter
On Thu, 2013-05-16 at 16:45 +0200, Paolo Bonzini wrote: > Il 16/05/2013 16:26, Vadim Rozenfeld ha scritto: > >>>>> > >>> > >>>>> > >>> Yes, I have this check added in the second patch. > >>>>> > >>> > >>>> > >> Move it here please. > >>> > > OK, will do it. > >> > > >> > Or better, remove all the handling of HV_X64_MSR_REFERENCE_TSC from this > >> > patch, and leave it all to the second. > >> > > > What for? Could you please elaborate? > > To make code reviewable. Add one MSR here, the other in the second patch. removing HV_X64_MSR_REFERENCE_TSC will make this particular patch completely non-functional. > > Paolo -- 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
[RFC PATCH v2 0/2] Hyper-V timers
This RFC series adds support for two Hyper-V timer services - a per-partition reference time counter, and a partition reference time enlightenment. Vadim Rozenfeld (2): add support for Hyper-V reference time counter add support for Hyper-V invariant TSC arch/x86/include/asm/kvm_host.h| 2 ++ arch/x86/include/uapi/asm/hyperv.h | 14 + arch/x86/kvm/x86.c | 43 +- include/uapi/linux/kvm.h | 1 + 4 files changed, 59 insertions(+), 1 deletion(-) -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v2 1/2] add support for Hyper-V reference time counter
Signed-off: Peter Lieven
Signed-off: Gleb Natapov
Signed-off: Vadim Rozenfeld
v1 -> v2
1. mark TSC page dirty as suggested by
Eric Northup and Gleb
2. disable local irq when calling get_kernel_ns,
as it was done by Peter Lieven
3. move check for TSC page enable from second patch
to this one.
---
arch/x86/include/asm/kvm_host.h| 2 ++
arch/x86/include/uapi/asm/hyperv.h | 14 ++
arch/x86/kvm/x86.c | 39 +-
include/uapi/linux/kvm.h | 1 +
4 files changed, 55 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 3741c65..f0fee35 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -575,6 +575,8 @@ struct kvm_arch {
/* fields used by HYPER-V emulation */
u64 hv_guest_os_id;
u64 hv_hypercall;
+ u64 hv_ref_count;
+ u64 hv_tsc_page;
#ifdef CONFIG_KVM_MMU_AUDIT
int audit_point;
diff --git a/arch/x86/include/uapi/asm/hyperv.h
b/arch/x86/include/uapi/asm/hyperv.h
index b80420b..890dfc3 100644
--- a/arch/x86/include/uapi/asm/hyperv.h
+++ b/arch/x86/include/uapi/asm/hyperv.h
@@ -136,6 +136,9 @@
/* MSR used to read the per-partition time reference counter */
#define HV_X64_MSR_TIME_REF_COUNT 0x4020
+/* A partition's reference time stamp counter (TSC) page */
+#define HV_X64_MSR_REFERENCE_TSC 0x4021
+
/* Define the virtual APIC registers */
#define HV_X64_MSR_EOI 0x4070
#define HV_X64_MSR_ICR 0x4071
@@ -179,6 +182,9 @@
#define HV_X64_MSR_APIC_ASSIST_PAGE_ADDRESS_MASK \
(~((1ull << HV_X64_MSR_APIC_ASSIST_PAGE_ADDRESS_SHIFT) - 1))
+#define HV_X64_MSR_TSC_REFERENCE_ENABLE0x0001
+#define HV_X64_MSR_TSC_REFERENCE_ADDRESS_SHIFT 12
+
#define HV_PROCESSOR_POWER_STATE_C00
#define HV_PROCESSOR_POWER_STATE_C11
#define HV_PROCESSOR_POWER_STATE_C22
@@ -191,4 +197,12 @@
#define HV_STATUS_INVALID_ALIGNMENT4
#define HV_STATUS_INSUFFICIENT_BUFFERS 19
+typedef struct _HV_REFERENCE_TSC_PAGE {
+ __u32 TscSequence;
+ __u32 Rserved1;
+ __u64 TscScale;
+ __s64 TscOffset;
+} HV_REFERENCE_TSC_PAGE, *PHV_REFERENCE_TSC_PAGE;
+
+
#endif
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 8d28810..9645dab 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -843,7 +843,7 @@ EXPORT_SYMBOL_GPL(kvm_rdpmc);
static u32 msrs_to_save[] = {
MSR_KVM_SYSTEM_TIME, MSR_KVM_WALL_CLOCK,
MSR_KVM_SYSTEM_TIME_NEW, MSR_KVM_WALL_CLOCK_NEW,
- HV_X64_MSR_GUEST_OS_ID, HV_X64_MSR_HYPERCALL,
+ HV_X64_MSR_GUEST_OS_ID, HV_X64_MSR_HYPERCALL, HV_X64_MSR_TIME_REF_COUNT,
HV_X64_MSR_APIC_ASSIST_PAGE, MSR_KVM_ASYNC_PF_EN, MSR_KVM_STEAL_TIME,
MSR_KVM_PV_EOI_EN,
MSR_IA32_SYSENTER_CS, MSR_IA32_SYSENTER_ESP, MSR_IA32_SYSENTER_EIP,
@@ -1788,6 +1788,8 @@ static bool kvm_hv_msr_partition_wide(u32 msr)
switch (msr) {
case HV_X64_MSR_GUEST_OS_ID:
case HV_X64_MSR_HYPERCALL:
+ case HV_X64_MSR_REFERENCE_TSC:
+ case HV_X64_MSR_TIME_REF_COUNT:
r = true;
break;
}
@@ -1827,6 +1829,29 @@ static int set_msr_hyperv_pw(struct kvm_vcpu *vcpu, u32
msr, u64 data)
if (__copy_to_user((void __user *)addr, instructions, 4))
return 1;
kvm->arch.hv_hypercall = data;
+ local_irq_disable();
+ kvm->arch.hv_ref_count = get_kernel_ns();
+ local_irq_enable();
+ break;
+ }
+ case HV_X64_MSR_REFERENCE_TSC: {
+ u64 gfn;
+ unsigned long addr;
+ HV_REFERENCE_TSC_PAGE tsc_ref;
+ tsc_ref.TscSequence = 0;
+ if (!(data & HV_X64_MSR_TSC_REFERENCE_ENABLE)) {
+ kvm->arch.hv_tsc_page = data;
+ break;
+ }
+ gfn = data >> HV_X64_MSR_TSC_REFERENCE_ADDRESS_SHIFT;
+ addr = gfn_to_hva(kvm, data >>
+ HV_X64_MSR_TSC_REFERENCE_ADDRESS_SHIFT);
+ if (kvm_is_error_hva(addr))
+ return 1;
+ if (__copy_to_user((void __user *)addr, &tsc_ref,
sizeof(tsc_ref)))
+ return 1;
+ mark_page_dirty(kvm, gfn);
+ kvm->arch.hv_tsc_page = data;
break;
}
default:
@@ -2253,6 +2278,17 @@ static int get_msr_hyperv_pw(struct kvm_vcpu *vcpu, u32
msr, u64 *pdata)
case HV_X64_MSR_HYPERCALL:
data = kvm->arch.hv_hypercall;
break;
+ case HV_X64_MSR_TIME_REF_COUNT: {
+ u64 now_ns;
+
