do_set_gdt

do_set_gdt

[Kip Macy]

Given that you that the first 256 GDT entries aren't reserved and you
explicitly state why, shouldn't the following check:

    if ( (entries <= LAST_RESERVED_GDT_ENTRY) || (entries > 8192) )
        return -EINVAL;

be:

    if ( (entries > FIRST_RESERVED_GDT_ENTRY &&
          entries <= LAST_RESERVED_GDT_ENTRY) || (entries > 8192) )
        return -EINVAL;




Thanks.

			-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

Re: do_set_gdt

[Christian Limpach]

> Given that you that the first 256 GDT entries aren't reserved and you
> explicitly state why, shouldn't the following check:
>
>     if ( (entries <= LAST_RESERVED_GDT_ENTRY) || (entries > 8192) )
>         return -EINVAL;

I think this is so that Xen can copy its GDT entries into the table which
you pass to it.  If you look in set_gdt() you'll see that Xen copies its
entries into the new GDT table.  This implies that all entries upto
FIRST_RESERVED_GDT_ENTRY have to be valid since at least
LAST_RESERVED_GDT_ENTRY many entries will have to be activated.  If you
wanted to allow a guest to request less than LAST_RESERVED_GDT_ENTRY
entries, Xen would have to (at least) copy the entries to a private GDT
table and use that.  This would still use at least 1 page so it's preferable
to just make the guest provide enough space to fit LAST_RESERVED_GDT_ENTRY
many entries and avoid a special case.

You'll also want to make sure that you don't put other stuff in the last
page which hold the GDT table and align the GDT table to a page boundary:
lgdt allows the gdt to be anywhere while for Xen you have to put it at the
beginning of a page, can't really use the rest of the last page for much
else and have to keep the pages around.

    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

Re: do_set_gdt

[Keir Fraser]

> > Given that you that the first 256 GDT entries aren't reserved and you
> > explicitly state why, shouldn't the following check:
> >
> >     if ( (entries <= LAST_RESERVED_GDT_ENTRY) || (entries > 8192) )
> >         return -EINVAL;
> 
> I think this is so that Xen can copy its GDT entries into the table which
> you pass to it.  If you look in set_gdt() you'll see that Xen copies its
> entries into the new GDT table.  This implies that all entries upto
> FIRST_RESERVED_GDT_ENTRY have to be valid since at least
> LAST_RESERVED_GDT_ENTRY many entries will have to be activated.  If you
> wanted to allow a guest to request less than LAST_RESERVED_GDT_ENTRY
> entries, Xen would have to (at least) copy the entries to a private GDT
> table and use that.  This would still use at least 1 page so it's preferable
> to just make the guest provide enough space to fit LAST_RESERVED_GDT_ENTRY
> many entries and avoid a special case.
> 
> You'll also want to make sure that you don't put other stuff in the last
> page which hold the GDT table and align the GDT table to a page boundary:
> lgdt allows the gdt to be anywhere while for Xen you have to put it at the
> beginning of a page, can't really use the rest of the last page for much
> else and have to keep the pages around.

Yes, this is all correct. On first glance I thought this was a bug (I
thought the code was deciding whether a particular GDT entry could be
updated by the guest).

 -- Keir


-------------------------------------------------------
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

Re: do_set_gdt

[Kip Macy]

> > You'll also want to make sure that you don't put other stuff in the last
> > page which hold the GDT table and align the GDT table to a page boundary:
> > lgdt allows the gdt to be anywhere while for Xen you have to put it at the
> > beginning of a page, can't really use the rest of the last page for much
> > else and have to keep the pages around.
>
> Yes, this is all correct. On first glance I thought this was a bug (I
> thought the code was deciding whether a particular GDT entry could be
> updated by the guest).
>


Yes, but you have to pass in at least a page which == 512 entries. So if
I'm only using the first 8 entries, there is no reason Xen can't use
256-296. Passing in LAST_RESERVED_ENTRY + 1, seems a little contrived
when it is only the first 8 that I care about. 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.


			-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

