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

Re: [PATCH 2/2] x86/vmx: implement Notify VM Exit


  • To: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Thu, 19 May 2022 08:59:13 +0200
  • 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=XvDDzknZzMcxfntwIJvK5bXWbo7dri2NsUaVwghPuUQ=; b=A12kr4qG7XHtd16zrCwcNI9UN3mwDxnjsXHyqbf0j+n2x5svNDQWDoXF69EvNMjVepMUc8lpM2Fln9Vl+EHxFPA11EL8PO6E61ckH4Se99GT/jHEgu2dsV2Fup29nd/bT4kbKCUIapdNm29dFiXw/rJuNqnUPN3fFtpomZFqi9uBzDA/JXS9hIflcoWd8RsL8Ore07/232EKW9qTMS56sk4dTCSnSPCflIb+sZcuxoHlGM078UozkpS+3jkKOlnAITqGDEy2x4gH5I66gJ0tSaPcyjolBTt4cGZo9JBcexVcqL2DeDHJjINcbQqw2waL9/kDrmvLeuWWQPUc1Fd0zg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cqmds8or1eBAMD/mpQcf4OreaFB4GyoZtP3tml2x+XFCJSFuvEwbs4acOwfTkvIKRnrYjWelzb9fe1M5FgGgYVDCBx+EFakM6uXZxiSane8QjF9WQ7ji6jrQLGUrVXbsJBpayjAhFzwsVKyCMCuHajdtEeICqn4ZBwUFd41s9V0CICNTh9i0fqc06+JE41rxWP4RHGkFlgMxdRvHJxRYQjoKnabUtLq9rG8da1Pn2XrsRy4exfKgvWNhElRQLFUk8SNIsTe4grCcqmg8hjfSw0zYeLrZLzQ8BDXVL+utIzK/GL7MCgoNjMUrPJFM+84AKaOKR6hX9NUZKA0tJGyfog==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: George Dunlap <George.Dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Jun Nakajima <jun.nakajima@xxxxxxxxx>, Kevin Tian <kevin.tian@xxxxxxxxx>, Roger Pau Monne <roger.pau@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Thu, 19 May 2022 06:59:30 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 19.05.2022 02:10, Andrew Cooper wrote:
> On 17/05/2022 14:21, Roger Pau Monne wrote:
>> Under certain conditions guests can get the CPU stuck in an infinite
>> loop without the possibility of an interrupt window to occur.
> 
> instruction boundary.
> 
> It's trivial to create an infinite loop without an interrupt window :)
> 
> Also, I'd probably phrase that as an unbounded loop, because not all
> problem cases are truly infinite.
> 
>>   This
>> was the case with the scenarios described in XSA-156.
> 
> Case in point, both of these can be broken by something else (another
> vCPU, or coherent DMA write) editing the IDT and e.g. making the #AC/#DB
> vectors not present, which will yield #NP instead.

"Can be broken" as in "the loop can be forced to be exited"? If so, how
would a remote CPU / agent become aware of the situation, and know what
the cause is (and hence know which IDT entry to clobber)? After all it's
guest state, which we wouldn't want to alter for no reason. Nor should
we put a guest in a state where #DF might eventually result.

Jan




 


Rackspace

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