[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] Add new location of Linux direct-map to theplaces to look for writable mappings


  • To: "Ian Pratt" <Ian.Pratt@xxxxxxxxxxxxx>
  • From: "George Dunlap" <dunlapg@xxxxxxxxx>
  • Date: Mon, 15 Sep 2008 11:56:14 +0100
  • Cc: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>, xen-devel mailing list <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Mon, 15 Sep 2008 03:56:40 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=S1nfED669Sk0jSQ1USr0YdDiXe/PlvqFHryXiUEH58lDAfaWNt4VprHl+/MtbR6t3X Ez8XDc5OFOy0k4LDtJsLDnx6ItIem45F9rDCpml9l6MK7I2FDY0wTF3uzg8Aj1gq/sOA ljIuniLEHpzTssRhPSoDNcDaCMQgxNh4IhBh4=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.