[PATCH] Allow xen to share device with domain (RE: [PATCH] RE: [Xen-ia64-devel] xencons interrupt problem)

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

Hi, Alex,
        Attached is an updated patch on top of yours, to address issues 
found by far. Please review and check whether working on your box, 
and I only did simple validation on my box since adding logic doesn't 
affect boxes out of such scenario.

        A major change is to convert into a mutual mapping between xen 
vector and guest vector, and thus to address injection and EOI issues.

Signed-off-by Alex Williamson <alex.williamson@xxxxxx>
Signed-off-by Kevin Tian <kevin.tian@xxxxxxxxx>

Thanks,
Kevin

>-----Original Message-----
>From: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
>[mailto:xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of
>Tian, Kevin
>Sent: 2006年7月3日 13:34
>To: Alex Williamson
>Cc: xen-ia64-devel
>Subject: RE: [PATCH] RE: [Xen-ia64-devel] xencons interrupt problem
>
>>From: Alex Williamson [mailto:alex.williamson@xxxxxx]
>>Sent: 2006年7月1日 2:50
>>
>>   I have something working, please tell me what you think.
>Modifying
>>assign_irq_vector() to pass in a GSI seemed rather intrusive to the
>>guest, so I took a different approach.  Instead I recognize the guest
>>trying to overwrite a Xen owned vector, store the guest vector in an
>>array and set it up as a "Xen redirect" vector.  These vectors are
>>serviced from __do_IRQ after the Xen handler.  There is only one
>>redirect vector allowed per Xen vector, but that seems sufficient at
>>this point.  This allows full use of both the PCI UART (owned by Xen)
>>and the PCI NIC (owned by the guest) sharing a physical RTE.  Let
>me
>>know if you think this approach is acceptable.  Thanks,
>>
>>      Alex
>>
>>Signed-off-by: Alex Williamson <alex.williamson@xxxxxx>
>
>Hi, Alex,
>       The idea is basically good, but I do see several issues with your
>patch as following:
>
>1.
>out:
>+      if (guest_vector[irq].enabled) {
>+              irq_desc_t *guest_desc = irq_desc + guest_vector[irq].vector;
>+
>+              if (likely(guest_desc->status & IRQ_GUEST)) {
>+                      spin_lock(&guest_desc->lock);
>+                      __do_IRQ_guest(guest_vector[irq].vector);
>+                      spin_unlock(&guest_desc->lock);
>+              }
>+      }
>
>Ack() and End() are always been issued before and after above code
>piece, which is not desired for devices owned by guest since
>__do_IRQ_guest only sets pending event bit without wait and guest
>hasn't got chance to handle the irq. EOI is only issued when guest
>hypercalls to notify.
>
>2. pirq_guest_eoi needs to convert guest vector to xen vector and then
>to issue real end method under xen vector. Maybe a reverse array is
>required here for performance
>
>3. Same conversion is also required in pirq_guest_unbind, to flush
>pending irqs.
>
>4. Add your new hw interrupt controller type in pirq_acktype which
>decides whether guest EOI notification is required
>
>5. For change in iosapic_guest_write, we shouldn't warning when
>guest_vector[xen_vector].vector exists since it's possible for guest
>to mask/unmask existing RTE entry. We can only warn when existing
>vector doesn't match new rte value.
>
>6. I'd like to see a comment to emphasize so-called guest vector
>actually occupies a vector in xen vector space, which means such
>xen-guest shared irq line always consumes two xen vectors. Or else
>it's ambiguous a bit.
>
>Thanks
>Kevins
>
>_______________________________________________
>Xen-ia64-devel mailing list
>Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>http://lists.xensource.com/xen-ia64-devel

Attachment: xen_irq_redirect_new.patch
Description: xen_irq_redirect_new.patch

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