> >> Considering that the EFI support is just for Dom0, and Dom0 (at > >> the time) had to be PV anyway, it was the more natural solution to > >> expose the interface via hypercalls, the more that this allows better > >> control over what is and primarily what is not being exposed to > >> Dom0. With the wrapper approach we'd be back to the same > >> problem (discussed elsewhere) of which EFI version to surface: The > >> host one would impose potentially missing extensions, while the > >> most recent hypervisor known one might imply hiding valuable > >> information from Dom0. Plus there are incompatible changes like > >> the altered meaning of EFI_MEMORY_WP in 2.5. > > > > I'm not sure I follow how hypercalls solve any impedance mismatch here; > > you're still expecting Dom0 to call up to Xen in order to perform calls, > > and all I suggested was a different location for those hypercalls. > > > > If Xen is happy to make such calls blindly, why does it matter if the > > hypercall was in the kernel binary or an external shim? > > Because there could be new entries in SystemTable->RuntimeServices > (expected and blindly but validly called by the kernel). Even worse > (because likely harder to deal with) would be new fields in other > structures. Any of these could cause Xen to blow up, while Xen could always provide a known-safe (but potentially sub-optimal) view to the kernel by default. > > Incompatible changes are a spec problem regardless of how this is > > handled. > > Not necessarily - we don't expose the memory map (we'd have to > if we were to mimic EFI for Dom0), and hence the mentioned issue > doesn't exist in our model. We have to expose _some_ memory map, so I don't follow this point. Mark. -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
