On Fri, Sep 12, 2008 at 8:19 PM, Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx> wrote:
> There are three different mechanisms that different OSes use to update
> their pagetables: 1:1 direct map regions, linear recursive map regions,
> and kmap-style regions. It would be possible to come up with logic to
> automatically detect and identify these regions, but its non trivial.
> The test might be quite expensive, so you'd want to run it for a while
> and then make a decision on the type and location. If you started
> getting too many 'misses' you'd want to re-evaluate the decision as the
> guest kernel may have changed mode of operation (perhaps someone's done
> a kexec, or the boot time behaviour was different from runtime).
Even automatically detecting this is still fairly OS-specific: it
relies on the fact that Linux normally does direct-mapping, and
Windows normally does linear recursive maps. If FooOS came out and
used the formula (LIMIT-gpfn) instead of (BASE+gpfn), for instance,
we'd be back to square one.
If it were less expensive (detection path on every set_l1e()
basically), or the exact addresses tended to move around a lot, that
might be a good option. But as Ian said, it would add a significant
amount of code to a common path, and the addresses really don't change
all that often.
Thanks for bringing this up though, Dan -- It's good to revisit these
kinds of decisions every so often to make sure that they're still
valid.
-George
>
> Anyhow, it's certainly possible to do this automatically, but given that
> the mechanism and location used by kernels typically doesn't change the
> hard-coded heuristic has served us pretty well to date. Feel free to
> send patches :-)
>
> What would also be interesting would be a shadow pagetable mode that
> stored 'back pointers' to enable one to easily find all the shadow PTEs
> that point to a page. This would be useful for some of the more fancy
> shadow pagetable modes that are interesting from a research POV, as well
> as coping with guests that use some other mechanism for updating PTEs
> (if such guests exist).
>
> Ian
>
>
>
>
>
>
>
>
>> > -----Original Message-----
>> > From: George Dunlap [mailto:George.Dunlap@xxxxxxxxxxxxx]
>> > Sent: Friday, September 12, 2008 9:39 AM
>> > To: xen-devel mailing list
>> > Subject: [Xen-devel] [PATCH] Add new location of Linux
>> > direct-map to the
>> > places to look for writable mappings
>> >
>> >
>> > Add new location of Linux direct-map to the places to look for
>> > writable mappings.
>> >
>> > Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx>
>> >
>> > diff -r dbac9ee4d761 xen/arch/x86/mm/shadow/common.c
>> > --- a/xen/arch/x86/mm/shadow/common.c Mon Sep 08 16:02:13 2008
>> +0100
>> > +++ b/xen/arch/x86/mm/shadow/common.c Fri Sep 12 16:42:32 2008
>> +0100
>> > @@ -2385,9 +2385,11 @@ int sh_remove_write_access(struct vcpu *
>> > + ((fault_addr & VADDR_MASK) >>
>> > 27), 3); break;
>> > }
>> >
>> > - /* 64bit Linux direct map at 0xffff810000000000;
>> > older kernels
>> > - * had it at 0x0000010000000000UL */
>> > + /* 64bit Linux direct map at 0xffff880000000000;
>> > older kernels
>> > + * had it at 0xffff880000000000, and older
>> > kernels yet had it
>> > + * at 0x0000010000000000UL */
>> > gfn = mfn_to_gfn(v->domain, gmfn);
>> > + GUESS(0xffff880000000000UL + (gfn << PAGE_SHIFT), 4);
>> > GUESS(0xffff810000000000UL + (gfn << PAGE_SHIFT), 4);
>> > GUESS(0x0000010000000000UL + (gfn << PAGE_SHIFT), 4);
>> >
>> > _______________________________________________
>> > Xen-devel mailing list
>> > Xen-devel@xxxxxxxxxxxxxxxxxxx
>> > http://lists.xensource.com/xen-devel
>> >
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/xen-devel
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home