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: [Xci-devel] Porblem with disabling and then re-enabling a PT device

To: 'Tom Rotenberg' <tom.rotenberg@xxxxxxxxx>
Subject: RE: [Xci-devel] Porblem with disabling and then re-enabling a PT device in Windows
From: Kamala Narasimhan <Kamala.Narasimhan@xxxxxxxxxx>
Date: Wed, 25 Nov 2009 10:13:00 -0500
Accept-language: en-US
Acceptlanguage: en-US
Cc: "xci-devel@xxxxxxxxxxxxxxxxxxx" <xci-devel@xxxxxxxxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 25 Nov 2009 07:12:58 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <8686c3cd0911250621g7735507du4393721aac2aef05@xxxxxxxxxxxxxx>
List-archive: <http://lists.xensource.com/archives/html/xci-devel>
List-help: <mailto:xci-devel-request@lists.xensource.com?subject=help>
List-id: xci-devel.lists.xensource.com
List-post: <mailto:xci-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xci-devel>, <mailto:xci-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xci-devel>, <mailto:xci-devel-request@lists.xensource.com?subject=unsubscribe>
References: <8686c3cd0911250508i5937d100k2cae23816e450bde@xxxxxxxxxxxxxx> <5997D0BE578D47409D1EBD41DFD341F489F5F54E85@xxxxxxxxxxxxxxxxxxxxxxxxx> <8686c3cd0911250621g7735507du4393721aac2aef05@xxxxxxxxxxxxxx>
Sender: xci-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acpt2qcDUcOHex/nR+CmciIPjnV0mQAAkLzQ
Thread-topic: [Xci-devel] Porblem with disabling and then re-enabling a PT device in Windows
I shouldn't have suggested that you build without pciback; I got carried away 
trying to make it simple for you :-); Obviously you would need it and I should 
have stopped with suggesting that you tweak it.

Here is the thought process that led to my suggestion -

Clearly, that bit is getting changed as indicated in your log.  It is unlikely 
that the guest is triggering that change which makes pciback a potential 
candidate to suspect as it does change pci configuration space bits.  I need to 
add some tracing and look at the path of execution to answer some of your 
specific questions accurately and I won't be able to do that right now but I 
can give some context to help you based on what I have experienced in 
comparable situation and based on that I would say pciback is one place to 
suspect.  To be a bit more specific I would say look into 
pciback_enable_msi/pciback_disable_msi code, add some tracing there, observe 
whether or not that code path is taken when the device is disabled/reenabled 
within guest etc.  To reiterate, these are mere suggestions but looks plausible 
based on prior observations.

Kamala

> -----Original Message-----
> From: Tom Rotenberg [mailto:tom.rotenberg@xxxxxxxxx]
> Sent: Wednesday, November 25, 2009 9:22 AM
> To: Kamala Narasimhan
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx; xci-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xci-devel] Porblem with disabling and then re-enabling a
> PT device in Windows
> 
> I am not sure i undertand how to test it...
> 1) Avoid doing FLR for the device - isn';t that done only when
> building the domain? does that happen when i disable the device in
> domU?
> 2) Don't build pciback - and then, i won't bind the wlan device to
> pciback? and change the xend scripts which check for it?
> 3) Comment out the relevant code - which code??
> 
> I also don't understand, how could it be that the pciback device is
> "messing" with it? isn't it supposed to be in-active when the device
> is being used in PT?
> 
> Tom
> 
> On Wed, Nov 25, 2009 at 4:12 PM, Kamala Narasimhan
> <Kamala.Narasimhan@xxxxxxxxxx> wrote:
> > There is a chance pciback is changing the bit you are referring
> to.  To confirm that, just for testing purpose you might want to avoid
> FLR for that device or simply not build pciback or comment out relevant
> code in that module whichever is easier and see if that helps.  If it
> does, you can then look into fixing the problem the right way.
> >
> > Kamala
> >
> >> -----Original Message-----
> >> From: xci-devel-bounces@xxxxxxxxxxxxxxxxxxx [mailto:xci-devel-
> >> bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Tom Rotenberg
> >> Sent: Wednesday, November 25, 2009 8:09 AM
> >> To: xen-devel@xxxxxxxxxxxxxxxxxxx; xci-devel@xxxxxxxxxxxxxxxxxxx
> >> Subject: [Xci-devel] Porblem with disabling and then re-enabling a
> PT
> >> device in Windows
> >>
> >> Hi All,
> >>
> >> (This is a continuation to my previous mail, but since it looks like
> a
> >> different problem - i decided to open a new thread for it)
> >>
> >> ----
> >> Problem Description:
> >> ----
> >> I am doing pass-through of an Intel wireless LAN device to a Windows
> >> XP domU (my machine is Dell e6400), and it looks like it's working
> ok.
> >> Then, i disable the device using Windows device manager, and the
> >> device is now disabled, after that i re-enable the device, and
> Windows
> >> re-enables the device correctly. However, the wlan device seems to
> >> malfunction (it can't turn on the WiFi of the computer), and can't
> >> connect to wireless networks.
> >> I tried it, both with MSI translation on, and with MSI translation
> off
> >> - it doesn't matter.
> >>
> >> ----
> >> My analysis:
> >> ----
> >> 1) Well, taking a look at the real PCI config space, before disable
> >> and after the (last) enable, shows that the difference is at the
> Intx
> >> bit (read-only bit 3 at status register (offset 0x6) at the PCI
> config
> >> space). Before disable, that bit was 0, and after the last enable
> that
> >> bit was 1.
> >> This, according to my understanding, means that the device is
> >> asserting it's IntX , and probably waiting for someone to handle it,
> >> no?
> >>
> >> 2) When i tried to track when did this bit was changed - i added a
> >> code which in every PCI config read, checks if that bit was changed
> -
> >> and added a print when it changed. The proper lines in the qemu log
> >> looks like this:
> >> ...
> >> pt_pci_read_config: [00:01.0]: address=00f0 val=0x00000000 len=2
> >> ACPI PCI hotplug: read addr=0x10c6, val=0x0f.
> >> ACPI PCI hotplug: read addr=0x10c6, val=0x0f.
> >> pt_pci_read_config: TEST CODE: STATUS CHNAGED! OLD: 0x10, NEW: 0x18
> >> pt_pci_read_config: [00:01.0]: address=0000 val=0x00008086 len=2
> >> ...
> >>
> >> This implies that the bit was changed, about the same time that
> >> Windows tried to start using it (because, i assume that it tried
> using
> >> it, just after questioning the ACPI for the existence of the device).
> >> No?
> >>
> >>
> >> Can someone help me with this?
> >>
> >> (BTW - i am using Xen 3.4)
> >>
> >> Tom
> >>
> >> _______________________________________________
> >> Xci-devel mailing list
> >> Xci-devel@xxxxxxxxxxxxxxxxxxx
> >> http://lists.xensource.com/mailman/listinfo/xci-devel
> >

_______________________________________________
Xci-devel mailing list
Xci-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/mailman/listinfo/xci-devel