Jeremy Fitzhardinge wrote: > Zachary Amsden wrote: >> This interface doesn't work for anything other than Xen. > > It works OK for native. It's a very simple rolling together of two > operations which always happen together anyway. > >> It is impossible to implement it without specific knowledge of kernel >> internals, since it doesn't provide the GDT selector for the LDT. > > Neither does the previous interface. load_ldt_desc needs to have the > specific LDT entry hardcoded into it. > >> Now everything that looks like real hardware needs to move the >> knowledge of the LDT structure into paravirt-ops, > > Do you mean the GDT structure? Yes. > >> and it has no clear calling convention, so you've now got to reason >> about SMP preemption correctness inside the paravirt-op, instead of >> at the higher level where it should be done. > > The previous interface already required that preempt be disabled > around those functions. In the previous interface, set_ldt_desc takes > a cpu number, but it is required to equal the current cpu; > load_ldt_desc always operates on the current CPU. It therefore > requires that those two ops be paired with preempt disabled. The new > interface is simpler, but still requires preempt disabled around it. The paravirt-op just got a lot harder to implement, so there is a cost to the simpler interface. > > In general, the set_ldt interface is cleaner for the base kernel, and > much cleaner for Xen, while being trivial to implement for native > hardware or something which looks like it. I just think it's really weird to have LDT not described in the GDT, but LDT is weird anyways. Zach
