From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Matias Zabaljauregui <zabaljauregui@gmail.com>
Cc: virtualization@lists.osdl.org, lguest@ozlabs.org
Subject: Re: lguest PAE
Date: Tue, 26 May 2009 12:58:47 -0700 [thread overview]
Message-ID: <4A1C49F7.6060804@goop.org> (raw)
In-Reply-To: <1243268749.7267.40.camel@zetabook>
Matias Zabaljauregui wrote:
> Jeremy, I fixed the code following your comments (hope you still
> remember).
>
> I'd like to ask you again about this one:
>
>
>>> /* Found in switcher.S */
>>> extern unsigned long default_idt_entries[];
>>> diff --git a/arch/x86/include/asm/lguest_hcall.h b/arch/x86/include/asm/lguest_hcall.h
>>> index 0f4ee71..3860153 100644
>>> --- a/arch/x86/include/asm/lguest_hcall.h
>>> +++ b/arch/x86/include/asm/lguest_hcall.h
>>> @@ -17,6 +17,7 @@
>>> #define LHCALL_SET_PMD 15
>>> #define LHCALL_LOAD_TLS 16
>>> #define LHCALL_NOTIFY 17
>>> +#define LHCALL_SET_PUD 18
>>>
>>>
>> PGD is more accurate than PUD (here, and the rest of the patch). The
>> pud level of the pagetable is the 4th level used by 64-bit; PAE just has
>> PGD, PMD and PTE levels. Due to pagetable level folding, the PGD is
>> sometimes referred to as the PUD when looking "up" the pagetable tree
>> (ie, the PUD is logically the next level up from the PMD), but its still
>> just an alias for the PGD. Since the hypervisor interface shouldn't
>> care about how the guest OS manages its pagetables, it should use a
>> consistent naming for the levels as they "really" are. Lguest
>> traditionally uses the same names that Linux does, so PGD is appropriate.
>>
>
> I understand, but then should we change also the LHCALL_SET_PMD name ?
> this is the one used for setting a new pgd when PAE is NOT activated.
>
Yeah, that would be consistent. In non-PAE, the pmd is just the next
logical level up from the pte, but just an alias name for the pgd.
> So, just to confirm: even if we are implementing pv_mmu_ops.set_pud
> replacement (lguest_set_pud in our case), we should use LHCALL_SET_PGD
> hypercall name in this code because that is what host is going to
> actually do?
>
Yeah, I guess. The set_pud notation makes some sense within Linux
because of its pagetable-folding, but the actual lguest implementation
is mapping between the guest's abstractions to the hypervisor abi's.
(In Xen this wasn't much of an issue because its the same hypercall for
updating a pagetable at any level, and the hypervisor can work out
what's going on for itself.)
J
prev parent reply other threads:[~2009-05-26 19:58 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-16 17:21 NULL pointer dereference at __switch_to() ( __unlazy_fpu ) with lguest PAE patch Matias Zabaljauregui
2009-04-16 18:26 ` Jeremy Fitzhardinge
[not found] ` <49E7785D.1040501-TSDbQ3PG+2Y@public.gmane.org>
2009-04-17 0:45 ` Matias Zabaljauregui
2009-05-25 16:25 ` lguest PAE Matias Zabaljauregui
2009-05-26 19:58 ` Jeremy Fitzhardinge [this message]
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=4A1C49F7.6060804@goop.org \
--to=jeremy@goop.org \
--cc=lguest@ozlabs.org \
--cc=virtualization@lists.osdl.org \
--cc=zabaljauregui@gmail.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).