From: David Hildenbrand <david@redhat.com>
To: Dave Hansen <dave.hansen@intel.com>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>,
Borislav Petkov <bp@alien8.de>,
Andrew Morton <akpm@linux-foundation.org>,
Vlastimil Babka <vbabka@suse.cz>,
Mike Rapoport <rppt@linux.ibm.com>,
Lorenzo Stoakes <lstoakes@gmail.com>,
Tom Lendacky <thomas.lendacky@amd.com>,
Baoquan He <bhe@redhat.com>, Vivek Goyal <vgoyal@redhat.com>,
Dave Young <dyoung@redhat.com>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-mm@kvack.org, linux-coco@lists.linux.dev,
linux-efi@vger.kernel.org, kexec@lists.infradead.org
Subject: Re: [PATCH 3/3] /dev/mem: Do not map unaccepted memory
Date: Mon, 11 Sep 2023 10:09:44 +0200 [thread overview]
Message-ID: <c60df0e4-4214-bbd0-7fc6-8f04e5888f53@redhat.com> (raw)
In-Reply-To: <7a50d04f-63ee-a901-6f39-7d341e423a77@intel.com>
On 07.09.23 16:46, Dave Hansen wrote:
> On 9/7/23 07:25, Kirill A. Shutemov wrote:
>> On Thu, Sep 07, 2023 at 07:15:21AM -0700, Dave Hansen wrote:
>>> On 9/6/23 00:39, Adrian Hunter wrote:
>>>> Support for unaccepted memory was added recently, refer commit
>>>> dcdfdd40fa82 ("mm: Add support for unaccepted memory"), whereby
>>>> a virtual machine may need to accept memory before it can be used.
>>>>
>>>> Do not map unaccepted memory because it can cause the guest to fail.
>>> Doesn't /dev/mem already provide a billion ways for someone to shoot
>>> themselves in the foot? TDX seems to have added the 1,000,000,001st.
>>> Is this really worth patching?
>> Is it better to let TD die silently? I don't think so.
>
> First, let's take a look at all of the distro kernels that folks will
> run under TDX. Do they have STRICT_DEVMEM set?
For virtio-mem, we do
config VIRTIO_MEM
...
depends on EXCLUSIVE_SYSTEM_RAM
Which in turn:
config EXCLUSIVE_SYSTEM_RAM
...
depends on !DEVMEM || STRICT_DEVMEM
Not supported on all archs, but at least on RHEL9 on x86_64 and aarch64.
So, making unaccepted memory similarly depend on "!DEVMEM ||
STRICT_DEVMEM" does not sound too far off ...
--
Cheers,
David / dhildenb
WARNING: multiple messages have this Message-ID (diff)
From: David Hildenbrand <david@redhat.com>
To: Dave Hansen <dave.hansen@intel.com>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>,
Borislav Petkov <bp@alien8.de>,
Andrew Morton <akpm@linux-foundation.org>,
Vlastimil Babka <vbabka@suse.cz>,
Mike Rapoport <rppt@linux.ibm.com>,
Lorenzo Stoakes <lstoakes@gmail.com>,
Tom Lendacky <thomas.lendacky@amd.com>,
Baoquan He <bhe@redhat.com>, Vivek Goyal <vgoyal@redhat.com>,
Dave Young <dyoung@redhat.com>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-mm@kvack.org, linux-coco@lists.linux.dev,
linux-efi@vger.kernel.org, kexec@lists.infradead.org
Subject: Re: [PATCH 3/3] /dev/mem: Do not map unaccepted memory
Date: Mon, 11 Sep 2023 10:09:44 +0200 [thread overview]
Message-ID: <c60df0e4-4214-bbd0-7fc6-8f04e5888f53@redhat.com> (raw)
In-Reply-To: <7a50d04f-63ee-a901-6f39-7d341e423a77@intel.com>
On 07.09.23 16:46, Dave Hansen wrote:
> On 9/7/23 07:25, Kirill A. Shutemov wrote:
>> On Thu, Sep 07, 2023 at 07:15:21AM -0700, Dave Hansen wrote:
>>> On 9/6/23 00:39, Adrian Hunter wrote:
>>>> Support for unaccepted memory was added recently, refer commit
>>>> dcdfdd40fa82 ("mm: Add support for unaccepted memory"), whereby
>>>> a virtual machine may need to accept memory before it can be used.
>>>>
>>>> Do not map unaccepted memory because it can cause the guest to fail.
>>> Doesn't /dev/mem already provide a billion ways for someone to shoot
>>> themselves in the foot? TDX seems to have added the 1,000,000,001st.
>>> Is this really worth patching?
>> Is it better to let TD die silently? I don't think so.
>
> First, let's take a look at all of the distro kernels that folks will
> run under TDX. Do they have STRICT_DEVMEM set?
For virtio-mem, we do
config VIRTIO_MEM
...
depends on EXCLUSIVE_SYSTEM_RAM
Which in turn:
config EXCLUSIVE_SYSTEM_RAM
...
depends on !DEVMEM || STRICT_DEVMEM
Not supported on all archs, but at least on RHEL9 on x86_64 and aarch64.
So, making unaccepted memory similarly depend on "!DEVMEM ||
STRICT_DEVMEM" does not sound too far off ...
--
Cheers,
David / dhildenb
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2023-09-11 8:09 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-06 7:38 [PATCH 0/3] Do not map unaccepted memory Adrian Hunter
2023-09-06 7:38 ` Adrian Hunter
2023-09-06 7:39 ` [PATCH 1/3] proc/vmcore: " Adrian Hunter
2023-09-06 7:39 ` Adrian Hunter
2023-09-07 15:39 ` Dave Hansen
2023-09-07 15:39 ` Dave Hansen
2023-09-07 15:44 ` Adrian Hunter
2023-09-07 15:44 ` Adrian Hunter
2023-09-07 15:51 ` Dave Hansen
2023-09-07 15:51 ` Dave Hansen
2023-09-11 8:03 ` David Hildenbrand
2023-09-11 8:03 ` David Hildenbrand
2023-09-11 8:41 ` Kirill A. Shutemov
2023-09-11 8:41 ` Kirill A. Shutemov
2023-09-11 8:42 ` David Hildenbrand
2023-09-11 8:42 ` David Hildenbrand
2023-09-11 9:27 ` Kirill A. Shutemov
2023-09-11 9:27 ` Kirill A. Shutemov
2023-09-11 9:50 ` David Hildenbrand
2023-09-11 9:50 ` David Hildenbrand
2023-09-11 10:05 ` Kirill A. Shutemov
2023-09-11 10:05 ` Kirill A. Shutemov
2023-09-11 14:33 ` David Hildenbrand
2023-09-11 14:33 ` David Hildenbrand
2023-09-06 7:39 ` [PATCH 2/3] proc/kcore: " Adrian Hunter
2023-09-06 7:39 ` Adrian Hunter
2023-09-07 15:36 ` Dave Hansen
2023-09-07 15:36 ` Dave Hansen
2023-09-07 15:43 ` Dave Hansen
2023-09-07 15:43 ` Dave Hansen
2023-09-06 7:39 ` [PATCH 3/3] /dev/mem: " Adrian Hunter
2023-09-06 7:39 ` Adrian Hunter
2023-09-07 10:06 ` Kirill A. Shutemov
2023-09-07 10:06 ` Kirill A. Shutemov
2023-09-07 14:15 ` Dave Hansen
2023-09-07 14:15 ` Dave Hansen
2023-09-07 14:25 ` Kirill A. Shutemov
2023-09-07 14:25 ` Kirill A. Shutemov
2023-09-07 14:46 ` Dave Hansen
2023-09-07 14:46 ` Dave Hansen
2023-09-07 15:04 ` Dave Hansen
2023-09-07 15:04 ` Dave Hansen
2023-09-11 8:09 ` David Hildenbrand [this message]
2023-09-11 8:09 ` David Hildenbrand
2023-09-11 14:32 ` Dave Hansen
2023-09-11 14:32 ` Dave Hansen
2023-09-07 10:07 ` [PATCH 0/3] " Kirill A. Shutemov
2023-09-07 10:07 ` Kirill A. Shutemov
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=c60df0e4-4214-bbd0-7fc6-8f04e5888f53@redhat.com \
--to=david@redhat.com \
--cc=adrian.hunter@intel.com \
--cc=akpm@linux-foundation.org \
--cc=bhe@redhat.com \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--cc=dyoung@redhat.com \
--cc=kexec@lists.infradead.org \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-coco@lists.linux.dev \
--cc=linux-efi@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lstoakes@gmail.com \
--cc=rppt@linux.ibm.com \
--cc=thomas.lendacky@amd.com \
--cc=vbabka@suse.cz \
--cc=vgoyal@redhat.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.