Re: [kvm-devel] [PATCH 6/6] kvm: qemu: Enable EPT support for real mode
Yang, Sheng wrote:
> On Tuesday 22 April 2008 18:16:41 Avi Kivity wrote:
>
>> Yang, Sheng wrote:
>>
>>> From 73c33765f3d879001818cd0719038c78a0c65561 Mon Sep 17 00:00:00 2001
>>> From: Sheng Yang <[EMAIL PROTECTED]>
>>> Date: Fri, 18 Apr 2008 17:15:39 +0800
>>> Subject: [PATCH] kvm: qemu: Enable EPT support for real mode
>>>
>>> This patch build a identity page table on the last page of VGA bios, and
>>> use it as the guest page table in nonpaging mode for EPT.
>>>
>> Doing this in qemu means older versions of qemu can't work with an
>> ept-enabled kernel. Also, placing the table in the vga bios might
>> conflict with video card assignment to a guest.
>>
>> Suggest placing this near the realmode tss (see vmx.c:init_rmode_tss())
>> which serves a similar function.
>>
>
> Something like this? (along with one page reserved in e820 table)
>
> I put the page it into 0xfffbc000 now. But I think the following implement is
> not very elegant... Too complex compared to the qemu one.
>
> BTW: The S/R and live migration problem was fixed.
>
>
Ah, good.
>
> +static int init_rmode_identity_map(struct kvm *kvm)
> +{
> + int i, r, ret;
> + pfn_t identity_map_pfn;
> + u32 table[PT32_ENT_PER_PAGE];
>
That's 4KB. On i386 with 4K stacks, this may cause a stack overflow.
Even with 8K stacks you're on thin ice here, with the temperature
rapidly rising.
> +
> + if (kvm->arch.ept_identity_pagetable_done)
> + return 1;
> + ret = 0;
> + identity_map_pfn = VMX_EPT_IDENTITY_PAGETABLE_ADDR >> PAGE_SHIFT;
> + r = kvm_clear_guest_page(kvm, identity_map_pfn, 0, PAGE_SIZE);
> + if (r < 0)
> + goto out;
> + /*
> + * Set up identity-mapping pagetable for EPT in real mode, also verify
> + * the contain of page
>
s/contain/contents/
> + * 0xe7 = _PAGE_PRESENT | _PAGE_RW | _PAGE_USER | _PAGE_ACCESSED |
> + *_PAGE_DIRTY | _PAGE_PSE
> + */
> + for (i = 0; i < PT32_ENT_PER_PAGE; i++)
> + table[i] = (i << 22) + 0xe7;
>
Instead of the comment, you can put the identifiers into the code
instead of 0xe7. And, to avoid the stack overflow, simply use
kvm_write_guest() here.
> +static int alloc_identity_pagetable(struct kvm *kvm)
> +{
> + struct kvm_userspace_memory_region kvm_userspace_mem;
> + int r = 0;
> +
> + down_write(&kvm->slots_lock);
> + if (kvm->arch.ept_identity_pagetable)
> + goto out;
> + kvm_userspace_mem.slot = IDENTITY_PAGETABLE_PRIVATE_MEMSLOT;
> + kvm_userspace_mem.flags = 0;
> + kvm_userspace_mem.guest_phys_addr = VMX_EPT_IDENTITY_PAGETABLE_ADDR;
> + kvm_userspace_mem.memory_size = PAGE_SIZE;
> + r = __kvm_set_memory_region(kvm, &kvm_userspace_mem, 0);
> + if (r)
> + goto out;
> +
> + down_read(¤t->mm->mmap_sem);
> + kvm->arch.ept_identity_pagetable = gfn_to_page(kvm,
> + VMX_EPT_IDENTITY_PAGETABLE_ADDR >> PAGE_SHIFT);
> + up_read(¤t->mm->mmap_sem);
> +out:
> + up_write(&kvm->slots_lock);
> + return r;
> +}
>
There's already a memslot for the tss, no? Why not expand it by a page?
> +
> static void allocate_vpid(struct vcpu_vmx *vmx)
> {
> int vpid;
> @@ -1904,6 +1960,15 @@ static int vmx_vcpu_setup(struct vcpu_vmx *vmx)
> return 0;
> }
>
> +static int init_rmode(struct kvm *kvm)
> +{
> + if (!init_rmode_tss(kvm))
> + return 0;
> + if (!init_rmode_identity_map(kvm))
> + return 0;
> + return 1;
> +}
> +
> static int vmx_vcpu_reset(struct kvm_vcpu *vcpu)
> {
> struct vcpu_vmx *vmx = to_vmx(vcpu);
> @@ -1911,7 +1976,7 @@ static int vmx_vcpu_reset(struct kvm_vcpu *vcpu)
> int ret;
>
> down_read(&vcpu->kvm->slots_lock);
> - if (!init_rmode_tss(vmx->vcpu.kvm)) {
> + if (!init_rmode(vmx->vcpu.kvm)) {
> ret = -ENOMEM;
> goto out;
> }
> @@ -2967,6 +3032,10 @@ static struct kvm_vcpu *vmx_create_vcpu(struct kvm
> *kvm, unsigned int id)
> if (alloc_apic_access_page(kvm) != 0)
> goto free_vmcs;
>
> + if (vm_need_ept())
> + if (alloc_identity_pagetable(kvm) != 0)
> + goto free_vmcs;
> +
> return &vmx->vcpu;
>
> free_vmcs:
> diff --git a/arch/x86/kvm/vmx.h b/arch/x86/kvm/vmx.h
> index 8f662e3..469a107 100644
> --- a/arch/x86/kvm/vmx.h
> +++ b/arch/x86/kvm/vmx.h
> @@ -340,6 +340,7 @@ enum vmcs_field {
> #define MSR_IA32_FEATURE_CONTROL_VMXON_ENABLED 0x4
>
> #define APIC_ACCESS_PAGE_PRIVATE_MEMSLOT 9
> +#define IDENTITY_PAGETABLE_PRIVATE_MEMSLOT 10
>
> #define VMX_NR_VPIDS (1 << 16)
> #define VMX_VPID_EXTENT_SINGLE_CONTEXT 1
> @@ -362,4 +363,6 @@ enum vmcs_field {
> #define VMX_EPT_FAKE_ACCESSED_MASK (1ul << 62)
> #define VMX_EPT_FAKE_DIRTY_MASK (1ul << 63)
>
> +#define VMX_EPT_IDENTITY_PAGETABLE_ADDR 0x
Re: [kvm-devel] [PATCH 6/6] kvm: qemu: Enable EPT support for real mode
On Thursday 24 April 2008 15:15:30 Avi Kivity wrote:
> Yang, Sheng wrote:
> > On Tuesday 22 April 2008 18:16:41 Avi Kivity wrote:
> >> Yang, Sheng wrote:
> >>> From 73c33765f3d879001818cd0719038c78a0c65561 Mon Sep 17 00:00:00 2001
> >>> From: Sheng Yang <[EMAIL PROTECTED]>
> >>> Date: Fri, 18 Apr 2008 17:15:39 +0800
> >>> Subject: [PATCH] kvm: qemu: Enable EPT support for real mode
> >>>
> >>> This patch build a identity page table on the last page of VGA bios,
> >>> and use it as the guest page table in nonpaging mode for EPT.
> >>
> >> Doing this in qemu means older versions of qemu can't work with an
> >> ept-enabled kernel. Also, placing the table in the vga bios might
> >> conflict with video card assignment to a guest.
> >>
> >> Suggest placing this near the realmode tss (see vmx.c:init_rmode_tss())
> >> which serves a similar function.
> >
> > Something like this? (along with one page reserved in e820 table)
> >
> > I put the page it into 0xfffbc000 now. But I think the following
> > implement is not very elegant... Too complex compared to the qemu one.
> >
> > BTW: The S/R and live migration problem was fixed.
>
> Ah, good.
>
> > +static int init_rmode_identity_map(struct kvm *kvm)
> > +{
> > + int i, r, ret;
> > + pfn_t identity_map_pfn;
> > + u32 table[PT32_ENT_PER_PAGE];
>
> That's 4KB. On i386 with 4K stacks, this may cause a stack overflow.
> Even with 8K stacks you're on thin ice here, with the temperature
> rapidly rising.
Oops... I forgot that...
> > +
> > + if (kvm->arch.ept_identity_pagetable_done)
> > + return 1;
> > + ret = 0;
> > + identity_map_pfn = VMX_EPT_IDENTITY_PAGETABLE_ADDR >> PAGE_SHIFT;
> > + r = kvm_clear_guest_page(kvm, identity_map_pfn, 0, PAGE_SIZE);
> > + if (r < 0)
> > + goto out;
> > + /*
> > +* Set up identity-mapping pagetable for EPT in real mode, also verify
> > +* the contain of page
>
> s/contain/contents/
>
> > +* 0xe7 = _PAGE_PRESENT | _PAGE_RW | _PAGE_USER | _PAGE_ACCESSED |
> > +*_PAGE_DIRTY | _PAGE_PSE
> > +*/
> > + for (i = 0; i < PT32_ENT_PER_PAGE; i++)
> > + table[i] = (i << 22) + 0xe7;
>
> Instead of the comment, you can put the identifiers into the code
> instead of 0xe7. And, to avoid the stack overflow, simply use
> kvm_write_guest() here.
OK.
> > +static int alloc_identity_pagetable(struct kvm *kvm)
> > +{
> > + struct kvm_userspace_memory_region kvm_userspace_mem;
> > + int r = 0;
> > +
> > + down_write(&kvm->slots_lock);
> > + if (kvm->arch.ept_identity_pagetable)
> > + goto out;
> > + kvm_userspace_mem.slot = IDENTITY_PAGETABLE_PRIVATE_MEMSLOT;
> > + kvm_userspace_mem.flags = 0;
> > + kvm_userspace_mem.guest_phys_addr = VMX_EPT_IDENTITY_PAGETABLE_ADDR;
> > + kvm_userspace_mem.memory_size = PAGE_SIZE;
> > + r = __kvm_set_memory_region(kvm, &kvm_userspace_mem, 0);
> > + if (r)
> > + goto out;
> > +
> > + down_read(¤t->mm->mmap_sem);
> > + kvm->arch.ept_identity_pagetable = gfn_to_page(kvm,
> > + VMX_EPT_IDENTITY_PAGETABLE_ADDR >> PAGE_SHIFT);
> > + up_read(¤t->mm->mmap_sem);
> > +out:
> > + up_write(&kvm->slots_lock);
> > + return r;
> > +}
>
> There's already a memslot for the tss, no? Why not expand it by a page?
Agree.
> > +
> > static void allocate_vpid(struct vcpu_vmx *vmx)
> > {
> > int vpid;
> > @@ -1904,6 +1960,15 @@ static int vmx_vcpu_setup(struct vcpu_vmx *vmx)
> > return 0;
> > }
> >
> > +static int init_rmode(struct kvm *kvm)
> > +{
> > + if (!init_rmode_tss(kvm))
> > + return 0;
> > + if (!init_rmode_identity_map(kvm))
> > + return 0;
> > + return 1;
> > +}
> > +
> > static int vmx_vcpu_reset(struct kvm_vcpu *vcpu)
> > {
> > struct vcpu_vmx *vmx = to_vmx(vcpu);
> > @@ -1911,7 +1976,7 @@ static int vmx_vcpu_reset(struct kvm_vcpu *vcpu)
> > int ret;
> >
> > down_read(&vcpu->kvm->slots_lock);
> > - if (!init_rmode_tss(vmx->vcpu.kvm)) {
> > + if (!init_rmode(vmx->vcpu.kvm)) {
> > ret = -ENOMEM;
> > goto out;
> > }
> > @@ -2967,6 +3032,10 @@ static struct kvm_vcpu *vmx_create_vcpu(struct kvm
> > *kvm, unsigned int id)
> > if (alloc_apic_access_page(kvm) != 0)
> > goto free_vmcs;
> >
> > + if (vm_need_ept())
> > + if (alloc_identity_pagetable(kvm) != 0)
> > + goto free_vmcs;
> > +
> > return &vmx->vcpu;
> >
> > free_vmcs:
> > diff --git a/arch/x86/kvm/vmx.h b/arch/x86/kvm/vmx.h
> > index 8f662e3..469a107 100644
> > --- a/arch/x86/kvm/vmx.h
> > +++ b/arch/x86/kvm/vmx.h
> > @@ -340,6 +340,7 @@ enum vmcs_field {
> > #define MSR_IA32_FEATURE_CONTROL_VMXON_ENABLED 0x4
> >
> > #define APIC_ACCESS_PAGE_PRIVATE_MEMSLOT 9
> > +#define IDENTITY_PAGETABLE_PRIVATE_MEMSLOT 10
> >
> > #define VMX_NR_VPIDS (1 << 16)
> > #define VMX_VPID_EXTENT_SINGLE_CONTEXT 1
> > @@ -362,4 +363,6 @@ enum vmcs_field {
> >
[kvm-devel] He went so deep inside me
Stop being the joke among the ladies, visit our website here now http://www.oeoiage.com/ - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH]: Fix MSR_K7_EVNTSEL{0,3} for SVM
Chris Lalancette wrote: > Avi, Joerg, > While trying to boot a RHEL-4 guest on latest KVM tip on an AMD machine, > I > found that the guest would consistently crash when trying to setup the NMI > watchdog. I traced it down to the following commit: > > 51ef1ac7b23ee32bfcc61c229d634fdc1c68b38a > > It seems that in that commit, the K7_EVNTSEL MSR's were set to fail if the > data > != 0. That test is actually fine, the problem is how the code around it is > generated. That is, we are only supposed to go to unhandled if data != 0; but > for some reason, we are *always* going to unhandled, even when the data == 0. > That causes RHEL-4 kernel to crash. If I rearrange the code to look like > this: > > case MSR_K7_EVNTSEL0: > case MSR_K7_EVNTSEL1: > case MSR_K7_EVNTSEL2: > case MSR_K7_EVNTSEL3: > > if (data != 0) > return kvm_set_msr_common(vcpu, ecx, data); > > default: > return kvm_set_msr_common(vcpu, ecx, data); > } > > Then everything works again. A patch that does just this is attached. It > might > be slightly nicer to say "if (data == 0) return 0" and then just fall through > to > the default case, but I don't much care either way. > You mean the gcc generates wrong code? It seems fine here (though wonderfully obfuscated). Can you attach an objdump -Sr svm.o? Also, what gcc version are you using? -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 6/6] kvm: qemu: Enable EPT support for real mode
Yang, Sheng wrote: >> Why not use ept_identity_pagetable != NULL to encode >> ept_identity_pagetable_done? >> > > ept_identity_pagetable_done was used to indicate if the pagetable was setted > up, and ept_identity_pagetable was used to indicate if the page used for > pagetable was allocated... I don't want to run alloc_identity_pagetable() > again and again and again... Another method is read several bits at the front > of page to tell if the pagetable was setted up, but somehow tricky... > No, better to avoid tricks. But rmode_tss is only allocated once, so if you unify the allocations, the identity table will also only be allocated once. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 6/6] kvm: qemu: Enable EPT support for real mode
On Thursday 24 April 2008 15:37:53 Avi Kivity wrote: > Yang, Sheng wrote: > >> Why not use ept_identity_pagetable != NULL to encode > >> ept_identity_pagetable_done? > > > > ept_identity_pagetable_done was used to indicate if the pagetable was > > setted up, and ept_identity_pagetable was used to indicate if the page > > used for pagetable was allocated... I don't want to run > > alloc_identity_pagetable() again and again and again... Another method is > > read several bits at the front of page to tell if the pagetable was > > setted up, but somehow tricky... > > No, better to avoid tricks. But rmode_tss is only allocated once, so if > you unify the allocations, the identity table will also only be > allocated once. But set_tss_addr() is a x86_ops, if the identity mapping allocation using the same approach, another null function should be added into SVM side, but this thing is VMX specific one... -- Thanks Yang, Sheng - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 6/6] kvm: qemu: Enable EPT support for real mode
Yang, Sheng wrote: > On Thursday 24 April 2008 15:37:53 Avi Kivity wrote: > >> Yang, Sheng wrote: >> Why not use ept_identity_pagetable != NULL to encode ept_identity_pagetable_done? >>> ept_identity_pagetable_done was used to indicate if the pagetable was >>> setted up, and ept_identity_pagetable was used to indicate if the page >>> used for pagetable was allocated... I don't want to run >>> alloc_identity_pagetable() again and again and again... Another method is >>> read several bits at the front of page to tell if the pagetable was >>> setted up, but somehow tricky... >>> >> No, better to avoid tricks. But rmode_tss is only allocated once, so if >> you unify the allocations, the identity table will also only be >> allocated once. >> > > But set_tss_addr() is a x86_ops, if the identity mapping allocation using the > same approach, another null function should be added into SVM side, but this > thing is VMX specific one... > We could rename set_tss_addr() to mean set_tss_and_ept_identity_pt_addr(), but it looks like the ioctl expects just three pages... so let's keep the flag for now. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 3/4] kvm/host: fix paravirt clocksource to be compatible with xen.
Signed-off-by: Gerd Hoffmann <[EMAIL PROTECTED]>
---
arch/x86/kvm/x86.c | 63 +++
1 files changed, 53 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 0ce5563..45b71c6 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -493,7 +493,7 @@ static void kvm_write_wall_clock(struct kvm *kvm, gpa_t
wall_clock)
{
static int version;
struct kvm_wall_clock wc;
- struct timespec wc_ts;
+ struct timespec now,sys,boot;
if (!wall_clock)
return;
@@ -502,9 +502,16 @@ static void kvm_write_wall_clock(struct kvm *kvm, gpa_t
wall_clock)
kvm_write_guest(kvm, wall_clock, &version, sizeof(version));
- wc_ts = current_kernel_time();
- wc.wc_sec = wc_ts.tv_sec;
- wc.wc_nsec = wc_ts.tv_nsec;
+#if 0
+ /* Hmm, getboottime() isn't exported to modules ... */
+ getboottime(&boot);
+#else
+ now = current_kernel_time();
+ ktime_get_ts(&sys);
+ boot = ns_to_timespec(timespec_to_ns(&now) - timespec_to_ns(&sys));
+#endif
+ wc.wc_sec = boot.tv_sec;
+ wc.wc_nsec = boot.tv_nsec;
wc.wc_version = version;
kvm_write_guest(kvm, wall_clock, &wc, sizeof(wc));
@@ -537,20 +544,58 @@ static void kvm_write_guest_time(struct kvm_vcpu *v)
/*
* The interface expects us to write an even number signaling that the
* update is finished. Since the guest won't see the intermediate
-* state, we just write "2" at the end
+* state, we just increase by 2 at the end.
*/
- vcpu->hv_clock.version = 2;
+ vcpu->hv_clock.version += 2;
shared_kaddr = kmap_atomic(vcpu->time_page, KM_USER0);
memcpy(shared_kaddr + vcpu->time_offset, &vcpu->hv_clock,
- sizeof(vcpu->hv_clock));
+ sizeof(vcpu->hv_clock));
kunmap_atomic(shared_kaddr, KM_USER0);
mark_page_dirty(v->kvm, vcpu->time >> PAGE_SHIFT);
}
+static uint32_t div_frac(uint32_t dividend, uint32_t divisor)
+{
+ uint32_t quotient, remainder;
+
+ __asm__ ( "divl %4"
+ : "=a" (quotient), "=d" (remainder)
+ : "0" (0), "1" (dividend), "r" (divisor) );
+ return quotient;
+}
+
+static void kvm_set_time_scale(uint32_t tsc_khz, struct kvm_vcpu_time_info
*hv_clock)
+{
+ uint64_t nsecs = 10LL;
+ int32_t shift = 0;
+ uint64_t tps64;
+ uint32_t tps32;
+
+ tps64 = tsc_khz * 1000LL;
+ while (tps64 > nsecs*2) {
+ tps64 >>= 1;
+ shift--;
+ }
+
+ tps32 = (uint32_t)tps64;
+ while (tps32 <= (uint32_t)nsecs) {
+ tps32 <<= 1;
+ shift++;
+ }
+
+ hv_clock->tsc_shift = shift;
+ hv_clock->tsc_to_system_mul = div_frac(nsecs, tps32);
+
+#if 0
+ printk(KERN_DEBUG "%s: tsc_khz %u, tsc_shift %d, tsc_mul %u\n",
+ __FUNCTION__, tsc_khz, hv_clock->tsc_shift,
+ hv_clock->tsc_to_system_mul);
+#endif
+}
int kvm_set_msr_common(struct kvm_vcpu *vcpu, u32 msr, u64 data)
{
@@ -599,9 +644,7 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, u32 msr, u64
data)
/* ...but clean it before doing the actual write */
vcpu->arch.time_offset = data & ~(PAGE_MASK | 1);
- vcpu->arch.hv_clock.tsc_to_system_mul =
- clocksource_khz2mult(tsc_khz, 22);
- vcpu->arch.hv_clock.tsc_shift = 22;
+ kvm_set_time_scale(tsc_khz, &vcpu->arch.hv_clock);
down_read(¤t->mm->mmap_sem);
vcpu->arch.time_page =
--
1.5.4.1
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 0/4] paravirt clock patches
Hi folks, My first attempt to send out a patch series with git ... The patches fix the kvm paravirt clocksource code to be compatible with xen and they also factor out some code which can be shared into a separate source files used by both kvm and xen. cheers, Gerd - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 2/4] Make xen use the generic paravirt clocksource code.
Signed-off-by: Gerd Hoffmann <[EMAIL PROTECTED]>
---
arch/x86/xen/Kconfig |1 +
arch/x86/xen/time.c | 110 +-
2 files changed, 12 insertions(+), 99 deletions(-)
diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index 4d5f264..47f0cdc 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -5,6 +5,7 @@
config XEN
bool "Xen guest support"
select PARAVIRT
+ select PARAVIRT_CLOCK
depends on X86_32
depends on X86_CMPXCHG && X86_TSC && !NEED_MULTIPLE_NODES &&
!(X86_VISWS || X86_VOYAGER)
help
diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index c39e1a5..3d5f945 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -13,6 +13,7 @@
#include
#include
+#include
#include
#include
@@ -30,17 +31,6 @@
static cycle_t xen_clocksource_read(void);
-/* These are perodically updated in shared_info, and then copied here. */
-struct shadow_time_info {
- u64 tsc_timestamp; /* TSC at last update of time vals. */
- u64 system_timestamp; /* Time, in nanosecs, since boot.*/
- u32 tsc_to_nsec_mul;
- int tsc_shift;
- u32 version;
-};
-
-static DEFINE_PER_CPU(struct shadow_time_info, shadow_time);
-
/* runstate info updated by Xen */
static DEFINE_PER_CPU(struct vcpu_runstate_info, runstate);
@@ -230,95 +220,14 @@ unsigned long xen_cpu_khz(void)
return xen_khz;
}
-/*
- * Reads a consistent set of time-base values from Xen, into a shadow data
- * area.
- */
-static unsigned get_time_values_from_xen(void)
-{
- struct vcpu_time_info *src;
- struct shadow_time_info *dst;
-
- /* src is shared memory with the hypervisor, so we need to
- make sure we get a consistent snapshot, even in the face of
- being preempted. */
- src = &__get_cpu_var(xen_vcpu)->time;
- dst = &__get_cpu_var(shadow_time);
-
- do {
- dst->version = src->version;
- rmb(); /* fetch version before data */
- dst->tsc_timestamp = src->tsc_timestamp;
- dst->system_timestamp = src->system_time;
- dst->tsc_to_nsec_mul = src->tsc_to_system_mul;
- dst->tsc_shift = src->tsc_shift;
- rmb(); /* test version after fetching data */
- } while ((src->version & 1) | (dst->version ^ src->version));
-
- return dst->version;
-}
-
-/*
- * Scale a 64-bit delta by scaling and multiplying by a 32-bit fraction,
- * yielding a 64-bit result.
- */
-static inline u64 scale_delta(u64 delta, u32 mul_frac, int shift)
-{
- u64 product;
-#ifdef __i386__
- u32 tmp1, tmp2;
-#endif
-
- if (shift < 0)
- delta >>= -shift;
- else
- delta <<= shift;
-
-#ifdef __i386__
- __asm__ (
- "mul %5 ; "
- "mov %4,%%eax ; "
- "mov %%edx,%4 ; "
- "mul %5 ; "
- "xor %5,%5; "
- "add %4,%%eax ; "
- "adc %5,%%edx ; "
- : "=A" (product), "=r" (tmp1), "=r" (tmp2)
- : "a" ((u32)delta), "1" ((u32)(delta >> 32)), "2" (mul_frac) );
-#elif __x86_64__
- __asm__ (
- "mul %%rdx ; shrd $32,%%rdx,%%rax"
- : "=a" (product) : "0" (delta), "d" ((u64)mul_frac) );
-#else
-#error implement me!
-#endif
-
- return product;
-}
-
-static u64 get_nsec_offset(struct shadow_time_info *shadow)
-{
- u64 now, delta;
- now = native_read_tsc();
- delta = now - shadow->tsc_timestamp;
- return scale_delta(delta, shadow->tsc_to_nsec_mul, shadow->tsc_shift);
-}
-
static cycle_t xen_clocksource_read(void)
{
- struct shadow_time_info *shadow = &get_cpu_var(shadow_time);
+struct vcpu_time_info *src;
cycle_t ret;
- unsigned version;
-
- do {
- version = get_time_values_from_xen();
- barrier();
- ret = shadow->system_timestamp + get_nsec_offset(shadow);
- barrier();
- } while (version != __get_cpu_var(xen_vcpu)->time.version);
-
- put_cpu_var(shadow_time);
+ src = &get_cpu_var(xen_vcpu)->time;
+ ret = pvclock_clocksource_read((void*)src);
+ put_cpu_var(xen_vcpu);
return ret;
}
@@ -349,9 +258,14 @@ static void xen_read_wallclock(struct timespec *ts)
unsigned long xen_get_wallclock(void)
{
+ const struct shared_info *s = HYPERVISOR_shared_info;
+ struct kvm_wall_clock *wall_clock = (void*)&(s->wc_version);
+struct vcpu_time_info *vcpu_time;
struct timespec ts;
- xen_read_wallclock(&ts);
+ vcpu_time = &get_cpu_var(xen_vcpu)->time;
+ pvclock_read_wallclock(wall_clock, (void*)vcpu_time, &ts);
+ put_cpu_var(xen_vcpu);
return ts.tv_sec;
}
@@ -576,8 +490,6 @@ __init void xen_time_init(void)
{
int cpu
[kvm-devel] [PATCH 4/4] kvm/guest: fix paravirt clocksource to be compartible with xen.
Signed-off-by: Gerd Hoffmann <[EMAIL PROTECTED]>
---
arch/x86/Kconfig |1 +
arch/x86/kernel/kvmclock.c | 66 ++-
2 files changed, 17 insertions(+), 50 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index fe73d38..ed1a679 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -373,6 +373,7 @@ config VMI
config KVM_CLOCK
bool "KVM paravirtualized clock"
select PARAVIRT
+ select PARAVIRT_CLOCK
depends on !(X86_VISWS || X86_VOYAGER)
help
Turning on this option will allow you to run a paravirtualized clock
diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
index ddee040..476b7c7 100644
--- a/arch/x86/kernel/kvmclock.c
+++ b/arch/x86/kernel/kvmclock.c
@@ -18,6 +18,7 @@
#include
#include
+#include
#include
#include
#include
@@ -37,17 +38,9 @@ early_param("no-kvmclock", parse_no_kvmclock);
/* The hypervisor will put information about time periodically here */
static DEFINE_PER_CPU_SHARED_ALIGNED(struct kvm_vcpu_time_info, hv_clock);
-#define get_clock(cpu, field) per_cpu(hv_clock, cpu).field
-
-static inline u64 kvm_get_delta(u64 last_tsc)
-{
- int cpu = smp_processor_id();
- u64 delta = native_read_tsc() - last_tsc;
- return (delta * get_clock(cpu, tsc_to_system_mul)) >> KVM_SCALE;
-}
static struct kvm_wall_clock wall_clock;
-static cycle_t kvm_clock_read(void);
+
/*
* The wallclock is the time of day when we booted. Since then, some time may
* have elapsed since the hypervisor wrote the data. So we try to account for
@@ -55,35 +48,19 @@ static cycle_t kvm_clock_read(void);
*/
unsigned long kvm_get_wallclock(void)
{
- u32 wc_sec, wc_nsec;
- u64 delta;
+ struct kvm_vcpu_time_info *vcpu_time;
struct timespec ts;
- int version, nsec;
int low, high;
low = (int)__pa(&wall_clock);
high = ((u64)__pa(&wall_clock) >> 32);
-
- delta = kvm_clock_read();
-
native_write_msr(MSR_KVM_WALL_CLOCK, low, high);
- do {
- version = wall_clock.wc_version;
- rmb();
- wc_sec = wall_clock.wc_sec;
- wc_nsec = wall_clock.wc_nsec;
- rmb();
- } while ((wall_clock.wc_version != version) || (version & 1));
-
- delta = kvm_clock_read() - delta;
- delta += wc_nsec;
- nsec = do_div(delta, NSEC_PER_SEC);
- set_normalized_timespec(&ts, wc_sec + delta, nsec);
- /*
-* Of all mechanisms of time adjustment I've tested, this one
-* was the champion!
-*/
- return ts.tv_sec + 1;
+
+ vcpu_time = &get_cpu_var(hv_clock);
+ pvclock_read_wallclock(&wall_clock, vcpu_time, &ts);
+ put_cpu_var(hv_clock);
+
+ return ts.tv_sec;
}
int kvm_set_wallclock(unsigned long now)
@@ -91,28 +68,17 @@ int kvm_set_wallclock(unsigned long now)
return 0;
}
-/*
- * This is our read_clock function. The host puts an tsc timestamp each time
- * it updates a new time. Without the tsc adjustment, we can have a situation
- * in which a vcpu starts to run earlier (smaller system_time), but probes
- * time later (compared to another vcpu), leading to backwards time
- */
static cycle_t kvm_clock_read(void)
{
- u64 last_tsc, now;
- int cpu;
+ struct kvm_vcpu_time_info *src;
+ cycle_t ret;
- preempt_disable();
- cpu = smp_processor_id();
-
- last_tsc = get_clock(cpu, tsc_timestamp);
- now = get_clock(cpu, system_time);
-
- now += kvm_get_delta(last_tsc);
- preempt_enable();
-
- return now;
+ src = &get_cpu_var(hv_clock);
+ ret = pvclock_clocksource_read(src);
+ put_cpu_var(hv_clock);
+ return ret;
}
+
static struct clocksource kvm_clock = {
.name = "kvm-clock",
.read = kvm_clock_read,
--
1.5.4.1
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 1/4] Add helper functions for paravirtual clocksources.
Signed-off-by: Gerd Hoffmann <[EMAIL PROTECTED]>
---
arch/x86/Kconfig |4 +
arch/x86/kernel/Makefile |1 +
arch/x86/kernel/pvclock.c | 146 +
include/asm-x86/pvclock.h |6 ++
4 files changed, 157 insertions(+), 0 deletions(-)
create mode 100644 arch/x86/kernel/pvclock.c
create mode 100644 include/asm-x86/pvclock.h
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index a22be4a..fe73d38 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -400,6 +400,10 @@ config PARAVIRT
over full virtualization. However, when run without a hypervisor
the kernel is theoretically slower and slightly larger.
+config PARAVIRT_CLOCK
+ bool
+ default n
+
endif
config MEMTEST_BOOTPARAM
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index fa19c38..ab7999c 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -83,6 +83,7 @@ obj-$(CONFIG_VMI) += vmi_32.o vmiclock_32.o
obj-$(CONFIG_KVM_GUEST)+= kvm.o
obj-$(CONFIG_KVM_CLOCK)+= kvmclock.o
obj-$(CONFIG_PARAVIRT) += paravirt.o paravirt_patch_$(BITS).o
+obj-$(CONFIG_PARAVIRT_CLOCK) += pvclock.o
ifdef CONFIG_INPUT_PCSPKR
obj-y += pcspeaker.o
diff --git a/arch/x86/kernel/pvclock.c b/arch/x86/kernel/pvclock.c
new file mode 100644
index 000..fecf17a
--- /dev/null
+++ b/arch/x86/kernel/pvclock.c
@@ -0,0 +1,146 @@
+/* paravirtual clock -- common code used by kvm/xen
+
+This program is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2 of the License, or
+(at your option) any later version.
+
+This program is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with this program; if not, write to the Free Software
+Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+*/
+
+#include
+#include
+#include
+
+/*
+ * These are perodically updated
+ *xen: magic shared_info page
+ *kvm: gpa registered via msr
+ * and then copied here.
+ */
+struct pvclock_shadow_time {
+ u64 tsc_timestamp; /* TSC at last update of time vals. */
+ u64 system_timestamp; /* Time, in nanosecs, since boot.*/
+ u32 tsc_to_nsec_mul;
+ int tsc_shift;
+ u32 version;
+};
+
+/*
+ * Scale a 64-bit delta by scaling and multiplying by a 32-bit fraction,
+ * yielding a 64-bit result.
+ */
+static inline u64 scale_delta(u64 delta, u32 mul_frac, int shift)
+{
+ u64 product;
+#ifdef __i386__
+ u32 tmp1, tmp2;
+#endif
+
+ if (shift < 0)
+ delta >>= -shift;
+ else
+ delta <<= shift;
+
+#ifdef __i386__
+ __asm__ (
+ "mul %5 ; "
+ "mov %4,%%eax ; "
+ "mov %%edx,%4 ; "
+ "mul %5 ; "
+ "xor %5,%5; "
+ "add %4,%%eax ; "
+ "adc %5,%%edx ; "
+ : "=A" (product), "=r" (tmp1), "=r" (tmp2)
+ : "a" ((u32)delta), "1" ((u32)(delta >> 32)), "2" (mul_frac) );
+#elif __x86_64__
+ __asm__ (
+ "mul %%rdx ; shrd $32,%%rdx,%%rax"
+ : "=a" (product) : "0" (delta), "d" ((u64)mul_frac) );
+#else
+#error implement me!
+#endif
+
+ return product;
+}
+
+static u64 pvclock_get_nsec_offset(struct pvclock_shadow_time *shadow)
+{
+ u64 delta = native_read_tsc() - shadow->tsc_timestamp;
+ return scale_delta(delta, shadow->tsc_to_nsec_mul, shadow->tsc_shift);
+}
+
+/*
+ * Reads a consistent set of time-base values from hypervisor,
+ * into a shadow data area.
+ */
+static unsigned pvclock_get_time_values(struct pvclock_shadow_time *dst,
+ struct kvm_vcpu_time_info *src)
+{
+ do {
+ dst->version = src->version;
+ rmb(); /* fetch version before data */
+ dst->tsc_timestamp = src->tsc_timestamp;
+ dst->system_timestamp = src->system_time;
+ dst->tsc_to_nsec_mul = src->tsc_to_system_mul;
+ dst->tsc_shift = src->tsc_shift;
+ rmb(); /* test version after fetching data */
+ } while ((src->version & 1) | (dst->version ^ src->version));
+
+ return dst->version;
+}
+
+/*
+ * This is our read_clock function. The host puts an tsc timestamp each time
+ * it updates a new time. Without the tsc adjustment, we can have a situation
+ * in which a vcpu starts to run earlier (smaller system_time), but probes
+ * time later (compared to another
Re: [kvm-devel] [PATCH 01 of 12] Core of mmu notifiers
I am not certain of this, but it seems like this patch leaves things in
a somewhat asymetric state. At the very least, I think that asymetry
should be documented in the comments of either mmu_notifier.h or .c.
Before I do the first mmu_notifier_register, all places that test for
mm_has_notifiers(mm) will return false and take the fast path.
After I do some mmu_notifier_register()s and their corresponding
mmu_notifier_unregister()s, The mm_has_notifiers(mm) will return true
and the slow path will be taken. This, despite all registered notifiers
having unregistered.
It seems to me the work done by mmu_notifier_mm_destroy should really
be done inside the mm_lock()/mm_unlock area of mmu_unregister and
mm_notifier_release when we have removed the last entry. That would
give the users job the same performance after they are done using the
special device that they had prior to its use.
On Thu, Apr 24, 2008 at 08:49:40AM +0200, Andrea Arcangeli wrote:
...
> diff --git a/mm/memory.c b/mm/memory.c
> --- a/mm/memory.c
> +++ b/mm/memory.c
...
> @@ -603,25 +605,39 @@
>* readonly mappings. The tradeoff is that copy_page_range is more
>* efficient than faulting.
>*/
> + ret = 0;
> if (!(vma->vm_flags &
> (VM_HUGETLB|VM_NONLINEAR|VM_PFNMAP|VM_INSERTPAGE))) {
> if (!vma->anon_vma)
> - return 0;
> + goto out;
> }
>
> - if (is_vm_hugetlb_page(vma))
> - return copy_hugetlb_page_range(dst_mm, src_mm, vma);
> + if (unlikely(is_vm_hugetlb_page(vma))) {
> + ret = copy_hugetlb_page_range(dst_mm, src_mm, vma);
> + goto out;
> + }
>
> + if (is_cow_mapping(vma->vm_flags))
> + mmu_notifier_invalidate_range_start(src_mm, addr, end);
> +
> + ret = 0;
I don't think this is needed.
...
> +/* avoid memory allocations for mm_unlock to prevent deadlock */
> +void mm_unlock(struct mm_struct *mm, struct mm_lock_data *data)
> +{
> + if (mm->map_count) {
> + if (data->nr_anon_vma_locks)
> + mm_unlock_vfree(data->anon_vma_locks,
> + data->nr_anon_vma_locks);
> + if (data->i_mmap_locks)
I think you really want data->nr_i_mmap_locks.
...
> diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c
> new file mode 100644
> --- /dev/null
> +++ b/mm/mmu_notifier.c
...
> +/*
> + * This function can't run concurrently against mmu_notifier_register
> + * or any other mmu notifier method. mmu_notifier_register can only
> + * run with mm->mm_users > 0 (and exit_mmap runs only when mm_users is
> + * zero). All other tasks of this mm already quit so they can't invoke
> + * mmu notifiers anymore. This can run concurrently only against
> + * mmu_notifier_unregister and it serializes against it with the
> + * unregister_lock in addition to RCU. struct mmu_notifier_mm can't go
> + * away from under us as the exit_mmap holds a mm_count pin itself.
> + *
> + * The ->release method can't allow the module to be unloaded, the
> + * module can only be unloaded after mmu_notifier_unregister run. This
> + * is because the release method has to run the ret instruction to
> + * return back here, and so it can't allow the ret instruction to be
> + * freed.
> + */
The second paragraph of this comment seems extraneous.
...
> + /*
> + * Wait ->release if mmu_notifier_unregister run list_del_rcu.
> + * srcu can't go away from under us because one mm_count is
> + * hold by exit_mmap.
> + */
These two sentences don't make any sense to me.
...
> +void mmu_notifier_unregister(struct mmu_notifier *mn, struct mm_struct *mm)
> +{
> + int before_release = 0, srcu;
> +
> + BUG_ON(atomic_read(&mm->mm_count) <= 0);
> +
> + srcu = srcu_read_lock(&mm->mmu_notifier_mm->srcu);
> + spin_lock(&mm->mmu_notifier_mm->unregister_lock);
> + if (!hlist_unhashed(&mn->hlist)) {
> + hlist_del_rcu(&mn->hlist);
> + before_release = 1;
> + }
> + spin_unlock(&mm->mmu_notifier_mm->unregister_lock);
> + if (before_release)
> + /*
> + * exit_mmap will block in mmu_notifier_release to
> + * guarantee ->release is called before freeing the
> + * pages.
> + */
> + mn->ops->release(mn, mm);
I am not certain about the need to do the release callout when the driver
has already told this subsystem it is done. For XPMEM, this callout
would immediately return. I would expect it to be the same or GRU.
Thanks,
Robin
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-dev
[kvm-devel] kvm-devel
现代制造业仓库管理与库存控制 主办单位：众人行管理咨询 联系人:凌小姐 传 真:0755-61351396 邮 箱:[EMAIL PROTECTED] 电 话:0755-26075365 课程对象:仓库管理、物流管理、采购管理、生产管理、供应链管理等人员 培训方式:专家讲解、案例分析、现场演练、师生互动、培训游戏、视频研讨等 参会费用:2800元/人(含:授课费,全套资料与讲义费,证书费,中餐, 点心及学员合影照片并邮寄等相关服务.) 参会时间:2008年04月17-18日 上海 课程目标： 从案例中领悟和提升,随着企业对物流管理的越来越重视，人们更多的认识到了采购对于库存的影响、 库存对于企业总体经营战略的重要性，也意识到了库房管理对于库存战略和采购管理的客观影响；但是, 仓库是成本中心吗？谁对库存负责？为什么库存总是控制不住？ERP平台上看到的库存信息为何经常失真？ 采购要对库存负哪些责任？仓库如何快速响应生产需求及其变化？如何计算仓库空间和面积、设备、人员 需求？仓库需要什么软件？ 面对以上问题，人们仍然显得不知所措�D�D本课程就是结合当前企业在采购和库存管理过程中遭遇到的 实际问题，站在企业物流管理系统的高度来剖析企业采购对库存构成的巨大影响和对库房的定位，从而让 学员在领略先进企业的先进做法的同时，领会其具有本企业特色的库存库房优化策略，从而提升学员个人 和企业的综合管理能力。 课程大纲： 库存控制与仓库管理综述 走出传统的库存思维看库存 库存产生的三大原因 库存结构的四个模块 生产企业物流管理与库存管理 现代企业中仓库形式及其管理模式的变化 仓库在企业供应链中的重要地位 1、 影响库存控制的因素分析 关于“提水案例” 库存分析方法 影响库存的六大背景因素 现场表现 综合问题 2、 物料交接与仓储管理 现代物流环境下的仓库重新定位 突破“我们的”仓库的第一印象 八家知名企业的仓库经典图解分析 质疑仓库管理的存在 仓库管理与库存控制的实质内容 不同企业、行业的仓库管理类型细分 仓库管理基本经济利益 3、 行业仓库现场管理问题分析与基本管理工具 录像：先进的仓库管理 错误的仓库管理思维：经验的错失 我国企业库房管理现状描述 图解仓库管理的八大基本瓶颈问题 管理思维与仓库层级定位 是否关注过物料？ 物料如何包装？ 是否关注过物料的流程？ 操作人员怎么知道自己做的是对的？ 如何保证信息是正确的 仓库效率决定什么？决定于什么？ 仓储管理的分析、业务指标及考核？ 仓库管理成本诱因分析 5S管理的短板和基础需求 目视管理 颜色管理 定置管理 看板管理 灯板管理 先进先出(FIFO)管理的3个最省力方法 4、 库存如何维持生产需要 谁在预测？如何预测？预测有多少用处？ 预测对于计划的龙头式影响 生产计划对于物料的影响模式 库存如何动态性应对生产需求变化的 静态物料流动化模式 精益生产与精益物流模式 零库存采购系统的达成 上门收货（milk-run） 供应商管理库存（ＶＭＩ）与准时化供应 5、 如何有效降低库存 工厂库存的结构分类与分析 仓库管理流程 仓库作业标准时间确定 提高仓库管理执行力 库存控制的傻瓜化模式推介 不要让检验成为库存流动瓶颈 超越资金的物料分类管理模式与帕累托原则 谁对库存负责？ 主生产计划体系与MRP 库存报警和订货系统 最低库存保有量的计算方法 生产库存模式因素分析与计算方法 原材料库存影响因素分析和计算方法 成品、经销库存因素分析与算法 定量订货与定期订货适应性 经济订货批量适应性 企业库存的经验算法 库存的变动细数折算法 库存周转率的计算、使用与误区的规避 库存资源约束与算法 6、 库存数量管理与盘点 突破经验模式的分组游戏：盘点 为什么盘点？ 盘点过程困惑？ 盘点的成本 盘点盈亏分析 如何取消帐-卡-物的传统管理模式 ERP对于仓库动态管理的无奈 库存信息管理与仓库管理软件（WMS）介绍 如何选用WMS软件 如何规避软件失败 世界顶尖仓库管理软件模式分析 7、 库存与库房的管理绩效提升的五大切入点 仓库规划、专业咨询和理念定位等 仓库保管原则 仓库规划与后期效益体现 仓库管理的动态变换趋势 仓库规划程序与要求 仓库功能分区与面积算法 分区分类管理的基本原理 某公司仓库规划案例分享 物流设备的合理配置 设备选用与设计原则 合理选择存储设备 搬运与堆高设备 物流容器设计与选用 工位器具非标准设计 仓库流程的合理化 现代企业物流管理组织与仓库地位确认 仓库基本流程规范 流程时间与标准工时 基于生产线需求模式的ｊｉｔ管理策略 JIT文化需求 七大浪费之库存表现 集约化生产管理需求六原则 仓库管理提升策略的技术经济性分析 仓库成本与物流成本 如何应证仓库是省钱的部门 物流冰山说 8、 仓库绩效考核与约束条件 ISO9000与仓库审核条列 仓库管理考核KPI指标及其本质分析 仓库消防与安全管理要求 五大约束条件 企业（尤其是决策层）对采购和仓库管理的定位 企业产品与行业特色约束 采购和库存管理的绩效周期 采购与仓库管理之间存在的“二律背反说” 人力资源与人才管理 讲师推荐 邱先生：上海交通大学工程硕士，中国机械工程学会物流工程分会理事，上海投资咨询公司（上海市计委） 物流园区投资计划与方案特聘专家；浙江大学EMBA总裁班客座教授；德国莱茵（TUV）（中国）学术部课程 长期特聘讲师。邱老师曾任上海大众汽车 SANTANA 轿车生产卫星工厂生产经营厂长；EVERWELL（中国）工 程部物流项目负责人；普茨迈斯特（中国）物流项目总监等职务。邱老师作为物流管理专业顾问组织完成了 美的电器、海尔、华晨汽车等多个大型物流咨询项目，其课程具备很强的实战性，并由此获得诸多客户的好 评。 擅长课题： 生产企业物流管理、企业供应链、库存控制与仓库管理、有效降低物流成本、生产计划与物料控 制、物流人才职业生涯规划等 荣誉客户：上海大众、上海通用、郑州宇通客车、张家港博泽汽车部件、沈阳金杯汽车、海尔集团、美的 集团、苏州旭电 、芜湖西门子VDO电子、南京菲尼克斯电气、华虹-NEC、天津通用半导体、上海施耐德电气、 苏州西门子电器、诺基亚苏州电信、上海通用电气、飞索半导体（苏州）、无锡罗地亚制药、汉高化工、 BASF染料化工、上海福斯油品、卜内门油漆、苏州葛兰素制药、惠氏白宫制药、上海汽轮机、普兹迈斯特 工程设备、广东摩恩、山西国际铸造、苏州百得电动工、上海物资集团、麦当劳华中地区配送中心、迅达 电梯上海物流中心、武汉红金龙卷烟、贝塔斯曼… - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] KVM Test result, kernel 873c05f.., userspace d102d75..
Hi All, This is today's KVM test result against kvm.git 873c05fa7e6fea27090b1bf0f67a073eadb04782 and kvm-userspace.git d102d750f397b543fe620a3c77a7e5e42c483865. In today's nightly testing, we meet host hang while booting multiple guests several times. This issue could be easily reproduced. Two Old Issues: 1. Booting four guests likely fails https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1919354&group_id=180599 2. Cannot boot guests with hugetlbfs https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1941302&group_id=180599 Test environment PlatformWoodcrest CPU 4 Memory size 8G' Details IA32-pae: 1. boot guest with 256M memory PASS 2. boot two windows xp guest PASS 3. boot 4 same guest in parallelPASS 4. boot linux and windows guest in parallel PASS 5. boot guest with 1500M memory PASS 6. boot windows 2003 with ACPI enabled PASS 7. boot Windows xp with ACPI enabled PASS 8. boot Windows 2000 without ACPI PASS 9. kernel build on SMP linux guestPASS 10. LTP on linux guest PASS 11. boot base kernel linux PASS 12. save/restore 32-bit HVM guests PASS 13. live migration 32-bit HVM guests PASS 14. boot SMP Windows xp with ACPI enabledPASS 15. boot SMP Windows 2003 with ACPI enabled PASS 16. boot SMP Windows 2000 with ACPI enabled PASS IA32e: 1. boot four 32-bit guest in parallel PASS 2. boot four 64-bit guest in parallel PASS 3. boot 4G 64-bit guest PASS 4. boot 4G pae guest PASS 5. boot 32-bit linux and 32 bit windows guest in parallelPASS 6. boot 32-bit guest with 1500M memory PASS 7. boot 64-bit guest with 1500M memory PASS 8. boot 32-bit guest with 256M memory PASS 9. boot 64-bit guest with 256M memory PASS 10. boot two 32-bit windows xp in parallelPASS 11. boot four 32-bit different guest in para PASS 12. save/restore 64-bit linux guests PASS 13. save/restore 32-bit linux guests PASS 14. boot 32-bit SMP windows 2003 with ACPI enabled PASS 15. boot 32-bit SMP Windows 2000 with ACPI enabled PASS 16. boot 32-bit SMP Windows xp with ACPI enabledPASS 17. boot 32-bit Windows 2000 without ACPIPASS 18. boot 64-bit Windows xp with ACPI enabledPASS 19. boot 32-bit Windows xp without ACPIPASS 20. boot 64-bit UP vista PASS 21. boot 64-bit SMP vista PASS 22. kernel build in 32-bit linux guest OS PASS 23. kernel build in 64-bit linux guest OS PASS 24. LTP on 32-bit linux guest OSPASS 25. LTP on 64-bit linux guest OSPASS 26. boot 64-bit guests with ACPI enabled PASS 27. boot 32-bit x-server PASS 28. boot 64-bit SMP windows XP with ACPI enabled PASS 29. boot 64-bit SMP windows 2003 with ACPI enabled PASS 30. live migration 64bit linux guests PASS 31. live migration 32bit linux guests PASS 32. reboot 32bit windows xp guest PASS 33. reboot 32bit windows xp guest PASS Report Summary on IA32-pae Summary Test Report of Last Session = Total PassFailNoResult Crash = control_panel 7 7 0 00 Restart 2 2 0 00 gtest 15 15 0 00 =
Re: [kvm-devel] KVM Test result, kernel 873c05f.., userspace d102d75..
Yunfeng Zhao wrote: > Hi All, > > This is today's KVM test result against kvm.git > 873c05fa7e6fea27090b1bf0f67a073eadb04782 and kvm-userspace.git > d102d750f397b543fe620a3c77a7e5e42c483865. > > I suspect 873c05fa7e6fea27090b1bf0f67a073eadb04782 itself, it's the only thing that has any chance of badness. Marcelo, any idea? Perhaps due to load, interrupts accumulate and can't be injected fast enough? These tests are run on a 2.6.22 host, which has a hacked smp_call_function_single() in external-module-compat.h, which may exaberate the problem. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [kvm-ppc-devel] [PATCH] [RESEND] [v2] Make "make sync" in kernel dir work for multiple archs
Jerone Young wrote: > 1 file changed, 37 insertions(+), 21 deletions(-) > kernel/Makefile | 58 +++ > > > - This adapts perviously sent patch to new changes to kernel/Makefile > - Fixes improper check in conditional > > This patch add the ability for make sync in the kernel directory to work for > mulitiple architectures and not just x86. > > I addressed this in a different way by always syncing headers from all architectures. This means the tarballs can be used to build userspace on any arch (though kernel modules are limited to x86, mostly due to arch limitations). In addition, we no longer refer to KERNELDIR when building userspace, so it ought to be easier to build on random kernels. Patches to be pushed shortly... -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Don't quit IO thread before all lvcpus stopped
Dor Laor wrote: > while investigating the revert of "fix sci irq set when acpi timer" I > discovered the reason. Please also re-revert the original patch. > Applied, but system_powerdown still doesn't work with the sci acpi timer fix. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] Moving kvm lists to kernel.org?
I propose moving the kvm lists to vger.kernel.org, for the following benefits: - better spam control - faster service (I see significant lag with the sourceforge lists) - no ads appended to the end of each email If no objections are raised, and if the vger postmasters agree, I will mass subscribe the current subscribers so that there will be no service interruption. Opinions? -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] KVM Test result, kernel 873c05f.., userspace d102d75..
On Thursday 24 April 2008 19:37:03 Avi Kivity wrote: > Yunfeng Zhao wrote: > > Hi All, > > > > This is today's KVM test result against kvm.git > > 873c05fa7e6fea27090b1bf0f67a073eadb04782 and kvm-userspace.git > > d102d750f397b543fe620a3c77a7e5e42c483865. > > I suspect 873c05fa7e6fea27090b1bf0f67a073eadb04782 itself, it's the only > thing that has any chance of badness. > > Marcelo, any idea? Perhaps due to load, interrupts accumulate and can't > be injected fast enough? > > These tests are run on a 2.6.22 host, which has a hacked > smp_call_function_single() in external-module-compat.h, which may > exaberate the problem. Yeah, I suspect the commit too(I tried tip without that, and found mostly alright). In fact, I didn't use kvm_vcpu_kick() just because that I found this function may causing hang on my host... But I didn't do more investigate so I can't tell what's wrong, then I just chose way to keep it working... I am sorry for not clarify... -- Thanks Yang, Sheng - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Moving kvm lists to kernel.org?
On Thursday 24 April 2008 20:54:10 Avi Kivity wrote: > I propose moving the kvm lists to vger.kernel.org, for the following > benefits: > > - better spam control > - faster service (I see significant lag with the sourceforge lists) > - no ads appended to the end of each email > > If no objections are raised, and if the vger postmasters agree, I will > mass subscribe the current subscribers so that there will be no service > interruption. > > Opinions? Yeah, finally we don't need to meet something like this everyday: "This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/"; ;) -- Thanks Yang, Sheng - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] KVM Test result, kernel 873c05f.., userspace d102d75..
Yang, Sheng wrote: > On Thursday 24 April 2008 19:37:03 Avi Kivity wrote: > >> Yunfeng Zhao wrote: >> >>> Hi All, >>> >>> This is today's KVM test result against kvm.git >>> 873c05fa7e6fea27090b1bf0f67a073eadb04782 and kvm-userspace.git >>> d102d750f397b543fe620a3c77a7e5e42c483865. >>> >> I suspect 873c05fa7e6fea27090b1bf0f67a073eadb04782 itself, it's the only >> thing that has any chance of badness. >> >> Marcelo, any idea? Perhaps due to load, interrupts accumulate and can't >> be injected fast enough? >> >> These tests are run on a 2.6.22 host, which has a hacked >> smp_call_function_single() in external-module-compat.h, which may >> exaberate the problem. >> > > Yeah, I suspect the commit too(I tried tip without that, and found mostly > alright). In fact, I didn't use kvm_vcpu_kick() just because that I found > this function may causing hang on my host... But I didn't do more investigate > so I can't tell what's wrong, then I just chose way to keep it working... I > am sorry for not clarify... > I think smp_call_function_single() is miscompiled when using the compatibility code. I took it out-of-line to be sure (it is now in kernel/external-module-compat.c). No evidence, but... -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] pv clock: kvm is incompatible with xen :-(
Gerd Hoffmann wrote: > Glauber Costa wrote: >> Gerd Hoffmann wrote: >>> Jeremy Fitzhardinge wrote: Xen could change the parameters in the instant after get_time_values(). That change could be as a result of suspend-resume, so the parameters and the tsc could be wildly different. >>> Ah, ok, forgot the rdtsc in the picture. With that in mind I fully >>> agree that the loop is needed. I think kvm guests can even hit that one >>> with the vcpu migrating to a different physical cpu, so we better handle >>> it correctly ;) >> It's probably not needed for kvm, since we update everything everytime >> we get scheduled in the host side, which would cover the case for >> migration between physical cpus. > > No, it wouldn't. The corner case we must catch is: guest reads time > info, kvm reschedules the guest to another pcpu, guest reads the tsc. > The time info used by the guest for the tsc delta is stale then, it > belongs to the previous pcpu. > > cheers, > Gerd > Agreed. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 1/4] Add helper functions for paravirtual clocksources.
> +void pvclock_read_wallclock(struct kvm_wall_clock *wall_clock,
> + struct kvm_vcpu_time_info *vcpu_time,
> + struct timespec *ts)
> +{
> + u32 version;
> + u64 delta;
> + struct timespec now;
> +
> + /* get wallclock at system boot */
> + do {
> + version = wall_clock->wc_version;
> + rmb(); /* fetch version before time */
> + now.tv_sec = wall_clock->wc_sec;
> + now.tv_nsec = wall_clock->wc_nsec;
> + rmb(); /* fetch time before checking version */
> + } while ((wall_clock->wc_version & 1) || (version !=
> wall_clock->wc_version));
> +
> + delta = pvclock_clocksource_read(vcpu_time);/* time since system
> boot */
> + delta += now.tv_sec * (u64)NSEC_PER_SEC + now.tv_nsec;
> +
> + now.tv_nsec = do_div(delta, NSEC_PER_SEC);
> + now.tv_sec = delta;
> +
> + set_normalized_timespec(ts, now.tv_sec, now.tv_nsec);
> +}
This is not exactly what kvm does. For us, wallclock read and system
time reads are decoupled operations, controlled by different msrs.
This function might exist, but in this case, it have to be wrapped
around a kvm_read_wallclock(), that does the msr read. (I'm not sure
whether or not you do it in your later patches, doing sequential reads
:-) )
> -
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
>
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
ads! ads!
--
Glauber Costa.
"Free as in Freedom"
http://glommer.net
"The less confident you are, the more serious you have to act."
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 4/4] kvm/guest: fix paravirt clocksource to be compartible with xen.
> -
> - delta = kvm_clock_read();
> -
> native_write_msr(MSR_KVM_WALL_CLOCK, low, high);
> - do {
> - version = wall_clock.wc_version;
> - rmb();
> - wc_sec = wall_clock.wc_sec;
> - wc_nsec = wall_clock.wc_nsec;
> - rmb();
> - } while ((wall_clock.wc_version != version) || (version & 1));
> -
> - delta = kvm_clock_read() - delta;
> - delta += wc_nsec;
> - nsec = do_div(delta, NSEC_PER_SEC);
> - set_normalized_timespec(&ts, wc_sec + delta, nsec);
> - /*
> -* Of all mechanisms of time adjustment I've tested, this one
> -* was the champion!
> -*/
> - return ts.tv_sec + 1;
> +
> + vcpu_time = &get_cpu_var(hv_clock);
> + pvclock_read_wallclock(&wall_clock, vcpu_time, &ts);
> + put_cpu_var(hv_clock);
> +
> + return ts.tv_sec;
> }
Here it is. Despite some needed cleanups, patches look beautiful to me.
--
Glauber Costa.
"Free as in Freedom"
http://glommer.net
"The less confident you are, the more serious you have to act."
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] paravirt clock stil causing hangs in kvm-65
On Mon, Apr 21, 2008 at 4:15 AM, Gerd Hoffmann <[EMAIL PROTECTED]> wrote: > Marcelo Tosatti wrote: > >> >From what me and marcelo discussed, I think there's a possibility that > >> it has marginally something to do with precision of clock calculation. > >> Gerd's patches address that issues. Can somebody test this with those > >> patches (both guest and host), while I'm off ? > > > > Haven't seen Gerd's guest patches ? > > I'm still busy cooking them up. I've mentioned them in a mail, but they > didn't ran over the list (yet). Stay tuned ;) > > cheers, > Gerd > Just saw Gerd's patches flying around. Can anyone that is able to reproduce this problem (a subgroup of human beings that does not include me) test it with them applied? If it still fails, please let me know asap -- Glauber Costa. "Free as in Freedom" http://glommer.net "The less confident you are, the more serious you have to act." - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] KVM Test result, kernel 873c05f.., userspace d102d75..
Avi Kivity wrote: > Yang, Sheng wrote: >> On Thursday 24 April 2008 19:37:03 Avi Kivity wrote: >> >>> Yunfeng Zhao wrote: >>> Hi All, This is today's KVM test result against kvm.git 873c05fa7e6fea27090b1bf0f67a073eadb04782 and kvm-userspace.git d102d750f397b543fe620a3c77a7e5e42c483865. >>> I suspect 873c05fa7e6fea27090b1bf0f67a073eadb04782 itself, it's the >>> only >>> thing that has any chance of badness. >>> >>> Marcelo, any idea? Perhaps due to load, interrupts accumulate and >>> can't >>> be injected fast enough? >>> >>> These tests are run on a 2.6.22 host, which has a hacked >>> smp_call_function_single() in external-module-compat.h, which may >>> exaberate the problem. >>> >> >> Yeah, I suspect the commit too(I tried tip without that, and found >> mostly alright). In fact, I didn't use kvm_vcpu_kick() just because >> that I found this function may causing hang on my host... But I >> didn't do more investigate so I can't tell what's wrong, then I just >> chose way to keep it working... I am sorry for not clarify... >> > > I think smp_call_function_single() is miscompiled when using the > compatibility code. I took it out-of-line to be sure (it is now in > kernel/external-module-compat.c). > > No evidence, but... > Ok. __pit_timer_fn() is called from an interrupt, which then calls smp_call_function_single(), which calls spin_lock(). If we've already taken the lock, we hang. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] Re: [PATCH 0/3] Qemu crashes with pci passthrough
On Sat, Apr 19, 2008 at 6:11 PM, Glauber Costa <[EMAIL PROTECTED]> wrote:
>
> On Fri, Apr 18, 2008 at 1:27 PM, Avi Kivity <[EMAIL PROTECTED]> wrote:
> >
> > Glauber de Oliveira Costa wrote:
> >
> > > Hi,
> > > I've got some qemu crashes while trying to passthrough an ide device
> > > to a kvm guest. After some investigation, it turned out that
> > register_ioport_{read/write} will abort on errors instead of returning
> > > a meaningful error.
> > >
> > > However, even if we do return an error, the asynchronous nature of pci
> > > config space mapping updates makes it a little bit hard to treat.
> > >
> > > This series of patches basically treats errors in the mapping functions
> in
> > > the pci layer. If anything goes wrong, we unregister the pci device,
> > unmapping
> > > any mappings that happened to be sucessfull already.
> > >
> > > After these patches are applied, a lot of warnings appears. And, you
> know,
> > > everytime there is a warning, god kills a kitten. But I'm not planning on
> > > touching the other pieces of qemu code for this until we set up (or not)
> > in
> > > this solution
> > >
> > > Comments are very welcome, specially from qemu folks (since it is a bit
> > invasive)
> > >
> > >
> > >
> >
> > Have you considered, instead of rolling back the changes you already made
> > before the failure, to have a function which checks if an ioport
> > registration will be successful? This may simplify the code.
> >
> Yes, I did.
>
> Basic problem is that I basically could not find this information
> handy until we were deep in the stack, right before calling the update
> mapping functions. I turned out preferring this option. I can,
> however, take a fresh look at that.
>
Looked at this again, and it does seem to me that we don't have too
much to gain from a "test-before" solution. We definitely can't test
it reliably until update_mappings arrive, (since the mapping can
change) and by this time, the pci device is already registered, and we
would have to de-register it anyway. There is room for "improvement"
(with a wide definition of improvement) if we test all the ports of a
device in advance (inside update_mappings) instead of a port-by-port
basis. We could get rid of the flag, but it would be traded off by
another complexities.
So unless someone have a very direct alternate solution for this I'm
failing to see, I do advocate for those humble patches.
--
Glauber Costa.
"Free as in Freedom"
http://glommer.net
"The less confident you are, the more serious you have to act."
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Moving kvm lists to kernel.org?
From: Avi Kivity <[EMAIL PROTECTED]> Date: Thu, 24 Apr 2008 15:54:10 +0300 > I propose moving the kvm lists to vger.kernel.org, for the following > benefits: > > - better spam control > - faster service (I see significant lag with the sourceforge lists) > - no ads appended to the end of each email > > If no objections are raised, and if the vger postmasters agree, I will > mass subscribe the current subscribers so that there will be no service > interruption. I'm fine with adding the list, but we don't do mass subscribes like that, and this rule applies to every list which moves to vger from somewhere else. People will need to subscribe themselves to the new list. We enforce this for two reasons: 1) If they don't go through the action of subscribing, they won't be able to unsubscribe, so they'll be upset and also bug us postmasters for help. 2) People are generally unhappy when they are subscribed to mailing lists at a site they didn't ask to be at. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Moving kvm lists to kernel.org?
David Miller wrote: >> If no objections are raised, and if the vger postmasters agree, I will >> mass subscribe the current subscribers so that there will be no service >> interruption. >> > > I'm fine with adding the list, but we don't do mass subscribes like > that, and this rule applies to every list which moves to vger from > somewhere else. > > (three lists) > People will need to subscribe themselves to the new list. > Okay. Will give people a week's notice to subscribe. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] KVM Test result, kernel 873c05f.., userspace d102d75..
Avi Kivity wrote: > > Ok. __pit_timer_fn() is called from an interrupt, which then calls > smp_call_function_single(), which calls spin_lock(). If we've already > taken the lock, we hang. > Ah. Just adding a "me too"; I didn't get a chance to debug it yesterday, but I was seeing similar problems. If I disabled in-kernel pit with -no-kvm-pit, all was well. Chris Lalancette - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Don't quit IO thread before all lvcpus stopped
On Thu, 2008-04-24 at 15:47 +0300, Avi Kivity wrote: > Dor Laor wrote: > > while investigating the revert of "fix sci irq set when acpi timer" I > > discovered the reason. Please also re-revert the original patch. > > > > Applied, but system_powerdown still doesn't work with the sci acpi timer > fix. > > With the above patch and revert the reversion of "fix sci irq set when acpi timer" it works for me. Can you give some details or try again? My host is 2.6.24.3-50-fc8, your kvm head (user da00aa5090cf2de4259960ea659ac783bd65a041 + re-revert, kernel 1736e3f0a3e173a7f452b32ad19bfff085a1a255). Guest is winXp with acpi hal. After it boots I go to the monitor and issue a system_powerdown. Everything works and there is no segfaults (tested multiple time) Dor - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] KVM Test result, kernel 873c05f.., userspace d102d75..
Chris Lalancette wrote: > Avi Kivity wrote: > >> Ok. __pit_timer_fn() is called from an interrupt, which then calls >> smp_call_function_single(), which calls spin_lock(). If we've already >> taken the lock, we hang. >> >> > > Ah. Just adding a "me too"; I didn't get a chance to debug it yesterday, but > I > was seeing similar problems. If I disabled in-kernel pit with -no-kvm-pit, > all > was well. > How to fix it, though? the only idea that comes to mind is to affine the hrtimer with vcpu0 (like the local apic timers) which would mean we only need to unwait the waitqueue, and never need to send the IPI. Would slightly improve performance as well. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] Real Mode Improvement on Intel Hosts - GSoC Project
Hi, My Project proposal "Improving and Stabilizing Real-Mode Support for Intel Hosts" has been accepted into Google Summer of Code under the Linux Foundation. You may have a look at the proposal abstract here: http://code.google.com/soc/2008/linux/appinfo.html?csaid=1CC1C8B4CCC1120E . Any pointers on where to start, what would you like to see done, and any other comments and suggestions would greatly be appreciated. Regards, Mohammed - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH]: Fix MSR_K7_EVNTSEL{0,3} for SVM
Chris Lalancette wrote: > Avi Kivity wrote: > >> You mean the gcc generates wrong code? It seems fine here (though >> wonderfully obfuscated). >> >> Can you attach an objdump -Sr svm.o? Also, what gcc version are you using? >> >> > > (sending attachment in private mail, so I don't spam the whole list with 189K > of > objdump). Note that this is an objdump -Sr of the current code, with my patch > *not* applied. > > gcc is gcc-4.3.0-7 in Fedora 9. > > It's a gcc bug. svm_set_msr() places ecx in %rsi, and consistently uses %esi to refer to the first 32 bits. But when it compiles this bit: > case MSR_K7_EVNTSEL0: > case MSR_K7_EVNTSEL1: > case MSR_K7_EVNTSEL2: > case MSR_K7_EVNTSEL3: > /* > * only support writing 0 to the performance counters for now > * to make Windows happy. Should be replaced by a real > * performance counter emulation later. > */ > if (data != 0) > goto unhandled; > break; (where MSR_K7_EVENTSEL[0123] == 0xc001000[0123]) it compiles it into > 1811: 8d 86 00 00 ff 3f lea0x3fff(%rsi),%eax > 1817: 83 f8 03cmp$0x3,%eax > 181a: 0f 87 e2 01 00 00 ja 1a02 Now it uses %rsi instead of %esi, and any junk in the upper bits will cause the ja to be taken. We need to get a reduced testcase to the gcc folks, this is a serious bug. Any changes in the code to work around this would be fragile. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 01 of 12] Core of mmu notifiers
On Thu, Apr 24, 2008 at 04:51:12AM -0500, Robin Holt wrote:
> It seems to me the work done by mmu_notifier_mm_destroy should really
> be done inside the mm_lock()/mm_unlock area of mmu_unregister and
There's no mm_lock/unlock for mmu_unregister anymore. That's the whole
point of using srcu so it becomes reliable and quick.
> mm_notifier_release when we have removed the last entry. That would
> give the users job the same performance after they are done using the
> special device that they had prior to its use.
That's not feasible. Otherwise mmu_notifier_mm will go away at any
time under both _release from exit_mmap and under _unregister
too. exit_mmap holds an mm_count implicit, so freeing mmu_notifier_mm
after the last mmdrop makes it safe. mmu_notifier_unregister also
holds the mm_count because mm_count was pinned by
mmu_notifier_register. That solves the issue with mmu_notifier_mm
going away from under mmu_notifier_unregister and _release and that's
why it can only be freed after mm_count == 0.
There's at least one small issue I noticed so far, that while _release
don't need to care about _register, but _unregister definitely need to
care about _register. I've to take the mmap_sem in addition or in
replacement of the unregister_lock. The srcu_read_lock can also likely
moved just before releasing the unregister_lock but that's just a
minor optimization to make the code more strict.
> On Thu, Apr 24, 2008 at 08:49:40AM +0200, Andrea Arcangeli wrote:
> ...
> > diff --git a/mm/memory.c b/mm/memory.c
> > --- a/mm/memory.c
> > +++ b/mm/memory.c
> ...
> > @@ -603,25 +605,39 @@
> > * readonly mappings. The tradeoff is that copy_page_range is more
> > * efficient than faulting.
> > */
> > + ret = 0;
> > if (!(vma->vm_flags &
> > (VM_HUGETLB|VM_NONLINEAR|VM_PFNMAP|VM_INSERTPAGE))) {
> > if (!vma->anon_vma)
> > - return 0;
> > + goto out;
> > }
> >
> > - if (is_vm_hugetlb_page(vma))
> > - return copy_hugetlb_page_range(dst_mm, src_mm, vma);
> > + if (unlikely(is_vm_hugetlb_page(vma))) {
> > + ret = copy_hugetlb_page_range(dst_mm, src_mm, vma);
> > + goto out;
> > + }
> >
> > + if (is_cow_mapping(vma->vm_flags))
> > + mmu_notifier_invalidate_range_start(src_mm, addr, end);
> > +
> > + ret = 0;
>
> I don't think this is needed.
It's not needed right, but I thought it was cleaner if they all use
"ret" after I had to change the code at the end of the
function. Anyway I'll delete this to make the patch shorter and only
change the minimum, agreed.
> ...
> > +/* avoid memory allocations for mm_unlock to prevent deadlock */
> > +void mm_unlock(struct mm_struct *mm, struct mm_lock_data *data)
> > +{
> > + if (mm->map_count) {
> > + if (data->nr_anon_vma_locks)
> > + mm_unlock_vfree(data->anon_vma_locks,
> > + data->nr_anon_vma_locks);
> > + if (data->i_mmap_locks)
>
> I think you really want data->nr_i_mmap_locks.
Indeed. It never happens that there are zero vmas with filebacked
mappings, this is why this couldn't be triggered in practice, thanks!
> The second paragraph of this comment seems extraneous.
ok removed.
> > + /*
> > +* Wait ->release if mmu_notifier_unregister run list_del_rcu.
> > +* srcu can't go away from under us because one mm_count is
> > +* hold by exit_mmap.
> > +*/
>
> These two sentences don't make any sense to me.
Well that was a short explanation of why the mmu_notifier_mm structure
can only be freed after the last mmdrop, which is what you asked at
the top. I'll try to rephrase.
> > +void mmu_notifier_unregister(struct mmu_notifier *mn, struct mm_struct *mm)
> > +{
> > + int before_release = 0, srcu;
> > +
> > + BUG_ON(atomic_read(&mm->mm_count) <= 0);
> > +
> > + srcu = srcu_read_lock(&mm->mmu_notifier_mm->srcu);
> > + spin_lock(&mm->mmu_notifier_mm->unregister_lock);
> > + if (!hlist_unhashed(&mn->hlist)) {
> > + hlist_del_rcu(&mn->hlist);
> > + before_release = 1;
> > + }
> > + spin_unlock(&mm->mmu_notifier_mm->unregister_lock);
> > + if (before_release)
> > + /*
> > +* exit_mmap will block in mmu_notifier_release to
> > +* guarantee ->release is called before freeing the
> > +* pages.
> > +*/
> > + mn->ops->release(mn, mm);
>
> I am not certain about the need to do the release callout when the driver
> has already told this subsystem it is done. For XPMEM, this callout
> would immediately return. I would expect it to be the same or GRU.
The point is that you don't want to run it twice. And without this you
will have to serialize against ->release yourself in the driver. It's
much more convenient if you know that ->release will be called just
once, and before mmu_notifier_unregister returns. It could be called
by _release even after you're already inside _u
Re: [kvm-devel] [PATCH]: Fix MSR_K7_EVNTSEL{0,3} for SVM
Avi Kivity wrote: > >> 1811:8d 86 00 00 ff 3f lea0x3fff(%rsi),%eax >> 1817:83 f8 03cmp$0x3,%eax >> 181a:0f 87 e2 01 00 00 ja 1a02 > Now it uses %rsi instead of %esi, and any junk in the upper bits will > cause the ja to be taken. > > We need to get a reduced testcase to the gcc folks, this is a serious > bug. Any changes in the code to work around this would be fragile. > Ouch, I missed this on my reading of it. I'll try to come up with a standalone program that shows this. Thanks, Avi. Chris Lalancette - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [kvm-ppc-devel] Moving kvm lists to kernel.org?
Hollis Blanchard wrote: > On Thursday 24 April 2008 07:54:10 Avi Kivity wrote: > >> I propose moving the kvm lists to vger.kernel.org, for the following >> benefits: >> >> - better spam control >> - faster service (I see significant lag with the sourceforge lists) >> - no ads appended to the end of each email >> >> If no objections are raised, and if the vger postmasters agree, I will >> mass subscribe the current subscribers so that there will be no service >> interruption. >> > > Sounds good to me. > > Will we continue to have manual moderation for non-subscribers? That seems to > be a good way to handle the last 1% of spam that sneaks through the automated > filters. > kvm-devel doesn't do manual moderation. If vger has the infrastructure, I don't see why you can't continue doing this on kvm-ppc-devel. btw, we can probably shorten the names to kvm@ and kvm-$arch@ while we're at it. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Real Mode Improvement on Intel Hosts - GSoC Project
On Thu, Apr 24, 2008 at 5:47 PM, Avi Kivity <[EMAIL PROTECTED]> wrote: > Mohammed Gamal wrote: > > > Hi, > > My Project proposal "Improving and Stabilizing Real-Mode Support for > > Intel Hosts" has been accepted into Google Summer of Code under the > > Linux Foundation. You may have a look at the proposal abstract here: > > http://code.google.com/soc/2008/linux/appinfo.html?csaid=1CC1C8B4CCC1120E > > . > > > > > > > > Excellent! It's an area where kvm has been lagging for a long time. > > > > > Any pointers on where to start, what would you like to see done, and > > any other comments and suggestions would greatly be appreciated. > > > > > > It boils down to: > > - removing the current hacks (fix_rmode_dataseg etc) > - identifying when the vcpu state does not allow using VT > (when a segment limit != 65535, or when ss.rpl != cpl in protected mode) > - can be done by intercepting vmentry failures > - or by looking at the state directly when entering real mode or protected > mode > - trapping to the emulator in this case > - extending the emulator to support any opcodes which we will encounter > when doing this > > Guillaume Thouvenin (copied) has been working on this lately. > > -- > error compiling committee.c: too many arguments to function > > Thanks for the feedback, this has been really helpful. I also saw Guillame's work and I'd be very much willing to cooperate :). Regards, Mohammed - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Real Mode Improvement on Intel Hosts - GSoC Project
Mohammed Gamal wrote: > Hi, > My Project proposal "Improving and Stabilizing Real-Mode Support for > Intel Hosts" has been accepted into Google Summer of Code under the > Linux Foundation. You may have a look at the proposal abstract here: > http://code.google.com/soc/2008/linux/appinfo.html?csaid=1CC1C8B4CCC1120E > . > > Any pointers on where to start, what would you like to see done, and > any other comments and suggestions would greatly be appreciated. > We have a two stage plan to address real-mode on Intel systems. Both involve using x86_emulate() to emulate 16-bit (and 32-bit) instructions that VT cannot handle. The first stage is to detect vmentry failures and run x86_emulate() for a single instruction. If you look at the mailing list, you'll see patches from myself and Guillaume. This should be enough to allow most Ubuntu installer CDs to work under KVM. In this case, the CDs are using a version of GFXBOOT that doesn't use big real mode, but still relies on an undefined architectural aspect that VT doesn't support. The second stage is to use a loop of x86_emulate() to run all 16-bit code (instead of using vm86 mode). This will allow us to support guests that use big real mode. The best place to start is probably to try out some of the patches on the list, and get familiar with the GFXBOOT assembly routines. There's a #kvm in FreeNode, that's a good place to start if you're having trouble getting started. Regards, Anthony Liguori > Regards, > Mohammed > > - > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > ___ > kvm-devel mailing list > kvm-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/kvm-devel > - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Don't quit IO thread before all lvcpus stopped
Dor Laor wrote: > On Thu, 2008-04-24 at 15:47 +0300, Avi Kivity wrote: > >> Dor Laor wrote: >> >>> while investigating the revert of "fix sci irq set when acpi timer" I >>> discovered the reason. Please also re-revert the original patch. >>> >>> >> Applied, but system_powerdown still doesn't work with the sci acpi timer >> fix. >> >> >> > > With the above patch and revert the reversion of "fix sci irq set when > acpi timer" it works for me. Can you give some details or try again? > > My host is 2.6.24.3-50-fc8, your kvm head (user > da00aa5090cf2de4259960ea659ac783bd65a041 + re-revert, kernel > 1736e3f0a3e173a7f452b32ad19bfff085a1a255). > Guest is winXp with acpi hal. After it boots I go to the monitor and > issue a system_powerdown. > Everything works and there is no segfaults (tested multiple time) > > With current master, Windows and Linux (FC6, x86_64) both shut down correctly after system_powerdown. With the sci timer thing re-applied, Windows continues to work but Linux no longer responds to ACPI powerdown. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] KVM Test result, kernel 873c05f.., userspace d102d75..
On Thu, Apr 24, 2008 at 04:44:27PM +0300, Avi Kivity wrote:
> Chris Lalancette wrote:
> >Avi Kivity wrote:
> >
> >>Ok. __pit_timer_fn() is called from an interrupt, which then calls
> >>smp_call_function_single(), which calls spin_lock(). If we've already
> >>taken the lock, we hang.
> >>
> >>
> >
> >Ah. Just adding a "me too"; I didn't get a chance to debug it yesterday,
> >but I
> >was seeing similar problems. If I disabled in-kernel pit with
> >-no-kvm-pit, all
> >was well.
> >
>
> How to fix it, though? the only idea that comes to mind is to affine
> the hrtimer with vcpu0 (like the local apic timers) which would mean we
> only need to unwait the waitqueue, and never need to send the IPI.
> Would slightly improve performance as well.
Yes, agree.
For now I think just revert
--- a/arch/x86/kvm/i8254.c
+++ b/arch/x86/kvm/i8254.c
@@ -200,10 +200,8 @@ int __pit_timer_fn(struct kvm_kpit_state *ps)
atomic_inc(&pt->pending);
smp_mb__after_atomic_inc();
- if (vcpu0 && waitqueue_active(&vcpu0->wq)) {
- vcpu0->arch.mp_state = KVM_MP_STATE_RUNNABLE;
- wake_up_interruptible(&vcpu0->wq);
- }
+ if (vcpu0)
+ kvm_vcpu_kick(vcpu0);
And add a big fat FIXME.
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [kvm-ppc-devel] Moving kvm lists to kernel.org?
On Thursday 24 April 2008 07:54:10 Avi Kivity wrote: > I propose moving the kvm lists to vger.kernel.org, for the following > benefits: > > - better spam control > - faster service (I see significant lag with the sourceforge lists) > - no ads appended to the end of each email > > If no objections are raised, and if the vger postmasters agree, I will > mass subscribe the current subscribers so that there will be no service > interruption. Sounds good to me. Will we continue to have manual moderation for non-subscribers? That seems to be a good way to handle the last 1% of spam that sneaks through the automated filters. -- Hollis Blanchard IBM Linux Technology Center - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Real Mode Improvement on Intel Hosts - GSoC Project
Mohammed Gamal wrote: > Hi, > My Project proposal "Improving and Stabilizing Real-Mode Support for > Intel Hosts" has been accepted into Google Summer of Code under the > Linux Foundation. You may have a look at the proposal abstract here: > http://code.google.com/soc/2008/linux/appinfo.html?csaid=1CC1C8B4CCC1120E > . > > Excellent! It's an area where kvm has been lagging for a long time. > Any pointers on where to start, what would you like to see done, and > any other comments and suggestions would greatly be appreciated. > It boils down to: - removing the current hacks (fix_rmode_dataseg etc) - identifying when the vcpu state does not allow using VT (when a segment limit != 65535, or when ss.rpl != cpl in protected mode) - can be done by intercepting vmentry failures - or by looking at the state directly when entering real mode or protected mode - trapping to the emulator in this case - extending the emulator to support any opcodes which we will encounter when doing this Guillaume Thouvenin (copied) has been working on this lately. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] KVM Test result, kernel 873c05f.., userspace d102d75..
Marcelo Tosatti wrote: > On Thu, Apr 24, 2008 at 04:44:27PM +0300, Avi Kivity wrote: > >> Chris Lalancette wrote: >> >>> Avi Kivity wrote: >>> >>> Ok. __pit_timer_fn() is called from an interrupt, which then calls smp_call_function_single(), which calls spin_lock(). If we've already taken the lock, we hang. >>> Ah. Just adding a "me too"; I didn't get a chance to debug it yesterday, >>> but I >>> was seeing similar problems. If I disabled in-kernel pit with >>> -no-kvm-pit, all >>> was well. >>> >>> >> How to fix it, though? the only idea that comes to mind is to affine >> the hrtimer with vcpu0 (like the local apic timers) which would mean we >> only need to unwait the waitqueue, and never need to send the IPI. >> Would slightly improve performance as well. >> > > Yes, agree. > > For now I think just revert > I committed this, so this should be fixed for now. I'm not sure hrtimer migration would work 100% reliably (suppose it fired just after a vcpu migration) so I think a queue_work is better. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] WARNING: at /usr/src/modules/kvm/mmu.c:390 account_shadowed()
On Wed, Apr 23, 2008 at 09:30:06AM +0300, Avi Kivity wrote: > > as I got no reply, I guess it is a bad setup on my part. If that might > > help, this happenned while I was doing a "make -j" on webkit svn tree > > (ie. heavy c++ compilation workload) . > > > > > > No this is not bad setup. No amount of bad setup should give this warning. > > You didn't get a reply because no one knows what to make of it, and > because it's much more fun to debate endianess or contemplete guests > with eighty thousand disks than to fix those impossible bugs. If you > can give clear instructions on how to reproduce this, we will try it > out. Please be sure to state OS name and versions for the guest as well > as the host. It is valid to have more than PAGES_PER_HPAGE in the largepage's shadowed count. If the gpte read races with a pte-update-from-guest (and the pte update results in a different sp->role), it might account twice for a single gfn. Such "zombie" shadow pages should eventually be removed through recycling, allowing for instantiation of a large page, unless references can be leaked. Can't spot such leakage problem though. Thoughts? diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c index 2ad6f54..8ae2118 100644 --- a/arch/x86/kvm/mmu.c +++ b/arch/x86/kvm/mmu.c @@ -387,7 +387,6 @@ static void account_shadowed(struct kvm *kvm, gfn_t gfn) write_count = slot_largepage_idx(gfn, gfn_to_memslot(kvm, gfn)); *write_count += 1; - WARN_ON(*write_count > KVM_PAGES_PER_HPAGE); } static void unaccount_shadowed(struct kvm *kvm, gfn_t gfn) - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] performance with guests running 2.4 kernels (specifically RHEL3)
What is the rip (GUEST_RIP) value in the VMEXIT trace output? Is that the current instruction pointer for the guest? I take it the virt in the PAGE_FAULT trace output is the virtual address the guest was referencing when the page fault occurred. What I don't understand (one of many things really) is what the 0xfffb63b0 corresponds to in the guest. Any ideas? Also, the expensive page fault occurs on errorcode = 0x000b (PAGE_FAULT trace data). What does the 4th bit in 0xb mean? bit 0 set means PFERR_PRESENT_MASK is set, and bit 1 means PT_WRITABLE_MASK. What is bit 3? david David S. Ahern wrote: > > Avi Kivity wrote: >> Ah! The flood detector is not seeing the access through the >> kmap_atomic() pte, because that access has gone through the emulator. >> last_updated_pte_accessed(vcpu) will never return true. >> >> Can you verify that last_updated_pte_accessed(vcpu) indeed always >> returns false? >> > > It returns both true and false. I added a tracer to kvm_mmu_pte_write() to > dump > the rc of last_updated_pte_accessed(vcpu). ie., > pte_access = last_updated_pte_accessed(vcpu); > KVMTRACE_1D(PTE_ACCESS, vcpu, (u32) pte_access, handler); > > A sample: > > (+4488) VMEXIT [ exitcode = 0x, rip = 0x c016104a ] > (+ 0) PAGE_FAULT [ errorcode = 0x000b, virt = 0x > fffb63b0 ] > (+2480) PAGE_FAULT1 [ write_count = 0 ] > (+ 424) PAGE_FAULT2 [ level = 2 metaphysical = 0 access 0x0007 ] > (+ 51672) PAGE_FAULT3 > (+ 472) PAGE_FAULT4 > (+ 704) PAGE_FAULT5 [ shadow_ent = 0x8001 2dfb5043 ] > (+1496) VMENTRY > (+4568) VMEXIT [ exitcode = 0x, rip = 0x c01610e7 ] > (+ 0) PAGE_FAULT [ errorcode = 0x0003, virt = 0x > c0009db4 ] > (+2352) PAGE_FAULT1 [ write_count = 0 ] > (+ 728) PAGE_FAULT5 [ shadow_ent = 0x0001 91409041 ] > (+ 0) PTE_WRITE[ gpa = 0x 9db4 gpte = 0x > 41fb5363 ] > (+ 0) PTE_ACCESS [ pte_access = 1 ] > (+6864) VMENTRY > (+3896) VMEXIT [ exitcode = 0x, rip = 0x c01610ee ] > (+ 0) PAGE_FAULT [ errorcode = 0x0003, virt = 0x > c0009db0 ] > (+2376) PAGE_FAULT1 [ write_count = 1 ] > (+ 720) PAGE_FAULT5 [ shadow_ent = 0x0001 91409041 ] > (+ 0) PTE_WRITE[ gpa = 0x 9db0 gpte = 0x > ] > (+ 0) PTE_ACCESS [ pte_access = 0 ] > (+ 12344) VMENTRY > (+4688) VMEXIT [ exitcode = 0x, rip = 0x c016127c ] > (+ 0) PAGE_FAULT [ errorcode = 0x0003, virt = 0x > c0009db4 ] > (+2416) PAGE_FAULT1 [ write_count = 2 ] > (+ 792) PAGE_FAULT5 [ shadow_ent = 0x0001 91409043 ] > (+1128) VMENTRY > (+4512) VMEXIT [ exitcode = 0x, rip = 0x c016104a ] > (+ 0) PAGE_FAULT [ errorcode = 0x000b, virt = 0x > fffb63b0 ] > (+2448) PAGE_FAULT1 [ write_count = 0 ] > (+ 448) PAGE_FAULT2 [ level = 2 metaphysical = 0 access 0x0007 ] > (+ 51520) PAGE_FAULT3 > (+ 432) PAGE_FAULT4 > (+ 696) PAGE_FAULT5 [ shadow_ent = 0x8001 2df5a043 ] > (+1480) VMENTRY > > > david > - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 01 of 12] Core of mmu notifiers
On Thu, Apr 24, 2008 at 05:39:43PM +0200, Andrea Arcangeli wrote:
> There's at least one small issue I noticed so far, that while _release
> don't need to care about _register, but _unregister definitely need to
> care about _register. I've to take the mmap_sem in addition or in
In the end the best is to use the spinlock around those
list_add/list_del they all run in O(1) with the hlist and they take a
few asm insn. This also avoids to take the mmap_sem in exit_mmap, at
exit_mmap time nobody should need to use mmap_sem anymore, it might
work but this looks cleaner. The lock is dynamically allocated only
when the notifiers are registered, so the few bytes taken by it aren't
relevant.
A full new update will some become visible here:
http://www.kernel.org/pub/linux/kernel/people/andrea/patches/v2.6/2.6.25/mmu-notifier-v14-pre3/
Please have a close look again. Your help is extremely appreciated and
very helpful as usual! Thanks a lot.
diff -urN xxx/include/linux/mmu_notifier.h xx/include/linux/mmu_notifier.h
--- xxx/include/linux/mmu_notifier.h2008-04-24 19:41:15.0 +0200
+++ xx/include/linux/mmu_notifier.h 2008-04-24 19:38:37.0 +0200
@@ -15,7 +15,7 @@
struct hlist_head list;
struct srcu_struct srcu;
/* to serialize mmu_notifier_unregister against mmu_notifier_release */
- spinlock_t unregister_lock;
+ spinlock_t lock;
};
struct mmu_notifier_ops {
diff -urN xxx/mm/memory.c xx/mm/memory.c
--- xxx/mm/memory.c 2008-04-24 19:41:15.0 +0200
+++ xx/mm/memory.c 2008-04-24 19:38:37.0 +0200
@@ -605,16 +605,13 @@
* readonly mappings. The tradeoff is that copy_page_range is more
* efficient than faulting.
*/
- ret = 0;
if (!(vma->vm_flags &
(VM_HUGETLB|VM_NONLINEAR|VM_PFNMAP|VM_INSERTPAGE))) {
if (!vma->anon_vma)
- goto out;
+ return 0;
}
- if (unlikely(is_vm_hugetlb_page(vma))) {
- ret = copy_hugetlb_page_range(dst_mm, src_mm, vma);
- goto out;
- }
+ if (is_vm_hugetlb_page(vma))
+ return copy_hugetlb_page_range(dst_mm, src_mm, vma);
if (is_cow_mapping(vma->vm_flags))
mmu_notifier_invalidate_range_start(src_mm, addr, end);
@@ -636,7 +633,6 @@
if (is_cow_mapping(vma->vm_flags))
mmu_notifier_invalidate_range_end(src_mm,
vma->vm_start, end);
-out:
return ret;
}
diff -urN xxx/mm/mmap.c xx/mm/mmap.c
--- xxx/mm/mmap.c 2008-04-24 19:41:15.0 +0200
+++ xx/mm/mmap.c2008-04-24 19:38:37.0 +0200
@@ -2381,7 +2381,7 @@
if (data->nr_anon_vma_locks)
mm_unlock_vfree(data->anon_vma_locks,
data->nr_anon_vma_locks);
- if (data->i_mmap_locks)
+ if (data->nr_i_mmap_locks)
mm_unlock_vfree(data->i_mmap_locks,
data->nr_i_mmap_locks);
}
diff -urN xxx/mm/mmu_notifier.c xx/mm/mmu_notifier.c
--- xxx/mm/mmu_notifier.c 2008-04-24 19:41:15.0 +0200
+++ xx/mm/mmu_notifier.c2008-04-24 19:31:23.0 +0200
@@ -24,22 +24,16 @@
* zero). All other tasks of this mm already quit so they can't invoke
* mmu notifiers anymore. This can run concurrently only against
* mmu_notifier_unregister and it serializes against it with the
- * unregister_lock in addition to RCU. struct mmu_notifier_mm can't go
- * away from under us as the exit_mmap holds a mm_count pin itself.
- *
- * The ->release method can't allow the module to be unloaded, the
- * module can only be unloaded after mmu_notifier_unregister run. This
- * is because the release method has to run the ret instruction to
- * return back here, and so it can't allow the ret instruction to be
- * freed.
+ * mmu_notifier_mm->lock in addition to RCU. struct mmu_notifier_mm
+ * can't go away from under us as exit_mmap holds a mm_count pin
+ * itself.
*/
void __mmu_notifier_release(struct mm_struct *mm)
{
struct mmu_notifier *mn;
int srcu;
- srcu = srcu_read_lock(&mm->mmu_notifier_mm->srcu);
- spin_lock(&mm->mmu_notifier_mm->unregister_lock);
+ spin_lock(&mm->mmu_notifier_mm->lock);
while (unlikely(!hlist_empty(&mm->mmu_notifier_mm->list))) {
mn = hlist_entry(mm->mmu_notifier_mm->list.first,
struct mmu_notifier,
@@ -52,23 +46,28 @@
*/
hlist_del_init(&mn->hlist);
/*
+* SRCU here will block mmu_notifier_unregister until
+* ->release returns.
+*/
+ srcu = srcu_read_lock(&mm->mmu_notifier_mm->srcu);
+ spin_unlock(&mm->mmu_notifier_mm->lock);
+ /*
* if ->release
Re: [kvm-devel] Moving kvm lists to kernel.org?
David Miller <[EMAIL PROTECTED]> writes: > I'm fine with adding the list, but we don't do mass subscribes like > that, and this rule applies to every list which moves to vger from > somewhere else. > > People will need to subscribe themselves to the new list. Can someone please resubscribe gmane too for us gmane users when the move occurs? Thanks, -Andi - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH]: Fix MSR_K7_EVNTSEL{0,3} for SVM
Avi Kivity wrote: > Now it uses %rsi instead of %esi, and any junk in the upper bits will > cause the ja to be taken. > > We need to get a reduced testcase to the gcc folks, this is a serious > bug. Any changes in the code to work around this would be fragile. > Avi, I've now filed a bug in the upstream gcc database: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36040 And I came up with a reduced test case, available here: http://people.redhat.com/clalance/rsi-test-case.tar.bz2 If I compile the code in the above and look at the disassembly, it shows the problem; however, I can't reproduce the bug by actually running the code. I suspect the %rsi register is always 0 when we start in this userland code, so I never run into the bogus ja, but I just thought I'd mention it. Chris Lalancette - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] State of NMI support
Hi, I saw kvm-userspace recently merged qemu's new CPU_INTERRUPT_NMI support. But the required infrastructure to use this in kvm mode is not yet visible. Is anyone working on this? Sheng? IIRC, you once said to work on it. Currently I just need the basic mechanism for injecting NMIs into the guest (from special hardware emulation), no full support for in-kernel [A]PICs. But before starting some quick&dirty hack, I would like to know if someone already has a patch pending and is able to share even just preliminary results. Thanks, Jan signature.asc Description: OpenPGP digital signature - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] State of NMI support
On Friday 25 April 2008 08:33:04 Jan Kiszka wrote: > Hi, > > I saw kvm-userspace recently merged qemu's new CPU_INTERRUPT_NMI > support. But the required infrastructure to use this in kvm mode is not > yet visible. Is anyone working on this? Sheng? IIRC, you once said to > work on it. > > Currently I just need the basic mechanism for injecting NMIs into the > guest (from special hardware emulation), no full support for in-kernel > [A]PICs. But before starting some quick&dirty hack, I would like to know > if someone already has a patch pending and is able to share even just > preliminary results. > > Thanks, > Jan Yeah, the patchset is mostly completed. But I have to switch to do EPT enabling these days so don't have time to do more test and push them out... I tested patchset by NMI watchdog(also introduce the logic of the NMI watchlog), about one thousand NMI per second at most. The patchset also did some clean up on VMX interrupt handling. I would like to push the patch next week (if the EPT things can be done this week or early next week). Sorry for keep you waiting so long... -- Thanks Yang, Sheng - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] Automatically hibernate XP guest on suspend?
If I suspend my host while running a Windows XP guest, the whole machine crashes, so I was hoping to automate hibernation of the guest OS and integrate that into my host's suspend process. Does anyone know how to do that? TIA, -- Dave Abrahams Boost Consulting http://boost-consulting.com - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 0/10] Factorize code in translate.c
Hi, This series is an (initial) attempt to make qemu code a little bit more modular. In this patch series specifically, I'm removing some #ifdef TARGET_* from the general-purpose translate.c, and rather, replacing them with a common function implemented in architecture specific files. Any rants and complaints, let me know Hope you like it - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 02/10] arm: replace code inside ifdef with generic function
this patch replaced code inside specific ifdef in translate-all.c
with a generic architecture-implemented function. This leads to a
cleaner and more modular code in the generic part.
---
target-arm/translate.c |5 +
translate-all.c|2 +-
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/target-arm/translate.c b/target-arm/translate.c
index 6de78f8..8966996 100644
--- a/target-arm/translate.c
+++ b/target-arm/translate.c
@@ -7706,3 +7706,8 @@ void cpu_dump_state(CPUState *env, FILE *f,
cpu_fprintf(f, "FPSCR: %08x\n", (int)env->vfp.xregs[ARM_VFP_FPSCR]);
}
+void gen_pc_load(CPUState *env, TranslationBlock *tb,
+unsigned long searched_pc, int pc_pos, void *puc)
+{
+env->regs[15] = gen_opc_pc[pc_pos];
+}
diff --git a/translate-all.c b/translate-all.c
index 73e1d67..e688318 100644
--- a/translate-all.c
+++ b/translate-all.c
@@ -196,7 +196,7 @@ int cpu_restore_state(TranslationBlock *tb,
#if defined(TARGET_I386)
gen_pc_load(env, tb, searched_pc, j, puc);
#elif defined(TARGET_ARM)
-env->regs[15] = gen_opc_pc[j];
+gen_pc_load(env, tb, searched_pc, j, puc);
#elif defined(TARGET_SPARC)
{
target_ulong npc;
--
1.5.0.6
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 01/10] i386: replace code inside ifdef with generic function
this patch replaced code inside specific ifdef in translate-all.c
with a generic architecture-implemented function. This leads to a
cleaner and more modular code in the generic part.
---
exec-all.h |3 +++
target-i386/translate.c | 23 +++
translate-all.c | 22 +-
3 files changed, 27 insertions(+), 21 deletions(-)
diff --git a/exec-all.h b/exec-all.h
index 62b8191..3ce8242 100644
--- a/exec-all.h
+++ b/exec-all.h
@@ -61,6 +61,9 @@ extern int loglevel;
int gen_intermediate_code(CPUState *env, struct TranslationBlock *tb);
int gen_intermediate_code_pc(CPUState *env, struct TranslationBlock *tb);
+void gen_pc_load(CPUState *env, struct TranslationBlock *tb,
+ unsigned long searched_pc, int pc_pos, void *puc);
+
unsigned long code_gen_max_block_size(void);
void cpu_gen_init(void);
int cpu_gen_code(CPUState *env, struct TranslationBlock *tb,
diff --git a/target-i386/translate.c b/target-i386/translate.c
index 356ceff..895d14b 100644
--- a/target-i386/translate.c
+++ b/target-i386/translate.c
@@ -6832,3 +6832,26 @@ int gen_intermediate_code_pc(CPUState *env,
TranslationBlock *tb)
return gen_intermediate_code_internal(env, tb, 1);
}
+void gen_pc_load(CPUState *env, TranslationBlock *tb,
+unsigned long searched_pc, int pc_pos, void *puc)
+{
+int cc_op;
+#ifdef DEBUG_DISAS
+if (loglevel & CPU_LOG_TB_OP) {
+int i;
+fprintf(logfile, "RESTORE:\n");
+for(i = 0;i <= pc_pos; i++) {
+if (gen_opc_instr_start[i]) {
+fprintf(logfile, "0x%04x: " TARGET_FMT_lx "\n", i,
gen_opc_pc[i]);
+}
+}
+fprintf(logfile, "spc=0x%08lx pc_pos=0x%x eip=" TARGET_FMT_lx "
cs_base=%x\n",
+searched_pc, pc_pos, gen_opc_pc[pc_pos] - tb->cs_base,
+(uint32_t)tb->cs_base);
+}
+#endif
+env->eip = gen_opc_pc[pc_pos] - tb->cs_base;
+cc_op = gen_opc_cc_op[pc_pos];
+if (cc_op != CC_OP_DYNAMIC)
+env->cc_op = cc_op;
+}
diff --git a/translate-all.c b/translate-all.c
index 6a273a8..73e1d67 100644
--- a/translate-all.c
+++ b/translate-all.c
@@ -194,27 +194,7 @@ int cpu_restore_state(TranslationBlock *tb,
while (gen_opc_instr_start[j] == 0)
j--;
#if defined(TARGET_I386)
-{
-int cc_op;
-#ifdef DEBUG_DISAS
-if (loglevel & CPU_LOG_TB_OP) {
-int i;
-fprintf(logfile, "RESTORE:\n");
-for(i=0;i<=j; i++) {
-if (gen_opc_instr_start[i]) {
-fprintf(logfile, "0x%04x: " TARGET_FMT_lx "\n", i,
gen_opc_pc[i]);
-}
-}
-fprintf(logfile, "spc=0x%08lx j=0x%x eip=" TARGET_FMT_lx "
cs_base=%x\n",
-searched_pc, j, gen_opc_pc[j] - tb->cs_base,
-(uint32_t)tb->cs_base);
-}
-#endif
-env->eip = gen_opc_pc[j] - tb->cs_base;
-cc_op = gen_opc_cc_op[j];
-if (cc_op != CC_OP_DYNAMIC)
-env->cc_op = cc_op;
-}
+gen_pc_load(env, tb, searched_pc, j, puc);
#elif defined(TARGET_ARM)
env->regs[15] = gen_opc_pc[j];
#elif defined(TARGET_SPARC)
--
1.5.0.6
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 03/10] sparc: replace code inside ifdef with generic function
this patch replaced code inside specific ifdef in translate-all.c
with a generic architecture-implemented function. This leads to a
cleaner and more modular code in the generic part.
---
target-sparc/translate.c | 20
translate-all.c | 18 +-
2 files changed, 21 insertions(+), 17 deletions(-)
diff --git a/target-sparc/translate.c b/target-sparc/translate.c
index 90d9278..6edf64d 100644
--- a/target-sparc/translate.c
+++ b/target-sparc/translate.c
@@ -4659,3 +4659,23 @@ void gen_intermediate_code_init(CPUSPARCState *env)
gregnames[i]);
}
}
+
+void gen_pc_load(CPUState *env, TranslationBlock *tb,
+unsigned long searched_pc, int pc_pos, void *puc)
+{
+target_ulong npc;
+env->pc = gen_opc_pc[pc_pos];
+npc = gen_opc_npc[pc_pos];
+if (npc == 1) {
+/* dynamic NPC: already stored */
+} else if (npc == 2) {
+target_ulong t2 = (target_ulong)(unsigned long)puc;
+/* jump PC: use T2 and the jump targets of the translation */
+if (t2)
+env->npc = gen_opc_jump_pc[0];
+else
+env->npc = gen_opc_jump_pc[1];
+} else {
+env->npc = npc;
+}
+}
diff --git a/translate-all.c b/translate-all.c
index e688318..92c8f1c 100644
--- a/translate-all.c
+++ b/translate-all.c
@@ -198,23 +198,7 @@ int cpu_restore_state(TranslationBlock *tb,
#elif defined(TARGET_ARM)
gen_pc_load(env, tb, searched_pc, j, puc);
#elif defined(TARGET_SPARC)
-{
-target_ulong npc;
-env->pc = gen_opc_pc[j];
-npc = gen_opc_npc[j];
-if (npc == 1) {
-/* dynamic NPC: already stored */
-} else if (npc == 2) {
-target_ulong t2 = (target_ulong)(unsigned long)puc;
-/* jump PC: use T2 and the jump targets of the translation */
-if (t2)
-env->npc = gen_opc_jump_pc[0];
-else
-env->npc = gen_opc_jump_pc[1];
-} else {
-env->npc = npc;
-}
-}
+gen_pc_load(env, tb, searched_pc, j, puc);
#elif defined(TARGET_PPC)
{
int type, c;
--
1.5.0.6
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 04/10] ppc: replace code inside ifdef with generic function
this patch replaced code inside specific ifdef in translate-all.c
with a generic architecture-implemented function. This leads to a
cleaner and more modular code in the generic part.
---
target-ppc/translate.c | 42 ++
translate-all.c| 40 +---
2 files changed, 43 insertions(+), 39 deletions(-)
diff --git a/target-ppc/translate.c b/target-ppc/translate.c
index c9530eb..6f7d16c 100644
--- a/target-ppc/translate.c
+++ b/target-ppc/translate.c
@@ -6344,3 +6344,45 @@ int gen_intermediate_code_pc (CPUState *env, struct
TranslationBlock *tb)
{
return gen_intermediate_code_internal(env, tb, 1);
}
+
+void gen_pc_load(CPUState *env, TranslationBlock *tb,
+unsigned long searched_pc, int pc_pos, void *puc)
+{
+int type, c;
+/* for PPC, we need to look at the micro operation to get the
+ * access type */
+env->nip = gen_opc_pc[pc_pos];
+c = gen_opc_buf[pc_pos];
+switch(c) {
+#if defined(CONFIG_USER_ONLY)
+#define CASE3(op)\
+case INDEX_op_ ## op ## _raw
+#else
+#define CASE3(op)\
+case INDEX_op_ ## op ## _user:\
+case INDEX_op_ ## op ## _kernel:\
+case INDEX_op_ ## op ## _hypv
+#endif
+
+CASE3(stfd):
+CASE3(stfs):
+CASE3(lfd):
+CASE3(lfs):
+type = ACCESS_FLOAT;
+break;
+CASE3(lwarx):
+type = ACCESS_RES;
+break;
+CASE3(stwcx):
+type = ACCESS_RES;
+break;
+CASE3(eciwx):
+CASE3(ecowx):
+type = ACCESS_EXT;
+break;
+default:
+type = ACCESS_INT;
+break;
+}
+env->access_type = type;
+}
diff --git a/translate-all.c b/translate-all.c
index 92c8f1c..66f03e1 100644
--- a/translate-all.c
+++ b/translate-all.c
@@ -200,45 +200,7 @@ int cpu_restore_state(TranslationBlock *tb,
#elif defined(TARGET_SPARC)
gen_pc_load(env, tb, searched_pc, j, puc);
#elif defined(TARGET_PPC)
-{
-int type, c;
-/* for PPC, we need to look at the micro operation to get the
- access type */
-env->nip = gen_opc_pc[j];
-c = gen_opc_buf[j];
-switch(c) {
-#if defined(CONFIG_USER_ONLY)
-#define CASE3(op)\
-case INDEX_op_ ## op ## _raw
-#else
-#define CASE3(op)\
-case INDEX_op_ ## op ## _user:\
-case INDEX_op_ ## op ## _kernel:\
-case INDEX_op_ ## op ## _hypv
-#endif
-
-CASE3(stfd):
-CASE3(stfs):
-CASE3(lfd):
-CASE3(lfs):
-type = ACCESS_FLOAT;
-break;
-CASE3(lwarx):
-type = ACCESS_RES;
-break;
-CASE3(stwcx):
-type = ACCESS_RES;
-break;
-CASE3(eciwx):
-CASE3(ecowx):
-type = ACCESS_EXT;
-break;
-default:
-type = ACCESS_INT;
-break;
-}
-env->access_type = type;
-}
+gen_pc_load(env, tb, searched_pc, j, puc);
#elif defined(TARGET_M68K)
env->pc = gen_opc_pc[j];
#elif defined(TARGET_MIPS)
--
1.5.0.6
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 05/10] m68k: replace code inside ifdef with generic function
this patch replaced code inside specific ifdef in translate-all.c
with a generic architecture-implemented function. This leads to a
cleaner and more modular code in the generic part.
---
target-m68k/translate.c |5 +
translate-all.c |2 +-
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/target-m68k/translate.c b/target-m68k/translate.c
index 39816f4..36e27a1 100644
--- a/target-m68k/translate.c
+++ b/target-m68k/translate.c
@@ -3280,3 +3280,8 @@ void cpu_dump_state(CPUState *env, FILE *f,
cpu_fprintf (f, "FPRESULT = %12g\n", *(double *)&env->fp_result);
}
+void gen_pc_load(CPUState *env, TranslationBlock *tb,
+unsigned long searched_pc, int pc_pos, void *puc)
+{
+env->pc = gen_opc_pc[pc_pos];
+}
diff --git a/translate-all.c b/translate-all.c
index 66f03e1..5e63978 100644
--- a/translate-all.c
+++ b/translate-all.c
@@ -202,7 +202,7 @@ int cpu_restore_state(TranslationBlock *tb,
#elif defined(TARGET_PPC)
gen_pc_load(env, tb, searched_pc, j, puc);
#elif defined(TARGET_M68K)
-env->pc = gen_opc_pc[j];
+gen_pc_load(env, tb, searched_pc, j, puc);
#elif defined(TARGET_MIPS)
env->PC[env->current_tc] = gen_opc_pc[j];
env->hflags &= ~MIPS_HFLAG_BMASK;
--
1.5.0.6
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 06/10] mips: replace code inside ifdef with generic function
this patch replaced code inside specific ifdef in translate-all.c
with a generic architecture-implemented function. This leads to a
cleaner and more modular code in the generic part.
---
target-mips/translate.c |8
translate-all.c |4 +---
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/target-mips/translate.c b/target-mips/translate.c
index 65f0ba9..46b917e 100644
--- a/target-mips/translate.c
+++ b/target-mips/translate.c
@@ -6942,3 +6942,11 @@ void cpu_reset (CPUMIPSState *env)
#endif
cpu_mips_register(env, env->cpu_model);
}
+
+void gen_pc_load(CPUState *env, TranslationBlock *tb,
+unsigned long searched_pc, int pc_pos, void *puc)
+{
+env->PC[env->current_tc] = gen_opc_pc[pc_pos];
+env->hflags &= ~MIPS_HFLAG_BMASK;
+env->hflags |= gen_opc_hflags[pc_pos];
+}
diff --git a/translate-all.c b/translate-all.c
index 5e63978..d2408f6 100644
--- a/translate-all.c
+++ b/translate-all.c
@@ -204,9 +204,7 @@ int cpu_restore_state(TranslationBlock *tb,
#elif defined(TARGET_M68K)
gen_pc_load(env, tb, searched_pc, j, puc);
#elif defined(TARGET_MIPS)
-env->PC[env->current_tc] = gen_opc_pc[j];
-env->hflags &= ~MIPS_HFLAG_BMASK;
-env->hflags |= gen_opc_hflags[j];
+gen_pc_load(env, tb, searched_pc, j, puc);
#elif defined(TARGET_ALPHA)
env->pc = gen_opc_pc[j];
#elif defined(TARGET_SH4)
--
1.5.0.6
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 07/10] alpha: replace code inside ifdef with generic function
this patch replaced code inside specific ifdef in translate-all.c
with a generic architecture-implemented function. This leads to a
cleaner and more modular code in the generic part.
---
target-alpha/translate.c |5 +
translate-all.c |2 +-
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/target-alpha/translate.c b/target-alpha/translate.c
index 1c8587d..c7bb207 100644
--- a/target-alpha/translate.c
+++ b/target-alpha/translate.c
@@ -2108,3 +2108,8 @@ CPUAlphaState * cpu_alpha_init (const char *cpu_model)
return env;
}
+void gen_pc_load(CPUState *env, TranslationBlock *tb,
+unsigned long searched_pc, int pc_pos, void *puc)
+{
+env->pc = gen_opc_pc[pc_pos];
+}
diff --git a/translate-all.c b/translate-all.c
index d2408f6..bcad1f4 100644
--- a/translate-all.c
+++ b/translate-all.c
@@ -206,7 +206,7 @@ int cpu_restore_state(TranslationBlock *tb,
#elif defined(TARGET_MIPS)
gen_pc_load(env, tb, searched_pc, j, puc);
#elif defined(TARGET_ALPHA)
-env->pc = gen_opc_pc[j];
+gen_pc_load(env, tb, searched_pc, j, puc);
#elif defined(TARGET_SH4)
env->pc = gen_opc_pc[j];
env->flags = gen_opc_hflags[j];
--
1.5.0.6
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 08/10] sh4: replace code inside ifdef with generic function
this patch replaced code inside specific ifdef in translate-all.c
with a generic architecture-implemented function. This leads to a
cleaner and more modular code in the generic part.
---
target-sh4/translate.c |7 +++
translate-all.c|3 +--
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/target-sh4/translate.c b/target-sh4/translate.c
index b7c5f8d..1468e7a 100644
--- a/target-sh4/translate.c
+++ b/target-sh4/translate.c
@@ -1302,3 +1302,10 @@ int gen_intermediate_code_pc(CPUState * env, struct
TranslationBlock *tb)
{
return gen_intermediate_code_internal(env, tb, 1);
}
+
+void gen_pc_load(CPUState *env, TranslationBlock *tb,
+unsigned long searched_pc, int pc_pos, void *puc)
+{
+env->pc = gen_opc_pc[pc_pos];
+env->flags = gen_opc_hflags[pc_pos];
+}
diff --git a/translate-all.c b/translate-all.c
index bcad1f4..401969c 100644
--- a/translate-all.c
+++ b/translate-all.c
@@ -208,8 +208,7 @@ int cpu_restore_state(TranslationBlock *tb,
#elif defined(TARGET_ALPHA)
gen_pc_load(env, tb, searched_pc, j, puc);
#elif defined(TARGET_SH4)
-env->pc = gen_opc_pc[j];
-env->flags = gen_opc_hflags[j];
+gen_pc_load(env, tb, searched_pc, j, puc);
#elif defined(TARGET_CRIS)
env->pregs[PR_ERP] = gen_opc_pc[j];
#endif
--
1.5.0.6
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 09/10] cris: replace code inside ifdef with generic function
this patch replaced code inside specific ifdef in translate-all.c
with a generic architecture-implemented function. This leads to a
cleaner and more modular code in the generic part.
---
target-cris/translate.c |6 ++
translate-all.c |2 +-
2 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/target-cris/translate.c b/target-cris/translate.c
index 5769175..e522678 100644
--- a/target-cris/translate.c
+++ b/target-cris/translate.c
@@ -2701,3 +2701,9 @@ void cpu_reset (CPUCRISState *env)
memset(env, 0, offsetof(CPUCRISState, breakpoints));
tlb_flush(env, 1);
}
+
+void gen_pc_load(CPUState *env, struct TranslationBlock *tb,
+ unsigned long searched_pc, int pc_pos, void *puc)
+{
+env->pregs[PR_ERP] = gen_opc_pc[pc_pos];
+}
diff --git a/translate-all.c b/translate-all.c
index 401969c..3afb656 100644
--- a/translate-all.c
+++ b/translate-all.c
@@ -210,7 +210,7 @@ int cpu_restore_state(TranslationBlock *tb,
#elif defined(TARGET_SH4)
gen_pc_load(env, tb, searched_pc, j, puc);
#elif defined(TARGET_CRIS)
-env->pregs[PR_ERP] = gen_opc_pc[j];
+gen_pc_load(env, tb, searched_pc, j, puc);
#endif
#ifdef CONFIG_PROFILER
--
1.5.0.6
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 10/10] remove arch-specific ifdefs from translate-all.c
As the current state of matters, all architectures call a function with the same name and signature for updating the pc. Remove the ifdefs, leading to a cleaner code --- translate-all.c | 19 +-- 1 files changed, 1 insertions(+), 18 deletions(-) diff --git a/translate-all.c b/translate-all.c index 3afb656..83056d5 100644 --- a/translate-all.c +++ b/translate-all.c @@ -193,25 +193,8 @@ int cpu_restore_state(TranslationBlock *tb, /* now find start of instruction before */ while (gen_opc_instr_start[j] == 0) j--; -#if defined(TARGET_I386) + gen_pc_load(env, tb, searched_pc, j, puc); -#elif defined(TARGET_ARM) -gen_pc_load(env, tb, searched_pc, j, puc); -#elif defined(TARGET_SPARC) -gen_pc_load(env, tb, searched_pc, j, puc); -#elif defined(TARGET_PPC) -gen_pc_load(env, tb, searched_pc, j, puc); -#elif defined(TARGET_M68K) -gen_pc_load(env, tb, searched_pc, j, puc); -#elif defined(TARGET_MIPS) -gen_pc_load(env, tb, searched_pc, j, puc); -#elif defined(TARGET_ALPHA) -gen_pc_load(env, tb, searched_pc, j, puc); -#elif defined(TARGET_SH4) -gen_pc_load(env, tb, searched_pc, j, puc); -#elif defined(TARGET_CRIS) -gen_pc_load(env, tb, searched_pc, j, puc); -#endif #ifdef CONFIG_PROFILER dyngen_restore_time += profile_getclock() - ti; -- 1.5.0.6 - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 3 of 3] Add premption handlers & properly wake sleeping guest
2 files changed, 16 insertions(+)
arch/powerpc/kvm/booke_guest.c |6 ++
arch/powerpc/kvm/powerpc.c | 10 ++
This patch adds vcpu_put & vpu_load in strategic places (as x86 does it), for
use of premption. This patch also adds a very critial bit need to wake up guest
that end up going to being rescheduled and go to sleep.
Signed-off-by: Jerone Young <[EMAIL PROTECTED]>
diff --git a/arch/powerpc/kvm/booke_guest.c b/arch/powerpc/kvm/booke_guest.c
--- a/arch/powerpc/kvm/booke_guest.c
+++ b/arch/powerpc/kvm/booke_guest.c
@@ -514,6 +514,8 @@ int kvm_arch_vcpu_ioctl_get_regs(struct
{
int i;
+ vcpu_load(vcpu);
+
regs->pc = vcpu->arch.pc;
regs->cr = vcpu->arch.cr;
regs->ctr = vcpu->arch.ctr;
@@ -533,6 +535,8 @@ int kvm_arch_vcpu_ioctl_get_regs(struct
for (i = 0; i < ARRAY_SIZE(regs->gpr); i++)
regs->gpr[i] = vcpu->arch.gpr[i];
+
+ vcpu_put(vcpu);
return 0;
}
@@ -595,6 +599,7 @@ int kvm_arch_vcpu_ioctl_translate(struct
u8 pid;
u8 as;
+ vcpu_load(vcpu);
eaddr = tr->linear_address;
pid = (tr->linear_address >> 32) & 0xff;
as = (tr->linear_address >> 40) & 0x1;
@@ -610,6 +615,7 @@ int kvm_arch_vcpu_ioctl_translate(struct
tr->physical_address = tlb_xlate(gtlbe, eaddr);
/* XXX what does "writeable" and "usermode" even mean? */
tr->valid = 1;
+ vcpu_put(vcpu);
return 0;
}
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -212,6 +212,9 @@ static void kvmppc_decrementer_func(unsi
{
struct kvm_vcpu *vcpu = (struct kvm_vcpu *)data;
+ if (waitqueue_active(&vcpu->wq))
+ wake_up_interruptible(&vcpu->wq);
+
kvmppc_queue_exception(vcpu, BOOKE_INTERRUPT_DECREMENTER);
}
@@ -338,6 +341,8 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_v
int r;
sigset_t sigsaved;
+ vcpu_load(vcpu);
+
if (vcpu->sigset_active)
sigprocmask(SIG_SETMASK, &vcpu->sigset, &sigsaved);
@@ -362,12 +367,17 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_v
if (vcpu->sigset_active)
sigprocmask(SIG_SETMASK, &sigsaved, NULL);
+ vcpu_put(vcpu);
+
return r;
}
int kvm_vcpu_ioctl_interrupt(struct kvm_vcpu *vcpu, struct kvm_interrupt *irq)
{
+ vcpu_load(vcpu);
kvmppc_queue_exception(vcpu, BOOKE_INTERRUPT_EXTERNAL);
+ vcpu_put(vcpu);
+
return 0;
}
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 0 of 3] Fix guest eating 100% cpu when guest is idle on PowerPC
This set of patches fixes 100% CPU usage when a guest is idle on PowerPC. This ti me it uses common kvm functions to sleep the guest. Signed-off-by: Jerone Young <[EMAIL PROTECTED]> 5 files changed, 91 insertions(+), 4 deletions(-) arch/powerpc/kvm/booke_guest.c |6 +++ arch/powerpc/kvm/emulate.c |5 ++ arch/powerpc/kvm/powerpc.c | 15 ++- arch/powerpc/platforms/44x/Makefile |2 - arch/powerpc/platforms/44x/idle.c | 67 +++ - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 1 of 3] Add idle wait support for 44x platforms
2 files changed, 68 insertions(+), 1 deletion(-)
arch/powerpc/platforms/44x/Makefile |2 -
arch/powerpc/platforms/44x/idle.c | 67 +++
This patch has been accepted upstream and will be in 2.6.26. So it will
eventually need to be removed when we move to 2.6.26rc.
This patch adds the ability for the CPU to go into wait state while in cpu_idle
loop. This helps virtulization solutions know when the guest Linux kernel is in
an idle state. There are two ways to do it.
Command line options:
idle=spin <-- CPU will spin
By default will go into wait mode.
Signed-off-by: Jerone Young <[EMAIL PROTECTED]>
diff --git a/arch/powerpc/platforms/44x/Makefile
b/arch/powerpc/platforms/44x/Makefile
--- a/arch/powerpc/platforms/44x/Makefile
+++ b/arch/powerpc/platforms/44x/Makefile
@@ -1,4 +1,4 @@ obj-$(CONFIG_44x) := misc_44x.o
-obj-$(CONFIG_44x) := misc_44x.o
+obj-$(CONFIG_44x) := misc_44x.o idle.o
obj-$(CONFIG_EBONY)+= ebony.o
obj-$(CONFIG_TAISHAN) += taishan.o
obj-$(CONFIG_BAMBOO) += bamboo.o
diff --git a/arch/powerpc/platforms/44x/idle.c
b/arch/powerpc/platforms/44x/idle.c
new file mode 100644
--- /dev/null
+++ b/arch/powerpc/platforms/44x/idle.c
@@ -0,0 +1,67 @@
+/*
+ * Copyright 2008 IBM Corp.
+ *
+ * Based on arch/powerpc/platforms/pasemi/idle.c:
+ * Copyright (C) 2006-2007 PA Semi, Inc
+ *
+ * Added by: Jerone Young <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#include
+#include
+#include
+
+static int mode_spin;
+
+static void ppc44x_idle(void)
+{
+ unsigned long msr_save;
+
+ msr_save = mfmsr();
+ /* set wait state MSR */
+ mtmsr(msr_save|MSR_WE|MSR_EE|MSR_CE|MSR_DE);
+ isync();
+ /* return to initial state */
+ mtmsr(msr_save);
+ isync();
+}
+
+int __init ppc44x_idle_init(void)
+{
+ if (!mode_spin) {
+ /* If we are not setting spin mode
+ then we set to wait mode */
+ ppc_md.power_save = &ppc44x_idle;
+ }
+
+ return 0;
+}
+
+arch_initcall(ppc44x_idle_init);
+
+static int __init idle_param(char *p)
+{
+
+ if (!strcmp("spin", p)) {
+ mode_spin = 1;
+ ppc_md.power_save = NULL;
+ }
+
+ return 0;
+}
+
+early_param("idle", idle_param);
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 2 of 3] Add PowerPC KVM guest wait handling support
2 files changed, 7 insertions(+), 3 deletions(-)
arch/powerpc/kvm/emulate.c |5 +
arch/powerpc/kvm/powerpc.c |5 ++---
This patch handles a guest that is in a wait state. This ensures that the guest
is not allways eating up 100% cpu when it is idle.
Signed-off-by: Jerone Young <[EMAIL PROTECTED]>
diff --git a/arch/powerpc/kvm/emulate.c b/arch/powerpc/kvm/emulate.c
--- a/arch/powerpc/kvm/emulate.c
+++ b/arch/powerpc/kvm/emulate.c
@@ -265,6 +265,11 @@ int kvmppc_emulate_instruction(struct kv
case 146: /* mtmsr */
rs = get_rs(inst);
kvmppc_set_msr(vcpu, vcpu->arch.gpr[rs]);
+
+ /* handle guest vcpu that is in wait state */
+ if (vcpu->arch.msr & MSR_WE) {
+ kvm_vcpu_block(vcpu);
+ }
break;
case 163: /* wrteei */
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -36,13 +36,12 @@ gfn_t unalias_gfn(struct kvm *kvm, gfn_t
int kvm_cpu_has_interrupt(struct kvm_vcpu *v)
{
- /* XXX implement me */
- return 0;
+ return !!(v->arch.pending_exceptions);
}
int kvm_arch_vcpu_runnable(struct kvm_vcpu *v)
{
- return 1;
+ return !(v->arch.msr & MSR_WE);
}
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Real Mode Improvement on Intel Hosts - GSoC Project
On Thu, 24 Apr 2008 11:05:39 -0500
Anthony Liguori <[EMAIL PROTECTED]> wrote:
> The first stage is to detect vmentry failures and run x86_emulate() for
> a single instruction. If you look at the mailing list, you'll see
> patches from myself and Guillaume. This should be enough to allow most
> Ubuntu installer CDs to work under KVM.
Howdy,
Here is the last patch I have. It can detects a vmentry failure and it
emulates one instruction. I added the emulation of several instructions
like "ljmp", "mov Sreg, reg", "mov reg, Sreg"... The problem I'm
working on is that once I entered in emulation of real mode I do not
manage to recover a VMX friendly state (in my case cs.rpl ==
ss.rpl). So I emulate more and more instructions.
I added a trace to see instructions that are emulated (emulation of
0xa8 is in progress so it currently fails):
[60108.040894] emulation at (46e53) rip 6e13: ea 18 6e 18
[60108.072108] emulation at (46e58) rip 6e18: 66 b8 20 00
[60108.103997] emulation at (46e5c) rip 6e1c: 8e d8 8c d0
[60108.148114] emulation at (46e5e) rip 6e1e: 8c d0 81 e4
[60108.180117] emulation at (46e60) rip 6e20: 81 e4 ff ff
[60108.212008] emulation at (46e66) rip 6e26: c1 e0 04 01
[60108.244926] emulation at (46e69) rip 6e29: 01 c4 66 b8
[60108.272948] emulation at (46e6b) rip 6e2b: 66 b8 08 00
[60108.304953] emulation at (46e6f) rip 6e2f: 8e d0 8e c0
[60108.348973] emulation at (46e71) rip 6e31: 8e c0 8e e0
[60108.396965] emulation at (46e73) rip 6e33: 8e e0 8e e8
[60108.445002] emulation at (46e75) rip 6e35: 8e e8 58 66
[60108.489021] emulation at (46e77) rip 6e37: 58 66 9d 66
[60108.521028] emulation at (46e78) rip 6e38: 66 9d 66 c3
[60108.552979] emulation at (46e7a) rip 6e3a: 66 c3 66 9c
[60108.581048] emulation at (40e2a) rip dea: be 29 0a 00
[60108.613033] emulation at (40e2f) rip def: e8 41 12 00
[60108.644970] emulation at (42075) rip 2035: c6 05 84 07
[60108.673038] emulation at (4207c) rip 203c: e8 18 01 00
[60108.705039] emulation at (42199) rip 2159: 31 c0 80 3d
[60108.736998] emulation at (4219b) rip 215b: 80 3d 86 07
[60108.765041] emulation at (421a2) rip 2162: 74 01 26 ac
[60108.797044] emulation at (421a5) rip 2165: ac c3 80 3d
[60108.829033] emulation at (421a6) rip 2166: c3 80 3d 86
[60108.857068] emulation at (42081) rip 2041: 09 c0 0f 84
[60108.889053] emulation at (42083) rip 2043: 0f 84 0f 01
[60108.921054] emulation at (42198) rip 2158: c3 31 c0 80
[60108.949076] emulation at (40e34) rip df4: 26 66 ff 35
[60108.981077] emulation at (40e3c) rip dfc: 66 8f 05 d0
[60109.013011] emulation at (40e43) rip e03: a1 b4 00 00
[60109.041079] emulation at (40e48) rip e08: 26 8a 40 03
[60109.073039] emulation at (40e4c) rip e0c: a8 01 74 4c
[60109.101078] emulation failed (vmentry failure) rip e0c a8 01 74 4c
So as we can see the first emulated instruction is the ljump and after
we emulate gfxboot loader instruction. I suspect a problem with an
update of SS segment or something like that in instructions that I
emulate.
I paste the patch. Don't worry about the last modification of the two
header files it's not related to real mode emulation.
Regards,
Guillaume
---
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 8e5d664..2c4c14d 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -1183,7 +1183,9 @@ static void enter_pmode(struct kvm_vcpu *vcpu)
fix_pmode_dataseg(VCPU_SREG_GS, &vcpu->arch.rmode.gs);
fix_pmode_dataseg(VCPU_SREG_FS, &vcpu->arch.rmode.fs);
+#if 0
vmcs_write16(GUEST_SS_SELECTOR, 0);
+#endif
vmcs_write32(GUEST_SS_AR_BYTES, 0x93);
vmcs_write16(GUEST_CS_SELECTOR,
@@ -2323,6 +2325,53 @@ static int handle_task_switch(struct kvm_vcpu *vcpu,
struct kvm_run *kvm_run)
return kvm_task_switch(vcpu, tss_selector, reason);
}
+static int handle_vmentry_failure(struct kvm_vcpu *vcpu,
+ struct kvm_run *kvm_run, u32 failure_reason)
+{
+ u16 ss, cs;
+ u8 opcodes[4];
+ unsigned long rip = vcpu->arch.rip;
+ unsigned long rip_linear;
+
+ ss = vmcs_read16(GUEST_SS_SELECTOR);
+ cs = vmcs_read16(GUEST_CS_SELECTOR);
+
+ if ((ss & 0x03) != (cs & 0x03)) {
+ int err;
+
+#if 0
+ printk(KERN_INFO "vmentry failure because ss.cpl != cs.cpl\n");
+#endif
+ rip_linear = rip + vmx_get_segment_base(vcpu, VCPU_SREG_CS);
+ emulator_read_std(rip_linear, (void *)opcodes, 4, vcpu);
+ printk(KERN_INFO "emulation at (%lx) rip %lx: %02x %02x %02x
%02x\n",
+ rip_linear,
+ rip, opcodes[0], opcodes[1], opcodes[2],
opcodes[3]);
+ err = emulate_instruction(vcpu, kvm_run, 0, 0, 0);
+ switch (err) {
+ case EMULATE_DONE:
+#if 0
+ printk(KERN_INFO "successfully emulated instruction\n");
+#endif
+ return 1;
+ case EMULATE_DO_MMIO:
+
Re: [kvm-devel] Real Mode Improvement on Intel Hosts - GSoC Project
Guillaume Thouvenin wrote: > On Thu, 24 Apr 2008 11:05:39 -0500 > Anthony Liguori <[EMAIL PROTECTED]> wrote: > > >> The first stage is to detect vmentry failures and run x86_emulate() for >> a single instruction. If you look at the mailing list, you'll see >> patches from myself and Guillaume. This should be enough to allow most >> Ubuntu installer CDs to work under KVM. >> > > Howdy, > > Here is the last patch I have. It can detects a vmentry failure and it > emulates one instruction. I added the emulation of several instructions > like "ljmp", "mov Sreg, reg", "mov reg, Sreg"... The problem I'm > working on is that once I entered in emulation of real mode I do not > manage to recover a VMX friendly state (in my case cs.rpl == > ss.rpl). So I emulate more and more instructions. > > I added a trace to see instructions that are emulated (emulation of > 0xa8 is in progress so it currently fails): > > [60108.040894] emulation at (46e53) rip 6e13: ea 18 6e 18 > Here cs.rpl == cpl == 0 > [60108.072108] emulation at (46e58) rip 6e18: 66 b8 20 00 > [60108.103997] emulation at (46e5c) rip 6e1c: 8e d8 8c d0 > [60108.148114] emulation at (46e5e) rip 6e1e: 8c d0 81 e4 > [60108.180117] emulation at (46e60) rip 6e20: 81 e4 ff ff > [60108.212008] emulation at (46e66) rip 6e26: c1 e0 04 01 > [60108.244926] emulation at (46e69) rip 6e29: 01 c4 66 b8 > [60108.272948] emulation at (46e6b) rip 6e2b: 66 b8 08 00 > mov $8, %eax > [60108.304953] emulation at (46e6f) rip 6e2f: 8e d0 8e c0 > mov %eax, %ss Here, ss.rpl == 0 -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
