From: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
To: "Nadav Har'El" <nyh@math.technion.ac.il>
Cc: kvm@vger.kernel.org, Joerg.Roedel@amd.com, avi@redhat.com,
owasserm@redhat.com, abelg@il.ibm.com, eddie.dong@intel.com,
yang.z.zhang@intel.com
Subject: Re: [PATCH 02/10] nEPT: Add EPT tables support to paging_tmpl.h
Date: Fri, 03 Aug 2012 16:08:21 +0800 [thread overview]
Message-ID: <501B86F5.9030209@linux.vnet.ibm.com> (raw)
In-Reply-To: <20120802212533.GA11601@fermat.math.technion.ac.il>
On 08/03/2012 05:25 AM, Nadav Har'El wrote:
> On Thu, Aug 02, 2012, Xiao Guangrong wrote about "Re: [PATCH 02/10] nEPT: Add EPT tables support to paging_tmpl.h":
>>> + #ifdef CONFIG_X86_64
>>> + #define PT_MAX_FULL_LEVELS 4
>>> + #define CMPXCHG cmpxchg
>>> + #else
>>> + #define CMPXCHG cmpxchg64
>>> + #define PT_MAX_FULL_LEVELS 2
>>> + #endif
>>
>> Missing the case of FULL_LEVELS == 3? Oh, you mentioned it
>> as PAE case in the PATCH 0.
>
> I understood this differently (and it would not be surprising if
> wrongly...): With nested EPT, we only deal with two *EPT* tables -
> the shadowed page table and shadow page table are both EPT.
> And EPT tables cannot have three levels - even if PAE is used. Or at least,
> that's what I thought...
>
>> Note A/D bits are supported on new intel cpus, this function should be reworked
>> for nept. I know you did not export this feather to guest, but we can reduce
>> the difference between nept and other mmu models if A/D are supported.
>
> I'm not sure what you meant: If the access/dirty bits are supported in
> newer cpus, do you think we *should* support them also in the processor
> L1 processor, or are you saying that it would be easier to support them
> because this is what the shadow page table code normally does anyway,
> so *not* supporting them will take effort?
I mean "it would be easier to support them
because this is what the shadow page table code normally does anyway,
so *not* supporting them will take effort" :)
Then, we can drop "ifndef PTTYPT_EPT"...
Actuality, we can redefine some bits (like PRSENT, WRTIABLE, DRITY...) to
let the paging_tmpl code work for all models.
>
>>> +#if PTTYPE != PTTYPE_EPT
>>> static int FNAME(walk_addr_nested)(struct guest_walker *walker,
>>> struct kvm_vcpu *vcpu, gva_t addr,
>>> u32 access)
>>> @@ -335,6 +395,7 @@ static int FNAME(walk_addr_nested)(struc
>>> return FNAME(walk_addr_generic)(walker, vcpu, &vcpu->arch.nested_mmu,
>>> addr, access);
>>> }
>>> +#endif
>>>
>>
>> Hmm, you do not need the special walking functions?
>
> Since these functions are static, the compiler warns me on every
> function that is never used, so I had to #if them out...
>
>
IIUC, you did not implement the functions (like walk_addr_nested) to translate
L2's VA to L2's PA, yes? (it is needed for emulation.)
next prev parent reply other threads:[~2012-08-03 8:08 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-01 14:36 [PATCH 0/10] nEPT v2: Nested EPT support for Nested VMX Nadav Har'El
2012-08-01 14:37 ` [PATCH 01/10] nEPT: Support LOAD_IA32_EFER entry/exit controls for L1 Nadav Har'El
2012-08-01 14:37 ` [PATCH 02/10] nEPT: Add EPT tables support to paging_tmpl.h Nadav Har'El
2012-08-02 4:00 ` Xiao Guangrong
2012-08-02 21:25 ` Nadav Har'El
2012-08-03 8:08 ` Xiao Guangrong [this message]
2012-08-01 14:38 ` [PATCH 03/10] nEPT: MMU context for nested EPT Nadav Har'El
2012-08-01 14:38 ` [PATCH 04/10] nEPT: Fix cr3 handling in nested exit and entry Nadav Har'El
2012-08-01 14:39 ` [PATCH 05/10] nEPT: Fix wrong test in kvm_set_cr3 Nadav Har'El
2012-08-01 14:39 ` [PATCH 06/10] nEPT: Some additional comments Nadav Har'El
2012-08-01 14:40 ` [PATCH 07/10] nEPT: Advertise EPT to L1 Nadav Har'El
2012-08-01 14:40 ` [PATCH 08/10] nEPT: Nested INVEPT Nadav Har'El
2012-08-01 14:41 ` [PATCH 09/10] nEPT: Documentation Nadav Har'El
2012-08-01 14:41 ` [PATCH 10/10] nEPT: Miscelleneous cleanups Nadav Har'El
2012-08-01 15:07 ` [PATCH 0/10] nEPT v2: Nested EPT support for Nested VMX Avi Kivity
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=501B86F5.9030209@linux.vnet.ibm.com \
--to=xiaoguangrong@linux.vnet.ibm.com \
--cc=Joerg.Roedel@amd.com \
--cc=abelg@il.ibm.com \
--cc=avi@redhat.com \
--cc=eddie.dong@intel.com \
--cc=kvm@vger.kernel.org \
--cc=nyh@math.technion.ac.il \
--cc=owasserm@redhat.com \
--cc=yang.z.zhang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.