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

[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