RE: [Xen-devel] Xen-3.4 and FLR

["Cui, Dexuan" <dexuan.cui@xxxxxxxxx>]

In some cases (e.g., assigning device to HVM guest with iommu), we do need the 
co-assignment checking/constraint, while for PV guest, we may not need it if 
iommu is not used.

The trouble is: to give a generic solution, we must consider both PV guest and 
HVM guest, and actually I think it's not easy to make the code clean to fit 
every case.

Thanks,
-- Dexuan



-----Original Message-----
From: Carsten Schiers [mailto:carsten@xxxxxxxxxx] 
Sent: 2009?6?11? 18:03
To: Cui, Dexuan; xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: AW: [Xen-devel] Xen-3.4 and FLR

Hi Dexuan,

if I would be able to, I would. But unfortunately I only understood only 10% of
what is happening. 

As long as it's ok to patch it away if you don't need it, why not. I had the
feeling already that it's quite tricky. 

Thanks,
Carsten.

----- Originalnachricht -----
Von: "Cui, Dexuan" <dexuan.cui@xxxxxxxxx>
Gesendet: Don, 11.6.2009 11:39
An: Carsten Schiers <carsten@xxxxxxxxxx> ; xen-devel@xxxxxxxxxxxxxxxxxxx
Betreff: RE: [Xen-devel] Xen-3.4 and FLR

Hi Carsten,
In some cases (especially assigning device to PV guest without iommu), the 
current code in xend does have some known limitations/issues.
I even think there is not a "generic and clean" solution...
In the long run, new BIOS/device should support the standard PCIe FLR or PCI 
FLR so we can get rid of the issues.
At present I'm busy on something else and  I appreciate somebody could help to 
try to improve the current code. :-)

Thanks,
-- Dexuan



-----Original Message-----
From: Carsten Schiers [mailto:carsten@xxxxxxxxxx] 
Sent: 2009?6?11? 16:20
To: Cui, Dexuan; xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: AW: [Xen-devel] Xen-3.4 and FLR

Dexuan,
Stefan,

from my past experience, I can tell you that these boards with nForce chipsets 
like the one Stefan uses have all 3/4 PCI slots behind a PCI bridge. I own a
Gigabyte GA-M56S-S3.

Assuming that Stefan has only PV domains running, I can confirm that the patch,
which I included manually (due to some offsets) still works. 

I still would vote for some kind of option to disable the necessety of 
co-assignment
in cases where they are not necessary or wanted.

I am missing the knowledge to help, but I can imagine that there are cases in 
which 
it is mandatory (when I understood right, it's when VT-d is used), but maybe it 
is
usefull to have FLR support also, when you have HVM Domains running without VT-d
support. Is it usefull to have FLR implemented in a pure-PV environment, too? 

I attached the outputs of the commands, just in case it makes sense to have a 
look
at them.

BR,
Carsten.

----- Originalnachricht -----
Von: "Cui, Dexuan" <dexuan.cui@xxxxxxxxx>
Gesendet: Don, 11.6.2009 04:33
An: xen-devel@xxxxxxxxxxxxxxxxxxx
Betreff: RE: [Xen-devel] Xen-3.4 and FLR

Hi Stefan,
Are you assigning device to PV guest or HVM guest?
Can you attach the log files of "lspci -tv" and "lspci -xxx -vvv" on your host?

Thanks,
-- Dexuan


-----Original Message-----
From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Stefan Kuhne
Sent: 2009?6?11? 8:25
To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] Xen-3.4 and FLR

Hi,

i've upgrade from xen-3.3.1 (with flr disable patch) to xen-3.4.
How i've my old FLR problem, when i try to give an PCI-Card from a real
slot to a domU i get:
VmError: pci: 0000:01:0e.0 must be co-assigned to the same guest with
0000:01:09.0

When i've more than one PCI-Card in system xen will all PCI-Cards give
this domU till xen is by an onBoard device.
When i give an onBoard device to a domU i've no problem.

I've a Gigabyte GA-M52S-S3P in this system.

I'am involved in a Project (EisXen), there are many with the same
Problem on xen-3.3.1 without patch.
So, where does it come from?

Regads,
Stefan Kuhne










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

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