similar to: [PATCH] virtio: make VIRTIO a menuconfig to ease disabling it all

No need to get into the submenu to disable all VIRTIO-related config entries. This makes it easier to disable all VIRTIO config options without entering the submenu. It will also enable one to see that en/dis-abled state from the outside menu. This is only intended to change menuconfig UI, not change the config dependencies. v2: add "default y" to avoid breaking existing configs

No need to get into the submenu to disable all VIRTIO-related config entries. This makes it easier to disable all VIRTIO config options without entering the submenu. It will also enable one to see that en/dis-abled state from the outside menu. This is only intended to change menuconfig UI, not change the config dependencies. v2: add "default y" to avoid breaking existing configs

Michael Ellerman <mpe at ellerman.id.au> writes: > Vincent Legoll <vincent.legoll at gmail.com> writes: > >> Hello, >> >> thanks for the help, and sorry for the poor patch, >> >> On Thu, Dec 21, 2017 at 11:53 AM, Michael Ellerman <mpe at ellerman.id.au> wrote: >>> This breaks all existing .configs *and* defconfigs that use VIRTIO.

No need to get into the submenu to disable all VIRTIO-related config entries. This makes it easier to disable all VIRTIO config options without entering the submenu. It will also enable one to see that en/dis-abled state from the outside menu. This is only intended to change menuconfig UI, not change the config dependencies. v2: Added "default y" to avoid breaking existing configs v3:

Vincent Legoll <vincent.legoll at gmail.com> writes: > No need to get into the submenu to disable all VIRTIO-related > config entries. > > This makes it easier to disable all VIRTIO config options > without entering the submenu. It will also enable one > to see that en/dis-abled state from the outside menu. > > This is only intended to change menuconfig UI, not

On 01/03/18 01:49, Vincent Legoll wrote: > No need to get into the submenu to disable all VIRTIO-related > config entries. > > This makes it easier to disable all VIRTIO config options > without entering the submenu. It will also enable one > to see that en/dis-abled state from the outside menu. > > This is only intended to change menuconfig UI, not change > the config

Hello, thanks for the help, and sorry for the poor patch, On Thu, Dec 21, 2017 at 11:53 AM, Michael Ellerman <mpe at ellerman.id.au> wrote: > This breaks all existing .configs *and* defconfigs that use VIRTIO. > > Please don't do that. > > If you make it default y then everything will continue to work. Do you want me to respin it with the added default ? Tchuss --

Hello, thanks for the help, and sorry for the poor patch, On Thu, Dec 21, 2017 at 11:53 AM, Michael Ellerman <mpe at ellerman.id.au> wrote: > This breaks all existing .configs *and* defconfigs that use VIRTIO. > > Please don't do that. > > If you make it default y then everything will continue to work. Do you want me to respin it with the added default ? Tchuss --

On 1/23/18, Michael Ellerman <mpe at ellerman.id.au> wrote: > This has been broken in linux-next for ~6 weeks now, can we please merge > this and get it fixed. Added Stephen Rothwell to cc -- Vincent Legoll

On Wed, Apr 01, 2020 at 10:29:32PM +0800, Jason Wang wrote: > > On 2020/4/1 ??10:13, Michael S. Tsirkin wrote: > > On Wed, Apr 01, 2020 at 10:08:59PM +0800, Jason Wang wrote: > > > On 2020/4/1 ??9:22, Michael S. Tsirkin wrote: > > > > On Thu, Mar 26, 2020 at 10:01:17PM +0800, Jason Wang wrote: > > > > > Currently, CONFIG_VHOST depends on

On Wed, 19 Aug 2020 18:23:17 +0200 Pierre Morel <pmorel at linux.ibm.com> wrote: > An architecture may restrict host access to guest memory. "e.g. IBM s390 Secure Execution or AMD SEV" Just to make clearer what you are referring to? > > Provide a new Kconfig entry the architecture can select, > CONFIG_ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS, when it provides >

Vincent Legoll <vincent.legoll at gmail.com> writes: > No need to get into the submenu to disable all VIRTIO-related > config entries. > > This makes it easier to disable all VIRTIO config options > without entering the submenu. It will also enable one > to see that en/dis-abled state from the outside menu. > > This is only intended to change menuconfig UI, not

On Tue, 18 Aug 2020 16:58:30 +0200 Pierre Morel <pmorel at linux.ibm.com> wrote: > An architecture may need to validate the VIRTIO devices features > based on architecture specifics. > > Provide a new Kconfig entry, CONFIG_ARCH_HAS_RESTRICTED_MEMORY_ACCESS, > the architecture can select when it provides a callback named > arch_has_restricted_memory_access to validate the

On Tue, 18 Aug 2020 16:58:30 +0200 Pierre Morel <pmorel at linux.ibm.com> wrote: > An architecture may need to validate the VIRTIO devices features > based on architecture specifics. > > Provide a new Kconfig entry, CONFIG_ARCH_HAS_RESTRICTED_MEMORY_ACCESS, > the architecture can select when it provides a callback named > arch_has_restricted_memory_access to validate the

No need to get into the submenu to disable all VIRTIO-related config entries. This makes it easier to disable all VIRTIO config options without entering the submenu. It will also enable one to see that en/dis-abled state from the outside menu. This is only intended to change menuconfig UI, not change the config dependencies. v2: Added "default y" to avoid breaking existing configs

Vincent Legoll <vincent.legoll at gmail.com> writes: > Hello, > > thanks for the help, and sorry for the poor patch, > > On Thu, Dec 21, 2017 at 11:53 AM, Michael Ellerman <mpe at ellerman.id.au> wrote: >> This breaks all existing .configs *and* defconfigs that use VIRTIO. >> >> Please don't do that. >> >> If you make it default y then

Hi all, The goal of the series is to give a chance to the architecture to validate VIRTIO device features. in this respin: The tests are back to virtio_finalize_features. No more argument for the architecture callback which only reports if the architecture needs guest memory access restrictions for VIRTIO. I renamed the callback to arch_has_restricted_virtio_memory_access, and the config

Hi all, The goal of the series is to give a chance to the architecture to validate VIRTIO device features. in this respin: I use the original idea from Connie for an optional arch_has_restricted_memory_access. I renamed the callback accordingly, added the definition of ARCH_HAS_RESTRICTED_MEMORY_ACCESS inside the VIRTIO Kconfig and the selection in the PROTECTED_VIRTUALIZATION_GUEST config

An architecture may need to validate the VIRTIO devices features based on architecture specifics. Provide a new Kconfig entry, CONFIG_ARCH_HAS_RESTRICTED_MEMORY_ACCESS, the architecture can select when it provides a callback named arch_has_restricted_memory_access to validate the virtio device features. Signed-off-by: Pierre Morel <pmorel at linux.ibm.com> --- drivers/virtio/Kconfig

An architecture may restrict host access to guest memory. Provide a new Kconfig entry the architecture can select, CONFIG_ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS, when it provides the arch_has_restricted_virtio_memory_access callback to advertise VIRTIO common code when the architecture restricts memory access from the host. Signed-off-by: Pierre Morel <pmorel at linux.ibm.com> ---