Avi Kivity wrote:
> Yang, Sheng wrote:
>>> From ac4dd1782b9f0f51e0c366a1b8db4515d6828df8 Mon Sep 17 00:00:00
2001
>> From: Sheng Yang <[EMAIL PROTECTED]>
>> Date: Tue, 23 Oct 2007 12:34:42 +0800
>> Subject: [PATCH] Enable memory mapped TPR shadow(FlexPriority)
>>
>> This patch based on CR8/TPR patch before, and enable the TPR
>> shadow(FlexPriority) for 32bit Windows. Since TPR is accessed
>> very frequently by 32bit Windows, especially SMP guest, with
>> FlexPriority enabled, we saw significant performance gain.
>>
>
> For the benefit of users, can you detail which processors have this
feature?
Basicly kvm hardware feature detection mechanism should work for that.
But here
I can give some examples: E6850, E6750, E6550, Core2 Duo processors
starting from
G0 stepping should support this.
>
>>
>> static inline struct kvm_pic *pic_irqchip(struct kvm *kvm)
>> @@ -503,6 +504,11 @@ void kvm_mmu_slot_remove_write_access(struct kvm
>> *kvm, int slot); void kvm_mmu_zap_all(struct kvm *kvm);
>> void kvm_mmu_change_mmu_pages(struct kvm *kvm, unsigned int
>> kvm_nr_mmu_pages);
>>
>> +int kvm_vm_ioctl_set_memory_region(struct kvm *kvm, +
struct
>> + kvm_userspace_memory_region *mem,
>> + int user_alloc);
>> +
>>
>
> Exporting an ioctl handler isn't very pretty. Izik is working on a
> patch that also requires an internal memory slot, so he will add an
API
> for it.
OK, that's my hope :-)
I will wait for that.
>
>> --- a/drivers/kvm/kvm_main.c
>> +++ b/drivers/kvm/kvm_main.c
>> @@ -643,10 +643,10 @@ EXPORT_SYMBOL_GPL(fx_init);
>> *
>> * Discontiguous memory is allowed, mostly for framebuffers. */
>> -static int kvm_vm_ioctl_set_memory_region(struct kvm *kvm,
>> - struct
>> - kvm_userspace_memory_region
>> *mem,
>> - int user_alloc)
>> +int kvm_vm_ioctl_set_memory_region(struct kvm *kvm, +
struct
>> + kvm_userspace_memory_region *mem,
>> + int user_alloc)
>> {
>> int r;
>> gfn_t base_gfn;
>> @@ -776,6 +776,7 @@ out_unlock:
>> out:
>> return r;
>> }
>> +EXPORT_SYMBOL_GPL(kvm_vm_ioctl_set_memory_region);
>>
>
> The internal memory slot needs to be hidden from userspace. Hopefully
> Izik's API will add that too.
>
>> +
>> + /* For APIC access vmexit */
>> + if ((gpa & PAGE_MASK) == APIC_DEFAULT_PHYS_BASE)
>> + goto mmio;
>>
>
> What if the guest changes the apic base address?
As Eddie said, we didn't observe this so far. And a workround for
disable this may also
a little complex, so we'd like to do it like this temporary.
>
>> @@ -1610,13 +1675,15 @@ static int vmx_vcpu_reset(struct kvm_vcpu
*vcpu)
>>
>> vmcs_write32(VM_ENTRY_INTR_INFO_FIELD, 0); /* 22.2.1 */
>>
>> -#ifdef CONFIG_X86_64
>> vmcs_write64(VIRTUAL_APIC_PAGE_ADDR, 0);
>>
>
> I think the #ifdef is for a reason... probably Core processors which
> don't support x86_64 (and therefore cr8) don't have this.
>
> Please check.
Thanks for remind. This should be in tpr feature judgement. I will
modify it.
>
>> /*
>> * Interruption-information format
>> diff --git a/drivers/kvm/x86_emulate.c b/drivers/kvm/x86_emulate.c
index
>> f858c01..d24166e 100644 --- a/drivers/kvm/x86_emulate.c
>> +++ b/drivers/kvm/x86_emulate.c
>> @@ -845,6 +845,11 @@ modrm_done:
>> c->src.type = OP_REG;
>> break;
>> }
>> + if (((ctxt->cmd_type & EMULCMD_DECODE_ADDR) != 0) && +
>> (c->modrm_ea == 0)) { + ctxt->cr2 =
insn_fetch(u32, c->src.bytes,
>> c->eip);
>> + c->eip -= c->src.bytes;
>> + }
>>
>
> Please explain this. Is this for mov eax, abs? If so, it's much
> needed, and should be in a separate patch. I don't think
> EMULCMD_DECODE_ADDR is necessary.
Thanks
Yang, Sheng
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
