* Zachary Amsden (zach@xxxxxxxxxx) wrote: > I've integrated patches from Chris and Martin into the -mm tree. I'll > be sending out the patches shortly after testing with my (still in > progress!) Linux LDT test suite. Thanks Zach. Hey, don't forget to submit those tests to LTP ;-) > First interface quirk came up. It looks like Xen wants to return errors > from hypercalls: Yes, why wouldn't it? ;-) > +static inline int install_ldt_entry (__u32 *lp, __u32 entry_1, __u32 > entry_2) > +{ > + unsigned long mach_lp = arbitrary_virt_to_machine(lp); > + > + return HYPERVISOR_update_descriptor(mach_lp, entry_1, entry_2); > +} > > While this is fine here, this could be problematic in terms of forcing > error checking in lots of situations where there used to be no error > checking in regular Linux - i.e. GDT updates which fail really are fatal > to the guest, and we don't want to pepper the boot-up code with error > checking where there used to be none. In practice there's not tons of extra error checking as a result of Xen, so it's not a great concern to me at this point. > Also, there is the problem of mapping error codes from the hypervisor > onto error codes for the guest - which could be quite different in > different guests. Well, Xen typically returns quite POSIX looking error codes. Since this is a Linux port, it's reasonable to expect this. > One general approach to this is to consider errors as faults to be > delivered to the guest, since in many cases, errors result from > protection violation attempts. This has the benefit of not presenting > the two problems I just mentioned. Hmm, actually sounds like that may be just moving the problem. > For now, the most expedient approach appears to be to preserve the error > code values, but the mapping issue seems to be a large one that needs > long term resolution. Agreed. We'll get way too bogged down otherwise. thanks, -chris