All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: "Wei Liu" <wl@xen.org>, "Roger Pau Monné" <roger.pau@citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH 2/4] x86/P2M: relax guarding of MMIO entries
Date: Wed, 1 Sep 2021 10:08:44 +0200	[thread overview]
Message-ID: <c48dd5c9-bd88-9ae8-856b-4049e26bc099@suse.com> (raw)
In-Reply-To: <5d69d4c0-7a04-c3da-f971-616363c6d63d@suse.com>

On 31.08.2021 17:38, Jan Beulich wrote:
> On 31.08.2021 17:25, Andrew Cooper wrote:
>> On 31/08/2021 14:26, Jan Beulich wrote:
>>> On 31.08.2021 15:16, Andrew Cooper wrote:
>>>> On 30/08/2021 14:02, Jan Beulich wrote:
>>>>> Further permit "access" to differ in the "executable" attribute. While
>>>>> ideally only ROM regions would get mapped with X set, getting there is
>>>>> quite a bit of work. Therefore, as a temporary measure, permit X to
>>>>> vary. For Dom0 the more permissive of the types will be used, while for
>>>>> DomU it'll be the more restrictive one.
>>>> Split behaviour between dom0 and domU based on types alone cannot
>>>> possibly be correct.
>>> True, but what do you do.
>>>
>>>> DomU's need to execute ROMs too, and this looks like will malfunction if
>>>> a ROM ends up in the region that HVMLoader relocated RAM from.
>>>>
>>>> As this is a temporary bodge emergency bugfix, don't try to be clever -
>>>> just take the latest access.
>>> And how do we know that that's what is going to work?
>>
>> Because it's the pre-existing behaviour.
> 
> Valid point. But for the DomU case there simply has not been any
> pre-existing behavior. Hence my desire to be restrictive initially
> there.

Further to this: Using the last-value-set approach also puts us at
risk of running into a similar issue again when the ordering of
some operations changes elsewhere.

Jan



  reply	other threads:[~2021-09-01  8:09 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-30 13:01 [PATCH 0/4] x86/PVH: Dom0 building adjustments Jan Beulich
2021-08-30 13:02 ` [PATCH 1/4] x86/PVH: de-duplicate mappings for first Mb of Dom0 memory Jan Beulich
2021-08-31 13:02   ` Andrew Cooper
2021-08-31 13:14     ` Jan Beulich
2021-08-31 13:19       ` Jan Beulich
2021-08-31 13:27         ` Andrew Cooper
2021-08-31 13:36           ` Jan Beulich
2021-09-01 11:49             ` Andrew Cooper
2021-09-01  8:41       ` Roger Pau Monné
2021-08-30 13:02 ` [PATCH 2/4] x86/P2M: relax guarding of MMIO entries Jan Beulich
2021-08-31 13:16   ` Jan Beulich
2021-08-31 13:16   ` Andrew Cooper
2021-08-31 13:26     ` Jan Beulich
2021-08-31 15:25       ` Andrew Cooper
2021-08-31 15:38         ` Jan Beulich
2021-09-01  8:08           ` Jan Beulich [this message]
2021-09-01  8:50           ` Roger Pau Monné
2021-09-01  9:53             ` Jan Beulich
2021-09-01 13:48               ` Roger Pau Monné
2021-09-01 14:05                 ` Jan Beulich
2021-09-01 12:47           ` Andrew Cooper
2021-09-01 13:08             ` Jan Beulich
2021-09-06 19:53               ` Andrew Cooper
2021-09-07  6:27                 ` Jan Beulich
2021-08-30 13:03 ` [PATCH 3/4] x86/PVH: improve Dom0 memory size calculation Jan Beulich
2021-08-31 14:07   ` Andrew Cooper
2021-08-31 15:30     ` Jan Beulich
2021-08-30 13:03 ` [PATCH 4/4] x86/PV: properly set shadow allocation for Dom0 Jan Beulich
2021-08-31 13:47   ` Andrew Cooper
2021-08-31 14:25     ` Jan Beulich
2021-08-31 21:08   ` Tim Deegan
2021-08-31  8:53 ` [PATCH 0/4] x86/PVH: Dom0 building adjustments Jan Beulich
2021-09-01 13:56   ` Roger Pau Monné
2021-09-01 14:19     ` Jan Beulich
2021-09-01 14:25       ` Jan Beulich
2021-09-01 16:13       ` Roger Pau Monné
2021-09-02  6:30         ` Jan Beulich
2021-09-01 15:06 ` Jan Beulich
2021-09-01 15:24   ` Juergen Gross
2021-09-01 15:51     ` Jan Beulich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c48dd5c9-bd88-9ae8-856b-4049e26bc099@suse.com \
    --to=jbeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=roger.pau@citrix.com \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.