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

Re: [Xen-devel] [PATCH V5] x86/hvm: fix domain crash when CR3 has the noflush bit set

On 02/19/2018 10:53 AM, Jan Beulich wrote:
>>>> On 19.02.18 at 09:48, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
>> On 02/16/2018 01:17 PM, Jan Beulich wrote:
>>>>>> On 16.02.18 at 11:22, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
>>>> The emulation layers of Xen lack PCID support, and as we only offer
>>>> PCID to HAP guests, all writes to CR3 are handled by hardware,
>>>> except when introspection is involved. Consequently, trying to set
>>>> CR3 when the noflush bit is set in hvm_set_cr3() leads to domain
>>>> crashes. The workaround is to clear the noflush bit in
>>>> hvm_set_cr3(). CR3 values in hvm_monitor_cr() are also sanitized.
>>>> Additionally, a bool parameter now propagates to
>>>> {svm,vmx}_update_guest_cr(), so that no flushes occur when
>>>> the bit was set.
>>>> Signed-off-by: Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>
>>>> Reported-by: Bitweasil <bitweasil@xxxxxxxxxxxxxx>
>>>> Suggested-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>>>> Acked-by: Tamas K Lengyel <tamas@xxxxxxxxxxxxx>
>>> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
>> Should I rebase this because of commit
>> 24470b99c1671dca531c2cf5747eda2f8892ecbc?
> Well, if that change introduces some conflict with yours, then
> generally the (obvious) answer is "yes". Considering that your
> patch doesn't have all necessary acks yet, whether you wait
> until you have those is up to you (as alternatively there may be
> further requests for changes to make).

Right, sorry for being ambiguous - definitely no conflicts, but I had
assumed (wrongly, as it turns out) that applying it would now require
human intervention. It doesn't.

Sorry for the noise.


Xen-devel mailing list



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