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