Borislav Petkov
2022-Apr-26 17:35 UTC
[PATCH 2/2] virtio: replace arch_has_restricted_virtio_memory_access()
On Tue, Apr 26, 2022 at 03:40:21PM +0200, Juergen Gross wrote:> /* protected virtualization */ > static void pv_init(void) > { > if (!is_prot_virt_guest()) > return; > > + platform_set_feature(PLATFORM_VIRTIO_RESTRICTED_MEM_ACCESS);Kinda long-ish for my taste. I'll probably call it: platform_set() as it is implicit that it sets a feature bit.> diff --git a/arch/x86/mm/mem_encrypt_identity.c b/arch/x86/mm/mem_encrypt_identity.c > index b43bc24d2bb6..6043ba6cd17d 100644 > --- a/arch/x86/mm/mem_encrypt_identity.c > +++ b/arch/x86/mm/mem_encrypt_identity.c > @@ -40,6 +40,7 @@ > #include <linux/mm.h> > #include <linux/mem_encrypt.h> > #include <linux/cc_platform.h> > +#include <linux/platform-feature.h> > > #include <asm/setup.h> > #include <asm/sections.h> > @@ -566,6 +567,10 @@ void __init sme_enable(struct boot_params *bp) > } else { > /* SEV state cannot be controlled by a command line option */ > sme_me_mask = me_mask; > + > + /* Set restricted memory access for virtio. */ > + platform_set_feature(PLATFORM_VIRTIO_RESTRICTED_MEM_ACCESS);Huh, what does that have to do with SME? In any case, yeah, looks ok at a quick glance. It would obviously need for more people to look at it and say whether it makes sense to them and whether that's fine to have in generic code but so far, the experience with cc_platform_* says that it seems to work ok in generic code. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette
Juergen Gross
2022-Apr-27 06:37 UTC
[PATCH 2/2] virtio: replace arch_has_restricted_virtio_memory_access()
On 26.04.22 19:35, Borislav Petkov wrote:> On Tue, Apr 26, 2022 at 03:40:21PM +0200, Juergen Gross wrote: >> /* protected virtualization */ >> static void pv_init(void) >> { >> if (!is_prot_virt_guest()) >> return; >> >> + platform_set_feature(PLATFORM_VIRTIO_RESTRICTED_MEM_ACCESS); > > Kinda long-ish for my taste. I'll probably call it: > > platform_set() > > as it is implicit that it sets a feature bit.Okay, fine with me.> >> diff --git a/arch/x86/mm/mem_encrypt_identity.c b/arch/x86/mm/mem_encrypt_identity.c >> index b43bc24d2bb6..6043ba6cd17d 100644 >> --- a/arch/x86/mm/mem_encrypt_identity.c >> +++ b/arch/x86/mm/mem_encrypt_identity.c >> @@ -40,6 +40,7 @@ >> #include <linux/mm.h> >> #include <linux/mem_encrypt.h> >> #include <linux/cc_platform.h> >> +#include <linux/platform-feature.h> >> >> #include <asm/setup.h> >> #include <asm/sections.h> >> @@ -566,6 +567,10 @@ void __init sme_enable(struct boot_params *bp) >> } else { >> /* SEV state cannot be controlled by a command line option */ >> sme_me_mask = me_mask; >> + >> + /* Set restricted memory access for virtio. */ >> + platform_set_feature(PLATFORM_VIRTIO_RESTRICTED_MEM_ACCESS); > > Huh, what does that have to do with SME?I picked the function where sev_status is being set, as this seemed to be the correct place to set the feature bit. Looking at it in more detail it might be preferable to do it in sev_setup_arch() instead. Juergen -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0xB0DE9DD628BF132F.asc Type: application/pgp-keys Size: 3098 bytes Desc: OpenPGP public key URL: <http://lists.linuxfoundation.org/pipermail/virtualization/attachments/20220427/3920d1ac/attachment.bin> -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 495 bytes Desc: OpenPGP digital signature URL: <http://lists.linuxfoundation.org/pipermail/virtualization/attachments/20220427/3920d1ac/attachment.sig>