Re: [Xen-devel] [PATCH 3/5] v4v: Introduce VIRQ_V4V

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 31.05.12 at 17:07, Jean Guyader <jean.guyader@xxxxxxxxxx> wrote:
>--- a/xen/common/event_channel.c
>+++ b/xen/common/event_channel.c
>@@ -107,6 +107,7 @@ static int virq_is_global(uint32_t virq)
>     case VIRQ_TIMER:
>     case VIRQ_DEBUG:
>     case VIRQ_XENOPROF:
>+    case VIRQ_V4V:

Either the placement here is wrong (the vIRQ being per-vCPU), ...

>         rc = 0;
>         break;
>     case VIRQ_ARCH_0 ... VIRQ_ARCH_7:
>--- a/xen/include/public/xen.h
>+++ b/xen/include/public/xen.h
>@@ -157,7 +157,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
> #define VIRQ_CON_RING   8  /* G. (DOM0) Bytes received on console            
> */
> #define VIRQ_PCPU_STATE 9  /* G. (DOM0) PCPU state changed                   
> */
> #define VIRQ_MEM_EVENT  10 /* G. (DOM0) A memory event has occured           
> */
>-#define VIRQ_XC_RESERVED 11 /* G. Reserved for XenClient                     
>*/
>+#define VIRQ_V4V        11 /* G. V4V event has occurred                      
>*/

... or the comment here is (and was before). This is an ABI property,
end hence you can't really convert a vIRQ defined to be global to
a per-vCPU one. So if it turns out the comment was wrong, I would
argue whether the change here is really acceptable - our kernel,
for example, has built-in knowledge of which vIRQ-s are per-vCPU
(but of course this should be benign when the only consumer of the
vIRQ lives in userland; otoh, a userland consumer can hardly really
make use of a per-vCPU one).

Jan

> #define VIRQ_ENOMEM     12 /* G. (DOM0) Low on heap memory       */
> 
> /* Architecture-specific VIRQ definitions. */


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel