Re: [Xen-devel] do_set_gdt

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

> > 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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel