qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Anthony Liguori <aliguori@us.ibm.com>
To: Alexander Graf <agraf@suse.de>
Cc: Alexey Kardashevskiy <aik@ozlabs.ru>,
	qemu-devel qemu-devel <qemu-devel@nongnu.org>,
	"qemu-ppc@nongnu.org list:PowerPC" <qemu-ppc@nongnu.org>,
	Paul Mackerras <paulus@samba.org>,
	Andreas Faerber <afaerber@suse.de>
Subject: Re: [Qemu-devel] [PATCH 09/12] spapr-vio: move special case handling for reg=0 to vio
Date: Wed, 19 Jun 2013 18:20:17 -0500	[thread overview]
Message-ID: <87k3lpelhq.fsf@codemonkey.ws> (raw)
In-Reply-To: <970EA7BC-E7EB-4971-8E36-CD303C872B53@suse.de>

Alexander Graf <agraf@suse.de> writes:

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

  reply	other threads:[~2013-06-19 23:20 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-19 20:40 [Qemu-devel] [PATCH 00/12] spapr: add qtest support and refactor vty Anthony Liguori
2013-06-19 20:40 ` [Qemu-devel] [PATCH 01/12] chardev: ringbuf: add optional save parameter to save state Anthony Liguori
2013-06-20 19:49   ` Eric Blake
2013-06-19 20:40 ` [Qemu-devel] [PATCH 02/12] qtest: add spapr hypercall support Anthony Liguori
2013-06-20 15:20   ` Andreas Färber
2013-06-20 15:42     ` Anthony Liguori
2013-06-20 18:43       ` Alexander Graf
2013-06-20 18:58         ` Anthony Liguori
2013-06-20 19:28           ` [Qemu-devel] [Qemu-ppc] " Scott Wood
2013-06-20 21:57           ` [Qemu-devel] " Alexander Graf
2013-06-19 20:40 ` [Qemu-devel] [PATCH 03/12] qtest: return string from QMP commands Anthony Liguori
2013-06-20 15:24   ` Andreas Färber
2013-06-20 15:43     ` Anthony Liguori
2013-06-19 20:40 ` [Qemu-devel] [PATCH 04/12] qtest: add interface to save/restore Anthony Liguori
2013-06-20 15:38   ` Andreas Färber
2013-06-19 20:40 ` [Qemu-devel] [PATCH 05/12] spapr-vty: add qtest test case Anthony Liguori
2013-06-19 21:13   ` Alexander Graf
2013-06-19 21:43     ` Anthony Liguori
2013-06-19 21:47       ` Alexander Graf
2013-06-19 20:40 ` [Qemu-devel] [PATCH 06/12] spapr-vty: add copyright and license Anthony Liguori
2013-06-20  1:45   ` Michael Ellerman
2013-06-20  4:08   ` Alexey Kardashevskiy
2013-06-20  4:43   ` David Gibson
2013-06-20  8:52   ` Paolo Bonzini
2013-06-20 15:47   ` Andreas Färber
2013-06-19 20:40 ` [Qemu-devel] [PATCH 07/12] spapr-rtas: add CPU argument to RTAS calls Anthony Liguori
2013-06-19 21:15   ` Alexander Graf
2013-06-20 15:51   ` Andreas Färber
2013-06-20 16:10     ` Anthony Liguori
2013-06-19 20:40 ` [Qemu-devel] [PATCH 08/12] spapr-rtas: use hypercall interface and remove special vty interfaces Anthony Liguori
2013-06-19 21:24   ` Alexander Graf
2013-06-19 21:45     ` Anthony Liguori
2013-06-19 21:48       ` Alexander Graf
2013-06-19 20:40 ` [Qemu-devel] [PATCH 09/12] spapr-vio: move special case handling for reg=0 to vio Anthony Liguori
2013-06-19 21:28   ` Alexander Graf
2013-06-19 21:49     ` Anthony Liguori
2013-06-19 21:53       ` Alexander Graf
2013-06-19 23:20         ` Anthony Liguori [this message]
2013-06-19 23:07     ` Benjamin Herrenschmidt
2013-06-19 20:40 ` [Qemu-devel] [PATCH 10/12] spapr-vty: refactor the code to improve consistency Anthony Liguori
2013-06-19 21:37   ` Alexander Graf
2013-06-19 20:40 ` [Qemu-devel] [PATCH 11/12] spapr-vio: pass type to spapr_vio_find_by_reg() Anthony Liguori
2013-06-19 21:38   ` Alexander Graf
2013-06-19 21:56     ` Anthony Liguori
2013-06-19 20:40 ` [Qemu-devel] [PATCH 12/12] spapr-vty: remove unfixable FIXME Anthony Liguori

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87k3lpelhq.fsf@codemonkey.ws \
    --to=aliguori@us.ibm.com \
    --cc=afaerber@suse.de \
    --cc=agraf@suse.de \
    --cc=aik@ozlabs.ru \
    --cc=paulus@samba.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).