arch_set_info_guest() and cr1

arch_set_info_guest() and cr1

[Mukesh Rathor]

Hi,

Just wondering under what circumstances will cr1 be set in this
function?

int arch_set_info_guest(
    struct vcpu *v, vcpu_guest_context_u c)
{
.....

#ifdef __x86_64__
        if ( c.nat->ctrlreg[1] )           <------
        {
.....



thanks,
Mukesh

Re: arch_set_info_guest() and cr1

[Keir Fraser]

We stash the user-space CR3 value there (PV x86_64 guests have two CR3s). Of
course you should need only the guest kernel CR3.

 K.

On 12/08/2011 03:03, "Mukesh Rathor" <mukesh.rathor@oracle.com> wrote:

> Hi,
> 
> Just wondering under what circumstances will cr1 be set in this
> function?
> 
> int arch_set_info_guest(
>     struct vcpu *v, vcpu_guest_context_u c)
> {
> .....
> 
> #ifdef __x86_64__
>         if ( c.nat->ctrlreg[1] )           <------
>         {
> .....
> 
> 
> 
> thanks,
> Mukesh
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: arch_set_info_guest() and cr1

[Mukesh Rathor]

Ah I see it, during save/restore, it is used. 
Well, I'm trying to keep the option of using PV paging with hybrid, so 
I may need to honor that. But that's phase 2.

thanks,
Mukesh

On Fri, 12 Aug 2011 07:16:39 +0100
Keir Fraser <keir.xen@gmail.com> wrote:

> We stash the user-space CR3 value there (PV x86_64 guests have two
> CR3s). Of course you should need only the guest kernel CR3.
> 
>  K.
> 
> On 12/08/2011 03:03, "Mukesh Rathor" <mukesh.rathor@oracle.com> wrote:
> 
> > Hi,
> > 
> > Just wondering under what circumstances will cr1 be set in this
> > function?
> > 
> > int arch_set_info_guest(
> >     struct vcpu *v, vcpu_guest_context_u c)
> > {
> > .....
> > 
> > #ifdef __x86_64__
> >         if ( c.nat->ctrlreg[1] )           <------
> >         {
> > .....
> > 
> > 
> > 
> > thanks,
> > Mukesh
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> 

Re: arch_set_info_guest() and cr1

[Jeremy Fitzhardinge]

On 08/12/2011 03:01 PM, Mukesh Rathor wrote:
> Ah I see it, during save/restore, it is used. 
> Well, I'm trying to keep the option of using PV paging with hybrid, so 
> I may need to honor that. But that's phase 2.

Though it would be nice to re-enable the use of PV writable pagetables
to get access to HAP, and we could do without that.

Does Xen require that the user pagetable be a proper subset of the
kernel pagetable?  If we can assume that and get proper ring protections
in the HVM container, then we can simply ignore the user pagetable (and
would have to if we want to get good syscall performance).

    J

Re: arch_set_info_guest() and cr1

[Jan Beulich]

>>> On 13.08.11 at 04:17, Jeremy Fitzhardinge <jeremy@goop.org> wrote:
> On 08/12/2011 03:01 PM, Mukesh Rathor wrote:
>> Ah I see it, during save/restore, it is used. 
>> Well, I'm trying to keep the option of using PV paging with hybrid, so 
>> I may need to honor that. But that's phase 2.
> 
> Though it would be nice to re-enable the use of PV writable pagetables
> to get access to HAP, and we could do without that.
> 
> Does Xen require that the user pagetable be a proper subset of the
> kernel pagetable?  If we can assume that and get proper ring protections
> in the HVM container, then we can simply ignore the user pagetable (and
> would have to if we want to get good syscall performance).

No, Xen doesn't enforce anything on the user page table that it
wouldn't on a kernel one. In fact, it can't even correlate the
respective (kernel,user) pairs.

Jan

Re: arch_set_info_guest() and cr1

[Ian Campbell]

(old mail, I know)

On Sat, 2011-08-13 at 03:17 +0100, Jeremy Fitzhardinge wrote:
> On 08/12/2011 03:01 PM, Mukesh Rathor wrote:
> > Ah I see it, during save/restore, it is used. 
> > Well, I'm trying to keep the option of using PV paging with hybrid, so 
> > I may need to honor that. But that's phase 2.
> 
> Though it would be nice to re-enable the use of PV writable pagetables
> to get access to HAP, and we could do without that.
> 
> Does Xen require that the user pagetable be a proper subset of the
> kernel pagetable?  If we can assume that and get proper ring protections
> in the HVM container, then we can simply ignore the user pagetable (and
> would have to if we want to get good syscall performance).

IIRC back when I did the (now completely defunct) supervisor mode kernel
stuff that was exactly the assumption which was made and it certainly
worked in practice (although "require" might be a strong term).

Ian.

Re: arch_set_info_guest() and cr1

[Jeremy Fitzhardinge]

On 09/22/2011 12:32 AM, Ian Campbell wrote:
> (old mail, I know)
>
> On Sat, 2011-08-13 at 03:17 +0100, Jeremy Fitzhardinge wrote:
>> On 08/12/2011 03:01 PM, Mukesh Rathor wrote:
>>> Ah I see it, during save/restore, it is used. 
>>> Well, I'm trying to keep the option of using PV paging with hybrid, so 
>>> I may need to honor that. But that's phase 2.
>> Though it would be nice to re-enable the use of PV writable pagetables
>> to get access to HAP, and we could do without that.
>>
>> Does Xen require that the user pagetable be a proper subset of the
>> kernel pagetable?  If we can assume that and get proper ring protections
>> in the HVM container, then we can simply ignore the user pagetable (and
>> would have to if we want to get good syscall performance).
> IIRC back when I did the (now completely defunct) supervisor mode kernel
> stuff that was exactly the assumption which was made and it certainly
> worked in practice (although "require" might be a strong term).

Well, I guess we could add ELF notes to allow a guest to say "I really
need separate non-intersecting user/kernel pagetables" if they really
need it.  Or repurpose auto_translated_physmap to also mean "no separate
user/kernel pagetables required".  Has that ever been supported for
64-bit PV guests?  My memory of the chronology is that it died as a
feature at about the time that 64-bit support went in.

    J

Re: arch_set_info_guest() and cr1

[Ian Campbell]

On Fri, 2011-09-23 at 00:31 +0100, Jeremy Fitzhardinge wrote:
> On 09/22/2011 12:32 AM, Ian Campbell wrote:
> > (old mail, I know)
> >
> > On Sat, 2011-08-13 at 03:17 +0100, Jeremy Fitzhardinge wrote:
> >> On 08/12/2011 03:01 PM, Mukesh Rathor wrote:
> >>> Ah I see it, during save/restore, it is used. 
> >>> Well, I'm trying to keep the option of using PV paging with hybrid, so 
> >>> I may need to honor that. But that's phase 2.
> >> Though it would be nice to re-enable the use of PV writable pagetables
> >> to get access to HAP, and we could do without that.
> >>
> >> Does Xen require that the user pagetable be a proper subset of the
> >> kernel pagetable?  If we can assume that and get proper ring protections
> >> in the HVM container, then we can simply ignore the user pagetable (and
> >> would have to if we want to get good syscall performance).
> > IIRC back when I did the (now completely defunct) supervisor mode kernel
> > stuff that was exactly the assumption which was made and it certainly
> > worked in practice (although "require" might be a strong term).
> 
> Well, I guess we could add ELF notes to allow a guest to say "I really
> need separate non-intersecting user/kernel pagetables" if they really
> need it.  Or repurpose auto_translated_physmap to also mean "no separate
> user/kernel pagetables required".

IIRC that's effectively one of the things which auto_translated_physmap
implies.

> Has that ever been supported for 64-bit PV guests?

In the classic patches, yes, but not in the pvops ones AFAIK.

>   My memory of the chronology is that it died as a
> feature at about the time that 64-bit support went in.
> 
>     J