David Hildenbrand
2022-Feb-04 13:29 UTC
[PATCH v3] drivers/virtio: Enable virtio mem for ARM64
On 04.02.22 14:24, Michael S. Tsirkin wrote:> On Wed, Jan 19, 2022 at 09:35:05AM +0100, David Hildenbrand wrote: >> On 19.01.22 08:46, Gavin Shan wrote: >>> Hi Michael, >>> >>> On 1/19/22 3:39 PM, Michael S. Tsirkin wrote: >>>> On Wed, Jan 19, 2022 at 09:05:51AM +0800, Gavin Shan wrote: >>>>> This enables virtio-mem device support by allowing to enable the >>>>> corresponding kernel config option (CONFIG_VIRTIO_MEM) on the >>>>> architecture. >>>>> >>>>> Signed-off-by: Gavin Shan <gshan at redhat.com> >>>>> Acked-by: David Hildenbrand <david at redhat.com> >>>>> Acked-by: Jonathan Cameron <Jonathan.Cameron at huawei.com> >>>>> Acked-by: Michael S. Tsirkin <mst at redhat.com> >>>>> --- >>>>> v3: Pick ack-by tags from Jonathan and Michael >>>>> --- >>>>> drivers/virtio/Kconfig | 7 ++++--- >>>>> 1 file changed, 4 insertions(+), 3 deletions(-) >>>>> >>>>> diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig >>>>> index 34f80b7a8a64..74c8b0c7bc33 100644 >>>>> --- a/drivers/virtio/Kconfig >>>>> +++ b/drivers/virtio/Kconfig >>>>> @@ -106,7 +106,7 @@ config VIRTIO_BALLOON >>>>> config VIRTIO_MEM >>>>> tristate "Virtio mem driver" >>>>> default m >>>>> - depends on X86_64 >>>>> + depends on X86_64 || ARM64 >>>>> depends on VIRTIO >>>>> depends on MEMORY_HOTPLUG >>>>> depends on MEMORY_HOTREMOVE >>>>> @@ -116,8 +116,9 @@ config VIRTIO_MEM >>>>> This driver provides access to virtio-mem paravirtualized memory >>>>> devices, allowing to hotplug and hotunplug memory. >>>>> >>>>> - This driver was only tested under x86-64, but should theoretically >>>>> - work on all architectures that support memory hotplug and hotremove. >>>>> + This driver was only tested under x86-64 and arm64, but should >>>>> + theoretically work on all architectures that support memory hotplug >>>>> + and hotremove. >>>>> >>>> >>>> BTW isn't there a symbol saying "memory hotplug" that we can depend on? >>>> >> >> You mean >> >> depends on MEMORY_HOTPLUG >> depends on MEMORY_HOTREMOVE >> >> We still need a manual opt-in from architectures, because devil's in the >> detail. (e.g., memblock stuff we had to adjust) > > Is there any chance of documenting some of this here? The current comment makes it > look like it's just a question of whitelisting an architecture.I can send a patch to add more details. -- Thanks, David / dhildenb
Michael S. Tsirkin
2022-Feb-04 14:04 UTC
[PATCH v3] drivers/virtio: Enable virtio mem for ARM64
On Fri, Feb 04, 2022 at 02:29:39PM +0100, David Hildenbrand wrote:> On 04.02.22 14:24, Michael S. Tsirkin wrote: > > On Wed, Jan 19, 2022 at 09:35:05AM +0100, David Hildenbrand wrote: > >> On 19.01.22 08:46, Gavin Shan wrote: > >>> Hi Michael, > >>> > >>> On 1/19/22 3:39 PM, Michael S. Tsirkin wrote: > >>>> On Wed, Jan 19, 2022 at 09:05:51AM +0800, Gavin Shan wrote: > >>>>> This enables virtio-mem device support by allowing to enable the > >>>>> corresponding kernel config option (CONFIG_VIRTIO_MEM) on the > >>>>> architecture. > >>>>> > >>>>> Signed-off-by: Gavin Shan <gshan at redhat.com> > >>>>> Acked-by: David Hildenbrand <david at redhat.com> > >>>>> Acked-by: Jonathan Cameron <Jonathan.Cameron at huawei.com> > >>>>> Acked-by: Michael S. Tsirkin <mst at redhat.com> > >>>>> --- > >>>>> v3: Pick ack-by tags from Jonathan and Michael > >>>>> --- > >>>>> drivers/virtio/Kconfig | 7 ++++--- > >>>>> 1 file changed, 4 insertions(+), 3 deletions(-) > >>>>> > >>>>> diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig > >>>>> index 34f80b7a8a64..74c8b0c7bc33 100644 > >>>>> --- a/drivers/virtio/Kconfig > >>>>> +++ b/drivers/virtio/Kconfig > >>>>> @@ -106,7 +106,7 @@ config VIRTIO_BALLOON > >>>>> config VIRTIO_MEM > >>>>> tristate "Virtio mem driver" > >>>>> default m > >>>>> - depends on X86_64 > >>>>> + depends on X86_64 || ARM64 > >>>>> depends on VIRTIO > >>>>> depends on MEMORY_HOTPLUG > >>>>> depends on MEMORY_HOTREMOVE > >>>>> @@ -116,8 +116,9 @@ config VIRTIO_MEM > >>>>> This driver provides access to virtio-mem paravirtualized memory > >>>>> devices, allowing to hotplug and hotunplug memory. > >>>>> > >>>>> - This driver was only tested under x86-64, but should theoretically > >>>>> - work on all architectures that support memory hotplug and hotremove. > >>>>> + This driver was only tested under x86-64 and arm64, but should > >>>>> + theoretically work on all architectures that support memory hotplug > >>>>> + and hotremove. > >>>>> > >>>> > >>>> BTW isn't there a symbol saying "memory hotplug" that we can depend on? > >>>> > >> > >> You mean > >> > >> depends on MEMORY_HOTPLUG > >> depends on MEMORY_HOTREMOVE > >> > >> We still need a manual opt-in from architectures, because devil's in the > >> detail. (e.g., memblock stuff we had to adjust) > > > > Is there any chance of documenting some of this here? The current comment makes it > > look like it's just a question of whitelisting an architecture. > > I can send a patch to add more details.oks so that will be a patch on top?> -- > Thanks, > > David / dhildenb