Re: [Xen-devel] [PATCH 2/3] Handle GNTST_eagain in kernel drivers

[Adin Scannell <adin@xxxxxxxxxxxxxxx>]

On Sat, Dec 17, 2011 at 9:30 AM, Konrad Rzeszutek Wilk
<konrad@xxxxxxxxxx> wrote:
>> +#define gnttab_check_GNTST_eagain_while(__HCop, __HCarg_p)                 
>>                   >
> So why does this have to be a macro? What is the advantage of that
> versus making this a function?

I just wanted to minimize changes in the patch from the known XCP
version.  I'm personally not a fan of big macros like this.

> So why msleep? Why not go for a proper yield? Call the safe_halt()
> function?

Yes, this is something that should be revisited.

Since it looks like Daniel's HVM patches are going to conflict with
this anyways, I'll revisit this patch independently from the other two
and see what I can do about making it nicer and addressing the other
bits of feedback you've given.

> Use GNTTABOP_error_msgs. Also should we continue? What is the
> impact if we do continue? The times this is hit is if the status
> is not GNTS_okay and if it is not GNTS_eagain - so what are the
> situations in which this happens and what can the domain do
> to recover? Should there be some helpfull message instead of
> just "gnt status: X" ?

In all the cases this macro is called, the caller still needs to check
op.status and handle any errors appropriately.  The point of the macro
is to reasonably get you from eagain => !eagain, whatever the result
may be.  If I turn this into a function, those semantics will still
apply.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel