[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [VTD][PATCH] Support intra-domain shared interrupt


  • To: "Han, Weidong" <weidong.han@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
  • Date: Wed, 07 Nov 2007 15:33:34 +0000
  • Cc: "Kay, Allen M" <allen.m.kay@xxxxxxxxx>
  • Delivery-date: Wed, 07 Nov 2007 07:34:30 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcgfbbYOsSWYB6MMQDuBGkYt+XjCJwAEwx4KAAASPxAAAXKGpgAAClDAAAJfMewAbWqM0AACgKoiAAAWh5AAAMMHUQ==
  • Thread-topic: [Xen-devel] [VTD][PATCH] Support intra-domain shared interrupt

Can you extend the test at line 750 in arch/x86/mm/shadow/multi.c with
... && !(mfn_valid(target_mfn)&&is_xen_heap_frame(mfn_to_page(target_mfn)))

And see if that fixes it? I suspect that the VLAPIC access page is mapped
uncacheable by HVM guests, and that uncacheability is getting passed through
to the shadow pte if the guest has pass-thru devices. We should not pass
thru cache attribute flags for xen heap pages as they should never be
involved in real I/O.

 -- Keir

On 7/11/07 15:16, "Han, Weidong" <weidong.han@xxxxxxxxx> wrote:

> Keir,
> 
> I found changeset 16331 breaks VT-d. When create guest with VT-d, qemu
> window is white, and we see following messages on serial console:
> 
> (XEN) intel-iommu.c:1374:d0 reassign_device-1:0:0- source = 0 target = 1
> (XEN) mm.c:684:d2 Attempt to change cache attributes of Xen heap page
> (XEN) mm.c:684:d2 Attempt to change cache attributes of Xen heap page
> (XEN) mm.c:684:d2 Attempt to change cache attributes of Xen heap page
> (XEN) mm.c:684:d2 Attempt to change cache attributes of Xen heap page
> (XEN) mm.c:684:d2 Attempt to change cache attributes of Xen heap page
> (XEN) mm.c:684:d2 Attempt to change cache attributes of Xen heap page
> (XEN) mm.c:684:d2 Attempt to change cache attributes of Xen heap page
> (XEN) mm.c:684:d2 Attempt to change cache attributes of Xen heap page
> (XEN) mm.c:684:d2 Attempt to change cache attributes of Xen heap page
> (XEN) printk: 2214196 messages suppressed.
> (XEN) mm.c:684:d2 Attempt to change cache attributes of Xen heap page
> (XEN) printk: 2510520 messages suppressed.
> (XEN) mm.c:684:d2 Attempt to change cache attributes of Xen heap page
> (XEN) printk: 2515634 messages suppressed.
> (XEN) mm.c:684:d2 Attempt to change cache attributes of Xen heap page
> (XEN) printk: 2510520 messages suppressed.
> (XEN) mm.c:684:d2 Attempt to change cache attributes of Xen heap page
> (XEN) printk: 2515634 messages suppressed.
> (XEN) mm.c:684:d2 Attempt to change cache attributes of Xen heap page
> (XEN) printk: 2525556 messages suppressed.
> (XEN) mm.c:684:d2 Attempt to change cache attributes of Xen heap page
> (XEN) printk: 2513768 messages suppressed.
> (XEN) mm.c:684:d2 Attempt to change cache attributes of Xen heap page
> (XEN) printk: 2510754 messages suppressed.
> 
> Keir Fraser wrote:
>> Yes, I'll slip this one in.
>> 
>>  K.
>> 
>> On 7/11/07 15:02, "Han, Weidong" <weidong.han@xxxxxxxxx> wrote:
>> 
>>> Keir, how about this intra-domain shared interrupt patch? Attached
>>> patch fixes memory leak issue and updates timeout function. Thanks.
>>> 
>>> -- Weidong
>>> 
>>> Keir Fraser wrote:
>>>> On 5/11/07 08:52, "Han, Weidong" <weidong.han@xxxxxxxxx> wrote:
>>>> 
>>>>> that situation two devices with different pyhsical IRQs getting
>>>>> aliased to the same guest GSI is hard to occur. And we need one
>>>>> guest GSI mapped to only one physical IRQ, or we can't know which
>>>>> device issues the guest GSI. Ideally, if we can make 1:1 mapping
>>>>> between guest GSI and physcial IRQ, the intra-domain shared
>>>>> interrupt can naturally handled by guest.
>>>> 
>>>> Ah, that's true. I suppose you can assign virtual devfn locations
>>>> for devices to purposely avoid aliasing in GSI space. What do you
>>>> do about aliasing into the ISA IRQ space?
>>>> 
>>>>  -- Keir



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.