On Fri, Aug 10, 2018 at 06:11:57PM +0300, Ivan Mishonov wrote:
> I'd like to hear Roman's opinion on this too since he wrote the initial
> implementation. As for the command line arguments I was looking at
> <qemu:commandline> since it's doing exactly the same thing and I thought it
> would be nice to be consistent with it
It would still be reasonable to allow <bhvyve:commandline> for arbitrary
passthrough of new features which have no XML defined for them. I just
think it is reasonable to model these two example explicitly.
The namespaced passthrough is intended for short term hacks primarily.
> On 08/10/2018 05:57 PM, Daniel P. Berrangé wrote:
> > On Fri, Aug 10, 2018 at 05:47:40PM +0300, Ivan Mishonov wrote:
> > > Yes, this is totally doable. I just don't know if it's a good idea to add
> > > a
> > > new device type specifically for bhyve LPC and nothing else. Even if we do
> > > it like this I'll still have to send another patch including the bhyve XML
> > > namespace as we need to be able to pass extra command line options to the
> > > bhyve process related to unimplemented MSRs on AMD Zen systems. I thought
> > > I'd do the 2 things in a similar manner as both of them are strictly bhyve
> > > specific
> > IMHO the LPC thing is definitely in scope for correct modelling in
> > the XML.
> > For the MSRs option, it is probable we'd consider that in scope as
> > well. Currently KVM has a global "ignore unknown msrs" option in the
> > kernel module, but I think it is conceptually reasonable to expect
> > that to be settable on a per-VM basis.
> > Probably would do the MSRs thing as a <features> flag, as we stuff
> > lots of random feature toggles under there
> > Regards,
> > Daniel
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
libvir-list mailing list