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

Re: [PATCH v6 4/5] x86/mm: Reject invalid cacheability in PV guests by default


  • To: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Fri, 6 Jan 2023 08:11:35 +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=Dp/SB8FHsc/pkJeDx9F8rMb9yST6AkHe9p8Ch4PCHkc=; b=nCZf8kPTPLb6VlMmePmX6Vlebf0nWDgWVjFdTt7I+n8s7posmeO1hmCcVw/IYeadXnwFKAxAOLBdQSENoPDPhC2Sax9fahrE0eUTg9BDVN3OqPDdFj0Goi36mihpWhmOTTIQGhEaHGMVlRWKCWTCUq3pswyYd8QQvvOgi2qMff5SZfkvihRxZIchSP5QDz0gf6XpbGnGO9YDICmYnmzmPIRywb38ow1X9ocrn9wKHNim/NE5ccNJvgEBMjhqDMRKCqgIFQp4GsIMe3bLykZYe9adYdy5K2f46YEq/YkDV/AZEfXXu47YXE1iAsVmuwHNIxZOzUuUdKh9yC4CfZkrJg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oTO/hX2NnU0CaFQ1rnRN2JHB8m6wntDKLv4VxP7WfR2Ms4ooXiUib3yWR7mQJEvDV5ZoSFwXnK/SG2kmnkbHzyRBy30Vbfa35N1jpo5vMApc+K/HJsOZGJxilu3BCy4fpoPH4+gXQxnEwIlAsMjcF+qPMTGCA58ahDMczSupMwvI0hODX2+yPLuZ7ooQgx7jkKJtyVOQlDo8sK8qVhrEFSTeF/1R6Yg93DGFmSpBGSqDrfcJw1d76up8UKKAU0BAr5l8Zx2qGgwkOO5/x5JYB4lK48roL8HA7rIGbpzmAzUQkzz8ZLRgdiKlTyNLmXG0oc7dgRqniWFivkv4jkziEw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>, Roger Pau Monne <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, "Tim (Xen.org)" <tim@xxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxx>, Demi Marie Obenour <demi@xxxxxxxxxxxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Fri, 06 Jan 2023 07:11:47 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 05.01.2023 21:28, Andrew Cooper wrote:
> On 22/12/2022 10:31 pm, Demi Marie Obenour wrote:
>> diff --git a/docs/misc/xen-command-line.pandoc 
>> b/docs/misc/xen-command-line.pandoc
>> index 
>> 424b12cfb27d6ade2ec63eacb8afe5df82465451..0230a7bc17cbd4362a42ea64cea695f31f5e0f86
>>  100644
>> --- a/docs/misc/xen-command-line.pandoc
>> +++ b/docs/misc/xen-command-line.pandoc
>> @@ -1417,6 +1417,17 @@ detection of systems known to misbehave upon accesses 
>> to that port.
>>  ### idle_latency_factor (x86)
>>  > `= <integer>`
>>  
>> +### invalid-cacheability (x86)
>> +> `= allow | deny | trap`
>> +
>> +> Default: `deny` in release builds, otherwise `trap`
>> +
>> +Specify what happens when a PV guest tries to use one of the reserved 
>> entries in
>> +the PAT.  `deny` causes the attempt to be rejected with -EINVAL, `allow` 
>> allows
>> +the attempt, and `trap` causes a general protection fault to be raised.
>> +Currently, the reserved entries are marked as uncacheable in Xen's PAT, but 
>> this
>> +will change if new memory types are added, so guests must not rely on it.
>> +
> 
> This wants to be scoped under "pv", and not a top-level option.  Current
> parsing is at the top of xen/arch/x86/pv/domain.c
> 
> How about `pv={no-}oob-pat`, and parse it into the opt_pv_oob_pat boolean ?
> 
> There really is no need to distinguish between deny and trap.  IMO,
> injecting #GP unilaterally is fine (to a guest expecting the hypercall
> to succeed, -EINVAL vs #GP makes no difference, but #GP is far more
> useful to a human trying to debug issues here), but I could be talked
> into putting that behind a CONFIG_DEBUG if other feel strongly.

What is or is not useful to guests is guesswork. They might be "handling"
failure with BUG(), in which case they'd still see a backtrace. So to me,
as previously said, injecting #GP in the case here can only reasonably be
a debugging aid (and hence be dependent upon DEBUG).

Jan



 


Rackspace

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