[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] PV drivers and zero copying

Hi, Paul!

On 07/31/2017 12:03 PM, Paul Durrant wrote:
-----Original Message-----
Comparison for display use-case

1 Number of grant references used
1-1 grant references: nr_pages
1-2 GNTTABOP_transfer: nr_pages
1-3 XENMEM_exchange: not an option

2 Effect of DomU crash on Dom0 (its mapped pages)
2-1 grant references: pages can be unmapped by Dom0, Dom0 is fully
2-2 GNTTABOP_transfer: pages will be returned to the Hypervisor, lost
for Dom0
2-3 XENMEM_exchange: not an option

3 Security issues from sharing Dom0 pages to DomU
1-1 grant references: none
1-2 GNTTABOP_transfer: none
1-3 XENMEM_exchange: not an option

At the moment approach 1 with granted references seems to be a winner for
sharing buffers both ways, e.g. Dom0 -> DomU and DomU -> Dom0.


I would like to get some feedback from the community on which approach
is more
suitable for sharing large buffers and to have a clear vision on cons
and pros
of each one: please feel free to add other metrics I missed and correct
the ones
I commented on.  I would appreciate help on comparing approaches 2 and 3
as I
have little knowledge of these APIs (2 seems to be addressed by
Christopher, and
3 seems to be relevant to what Konrad/Stefano do WRT SWIOTLB).


   I once implemented a scheme where network frontends used memory granted from 
backends and this hit quite a few problems:

- If domU is allowed to grant map memory from dom0, there is not currently a 
way to forcibly take it back (so I don't think you're quite correct in 2-1 
above... but I may have missed something).
This is where I was not 100% confident, so you seem to be right here.
  Hence the domU can hold dom0's memory to ransom.
Yes, this is the problem
  (In the network case this was avoided by using grant table v2 'copy-only' 
- If you end up having to grant buffers which do not originate in dom0 (i.e. they were 
grant mapped from another domU) then this creates similar problems with one domU 
holding another domU's memory to ransom, even when using copy-only grants. I 
don’t think this would be an issue in your use-case.
In our use-cases we will only share from Dom0 to DomU in case Dom0 is 1:1 mapped
Otherwise, HW should be capable of dealing with non-contiguous memory
- Currently the default grant table size is 32 pages and it may not take that 
many guests using a protocol where dom0 grants memory to domU to exhaust dom0's 
grant table
Yes, I know about this limitation, thank you
  (depending on how many grants-per-domU the protocol allows). If you're 
intending to grant large buffers then you may need quite a few grants (since 
they are per-4k-chunk) to do this, so you might run into this limit.


Thank you for comments,
so in both cases (with grant refs or memory transfer) there is no way to cleanly recover from DomU crash (either grants cannot be returned or memory goes to the
hypervisor, not Dom0).
Is this correct?

Thank you,

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.