Alexander Graf <ag...@suse.de> writes: > 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?
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
