Displaying 11 results from an estimated 11 matches for "5f1f79bbc9e26".
Did you mean:
5f1f79bbc9e26f
2020 Jun 11
2
[PATCH v1] virtio-mem: add memory via add_memory_driver_managed()
...f tip as the results are sometimes kind of
> random.
Right, I just wanted to get this out early so we can discuss how to proceed.
> And let's add a Fixes: tag as well, this way people will remember to
> pick this.
> Makes sense?
Yes, it's somehow a fix (for kexec). So
Fixes: 5f1f79bbc9e26 ("virtio-mem: Paravirtualized memory hotplug")
I can respin after -rc1 with the commit id fixed as noted by Pankaj.
Just let me know what you prefer.
Thanks!
--
Thanks,
David / dhildenb
2020 Jun 11
2
[PATCH v1] virtio-mem: add memory via add_memory_driver_managed()
...f tip as the results are sometimes kind of
> random.
Right, I just wanted to get this out early so we can discuss how to proceed.
> And let's add a Fixes: tag as well, this way people will remember to
> pick this.
> Makes sense?
Yes, it's somehow a fix (for kexec). So
Fixes: 5f1f79bbc9e26 ("virtio-mem: Paravirtualized memory hotplug")
I can respin after -rc1 with the commit id fixed as noted by Pankaj.
Just let me know what you prefer.
Thanks!
--
Thanks,
David / dhildenb
2020 Jun 11
1
[PATCH v1] virtio-mem: add memory via add_memory_driver_managed()
...t wanted to get this out early so we can discuss how to proceed.
>>
>>> And let's add a Fixes: tag as well, this way people will remember to
>>> pick this.
>>> Makes sense?
>>
>> Yes, it's somehow a fix (for kexec). So
>>
>> Fixes: 5f1f79bbc9e26 ("virtio-mem: Paravirtualized memory hotplug")
>>
>> I can respin after -rc1 with the commit id fixed as noted by Pankaj.
>> Just let me know what you prefer.
>>
>> Thanks!
>
> Some once this commit is in Linus' tree, please ping me.
It already...
2020 Jun 08
4
[PATCH] virtio_mem: prevent overflow with subblock size
...involving it
can overflow. Rather than try to catch all instances of that,
let's tweak block size to 64 bit.
It ripples through UAPI which is an ABI change, but it's not too late to
make it, and it will allow supporting >4Gbyte blocks while might
become necessary down the road.
Fixes: 5f1f79bbc9e26 ("virtio-mem: Paravirtualized memory hotplug")
Signed-off-by: Michael S. Tsirkin <mst at redhat.com>
---
drivers/virtio/virtio_mem.c | 14 +++++++-------
include/uapi/linux/virtio_mem.h | 4 ++--
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/virtio/vir...
2020 Jun 08
4
[PATCH] virtio_mem: prevent overflow with subblock size
...involving it
can overflow. Rather than try to catch all instances of that,
let's tweak block size to 64 bit.
It ripples through UAPI which is an ABI change, but it's not too late to
make it, and it will allow supporting >4Gbyte blocks while might
become necessary down the road.
Fixes: 5f1f79bbc9e26 ("virtio-mem: Paravirtualized memory hotplug")
Signed-off-by: Michael S. Tsirkin <mst at redhat.com>
---
drivers/virtio/virtio_mem.c | 14 +++++++-------
include/uapi/linux/virtio_mem.h | 4 ++--
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/virtio/vir...
2020 Jun 11
0
[PATCH v1] virtio-mem: add memory via add_memory_driver_managed()
...ndom.
>
> Right, I just wanted to get this out early so we can discuss how to proceed.
>
> > And let's add a Fixes: tag as well, this way people will remember to
> > pick this.
> > Makes sense?
>
> Yes, it's somehow a fix (for kexec). So
>
> Fixes: 5f1f79bbc9e26 ("virtio-mem: Paravirtualized memory hotplug")
>
> I can respin after -rc1 with the commit id fixed as noted by Pankaj.
> Just let me know what you prefer.
>
> Thanks!
Some once this commit is in Linus' tree, please ping me.
> --
> Thanks,
>
> David /...
2020 Jun 08
0
[PATCH] virtio_mem: prevent overflow with subblock size
...-hypervisor, who's already implementing this
protocol upstream (ccing Hui).
https://github.com/cloud-hypervisor/cloud-hypervisor/blob/master/vm-virtio/src/mem.rs
(blocks in the gigabyte range were never the original intention of
virtio-mem, but I am not completely opposed to that)
> Fixes: 5f1f79bbc9e26 ("virtio-mem: Paravirtualized memory hotplug")
> Signed-off-by: Michael S. Tsirkin <mst at redhat.com>
> ---
> drivers/virtio/virtio_mem.c | 14 +++++++-------
> include/uapi/linux/virtio_mem.h | 4 ++--
> 2 files changed, 9 insertions(+), 9 deletions(-)
>
&...
2020 Jun 08
2
[PATCH] virtio_mem: prevent overflow with subblock size
...thub.com/cloud-hypervisor/cloud-hypervisor/blob/master/vm-virtio/src/mem.rs
>
> (blocks in the gigabyte range were never the original intention of
> virtio-mem, but I am not completely opposed to that)
So in that case, can you code up validation in the probe function?
> > Fixes: 5f1f79bbc9e26 ("virtio-mem: Paravirtualized memory hotplug")
> > Signed-off-by: Michael S. Tsirkin <mst at redhat.com>
> > ---
> > drivers/virtio/virtio_mem.c | 14 +++++++-------
> > include/uapi/linux/virtio_mem.h | 4 ++--
> > 2 files changed, 9 insertions(+...
2020 Jun 08
2
[PATCH] virtio_mem: prevent overflow with subblock size
...thub.com/cloud-hypervisor/cloud-hypervisor/blob/master/vm-virtio/src/mem.rs
>
> (blocks in the gigabyte range were never the original intention of
> virtio-mem, but I am not completely opposed to that)
So in that case, can you code up validation in the probe function?
> > Fixes: 5f1f79bbc9e26 ("virtio-mem: Paravirtualized memory hotplug")
> > Signed-off-by: Michael S. Tsirkin <mst at redhat.com>
> > ---
> > drivers/virtio/virtio_mem.c | 14 +++++++-------
> > include/uapi/linux/virtio_mem.h | 4 ++--
> > 2 files changed, 9 insertions(+...
2020 Jun 11
2
[PATCH v1] virtio-mem: add memory via add_memory_driver_managed()
Virtio-mem managed memory is always detected and added by the virtio-mem
driver, never using something like the firmware-provided memory map.
This is the case after an ordinary system reboot, and has to be guaranteed
after kexec. Especially, virtio-mem added memory resources can contain
inaccessible parts ("unblocked memory blocks"), blindly forwarding them
to a kexec kernel is
2020 Jun 11
2
[PATCH v1] virtio-mem: add memory via add_memory_driver_managed()
Virtio-mem managed memory is always detected and added by the virtio-mem
driver, never using something like the firmware-provided memory map.
This is the case after an ordinary system reboot, and has to be guaranteed
after kexec. Especially, virtio-mem added memory resources can contain
inaccessible parts ("unblocked memory blocks"), blindly forwarding them
to a kexec kernel is