[PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address

[PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address

[Huang Ying]

Author: Max Asbock <masbock@linux.vnet.ibm.com>

Add command pfa2hva to translate guest physical address to host
virtual address.

The pfa2hva command provides one step in a chain of translations from
guest virtual to guest physical to host virtual to host physical. Host
physical is then used to inject a machine check error. As a
consequence the HWPOISON code on the host and the MCE injection code
in qemu-kvm are exercised.

v2:

- Add QMP support

Signed-off-by: Max Asbock <masbock@linux.vnet.ibm.com>
Signed-off-by: Jiajia Zheng <jiajia.zheng@intel.com>
Signed-off-by: Huang Ying <ying.huang@intel.com>
---
 hmp-commands.hx |   15 +++++++++++++++
 monitor.c       |   22 ++++++++++++++++++++++
 qmp-commands.hx |   27 +++++++++++++++++++++++++++
 3 files changed, 64 insertions(+)

--- a/monitor.c
+++ b/monitor.c
@@ -2272,6 +2272,28 @@ static void do_inject_mce(Monitor *mon,
 }
 #endif
 
+static void do_pfa2hva_print(Monitor *mon, const QObject *data)
+{
+    QInt *qint;
+
+    qint = qobject_to_qint(data);
+    monitor_printf(mon, "0x%lx\n", (unsigned long)qint->value);
+}
+
+static int do_pfa2hva(Monitor *mon, const QDict *qdict, QObject **ret_data)
+{
+    target_phys_addr_t paddr;
+    target_phys_addr_t size = TARGET_PAGE_SIZE;
+    void *vaddr;
+
+    paddr = qdict_get_int(qdict, "addr");
+    vaddr = cpu_physical_memory_map(paddr, &size, 0);
+    cpu_physical_memory_unmap(vaddr, size, 0, 0);
+    *ret_data = qobject_from_jsonf("%ld", (unsigned long)vaddr);
+
+    return 0;
+}
+
 static int do_getfd(Monitor *mon, const QDict *qdict, QObject **ret_data)
 {
     const char *fdname = qdict_get_str(qdict, "fdname");
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -293,6 +293,21 @@ Start gdbserver session (default @var{po
 ETEXI
 
     {
+        .name       = "pfa2hva",
+        .args_type  = "fmt:/,addr:l",
+        .params     = "/fmt addr",
+        .help       = "translate guest physical 'addr' to host virtual address",
+        .user_print = do_pfa2hva_print,
+        .mhandler.cmd_new = do_pfa2hva,
+    },
+
+STEXI
+@item pfa2hva @var{addr}
+@findex pfa2hva
+Translate guest physical @var{addr} to host virtual address.
+ETEXI
+
+    {
         .name       = "x",
         .args_type  = "fmt:/,addr:l",
         .params     = "/fmt addr",
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -738,6 +738,33 @@ Example:
 EQMP
 
     {
+        .name       = "pfa2hva",
+        .args_type  = "addr:l",
+        .params     = "addr",
+        .help       = "translate guest physical 'addr' to host virtual address",
+        .user_print = do_pfa2hva_print,
+        .mhandler.cmd_new = do_pfa2hva,
+    },
+
+SQMP
+pfa2hva
+---
+
+Translate guest physical 'addr' to host virtual address.
+
+Arguments:
+
+- "addr": the guest physical address
+
+Example:
+
+-> { "execute": "pfa2hva",
+		"arguments": { "addr": 196608 } }
+<- { "return": 139888084717568 }
+
+EQMP
+
+    {
         .name       = "qmp_capabilities",
         .args_type  = "",
         .params     = "",

Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address

[Marcelo Tosatti]

On Tue, Oct 26, 2010 at 10:39:48AM +0800, Huang Ying wrote:
> Author: Max Asbock <masbock@linux.vnet.ibm.com>
> 
> Add command pfa2hva to translate guest physical address to host
> virtual address.
> 
> The pfa2hva command provides one step in a chain of translations from
> guest virtual to guest physical to host virtual to host physical. Host
> physical is then used to inject a machine check error. As a
> consequence the HWPOISON code on the host and the MCE injection code
> in qemu-kvm are exercised.
> 
> v2:
> 
> - Add QMP support


Looks good to me. Anthony?

> 
> Signed-off-by: Max Asbock <masbock@linux.vnet.ibm.com>
> Signed-off-by: Jiajia Zheng <jiajia.zheng@intel.com>
> Signed-off-by: Huang Ying <ying.huang@intel.com>
> ---
>  hmp-commands.hx |   15 +++++++++++++++
>  monitor.c       |   22 ++++++++++++++++++++++
>  qmp-commands.hx |   27 +++++++++++++++++++++++++++
>  3 files changed, 64 insertions(+)
> 
> --- a/monitor.c
> +++ b/monitor.c
> @@ -2272,6 +2272,28 @@ static void do_inject_mce(Monitor *mon,
>  }
>  #endif
>  
> +static void do_pfa2hva_print(Monitor *mon, const QObject *data)
> +{
> +    QInt *qint;
> +
> +    qint = qobject_to_qint(data);
> +    monitor_printf(mon, "0x%lx\n", (unsigned long)qint->value);
> +}
> +
> +static int do_pfa2hva(Monitor *mon, const QDict *qdict, QObject **ret_data)
> +{
> +    target_phys_addr_t paddr;
> +    target_phys_addr_t size = TARGET_PAGE_SIZE;
> +    void *vaddr;
> +
> +    paddr = qdict_get_int(qdict, "addr");
> +    vaddr = cpu_physical_memory_map(paddr, &size, 0);
> +    cpu_physical_memory_unmap(vaddr, size, 0, 0);
> +    *ret_data = qobject_from_jsonf("%ld", (unsigned long)vaddr);
> +
> +    return 0;
> +}
> +
>  static int do_getfd(Monitor *mon, const QDict *qdict, QObject **ret_data)
>  {
>      const char *fdname = qdict_get_str(qdict, "fdname");
> --- a/hmp-commands.hx
> +++ b/hmp-commands.hx
> @@ -293,6 +293,21 @@ Start gdbserver session (default @var{po
>  ETEXI
>  
>      {
> +        .name       = "pfa2hva",
> +        .args_type  = "fmt:/,addr:l",
> +        .params     = "/fmt addr",
> +        .help       = "translate guest physical 'addr' to host virtual address",
> +        .user_print = do_pfa2hva_print,
> +        .mhandler.cmd_new = do_pfa2hva,
> +    },
> +
> +STEXI
> +@item pfa2hva @var{addr}
> +@findex pfa2hva
> +Translate guest physical @var{addr} to host virtual address.
> +ETEXI
> +
> +    {
>          .name       = "x",
>          .args_type  = "fmt:/,addr:l",
>          .params     = "/fmt addr",
> --- a/qmp-commands.hx
> +++ b/qmp-commands.hx
> @@ -738,6 +738,33 @@ Example:
>  EQMP
>  
>      {
> +        .name       = "pfa2hva",
> +        .args_type  = "addr:l",
> +        .params     = "addr",
> +        .help       = "translate guest physical 'addr' to host virtual address",
> +        .user_print = do_pfa2hva_print,
> +        .mhandler.cmd_new = do_pfa2hva,
> +    },
> +
> +SQMP
> +pfa2hva
> +---
> +
> +Translate guest physical 'addr' to host virtual address.
> +
> +Arguments:
> +
> +- "addr": the guest physical address
> +
> +Example:
> +
> +-> { "execute": "pfa2hva",
> +		"arguments": { "addr": 196608 } }
> +<- { "return": 139888084717568 }
> +
> +EQMP
> +
> +    {
>          .name       = "qmp_capabilities",
>          .args_type  = "",
>          .params     = "",
> 

Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address

[Anthony Liguori]

On 11/01/2010 11:09 AM, Marcelo Tosatti wrote:
> On Tue, Oct 26, 2010 at 10:39:48AM +0800, Huang Ying wrote:
>    
>> Author: Max Asbock<masbock@linux.vnet.ibm.com>
>>
>> Add command pfa2hva to translate guest physical address to host
>> virtual address.
>>
>> The pfa2hva command provides one step in a chain of translations from
>> guest virtual to guest physical to host virtual to host physical. Host
>> physical is then used to inject a machine check error. As a
>> consequence the HWPOISON code on the host and the MCE injection code
>> in qemu-kvm are exercised.
>>
>> v2:
>>
>> - Add QMP support
>>      
>
> Looks good to me. Anthony?
>    

The translation is not stable so this is really a bad interface.

It definitely shouldn't be a QMP command and I don't think it's 
generally useful enough that it should be a monitor command.

It's impossible to use correctly as a general interface.

I gave this feedback when it was initially submitted.

Regards,

Anthony Liguori

>> Signed-off-by: Max Asbock<masbock@linux.vnet.ibm.com>
>> Signed-off-by: Jiajia Zheng<jiajia.zheng@intel.com>
>> Signed-off-by: Huang Ying<ying.huang@intel.com>
>> ---
>>   hmp-commands.hx |   15 +++++++++++++++
>>   monitor.c       |   22 ++++++++++++++++++++++
>>   qmp-commands.hx |   27 +++++++++++++++++++++++++++
>>   3 files changed, 64 insertions(+)
>>
>> --- a/monitor.c
>> +++ b/monitor.c
>> @@ -2272,6 +2272,28 @@ static void do_inject_mce(Monitor *mon,
>>   }
>>   #endif
>>
>> +static void do_pfa2hva_print(Monitor *mon, const QObject *data)
>> +{
>> +    QInt *qint;
>> +
>> +    qint = qobject_to_qint(data);
>> +    monitor_printf(mon, "0x%lx\n", (unsigned long)qint->value);
>> +}
>> +
>> +static int do_pfa2hva(Monitor *mon, const QDict *qdict, QObject **ret_data)
>> +{
>> +    target_phys_addr_t paddr;
>> +    target_phys_addr_t size = TARGET_PAGE_SIZE;
>> +    void *vaddr;
>> +
>> +    paddr = qdict_get_int(qdict, "addr");
>> +    vaddr = cpu_physical_memory_map(paddr,&size, 0);
>> +    cpu_physical_memory_unmap(vaddr, size, 0, 0);
>> +    *ret_data = qobject_from_jsonf("%ld", (unsigned long)vaddr);
>> +
>> +    return 0;
>> +}
>> +
>>   static int do_getfd(Monitor *mon, const QDict *qdict, QObject **ret_data)
>>   {
>>       const char *fdname = qdict_get_str(qdict, "fdname");
>> --- a/hmp-commands.hx
>> +++ b/hmp-commands.hx
>> @@ -293,6 +293,21 @@ Start gdbserver session (default @var{po
>>   ETEXI
>>
>>       {
>> +        .name       = "pfa2hva",
>> +        .args_type  = "fmt:/,addr:l",
>> +        .params     = "/fmt addr",
>> +        .help       = "translate guest physical 'addr' to host virtual address",
>> +        .user_print = do_pfa2hva_print,
>> +        .mhandler.cmd_new = do_pfa2hva,
>> +    },
>> +
>> +STEXI
>> +@item pfa2hva @var{addr}
>> +@findex pfa2hva
>> +Translate guest physical @var{addr} to host virtual address.
>> +ETEXI
>> +
>> +    {
>>           .name       = "x",
>>           .args_type  = "fmt:/,addr:l",
>>           .params     = "/fmt addr",
>> --- a/qmp-commands.hx
>> +++ b/qmp-commands.hx
>> @@ -738,6 +738,33 @@ Example:
>>   EQMP
>>
>>       {
>> +        .name       = "pfa2hva",
>> +        .args_type  = "addr:l",
>> +        .params     = "addr",
>> +        .help       = "translate guest physical 'addr' to host virtual address",
>> +        .user_print = do_pfa2hva_print,
>> +        .mhandler.cmd_new = do_pfa2hva,
>> +    },
>> +
>> +SQMP
>> +pfa2hva
>> +---
>> +
>> +Translate guest physical 'addr' to host virtual address.
>> +
>> +Arguments:
>> +
>> +- "addr": the guest physical address
>> +
>> +Example:
>> +
>> +->  { "execute": "pfa2hva",
>> +		"arguments": { "addr": 196608 } }
>> +<- { "return": 139888084717568 }
>> +
>> +EQMP
>> +
>> +    {
>>           .name       = "qmp_capabilities",
>>           .args_type  = "",
>>           .params     = "",
>>
>>      

Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address

[Huang Ying]

On Mon, 2010-11-01 at 11:49 -0700, Anthony Liguori wrote:
> On 11/01/2010 11:09 AM, Marcelo Tosatti wrote:
> > On Tue, Oct 26, 2010 at 10:39:48AM +0800, Huang Ying wrote:
> >    
> >> Author: Max Asbock<masbock@linux.vnet.ibm.com>
> >>
> >> Add command pfa2hva to translate guest physical address to host
> >> virtual address.
> >>
> >> The pfa2hva command provides one step in a chain of translations from
> >> guest virtual to guest physical to host virtual to host physical. Host
> >> physical is then used to inject a machine check error. As a
> >> consequence the HWPOISON code on the host and the MCE injection code
> >> in qemu-kvm are exercised.
> >>
> >> v2:
> >>
> >> - Add QMP support
> >>      
> >
> > Looks good to me. Anthony?
> >    
> 
> The translation is not stable so this is really a bad interface.
> 
> It definitely shouldn't be a QMP command and I don't think it's 
> generally useful enough that it should be a monitor command.
> 
> It's impossible to use correctly as a general interface.
> 
> I gave this feedback when it was initially submitted.

Yes. As general interface, it may not work so well, but as test
interface, it works quite well and useful.

Do we have any mechanism to add a test only interface?

Best Regards,
Huang Ying

Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address

[Anthony Liguori]

On 11/01/2010 02:20 PM, Huang Ying wrote:
> Yes. As general interface, it may not work so well, but as test
> interface, it works quite well and useful.
>
> Do we have any mechanism to add a test only interface?
>    

I'd like to see what Luiz/Markus think but definitely only a human 
monitor interface and probably prefix the command with a 'x-' prefix to 
indicate that it's not a supported interface.

The documentation should be very clear about the limitations of the 
interface and the intended use-case.

Regards,

Anthony Liguori

> Best Regards,
> Huang Ying
>
>
>    

Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address

[Luiz Capitulino]

On Mon, 01 Nov 2010 14:22:21 -0500
Anthony Liguori <aliguori@linux.vnet.ibm.com> wrote:

> On 11/01/2010 02:20 PM, Huang Ying wrote:
> > Yes. As general interface, it may not work so well, but as test
> > interface, it works quite well and useful.
> >
> > Do we have any mechanism to add a test only interface?

No.

We're likely going to introduce a new namespace for that in the near future,
but only for QMP.

Is this command supposed to be useful for applications or is it primary
designed for (human) debugging?

> I'd like to see what Luiz/Markus think but definitely only a human 
> monitor interface and probably prefix the command with a 'x-' prefix to 
> indicate that it's not a supported interface.

Yes, I agree on having only the human interface but I'm not sure about
prexing it with 'x-'. I think new HMP commands should be declared unstable
by default starting with 0.14.

> The documentation should be very clear about the limitations of the 
> interface and the intended use-case.
> 
> Regards,
> 
> Anthony Liguori
> 
> > Best Regards,
> > Huang Ying
> >
> >
> >    
> 

Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address

[Avi Kivity]

On 11/01/2010 03:22 PM, Anthony Liguori wrote:
> On 11/01/2010 02:20 PM, Huang Ying wrote:
>> Yes. As general interface, it may not work so well, but as test
>> interface, it works quite well and useful.
>>
>> Do we have any mechanism to add a test only interface?
>
> I'd like to see what Luiz/Markus think but definitely only a human 
> monitor interface and probably prefix the command with a 'x-' prefix 
> to indicate that it's not a supported interface.
>

Automated testing will want to use qmp.

> The documentation should be very clear about the limitations of the 
> interface and the intended use-case.
>

Perhaps a { execute: 'enable-version-specific-commands', arguments: 
['pfa2hva'] } ?

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address

[Huang Ying]

On Sun, 2010-11-07 at 00:24 +0800, Avi Kivity wrote:
> On 11/01/2010 03:22 PM, Anthony Liguori wrote:
> > On 11/01/2010 02:20 PM, Huang Ying wrote:
> >> Yes. As general interface, it may not work so well, but as test
> >> interface, it works quite well and useful.
> >>
> >> Do we have any mechanism to add a test only interface?
> >
> > I'd like to see what Luiz/Markus think but definitely only a human 
> > monitor interface and probably prefix the command with a 'x-' prefix 
> > to indicate that it's not a supported interface.
> >
> 
> Automated testing will want to use qmp.

Yes. The main usage of the interface is automated testing.

> > The documentation should be very clear about the limitations of the 
> > interface and the intended use-case.
> >
> 
> Perhaps a { execute: 'enable-version-specific-commands', arguments: 
> ['pfa2hva'] } ?

Best Regards,
Huang Ying

Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address

[Anthony Liguori]

On 11/06/2010 11:24 AM, Avi Kivity wrote:
> On 11/01/2010 03:22 PM, Anthony Liguori wrote:
>> On 11/01/2010 02:20 PM, Huang Ying wrote:
>>> Yes. As general interface, it may not work so well, but as test
>>> interface, it works quite well and useful.
>>>
>>> Do we have any mechanism to add a test only interface?
>>
>> I'd like to see what Luiz/Markus think but definitely only a human 
>> monitor interface and probably prefix the command with a 'x-' prefix 
>> to indicate that it's not a supported interface.
>>
>
> Automated testing will want to use qmp.

The command is inherently racy so if you tried to implement an automated 
unit test, you'd get false

>> The documentation should be very clear about the limitations of the 
>> interface and the intended use-case.
>>
>
> Perhaps a { execute: 'enable-version-specific-commands', arguments: 
> ['pfa2hva'] } ?
>

Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address

[Anthony Liguori]

On 11/07/2010 07:29 PM, Huang Ying wrote:
> On Sun, 2010-11-07 at 00:24 +0800, Avi Kivity wrote:
>    
>> On 11/01/2010 03:22 PM, Anthony Liguori wrote:
>>      
>>> On 11/01/2010 02:20 PM, Huang Ying wrote:
>>>        
>>>> Yes. As general interface, it may not work so well, but as test
>>>> interface, it works quite well and useful.
>>>>
>>>> Do we have any mechanism to add a test only interface?
>>>>          
>>> I'd like to see what Luiz/Markus think but definitely only a human
>>> monitor interface and probably prefix the command with a 'x-' prefix
>>> to indicate that it's not a supported interface.
>>>
>>>        
>> Automated testing will want to use qmp.
>>      
> Yes. The main usage of the interface is automated testing.
>    

That's precisely what the command should not be used for.

You can't assume a gpa -> hva mapping is consistent in an external 
application.  If you want to implement an interface for testing, you 
have to push more of the logic into QEMU to avoid the race.

Regards,

Anthony Liguori

>>> The documentation should be very clear about the limitations of the
>>> interface and the intended use-case.
>>>
>>>        
>> Perhaps a { execute: 'enable-version-specific-commands', arguments:
>> ['pfa2hva'] } ?
>>      
> Best Regards,
> Huang Ying
>
>
>    

Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address

[Huang Ying]

Hi, Anthony,

On Mon, 2010-11-08 at 11:39 +0800, Anthony Liguori wrote:
> On 11/07/2010 07:29 PM, Huang Ying wrote:
> > On Sun, 2010-11-07 at 00:24 +0800, Avi Kivity wrote:
> >    
> >> On 11/01/2010 03:22 PM, Anthony Liguori wrote:
> >>      
> >>> On 11/01/2010 02:20 PM, Huang Ying wrote:
> >>>        
> >>>> Yes. As general interface, it may not work so well, but as test
> >>>> interface, it works quite well and useful.
> >>>>
> >>>> Do we have any mechanism to add a test only interface?
> >>>>          
> >>> I'd like to see what Luiz/Markus think but definitely only a human
> >>> monitor interface and probably prefix the command with a 'x-' prefix
> >>> to indicate that it's not a supported interface.
> >>>
> >>>        
> >> Automated testing will want to use qmp.
> >>      
> > Yes. The main usage of the interface is automated testing.
> >    
> 
> That's precisely what the command should not be used for.
> 
> You can't assume a gpa -> hva mapping is consistent in an external 
> application.  If you want to implement an interface for testing, you 
> have to push more of the logic into QEMU to avoid the race.

Yes. pfa2hva (should be renamed to gpa2hva) in the patch works not well
in general cases, but it works well for our testing. So we do not want
to make it a general interface, but a testing only interface. Maybe via
putting it into a special name space like "x-". Do you agree?

Best Regards,
Huang Ying

Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address

[Huang Ying]

On Mon, 2010-11-08 at 11:39 +0800, Anthony Liguori wrote:
> On 11/07/2010 07:29 PM, Huang Ying wrote:
> > On Sun, 2010-11-07 at 00:24 +0800, Avi Kivity wrote:
> >    
> >> On 11/01/2010 03:22 PM, Anthony Liguori wrote:
> >>      
> >>> On 11/01/2010 02:20 PM, Huang Ying wrote:
> >>>        
> >>>> Yes. As general interface, it may not work so well, but as test
> >>>> interface, it works quite well and useful.
> >>>>
> >>>> Do we have any mechanism to add a test only interface?
> >>>>          
> >>> I'd like to see what Luiz/Markus think but definitely only a human
> >>> monitor interface and probably prefix the command with a 'x-' prefix
> >>> to indicate that it's not a supported interface.
> >>>
> >>>        
> >> Automated testing will want to use qmp.
> >>      
> > Yes. The main usage of the interface is automated testing.
> >    
> 
> That's precisely what the command should not be used for.
> 
> You can't assume a gpa -> hva mapping is consistent in an external 
> application.  If you want to implement an interface for testing, you 
> have to push more of the logic into QEMU to avoid the race.

>From the code of cpu_physical_memory_map(), it seems that if the 'addr'
is physical address in RAM, the mapping should be consistent at least
for x86, doesn't it?

Best Regards,
Huang Ying

Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address

[Avi Kivity]

On 11/08/2010 05:39 AM, Anthony Liguori wrote:
>> Yes. The main usage of the interface is automated testing.
>
> That's precisely what the command should not be used for.
>
> You can't assume a gpa -> hva mapping is consistent in an external 
> application.  If you want to implement an interface for testing, you 
> have to push more of the logic into QEMU to avoid the race.

An alternative is to use -mempath.  Does poisoning work for tmpfs?

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address

[Avi Kivity]

On 11/10/2010 08:56 AM, Avi Kivity wrote:
> On 11/08/2010 05:39 AM, Anthony Liguori wrote:
>>> Yes. The main usage of the interface is automated testing.
>>
>> That's precisely what the command should not be used for.
>>
>> You can't assume a gpa -> hva mapping is consistent in an external 
>> application.  If you want to implement an interface for testing, you 
>> have to push more of the logic into QEMU to avoid the race.
>
> An alternative is to use -mempath.  Does poisoning work for tmpfs?
>

Or hugetlbfs - I think it does?

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address

[Huang Ying]

On Wed, 2010-11-10 at 14:59 +0800, Avi Kivity wrote:
> On 11/10/2010 08:56 AM, Avi Kivity wrote:
> > On 11/08/2010 05:39 AM, Anthony Liguori wrote:
> >>> Yes. The main usage of the interface is automated testing.
> >>
> >> That's precisely what the command should not be used for.
> >>
> >> You can't assume a gpa -> hva mapping is consistent in an external 
> >> application.  If you want to implement an interface for testing, you 
> >> have to push more of the logic into QEMU to avoid the race.
> >
> > An alternative is to use -mempath.  Does poisoning work for tmpfs?
> >
> Or hugetlbfs - I think it does?

The QEMU support for hugetlbfs has some issues now. Because it is hard
for QEMU to deal with 2M poisoned page reported by host OS. Although it
is possible for QEMU to relay 2M poisoned page as MCE to guest OS, the
guest OS may not work properly for this kind of MCE.

Best Regards,
Huang Ying

Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address

[Huang Ying]

On Wed, 2010-11-10 at 14:56 +0800, Avi Kivity wrote:
> On 11/08/2010 05:39 AM, Anthony Liguori wrote:
> >> Yes. The main usage of the interface is automated testing.
> >
> > That's precisely what the command should not be used for.
> >
> > You can't assume a gpa -> hva mapping is consistent in an external 
> > application.  If you want to implement an interface for testing, you 
> > have to push more of the logic into QEMU to avoid the race.
> 
> An alternative is to use -mempath.  Does poisoning work for tmpfs?

Sorry for my stupid question. Why the gpa -> hva mapping is not
consistent for RAM if -mempath is not used?

Best Regards,
Huang Ying

Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address

[Avi Kivity]

On 11/10/2010 09:41 AM, Huang Ying wrote:
> On Wed, 2010-11-10 at 14:59 +0800, Avi Kivity wrote:
> >  On 11/10/2010 08:56 AM, Avi Kivity wrote:
> >  >  On 11/08/2010 05:39 AM, Anthony Liguori wrote:
> >  >>>  Yes. The main usage of the interface is automated testing.
> >  >>
> >  >>  That's precisely what the command should not be used for.
> >  >>
> >  >>  You can't assume a gpa ->  hva mapping is consistent in an external
> >  >>  application.  If you want to implement an interface for testing, you
> >  >>  have to push more of the logic into QEMU to avoid the race.
> >  >
> >  >  An alternative is to use -mempath.  Does poisoning work for tmpfs?
> >  >
> >  Or hugetlbfs - I think it does?
>
> The QEMU support for hugetlbfs has some issues now. Because it is hard
> for QEMU to deal with 2M poisoned page reported by host OS. Although it
> is possible for QEMU to relay 2M poisoned page as MCE to guest OS, the
> guest OS may not work properly for this kind of MCE.
>

If we get a full address (rather than just a frame number) then we can 
identify the 4k page and send an mce just for that frame?

-- 
error compiling committee.c: too many arguments to function

Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address

[Avi Kivity]

On 11/10/2010 10:21 AM, Huang Ying wrote:
> On Wed, 2010-11-10 at 14:56 +0800, Avi Kivity wrote:
> >  On 11/08/2010 05:39 AM, Anthony Liguori wrote:
> >  >>  Yes. The main usage of the interface is automated testing.
> >  >
> >  >  That's precisely what the command should not be used for.
> >  >
> >  >  You can't assume a gpa ->  hva mapping is consistent in an external
> >  >  application.  If you want to implement an interface for testing, you
> >  >  have to push more of the logic into QEMU to avoid the race.
> >
> >  An alternative is to use -mempath.  Does poisoning work for tmpfs?
>
> Sorry for my stupid question.

It is not a stupid question.

> Why the gpa ->  hva mapping is not
> consistent for RAM if -mempath is not used?

Video RAM in the range a0000-bffff and PCI mapped RAM can change gpas 
(while remaining in the same hva).

Even for ordinary RAM, which doesn't normally change gpa/hva, I'm not 
sure we want to guarantee that it won't.

-- 
error compiling committee.c: too many arguments to function

Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address

[Huang Ying]

On Wed, 2010-11-10 at 16:28 +0800, Avi Kivity wrote:
> On 11/10/2010 09:41 AM, Huang Ying wrote:
> > On Wed, 2010-11-10 at 14:59 +0800, Avi Kivity wrote:
> > >  On 11/10/2010 08:56 AM, Avi Kivity wrote:
> > >  >  On 11/08/2010 05:39 AM, Anthony Liguori wrote:
> > >  >>>  Yes. The main usage of the interface is automated testing.
> > >  >>
> > >  >>  That's precisely what the command should not be used for.
> > >  >>
> > >  >>  You can't assume a gpa ->  hva mapping is consistent in an external
> > >  >>  application.  If you want to implement an interface for testing, you
> > >  >>  have to push more of the logic into QEMU to avoid the race.
> > >  >
> > >  >  An alternative is to use -mempath.  Does poisoning work for tmpfs?
> > >  >
> > >  Or hugetlbfs - I think it does?
> >
> > The QEMU support for hugetlbfs has some issues now. Because it is hard
> > for QEMU to deal with 2M poisoned page reported by host OS. Although it
> > is possible for QEMU to relay 2M poisoned page as MCE to guest OS, the
> > guest OS may not work properly for this kind of MCE.
> >
> 
> If we get a full address (rather than just a frame number) then we can 
> identify the 4k page and send an mce just for that frame?

We need host kernel to break down the 2M huge page into 4k pages. Then
send SIGBUS to QEMU with the poisoned 4k page. Because host kernel will
poison the whole 2M virtual address space otherwise, and other 4k pages
inside the 2M page can not used accessed in guest (will trigger SIGBUS
and SRAR MCE).

Best Regards,
Huang Ying

Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address

[Avi Kivity]

On 11/10/2010 10:38 AM, Huang Ying wrote:
> >
> >  If we get a full address (rather than just a frame number) then we can
> >  identify the 4k page and send an mce just for that frame?
>
> We need host kernel to break down the 2M huge page into 4k pages. Then
> send SIGBUS to QEMU with the poisoned 4k page. Because host kernel will
> poison the whole 2M virtual address space otherwise, and other 4k pages
> inside the 2M page can not used accessed in guest (will trigger SIGBUS
> and SRAR MCE).
>

We could do that by using mmap(MAP_FIXED) or mremap().  It's probably 
not worth it just for testing, but it has a real use, no?

Note we may need to stop the guest while we copy memory.

-- 
error compiling committee.c: too many arguments to function

Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address

[Andi Kleen]

> We need host kernel to break down the 2M huge page into 4k pages. Then
> send SIGBUS to QEMU with the poisoned 4k page. Because host kernel will
> poison the whole 2M virtual address space otherwise, and other 4k pages
> inside the 2M page can not used accessed in guest (will trigger SIGBUS
> and SRAR MCE).

The easiest way would be to port the respective code from Andrea's 
transparent hugetlb patchkit. It already does break down huge pages
as needed. You just have to be careful to not touch (/copy) the corrupted
subpage.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.

Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address

[Anthony Liguori]

On 11/10/2010 02:34 AM, Avi Kivity wrote:
>> Why the gpa ->  hva mapping is not
>> consistent for RAM if -mempath is not used?
>
> Video RAM in the range a0000-bffff and PCI mapped RAM can change gpas 
> (while remaining in the same hva).
>
> Even for ordinary RAM, which doesn't normally change gpa/hva, I'm not 
> sure we want to guarantee that it won't.

We can't universally either.  Memory hot remove potentially breaks the 
mapping and some non-x86 architectures (like ARM) can alias RAM via a 
guest triggered mechanism.

Regards,

Anthony Liguori

Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address

[Avi Kivity]

On 11/10/2010 06:42 PM, Andi Kleen wrote:
> >  We need host kernel to break down the 2M huge page into 4k pages. Then
> >  send SIGBUS to QEMU with the poisoned 4k page. Because host kernel will
> >  poison the whole 2M virtual address space otherwise, and other 4k pages
> >  inside the 2M page can not used accessed in guest (will trigger SIGBUS
> >  and SRAR MCE).
>
> The easiest way would be to port the respective code from Andrea's
> transparent hugetlb patchkit. It already does break down huge pages
> as needed. You just have to be careful to not touch (/copy) the corrupted
> subpage.

Doing it in userspace in easier, since we can replace the vma for that 
section (and avoid mixed 4k/2M pages in hugetlbfs).

With transparent hugepages it's easy of course, you just call 
split_hugepage() and poison the 4k page.

-- 
error compiling committee.c: too many arguments to function

Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address

[Andi Kleen]

> Doing it in userspace in easier, since we can replace the vma for
> that section (and avoid mixed 4k/2M pages in hugetlbfs).

You can't do that today, there's no way currently to access the non corrupted
portion of the 2MB page. Once it's poisoned it's all gone.

-Andi
-- 
ak@linux.intel.com -- Speaking for myself only.

Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address

[Avi Kivity]

On 11/10/2010 07:44 PM, Andi Kleen wrote:
> >  Doing it in userspace in easier, since we can replace the vma for
> >  that section (and avoid mixed 4k/2M pages in hugetlbfs).
>
> You can't do that today, there's no way currently to access the non corrupted
> portion of the 2MB page. Once it's poisoned it's all gone.

I see.  Thanks.

-- 
error compiling committee.c: too many arguments to function

Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address

[Andi Kleen]

On Wed, Nov 10, 2010 at 07:47:11PM +0200, Avi Kivity wrote:
> On 11/10/2010 07:44 PM, Andi Kleen wrote:
> >>  Doing it in userspace in easier, since we can replace the vma for
> >>  that section (and avoid mixed 4k/2M pages in hugetlbfs).
> >
> >You can't do that today, there's no way currently to access the non corrupted
> >portion of the 2MB page. Once it's poisoned it's all gone.
> 
> I see.  Thanks.

BTW my understanding is that KVM will only use hugepages with
transparent huge pages anyways, correct?

So it may be reasonable to simply fix this as part of the transparent
hugepages work, but ignore it before that.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.

Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address

[Avi Kivity]

On 11/10/2010 09:16 PM, Andi Kleen wrote:
> On Wed, Nov 10, 2010 at 07:47:11PM +0200, Avi Kivity wrote:
> >  On 11/10/2010 07:44 PM, Andi Kleen wrote:
> >  >>   Doing it in userspace in easier, since we can replace the vma for
> >  >>   that section (and avoid mixed 4k/2M pages in hugetlbfs).
> >  >
> >  >You can't do that today, there's no way currently to access the non corrupted
> >  >portion of the 2MB page. Once it's poisoned it's all gone.
> >
> >  I see.  Thanks.
>
> BTW my understanding is that KVM will only use hugepages with
> transparent huge pages anyways, correct?

There will always be those who want full control over every last bit; 
they will use hugetlbfs and numactl for manual allocation of resources 
for guests.

General usage will be with transparent huge pages, though.

> So it may be reasonable to simply fix this as part of the transparent
> hugepages work, but ignore it before that.

Transparent hugepages work only for anonymous memory.

However, hugetlbfs is not the only option for backing -mempath memory; 
if poisoning works for tmpfs/shm or other file backed memory, we can use 
that to get named access to memory.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address

[Huang Ying]

On Thu, 2010-11-11 at 00:49 +0800, Anthony Liguori wrote:
> On 11/10/2010 02:34 AM, Avi Kivity wrote:
> >> Why the gpa ->  hva mapping is not
> >> consistent for RAM if -mempath is not used?
> >
> > Video RAM in the range a0000-bffff and PCI mapped RAM can change gpas 
> > (while remaining in the same hva).
> >
> > Even for ordinary RAM, which doesn't normally change gpa/hva, I'm not 
> > sure we want to guarantee that it won't.
> 
> We can't universally either.  Memory hot remove potentially breaks the 
> mapping and some non-x86 architectures (like ARM) can alias RAM via a 
> guest triggered mechanism.

Thanks for clarification. Now I think we have two options.

1) Clearly mark gpa2hva (pfa2hva now, should renamed to gpa2hva) as a
testing only interface, and should be used only on restricted
environment (normal memory, without hot-remove, maybe only on x86).

2) Find some way to lock the gpa -> hva mapping during operating. Such
as gpa2hva_begin and gpa2hva_end and lock the mapping in between.

I think 2) may be possible. But if there are no other users, why do that
for a test case? So I think 1) may be the better option.

Best Regards,
Huang Ying

Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address

[Avi Kivity]

On 11/11/2010 02:56 AM, Huang Ying wrote:
> On Thu, 2010-11-11 at 00:49 +0800, Anthony Liguori wrote:
> >  On 11/10/2010 02:34 AM, Avi Kivity wrote:
> >  >>  Why the gpa ->   hva mapping is not
> >  >>  consistent for RAM if -mempath is not used?
> >  >
> >  >  Video RAM in the range a0000-bffff and PCI mapped RAM can change gpas
> >  >  (while remaining in the same hva).
> >  >
> >  >  Even for ordinary RAM, which doesn't normally change gpa/hva, I'm not
> >  >  sure we want to guarantee that it won't.
> >
> >  We can't universally either.  Memory hot remove potentially breaks the
> >  mapping and some non-x86 architectures (like ARM) can alias RAM via a
> >  guest triggered mechanism.
>
> Thanks for clarification. Now I think we have two options.
>
> 1) Clearly mark gpa2hva (pfa2hva now, should renamed to gpa2hva) as a
> testing only interface, and should be used only on restricted
> environment (normal memory, without hot-remove, maybe only on x86).
>
> 2) Find some way to lock the gpa ->  hva mapping during operating. Such
> as gpa2hva_begin and gpa2hva_end and lock the mapping in between.
>
> I think 2) may be possible. But if there are no other users, why do that
> for a test case? So I think 1) may be the better option.
>

3) Move the poisoning code into qemu, so the command becomes

    posison-address <addr>

(though physical addresses aren't stable either)

4) Use -mempath on /dev/shm and poison a page in the backing file

(if poisoning works on tmpfs)

-- 
error compiling committee.c: too many arguments to function

Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address

[Huang Ying]

On Thu, 2010-11-11 at 17:39 +0800, Avi Kivity wrote:
> On 11/11/2010 02:56 AM, Huang Ying wrote:
> > On Thu, 2010-11-11 at 00:49 +0800, Anthony Liguori wrote:
> > >  On 11/10/2010 02:34 AM, Avi Kivity wrote:
> > >  >>  Why the gpa ->   hva mapping is not
> > >  >>  consistent for RAM if -mempath is not used?
> > >  >
> > >  >  Video RAM in the range a0000-bffff and PCI mapped RAM can change gpas
> > >  >  (while remaining in the same hva).
> > >  >
> > >  >  Even for ordinary RAM, which doesn't normally change gpa/hva, I'm not
> > >  >  sure we want to guarantee that it won't.
> > >
> > >  We can't universally either.  Memory hot remove potentially breaks the
> > >  mapping and some non-x86 architectures (like ARM) can alias RAM via a
> > >  guest triggered mechanism.
> >
> > Thanks for clarification. Now I think we have two options.
> >
> > 1) Clearly mark gpa2hva (pfa2hva now, should renamed to gpa2hva) as a
> > testing only interface, and should be used only on restricted
> > environment (normal memory, without hot-remove, maybe only on x86).
> >
> > 2) Find some way to lock the gpa ->  hva mapping during operating. Such
> > as gpa2hva_begin and gpa2hva_end and lock the mapping in between.
> >
> > I think 2) may be possible. But if there are no other users, why do that
> > for a test case? So I think 1) may be the better option.
> >
> 
> 3) Move the poisoning code into qemu, so the command becomes
> 
>     posison-address <addr>
> 
> (though physical addresses aren't stable either)

Poisoning includes:

a) gva -> gpa
b) gpa -> hva
c) hva -> hpa
d) inject the MCE into host via some external tool

