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

Re: [Xen-devel] PVH backports to 4.9 and 4.8

On 01/11/2018 12:01 PM, Roger Pau Monné wrote:
> On Thu, Jan 11, 2018 at 11:03:05AM +0000, George Dunlap wrote:
>> On 01/11/2018 10:58 AM, Roger Pau Monné wrote:
>>> On Tue, Jan 09, 2018 at 05:08:15PM +0000, George Dunlap wrote:
>>>> Part of our solution to XSA-254 SP3 (aka "Meltdown") is to backport
>>>> the PVH mode from 4.10 to 4.9 and 4.8.  This will first allow people
>>>> able to run PVH kernels to switch their PV guests directly to PVH
>>>> guests; and second, eventually enable the backport of patches which
>>>> will enable transparent changing of PV guests into PVH guests.
>>>> All of the hypervisor support seems to have existed already in 4.8, so
>>>> the only backports involve toolstack patches.
>>> Thanks for looking into this.
>>> My general opinion given those are toolstack only patches is that if
>>> it works it's fine.
>>>> I've put up two trees for a first-cut backport of the PVH
>>>> functionality, to 4.9 and 4.8 here:
>>>> git://xenbits.xen.org/people/gdunlap/xen.git
>>>> Branches out/pvh-backport/4.8/v1 and out/pvh-backport/4.9/v1
>>>> Below are the patches backported from 4.10 to 4.9 (23 patches total):
>>>> Roger Pau Monne    libxl: add is_default checkers for string and timer_mode
>>>> types
>>>> Roger Pau Monne    libxl: introduce a way to mark fields as deprecated in
>>>> the idl
>>> This or one of the related patches is going to add fields in
>>> domain_build_info, which will break the ABI. Is this expected/OK?
>> Oh right -- this needs to be ported to add the fields at the end.
>> Going back to the 4.10 series, it looks like there are also some "shim
>> host" patches having to do with enabling CPUID faulting in the guest.
>> Do we need to backport those to 4.9 and 4.8 as well?  ISTR they may rely
>> on some hypervisor infrastructure which would then also need to be
>> backported.
> IIRC those are for AMD hardware?
> Adding Andy who worked on those patches.

From what I recall there were two parts:
1. Allow AMD to even enable CPUID faulting if available
2. Enable CPUID faulting for shim guests (both Intel and AMD)

The point of #1 was to enable #2 on AMD hardware.


Xen-devel mailing list



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