Re: do_set_gdt

[Christian Limpach]

> Yes, but you have to pass in at least a page which == 512 entries. So if
> I'm only using the first 8 entries, there is no reason Xen can't use
> 256-296. Passing in LAST_RESERVED_ENTRY + 1, seems a little contrived
> when it is only the first 8 that I care about.

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...

[*] 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...

    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

Re: do_set_gdt

[Kip Macy]

> 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

Re: do_set_gdt

[Christian Limpach]

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

Re: do_set_gdt

[Keir Fraser]

> > > You'll also want to make sure that you don't put other stuff in the last
> > > page which hold the GDT table and align the GDT table to a page boundary:
> > > lgdt allows the gdt to be anywhere while for Xen you have to put it at the
> > > beginning of a page, can't really use the rest of the last page for much
> > > else and have to keep the pages around.
> >
> > Yes, this is all correct. On first glance I thought this was a bug (I
> > thought the code was deciding whether a particular GDT entry could be
> > updated by the guest).
> >
> 
> 
> Yes, but you have to pass in at least a page which == 512 entries. So if
> I'm only using the first 8 entries, there is no reason Xen can't use
> 256-296. Passing in LAST_RESERVED_ENTRY + 1, seems a little contrived
> when it is only the first 8 that I care about. 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.

Part of the semantics of GDT virtualisation is that the guest knows
which entries will be taken by Xen, and must offer a large enough
table to contain Xen's entries. 

Given that you pretty much have to burn a page on the GDT (since we
use page-level protection to prevent direct guest updates of the GDT),
zeroing out a whole page and passing in ents==512 doesn't seem a great
hardship. 

One of the reasons for not going down the full virtualisation route is
that it allows us to adjust the VM interface for Xen's benefit -- some
of these changes may seem odd or contrived if you're not aware how Xen
benefits. But I'm fairly happy that none of the changes should be too
onerous for the guest-OS programmer to abide by.

 -- Keir


-------------------------------------------------------
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

Re: do_set_gdt

[Keir Fraser]

> 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.

frame_list: An array of up to 16 page frames within which the GDT
resides. Any frame registered as a GDT frame may only be mapped
read-only within the guest's address space (e.g., no writeable
mappings, no use as a page-table page, and so on).

entries: The number of descriptor-entry slots in the GDT. Note that
the table must be large enough to contain Xen's reserved entries; thus
we must have 'entries > LAST_RESERVED_GDT_ENTRY'. Note also that,
after registering the GDT, slots FIRST_RESERVED_GDT_ENTRY to
LAST_RESERVED_GDT_ENTRY are no longer usable by the guest and may be
overwritten by Xen. 

> =========================================================================
> 
> 
> 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.

It's the same with the linear address space: the guest is aware that
the top 64MB of the address space is unavailable to it. Similarly
here, the guest will be aware that a number of GDT entries are
inaccessible outside Xen.

This inelegance is part of the price we pay for performance on x86.

 -- Keir


-------------------------------------------------------
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

Re: do_set_gdt

[Kip Macy]

That is a nice complete definition. Why don't you paste it into
interface.tex?

				-Kip

>
> frame_list: An array of up to 16 page frames within which the GDT
> resides. Any frame registered as a GDT frame may only be mapped
> read-only within the guest's address space (e.g., no writeable
> mappings, no use as a page-table page, and so on).
>
> entries: The number of descriptor-entry slots in the GDT. Note that
> the table must be large enough to contain Xen's reserved entries; thus
> we must have 'entries > LAST_RESERVED_GDT_ENTRY'. Note also that,
> after registering the GDT, slots FIRST_RESERVED_GDT_ENTRY to
> LAST_RESERVED_GDT_ENTRY are no longer usable by the guest and may be
> overwritten by Xen.


-------------------------------------------------------
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