Re: [Xen-devel] [PATCH 00/22] Vixen: A PV-in-HVM shim

[Anthony Liguori <anthony@xxxxxxxxxxxxx>]

On Mon, Jan 8, 2018 at 8:39 AM, Ian Jackson <ian.jackson@xxxxxxxxxxxxx> wrote:
> Wei Liu writes ("Re: [Xen-devel] [PATCH 00/22] Vixen: A PV-in-HVM shim"):
>> On Mon, Jan 08, 2018 at 08:02:07AM -0800, Anthony Liguori wrote:
>> > OTOH, the HVM version of the series requires no tools changes and
>> > works on Xen versions going back to 3.4 (at least).
>
> That depends, I think, on how you are selecting the guest kernel.
>
> libxl (at least, older libxls) don't support direct kernel boot in HVM
> mode.  So if you were using kernel= in your config file that won't
> work without libxl changes which are really hard to do and also
> maintain ABI compatibility.
>
> Likewise bootloader= (eg bootloader="pygrub").

I think pvgrub is a pretty reasonable alternative to pygrub for most people.

What we specifically did was take the kernel/etc arguments and used them
to generate an ISO with isolinux with the shim embedded in the ISO.

While it does work to set boot="d" and add the ISO to the disk=[] option, we
preferred to use a wrapper around qemu to directly add a -cdrom option so
that the ISO would not be exposed as a blkback device.

It's not effort free, but it's also a change that I would think most
administrators
can make.

Regards,

Anthony Liguori

>> > If it was entirely my call, I would work on merging HVM shim
>> > first, get a 4.10 stable release cut with it, and then focus on
>> > getting PVH shim in place for the 4.11 release.  I think this is
>> > the right balance of addressing the short term needs while also
>> > having the best long term solution.
>>
>> Not my call either. I will wait for security team member and stable tree
>> maintainers to weight in.
>
> Since shim users are going to be using unstable/4.10 as the shim
> anyway, I think a good priority is indeed getting a good solution for
> 4.10.
>
> Personally I am not doing any Xen review work or commit work right now
> that is not related to Meltdown/Spectre.  Everything else has to wait.
>
> Furthermore I think we should avoid committing anything to
> xen-unstable that will complicate our efforts on the shim.
>
> Ian.

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