I''m looking at the 2009 era patches for vBAR=pBAR and the more recent maintained version at davidgis.fr, and it would appear that the BAR spaces get hard-coded. Is there a reason why this cannot be dynamically generated at domU start time? I could write a wrapper easily enough to doctor this every time I need to start a VM that generates a patch for the relevant devices and recompiles hvmloader, but this is quite a horrible way to do this. Gordan
Gordan Bobic <gordan@bobich.net> wrote:> I''m looking at the 2009 era patches for vBAR=pBAR and > the more recent maintained version at davidgis.fr, > and it would appear that the BAR spaces get hard-coded. > > Is there a reason why this cannot be dynamically > generated at domU start time? I could write a > wrapper easily enough to doctor this every time > I need to start a VM that generates a patch for > the relevant devices and recompiles hvmloader, > but this is quite a horrible way to do this. > > Gordan > >_______________________________________________ >Xen-devel mailing list >Xen-devel@lists.xen.org >http://lists.xen.org/xen-develCould it be done via Xen Store? hvmloader is already capable of reading values from there. Perhaps add a new attribute there? In local/domain/0/vpci/<domain>/pbar-<bdf>? -- Sent from my Android phone. Please excuse my brevity.
On Wed, 03 Jul 2013 07:33:56 -0400, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:> Gordan Bobic <gordan@bobich.net> wrote: > >> I''m looking at the 2009 era patches for vBAR=pBAR and >> the more recent maintained version at davidgis.fr, >> and it would appear that the BAR spaces get hard-coded. >> >> Is there a reason why this cannot be dynamically >> generated at domU start time? I could write a >> wrapper easily enough to doctor this every time >> I need to start a VM that generates a patch for >> the relevant devices and recompiles hvmloader, >> but this is quite a horrible way to do this. > > Could it be done via Xen Store? hvmloader is already capable of > reading values from there. Perhaps add a new attribute there? In > local/domain/0/vpci/<domain>/pbar-<bdf>?Considering xenstore seems to be deprecated for storing domU configs in favour of plain text files (Windows registry, anyone?), I''m weary of going down the route of anything touching the xenstore. If it''s still going to be hard-coded, I''d rather having it in the domU config file. Detecting all the BARs from all the assigned PCI devices at domU initialization time would be better, though... Gordan
On Wed, 2013-07-03 at 12:42 +0100, Gordan Bobic wrote:> On Wed, 03 Jul 2013 07:33:56 -0400, Konrad Rzeszutek Wilk > <konrad.wilk@oracle.com> wrote: > > Gordan Bobic <gordan@bobich.net> wrote: > > > >> I''m looking at the 2009 era patches for vBAR=pBAR and > >> the more recent maintained version at davidgis.fr, > >> and it would appear that the BAR spaces get hard-coded. > >> > >> Is there a reason why this cannot be dynamically > >> generated at domU start time? I could write a > >> wrapper easily enough to doctor this every time > >> I need to start a VM that generates a patch for > >> the relevant devices and recompiles hvmloader, > >> but this is quite a horrible way to do this. > > > > Could it be done via Xen Store? hvmloader is already capable of > > reading values from there. Perhaps add a new attribute there? In > > local/domain/0/vpci/<domain>/pbar-<bdf>? > > Considering xenstore seems to be deprecated for > storing domU configs in favour of plain text filesUhm, what? domU configs have never been stored in xenstore. xenstore is a runtime service used for communicating configuration information between different bits of the system and serving as a rendevous point for different parts of the system (e.g. front and backends, toolstack and hvmloader, toolstack and itself).> (Windows registry, anyone?), I''m weary of going > down the route of anything touching the xenstore. > If it''s still going to be hard-coded, I''d rather > having it in the domU config file....from where it should be written to xenstore when creating the domain in order to communicate to hvmloader where things should go.> > Detecting all the BARs from all the assigned PCI > devices at domU initialization time would be > better, though... > > Gordan > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel
On Wed, 3 Jul 2013 12:52:21 +0100, Ian Campbell <Ian.Campbell@citrix.com> wrote:> On Wed, 2013-07-03 at 12:42 +0100, Gordan Bobic wrote: >> On Wed, 03 Jul 2013 07:33:56 -0400, Konrad Rzeszutek Wilk >> <konrad.wilk@oracle.com> wrote: >> > Gordan Bobic <gordan@bobich.net> wrote: >> > >> >> I''m looking at the 2009 era patches for vBAR=pBAR and >> >> the more recent maintained version at davidgis.fr, >> >> and it would appear that the BAR spaces get hard-coded. >> >> >> >> Is there a reason why this cannot be dynamically >> >> generated at domU start time? I could write a >> >> wrapper easily enough to doctor this every time >> >> I need to start a VM that generates a patch for >> >> the relevant devices and recompiles hvmloader, >> >> but this is quite a horrible way to do this. >> > >> > Could it be done via Xen Store? hvmloader is already capable of >> > reading values from there. Perhaps add a new attribute there? In >> > local/domain/0/vpci/<domain>/pbar-<bdf>? >> >> Considering xenstore seems to be deprecated for >> storing domU configs in favour of plain text files > > Uhm, what? > > domU configs have never been stored in xenstore.Really? I was under the impression that this was where libvirt put them, because after configuring an xm domU using virt-manager/libvirt I could not find where the domU configuration was stored. I tried grepping the entire FS for things I thought should appear in the file, but maybe I searched for the wrong thing.> xenstore is a runtime service used for communicating configuration > information between different bits of the system and serving as a > rendevous point for different parts of the system (e.g. front and > backends, toolstack and hvmloader, toolstack and itself). > >> (Windows registry, anyone?), I''m weary of going >> down the route of anything touching the xenstore. >> If it''s still going to be hard-coded, I''d rather >> having it in the domU config file. > > ...from where it should be written to xenstore when creating the > domain > in order to communicate to hvmloader where things should go.I see. Thanks for clarifying. Gordan
On Wed, 2013-07-03 at 13:24 +0100, Gordan Bobic wrote:> On Wed, 3 Jul 2013 12:52:21 +0100, Ian Campbell > <Ian.Campbell@citrix.com> wrote: > > On Wed, 2013-07-03 at 12:42 +0100, Gordan Bobic wrote: > >> On Wed, 03 Jul 2013 07:33:56 -0400, Konrad Rzeszutek Wilk > >> <konrad.wilk@oracle.com> wrote: > >> > Gordan Bobic <gordan@bobich.net> wrote: > >> > > >> >> I''m looking at the 2009 era patches for vBAR=pBAR and > >> >> the more recent maintained version at davidgis.fr, > >> >> and it would appear that the BAR spaces get hard-coded. > >> >> > >> >> Is there a reason why this cannot be dynamically > >> >> generated at domU start time? I could write a > >> >> wrapper easily enough to doctor this every time > >> >> I need to start a VM that generates a patch for > >> >> the relevant devices and recompiles hvmloader, > >> >> but this is quite a horrible way to do this. > >> > > >> > Could it be done via Xen Store? hvmloader is already capable of > >> > reading values from there. Perhaps add a new attribute there? In > >> > local/domain/0/vpci/<domain>/pbar-<bdf>? > >> > >> Considering xenstore seems to be deprecated for > >> storing domU configs in favour of plain text files > > > > Uhm, what? > > > > domU configs have never been stored in xenstore. > > Really? I was under the impression that this was where > libvirt put them, because after configuring an xm domU > using virt-manager/libvirt I could not find where > the domU configuration was stored.I''m not an expert on libvirt but for ephermeral domains I think it creates the cfg on the fly and then I expect it discards it, since there is no reason to keep it around after starting the domain. For persistent domains it can''t be keeping them in xenstore because that doesn''t persist over reboots etc.> I tried grepping > the entire FS for things I thought should appear in > the file, but maybe I searched for the wrong thing. > > > xenstore is a runtime service used for communicating configuration > > information between different bits of the system and serving as a > > rendevous point for different parts of the system (e.g. front and > > backends, toolstack and hvmloader, toolstack and itself). > > > >> (Windows registry, anyone?), I''m weary of going > >> down the route of anything touching the xenstore. > >> If it''s still going to be hard-coded, I''d rather > >> having it in the domU config file. > > > > ...from where it should be written to xenstore when creating the > > domain > > in order to communicate to hvmloader where things should go. > > I see. Thanks for clarifying. > > Gordan