Re: [Minios-devel] [UNIKRAFT] Xen PVH platform

[Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>]

On Tue, Mar 12, 2019 at 08:52:11AM +0000, Simon Kuenzer wrote:
> Hey Marek,
> 
> yes, you are right. We are supporting only PV on x86 for now. The pieces of 
> PVH/HVM that we have left are left-overs from taking some of the code from 
> Mini-OS. In general, we would be happy to have also PVH support.
> So far, our focus was on increasing functionality with libraries and drivers 
> in order to make the project more useful for most people. However, if you 
> have time, we are happy to receive patches to enable PVH ;-) . Let us know if 
> you are interested.

Yes! Actually, I already have something that boots on PVH. It's quite
specific, as it's plugged into MirageOS, which use unikraft as just one
of its packages right now. It's very much work in progress state.

> The most natural way for Unikraft would be to build two Xen binaries: One for 
> PV and another one for PVH. The idea is that you get the most optimized image 
> for your execution environment. This way you would avoid impacts because of 
> the two implementations. You also would not require a detection at runtime.

I see, that makes sense. On the other hand, passing CONFIG_PARAVIRT
through multiple layers may be problematic, so I think it may be worth
having some universal binary. But I'll leave it for some undefined
future.

Anyway, even without having PV+PVH binary, I have one important question:
how start_info_t and HYPERVISOR_start_info should looks like? Right now
I've made it an union (with "pv" under CONFIG_PARAVIRT and "hvm" under
CONFIG_XEN_HVMLITE). This require all the places using this symbol to be
changed. Some alternative would be to have a separate symbol like
HYPERVISOR_start_info_hvm for the other start info structure and keep
HYPERVISOR_start_info unchanged (or under CONFIG_PARAVIRT). While
changing everything using HYPERVISOR_start_info is some pain, IMO it's
better than forgetting something and erroneously using (uninitialized)
PV version on PVH...

What do you prefer?

> 
> Thanks,
> 
> Simon
> 
> On 12.03.19, 02:27, "Minios-devel on behalf of Marek Marczykowski-Górecki" 
> <minios-devel-bounces@xxxxxxxxxxxxxxxxxxxx on behalf of 
> marmarek@xxxxxxxxxxxxxxxxxxxxxx> wrote:
> 
>     Hi,
>     
>     In Unikraft, some of the Xen platform code is under CONFIG_PARAVIRT, as an
>     alternative to (incomplete, broken) PVH/HVM support. Would it make sense
>     to support a build for both PV and PVH at the same time? Technically it
>     would be possible, since those use different entry points and also
>     start_info structure has a different magic. But on the other hand,
>     supporting such configuration would mean slightly bigger binary. And
>     possibly slight slower (not really sure about that yet).
>     It looks like the x86/entry64.S and x86/mm.c are the most tricky parts,
>     but it shouldn't be that hard to support runtime PV/PVH detection.
>     
>     -- 
>     Best Regards,
>     Marek Marczykowski-Górecki
>     Invisible Things Lab
>     A: Because it messes up the order in which people normally read text.
>     Q: Why is top-posting such a bad thing?
>     
> 

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

Attachment: signature.asc
Description: PGP signature

_______________________________________________
Minios-devel mailing list
Minios-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/minios-devel