[virtio-comment] [PATCH v1] virtio-mem: minor clarification regarding read-access to unplugged blocks

[virtio-comment] [PATCH v1] virtio-mem: minor clarification regarding read-access to unplugged blocks

[David Hildenbrand]

Let's clarify that we don't expect all DMA to work with unplugged blocks.
We really only give guarantees when reading from unplugged memory blocks
via the CPU, e.g., as done by Linux when creating a system dump via
kdump: the new kernel will copy the content of the old (crashed) kernel
via the CPU to user space, from where it will find its final destination
inside the dump file. Note that dumping via makedumpfile under Linux will
avoid reading unplugged blocks completely.

This is a preparation for device passthrough to VMs, whereby such
dedicated devices might not be able to read from unplugged memory blocks.

Let's document that this scenario is possible, and why this handling is
in place at all.

Cc: teawater <teawaterz@linux.alibaba.com>
Cc: Marek Kedzierski <mkedzier@redhat.com>
Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
---
 virtio-mem.tex | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/virtio-mem.tex b/virtio-mem.tex
index 85cfb61..62a1d02 100644
--- a/virtio-mem.tex
+++ b/virtio-mem.tex
@@ -246,8 +246,13 @@ \subsection{Device Operation}\label{sec:Device Types / Memory Device / Device Op
 
 The device MUST NOT change the content of plugged memory blocks.
 
-The device MUST allow to read from unplugged memory blocks inside
-the usable device-managed region.
+The device MUST allow the CPU to read from unplugged memory blocks inside
+the usable device-managed region. \footnote{To allow for simplified dumping of
+memory. The CPU is expected to copy such memory to another location before
+starting DMA.}
+
+The device MAY allow to read from unplugged memory blocks inside the
+usable device-managed region via DMA.
 
 The device MAY allow to read from unplugged memory blocks outside
 the usable device-managed region.
-- 
2.26.2


This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/

[virtio-comment] Re: [PATCH v1] virtio-mem: minor clarification regarding read-access to unplugged blocks

[Cornelia Huck]

On Mon, 16 Nov 2020 20:16:29 +0100
David Hildenbrand <david@redhat.com> wrote:

> Let's clarify that we don't expect all DMA to work with unplugged blocks.
> We really only give guarantees when reading from unplugged memory blocks
> via the CPU, e.g., as done by Linux when creating a system dump via
> kdump: the new kernel will copy the content of the old (crashed) kernel
> via the CPU to user space, from where it will find its final destination
> inside the dump file. Note that dumping via makedumpfile under Linux will
> avoid reading unplugged blocks completely.
> 
> This is a preparation for device passthrough to VMs, whereby such
> dedicated devices might not be able to read from unplugged memory blocks.
> 
> Let's document that this scenario is possible, and why this handling is
> in place at all.
> 
> Cc: teawater <teawaterz@linux.alibaba.com>
> Cc: Marek Kedzierski <mkedzier@redhat.com>
> Cc: Michael S. Tsirkin <mst@redhat.com>
> Cc: Cornelia Huck <cohuck@redhat.com>
> Signed-off-by: David Hildenbrand <david@redhat.com>
> ---
>  virtio-mem.tex | 9 +++++++--
>  1 file changed, 7 insertions(+), 2 deletions(-)

Looks reasonable to me.

Acked-by: Cornelia Huck <cohuck@redhat.com>


This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/

Re: [virtio-comment] Re: [PATCH v1] virtio-mem: minor clarification regarding read-access to unplugged blocks

[David Hildenbrand]

On 20.11.20 16:13, Cornelia Huck wrote:
> On Mon, 16 Nov 2020 20:16:29 +0100
> David Hildenbrand <david@redhat.com> wrote:
> 
>> Let's clarify that we don't expect all DMA to work with unplugged blocks.
>> We really only give guarantees when reading from unplugged memory blocks
>> via the CPU, e.g., as done by Linux when creating a system dump via
>> kdump: the new kernel will copy the content of the old (crashed) kernel
>> via the CPU to user space, from where it will find its final destination
>> inside the dump file. Note that dumping via makedumpfile under Linux will
>> avoid reading unplugged blocks completely.
>>
>> This is a preparation for device passthrough to VMs, whereby such
>> dedicated devices might not be able to read from unplugged memory blocks.
>>
>> Let's document that this scenario is possible, and why this handling is
>> in place at all.
>>
>> Cc: teawater <teawaterz@linux.alibaba.com>
>> Cc: Marek Kedzierski <mkedzier@redhat.com>
>> Cc: Michael S. Tsirkin <mst@redhat.com>
>> Cc: Cornelia Huck <cohuck@redhat.com>
>> Signed-off-by: David Hildenbrand <david@redhat.com>
>> ---
>>  virtio-mem.tex | 9 +++++++--
>>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> Looks reasonable to me.
> 
> Acked-by: Cornelia Huck <cohuck@redhat.com>

Thanks!

I assume I'll need a github issue etc. to get this in, right?

-- 
Thanks,

David / dhildenb


This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/

Re: [virtio-comment] Re: [PATCH v1] virtio-mem: minor clarification regarding read-access to unplugged blocks

[Cornelia Huck]

On Fri, 27 Nov 2020 11:39:50 +0100
David Hildenbrand <david@redhat.com> wrote:

> On 20.11.20 16:13, Cornelia Huck wrote:
> > On Mon, 16 Nov 2020 20:16:29 +0100
> > David Hildenbrand <david@redhat.com> wrote:
> >   
> >> Let's clarify that we don't expect all DMA to work with unplugged blocks.
> >> We really only give guarantees when reading from unplugged memory blocks
> >> via the CPU, e.g., as done by Linux when creating a system dump via
> >> kdump: the new kernel will copy the content of the old (crashed) kernel
> >> via the CPU to user space, from where it will find its final destination
> >> inside the dump file. Note that dumping via makedumpfile under Linux will
> >> avoid reading unplugged blocks completely.
> >>
> >> This is a preparation for device passthrough to VMs, whereby such
> >> dedicated devices might not be able to read from unplugged memory blocks.
> >>
> >> Let's document that this scenario is possible, and why this handling is
> >> in place at all.
> >>
> >> Cc: teawater <teawaterz@linux.alibaba.com>
> >> Cc: Marek Kedzierski <mkedzier@redhat.com>
> >> Cc: Michael S. Tsirkin <mst@redhat.com>
> >> Cc: Cornelia Huck <cohuck@redhat.com>
> >> Signed-off-by: David Hildenbrand <david@redhat.com>
> >> ---
> >>  virtio-mem.tex | 9 +++++++--
> >>  1 file changed, 7 insertions(+), 2 deletions(-)  
> > 
> > Looks reasonable to me.
> > 
> > Acked-by: Cornelia Huck <cohuck@redhat.com>  
> 
> Thanks!
> 
> I assume I'll need a github issue etc. to get this in, right?
> 

Yes; just open the issue, point to this patch in the archives, and
reply with the issue here.

(I don't think this is trivial enough to push without voting.)


This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/

Re: [virtio-comment] Re: [PATCH v1] virtio-mem: minor clarification regarding read-access to unplugged blocks

[David Hildenbrand]

On 27.11.20 12:02, Cornelia Huck wrote:
> On Fri, 27 Nov 2020 11:39:50 +0100
> David Hildenbrand <david@redhat.com> wrote:
> 
>> On 20.11.20 16:13, Cornelia Huck wrote:
>>> On Mon, 16 Nov 2020 20:16:29 +0100
>>> David Hildenbrand <david@redhat.com> wrote:
>>>   
>>>> Let's clarify that we don't expect all DMA to work with unplugged blocks.
>>>> We really only give guarantees when reading from unplugged memory blocks
>>>> via the CPU, e.g., as done by Linux when creating a system dump via
>>>> kdump: the new kernel will copy the content of the old (crashed) kernel
>>>> via the CPU to user space, from where it will find its final destination
>>>> inside the dump file. Note that dumping via makedumpfile under Linux will
>>>> avoid reading unplugged blocks completely.
>>>>
>>>> This is a preparation for device passthrough to VMs, whereby such
>>>> dedicated devices might not be able to read from unplugged memory blocks.
>>>>
>>>> Let's document that this scenario is possible, and why this handling is
>>>> in place at all.
>>>>
>>>> Cc: teawater <teawaterz@linux.alibaba.com>
>>>> Cc: Marek Kedzierski <mkedzier@redhat.com>
>>>> Cc: Michael S. Tsirkin <mst@redhat.com>
>>>> Cc: Cornelia Huck <cohuck@redhat.com>
>>>> Signed-off-by: David Hildenbrand <david@redhat.com>
>>>> ---
>>>>  virtio-mem.tex | 9 +++++++--
>>>>  1 file changed, 7 insertions(+), 2 deletions(-)  
>>>
>>> Looks reasonable to me.
>>>
>>> Acked-by: Cornelia Huck <cohuck@redhat.com>  
>>
>> Thanks!
>>
>> I assume I'll need a github issue etc. to get this in, right?
>>
> 
> Yes; just open the issue, point to this patch in the archives, and
> reply with the issue here.
> 
> (I don't think this is trivial enough to push without voting.)
> 

Makes sense. I'll wait a bit more. Thanks!

-- 
Thanks,

David / dhildenb


This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/

Re: [virtio-comment] Re: [PATCH v1] virtio-mem: minor clarification regarding read-access to unplugged blocks

[Cornelia Huck]

On Wed, 2 Dec 2020 10:25:16 +0100
David Hildenbrand <david@redhat.com> wrote:

> On 27.11.20 12:02, Cornelia Huck wrote:
> > On Fri, 27 Nov 2020 11:39:50 +0100
> > David Hildenbrand <david@redhat.com> wrote:
> >   
> >> On 20.11.20 16:13, Cornelia Huck wrote:  
> >>> On Mon, 16 Nov 2020 20:16:29 +0100
> >>> David Hildenbrand <david@redhat.com> wrote:
> >>>     
> >>>> Let's clarify that we don't expect all DMA to work with unplugged blocks.
> >>>> We really only give guarantees when reading from unplugged memory blocks
> >>>> via the CPU, e.g., as done by Linux when creating a system dump via
> >>>> kdump: the new kernel will copy the content of the old (crashed) kernel
> >>>> via the CPU to user space, from where it will find its final destination
> >>>> inside the dump file. Note that dumping via makedumpfile under Linux will
> >>>> avoid reading unplugged blocks completely.
> >>>>
> >>>> This is a preparation for device passthrough to VMs, whereby such
> >>>> dedicated devices might not be able to read from unplugged memory blocks.
> >>>>
> >>>> Let's document that this scenario is possible, and why this handling is
> >>>> in place at all.
> >>>>
> >>>> Cc: teawater <teawaterz@linux.alibaba.com>
> >>>> Cc: Marek Kedzierski <mkedzier@redhat.com>
> >>>> Cc: Michael S. Tsirkin <mst@redhat.com>
> >>>> Cc: Cornelia Huck <cohuck@redhat.com>
> >>>> Signed-off-by: David Hildenbrand <david@redhat.com>
> >>>> ---
> >>>>  virtio-mem.tex | 9 +++++++--
> >>>>  1 file changed, 7 insertions(+), 2 deletions(-)    
> >>>
> >>> Looks reasonable to me.
> >>>
> >>> Acked-by: Cornelia Huck <cohuck@redhat.com>    
> >>
> >> Thanks!
> >>
> >> I assume I'll need a github issue etc. to get this in, right?
> >>  
> > 
> > Yes; just open the issue, point to this patch in the archives, and
> > reply with the issue here.
> > 
> > (I don't think this is trivial enough to push without voting.)
> >   
> 
> Makes sense. I'll wait a bit more. Thanks!
> 

I think you can just go ahead and request a vote... no need to wait
further IMHO.


This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/

Re: [virtio-comment] [PATCH v1] virtio-mem: minor clarification regarding read-access to unplugged blocks

[David Hildenbrand]

On 16.11.20 20:16, David Hildenbrand wrote:
> Let's clarify that we don't expect all DMA to work with unplugged blocks.
> We really only give guarantees when reading from unplugged memory blocks
> via the CPU, e.g., as done by Linux when creating a system dump via
> kdump: the new kernel will copy the content of the old (crashed) kernel
> via the CPU to user space, from where it will find its final destination
> inside the dump file. Note that dumping via makedumpfile under Linux will
> avoid reading unplugged blocks completely.
> 
> This is a preparation for device passthrough to VMs, whereby such
> dedicated devices might not be able to read from unplugged memory blocks.
> 
> Let's document that this scenario is possible, and why this handling is
> in place at all.
> 
> Cc: teawater <teawaterz@linux.alibaba.com>
> Cc: Marek Kedzierski <mkedzier@redhat.com>
> Cc: Michael S. Tsirkin <mst@redhat.com>
> Cc: Cornelia Huck <cohuck@redhat.com>
> Signed-off-by: David Hildenbrand <david@redhat.com>
> ---
>  virtio-mem.tex | 9 +++++++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/virtio-mem.tex b/virtio-mem.tex
> index 85cfb61..62a1d02 100644
> --- a/virtio-mem.tex
> +++ b/virtio-mem.tex
> @@ -246,8 +246,13 @@ \subsection{Device Operation}\label{sec:Device Types / Memory Device / Device Op
>  
>  The device MUST NOT change the content of plugged memory blocks.
>  
> -The device MUST allow to read from unplugged memory blocks inside
> -the usable device-managed region.
> +The device MUST allow the CPU to read from unplugged memory blocks inside
> +the usable device-managed region. \footnote{To allow for simplified dumping of
> +memory. The CPU is expected to copy such memory to another location before
> +starting DMA.}
> +
> +The device MAY allow to read from unplugged memory blocks inside the
> +usable device-managed region via DMA.
>  
>  The device MAY allow to read from unplugged memory blocks outside
>  the usable device-managed region.
> 

Requesting a vote, thanks!

Fixes: https://github.com/oasis-tcs/virtio-spec/issues/91

-- 
Thanks,

David / dhildenb


This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/