All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oliver Upton <oliver.upton@linux.dev>
To: ankita@nvidia.com
Cc: jgg@nvidia.com, maz@kernel.org, james.morse@arm.com,
	suzuki.poulose@arm.com, yuzenghui@huawei.com,
	reinette.chatre@intel.com, surenb@google.com,
	stefanha@redhat.com, brauner@kernel.org, catalin.marinas@arm.com,
	will@kernel.org, mark.rutland@arm.com,
	alex.williamson@redhat.com, kevin.tian@intel.com,
	yi.l.liu@intel.com, ardb@kernel.org, akpm@linux-foundation.org,
	andreyknvl@gmail.com, wangjinchao@xfusion.com, gshan@redhat.com,
	shahuang@redhat.com, ricarkol@google.com, linux-mm@kvack.org,
	lpieralisi@kernel.org, rananta@google.com, ryan.roberts@arm.com,
	david@redhat.com, linus.walleij@linaro.org, bhe@redhat.com,
	aniketa@nvidia.com, cjia@nvidia.com, kwankhede@nvidia.com,
	targupta@nvidia.com, vsethi@nvidia.com, acurrid@nvidia.com,
	apopple@nvidia.com, jhubbard@nvidia.com, danw@nvidia.com,
	kvmarm@lists.linux.dev, mochs@nvidia.com, zhiw@nvidia.com,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v7 0/4] kvm: arm64: allow the VM to select DEVICE_* and NORMAL_NC for IO memory
Date: Mon, 12 Feb 2024 20:24:36 +0000	[thread overview]
Message-ID: <Zcp-hIlV-ZEu0Jou@linux.dev> (raw)
In-Reply-To: <20240211174705.31992-1-ankita@nvidia.com>

On Sun, Feb 11, 2024 at 11:17:01PM +0530, ankita@nvidia.com wrote:
> From: Ankit Agrawal <ankita@nvidia.com>
> 
> Currently, KVM for ARM64 maps at stage 2 memory that is considered device
> with DEVICE_nGnRE memory attributes; this setting overrides (per
> ARM architecture [1]) any device MMIO mapping present at stage 1,
> resulting in a set-up whereby a guest operating system cannot
> determine device MMIO mapping memory attributes on its own but
> it is always overridden by the KVM stage 2 default.
> 
> This set-up does not allow guest operating systems to select device
> memory attributes independently from KVM stage-2 mappings
> (refer to [1], "Combining stage 1 and stage 2 memory type attributes"),
> which turns out to be an issue in that guest operating systems
> (e.g. Linux) may request to map devices MMIO regions with memory
> attributes that guarantee better performance (e.g. gathering
> attribute - that for some devices can generate larger PCIe memory
> writes TLPs) and specific operations (e.g. unaligned transactions)
> such as the NormalNC memory type.
> 
> The default device stage 2 mapping was chosen in KVM for ARM64 since
> it was considered safer (i.e. it would not allow guests to trigger
> uncontained failures ultimately crashing the machine) but this
> turned out to be asynchronous (SError) defeating the purpose.
> 
> For these reasons, relax the KVM stage 2 device memory attributes
> from DEVICE_nGnRE to Normal-NC.

Hi Ankit,

Thanks for being responsive in respinning the series according to the
feedback. I think we're pretty close here, but it'd be good to address
the comment / changelog feedback as well.

Can you respin this once more? Hopefully we can get this stuff soaking
in -next thereafter.

-- 
Thanks,
Oliver

WARNING: multiple messages have this Message-ID (diff)
From: Oliver Upton <oliver.upton@linux.dev>
To: ankita@nvidia.com
Cc: jgg@nvidia.com, maz@kernel.org, james.morse@arm.com,
	suzuki.poulose@arm.com, yuzenghui@huawei.com,
	reinette.chatre@intel.com, surenb@google.com,
	stefanha@redhat.com, brauner@kernel.org, catalin.marinas@arm.com,
	will@kernel.org, mark.rutland@arm.com,
	alex.williamson@redhat.com, kevin.tian@intel.com,
	yi.l.liu@intel.com, ardb@kernel.org, akpm@linux-foundation.org,
	andreyknvl@gmail.com, wangjinchao@xfusion.com, gshan@redhat.com,
	shahuang@redhat.com, ricarkol@google.com, linux-mm@kvack.org,
	lpieralisi@kernel.org, rananta@google.com, ryan.roberts@arm.com,
	david@redhat.com, linus.walleij@linaro.org, bhe@redhat.com,
	aniketa@nvidia.com, cjia@nvidia.com, kwankhede@nvidia.com,
	targupta@nvidia.com, vsethi@nvidia.com, acurrid@nvidia.com,
	apopple@nvidia.com, jhubbard@nvidia.com, danw@nvidia.com,
	kvmarm@lists.linux.dev, mochs@nvidia.com, zhiw@nvidia.com,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v7 0/4] kvm: arm64: allow the VM to select DEVICE_* and NORMAL_NC for IO memory
Date: Mon, 12 Feb 2024 20:24:36 +0000	[thread overview]
Message-ID: <Zcp-hIlV-ZEu0Jou@linux.dev> (raw)
In-Reply-To: <20240211174705.31992-1-ankita@nvidia.com>

