qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2] hmp: gpa2hva and gpa2hpa hostaddr command


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH v2] hmp: gpa2hva and gpa2hpa hostaddr command
Date: Fri, 24 Mar 2017 22:56:24 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0


On 20/03/2017 18:16, Paolo Bonzini wrote:
> 
> 
> On 20/03/2017 18:01, Markus Armbruster wrote:
>> Peter Maydell <address@hidden> writes:
>>
>>> On 20 March 2017 at 16:29, Markus Armbruster <address@hidden> wrote:
>>>> Peter Maydell <address@hidden> 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?

Paolo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]