[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 09/12] spapr-vio: move special case handling for
From: |
Alexander Graf |
Subject: |
Re: [Qemu-devel] [PATCH 09/12] spapr-vio: move special case handling for reg=0 to vio |
Date: |
Wed, 19 Jun 2013 23:53:29 +0200 |
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
- [Qemu-devel] [PATCH 00/12] spapr: add qtest support and refactor vty, Anthony Liguori, 2013/06/19
- [Qemu-devel] [PATCH 01/12] chardev: ringbuf: add optional save parameter to save state, Anthony Liguori, 2013/06/19
- [Qemu-devel] [PATCH 03/12] qtest: return string from QMP commands, Anthony Liguori, 2013/06/19
- [Qemu-devel] [PATCH 06/12] spapr-vty: add copyright and license, Anthony Liguori, 2013/06/19
- [Qemu-devel] [PATCH 09/12] spapr-vio: move special case handling for reg=0 to vio, Anthony Liguori, 2013/06/19
- Re: [Qemu-devel] [PATCH 09/12] spapr-vio: move special case handling for reg=0 to vio, Benjamin Herrenschmidt, 2013/06/19
[Qemu-devel] [PATCH 08/12] spapr-rtas: use hypercall interface and remove special vty interfaces, Anthony Liguori, 2013/06/19
[Qemu-devel] [PATCH 12/12] spapr-vty: remove unfixable FIXME, Anthony Liguori, 2013/06/19
[Qemu-devel] [PATCH 10/12] spapr-vty: refactor the code to improve consistency, Anthony Liguori, 2013/06/19
[Qemu-devel] [PATCH 04/12] qtest: add interface to save/restore, Anthony Liguori, 2013/06/19