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

[Xen-devel] Re: xen dependant on pcpu 0 ?



Wednesday, October 13, 2010, 5:26:27 PM, you wrote:

>>>> On 13.10.10 at 17:03, Sander Eikelenboom <linux@xxxxxxxxxxxxxx> wrote:
>> Err yes i'm nor a kernel nor a xen hacker so i'm just trying not to speak 
>> complete gibberish :-)
>> Well since the device when seized by pciback on boot, seems to be assigned 
>> to dom0 and therefore d=0, the
>>                for_each_domain(d)
>>                      if ( !paging_mode_translate(d) &&
>>                           (iomem_access_permitted(d, dev->msix_table.first,
>>                                                  dev->msix_table.last) ||
>>                            iomem_access_permitted(d, dev->msix_pba.first,
>>                                                   dev->msix_pba.last)) )
>>                          break;
>> 
>> part seems never to be run, because a device seems to allways be assigned to 
>> a domain.

> That code fragment sits inside a if (!d), i.e. if we can easily tell
> (by just looking at dev->domain) which domain owns the device.

>> So if it seems to be never run ... why is it there ?

> You're probably more after the subsequent if (d) with the comment
> somewhat confusing you in its body - again, the function gets
> executed (or is supposed to) when a domain enables MSI-X on the
> device. At that point, dev->domain should be non-NULL (and
> different from dom0), so the body (if there really was one) would
> get executed.

Thx for you patience .. just one more time ...
I saw a mistake in my explanation, i didn't mean d=0, but in my case (fresh 
boot, first time domain with passthrough is started) d is not NULL and 
d->domain_id = 0
So it seems it thinks it's still assigned to dom0 when the MSI-X gets enabled ?
But this all does get triggered when the domU is started to which the domain is 
passed through, and yes it enables MSI-X (when i look at lspci or 
/proc/interrupts in the domU)
but d->domain_id results in "0" and not in the domain id of domU.
So if in this case the code in ( !d ) should have been run, it didn't (have put 
a printk there to be sure)

You were right that it didn't fix my freeze problem, although the RCU detected 
CPU stall was now followed by the beginning of a trace although it doesn't 
provide much more info.
I attached a photo of it.

--

Sander

> Jan




-- 
Best regards,
 Sander                            mailto:linux@xxxxxxxxxxxxxx

Attachment: SAM_0480.JPG
Description: JPEG image

_______________________________________________
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®.