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

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

 



Chris Wright wrote:

* Andrew Morton ([email protected]) wrote:
"Martin J. Bligh" <[email protected]> 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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]
  Powered by Linux