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

[Alexander Graf]

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?

> 
>> 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