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

Re: [Xen-devel] [Xen-unstable] XenbusState signaling with regard to pci-detach on HVM guests



Friday, August 8, 2014, 10:51:29 AM, you wrote:

>>>> On 08.08.14 at 10:20, <linux@xxxxxxxxxxxxxx> wrote:
>> So how feasible is it to keep on trying to work around on things .. when 
>> there 
>> is that much spaghetti :-)

> It's ugly, yes, but breaking existing code is ugly too. The usual
> handshaking negotiation via xenstore should be used to control
> altered behavior.

> Jan

Got an example (something like the ) that is used between pciback and front ?

But i still don't see how it could be done without a lot of code duplication or 
complicating things further.

I also tried the other route that keeps the changes to pciback only.
That is placing a "safeguard" at the end of the xenstore watch callback 
(xen_pcibk_be_watch), that way there is no change for PV guests ( as pcifront 
does seem to do the proper signaling ).  

So on every change to (or under) a guests "pci-root" tree in xenstore, pciback 
would
check if the list of devices that it has registered as passed through to a 
domain (dev_domain_list) matches with the xenstore entries.

If a xenstore entry is missing for a device that is still registred to a 
domain, 
it is clear that libxl has removed it and yanked the xenstore entries from 
beneath our feet,
so we should now deregister the device from the domain in pciback. 

How ever my C-skills are a bit too limited with respect to passing around 
the necessary lists/arrays of pci_dev structs to loop through and compare it
to the xenstore entries, so i can't get it implemented :-( *sigh*

--
Sander




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.