WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] irq_guest_eoi_timer interaction with MSI

To: Jan Beulich <jbeulich@xxxxxxxxxx>
Subject: Re: [Xen-devel] irq_guest_eoi_timer interaction with MSI
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Mon, 24 Nov 2008 17:02:47 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 24 Nov 2008 09:03:17 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <492AE5B6.76E4.0078.0@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AclOVnmJuDDKALpJEd268QAX8io7RQ==
Thread-topic: [Xen-devel] irq_guest_eoi_timer interaction with MSI
User-agent: Microsoft-Entourage/11.4.0.080122
On 24/11/08 16:34, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:

> Perhaps the other way around: Make PHYSDEVOP_eoi imply an unmask,
> as that's what is always happening (whereas not every unmask also wants
> an EOI to be signaled). Below is a draft (compile-tested only) patch that,
> before coding the guest side, I'd appreciate to get comments on -
> especially if it appears reasonable to be done that way, if it meets your
> naming and coding preferences (I'm pretty sure it won't), and of course
> whether it's obviously broken in some respect.

I don't care which way round you do it (PHYSDEVOP_eoi implies unmask, or
vice versa) although you had just about convinced me that you should do it
the other way round to how you've chosen. I don't really mind either way
though.

The fixmap stuff is a bit ugly and I would just have done a
map_domain_page_global() for 32-bit Xen (good enough as far as I'm
concerned). I'm not dead set against your approach if you like it very much,
though.

Setting the need-a-hypercall bit looks racey. Don't you need to set the bit,
then check the guest didn't unmask meanwhile?

 -- Keir



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