poison-address need to do b, c, d. Do you think it is good to do all
these inside qemu?

> 4) Use -mempath on /dev/shm and poison a page in the backing file

If we can poison a page in the backing file, how do we know the
corresponding gpa and hpa?

Best Regards,
Huang Ying

Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address

[Avi Kivity]

On 11/12/2010 03:16 AM, Huang Ying wrote:
> On Thu, 2010-11-11 at 17:39 +0800, Avi Kivity wrote:
> >  On 11/11/2010 02:56 AM, Huang Ying wrote:
> >  >  On Thu, 2010-11-11 at 00:49 +0800, Anthony Liguori wrote:
> >  >  >   On 11/10/2010 02:34 AM, Avi Kivity wrote:
> >  >  >   >>   Why the gpa ->    hva mapping is not
> >  >  >   >>   consistent for RAM if -mempath is not used?
> >  >  >   >
> >  >  >   >   Video RAM in the range a0000-bffff and PCI mapped RAM can change gpas
> >  >  >   >   (while remaining in the same hva).
> >  >  >   >
> >  >  >   >   Even for ordinary RAM, which doesn't normally change gpa/hva, I'm not
> >  >  >   >   sure we want to guarantee that it won't.
> >  >  >
> >  >  >   We can't universally either.  Memory hot remove potentially breaks the
> >  >  >   mapping and some non-x86 architectures (like ARM) can alias RAM via a
> >  >  >   guest triggered mechanism.
> >  >
> >  >  Thanks for clarification. Now I think we have two options.
> >  >
> >  >  1) Clearly mark gpa2hva (pfa2hva now, should renamed to gpa2hva) as a
> >  >  testing only interface, and should be used only on restricted
> >  >  environment (normal memory, without hot-remove, maybe only on x86).
> >  >
> >  >  2) Find some way to lock the gpa ->   hva mapping during operating. Such
> >  >  as gpa2hva_begin and gpa2hva_end and lock the mapping in between.
> >  >
> >  >  I think 2) may be possible. But if there are no other users, why do that
> >  >  for a test case? So I think 1) may be the better option.
> >  >
> >
> >  3) Move the poisoning code into qemu, so the command becomes
> >
> >      posison-address<addr>
> >
> >  (though physical addresses aren't stable either)
>
> Poisoning includes:
>
> a) gva ->  gpa
> b) gpa ->  hva
> c) hva ->  hpa
> d) inject the MCE into host via some external tool
>
> poison-address need to do b, c, d. Do you think it is good to do all
> these inside qemu?

