| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] do_set_gdt
Please keep in mind that I didn't design this interface and can only guess
what the design decisions were. I've tried to explain to you how to use it
and why changing it the way you suggest is impractical or doesn't work...
> 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?
I think you look at this backwards: if Xen makes the guest pass in a table
which has at least LAST_RESERVED_ENTRY then Xen can be sure that the guest
knows that the memory where the reserved entries are located is part of the
GDT table. If Xen accepts tables which have less than LAST_RESERVED_ENTRY
entries, then Xen has to:
- modify entries outside the table[*] passed in by the guest
or:
- copy the valid entries to a Xen private table
Both seem undesirable for different reasons... Well, the 2nd would maybe
cleanup the interface but require special handling in set_gdt and
update_descriptor. The 1st would IMHO make the interface unpredictable,
please try to "document" it and see for yourself ;-)
[*] entries with an entry number higher than the entries parameter passed to
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.
You realize that in your description of the entries parameter you repeat two
things twice and that that will make the interface look crufty because the
"documentation" is ;-) See below for a much shorter description of the
restrictions imposed on the entries parameter.
> 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.
The guest only needs to know that "a gdt table must have at least
LAST_RESERVED_ENTRY+1 many entries and [that] entries FIRST_RESERVED_ENTRY -
LAST_RESERVED_ENTRY are reserved". I don't think that's crufty once you
accept that the guest has to provide a table large enough to also hold the
Xen reserved entries.
It is my understanding that imposing some restrictions on the guest to
simplify the Xen implementation or get performance advantages was/is one of
the basic Xen design decisions!?
christian
-------------------------------------------------------
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