* 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
