Re: [Qemu-devel] [PATCH 09/12] spapr-vio: move special case handling for reg=0 to vio

[Anthony Liguori]

Alexander Graf <address@hidden> writes:

> On 19.06.2013, at 23:49, Anthony Liguori wrote:
>
>> Alexander Graf <address@hidden> writes:
>> 
>>> On 19.06.2013, at 22:40, Anthony Liguori wrote:
>>> 
>>>> The creatively named reg field is a hypervisor assigned global
>>>> identifier for a virtual device.  Despite the fact that no device
>>>> is assigned a reg of 0, guests still use it to refer to early
>>>> console.
>>>> 
>>>> Instead of handling this in the VTY device, handle this in the VIO
>>>> bus since this is ultimately about how devices are decoded.
>>>> 
>>>> This does not produce a change in behavior since reg=0 hcalls to
>>>> non-VTY devices will still fail as gloriously as they did before
>>>> just for a different reason (invalid device instead of invalid reg).
>>> 
>>> Ben, is it true that reg=0 is guaranteed to be free, regardless of the
>>> target call?
>> 
>> reg is exposed to the guest via device tree.  My assumption is that the
>> only reason this reg=0 silliness exists is for early boot code that
>> hasn't gotten enough working yet to actually read the device tree to
>> discover the proper reg value for the VTY.
>
> So QEMU decided the numbering scheme. Can we just use reg=0 for the
> default VTY? Or is reg=0 considered invalid?

We expose reg= on the command line too.  I think we want to exclude 0
from that interface though.  I suspect libvirt is going to want to
allocate IDs to ensure a stable guest interface.

Regardless of what the "first" VTY is assigned as it's reg, software is
going to use reg=0 to access it.

Regards,

Anthony Liguori

>>> Also, are there no other PAPR calls that could possibly refer to reg=0
>>> but mean something different from the VTY device?
>> 
>> Note that if there is, it will still fail today exactly the same way as
>> it does without this patch.
>> 
>> We can still add work arounds to the reg lookup code to return something
>> different for reg=0 if a different device type is being searched for.
>
> As mentioned in a later patch review, that's pretty much what I think would 
> be the best way forward, yes. Unless we can just make the default VTY be 
> reg=0. Then there's no hack needed at all ;).
>
>> 
>> So even if that's the case, I still think this move is the right way to
>> handle things.
>
> Yes, but I want to grasp the scope of potential breakage.
>
>
> Alex