> I haven't even looked at this code so sorry for my
> possibly naive comment, but isn't this just asking for
> trouble to hardcode constants that apply to specific
> OS's? Isn't there a way to "sense" that this address is
> used a lot and add it to a dynamic list that can be
> checked? Else sooner or later some user is going to say
> "I tried Xen on xxx OS and performance sucked and it
> was fine on (unnamed virtualization platform)". But that
> user might not be as diligent about reporting to
> xen-devel as Todd was.
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).
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
|
Home