[libvirt] [PATCH 0/1] bhyve: Make LPC slot number configurable

[Ivan Mishonov]

Yes, that makes sense. I'll try to find some time next week to redo my 
code and send another patch. Since my time for working on libvirt is 
very limited can you confirm that the LPC configuration should look like 
this:

    <controller type="isa-bridge" index="0">
        <address type="pci" domain="0" bus="0" slot="NNN" function="0"/>
    </controller>

Also can you send me an example of how you imagine the <features> 
setting for unimplemented MSRs?

Regards,
Ivan

On 08/10/2018 06:24 PM, Daniel P. Berrangé wrote:
> 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
> Regards,
> Daniel