[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] x86/hvm: Include interruptibility state in hvm_hw_cpu
- To: Tamas K Lengyel <tamas.k.lengyel@xxxxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Thu, 17 Mar 2022 17:07:34 +0100
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=c2ix9lrDuwnC2mfvf9nilBBANmOfSzZuGKrKqTEQeeo=; b=mqM9PlA/xheJFGVP/BJjq2F3yNEru6f1RTIvIo90UZ5VEr48xv0lRSrXziY87hjlcE0NNo7nBViATakDMut5qKtzKsox/OfZlt+k7yVZOLkm+7IgOQAViqYsASmwQj3pAzUIV4Hiq9jYJD7o4n1jGPmAcl2onxF5ExX+MENsiRob28OXYM7uqfVE2q+CaGwHpmSgn1zJc+xTwhggNFeDHz4kPTJVijXK2YvFBGdbJKwIpW7qZVnT08hcSmmQgprBbmo10eCg9W5xtGxKvSFxx08yxHI0kiRF3lQ+iVODHBDkUssrbzQcRUm9QiPfX+T908OUigoqIid4ICWHJhvOGQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=W7mevC968OOOLH5EA7LMbg1WkJbTCBuUbpDXNVYJR//iALWTgcQrstZ0eHWyAex3uUPvs+6LYvWPkOW8w1nlQflv0cbZce041Sx0yqd8n6cyeBT7mZCfX5L/b+JYF90qshPWT0um7Gjly2fVVtcBDEJXAzv6IJTEqOfTaaqcIbnP7RoR8yZN6S3vGHr+EyG6B38NRQaFM46cyGdDQGHmCp4Qaqc61g2vtd2tNsB8XePcH3np+IuIKKfQU9GmHRc9pRJSkzbwXRyPf43rtZ+Kj5zKpVy8Kec5GmY91oQcSOvCeOVaoFwgkQHq9HmVdaMZgg/gaPfp7PXssKZYT2KYyw==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
- Cc: Tamas K Lengyel <tamas.lengyel@xxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Jun Nakajima <jun.nakajima@xxxxxxxxx>, Kevin Tian <kevin.tian@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
- Delivery-date: Thu, 17 Mar 2022 16:07:51 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 17.03.2022 16:59, Tamas K Lengyel wrote:
> On Thu, Mar 17, 2022 at 11:06 AM Jan Beulich <jbeulich@xxxxxxxx> wrote:
>>
>> On 17.03.2022 15:43, Tamas K Lengyel wrote:
>>> On Thu, Mar 17, 2022 at 9:56 AM Jan Beulich <jbeulich@xxxxxxxx> wrote:
>>>> On 10.03.2022 19:44, Tamas K Lengyel wrote:
>>>>> @@ -1155,6 +1154,8 @@ static int cf_check hvm_load_cpu_ctxt(struct domain
>>>>> *d, hvm_domain_context_t *h)
>>>>> v->arch.dr6 = ctxt.dr6;
>>>>> v->arch.dr7 = ctxt.dr7;
>>>>>
>>>>> + hvm_set_interrupt_shadow(v, ctxt.interruptibility_info);
>>>>
>>>> Setting reserved bits as well as certain combinations of bits will
>>>> cause VM entry to fail. I think it would be nice to report this as
>>>> an error here rather than waiting for the VM entry failure.
>>>
>>> Not sure if this would be the right spot to do that since that's all
>>> VMX specific and this is the common hvm code.
>>
>> Well, it would be the VMX hook to do the checking, with an error
>> propagated back here.
>
> I'm actually against it because the overhead of that error-checking
> during vm forking would be significant with really no benefit. We are
> copying the state from the parent where it was running fine before, so
> doing that sanity checking thousands of times per second when we
> already know its fine is bad.
I can see your point, but my concern is not forking but normal migration
or restoring of guests, where the incoming data is of effectively
unknown origin.
Jan
|
