From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Paolo Bonzini <bonzini@gnu.org>
Cc: Markus Armbruster <armbru@redhat.com>,
Peter Maydell <peter.maydell@linaro.org>,
QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH v2] hmp: gpa2hva and gpa2hpa hostaddr command
Date: Mon, 27 Mar 2017 10:25:13 +0100 [thread overview]
Message-ID: <20170327092513.GD2373@work-vm> (raw)
In-Reply-To: <40d2f327-46ec-8a1d-a3c4-0bb90180b847@gnu.org>
* Paolo Bonzini (bonzini@gnu.org) wrote:
>
>
> On 20/03/2017 18:16, Paolo Bonzini wrote:
> >
> >
> > On 20/03/2017 18:01, Markus Armbruster wrote:
> >> Peter Maydell <peter.maydell@linaro.org> writes:
> >>
> >>> On 20 March 2017 at 16:29, Markus Armbruster <armbru@redhat.com> wrote:
> >>>> Peter Maydell <peter.maydell@linaro.org> writes:
> >>>>> I have some comments which feel kind of nit-picky, but since this
> >>>>> is a public-facing HMP API I think they need attention since we only
> >>>>> get one chance to get it right.
> >>>>
> >>>> HMP is not a stable interface. If we get it wrong, we change it. If
> >>>> our change breaks your usage, you get to keep the pieces.
> >>>
> >>> Oh yes, I had my HMP and QMP the wrong way round.
> >>>
> >>> ...which reminds me that I thought we preferred all HMP commands
> >>> to be implemented in terms of their QMP equivalent ?
> >>
> >> Yes. We make exceptions for commands we believe have no QMP use, such
> >> as "print". I figure the rationale for these is "just for testing".
> >> Paolo, can you confirm?
> >
> > Yes. If somebody comes up with a non-testing use, I suppose we can
> > always add a QMP variant. I'll send v3 which uses the current monitor
> > CPU's address space according to Peter's review.
>
> Since there is no CPU method to transform a CPU state into a MemTxAttrs
> value, and the MemTxAttrs are needed to get the right address space, v2
> is the best I can do for 2.9.
>
> Changing it to take the CPU state into account (e.g. include secure
> memory when in secure mode) can be done in later releases if necessary.
>
> David, are you queuing the patch?
Yes, will do.
Dave
> Paolo
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
next prev parent reply other threads:[~2017-03-27 9:25 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-20 14:45 [Qemu-devel] [PATCH v2] hmp: gpa2hva and gpa2hpa hostaddr command Paolo Bonzini
2017-03-20 14:56 ` Peter Maydell
2017-03-20 15:08 ` Paolo Bonzini
2017-03-20 16:29 ` Markus Armbruster
2017-03-20 16:32 ` Peter Maydell
2017-03-20 16:35 ` Paolo Bonzini
2017-03-20 17:01 ` Markus Armbruster
2017-03-20 17:16 ` Paolo Bonzini
2017-03-24 21:56 ` Paolo Bonzini
2017-03-27 9:25 ` Dr. David Alan Gilbert [this message]
2017-03-27 15:35 ` Dr. David Alan Gilbert
2017-03-20 14:59 ` Dr. David Alan Gilbert
2017-03-27 13:49 ` Dr. David Alan Gilbert
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=20170327092513.GD2373@work-vm \
--to=dgilbert@redhat.com \
--cc=armbru@redhat.com \
--cc=bonzini@gnu.org \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.