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] Move some of the PCI device manage/control into pciback?

To: 'Keir Fraser' <keir.fraser@xxxxxxxxxxxxx>, "'xen-devel@xxxxxxxxxxxxxxxxxxx'" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] Move some of the PCI device manage/control into pciback?
From: "Cui, Dexuan" <dexuan.cui@xxxxxxxxx>
Date: Thu, 15 Jan 2009 11:09:21 +0800
Accept-language: zh-CN, en-US
Acceptlanguage: zh-CN, en-US
Cc:
Delivery-date: Wed, 14 Jan 2009 19:09:58 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <EADF0A36011179459010BDF5142A4575046C2B8E@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <EADF0A36011179459010BDF5142A4575046C2B8E@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acl0fEP4yEbs9v0fQ3q90YKL9Bb65gA4VCmQ
Thread-topic: Move some of the PCI device manage/control into pciback?
1) Now in Xen VT-d, the FLR related things (can the device(s) be 
statically/dynamically assigned to a guest? how should the device(s) be 
FLR-ed?) are done in xend. The diff of the python patch is ~700 lines.
We may consider moving these things to pciback.  Certainly, with these things 
in pciback, I'm afraid we'll have less  flexibility -- a small adjustment 
(e.g., some people would like to relax the co-assignment constraint) or a bug 
fix requires a reload of pciback or a reboot of host (if pciback is built into 
Dom0 kernel). And we have some other issues: a) moving all the python logic 
into the pciback using C needs a big effort so maybe somebody doesn't like the 
big number of the line of code; b) we may need to add an interface between 
pciback and control panel so that xend can invoke these FLR related functions 
of pciback.

2) Now the pci config space virtualizations of PV and HVM guests are not the 
same and there are some duplicated codes in pciback and ioemu. Now the ioemu of 
Dom0 accesses device config space via libpci (the /sys); maybe ioemu can talk 
to pciback directly?
In the case of stubdomain, looks the libpci is implemented via pcifront -- if 
ioemu can talk to pciback directly, I think we can eliminate the duplicated 
codes in ioemu and we'll have a consistency between PV and HVM.
And for the pci passthrough related hypercalls invoked by the ioemu in the 
de-priviledged stubdomain, I think ioemu can ask pciback to help to invoke the 
hypercall, but this needs us to add an interface in pciback.

All these things need us to re-architect the current codes. Will this bring 
compatibility issues? I remember it's said Xen 3.4 will be released in March; 
now it's the suitable time for us to consider the changes?

PS, in the long run -- how long? -- will ioemu be removed from Dom0 and 
stubdomain will be the only place for ioemu?

Any comment is appreciated!

Thanks,
-- Dexuan

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