Re: The status about vhost-net on kvm-arm?
On 08/12/2014 04:41 AM, Li Liu wrote: Hi all, Is anyone there can tell the current status of vhost-net on kvm-arm? Half a year has passed from Isa Ansharullah asked this question: http://www.spinics.net/lists/kvm-arm/msg08152.html I have found two patches which have provided the kvm-arm support of eventfd and irqfd: 1) [RFC PATCH 0/4] ARM: KVM: Enable the ioeventfd capability of KVM on ARM http://lists.gnu.org/archive/html/qemu-devel/2014-01/msg01770.html 2) [RFC,v3] ARM: KVM: add irqfd and irq routing support https://patches.linaro.org/32261/ Hi Li, The patch below uses Paul Mackerras' work and removed usage of GSI routing table. It is a simpler alternative to 2) http://www.spinics.net/lists/kvm/msg106535.html And there's a rough patch for qemu to support eventfd from Ying-Shiuan Pan: [Qemu-devel] [PATCH 0/4] ioeventfd support for virtio-mmio https://lists.gnu.org/archive/html/qemu-devel/2014-02/msg00715.html But there no any comments of this patch. And I can found nothing about qemu to support irqfd. Do I lost the track? Actually I am using irqfd in QEMU VFIO Platform device https://lists.nongnu.org/archive/html/qemu-devel/2014-08/msg01455.html Best Regards Eric If nobody try to fix it. We have a plan to complete it about virtio-mmio supporing irqfd and multiqueue. -- 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 -- 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
[Bug 82211] New: [Nested xen on kvm] L1 guest panic and reboot when L1 guest boot up.
https://bugzilla.kernel.org/show_bug.cgi?id=82211 Bug ID: 82211 Summary: [Nested xen on kvm] L1 guest panic and reboot when L1 guest boot up. Product: Virtualization Version: unspecified Kernel Version: 3.16.0 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: kvm Assignee: virtualization_...@kernel-bugs.osdl.org Reporter: chao.z...@intel.com Regression: No Environment: Host OS (ia32/ia32e/IA64):ia32e Guest OS (ia32/ia32e/IA64):ia32e Guest OS Type (Linux/Windows):Linux kvm.git Commit:c77dcacb397519b6ade8f08201a4a90a7f4f751e qemu.git Commit:2d591ce2aeebf9620ff527c7946844a3122afeec Host Kernel Version:3.16.0 Hardware:Romley_EP, Haswell_EP, Ivytown_EP Bug detailed description: -- L1(xen on kvm) guest panic then reboot continuously when boot up L1 guest. note: this is a kernel bug: kvm.git + qemu.git = result c77dcacb + 2d591ce2 = bad 9f6226a7 + 2d591ce2 = good Reproduce steps: 1. create guest qemu-system-x86_64 -enable-kvm -m 4G -smp 2 -net nic,macaddr=00:13:13:51:51:15 -net tap,script=/etc/kvm/qemu-ifup nested-xen.qcow -cpu host Current result: L1 guest panic then reboot continuously Expected result: L1 guest boot up correctly Basic root-causing log: -- You are receiving this mail because: You are watching the assignee of the bug. -- 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
[Bug 82211] [Nested xen on kvm] L1 guest panic and reboot when L1 guest boot up.
https://bugzilla.kernel.org/show_bug.cgi?id=82211 --- Comment #1 from Zhou, Chao chao.z...@intel.com --- the first bad commit is: commit 6addfc42992be4b073c39137ecfdf4b2aa2d487f Author: Paolo Bonzini pbonz...@redhat.com Date: Thu Mar 27 11:29:28 2014 +0100 KVM: x86: avoid useless set of KVM_REQ_EVENT after emulation Despite the provisions to emulate up to 130 consecutive instructions, in practice KVM will emulate just one before exiting handle_invalid_guest_state because x86_emulate_instruction always sets KVM_REQ_EVENT. However, we only need to do this if an interrupt could be injected, which happens a) if an interrupt shadow bit (STI or MOV SS) has gone away; b) if the interrupt flag has just been set (other instructions than STI can set it without enabling an interrupt shadow). This cuts another 700-900 cycles from the cost of emulating an instruction (measured on a Sandy Bridge Xeon: 1650-2600 cycles before the patch on kvm-unit-tests, 925-1700 afterwards). Signed-off-by: Paolo Bonzini pbonz...@redhat.com -- You are receiving this mail because: You are watching the assignee of the bug. -- 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 7/7 v3] KVM: PPC: BOOKE: Emulate debug registers and exception
-Original Message-
From: Wood Scott-B07421
Sent: Tuesday, August 12, 2014 5:30 AM
To: Bhushan Bharat-R65777
Cc: ag...@suse.de; kvm-...@vger.kernel.org; kvm@vger.kernel.org; Yoder Stuart-
B08248
Subject: Re: [PATCH 7/7 v3] KVM: PPC: BOOKE: Emulate debug registers and
exception
On Wed, 2014-08-06 at 12:08 +0530, Bharat Bhushan wrote:
@@ -1249,6 +1284,7 @@ int kvmppc_subarch_vcpu_init(struct kvm_vcpu *vcpu)
setup_timer(vcpu-arch.wdt_timer, kvmppc_watchdog_func,
(unsigned long)vcpu);
+ kvmppc_clear_dbsr();
return 0;
This could use a comment for why we're doing this. Also, I'm a bit uneasy
about
clearing the whole DBSR here, where we haven't yet switched the debug
registers
to guest context.
I think we wanted MRR to not cause debug event to guest, So should we only
clear MRR ?
It shouldn't actually matter except for deferred debug
exceptions which are not actually useful (in fact e6500 removed support for
them),
Exactly, that's why I was clearing complete DBSR. Probably we can have a comment
Do not let previously set debug events visible to guest. As deferred debug
events
are not supported, so it is ok to clear complete DBSR.
Thanks
-Bharat
but still...
-Scott
N�r��yb�X��ǧv�^�){.n�+h����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?��)ߢf
[Bug 82211] [Nested xen on kvm] L1 guest panic and reboot when L1 guest boot up.
https://bugzilla.kernel.org/show_bug.cgi?id=82211 --- Comment #2 from Zhou, Chao chao.z...@intel.com --- Created attachment 146291 -- https://bugzilla.kernel.org/attachment.cgi?id=146291action=edit L1 serial log -- You are receiving this mail because: You are watching the assignee of the bug. -- 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] vhost: Add polling mode
On Mon, Aug 11, 2014 at 12:46:21PM -0700, David Miller wrote: From: Michael S. Tsirkin m...@redhat.com Date: Sun, 10 Aug 2014 21:45:59 +0200 On Sun, Aug 10, 2014 at 11:30:35AM +0300, Razya Ladelsky wrote: ... And, did your tests actually produce 100% load on both host CPUs? ... Michael, please do not quote an entire patch just to ask a one line question. I truly, truly, wish it was simpler in modern email clients to delete the unrelated quoted material because I bet when people do this they are simply being lazy. Thank you. Lazy - mea culpa, though I'm using mutt so it isn't even hard. The question still stands: the test results are only valid if CPU was at 100% in all configurations. This is the reason I generally prefer it when people report throughput divided by CPU (power would be good too but it still isn't easy for people to get that number). -- MST -- 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
LPC IOMMU and VFIO MicroConference - Call for Participation
LPC IOMMU and VFIO MicroConference - Call for Participation === We are pleased to announce that this year there will be the first IOMMU and VFIO MicroConference held at Linux Plumbers Conference in Düsseldorf. An initial request for support of this micro conference generated, among others, the following possible topic ideas: * Improving generic IOMMU code and move code out of drivers * IOMMU device error handling * IOMMU Power Management * Virtualizing IOMMUs * Interface between IOMMUs an memory management More suggested topics can be found at the wiki page of the micro conference: http://wiki.linuxplumbersconf.org/2014:iommu_microconference We now ask for formal proposals for these discussions along with any other topics or problems that need to be discussed in this area. The format of the micro conference will be roughly half-hour slots for each topic, where the discussion lead gives a short introduction to the problem and maybe sketches possible solutions. The rest of the slot is open for discussions so that we come to an agreement how to move forward. Please submit your formal proposal on the Linux Plumbers website (OpenID login required) until August 31st at: http://www.linuxplumbersconf.org/2014/how-to-submit-microconference-discussions-topics/ Hope to see you in Düsseldorf! Joerg Roedel and Alex Williamson -- 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 v9 2/4] arm: ARMv7 dirty page logging inital mem region write protect (w/no huge PUD support)
On Mon, Aug 11, 2014 at 05:16:21PM -0700, Mario Smarduch wrote:
On 08/11/2014 12:12 PM, Christoffer Dall wrote:
Remove the parenthesis from the subject line.
I just prefer not having the (w/no huge PUD support) part in the patch
title.
Hmmm have to check this don't see it my patch file.
On Thu, Jul 24, 2014 at 05:56:06PM -0700, Mario Smarduch wrote:
Patch adds support for initial write protection VM memlsot. This patch
series
^^^
stray whitespace of
Need to watch out for these adds delays to review cycle.
yes, I care quite a lot about proper English, syntax, grammar and
spelling. Reading critically through your own patch files before
mailing them out is a good exercise. You can even consider putting them
through a spell-checker and/or configure your editor to mark double
white space, trailing white space etc.
[...]
+ do {
+ next = kvm_pmd_addr_end(addr, end);
+ if (!pmd_none(*pmd)) {
+ if (kvm_pmd_huge(*pmd)) {
+ if (!kvm_s2pmd_readonly(pmd))
+ kvm_set_s2pmd_readonly(pmd);
+ } else
+ stage2_wp_pte_range(pmd, addr, next);
please use a closing brace when the first part of the if-statement is a
multi-line block with braces, as per the CodingStyle.
Will fix.
+
stray blank line
Not sure how it got by checkpatch, will fix.
Not sure checkpatch will complain, but I do ;) No big deal anyway.
+ }
+ } while (pmd++, addr = next, addr != end);
+}
+
+/**
+ * stage2_wp_pud_range - write protect PUD range
+ * @kvm: pointer to kvm structure
+ * @pud: pointer to pgd entry
pgd
+ * @addr:range start address
+ * @end: range end address
+ *
+ * While walking the PUD range huge PUD pages are ignored, in the future
this
range, huge PUDs are ignored. In the future...
+ * may need to be revisited. Determine how to handle huge PUDs when
logging
+ * of dirty pages is enabled.
I don't understand the last sentence?
Probably last two sentences should be combined.
to determine how to handle huge PUT Would that be
clear enough?
The overall theme is what to do about PUDs - mark all pages dirty
in the region, attempt to breakup such huge regions?
I think you should just state that this is not supported and worry
about how to deal with it when it's properly supported. The TODO below
is sufficient, so just drop all mentionings about the future in the
function description above - it's likely to be forgotten when PUDs are
in fact support anyhow.
Thanks,
-Christoffer
--
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
[Bug 81841] amd-iommu: kernel BUG lockup after shutting down KVM guest using PCI passthrough/PCIe bridge
https://bugzilla.kernel.org/show_bug.cgi?id=81841 Joerg Roedel j...@8bytes.org changed: What|Removed |Added CC||j...@8bytes.org --- Comment #12 from Joerg Roedel j...@8bytes.org --- Created attachment 146311 -- https://bugzilla.kernel.org/attachment.cgi?id=146311action=edit Possible fix as a patch against v3.13 Hi Marti, Can you please test this patch? I think it should fix the issue. Thanks, Joerg -- You are receiving this mail because: You are watching the assignee of the bug. -- 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 v9 2/4] arm: ARMv7 dirty page logging inital mem region write protect (w/no huge PUD support)
On Mon, Aug 11, 2014 at 06:36:14PM -0700, Mario Smarduch wrote:
On 08/11/2014 12:12 PM, Christoffer Dall wrote:
[...]
+/**
+ * stage2_wp_range() - write protect stage2 memory region range
+ * @kvm: The KVM pointer
+ * @start:Start address of range
+ * end: End address of range
+ */
+static void stage2_wp_range(struct kvm *kvm, phys_addr_t addr,
phys_addr_t end)
+{
+ pgd_t *pgd;
+ phys_addr_t next;
+
+ pgd = kvm-arch.pgd + pgd_index(addr);
+ do {
+ /*
+ * Release kvm_mmu_lock periodically if the memory region is
+ * large features like detect hung task, lock detector or lock
large. Otherwise, we may see panics due to..
+ * dep may panic. In addition holding the lock this long will
extra white space ^^ Additionally, holding the lock for a
long timer will
+ * also starve other vCPUs. Applies to huge VM memory regions.
^^^ I don't understand this
last remark.
Sorry overlooked this.
While testing - VM regions that were small (~1GB) holding the mmu_lock
caused not problems, but when I was running memory regions around 2GB large
some kernel lockup detection/lock contention options (some selected by
default)
caused deadlock warnings/panics in host kernel.
This was in one my previous review comments sometime ago, I can go back
and find the options.
Just drop the last part of the comment, so the whole thing reads:
/*
* Release kvm_mmu_lock periodically if the memory region is
* large. Otherwise, we may see kernel panics from debugging features
* such as detect hung task, lock detector or lock dep checks.
* Additionally, holding the lock too long will also starve other vCPUs.
*/
And check the actual names of those debugging features or use the
CONFIG_WHATEVER names and say we may see kernel panics with CONFIG_X,
CONFIG_Y, and CONFIG_Z.
Makes sense?
-Christoffer
--
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 v9 4/4] arm: ARMv7 dirty page logging 2nd stage page fault handling support
On Mon, Aug 11, 2014 at 06:25:05PM -0700, Mario Smarduch wrote:
On 08/11/2014 12:13 PM, Christoffer Dall wrote:
On Thu, Jul 24, 2014 at 05:56:08PM -0700, Mario Smarduch wrote:
This patch adds support for handling 2nd stage page faults during
migration,
it disables faulting in huge pages, and dissolves huge pages to page
tables.
In case migration is canceled huge pages will be used again.
Signed-off-by: Mario Smarduch m.smard...@samsung.com
---
arch/arm/kvm/mmu.c | 31 +--
1 file changed, 25 insertions(+), 6 deletions(-)
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index ca84331..a17812a 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -642,7 +642,8 @@ static int stage2_set_pmd_huge(struct kvm *kvm, struct
kvm_mmu_memory_cache
}
static int stage2_set_pte(struct kvm *kvm, struct kvm_mmu_memory_cache
*cache,
-phys_addr_t addr, const pte_t *new_pte, bool iomap)
+phys_addr_t addr, const pte_t *new_pte, bool iomap,
+bool logging_active)
{
pmd_t *pmd;
pte_t *pte, old_pte;
@@ -657,6 +658,15 @@ static int stage2_set_pte(struct kvm *kvm, struct
kvm_mmu_memory_cache *cache,
return 0;
}
+ /*
+ * While dirty memory logging, clear PMD entry for huge page and split
+ * into smaller pages, to track dirty memory at page granularity.
+ */
+ if (logging_active kvm_pmd_huge(*pmd)) {
+ phys_addr_t ipa = pmd_pfn(*pmd) PAGE_SHIFT;
+ clear_pmd_entry(kvm, pmd, ipa);
clear_pmd_entry has a VM_BUG_ON(kvm_pmd_huge(*pmd)) so that is
definitely not the right thing to call.
I don't see that in 3.15rc1/rc4 -
static void clear_pmd_entry(struct kvm *kvm, pmd_t *pmd, phys_addr_t addr)
{
if (kvm_pmd_huge(*pmd)) {
pmd_clear(pmd);
kvm_tlb_flush_vmid_ipa(kvm, addr);
} else {
[]
}
I thought the purpose of this function was to clear PMD entry. Also
ran hundreds of tests no problems. Hmmm confused.
You need to rebase on kvm/next or linus/master, something that contains:
4f853a7 arm/arm64: KVM: Fix and refactor unmap_range
+ }
+
/* Create stage-2 page mappings - Level 2 */
if (pmd_none(*pmd)) {
if (!cache)
@@ -709,7 +719,7 @@ int kvm_phys_addr_ioremap(struct kvm *kvm, phys_addr_t
guest_ipa,
if (ret)
goto out;
spin_lock(kvm-mmu_lock);
- ret = stage2_set_pte(kvm, cache, addr, pte, true);
+ ret = stage2_set_pte(kvm, cache, addr, pte, true, false);
spin_unlock(kvm-mmu_lock);
if (ret)
goto out;
@@ -926,6 +936,12 @@ static int user_mem_abort(struct kvm_vcpu *vcpu,
phys_addr_t fault_ipa,
struct kvm_mmu_memory_cache *memcache = vcpu-arch.mmu_page_cache;
struct vm_area_struct *vma;
pfn_t pfn;
+ /* Get logging status, if dirty_bitmap is not NULL then logging is on */
+ #ifdef CONFIG_ARM
+ bool logging_active = !!memslot-dirty_bitmap;
+ #else
+ bool logging_active = false;
+ #endif
can you make this an inline in the header files for now please?
Yes definitely.
write_fault = kvm_is_write_fault(kvm_vcpu_get_hsr(vcpu));
if (fault_status == FSC_PERM !write_fault) {
@@ -936,7 +952,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu,
phys_addr_t fault_ipa,
/* Let's check if we will get back a huge page backed by hugetlbfs */
down_read(current-mm-mmap_sem);
vma = find_vma_intersection(current-mm, hva, hva + 1);
- if (is_vm_hugetlb_page(vma)) {
+ if (is_vm_hugetlb_page(vma) !logging_active) {
hugetlb = true;
gfn = (fault_ipa PMD_MASK) PAGE_SHIFT;
} else {
@@ -979,7 +995,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu,
phys_addr_t fault_ipa,
spin_lock(kvm-mmu_lock);
if (mmu_notifier_retry(kvm, mmu_seq))
goto out_unlock;
- if (!hugetlb !force_pte)
+ if (!hugetlb !force_pte !logging_active)
hugetlb = transparent_hugepage_adjust(pfn, fault_ipa);
if (hugetlb) {
@@ -998,9 +1014,12 @@ static int user_mem_abort(struct kvm_vcpu *vcpu,
phys_addr_t fault_ipa,
kvm_set_pfn_dirty(pfn);
}
coherent_cache_guest_page(vcpu, hva, PAGE_SIZE);
- ret = stage2_set_pte(kvm, memcache, fault_ipa, new_pte, false);
+ ret = stage2_set_pte(kvm, memcache, fault_ipa, new_pte, false,
+ logging_active);
}
+ if (write_fault)
+ mark_page_dirty(kvm, gfn);
out_unlock:
spin_unlock(kvm-mmu_lock);
@@ -1151,7 +1170,7 @@ static void kvm_set_spte_handler(struct kvm *kvm,
gpa_t gpa, void *data)
{
pte_t *pte = (pte_t *)data;
- stage2_set_pte(kvm, NULL, gpa,
Re: [PATCH 6/7 v3] KVM: PPC: BOOKE: Add one reg interface for DBSR
On 06.08.14 08:38, Bharat Bhushan wrote:
Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com
---
v2-v3
- New patch
arch/powerpc/include/uapi/asm/kvm.h | 1 +
arch/powerpc/kvm/booke.c| 6 ++
2 files changed, 7 insertions(+)
diff --git a/arch/powerpc/include/uapi/asm/kvm.h
b/arch/powerpc/include/uapi/asm/kvm.h
index e0e49db..3ca357a 100644
--- a/arch/powerpc/include/uapi/asm/kvm.h
+++ b/arch/powerpc/include/uapi/asm/kvm.h
@@ -557,6 +557,7 @@ struct kvm_get_htab_header {
#define KVM_REG_PPC_DABRX (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0xb8)
#define KVM_REG_PPC_WORT (KVM_REG_PPC | KVM_REG_SIZE_U64 | 0xb9)
#define KVM_REG_PPC_SPRG9 (KVM_REG_PPC | KVM_REG_SIZE_U64 | 0xba)
+#define KVM_REG_PPC_DBSR (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0xbb)
Please write up a follow-up patch that adds SPRG9 and DBSR to
Documentation/virtual/kvm/api.txt.
Alex
--
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 0/7 v3] Guest debug emulation
On 06.08.14 08:38, Bharat Bhushan wrote: This patchset adds debug register and interrupt emulation support for guest, which enables running gdb/kgdb etc in guest. v2-v3 - Added One-reg interface for DBSR - removed arch-shadow_dbg_reg - Addressed some more comments on v2 (detail in individual patch) Thanks, applied patches 1-6 to kvm-ppc-queue. That way you only need to respin patch 7 and add the documentation patch. Alex -- 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 0/7 v3] Guest debug emulation
-Original Message- From: Alexander Graf [mailto:ag...@suse.de] Sent: Tuesday, August 12, 2014 3:55 PM To: Bhushan Bharat-R65777; kvm-...@vger.kernel.org Cc: kvm@vger.kernel.org; Wood Scott-B07421; Yoder Stuart-B08248 Subject: Re: [PATCH 0/7 v3] Guest debug emulation On 06.08.14 08:38, Bharat Bhushan wrote: This patchset adds debug register and interrupt emulation support for guest, which enables running gdb/kgdb etc in guest. v2-v3 - Added One-reg interface for DBSR - removed arch-shadow_dbg_reg - Addressed some more comments on v2 (detail in individual patch) Thanks, applied patches 1-6 to kvm-ppc-queue. That way you only need to respin patch 7 and add the documentation patch. Thanks Alex, I will add the documentation patch with next version on 7/7 patch. Regards -Bharat Alex -- 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
[Bug 81841] amd-iommu: kernel BUG lockup after shutting down KVM guest using PCI passthrough/PCIe bridge
https://bugzilla.kernel.org/show_bug.cgi?id=81841 --- Comment #13 from Marti Raudsepp ma...@juffo.org --- (In reply to Joerg Roedel from comment #12) Thanks, Joerg Indeed. Thanks, Joerg. And thanks everyone else too, you have been very helpful! I didn't have v3.13 sources handy, but I applied the attachment 146311 patch to 3.16.0 and it fixes the problem. (I verified that unpatched 3.16.0 also crashes). I can start shut down the VM multiple times without crashing the host and PCI passthrough works as expected. Feel free to add Tested-by: Marti Raudsepp ma...@juffo.org (In reply to Alex Williamson from comment #7) Note that it's not required to assign all the devices, they simply need to be detached from host drivers (ie. bound to pci-stub or vfio-pci). This approach also works; I think I will go this route for the production setup. Seems that we don't actually need any of the devices in the same IOMMU group. (In reply to Joel Schopp from comment #10) AMD would need to confirm it. I don't have an answer for you offhand. Let me do some digging and get you an answer. I am sorry if I sounded frustrated or arrogant earlier. Any update on this? -- You are receiving this mail because: You are watching the assignee of the bug. -- 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
[Bug 81841] amd-iommu: kernel BUG lockup after shutting down KVM guest using PCI passthrough/PCIe bridge
https://bugzilla.kernel.org/show_bug.cgi?id=81841 --- Comment #14 from Joerg Roedel j...@8bytes.org --- Hi Marti, Indeed. Thanks, Joerg. And thanks everyone else too, you have been very helpful! I didn't have v3.13 sources handy, but I applied the attachment 146311 I can start shut down the VM multiple times without crashing the host and PCI passthrough works as expected. Feel free to add Tested-by: Marti Raudsepp ma...@juffo.org Thanks for testing the fix, I will send it upstream once the merge window is over -rc1 is released. I also added a stable tag so it gets backported. Joerg -- You are receiving this mail because: You are watching the assignee of the bug. -- 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] vhost: Add polling mode
Michael S. Tsirkin m...@redhat.com wrote on 12/08/2014 12:18:50 PM: From: Michael S. Tsirkin m...@redhat.com To: David Miller da...@davemloft.net Cc: Razya Ladelsky/Haifa/IBM@IBMIL, kvm@vger.kernel.org, Alex Glikson/Haifa/IBM@IBMIL, Eran Raichstein/Haifa/IBM@IBMIL, Yossi Kuperman1/Haifa/IBM@IBMIL, Joel Nider/Haifa/IBM@IBMIL, abel.gor...@gmail.com, linux-ker...@vger.kernel.org, net...@vger.kernel.org, virtualizat...@lists.linux-foundation.org Date: 12/08/2014 12:18 PM Subject: Re: [PATCH] vhost: Add polling mode On Mon, Aug 11, 2014 at 12:46:21PM -0700, David Miller wrote: From: Michael S. Tsirkin m...@redhat.com Date: Sun, 10 Aug 2014 21:45:59 +0200 On Sun, Aug 10, 2014 at 11:30:35AM +0300, Razya Ladelsky wrote: ... And, did your tests actually produce 100% load on both host CPUs? ... Michael, please do not quote an entire patch just to ask a one line question. I truly, truly, wish it was simpler in modern email clients to delete the unrelated quoted material because I bet when people do this they are simply being lazy. Thank you. Lazy - mea culpa, though I'm using mutt so it isn't even hard. The question still stands: the test results are only valid if CPU was at 100% in all configurations. This is the reason I generally prefer it when people report throughput divided by CPU (power would be good too but it still isn't easy for people to get that number). Hi Michael, Sorry for the delay, had some problems with my mailbox, and I realized just now that my reply wasn't sent. The vm indeed ALWAYS utilized 100% cpu, whether polling was enabled or not. The vhost thread utilized less than 100% (of the other cpu) when polling was disabled. Enabling polling increased its utilization to 100% (in which case both cpus were 100% utilized). -- MST -- 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
E-mail Account Warning !!!
E-mail Account Warning !!! This mail is from Administrator; we wish to bring to your notice the Condition of your email account. We have just noticed that you have exceeded your email Database limit of 500 MB quota and your email IP is causing conflict because it is been accessed in different server location. You need to Upgrade and expand your email quota limit before you can continue to use your email. Provide details or click the link below : Update your email quota limit to 2.6 GB, use the below web link: https://www.formlogix.com/Manager/UserConditionalSurvey248932.aspx?Param=VXNlcklkPTI0ODkzMi5Gb3JtSWQ9MQ%3d%3d Failure to do this will result to email deactivation within 24hours Thank you for your understanding. Copyright 2014 Help Desk Email Upgrade -- 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 v3] powerpc/kvm: support to handle sw breakpoint
On 12.08.14 07:17, Madhavan Srinivasan wrote: On Monday 11 August 2014 02:45 PM, Alexander Graf wrote: On 11.08.14 10:51, Benjamin Herrenschmidt wrote: On Mon, 2014-08-11 at 09:26 +0200, Alexander Graf wrote: diff --git a/arch/powerpc/kvm/emulate.c b/arch/powerpc/kvm/emulate.c index da86d9b..d95014e 100644 --- a/arch/powerpc/kvm/emulate.c +++ b/arch/powerpc/kvm/emulate.c This should be book3s_emulate.c. Any reason we can't make that 0000 opcode as breakpoint common to all powerpc variants ? I can't think of a good reason. We use a hypercall on booke (which traps into an illegal instruction for pr) today, but I don't think it has to be that way. Given that the user space API allows us to change it dynamically, there should be nothing blocking us from going with 0000 always. Kindly correct me if i am wrong. So we can still have a common code in emulate.c to set the env for both HV and pr incase of illegal instruction (i will rebase latest src). But suggestion here to use 0000, in that case current path in embed is kvmppc_handle_exit (booke.c) - BOOKE_INTERRUPT_HV_PRIV - emulation_exit - kvmppc_emulate_instruction, will change to kvmppc_handle_exit (booke.c) - BOOKE_INTERRUPT_PROGRAM - if debug instr call emulation_exit else send to guest? I can't follow your description above. With the latest git version HV KVM does not include emulate.c anymore. Also, it would make a lot of sense of have the same soft breakpoint instruction across all ppc targets, so it would make sense to change it to 0x0000 for booke as well. Basically you would have handling code in emulate.c and book3s_hv.c at the end of the day. Alex -- 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 v3] powerpc/kvm: support to handle sw breakpoint
On Tuesday 12 August 2014 04:49 PM, Alexander Graf wrote: On 12.08.14 07:17, Madhavan Srinivasan wrote: On Monday 11 August 2014 02:45 PM, Alexander Graf wrote: On 11.08.14 10:51, Benjamin Herrenschmidt wrote: On Mon, 2014-08-11 at 09:26 +0200, Alexander Graf wrote: diff --git a/arch/powerpc/kvm/emulate.c b/arch/powerpc/kvm/emulate.c index da86d9b..d95014e 100644 --- a/arch/powerpc/kvm/emulate.c +++ b/arch/powerpc/kvm/emulate.c This should be book3s_emulate.c. Any reason we can't make that 0000 opcode as breakpoint common to all powerpc variants ? I can't think of a good reason. We use a hypercall on booke (which traps into an illegal instruction for pr) today, but I don't think it has to be that way. Given that the user space API allows us to change it dynamically, there should be nothing blocking us from going with 0000 always. Kindly correct me if i am wrong. So we can still have a common code in emulate.c to set the env for both HV and pr incase of illegal instruction (i will rebase latest src). But suggestion here to use 0000, in that case current path in embed is kvmppc_handle_exit (booke.c) - BOOKE_INTERRUPT_HV_PRIV - emulation_exit - kvmppc_emulate_instruction, will change to kvmppc_handle_exit (booke.c) - BOOKE_INTERRUPT_PROGRAM - if debug instr call emulation_exit else send to guest? I can't follow your description above. My bad. With the latest git version HV KVM does not include emulate.c anymore. Also, it would make a lot of sense of have the same soft breakpoint instruction across all ppc targets, so it would make sense to change it to 0x0000 for booke as well. Got it. Was describing the current control flow with respect to booke and where changes needed (for same software breakpoint inst). This is for my understanding and wanted verify. kvmppc_handle_exit(booke.c) - BOOKE_INTERRUPT_HV_PRIV - emulation_exit -kvmppc_emulate_instruction Incase of using the same software breakpoint instruction (0x0000), then we need to add code in booke something like this kvmppc_handle_exit (booke.c) - BOOKE_INTERRUPT_PROGRAM - if debug instr -emulation_exit else -send to guest? Basically you would have handling code in emulate.c and book3s_hv.c at the end of the day. Yes. Will resend the patch with updated code. Alex -- 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 v3 2/5] KVM: PPC: Book3e: Add AltiVec support
On 05.08.14 12:39, Mihai Caraman wrote:
Add KVM Book3e AltiVec support. KVM Book3e FPU support gracefully reuse host
infrastructure so follow the same approach for AltiVec.
Keep SPE/AltiVec exception handlers distinct using CONFIG_KVM_E500V2.
Signed-off-by: Mihai Caraman mihai.cara...@freescale.com
---
v3:
- use distinct SPE/AltiVec exception handlers
v2:
- integrate Paul's FP/VMX/VSX changes
arch/powerpc/kvm/booke.c | 73 +++
arch/powerpc/kvm/booke.h | 5 +++
arch/powerpc/kvm/bookehv_interrupts.S | 10 +++--
arch/powerpc/kvm/e500_emulate.c | 18 +
4 files changed, 102 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index 0c6f616..c5cca09 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -168,6 +168,40 @@ static void kvmppc_vcpu_sync_fpu(struct kvm_vcpu *vcpu)
#endif
}
+/*
+ * Simulate AltiVec unavailable fault to load guest state
+ * from thread to AltiVec unit.
+ * It requires to be called with preemption disabled.
+ */
+static inline void kvmppc_load_guest_altivec(struct kvm_vcpu *vcpu)
+{
+#ifdef CONFIG_ALTIVEC
+ if (cpu_has_feature(CPU_FTR_ALTIVEC)) {
+ if (!(current-thread.regs-msr MSR_VEC)) {
+ enable_kernel_altivec();
+ load_vr_state(vcpu-arch.vr);
+ current-thread.vr_save_area = vcpu-arch.vr;
+ current-thread.regs-msr |= MSR_VEC;
+ }
+ }
+#endif
+}
+
+/*
+ * Save guest vcpu AltiVec state into thread.
+ * It requires to be called with preemption disabled.
+ */
+static inline void kvmppc_save_guest_altivec(struct kvm_vcpu *vcpu)
+{
+#ifdef CONFIG_ALTIVEC
+ if (cpu_has_feature(CPU_FTR_ALTIVEC)) {
+ if (current-thread.regs-msr MSR_VEC)
+ giveup_altivec(current);
+ current-thread.vr_save_area = NULL;
+ }
+#endif
+}
+
static void kvmppc_vcpu_sync_debug(struct kvm_vcpu *vcpu)
{
/* Synchronize guest's desire to get debug interrupts into shadow MSR */
@@ -375,9 +409,14 @@ static int kvmppc_booke_irqprio_deliver(struct kvm_vcpu
*vcpu,
case BOOKE_IRQPRIO_ITLB_MISS:
case BOOKE_IRQPRIO_SYSCALL:
case BOOKE_IRQPRIO_FP_UNAVAIL:
+#ifdef CONFIG_KVM_E500V2
Why not use your new SPE_POSSIBLE define?
case BOOKE_IRQPRIO_SPE_UNAVAIL:
case BOOKE_IRQPRIO_SPE_FP_DATA:
case BOOKE_IRQPRIO_SPE_FP_ROUND:
+#else
We only ever support altivec capable CPUs with CONFIG_ALTIVEC, no? So
just make this a new #ifdef CONFIG_ALTIVEC
+ case BOOKE_IRQPRIO_ALTIVEC_UNAVAIL:
+ case BOOKE_IRQPRIO_ALTIVEC_ASSIST:
+#endif
case BOOKE_IRQPRIO_AP_UNAVAIL:
allowed = 1;
msr_mask = MSR_CE | MSR_ME | MSR_DE;
@@ -693,6 +732,17 @@ int kvmppc_vcpu_run(struct kvm_run *kvm_run, struct
kvm_vcpu *vcpu)
kvmppc_load_guest_fp(vcpu);
#endif
+#ifdef CONFIG_ALTIVEC
+ /* Save userspace AltiVec state in stack */
+ if (cpu_has_feature(CPU_FTR_ALTIVEC))
+ enable_kernel_altivec();
+ /*
+* Since we can't trap on MSR_VEC in GS-mode, we consider the guest
+* as always using the AltiVec.
+*/
+ kvmppc_load_guest_altivec(vcpu);
+#endif
+
/* Switch to guest debug context */
debug = vcpu-arch.shadow_dbg_reg;
switch_booke_debug_regs(debug);
@@ -715,6 +765,10 @@ int kvmppc_vcpu_run(struct kvm_run *kvm_run, struct
kvm_vcpu *vcpu)
kvmppc_save_guest_fp(vcpu);
#endif
+#ifdef CONFIG_ALTIVEC
+ kvmppc_save_guest_altivec(vcpu);
+#endif
+
out:
vcpu-mode = OUTSIDE_GUEST_MODE;
return ret;
@@ -999,6 +1053,7 @@ int kvmppc_handle_exit(struct kvm_run *run, struct
kvm_vcpu *vcpu,
r = RESUME_GUEST;
break;
+#ifdef CONFIG_KVM_E500V2
Why? We're already guarded by CONFIG_SPE
#ifdef CONFIG_SPE
case BOOKE_INTERRUPT_SPE_UNAVAIL: {
if (vcpu-arch.shared-msr MSR_SPE)
@@ -1040,7 +1095,24 @@ int kvmppc_handle_exit(struct kvm_run *run, struct
kvm_vcpu *vcpu,
run-hw.hardware_exit_reason = exit_nr;
r = RESUME_HOST;
break;
+#endif /* !CONFIG_SPE */
+#else
+/*
+ * On cores with Vector category, KVM is loaded only if CONFIG_ALTIVEC,
+ * see kvmppc_core_check_processor_compat().
+ */
+#ifdef CONFIG_ALTIVEC
... and CONFIG_ALTIVEC
+ case BOOKE_INTERRUPT_ALTIVEC_UNAVAIL:
+ kvmppc_booke_queue_irqprio(vcpu, BOOKE_IRQPRIO_ALTIVEC_UNAVAIL);
+ r = RESUME_GUEST;
+ break;
+
+ case BOOKE_INTERRUPT_ALTIVEC_ASSIST:
+ kvmppc_booke_queue_irqprio(vcpu, BOOKE_IRQPRIO_ALTIVEC_ASSIST);
+ r = RESUME_GUEST;
+ break;
#endif
+#endif /* !CONFIG_KVM_E500V2 */
case BOOKE_INTERRUPT_DATA_STORAGE:
Re: [PATCH v3 3/5] KVM: PPC: Move ONE_REG AltiVec support to powerpc
On 05.08.14 12:39, Mihai Caraman wrote: Make ONE_REG AltiVec support common across server and embedded implementations moving kvm_vcpu_ioctl_get_one_reg() and kvm_vcpu_ioctl_set_one_reg() functions to powerpc layer. Signed-off-by: Mihai Caraman mihai.cara...@freescale.com Please split this into 2 separate patches, one that makes ONE_REG generic and one that moves Altivec from book3s into the generic version. Alex -- 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 v3 4/5] KVM: PPC: Booke: Add ONE_REG IVORs support
On 05.08.14 12:39, Mihai Caraman wrote:
Add ONE_REG IVORs support, with IVORs 0-15 and 35 booke common.
Signed-off-by: Mihai Caraman mihai.cara...@freescale.com
---
v3:
- new patch
arch/powerpc/include/uapi/asm/kvm.h | 24 +++
arch/powerpc/kvm/booke.c| 132
arch/powerpc/kvm/e500.c | 42 +++-
arch/powerpc/kvm/e500mc.c | 32 +
4 files changed, 228 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/uapi/asm/kvm.h
b/arch/powerpc/include/uapi/asm/kvm.h
index 7a27ff0..174fed0 100644
--- a/arch/powerpc/include/uapi/asm/kvm.h
+++ b/arch/powerpc/include/uapi/asm/kvm.h
@@ -563,6 +563,30 @@ struct kvm_get_htab_header {
#define KVM_REG_PPC_WORT (KVM_REG_PPC | KVM_REG_SIZE_U64 | 0xb9)
#define KVM_REG_PPC_SPRG9 (KVM_REG_PPC | KVM_REG_SIZE_U64 | 0xba)
+/* Booke IVOR registers */
+#define KVM_REG_PPC_IVOR0 (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0xc0)
+#define KVM_REG_PPC_IVOR1 (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0xc1)
+#define KVM_REG_PPC_IVOR2 (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0xc2)
+#define KVM_REG_PPC_IVOR3 (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0xc3)
+#define KVM_REG_PPC_IVOR4 (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0xc4)
+#define KVM_REG_PPC_IVOR5 (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0xc5)
+#define KVM_REG_PPC_IVOR6 (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0xc6)
+#define KVM_REG_PPC_IVOR7 (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0xc7)
+#define KVM_REG_PPC_IVOR8 (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0xc8)
+#define KVM_REG_PPC_IVOR9 (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0xc9)
+#define KVM_REG_PPC_IVOR10 (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0xca)
+#define KVM_REG_PPC_IVOR11 (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0xcb)
+#define KVM_REG_PPC_IVOR12 (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0xcc)
+#define KVM_REG_PPC_IVOR13 (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0xcd)
+#define KVM_REG_PPC_IVOR14 (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0xce)
+#define KVM_REG_PPC_IVOR15 (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0xcf)
+#define KVM_REG_PPC_IVOR32 (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0xd0)
+#define KVM_REG_PPC_IVOR33 (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0xd1)
+#define KVM_REG_PPC_IVOR34 (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0xd2)
+#define KVM_REG_PPC_IVOR35 (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0xd3)
+#define KVM_REG_PPC_IVOR36 (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0xd4)
+#define KVM_REG_PPC_IVOR37 (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0xd5)
These should also get mentioned in Documentation/virtual/kvm/api.txt.
Otherwise looks nice :).
Alex
--
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 v3] powerpc/kvm: support to handle sw breakpoint
On 12.08.14 13:35, Madhavan Srinivasan wrote:
On Tuesday 12 August 2014 04:49 PM, Alexander Graf wrote:
On 12.08.14 07:17, Madhavan Srinivasan wrote:
On Monday 11 August 2014 02:45 PM, Alexander Graf wrote:
On 11.08.14 10:51, Benjamin Herrenschmidt wrote:
On Mon, 2014-08-11 at 09:26 +0200, Alexander Graf wrote:
diff --git a/arch/powerpc/kvm/emulate.c b/arch/powerpc/kvm/emulate.c
index da86d9b..d95014e 100644
--- a/arch/powerpc/kvm/emulate.c
+++ b/arch/powerpc/kvm/emulate.c
This should be book3s_emulate.c.
Any reason we can't make that 0000 opcode as breakpoint common to
all powerpc variants ?
I can't think of a good reason. We use a hypercall on booke (which traps
into an illegal instruction for pr) today, but I don't think it has to
be that way.
Given that the user space API allows us to change it dynamically, there
should be nothing blocking us from going with 0000 always.
Kindly correct me if i am wrong. So we can still have a common code in
emulate.c to set the env for both HV and pr incase of illegal
instruction (i will rebase latest src). But suggestion here to use
0000, in that case current path in embed is kvmppc_handle_exit
(booke.c) - BOOKE_INTERRUPT_HV_PRIV - emulation_exit -
kvmppc_emulate_instruction, will change to kvmppc_handle_exit (booke.c)
- BOOKE_INTERRUPT_PROGRAM - if debug instr call emulation_exit else
send to guest?
I can't follow your description above.
My bad.
With the latest git version HV KVM does not include emulate.c anymore.
Also, it would make a lot of sense of have the same soft breakpoint
instruction across all ppc targets, so it would make sense to change it
to 0x0000 for booke as well.
Got it. Was describing the current control flow with respect to booke
and where changes needed (for same software breakpoint inst). This is
for my understanding and wanted verify.
kvmppc_handle_exit(booke.c)
- BOOKE_INTERRUPT_HV_PRIV
- emulation_exit
-kvmppc_emulate_instruction
Incase of using the same software breakpoint instruction (0x0000),
then we need to add code in booke something like this
kvmppc_handle_exit (booke.c)
- BOOKE_INTERRUPT_PROGRAM
- if debug instr
-emulation_exit
else
-send to guest?
Bleks. I see your point. I guess you need something like this for booke:
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index 074b7fc..1fdeee0 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -876,6 +876,11 @@ int kvmppc_handle_exit(struct kvm_run *run, struct
kvm_vcpu *vcpu,
case BOOKE_INTERRUPT_HV_PRIV:
emulated = kvmppc_get_last_inst(vcpu, false, last_inst);
break;
+case BOOKE_INTERRUPT_PROGRAM:
+/* SW breakpoints arrive as illegal instructions on HV */
+if (vcpu-guest_debug KVM_GUESTDBG_USE_SW_BP)
+emulated = kvmppc_get_last_inst(vcpu, false, last_inst);
+break;
default:
break;
}
@@ -953,7 +958,8 @@ int kvmppc_handle_exit(struct kvm_run *run, struct
kvm_vcpu *vcpu,
break;
case BOOKE_INTERRUPT_PROGRAM:
-if (vcpu-arch.shared-msr (MSR_PR | MSR_GS)) {
+if ((vcpu-arch.shared-msr (MSR_PR | MSR_GS))
+(last_inst != KVMPPC_INST_SOFT_BREAKPOINT)) {
/*
* Program traps generated by user-level software must
* be handled by the guest kernel.
Basically you would have handling code in emulate.c and book3s_hv.c at
the end of the day.
Yes. Will resend the patch with updated code.
Thanks,
Alex
--
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 v3] powerpc/kvm: support to handle sw breakpoint
On Tuesday 12 August 2014 05:45 PM, Alexander Graf wrote:
On 12.08.14 13:35, Madhavan Srinivasan wrote:
On Tuesday 12 August 2014 04:49 PM, Alexander Graf wrote:
On 12.08.14 07:17, Madhavan Srinivasan wrote:
On Monday 11 August 2014 02:45 PM, Alexander Graf wrote:
On 11.08.14 10:51, Benjamin Herrenschmidt wrote:
On Mon, 2014-08-11 at 09:26 +0200, Alexander Graf wrote:
diff --git a/arch/powerpc/kvm/emulate.c
b/arch/powerpc/kvm/emulate.c
index da86d9b..d95014e 100644
--- a/arch/powerpc/kvm/emulate.c
+++ b/arch/powerpc/kvm/emulate.c
This should be book3s_emulate.c.
Any reason we can't make that 0000 opcode as breakpoint common to
all powerpc variants ?
I can't think of a good reason. We use a hypercall on booke (which
traps
into an illegal instruction for pr) today, but I don't think it has to
be that way.
Given that the user space API allows us to change it dynamically,
there
should be nothing blocking us from going with 0000 always.
Kindly correct me if i am wrong. So we can still have a common code in
emulate.c to set the env for both HV and pr incase of illegal
instruction (i will rebase latest src). But suggestion here to use
0000, in that case current path in embed is kvmppc_handle_exit
(booke.c) - BOOKE_INTERRUPT_HV_PRIV - emulation_exit -
kvmppc_emulate_instruction, will change to kvmppc_handle_exit (booke.c)
- BOOKE_INTERRUPT_PROGRAM - if debug instr call emulation_exit else
send to guest?
I can't follow your description above.
My bad.
With the latest git version HV KVM does not include emulate.c anymore.
Also, it would make a lot of sense of have the same soft breakpoint
instruction across all ppc targets, so it would make sense to change it
to 0x0000 for booke as well.
Got it. Was describing the current control flow with respect to booke
and where changes needed (for same software breakpoint inst). This is
for my understanding and wanted verify.
kvmppc_handle_exit(booke.c)
- BOOKE_INTERRUPT_HV_PRIV
- emulation_exit
-kvmppc_emulate_instruction
Incase of using the same software breakpoint instruction (0x0000),
then we need to add code in booke something like this
kvmppc_handle_exit (booke.c)
- BOOKE_INTERRUPT_PROGRAM
-if debug instr
-emulation_exit
else
-send to guest?
Bleks. I see your point. I guess you need something like this for booke:
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index 074b7fc..1fdeee0 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -876,6 +876,11 @@ int kvmppc_handle_exit(struct kvm_run *run, struct
kvm_vcpu *vcpu,
case BOOKE_INTERRUPT_HV_PRIV:
emulated = kvmppc_get_last_inst(vcpu, false, last_inst);
break;
+case BOOKE_INTERRUPT_PROGRAM:
+/* SW breakpoints arrive as illegal instructions on HV */
+if (vcpu-guest_debug KVM_GUESTDBG_USE_SW_BP)
+emulated = kvmppc_get_last_inst(vcpu, false, last_inst);
+break;
default:
break;
}
@@ -953,7 +958,8 @@ int kvmppc_handle_exit(struct kvm_run *run, struct
kvm_vcpu *vcpu,
break;
case BOOKE_INTERRUPT_PROGRAM:
-if (vcpu-arch.shared-msr (MSR_PR | MSR_GS)) {
+if ((vcpu-arch.shared-msr (MSR_PR | MSR_GS))
+(last_inst != KVMPPC_INST_SOFT_BREAKPOINT)) {
/*
* Program traps generated by user-level software must
* be handled by the guest kernel.
Ok make sense.
Regards
Maddy
Basically you would have handling code in emulate.c and book3s_hv.c at
the end of the day.
Yes. Will resend the patch with updated code.
Thanks,
Alex
--
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
[Bug 81841] amd-iommu: kernel BUG lockup after shutting down KVM guest using PCI passthrough/PCIe bridge
https://bugzilla.kernel.org/show_bug.cgi?id=81841 --- Comment #15 from Joel Schopp joel.sch...@amd.com --- (In reply to Joel Schopp from comment #10) AMD would need to confirm it. I don't have an answer for you offhand. Let me do some digging and get you an answer. I am sorry if I sounded frustrated or arrogant earlier. Any update on this? It's not clear to me which devices were being put in the same group. Here's some of my notes on your lspci output lspci -vt -[:00]-+-00.0 Advanced Micro Devices, Inc. [AMD] Device 1422 +-00.2 Advanced Micro Devices, Inc. [AMD] Device 1423 +-01.0 Advanced Micro Devices, Inc. [AMD/ATI] Kaveri [Radeon R7 200 Series] +-01.1 Advanced Micro Devices, Inc. [AMD/ATI] Device 1308 +-02.0 Advanced Micro Devices, Inc. [AMD] Device 1424 +-03.0 Advanced Micro Devices, Inc. [AMD] Device 1424 +-04.0 Advanced Micro Devices, Inc. [AMD] Device 1424 +-10.0 Advanced Micro Devices, Inc. [AMD] FCH USB XHCI Controller +-10.1 Advanced Micro Devices, Inc. [AMD] FCH USB XHCI Controller These xhci controllers are isolated from from the other devices, I would need some more detail on which variant you are running to determine if they are isolated from eachother, they probably aren't. +-11.0 Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] The sata controller is isolated from the other devices +-12.0 Advanced Micro Devices, Inc. [AMD] FCH USB OHCI Controller +-12.2 Advanced Micro Devices, Inc. [AMD] FCH USB EHCI Controller This pair of OHCI/EHCI controllers are together isolated from the other devices +-13.0 Advanced Micro Devices, Inc. [AMD] FCH USB OHCI Controller +-13.2 Advanced Micro Devices, Inc. [AMD] FCH USB EHCI Controller This pair of OHCI/EHCI controllers are together isolated from the other devices +-14.0 Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller +-14.1 Advanced Micro Devices, Inc. [AMD] FCH IDE Controller +-14.2 Advanced Micro Devices, Inc. [AMD] FCH Azalia Controller +-14.3 Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge I do not think the SMBus/IDE/Azalia/LPC are isolated from eachother, but they are isolated from the other devices I have identified. +-14.4-[01]05.0 Dialogic Corporation PRI The legacy PCI should be isolated from the other devices identified. Not sure what is going on here. +-14.5 Advanced Micro Devices, Inc. [AMD] FCH USB OHCI Controller This OHCI Controller should also be isolated from the other devices. +-15.0-[02]-- +-15.2-[03]00.0 ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller Is this in a PCI-e slot or otherwise attached to the PCI-e? +-15.3-[04]00.0 Qualcomm Atheros QCA8171 Gigabit Ethernet Is this in a PCI-e slot or otherwise attached to the PCI-e? +-18.0 Advanced Micro Devices, Inc. [AMD] Device 141a +-18.1 Advanced Micro Devices, Inc. [AMD] Device 141b +-18.2 Advanced Micro Devices, Inc. [AMD] Device 141c +-18.3 Advanced Micro Devices, Inc. [AMD] Device 141d +-18.4 Advanced Micro Devices, Inc. [AMD] Device 141e \-18.5 Advanced Micro Devices, Inc. [AMD] Device 141f -- You are receiving this mail because: You are watching the assignee of the bug. -- 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 1/1] virtio: rng: add derating factor for use by hwrng core
On 08/11/2014 10:27 PM, Amit Shah wrote: On (Mon) 11 Aug 2014 [15:11:03], H. Peter Anvin wrote: On 08/11/2014 11:49 AM, Amit Shah wrote: The khwrngd thread is started when a hwrng device of sufficient quality is registered. The virtio-rng device is backed by the hypervisor, and we trust the hypervisor to provide real entropy. A malicious hypervisor is a scenario that's ruled out, so we are certain the quality of randomness we receive is perfectly trustworthy. Hence, we use 100% for the factor, indicating maximum confidence in the source. Signed-off-by: Amit Shah amit.s...@redhat.com It isn't ruled out, it is just irrelevant: if the hypervisor is malicious, the quality of your random number source is the least of your problems. Yea; I meant ruled out in that sense. Should the commit msg be more verbose? Yes, as it is written it is misleading. -hpa -- 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
[Bug 81841] amd-iommu: kernel BUG lockup after shutting down KVM guest using PCI passthrough/PCIe bridge
https://bugzilla.kernel.org/show_bug.cgi?id=81841 --- Comment #16 from Alex Williamson alex.william...@redhat.com --- (In reply to Joel Schopp from comment #15) (In reply to Joel Schopp from comment #10) AMD would need to confirm it. I don't have an answer for you offhand. Let me do some digging and get you an answer. I am sorry if I sounded frustrated or arrogant earlier. Any update on this? It's not clear to me which devices were being put in the same group. Here's some of my notes on your lspci output Marti, the output of 'find /sys/kernel/iommu_groups' would be useful here. I'll try to help based on what I think is happening... lspci -vt -[:00]-+-00.0 Advanced Micro Devices, Inc. [AMD] Device 1422 +-00.2 Advanced Micro Devices, Inc. [AMD] Device 1423 +-01.0 Advanced Micro Devices, Inc. [AMD/ATI] Kaveri [Radeon R7 200 Series] +-01.1 Advanced Micro Devices, Inc. [AMD/ATI] Device 1308 +-02.0 Advanced Micro Devices, Inc. [AMD] Device 1424 +-03.0 Advanced Micro Devices, Inc. [AMD] Device 1424 +-04.0 Advanced Micro Devices, Inc. [AMD] Device 1424 +-10.0 Advanced Micro Devices, Inc. [AMD] FCH USB XHCI Controller +-10.1 Advanced Micro Devices, Inc. [AMD] FCH USB XHCI Controller These xhci controllers are isolated from from the other devices, I would need some more detail on which variant you are running to determine if they are isolated from eachother, they probably aren't. 10.0 10.1 will typically be grouped together due to lack of ACS. This is usually not a problem. +-11.0 Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] The sata controller is isolated from the other devices Yep, and it's a single function device so IOMMU groups should be ok. +-12.0 Advanced Micro Devices, Inc. [AMD] FCH USB OHCI Controller +-12.2 Advanced Micro Devices, Inc. [AMD] FCH USB EHCI Controller This pair of OHCI/EHCI controllers are together isolated from the other devices Yep, same as above. +-13.0 Advanced Micro Devices, Inc. [AMD] FCH USB OHCI Controller +-13.2 Advanced Micro Devices, Inc. [AMD] FCH USB EHCI Controller This pair of OHCI/EHCI controllers are together isolated from the other devices Yep +-14.0 Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller +-14.1 Advanced Micro Devices, Inc. [AMD] FCH IDE Controller +-14.2 Advanced Micro Devices, Inc. [AMD] FCH Azalia Controller +-14.3 Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge I do not think the SMBus/IDE/Azalia/LPC are isolated from eachother, but they are isolated from the other devices I have identified. +-14.4-[01]05.0 Dialogic Corporation PRI The legacy PCI should be isolated from the other devices identified. Not sure what is going on here. +-14.5 Advanced Micro Devices, Inc. [AMD] FCH USB OHCI Controller This OHCI Controller should also be isolated from the other devices. All of the above will be grouped together, this is the problem. Since none of these functions support ACS, IOMMU groups assume that peer-to-peer between functions is possible. If 14.4 and 14.5 are truly isolated from the rest of the package then we should have quirks to support that. This whole block is an update or the quirk already shown in comment 7. +-15.0-[02]-- +-15.2-[03]00.0 ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller Is this in a PCI-e slot or otherwise attached to the PCI-e? +-15.3-[04]00.0 Qualcomm Atheros QCA8171 Gigabit Ethernet Is this in a PCI-e slot or otherwise attached to the PCI-e? I would guess 15.x are all PCIe root ports, hopefully with ACS support. -- You are receiving this mail because: You are watching the assignee of the bug. -- 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 1/1] virtio: rng: add derating factor for use by hwrng core
The khwrngd thread is started when a hwrng device of sufficient quality is registered. The virtio-rng device is backed by the hypervisor, and we trust the hypervisor to provide real entropy. A malicious hypervisor is a scenario that's irrelevant -- such a setup is bound to cause all sorts of badness, and a compromised hwrng is not the biggest threat. Given this, we are certain the quality of randomness we receive is perfectly trustworthy. Hence, we use 100% for the factor, indicating maximum confidence in the source. Signed-off-by: Amit Shah amit.s...@redhat.com --- Pretty small and contained patch; would be great if it is picked up for 3.17. v2: re-word commit msg --- drivers/char/hw_random/virtio-rng.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/char/hw_random/virtio-rng.c b/drivers/char/hw_random/virtio-rng.c index 0027137..2e3139e 100644 --- a/drivers/char/hw_random/virtio-rng.c +++ b/drivers/char/hw_random/virtio-rng.c @@ -116,6 +116,7 @@ static int probe_common(struct virtio_device *vdev) .cleanup = virtio_cleanup, .priv = (unsigned long)vi, .name = vi-name, + .quality = 1000, }; vdev-priv = vi; -- 1.9.3 -- 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
[Bug 81841] amd-iommu: kernel BUG lockup after shutting down KVM guest using PCI passthrough/PCIe bridge
https://bugzilla.kernel.org/show_bug.cgi?id=81841 --- Comment #17 from Marti Raudsepp ma...@juffo.org --- It's an ASRock FM2A88X Extreme6+ motherboard with the AMD A88X (Bolton-D4) chipset. There are 12 IOMMU groups on the system. The problematic group for me is number 9 because the legacy PCI bridge (14.4) gets mixed in with other southbridge devices (all 14.*). /sys/kernel/iommu_groups/0/devices: :00:00.0 - ../../../../devices/pci:00/:00:00.0 /sys/kernel/iommu_groups/1/devices: :00:01.0 - ../../../../devices/pci:00/:00:01.0 :00:01.1 - ../../../../devices/pci:00/:00:01.1 /sys/kernel/iommu_groups/2/devices: :00:02.0 - ../../../../devices/pci:00/:00:02.0 /sys/kernel/iommu_groups/3/devices: :00:03.0 - ../../../../devices/pci:00/:00:03.0 /sys/kernel/iommu_groups/4/devices: :00:04.0 - ../../../../devices/pci:00/:00:04.0 /sys/kernel/iommu_groups/5/devices: :00:10.0 - ../../../../devices/pci:00/:00:10.0 :00:10.1 - ../../../../devices/pci:00/:00:10.1 /sys/kernel/iommu_groups/6/devices: :00:11.0 - ../../../../devices/pci:00/:00:11.0 /sys/kernel/iommu_groups/7/devices: :00:12.0 - ../../../../devices/pci:00/:00:12.0 :00:12.2 - ../../../../devices/pci:00/:00:12.2 /sys/kernel/iommu_groups/8/devices: :00:13.0 - ../../../../devices/pci:00/:00:13.0 :00:13.2 - ../../../../devices/pci:00/:00:13.2 /sys/kernel/iommu_groups/9/devices: :00:14.0 - ../../../../devices/pci:00/:00:14.0 :00:14.1 - ../../../../devices/pci:00/:00:14.1 :00:14.2 - ../../../../devices/pci:00/:00:14.2 :00:14.3 - ../../../../devices/pci:00/:00:14.3 :00:14.4 - ../../../../devices/pci:00/:00:14.4 :00:14.5 - ../../../../devices/pci:00/:00:14.5 :01:05.0 - ../../../../devices/pci:00/:00:14.4/:01:05.0 [When I plug in a card to the other legacy PCI slot, it also appears here as pci:00/:00:14.4/:01:06.0] /sys/kernel/iommu_groups/10/devices: :00:15.0 - ../../../../devices/pci:00/:00:15.0 :00:15.2 - ../../../../devices/pci:00/:00:15.2 :00:15.3 - ../../../../devices/pci:00/:00:15.3 :03:00.0 - ../../../../devices/pci:00/:00:15.2/:03:00.0 :04:00.0 - ../../../../devices/pci:00/:00:15.3/:04:00.0 /sys/kernel/iommu_groups/11/devices: :00:18.0 - ../../../../devices/pci:00/:00:18.0 :00:18.1 - ../../../../devices/pci:00/:00:18.1 :00:18.2 - ../../../../devices/pci:00/:00:18.2 :00:18.3 - ../../../../devices/pci:00/:00:18.3 :00:18.4 - ../../../../devices/pci:00/:00:18.4 :00:18.5 - ../../../../devices/pci:00/:00:18.5 (In reply to Joel Schopp from comment #15) It's not clear to me which devices were being put in the same group. Here's some of my notes on your lspci output Other than the 14.* devices everything seems to be as you describe. +-14.0 Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller +-14.1 Advanced Micro Devices, Inc. [AMD] FCH IDE Controller +-14.2 Advanced Micro Devices, Inc. [AMD] FCH Azalia Controller +-14.3 Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge I do not think the SMBus/IDE/Azalia/LPC are isolated from eachother, but they are isolated from the other devices I have identified. Ok, that's not a problem. +-14.4-[01]05.0 Dialogic Corporation PRI The legacy PCI should be isolated from the other devices identified. Not sure what is going on here. Yep, currently shares group 9. +-14.5 Advanced Micro Devices, Inc. [AMD] FCH USB OHCI Controller This OHCI Controller should also be isolated from the other devices. Also shares group 9. +-15.0-[02]-- +-15.2-[03]00.0 ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller Is this in a PCI-e slot or otherwise attached to the PCI-e? Nope, this is integrated on the motherboard. The only used PCI slot is the Dialogic card. +-15.3-[04]00.0 Qualcomm Atheros QCA8171 Gigabit Ethernet Is this in a PCI-e slot or otherwise attached to the PCI-e? Integrated Ethernet. -- You are receiving this mail because: You are watching the assignee of the bug. -- 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: The status about vhost-net on kvm-arm?
Hello, On Tue, Aug 12, 2014 at 5:41 AM, Li Liu john.li...@huawei.com wrote: Hi all, Is anyone there can tell the current status of vhost-net on kvm-arm? Half a year has passed from Isa Ansharullah asked this question: http://www.spinics.net/lists/kvm-arm/msg08152.html I have found two patches which have provided the kvm-arm support of eventfd and irqfd: 1) [RFC PATCH 0/4] ARM: KVM: Enable the ioeventfd capability of KVM on ARM http://lists.gnu.org/archive/html/qemu-devel/2014-01/msg01770.html 2) [RFC,v3] ARM: KVM: add irqfd and irq routing support https://patches.linaro.org/32261/ And there's a rough patch for qemu to support eventfd from Ying-Shiuan Pan: [Qemu-devel] [PATCH 0/4] ioeventfd support for virtio-mmio https://lists.gnu.org/archive/html/qemu-devel/2014-02/msg00715.html But there no any comments of this patch. And I can found nothing about qemu to support irqfd. Do I lost the track? If nobody try to fix it. We have a plan to complete it about virtio-mmio supporing irqfd and multiqueue. we at Virtual Open Systems did some work and tested vhost-net on ARM back in March. The setup was based on: - host kernel with our ioeventfd patches: http://www.spinics.net/lists/kvm-arm/msg08413.html - qemu with the aforementioned patches from Ying-Shiuan Pan https://lists.gnu.org/archive/html/qemu-devel/2014-02/msg00715.html The testbed was ARM Chromebook with Exynos 5250, using a 1Gbps USB3 Ethernet adapter connected to a 1Gbps switch. I can't find the actual numbers but I remember that with multiple streams the gain was clearly seen. Note that it used the minimum required ioventfd implementation and not irqfd. I guess it is feasible to think that it all can be put together and rebased + the recent irqfd work. One can achiev even better performance (because of the irqfd). ___ kvmarm mailing list kvm...@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm regards, Nikolay Nikolaev Virtual Open Systems -- 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 v4] arm64: fix VTTBR_BADDR_MASK
On Mon, Aug 11, 2014 at 03:38:23PM -0500, Joel Schopp wrote:
The current VTTBR_BADDR_MASK only masks 39 bits, which is broken on current
systems. Rather than just add a bit it seems like a good time to also set
things at run-time instead of compile time to accomodate more hardware.
This patch sets TCR_EL2.PS, VTCR_EL2.T0SZ and vttbr_baddr_mask in runtime,
not compile time.
In ARMv8, EL2 physical address size (TCR_EL2.PS) and stage2 input address
size (VTCR_EL2.T0SZE) cannot be determined in compile time since they
depend on hardware capability.
According to Table D4-23 and Table D4-25 in ARM DDI 0487A.b document,
vttbr_x is calculated using different fixed values with consideration
of T0SZ, granule size and the level of translation tables. Therefore,
vttbr_baddr_mask should be determined dynamically.
Changes since v3:
Another rebase
Addressed minor comments from v2
Changes since v2:
Rebased on https://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git
next branch
Changes since v1:
Rebased fix on Jungseok Lee's patch https://lkml.org/lkml/2014/5/12/189 to
provide better long term fix. Updated that patch to log error instead of
silently fail on unaligned vttbr.
Cc: Christoffer Dall christoffer.d...@linaro.org
Cc: Sungjinn Chung sungjinn.ch...@samsung.com
Signed-off-by: Jungseok Lee jays@samsung.com
Signed-off-by: Joel Schopp joel.sch...@amd.com
---
arch/arm/kvm/arm.c | 116
+-
arch/arm64/include/asm/kvm_arm.h | 17 +-
arch/arm64/kvm/hyp-init.S| 20 +--
3 files changed, 131 insertions(+), 22 deletions(-)
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 3c82b37..b4859fa 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -37,6 +37,7 @@
#include asm/mman.h
#include asm/tlbflush.h
#include asm/cacheflush.h
+#include asm/cputype.h
#include asm/virt.h
#include asm/kvm_arm.h
#include asm/kvm_asm.h
@@ -61,6 +62,8 @@ static atomic64_t kvm_vmid_gen = ATOMIC64_INIT(1);
static u8 kvm_next_vmid;
static DEFINE_SPINLOCK(kvm_vmid_lock);
+static u64 vttbr_baddr_mask;
+
static bool vgic_present;
static void kvm_arm_set_running_vcpu(struct kvm_vcpu *vcpu)
@@ -412,6 +415,103 @@ static bool need_new_vmid_gen(struct kvm *kvm)
return unlikely(kvm-arch.vmid_gen != atomic64_read(kvm_vmid_gen));
}
+
+
+ /*
+ * ARMv8 64K architecture limitations:
+ * 16 = T0SZ = 21 is valid under 3 level of translation tables
+ * 18 = T0SZ = 34 is valid under 2 level of translation tables
+ * 31 = T0SZ = 39 is valid under 1 level of transltaion tables
+ *
+ * ARMv8 4K architecture limitations:
+ * 16 = T0SZ = 24 is valid under 4 level of translation tables
+ * 21 = T0SZ = 30 is valid under 3 level of translation tables
this is still wrong, as I pointed out, it should be 21 = T0SZ = 30
+ * 30 = T0SZ = 39 is valid under 2 level of translation tables
+ *
+ *
+ * We further limit T0SZ in ARM64 Linux by not supporting 1 level
+ * translation tables at all, not supporting 2 level translation
+ * tables with 4k pages, not supporting different levels of translation
+ * tables in stage 1 vs stage 2, not supporting different page sizes in
+ * stage 1 vs stage 2, not supporting less than 40 bit address space
+ * with 64k pages, and not supporting less than 32 bit address space
+ * with 4K pages.
+ *
+ * See Table D4-23 and Table D4-25 in ARM DDI 0487A.b to figure out
+ * the origin of the hardcoded values, 38 and 37.
+ */
nit: why is this block indented one level?
+
+#ifdef CONFIG_ARM64_64K_PAGES
+static inline int t0sz_to_vttbr_x(int t0sz){
+ if (t0sz 16 || t0sz 24) {
How are you getting at this? The comment above is now almost useless,
the whole point of listing the options with the various levels of
translation tables given a page size is to show how we get to these
limits.
I think what you mean here, is:
if (t0sz 18 || t0sz 34) {
+ kvm_err(Cannot support %d-bit address space\n, 64 - t0sz);
+ return -EINVAL;
+ }
+
+ return 38 - t0sz;
+}
+#elif CONFIG_ARM64 !CONFIG_ARM64_64K_PAGES
+static inline int t0sz_to_vttbr_x(int t0sz){
+ if (t0sz 16 || t0sz 32) {
And here:
if (t0sz 21 || t0sz 33)
+ kvm_err(Cannot support %d-bit address space\n, 64 - t0sz);
+ return -EINVAL;
+ }
+ return 37 - t0sz;
+}
+#endif
I'd really much more like to see these two with the comment in
arch/arm64/include/asm/kvm_mmu.h as that is the scheme we've used for
all the other KVM code.
+
+
+/**
+ * set_vttbr_baddr_mask - set mask value for vttbr base address
+ *
+ * In ARMv8, vttbr_baddr_mask cannot be determined in compile time since the
+ * stage2 input address size depends on hardware capability. Thus, we first
+ *
Re: [Qemu-devel] [PATCH] Qemu: Fix eax for cpuid leaf 0x40000000
On Wed, Jun 04, 2014 at 03:17:56AM -0400, Jidong Xiao wrote: On Wed, Jun 4, 2014 at 3:09 AM, Paolo Bonzini pbonz...@redhat.com wrote: Il 04/06/2014 03:10, Jidong Xiao ha scritto: diff --git a/qemu-2.0.0/target-i386/kvm.c.orig b/qemu-2.0.0/target-i386/kvm.c index 4389959..b8b282d 100644 --- a/qemu-2.0.0/target-i386/kvm.c.orig +++ b/qemu-2.0.0/target-i386/kvm.c @@ -530,7 +530,7 @@ int kvm_arch_init_vcpu(CPUState *cs) memcpy(signature, KVMKVMKVM\0\0\0, 12); c = cpuid_data.entries[cpuid_i++]; c-function = KVM_CPUID_SIGNATURE | kvm_base; -c-eax = 0; + c-eax = KVM_CPUID_FEATURES; c-ebx = signature[0]; c-ecx = signature[1]; c-edx = signature[2]; This should actually be KVM_CPUID_FEATURES | kvm_base, in case Hyper-V leaves are available too. But it is a good catch! Paolo Thanks Paolo. I have just added that and resend the patch as following: -Jidong === Signed-off-by: Jidong Xiao jidong.x...@gmail.com --- diff --git a/qemu-2.0.0/target-i386/kvm.c.orig b/qemu-2.0.0/target-i386/kvm.c index 4389959..fe49a75 100644 --- a/qemu-2.0.0/target-i386/kvm.c.orig +++ b/qemu-2.0.0/target-i386/kvm.c @@ -530,7 +530,7 @@ int kvm_arch_init_vcpu(CPUState *cs) memcpy(signature, KVMKVMKVM\0\0\0, 12); c = cpuid_data.entries[cpuid_i++]; c-function = KVM_CPUID_SIGNATURE | kvm_base; -c-eax = 0; + c-eax = KVM_CPUID_FEATURES | kvm_base; This makes the CPUID data change under the guest's feet during live-migration. Adding compat code to ensure older machine-types keep the old behavior is necessary, but in this specific case it is mostly harmless because 0x0 is documented as being equivalent to 0x4001. (But I don't know how guests are supposed to behave when they see CPUID[KVM_CPUID_SIGNATURE_NEXT].EAX==0.) -- Eduardo -- 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: [Qemu-devel] [PATCH] Qemu: Fix eax for cpuid leaf 0x40000000
Il 12/08/2014 20:55, Eduardo Habkost ha scritto: This makes the CPUID data change under the guest's feet during live-migration. Adding compat code to ensure older machine-types keep the old behavior is necessary, but in this specific case it is mostly harmless because 0x0 is documented as being equivalent to 0x4001. (But I don't know how guests are supposed to behave when they see CPUID[KVM_CPUID_SIGNATURE_NEXT].EAX==0.) The only obvious thing to do would be to treat it as 0x4101. Paolo -- 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 v5 0/5] random,x86,kvm: Rework arch RNG seeds and get some from kvm
On Wed, Jul 23, 2014 at 9:57 PM, Andy Lutomirski l...@amacapital.net wrote: This introduces and uses a very simple synchronous mechanism to get /dev/urandom-style bits appropriate for initial KVM PV guest RNG seeding. It also re-works the way that architectural random data is fed into random.c's pools. I added a new arch hook called arch_get_rng_seed. The default implementation is more or less the same as the current code, except that random_get_entropy is now called unconditionally. x86 gets a custom arch_get_rng_seed. It will use KVM_GET_RNG_SEED if available, and, if it does anything, it will log the number of bits collected from each available architectural source. If more paravirt seed sources show up, it will be a natural place to add them. I sent the corresponding kvm-unit-tests and qemu changes separately. What's the status of this series? I assume that it's too late for at least patches 2-5 to make it into 3.17. --Andy Changes from v4: - Got rid of the RDRAND behavior change. If this series is accepted, I may resend it separately, but I think it's an unrelated issue. - Fix up the changelog entries -- I misunderstood how the old code worked. - Avoid lots of failed attempts to use KVM_GET_RNG_SEED if it's not available. Changes from v3: - Other than KASLR, the guest pieces are completely rewritten. Patches 2-4 have essentially nothing in common with v2. Changes from v2: - Bisection fix (patch 2 had a misplaced brace). The final states is identical to that of v2. - Improve the 0/5 description a little bit. Changes from v1: - Split patches 2 and 3 - Log all arch sources in init_std_data - Fix the 32-bit kaslr build Andy Lutomirski (5): x86,kvm: Add MSR_KVM_GET_RNG_SEED and a matching feature bit random: Add and use arch_get_rng_seed x86,random: Add an x86 implementation of arch_get_rng_seed x86,random,kvm: Use KVM_GET_RNG_SEED in arch_get_rng_seed x86,kaslr: Use MSR_KVM_GET_RNG_SEED for KASLR if available Documentation/virtual/kvm/cpuid.txt | 3 ++ arch/x86/Kconfig | 4 ++ arch/x86/boot/compressed/aslr.c | 27 + arch/x86/include/asm/archrandom.h| 6 +++ arch/x86/include/asm/kvm_guest.h | 9 + arch/x86/include/asm/processor.h | 21 -- arch/x86/include/uapi/asm/kvm_para.h | 2 + arch/x86/kernel/Makefile | 2 + arch/x86/kernel/archrandom.c | 74 arch/x86/kernel/kvm.c| 10 + arch/x86/kvm/cpuid.c | 3 +- arch/x86/kvm/x86.c | 4 ++ drivers/char/random.c| 14 +-- include/linux/random.h | 40 +++ 14 files changed, 212 insertions(+), 7 deletions(-) create mode 100644 arch/x86/kernel/archrandom.c -- 1.9.3 -- Andy Lutomirski AMA Capital Management, LLC -- 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 v5 0/5] random,x86,kvm: Rework arch RNG seeds and get some from kvm
On Tue, Aug 12, 2014 at 12:11:29PM -0700, Andy Lutomirski wrote: What's the status of this series? I assume that it's too late for at least patches 2-5 to make it into 3.17. Which tree were you hoping this patch series to go through? I was assuming it would go through the x86 tree since the bulk of the changes in the x86 subsystem (hence my Acked-by). IIRC, Peter had some concerns, and I don't remember if they were all addressed. Peter? - Ted -- 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 v5 0/5] random,x86,kvm: Rework arch RNG seeds and get some from kvm
On Tue, Aug 12, 2014 at 12:17 PM, Theodore Ts'o ty...@mit.edu wrote: On Tue, Aug 12, 2014 at 12:11:29PM -0700, Andy Lutomirski wrote: What's the status of this series? I assume that it's too late for at least patches 2-5 to make it into 3.17. Which tree were you hoping this patch series to go through? I was assuming it would go through the x86 tree since the bulk of the changes in the x86 subsystem (hence my Acked-by). There's some argument that patch 1 should go through the kvm tree. There's no real need for patch 1 and 2-5 to end up in the same kernel release, either. IIRC, Peter had some concerns, and I don't remember if they were all addressed. Peter? I don't know. I rewrite one thing he didn't like and undid the other, but there's plenty of opportunity for this version to be problematic, too. --Andy -- 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: [Qemu-devel] [PATCH] Qemu: Fix eax for cpuid leaf 0x40000000
On Tue, Aug 12, 2014 at 09:12:00PM +0200, Paolo Bonzini wrote: Il 12/08/2014 20:55, Eduardo Habkost ha scritto: This makes the CPUID data change under the guest's feet during live-migration. Adding compat code to ensure older machine-types keep the old behavior is necessary, but in this specific case it is mostly harmless because 0x0 is documented as being equivalent to 0x4001. (But I don't know how guests are supposed to behave when they see CPUID[KVM_CPUID_SIGNATURE_NEXT].EAX==0.) The only obvious thing to do would be to treat it as 0x4101. I just want to be sure the guests really do that. If we know guests won't do anything different with the CPUID change, I won't mind having no compat code for this. -- Eduardo -- 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
Logging Information
Hello, I am exploring ideas for clients in cloud to be able to implement functions where there could verify the services offered by the cloud provider like metering services. Idea is I am using the concept of write execute protection scheme. And also I am using TamperEvident Log. I am making use of WP bit to protect pagetable entries so that any modifications is captured in the log. Code pages of the log are also read only and hence any modifications to it is also captured. My questions are: What are the important events that one needs to log so that one could have reasonable overhead? Currently, I have large overhead since any update to page table/modifications creates a trap and in cloud, this is huge. How can one create tamperevident logging mechanism? How could client and the provider verify that each events are logged as intended without a miss. How can one create a logging mechanism (say per client basis). In that case, if required we could replay the log so that we could capture the malicious event. -- 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 7/7 v3] KVM: PPC: BOOKE: Emulate debug registers and exception
On Tue, 2014-08-12 at 02:36 -0500, Bhushan Bharat-R65777 wrote: -Original Message- From: Wood Scott-B07421 Sent: Tuesday, August 12, 2014 5:30 AM To: Bhushan Bharat-R65777 Cc: ag...@suse.de; kvm-...@vger.kernel.org; kvm@vger.kernel.org; Yoder Stuart- B08248 Subject: Re: [PATCH 7/7 v3] KVM: PPC: BOOKE: Emulate debug registers and exception On Wed, 2014-08-06 at 12:08 +0530, Bharat Bhushan wrote: @@ -1249,6 +1284,7 @@ int kvmppc_subarch_vcpu_init(struct kvm_vcpu *vcpu) setup_timer(vcpu-arch.wdt_timer, kvmppc_watchdog_func, (unsigned long)vcpu); + kvmppc_clear_dbsr(); return 0; This could use a comment for why we're doing this. Also, I'm a bit uneasy about clearing the whole DBSR here, where we haven't yet switched the debug registers to guest context. I think we wanted MRR to not cause debug event to guest, So should we only clear MRR ? It shouldn't actually matter except for deferred debug exceptions which are not actually useful (in fact e6500 removed support for them), Exactly, that's why I was clearing complete DBSR. Probably we can have a comment Do not let previously set debug events visible to guest. As deferred debug events are not supported, so it is ok to clear complete DBSR. This would be affecting host debugging of the host, not guest debugging of the guest. Still I don't think it's a huge deal, but clearing only MRR would be cleaner. -Scott -- 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 v9 2/4] arm: ARMv7 dirty page logging inital mem region write protect (w/no huge PUD support)
On 08/12/2014 02:36 AM, Christoffer Dall wrote:
On Mon, Aug 11, 2014 at 06:36:14PM -0700, Mario Smarduch wrote:
On 08/11/2014 12:12 PM, Christoffer Dall wrote:
[...]
+/**
+ * stage2_wp_range() - write protect stage2 memory region range
+ * @kvm: The KVM pointer
+ * @start:Start address of range
+ * end: End address of range
+ */
+static void stage2_wp_range(struct kvm *kvm, phys_addr_t addr,
phys_addr_t end)
+{
+ pgd_t *pgd;
+ phys_addr_t next;
+
+ pgd = kvm-arch.pgd + pgd_index(addr);
+ do {
+ /*
+ * Release kvm_mmu_lock periodically if the memory region is
+ * large features like detect hung task, lock detector or lock
large. Otherwise, we may see panics due to..
+ * dep may panic. In addition holding the lock this long will
extra white space ^^ Additionally, holding the lock for a
long timer will
+ * also starve other vCPUs. Applies to huge VM memory regions.
^^^ I don't understand this
last remark.
Sorry overlooked this.
While testing - VM regions that were small (~1GB) holding the mmu_lock
caused not problems, but when I was running memory regions around 2GB large
some kernel lockup detection/lock contention options (some selected by
default)
caused deadlock warnings/panics in host kernel.
This was in one my previous review comments sometime ago, I can go back
and find the options.
Just drop the last part of the comment, so the whole thing reads:
/*
* Release kvm_mmu_lock periodically if the memory region is
* large. Otherwise, we may see kernel panics from debugging features
* such as detect hung task, lock detector or lock dep checks.
* Additionally, holding the lock too long will also starve other vCPUs.
*/
And check the actual names of those debugging features or use the
CONFIG_WHATEVER names and say we may see kernel panics with CONFIG_X,
CONFIG_Y, and CONFIG_Z.
Makes sense?
Yep sure does.
-Christoffer
--
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 1/2] KVM: fix cache stale memslot info with correct mmio generation number
On Mon, Aug 11, 2014 at 10:02 PM, Xiao Guangrong
xiaoguangr...@linux.vnet.ibm.com wrote:
@@ -722,9 +719,10 @@ static struct kvm_memslots *install_new_memslots(struct
kvm *kvm,
{
struct kvm_memslots *old_memslots = kvm-memslots;
I think you want
slots-generation = old_memslots-generation;
here.
On the KVM_MR_DELETE path, install_new_memslots is called twice so this
patch introduces a short window of time where the generation number
actually decreases.
- update_memslots(slots, new, kvm-memslots-generation);
+ update_memslots(slots, new);
rcu_assign_pointer(kvm-memslots, slots);
synchronize_srcu_expedited(kvm-srcu);
+ slots-generation++;
kvm_arch_memslots_updated(kvm);
--
1.8.3.1
--
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 v9 2/4] arm: ARMv7 dirty page logging inital mem region write protect (w/no huge PUD support)
On 08/12/2014 02:32 AM, Christoffer Dall wrote:
On Mon, Aug 11, 2014 at 05:16:21PM -0700, Mario Smarduch wrote:
On 08/11/2014 12:12 PM, Christoffer Dall wrote:
Remove the parenthesis from the subject line.
I just prefer not having the (w/no huge PUD support) part in the patch
title.
Ah ok.
Hmmm have to check this don't see it my patch file.
On Thu, Jul 24, 2014 at 05:56:06PM -0700, Mario Smarduch wrote:
Patch adds support for initial write protection VM memlsot. This patch
series
^^^
stray whitespace of
Need to watch out for these adds delays to review cycle.
yes, I care quite a lot about proper English, syntax, grammar and
spelling. Reading critically through your own patch files before
mailing them out is a good exercise. You can even consider putting them
through a spell-checker and/or configure your editor to mark double
white space, trailing white space etc.
[...]
+ do {
+ next = kvm_pmd_addr_end(addr, end);
+ if (!pmd_none(*pmd)) {
+ if (kvm_pmd_huge(*pmd)) {
+ if (!kvm_s2pmd_readonly(pmd))
+ kvm_set_s2pmd_readonly(pmd);
+ } else
+ stage2_wp_pte_range(pmd, addr, next);
please use a closing brace when the first part of the if-statement is a
multi-line block with braces, as per the CodingStyle.
Will fix.
+
stray blank line
Not sure how it got by checkpatch, will fix.
Not sure checkpatch will complain, but I do ;) No big deal anyway.
+ }
+ } while (pmd++, addr = next, addr != end);
+}
+
+/**
+ * stage2_wp_pud_range - write protect PUD range
+ * @kvm: pointer to kvm structure
+ * @pud: pointer to pgd entry
pgd
+ * @addr:range start address
+ * @end: range end address
+ *
+ * While walking the PUD range huge PUD pages are ignored, in the future
this
range, huge PUDs are ignored. In the future...
+ * may need to be revisited. Determine how to handle huge PUDs when
logging
+ * of dirty pages is enabled.
I don't understand the last sentence?
Probably last two sentences should be combined.
to determine how to handle huge PUT Would that be
clear enough?
The overall theme is what to do about PUDs - mark all pages dirty
in the region, attempt to breakup such huge regions?
I think you should just state that this is not supported and worry
about how to deal with it when it's properly supported. The TODO below
is sufficient, so just drop all mentionings about the future in the
function description above - it's likely to be forgotten when PUDs are
in fact support anyhow.
Ok the simpler the better.
Thanks,
-Christoffer
--
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
EPT Accessed bit
Hi, From the Intel processor manual I read that accessed bit has been introduced in EPT. The Redhat 6 release notes mention that Extended Page Table age bits enables a host to make smarter choices for swapping memory under memory pressure. I couldn't find any related patches on KVM or LKML. I was wondering if using the EPT accessed bit requires any support from KVM to allow the host kernel to determine and swap out the inactive VM pages. Thanks, Umesh -- 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 v9 4/4] arm: ARMv7 dirty page logging 2nd stage page fault handling support
On 08/12/2014 02:50 AM, Christoffer Dall wrote:
On Mon, Aug 11, 2014 at 06:25:05PM -0700, Mario Smarduch wrote:
On 08/11/2014 12:13 PM, Christoffer Dall wrote:
On Thu, Jul 24, 2014 at 05:56:08PM -0700, Mario Smarduch wrote:
This patch adds support for handling 2nd stage page faults during
migration,
it disables faulting in huge pages, and dissolves huge pages to page
tables.
In case migration is canceled huge pages will be used again.
Signed-off-by: Mario Smarduch m.smard...@samsung.com
---
arch/arm/kvm/mmu.c | 31 +--
1 file changed, 25 insertions(+), 6 deletions(-)
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index ca84331..a17812a 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -642,7 +642,8 @@ static int stage2_set_pmd_huge(struct kvm *kvm, struct
kvm_mmu_memory_cache
}
static int stage2_set_pte(struct kvm *kvm, struct kvm_mmu_memory_cache
*cache,
-phys_addr_t addr, const pte_t *new_pte, bool iomap)
+phys_addr_t addr, const pte_t *new_pte, bool iomap,
+bool logging_active)
{
pmd_t *pmd;
pte_t *pte, old_pte;
@@ -657,6 +658,15 @@ static int stage2_set_pte(struct kvm *kvm, struct
kvm_mmu_memory_cache *cache,
return 0;
}
+ /*
+ * While dirty memory logging, clear PMD entry for huge page and split
+ * into smaller pages, to track dirty memory at page granularity.
+ */
+ if (logging_active kvm_pmd_huge(*pmd)) {
+ phys_addr_t ipa = pmd_pfn(*pmd) PAGE_SHIFT;
+ clear_pmd_entry(kvm, pmd, ipa);
clear_pmd_entry has a VM_BUG_ON(kvm_pmd_huge(*pmd)) so that is
definitely not the right thing to call.
I don't see that in 3.15rc1/rc4 -
static void clear_pmd_entry(struct kvm *kvm, pmd_t *pmd, phys_addr_t addr)
{
if (kvm_pmd_huge(*pmd)) {
pmd_clear(pmd);
kvm_tlb_flush_vmid_ipa(kvm, addr);
} else {
[]
}
I thought the purpose of this function was to clear PMD entry. Also
ran hundreds of tests no problems. Hmmm confused.
You need to rebase on kvm/next or linus/master, something that contains:
4f853a7 arm/arm64: KVM: Fix and refactor unmap_range
+ }
+
/* Create stage-2 page mappings - Level 2 */
if (pmd_none(*pmd)) {
if (!cache)
@@ -709,7 +719,7 @@ int kvm_phys_addr_ioremap(struct kvm *kvm, phys_addr_t
guest_ipa,
if (ret)
goto out;
spin_lock(kvm-mmu_lock);
- ret = stage2_set_pte(kvm, cache, addr, pte, true);
+ ret = stage2_set_pte(kvm, cache, addr, pte, true, false);
spin_unlock(kvm-mmu_lock);
if (ret)
goto out;
@@ -926,6 +936,12 @@ static int user_mem_abort(struct kvm_vcpu *vcpu,
phys_addr_t fault_ipa,
struct kvm_mmu_memory_cache *memcache = vcpu-arch.mmu_page_cache;
struct vm_area_struct *vma;
pfn_t pfn;
+ /* Get logging status, if dirty_bitmap is not NULL then logging is on */
+ #ifdef CONFIG_ARM
+ bool logging_active = !!memslot-dirty_bitmap;
+ #else
+ bool logging_active = false;
+ #endif
can you make this an inline in the header files for now please?
Yes definitely.
write_fault = kvm_is_write_fault(kvm_vcpu_get_hsr(vcpu));
if (fault_status == FSC_PERM !write_fault) {
@@ -936,7 +952,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu,
phys_addr_t fault_ipa,
/* Let's check if we will get back a huge page backed by hugetlbfs */
down_read(current-mm-mmap_sem);
vma = find_vma_intersection(current-mm, hva, hva + 1);
- if (is_vm_hugetlb_page(vma)) {
+ if (is_vm_hugetlb_page(vma) !logging_active) {
hugetlb = true;
gfn = (fault_ipa PMD_MASK) PAGE_SHIFT;
} else {
@@ -979,7 +995,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu,
phys_addr_t fault_ipa,
spin_lock(kvm-mmu_lock);
if (mmu_notifier_retry(kvm, mmu_seq))
goto out_unlock;
- if (!hugetlb !force_pte)
+ if (!hugetlb !force_pte !logging_active)
hugetlb = transparent_hugepage_adjust(pfn, fault_ipa);
if (hugetlb) {
@@ -998,9 +1014,12 @@ static int user_mem_abort(struct kvm_vcpu *vcpu,
phys_addr_t fault_ipa,
kvm_set_pfn_dirty(pfn);
}
coherent_cache_guest_page(vcpu, hva, PAGE_SIZE);
- ret = stage2_set_pte(kvm, memcache, fault_ipa, new_pte, false);
+ ret = stage2_set_pte(kvm, memcache, fault_ipa, new_pte, false,
+ logging_active);
}
+ if (write_fault)
+ mark_page_dirty(kvm, gfn);
out_unlock:
spin_unlock(kvm-mmu_lock);
@@ -1151,7 +1170,7 @@ static void kvm_set_spte_handler(struct kvm *kvm,
gpa_t gpa, void *data)
{
pte_t *pte = (pte_t *)data;
- stage2_set_pte(kvm, NULL, gpa, pte, false);
+ stage2_set_pte(kvm, NULL, gpa, pte, false, false);
Re: The status about vhost-net on kvm-arm?
On 2014/8/12 15:29, Eric Auger wrote: On 08/12/2014 04:41 AM, Li Liu wrote: Hi all, Is anyone there can tell the current status of vhost-net on kvm-arm? Half a year has passed from Isa Ansharullah asked this question: http://www.spinics.net/lists/kvm-arm/msg08152.html I have found two patches which have provided the kvm-arm support of eventfd and irqfd: 1) [RFC PATCH 0/4] ARM: KVM: Enable the ioeventfd capability of KVM on ARM http://lists.gnu.org/archive/html/qemu-devel/2014-01/msg01770.html 2) [RFC,v3] ARM: KVM: add irqfd and irq routing support https://patches.linaro.org/32261/ Hi Li, The patch below uses Paul Mackerras' work and removed usage of GSI routing table. It is a simpler alternative to 2) http://www.spinics.net/lists/kvm/msg106535.html Thanks for your tips. This looks more clear. Best Regards Li And there's a rough patch for qemu to support eventfd from Ying-Shiuan Pan: [Qemu-devel] [PATCH 0/4] ioeventfd support for virtio-mmio https://lists.gnu.org/archive/html/qemu-devel/2014-02/msg00715.html But there no any comments of this patch. And I can found nothing about qemu to support irqfd. Do I lost the track? Actually I am using irqfd in QEMU VFIO Platform device https://lists.nongnu.org/archive/html/qemu-devel/2014-08/msg01455.html Best Regards Eric If nobody try to fix it. We have a plan to complete it about virtio-mmio supporing irqfd and multiqueue. -- 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 -- 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: The status about vhost-net on kvm-arm?
On 2014/8/12 23:47, Nikolay Nikolaev wrote: Hello, On Tue, Aug 12, 2014 at 5:41 AM, Li Liu john.li...@huawei.com wrote: Hi all, Is anyone there can tell the current status of vhost-net on kvm-arm? Half a year has passed from Isa Ansharullah asked this question: http://www.spinics.net/lists/kvm-arm/msg08152.html I have found two patches which have provided the kvm-arm support of eventfd and irqfd: 1) [RFC PATCH 0/4] ARM: KVM: Enable the ioeventfd capability of KVM on ARM http://lists.gnu.org/archive/html/qemu-devel/2014-01/msg01770.html 2) [RFC,v3] ARM: KVM: add irqfd and irq routing support https://patches.linaro.org/32261/ And there's a rough patch for qemu to support eventfd from Ying-Shiuan Pan: [Qemu-devel] [PATCH 0/4] ioeventfd support for virtio-mmio https://lists.gnu.org/archive/html/qemu-devel/2014-02/msg00715.html But there no any comments of this patch. And I can found nothing about qemu to support irqfd. Do I lost the track? If nobody try to fix it. We have a plan to complete it about virtio-mmio supporing irqfd and multiqueue. we at Virtual Open Systems did some work and tested vhost-net on ARM back in March. The setup was based on: - host kernel with our ioeventfd patches: http://www.spinics.net/lists/kvm-arm/msg08413.html - qemu with the aforementioned patches from Ying-Shiuan Pan https://lists.gnu.org/archive/html/qemu-devel/2014-02/msg00715.html The testbed was ARM Chromebook with Exynos 5250, using a 1Gbps USB3 Ethernet adapter connected to a 1Gbps switch. I can't find the actual numbers but I remember that with multiple streams the gain was clearly seen. Note that it used the minimum required ioventfd implementation and not irqfd. Yeah, we have roughly tested vhost-net without irqfd and get the same result. And now try to see what will happen with irqfd :). I guess it is feasible to think that it all can be put together and rebased + the recent irqfd work. One can achiev even better performance (because of the irqfd). ___ kvmarm mailing list kvm...@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm regards, Nikolay Nikolaev Virtual Open Systems . -- 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: EPT Accessed bit
Hi Umesh, On Tue, Aug 12, 2014 at 08:07:48PM -0500, Umesh Deshpande wrote: Hi, From the Intel processor manual I read that accessed bit has been introduced in EPT. The Redhat 6 release notes mention that Extended Page Table age bits enables a host to make smarter choices for swapping memory under memory pressure. I couldn't find any related patches on KVM or LKML. I was wondering if using the EPT accessed bit requires any support from KVM to allow the host kernel to determine and swap out the inactive VM pages. IIUC, host tracks the EPT A bit through mmu notifier. Regards, Wanpeng Li Thanks, Umesh -- 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 -- 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] PC, KVM, CMA: Fix regression caused by wrong get_order() use
fc95ca7284bc54953165cba76c3228bd2cdb9591 claims that there is no
functional change but this is not true as it calls get_order() (which
takes bytes) where it should have called ilog2() and the kernel stops
on VM_BUG_ON().
This replaces get_order() with ilog2().
Suggested-by: Paul Mackerras pau...@samba.org
Cc: Alexander Graf ag...@suse.de
Cc: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
Cc: Joonsoo Kim iamjoonsoo@lge.com
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: sta...@vger.kernel.org
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
arch/powerpc/kvm/book3s_hv_builtin.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_hv_builtin.c
b/arch/powerpc/kvm/book3s_hv_builtin.c
index 329d7fd..bfe9f01 100644
--- a/arch/powerpc/kvm/book3s_hv_builtin.c
+++ b/arch/powerpc/kvm/book3s_hv_builtin.c
@@ -101,7 +101,7 @@ struct kvm_rma_info *kvm_alloc_rma()
ri = kmalloc(sizeof(struct kvm_rma_info), GFP_KERNEL);
if (!ri)
return NULL;
- page = cma_alloc(kvm_cma, kvm_rma_pages, get_order(kvm_rma_pages));
+ page = cma_alloc(kvm_cma, kvm_rma_pages, ilog2(kvm_rma_pages));
if (!page)
goto err_out;
atomic_set(ri-use_count, 1);
@@ -135,12 +135,12 @@ struct page *kvm_alloc_hpt(unsigned long nr_pages)
{
unsigned long align_pages = HPT_ALIGN_PAGES;
- VM_BUG_ON(get_order(nr_pages) KVM_CMA_CHUNK_ORDER - PAGE_SHIFT);
+ VM_BUG_ON(ilog2(nr_pages) KVM_CMA_CHUNK_ORDER - PAGE_SHIFT);
/* Old CPUs require HPT aligned on a multiple of its size */
if (!cpu_has_feature(CPU_FTR_ARCH_206))
align_pages = nr_pages;
- return cma_alloc(kvm_cma, nr_pages, get_order(align_pages));
+ return cma_alloc(kvm_cma, nr_pages, ilog2(align_pages));
}
EXPORT_SYMBOL_GPL(kvm_alloc_hpt);
--
2.0.0
--
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 6/7 v3] KVM: PPC: BOOKE: Add one reg interface for DBSR
On 06.08.14 08:38, Bharat Bhushan wrote:
Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com
---
v2-v3
- New patch
arch/powerpc/include/uapi/asm/kvm.h | 1 +
arch/powerpc/kvm/booke.c| 6 ++
2 files changed, 7 insertions(+)
diff --git a/arch/powerpc/include/uapi/asm/kvm.h
b/arch/powerpc/include/uapi/asm/kvm.h
index e0e49db..3ca357a 100644
--- a/arch/powerpc/include/uapi/asm/kvm.h
+++ b/arch/powerpc/include/uapi/asm/kvm.h
@@ -557,6 +557,7 @@ struct kvm_get_htab_header {
#define KVM_REG_PPC_DABRX (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0xb8)
#define KVM_REG_PPC_WORT (KVM_REG_PPC | KVM_REG_SIZE_U64 | 0xb9)
#define KVM_REG_PPC_SPRG9 (KVM_REG_PPC | KVM_REG_SIZE_U64 | 0xba)
+#define KVM_REG_PPC_DBSR (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0xbb)
Please write up a follow-up patch that adds SPRG9 and DBSR to
Documentation/virtual/kvm/api.txt.
Alex
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7 v3] Guest debug emulation
On 06.08.14 08:38, Bharat Bhushan wrote: This patchset adds debug register and interrupt emulation support for guest, which enables running gdb/kgdb etc in guest. v2-v3 - Added One-reg interface for DBSR - removed arch-shadow_dbg_reg - Addressed some more comments on v2 (detail in individual patch) Thanks, applied patches 1-6 to kvm-ppc-queue. That way you only need to respin patch 7 and add the documentation patch. Alex -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/7 v3] Guest debug emulation
-Original Message- From: Alexander Graf [mailto:ag...@suse.de] Sent: Tuesday, August 12, 2014 3:55 PM To: Bhushan Bharat-R65777; kvm-ppc@vger.kernel.org Cc: k...@vger.kernel.org; Wood Scott-B07421; Yoder Stuart-B08248 Subject: Re: [PATCH 0/7 v3] Guest debug emulation On 06.08.14 08:38, Bharat Bhushan wrote: This patchset adds debug register and interrupt emulation support for guest, which enables running gdb/kgdb etc in guest. v2-v3 - Added One-reg interface for DBSR - removed arch-shadow_dbg_reg - Addressed some more comments on v2 (detail in individual patch) Thanks, applied patches 1-6 to kvm-ppc-queue. That way you only need to respin patch 7 and add the documentation patch. Thanks Alex, I will add the documentation patch with next version on 7/7 patch. Regards -Bharat Alex -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/5] KVM: PPC: Move ONE_REG AltiVec support to powerpc
On 05.08.14 12:39, Mihai Caraman wrote: Make ONE_REG AltiVec support common across server and embedded implementations moving kvm_vcpu_ioctl_get_one_reg() and kvm_vcpu_ioctl_set_one_reg() functions to powerpc layer. Signed-off-by: Mihai Caraman mihai.cara...@freescale.com Please split this into 2 separate patches, one that makes ONE_REG generic and one that moves Altivec from book3s into the generic version. Alex -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/5] KVM: PPC: Booke: Add ONE_REG IVORs support
On 05.08.14 12:39, Mihai Caraman wrote:
Add ONE_REG IVORs support, with IVORs 0-15 and 35 booke common.
Signed-off-by: Mihai Caraman mihai.cara...@freescale.com
---
v3:
- new patch
arch/powerpc/include/uapi/asm/kvm.h | 24 +++
arch/powerpc/kvm/booke.c| 132
arch/powerpc/kvm/e500.c | 42 +++-
arch/powerpc/kvm/e500mc.c | 32 +
4 files changed, 228 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/uapi/asm/kvm.h
b/arch/powerpc/include/uapi/asm/kvm.h
index 7a27ff0..174fed0 100644
--- a/arch/powerpc/include/uapi/asm/kvm.h
+++ b/arch/powerpc/include/uapi/asm/kvm.h
@@ -563,6 +563,30 @@ struct kvm_get_htab_header {
#define KVM_REG_PPC_WORT (KVM_REG_PPC | KVM_REG_SIZE_U64 | 0xb9)
#define KVM_REG_PPC_SPRG9 (KVM_REG_PPC | KVM_REG_SIZE_U64 | 0xba)
+/* Booke IVOR registers */
+#define KVM_REG_PPC_IVOR0 (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0xc0)
+#define KVM_REG_PPC_IVOR1 (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0xc1)
+#define KVM_REG_PPC_IVOR2 (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0xc2)
+#define KVM_REG_PPC_IVOR3 (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0xc3)
+#define KVM_REG_PPC_IVOR4 (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0xc4)
+#define KVM_REG_PPC_IVOR5 (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0xc5)
+#define KVM_REG_PPC_IVOR6 (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0xc6)
+#define KVM_REG_PPC_IVOR7 (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0xc7)
+#define KVM_REG_PPC_IVOR8 (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0xc8)
+#define KVM_REG_PPC_IVOR9 (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0xc9)
+#define KVM_REG_PPC_IVOR10 (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0xca)
+#define KVM_REG_PPC_IVOR11 (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0xcb)
+#define KVM_REG_PPC_IVOR12 (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0xcc)
+#define KVM_REG_PPC_IVOR13 (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0xcd)
+#define KVM_REG_PPC_IVOR14 (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0xce)
+#define KVM_REG_PPC_IVOR15 (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0xcf)
+#define KVM_REG_PPC_IVOR32 (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0xd0)
+#define KVM_REG_PPC_IVOR33 (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0xd1)
+#define KVM_REG_PPC_IVOR34 (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0xd2)
+#define KVM_REG_PPC_IVOR35 (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0xd3)
+#define KVM_REG_PPC_IVOR36 (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0xd4)
+#define KVM_REG_PPC_IVOR37 (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0xd5)
These should also get mentioned in Documentation/virtual/kvm/api.txt.
Otherwise looks nice :).
Alex
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] powerpc/kvm: support to handle sw breakpoint
On 12.08.14 13:35, Madhavan Srinivasan wrote:
On Tuesday 12 August 2014 04:49 PM, Alexander Graf wrote:
On 12.08.14 07:17, Madhavan Srinivasan wrote:
On Monday 11 August 2014 02:45 PM, Alexander Graf wrote:
On 11.08.14 10:51, Benjamin Herrenschmidt wrote:
On Mon, 2014-08-11 at 09:26 +0200, Alexander Graf wrote:
diff --git a/arch/powerpc/kvm/emulate.c b/arch/powerpc/kvm/emulate.c
index da86d9b..d95014e 100644
--- a/arch/powerpc/kvm/emulate.c
+++ b/arch/powerpc/kvm/emulate.c
This should be book3s_emulate.c.
Any reason we can't make that 0000 opcode as breakpoint common to
all powerpc variants ?
I can't think of a good reason. We use a hypercall on booke (which traps
into an illegal instruction for pr) today, but I don't think it has to
be that way.
Given that the user space API allows us to change it dynamically, there
should be nothing blocking us from going with 0000 always.
Kindly correct me if i am wrong. So we can still have a common code in
emulate.c to set the env for both HV and pr incase of illegal
instruction (i will rebase latest src). But suggestion here to use
0000, in that case current path in embed is kvmppc_handle_exit
(booke.c) - BOOKE_INTERRUPT_HV_PRIV - emulation_exit -
kvmppc_emulate_instruction, will change to kvmppc_handle_exit (booke.c)
- BOOKE_INTERRUPT_PROGRAM - if debug instr call emulation_exit else
send to guest?
I can't follow your description above.
My bad.
With the latest git version HV KVM does not include emulate.c anymore.
Also, it would make a lot of sense of have the same soft breakpoint
instruction across all ppc targets, so it would make sense to change it
to 0x0000 for booke as well.
Got it. Was describing the current control flow with respect to booke
and where changes needed (for same software breakpoint inst). This is
for my understanding and wanted verify.
kvmppc_handle_exit(booke.c)
- BOOKE_INTERRUPT_HV_PRIV
- emulation_exit
-kvmppc_emulate_instruction
Incase of using the same software breakpoint instruction (0x0000),
then we need to add code in booke something like this
kvmppc_handle_exit (booke.c)
- BOOKE_INTERRUPT_PROGRAM
- if debug instr
-emulation_exit
else
-send to guest?
Bleks. I see your point. I guess you need something like this for booke:
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index 074b7fc..1fdeee0 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -876,6 +876,11 @@ int kvmppc_handle_exit(struct kvm_run *run, struct
kvm_vcpu *vcpu,
case BOOKE_INTERRUPT_HV_PRIV:
emulated = kvmppc_get_last_inst(vcpu, false, last_inst);
break;
+case BOOKE_INTERRUPT_PROGRAM:
+/* SW breakpoints arrive as illegal instructions on HV */
+if (vcpu-guest_debug KVM_GUESTDBG_USE_SW_BP)
+emulated = kvmppc_get_last_inst(vcpu, false, last_inst);
+break;
default:
break;
}
@@ -953,7 +958,8 @@ int kvmppc_handle_exit(struct kvm_run *run, struct
kvm_vcpu *vcpu,
break;
case BOOKE_INTERRUPT_PROGRAM:
-if (vcpu-arch.shared-msr (MSR_PR | MSR_GS)) {
+if ((vcpu-arch.shared-msr (MSR_PR | MSR_GS))
+(last_inst != KVMPPC_INST_SOFT_BREAKPOINT)) {
/*
* Program traps generated by user-level software must
* be handled by the guest kernel.
Basically you would have handling code in emulate.c and book3s_hv.c at
the end of the day.
Yes. Will resend the patch with updated code.
Thanks,
Alex
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] powerpc/kvm: support to handle sw breakpoint
On Tuesday 12 August 2014 05:45 PM, Alexander Graf wrote:
On 12.08.14 13:35, Madhavan Srinivasan wrote:
On Tuesday 12 August 2014 04:49 PM, Alexander Graf wrote:
On 12.08.14 07:17, Madhavan Srinivasan wrote:
On Monday 11 August 2014 02:45 PM, Alexander Graf wrote:
On 11.08.14 10:51, Benjamin Herrenschmidt wrote:
On Mon, 2014-08-11 at 09:26 +0200, Alexander Graf wrote:
diff --git a/arch/powerpc/kvm/emulate.c
b/arch/powerpc/kvm/emulate.c
index da86d9b..d95014e 100644
--- a/arch/powerpc/kvm/emulate.c
+++ b/arch/powerpc/kvm/emulate.c
This should be book3s_emulate.c.
Any reason we can't make that 0000 opcode as breakpoint common to
all powerpc variants ?
I can't think of a good reason. We use a hypercall on booke (which
traps
into an illegal instruction for pr) today, but I don't think it has to
be that way.
Given that the user space API allows us to change it dynamically,
there
should be nothing blocking us from going with 0000 always.
Kindly correct me if i am wrong. So we can still have a common code in
emulate.c to set the env for both HV and pr incase of illegal
instruction (i will rebase latest src). But suggestion here to use
0000, in that case current path in embed is kvmppc_handle_exit
(booke.c) - BOOKE_INTERRUPT_HV_PRIV - emulation_exit -
kvmppc_emulate_instruction, will change to kvmppc_handle_exit (booke.c)
- BOOKE_INTERRUPT_PROGRAM - if debug instr call emulation_exit else
send to guest?
I can't follow your description above.
My bad.
With the latest git version HV KVM does not include emulate.c anymore.
Also, it would make a lot of sense of have the same soft breakpoint
instruction across all ppc targets, so it would make sense to change it
to 0x0000 for booke as well.
Got it. Was describing the current control flow with respect to booke
and where changes needed (for same software breakpoint inst). This is
for my understanding and wanted verify.
kvmppc_handle_exit(booke.c)
- BOOKE_INTERRUPT_HV_PRIV
- emulation_exit
-kvmppc_emulate_instruction
Incase of using the same software breakpoint instruction (0x0000),
then we need to add code in booke something like this
kvmppc_handle_exit (booke.c)
- BOOKE_INTERRUPT_PROGRAM
-if debug instr
-emulation_exit
else
-send to guest?
Bleks. I see your point. I guess you need something like this for booke:
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index 074b7fc..1fdeee0 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -876,6 +876,11 @@ int kvmppc_handle_exit(struct kvm_run *run, struct
kvm_vcpu *vcpu,
case BOOKE_INTERRUPT_HV_PRIV:
emulated = kvmppc_get_last_inst(vcpu, false, last_inst);
break;
+case BOOKE_INTERRUPT_PROGRAM:
+/* SW breakpoints arrive as illegal instructions on HV */
+if (vcpu-guest_debug KVM_GUESTDBG_USE_SW_BP)
+emulated = kvmppc_get_last_inst(vcpu, false, last_inst);
+break;
default:
break;
}
@@ -953,7 +958,8 @@ int kvmppc_handle_exit(struct kvm_run *run, struct
kvm_vcpu *vcpu,
break;
case BOOKE_INTERRUPT_PROGRAM:
-if (vcpu-arch.shared-msr (MSR_PR | MSR_GS)) {
+if ((vcpu-arch.shared-msr (MSR_PR | MSR_GS))
+(last_inst != KVMPPC_INST_SOFT_BREAKPOINT)) {
/*
* Program traps generated by user-level software must
* be handled by the guest kernel.
Ok make sense.
Regards
Maddy
Basically you would have handling code in emulate.c and book3s_hv.c at
the end of the day.
Yes. Will resend the patch with updated code.
Thanks,
Alex
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/7 v3] KVM: PPC: BOOKE: Emulate debug registers and exception
On Tue, 2014-08-12 at 02:36 -0500, Bhushan Bharat-R65777 wrote: -Original Message- From: Wood Scott-B07421 Sent: Tuesday, August 12, 2014 5:30 AM To: Bhushan Bharat-R65777 Cc: ag...@suse.de; kvm-ppc@vger.kernel.org; k...@vger.kernel.org; Yoder Stuart- B08248 Subject: Re: [PATCH 7/7 v3] KVM: PPC: BOOKE: Emulate debug registers and exception On Wed, 2014-08-06 at 12:08 +0530, Bharat Bhushan wrote: @@ -1249,6 +1284,7 @@ int kvmppc_subarch_vcpu_init(struct kvm_vcpu *vcpu) setup_timer(vcpu-arch.wdt_timer, kvmppc_watchdog_func, (unsigned long)vcpu); + kvmppc_clear_dbsr(); return 0; This could use a comment for why we're doing this. Also, I'm a bit uneasy about clearing the whole DBSR here, where we haven't yet switched the debug registers to guest context. I think we wanted MRR to not cause debug event to guest, So should we only clear MRR ? It shouldn't actually matter except for deferred debug exceptions which are not actually useful (in fact e6500 removed support for them), Exactly, that's why I was clearing complete DBSR. Probably we can have a comment Do not let previously set debug events visible to guest. As deferred debug events are not supported, so it is ok to clear complete DBSR. This would be affecting host debugging of the host, not guest debugging of the guest. Still I don't think it's a huge deal, but clearing only MRR would be cleaner. -Scott -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] PC, KVM, CMA: Fix regression caused by wrong get_order() use
fc95ca7284bc54953165cba76c3228bd2cdb9591 claims that there is no
functional change but this is not true as it calls get_order() (which
takes bytes) where it should have called ilog2() and the kernel stops
on VM_BUG_ON().
This replaces get_order() with ilog2().
Suggested-by: Paul Mackerras pau...@samba.org
Cc: Alexander Graf ag...@suse.de
Cc: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
Cc: Joonsoo Kim iamjoonsoo@lge.com
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: sta...@vger.kernel.org
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
arch/powerpc/kvm/book3s_hv_builtin.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_hv_builtin.c
b/arch/powerpc/kvm/book3s_hv_builtin.c
index 329d7fd..bfe9f01 100644
--- a/arch/powerpc/kvm/book3s_hv_builtin.c
+++ b/arch/powerpc/kvm/book3s_hv_builtin.c
@@ -101,7 +101,7 @@ struct kvm_rma_info *kvm_alloc_rma()
ri = kmalloc(sizeof(struct kvm_rma_info), GFP_KERNEL);
if (!ri)
return NULL;
- page = cma_alloc(kvm_cma, kvm_rma_pages, get_order(kvm_rma_pages));
+ page = cma_alloc(kvm_cma, kvm_rma_pages, ilog2(kvm_rma_pages));
if (!page)
goto err_out;
atomic_set(ri-use_count, 1);
@@ -135,12 +135,12 @@ struct page *kvm_alloc_hpt(unsigned long nr_pages)
{
unsigned long align_pages = HPT_ALIGN_PAGES;
- VM_BUG_ON(get_order(nr_pages) KVM_CMA_CHUNK_ORDER - PAGE_SHIFT);
+ VM_BUG_ON(ilog2(nr_pages) KVM_CMA_CHUNK_ORDER - PAGE_SHIFT);
/* Old CPUs require HPT aligned on a multiple of its size */
if (!cpu_has_feature(CPU_FTR_ARCH_206))
align_pages = nr_pages;
- return cma_alloc(kvm_cma, nr_pages, get_order(align_pages));
+ return cma_alloc(kvm_cma, nr_pages, ilog2(align_pages));
}
EXPORT_SYMBOL_GPL(kvm_alloc_hpt);
--
2.0.0
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
