[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |