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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).