[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Radical proposal: ship not-fully-tidied shim as 4.10.1



On Tue, Jan 9, 2018 at 8:52 AM, Stefano Stabellini
<sstabellini@xxxxxxxxxx> wrote:
> On Tue, 9 Jan 2018, George Dunlap wrote:
>> On Mon, Jan 8, 2018 at 9:01 PM, Rich Persaud <persaur@xxxxxxxxx> wrote:
>> > On a similarly pragmatic note: would a variation of Anthony's vixen patch 
>> > series be suitable for pre-PVH Xen 4.6 - 4.9?  These versions are 
>> > currently documented as security-supported (Oct 2018 - July 2020).
>>
>> Hmm, Ian's mail seems to be focusing on the idea of checking in a
>> non-polished series to 4.10, rather than exctly what the content of
>> that series would be.
>>
>> In the IRL conversation that preceeded this mail, the new short-term
>> target we discussed was:
>> 1. A 4.10-based shim that could boot either under HVM or PVH
>> 2. A script that would take an existing PV config, and spit out a) a
>> bootable ISO with the shim & whatever was needed, and b) a new config
>> that would boot the same VM, but in HVM mode with the shim
>>
>> The script + a 4.10 shim binary *should* allow most PV guests to boot
>> without any changes whatsoever for most older versions of Xen.
>>
>> There are a number of people for whom this won't work; I think we also
>> need to provide a way to transparently change PV guests into PVshim
>> guests.  But that will necessarily involve significant toolstack
>> functionality, at which point you might as well backport PVH as well.
>
> Yes, there will be a number of people that won't be covered by this fix,
> including those that can't use HVM/PVH mode because VT-x isn't available
> at all in their environment. That is the only reason to run PV today.
> Providing a way to transparently change PV guests into PVshim guests
> won't cover any of these cases. A more complete workaround to SP3 is
> along the lines of https://marc.info/?l=xen-devel&m=151509740625690.
>
> That said, I realize that we are only trying to do the best we can in a
> very difficult situation, with very little time in our hands. I agree
> with Ian that we should commit something unpolished and only partially
> reviewed soon, even though it doesn't cover a good chunk of the userbase
> for one reason or another. Even if migration doesn't work, it will still
> help all that don't require it. It is only a partial fix by nature
> anyway.

Can people be a bit more explicit about what they think should be done here?

I'm happy to redirect effort to PVH shim if that's what the solution
is going to be.

I obviously prefer the HVM approach as it works on a broad range of Xen versions
without modification but I'm keen to get something done quickly and
don't want to
waste effort.

Where are people's heads at?

Regards,

Anthony Liguori


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

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.