On Tuesday, January 03, 2006 10:13 AM, Ewan Mellor <> wrote:
> On Sat, Dec 31, 2005 at 09:52:49AM +0000, Keir Fraser wrote:
>
>> How about add a new command XS_NEW_CONNECTION, taking a grant
>> reference and an event channel? This would then set up a new
>> inter-domain event channel and messaging memory page, and then
>> commands would no longer go via the kernel at all.
This is a bigger change than I was expecting, but sometimes (often ;-)
doing the right thing is harder than doing the easy thing. I'll start
working on this approach.
This also facilitates a useful follow-on change: modify XS_INTRODUCE to
take a grant reference instead of an mfn and use that as the command
(instead of XS_NEW_CONNECTION) to establish communication with the
userspace clients. This would have the additional benefit of not
requiring xenstored's domain to be privileged just to map pages for its
clients. Of course, it would mean altering the domain builder code to
create a grant reference for the xenbus page.
On Saturday, December 31, 2005 1:53 AM, Keir Fraser wrote:
> One drawback is it would then be very hard for the kernel to tell
> whether any xenstore transactions are in progress in user space. This
> is a problem since transaction state is not copied during
> save/restore.
> Either that needs to happen, or transactional xenstore code needs to
> handle 'spurious' failures at any point in a transaction (handle
> EAGAIN on any transactional read/write, not just on commit).
On Wednesday, January 04, 2006 2:38 AM, Keir Fraser wrote:
> On 3 Jan 2006, at 18:12, Ewan Mellor wrote:
>
>> Could Xenstored not simply "save up" the EAGAIN until the commit?
>> If a domain migrated in the middle of a transaction, then Xenstored
>> would see a transaction handle that was invalid for that connection.
>> In that case, it could simply ignore all writes until a commit, in
>> which case it would return EAGAIN, just as if the transaction had
>> seen a conflicting write.
>>
>> I think that forcing clients to handle EAGAIN for all messages, not
>> just commit, would be undesirable.
>
> The alternative is to allow the restored client to see inconsistent
> data. Currently we ensure that a transaction sees a consistent
> snapshot of the store by copying the database file at the start of a
> transaction. If we do not copy that snapshot as part of save/restore
> (we don't currently) then in-progress transactions in a restored guest
> cannot be guaranteed to see data consistent with their snapshot in
> later reads.
>
> Seems to me that is likely to have more subtle issues than simply
> returning EAGAIN and requiring the client to just have to deal with
> it. If the client has to be robust against seeing weird inconsistent
data
> then it is likely to have a bail-and-retry path for many transactional
> reads anyway. May as well make the issue explicit.
I think that I'll go with Keir's approach for the initial patch, since
it will be easy to detect the invalid transaction handle and just fail
all successive calls. I suspect that it would be both complex and
problematic to try to return meaningful data to a resumed client,
especially if you're just going to fail the transaction anyway (writes
could be dropped but reads would be an issue). Improvements could
always be added later.
Joseph Cihula
(Linux) Software Security Architect
Open Source Technology Center
Intel Corp.
*** These opinions are not necessarily those of my employer ***
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home