On Sun, Feb 11, 2024 at 11:17:01PM +0530, ankita@nvidia.com wrote:
> From: Ankit Agrawal <ankita@nvidia.com>
> 
> Currently, KVM for ARM64 maps at stage 2 memory that is considered device
> with DEVICE_nGnRE memory attributes; this setting overrides (per
> ARM architecture [1]) any device MMIO mapping present at stage 1,
> resulting in a set-up whereby a guest operating system cannot
> determine device MMIO mapping memory attributes on its own but
> it is always overridden by the KVM stage 2 default.
> 
> This set-up does not allow guest operating systems to select device
> memory attributes independently from KVM stage-2 mappings
> (refer to [1], "Combining stage 1 and stage 2 memory type attributes"),
> which turns out to be an issue in that guest operating systems
> (e.g. Linux) may request to map devices MMIO regions with memory
> attributes that guarantee better performance (e.g. gathering
> attribute - that for some devices can generate larger PCIe memory
> writes TLPs) and specific operations (e.g. unaligned transactions)
> such as the NormalNC memory type.
> 
> The default device stage 2 mapping was chosen in KVM for ARM64 since
> it was considered safer (i.e. it would not allow guests to trigger
> uncontained failures ultimately crashing the machine) but this
> turned out to be asynchronous (SError) defeating the purpose.
> 
> For these reasons, relax the KVM stage 2 device memory attributes
> from DEVICE_nGnRE to Normal-NC.

Hi Ankit,

Thanks for being responsive in respinning the series according to the
feedback. I think we're pretty close here, but it'd be good to address
the comment / changelog feedback as well.

Can you respin this once more? Hopefully we can get this stuff soaking
in -next thereafter.

-- 
Thanks,
Oliver

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2024-02-12 20:24 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-11 17:47 [PATCH v7 0/4] kvm: arm64: allow the VM to select DEVICE_* and NORMAL_NC for IO memory ankita
2024-02-11 17:47 ` ankita
2024-02-11 17:47 ` [PATCH v7 1/4] kvm: arm64: introduce new flag for non-cacheable " ankita
2024-02-11 17:47   ` ankita
2024-02-11 17:47 ` [PATCH v7 2/4] mm: introduce new flag to indicate wc safe ankita
2024-02-11 17:47   ` ankita
2024-02-12 13:13   ` David Hildenbrand
2024-02-12 13:13     ` David Hildenbrand
2024-02-13  3:41     ` Ankit Agrawal
2024-02-13  3:41       ` Ankit Agrawal
2024-02-11 17:47 ` [PATCH v7 3/4] kvm: arm64: set io memory s2 pte as normalnc for vfio pci device ankita
2024-02-11 17:47   ` ankita
2024-02-11 17:47 ` [PATCH v7 4/4] vfio: convey kvm that the vfio-pci device is wc safe ankita
2024-02-11 17:47   ` ankita
2024-02-12 13:16   ` David Hildenbrand
2024-02-12 13:16     ` David Hildenbrand
2024-02-12 17:05   ` Alex Williamson
2024-02-12 17:05     ` Alex Williamson
2024-02-12 17:20     ` Jason Gunthorpe
2024-02-12 17:20       ` Jason Gunthorpe
2024-02-12 17:27       ` Alex Williamson
2024-02-12 17:27         ` Alex Williamson
2024-02-13  1:59         ` Ankit Agrawal
2024-02-13  1:59           ` Ankit Agrawal
2024-02-12 10:26 ` [PATCH v7 0/4] kvm: arm64: allow the VM to select DEVICE_* and NORMAL_NC for IO memory David Hildenbrand
2024-02-12 10:26   ` David Hildenbrand
2024-02-12 12:56   ` Jason Gunthorpe
2024-02-12 12:56     ` Jason Gunthorpe
2024-02-12 13:06     ` David Hildenbrand
2024-02-12 13:06       ` David Hildenbrand
2024-02-12 20:24 ` Oliver Upton [this message]
2024-02-12 20:24   ` Oliver Upton
2024-02-13  2:29   ` Ankit Agrawal
2024-02-13  2:29     ` Ankit Agrawal

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=Zcp-hIlV-ZEu0Jou@linux.dev \
    --to=oliver.upton@linux.dev \
    --cc=acurrid@nvidia.com \
    --cc=akpm@linux-foundation.org \
    --cc=alex.williamson@redhat.com \
    --cc=andreyknvl@gmail.com \
    --cc=aniketa@nvidia.com \
    --cc=ankita@nvidia.com \
    --cc=apopple@nvidia.com \
    --cc=ardb@kernel.org \
    --cc=bhe@redhat.com \
    --cc=brauner@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=cjia@nvidia.com \
    --cc=danw@nvidia.com \
    --cc=david@redhat.com \
    --cc=gshan@redhat.com \
    --cc=james.morse@arm.com \
    --cc=jgg@nvidia.com \
    --cc=jhubbard@nvidia.com \
    --cc=kevin.tian@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.linux.dev \
    --cc=kwankhede@nvidia.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lpieralisi@kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=maz@kernel.org \
    --cc=mochs@nvidia.com \
    --cc=rananta@google.com \
    --cc=reinette.chatre@intel.com \
    --cc=ricarkol@google.com \
    --cc=ryan.roberts@arm.com \
    --cc=shahuang@redhat.com \
    --cc=stefanha@redhat.com \
    --cc=surenb@google.com \
    --cc=suzuki.poulose@arm.com \
    --cc=targupta@nvidia.com \
    --cc=vsethi@nvidia.com \
    --cc=wangjinchao@xfusion.com \
    --cc=will@kernel.org \
    --cc=yi.l.liu@intel.com \
    --cc=yuzenghui@huawei.com \
    --cc=zhiw@nvidia.com \
    /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.