If d is not too complicated (an ioctl?), we might to it in qemu.

> >  4) Use -mempath on /dev/shm and poison a page in the backing file
>
> If we can poison a page in the backing file, how do we know the
> corresponding gpa and hpa?

I think you currently can't know it's gpa (why do you want to?); the 
upcoming NUMA enhancements should allow this (the plan is to have a file 
per guest NUMA node, so we can tell the host what policy to apply for 
that node).

gpa->hpa translation can be derived from /proc/pid/maps.

-- 
error compiling committee.c: too many arguments to function

Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address

[Avi Kivity]

On 11/14/2010 01:08 PM, Avi Kivity wrote:
>
>> >  4) Use -mempath on /dev/shm and poison a page in the backing file
>>
>> If we can poison a page in the backing file, how do we know the
>> corresponding gpa and hpa?
>
> I think you currently can't know it's gpa (why do you want to?); the 
> upcoming NUMA enhancements should allow this (the plan is to have a 
> file per guest NUMA node, so we can tell the host what policy to apply 
> for that node).
>
> gpa->hpa translation can be derived from /proc/pid/maps.
>

That would be gpa->hva.

-- 
error compiling committee.c: too many arguments to function

Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address

[Huang Ying]

On Sun, 2010-11-14 at 19:08 +0800, Avi Kivity wrote:
> On 11/12/2010 03:16 AM, Huang Ying wrote:
> > On Thu, 2010-11-11 at 17:39 +0800, Avi Kivity wrote:
> > >  On 11/11/2010 02:56 AM, Huang Ying wrote:
> > >  >  On Thu, 2010-11-11 at 00:49 +0800, Anthony Liguori wrote:
> > >  >  >   On 11/10/2010 02:34 AM, Avi Kivity wrote:
> > >  >  >   >>   Why the gpa ->    hva mapping is not
> > >  >  >   >>   consistent for RAM if -mempath is not used?
> > >  >  >   >
> > >  >  >   >   Video RAM in the range a0000-bffff and PCI mapped RAM can change gpas
> > >  >  >   >   (while remaining in the same hva).
> > >  >  >   >
> > >  >  >   >   Even for ordinary RAM, which doesn't normally change gpa/hva, I'm not
> > >  >  >   >   sure we want to guarantee that it won't.
> > >  >  >
> > >  >  >   We can't universally either.  Memory hot remove potentially breaks the
> > >  >  >   mapping and some non-x86 architectures (like ARM) can alias RAM via a
> > >  >  >   guest triggered mechanism.
> > >  >
> > >  >  Thanks for clarification. Now I think we have two options.
> > >  >
> > >  >  1) Clearly mark gpa2hva (pfa2hva now, should renamed to gpa2hva) as a
> > >  >  testing only interface, and should be used only on restricted
> > >  >  environment (normal memory, without hot-remove, maybe only on x86).
> > >  >
> > >  >  2) Find some way to lock the gpa ->   hva mapping during operating. Such
> > >  >  as gpa2hva_begin and gpa2hva_end and lock the mapping in between.
> > >  >
> > >  >  I think 2) may be possible. But if there are no other users, why do that
> > >  >  for a test case? So I think 1) may be the better option.
> > >  >
> > >
> > >  3) Move the poisoning code into qemu, so the command becomes
> > >
> > >      posison-address<addr>
> > >
> > >  (though physical addresses aren't stable either)
> >
> > Poisoning includes:
> >
> > a) gva ->  gpa
> > b) gpa ->  hva
> > c) hva ->  hpa
> > d) inject the MCE into host via some external tool
> >
> > poison-address need to do b, c, d. Do you think it is good to do all
> > these inside qemu?
> 
> If d is not too complicated (an ioctl?), we might to it in qemu.

The issue of d) is that there are multiple ways to inject MCE. Now one
software based, one APEI based, and maybe some others in the future.
They all use different interfaces. And as debug interface, there are not
considered kernel ABI too (some are in debugfs). So I think it is better
to use these ABI only in some test suite.

Best Regards,
Huang Ying

Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address

[Andi Kleen]

> The issue of d) is that there are multiple ways to inject MCE. Now one
> software based, one APEI based, and maybe some others in the future.
> They all use different interfaces. And as debug interface, there are not
> considered kernel ABI too (some are in debugfs). So I think it is better
> to use these ABI only in some test suite.

In some cases the injection may be also through external hardware
debugging mechanisms. So yes requiring that in qemu isn't a good
idea.

-Andi
-- 
ak@linux.intel.com -- Speaking for myself only.