Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address
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 -- a...@linux.intel.com -- Speaking for myself only. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address
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 a-b 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-addressaddr (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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address
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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address
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 a-b 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-addressaddr (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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address
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 a-b 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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address
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 a-b 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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address
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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address
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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address
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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address
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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address
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 a-b 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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address
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 -- a...@linux.intel.com -- Speaking for myself only. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address
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 a-b 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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address
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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address
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 -- a...@linux.intel.com -- Speaking for myself only. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address
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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address
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 -- a...@linux.intel.com -- Speaking for myself only. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address
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. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address
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 a-b 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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address
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. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address
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. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address
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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address
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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address
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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address
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
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address
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'] } ?
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address
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
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address
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.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address
On Mon, 01 Nov 2010 14:22:21 -0500 Anthony Liguori aligu...@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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address
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 Asbockmasb...@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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address
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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address
Author: Max Asbock masb...@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 masb...@linux.vnet.ibm.com
Signed-off-by: Jiajia Zheng jiajia.zh...@intel.com
Signed-off-by: Huang Ying ying.hu...@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 = ,
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
