| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] do_set_gdt
> I'd find it disturbing if we passed in 8 and Xen would then change entries
> 9-LAST_RESERVED_ENTRY[*]. Right now Xen only changes entries within the
> memory you offered it for storing the GDT, so you are implicitly aware that
> memory for at least LAST_RESERVED_ENTRY entries will be used for the GDT
> table...
As far as I can tell you're doing this anyway. You're not even passing
an address, you're passing an array page frames. So how is it that we
don't know what is being used? And you, in your code, are passing
LAST_RESERVED_ENTRY + 1 - but you are in fact using far fewer entries
than that. You're supposedly communicating to the hypervisor that that
is how much space it can use, but if you're passing it a page frame and
the GDT has to be page-aligned what else would you be doing?
In principle one could put other data on the same page right after the
last available entry, but that would be kind of bizarre.
>
> [*] Xen would have to zero/invalidate entries 9-FIRST_RESERVED_ENTRY
>
> > A better approach would
> > be to insist that entries 256-296 are set to 0 in the case where the
> > user sets nentries >= FIRST_RESERVED_ENTRY.
>
> What would that accomplish? Besides that it wouldn't work: we copy Xen's
> entries into the table which would make the table fail the 0-check the next
> time you call set_gdt...
Good point. However, let me write a short piece of "documentation" on
set_gdt, to give you an idea of how crufty I think it is as an
interface.
HYPERVISOR_set_gdt(unsigned long *frame_list, unsigned int entries)
frame_list: an array of up to 16 page frames on which the gdt resides
entries: NOT the number of entries used in the gdt, but rather the
number of gdt sized elements on the page that the hypervisor can use,
this number must be greater than the maximum number of reserved entries
regardless of the actual number of gdt entries you use or the call will
fail with EINVAL, do not use FIRST_RESERVED_GDT_ENTRY -
LAST_RESERVED_GDT_ENTRY as they are blindly overwritten by the
hypervisor. You are, however, free to use any entry prior to
FIRST_RESERVED_GDT_ENTRY and after LAST_RESERVED_GDT_ENTRY.
=========================================================================
I think segments are intrinsically crufty, so a crufty interface is
unavoidable. I'm merely pointing out that this particular interface
requires the guest to know more about the internals of Xen than
standard system/hyper call. To claim otherwise would be misleading.
-Kip
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
|
|
|
| |
|
Home