On 19.06.2013, at 23:49, Anthony Liguori wrote: > Alexander Graf <ag...@suse.de> 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
