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

[Simon Kuenzer <simon.kuenzer@xxxxxxxxx>]

Hey Marek,

On 12.03.19, 17:03, "Minios-devel on behalf of Marek Marczykowski-Górecki" 
<minios-devel-bounces@xxxxxxxxxxxxxxxxxxxx on behalf of 
marmarek@xxxxxxxxxxxxxxxxxxxxxx> wrote:

    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.

This sounds great! We are happy to receive patches. ;-)
    
    > 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.

Which layers do you mean? Unikraft? Or the whole Unikernel that you build and 
that includes MirageOS?

    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?
    
Hum... good question. I would actually check how much differences you see in 
the PV and PVH code, as well as these structs. How many fields are similar and 
how much of the existing code could be re-used? Since I assume building 
different binaries for PVH and PV, you are able to do the build with a 
different set of sources. For instance, entry64.S for PVH can be a complete 
different one than the one for PV. Some other files will probably have minor 
cases. I would use an approach that looks minimal while keeping readability. 
Maybe you provide alternative struct definitions depending on the configuration?

Btw, CONFIG_PARAVIRT and CONFIG_HVMLITE are left-overs from our Mini-OS port. I 
think it makes sense to clean this up and replace the definitions.

    > 
    > 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?

Thanks,

Simon
    

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