Re: [PATCH] abstract out bits of ldt.c

[Zachary Amsden <zach@vmware.com>]

Chris Wright wrote:

> * Andrew Morton (akpm@osdl.org) wrote:
>  
>
> > "Martin J. Bligh" <mbligh@mbligh.org> wrote:
> >    
> >
> > > xen_make_pages_readonly / xen_make_pages_writable ?
> > >      
> > Well we don't want to assume "xen" at this stage.  We're faced with a
> > choice at present: to make the linux->hypervisor interface be some
> > xen-specific and xen-controlled thing, or to make it a more formal and
> > controlled kernel interface which talks to a generic hypervisor rather than
> > assuming it's Xen down there.
> >    
>
> No, definietly not.  Xen is not appropriate global namespace.  Also,
> it's not about pages at this point, it's about ldt handling.
>  

I like these patches.  They greatly simplify a lot of the work I had 
anticipated was necessary for Xen.  I.e. - LDT / GDT accessors are not 
needed for most updates, only updates to live descriptor table entries 
(for GDT this is TLS, LDT, TSS?, entries and there is 1 LDT update case).

BTW, Martin, did you see my ldt-accessors patch?  It also encapsulates 
that 1 LDT update case you show here, just named differently.

Yours:

+static inline int install_ldt_entry (__u32 *lp, __u32 entry_1, __u32 entry_2)
+{
+	*lp     = entry_1;
+	*(lp+1) = entry_2;
+	return 0;
+}

Mine:

+static inline void write_ldt_entry(void *ldt, int entry, __u32 entry_a, __u32 entry_b)
+{
+	__u32 *lp = (__u32 *)((char *)ldt + entry*8);
+	*lp = entry_a;
+	*(lp+1) = entry_b;
+}


They both work, but mine does not assume page aligned LDTs (necessary to 
extract entry number).  This is moot right now because LDTs are page 
aligned anyway in Linux.  I actually don't care which one we use, but it 
might be even nicer if we got one with C type checking (struct 
desc_struct for ldt).

Does Xen assume page aligned descriptor tables?  I assume from this 
patch and snippets I have gathered from others, that is a yes, and other 
things here imply that DT pages are not shadowed.  If so, Xen itself 
must have live segments in the GDT pages, so how do you allocate space 
for the per-CPU GDT pages on SMP?


> > As long as it doesn't hamper performance or general code sanity, I think it
> > would be better to make this a well-defined and controlled Linux interface.
> > Some of the code to do that is starting to accumulate in -mm.  Everyone
> > needs to sit down, take a look at the patches and the proposal and work out
> > if this is the way to proceed.
> >    
>
> We're doing that, but it's splintered and coming in from different angles.
> It'd be better to get the story straight then submit patches, IMO.
>  

I think introducing mach-xen headers is a bit premature though - lets 
get the interface nailed down first so that the hypervisor developers 
have time to settle the include/asm-i386/mach-xxx files without dealing 
unneeded churn onto the maintainers.

Zach
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/