Re: Re: blktap: Sync with XCP, dropping zero-copy.

[Jeremy Fitzhardinge <jeremy@goop.org>]

On 11/15/2010 11:19 AM, Ian Campbell wrote:
> On Mon, 2010-11-15 at 18:27 +0000, Jeremy Fitzhardinge wrote:
>> Then we'd have a set of frames whose lifetimes are being determined by
>> some other subsystem.  We can either maintain a list of them and poll
>> waiting for them to become free, or just release them and let them be
>> managed by the normal kernel lifetime rules (which requires that the
>> memory attached to them be completely normal, of course). 
> GNTTABOP_unmap_and_replace is probably the answer to this? This is what
> netback uses (via gnttab_copy_grant_page) when it wants to copy and skb
> which has remained in flight for too long.
>
> Maybe this doesn't work since the memcpy and replace are not atomic and
> we don't have a lock to use, since we don't know which subsystem holds
> the reference. However it should work if we don't really care about the
> contents of the replacement too much, which I don't think we do in this
> case since the data could just as easily get clobbered by the userspace
> process which thinks the write has completed fully, in which case we
> just replace the grant mapping without bothering with the copy.

Well, if atomicity is important (and it is a relatively rare event), I
dare say Xen could de-schedule all the VCPUs a lot more efficiently than
we could run stop_machine() from within the kernel...

    J