Re: [Xen-devel] [PATCH v1 03/10] KVM: Prepare kvm_is_reserved_pfn() for PG_reserved changes
On 06.11.19 01:08, Dan Williams wrote:
On Tue, Nov 5, 2019 at 4:03 PM Sean Christopherson
wrote:
On Tue, Nov 05, 2019 at 03:43:29PM -0800, Dan Williams wrote:
On Tue, Nov 5, 2019 at 3:30 PM Dan Williams wrote:
On Tue, Nov 5, 2019 at 3:13 PM Sean Christopherson
wrote:
On Tue, Nov 05, 2019 at 03:02:40PM -0800, Dan Williams wrote:
On Tue, Nov 5, 2019 at 12:31 PM David Hildenbrand wrote:
The scarier code (for me) is transparent_hugepage_adjust() and
kvm_mmu_zap_collapsible_spte(), as I don't at all understand the
interaction between THP and _PAGE_DEVMAP.
The x86 KVM MMU code is one of the ugliest code I know (sorry, but it
had to be said :/ ). Luckily, this should be independent of the
PG_reserved thingy AFAIKs.
Both transparent_hugepage_adjust() and kvm_mmu_zap_collapsible_spte()
are honoring kvm_is_reserved_pfn(), so again I'm missing where the
page count gets mismanaged and leads to the reported hang.
When mapping pages into the guest, KVM gets the page via gup(), which
increments the page count for ZONE_DEVICE pages. But KVM puts the page
using kvm_release_pfn_clean(), which skips put_page() if PageReserved()
and so never puts its reference to ZONE_DEVICE pages.
Oh, yeah, that's busted.
Ugh, it's extra busted because every other gup user in the kernel
tracks the pages resulting from gup and puts them (put_page()) when
they are done. KVM wants to forget about whether it did a gup to get
the page and optionally trigger put_page() based purely on the pfn.
Outside of VFIO device assignment that needs pages pinned for DMA, why
does KVM itself need to pin pages? If pages are pinned over a return
to userspace that needs to be a FOLL_LONGTERM gup.
Short answer, KVM pins the page to ensure correctness with respect to the
primary MMU invalidating the associated host virtual address, e.g. when
the page is being migrated or unmapped from host userspace.
The main use of gup() is to handle guest page faults and map pages into
the guest, i.e. into KVM's secondary MMU. KVM uses gup() to both get the
PFN and to temporarily pin the page. The pin is held just long enough to
guaranteed that any invalidation via the mmu_notifier will be stalled
until after KVM finishes installing the page into the secondary MMU, i.e.
the pin is short-term and not held across a return to userspace or entry
into the guest. When a subsequent mmu_notifier invalidation occurs, KVM
pulls the PFN from the secondary MMU and uses that to update accessed
and dirty bits in the host.
There are a few other KVM flows that eventually call into gup(), but those
are "traditional" short-term pins and use put_page() directly.
Ok, I was misinterpreting the effect of the bug with what KVM is using
the reference to do.
To your other point:
But David's proposed fix for the above refcount bug is to omit the patch
so that KVM no longer treats ZONE_DEVICE pages as reserved. That seems
like the right thing to do, including for thp_adjust(), e.g. it would
naturally let KVM use 2mb pages for the guest when a ZONE_DEVICE page is
mapped with a huge page (2mb or above) in the host. The only hiccup is
figuring out how to correctly transfer the reference.
That might not be the only hiccup. There's currently no such thing as
huge pages for ZONE_DEVICE, there are huge *mappings* (pmd and pud),
but the result of pfn_to_page() on such a mapping does not yield a
huge 'struct page'. It seems there are other paths in KVM that assume
that more typical page machinery is active like SetPageDirty() based
on kvm_is_reserved_pfn(). While I told David that I did not want to
see more usage of is_zone_device_page(), this patch below (untested)
seems a cleaner path with less surprises:
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 4df0aa6b8e5c..fbea17c1810c 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -1831,7 +1831,8 @@ EXPORT_SYMBOL_GPL(kvm_release_page_clean);
void kvm_release_pfn_clean(kvm_pfn_t pfn)
{
- if (!is_error_noslot_pfn(pfn) && !kvm_is_reserved_pfn(pfn))
+ if ((!is_error_noslot_pfn(pfn) && !kvm_is_reserved_pfn(pfn)) ||
+ (pfn_valid(pfn) && is_zone_device_page(pfn_to_page(pfn
put_page(pfn_to_page(pfn));
}
EXPORT_SYMBOL_GPL(kvm_release_pfn_clean);
I had the same thought, but I do wonder about the kvm_get_pfn() users,
e.g.,:
hva_to_pfn_remapped():
r = follow_pfn(vma, addr, );
...
kvm_get_pfn(pfn);
...
We would not take a reference for ZONE_DEVICE, but later drop one
reference via kvm_release_pfn_clean(). IOW, kvm_get_pfn() gets *really*
dangerous to use. I can't tell if this can happen right now.
We do have 3 users of kvm_get_pfn() that we have to audit before this
change. Also, we should add a comment to kvm_get_pfn() that it should
never be used with possible ZONE_DEVICE pages.
Also, we should add a comment to kvm_release_pfn_clean(), describing why
we treat ZONE_DEVICE in a special way here.
We can then
[Xen-devel] [xen-4.8-testing test] 143733: regressions - trouble: fail/pass/starved
flight 143733 xen-4.8-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/143733/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 15 guest-saverestore.2 fail REGR. vs. 138829 test-amd64-amd64-xl-qcow2 19 guest-start/debian.repeat fail REGR. vs. 138829 test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail REGR. vs. 138829 test-armhf-armhf-libvirt-raw 15 guest-start/debian.repeat fail REGR. vs. 138829 test-amd64-i386-xl-raw 19 guest-start/debian.repeat fail REGR. vs. 138829 test-armhf-armhf-xl-vhd 15 guest-start/debian.repeat fail REGR. vs. 138829 Tests which did not succeed, but are not blocking: test-xtf-amd64-amd64-3 70 xtf/test-hvm64-xsa-278 fail like 138747 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 138770 test-xtf-amd64-amd64-3 50 xtf/test-hvm64-lbr-tsx-vmentry fail like 138809 test-xtf-amd64-amd64-5 50 xtf/test-hvm64-lbr-tsx-vmentry fail like 138829 test-xtf-amd64-amd64-4 50 xtf/test-hvm64-lbr-tsx-vmentry fail like 138829 test-xtf-amd64-amd64-4 70 xtf/test-hvm64-xsa-278 fail like 138829 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 138829 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 138829 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 138829 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 138829 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 138829 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 138829 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 138829 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 138829 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-check
[Xen-devel] [PATCH 1/1] kdd.c: Add support for initial handshake in KD protocol for Win 7, 8 and 10 (64 bit)
From: "julian.tumin...@gmail.com"
Current implementation of find_os is based on the hard-coded values for
different Windows version. It uses the value for get the address to
start looking for DOS header in the given specified range. However, this
is not scalable to all version of Windows as it will require us to keep
adding new entries and also due to KASLR, chances of not hitting the PE
header is significant. We implement a way for 64-bit systems to use IDT
entry to get a valid exception/interrupt handler and then move back into
the memory to find the valid DOS header. Since IDT entries are protected
by PatchGuard, we think our assumption that IDT entries will not be
corrupted is valid for our purpose. Once we have the image base, we
search for the DBGKD_GET_VERSION64 structure type in .data section to
get information required for handshake.
Currently, this is a work in progress feature and current patch only
supports the handshake and memory read/write on 64-bit systems.
Signed-off-by: Jenish Rakholiya
Signed-off-by: Julian Tuminaro
---
tools/debugger/kdd/kdd.c | 389 ++-
1 file changed, 388 insertions(+), 1 deletion(-)
diff --git a/tools/debugger/kdd/kdd.c b/tools/debugger/kdd/kdd.c
index fb8c645355..407b70a21c 100644
--- a/tools/debugger/kdd/kdd.c
+++ b/tools/debugger/kdd/kdd.c
@@ -51,6 +51,8 @@
#include "kdd.h"
+// TODO: make fix this to actually use address instead of offset?
+// TODO: Maybe clean something as well?
/* Windows version details */
typedef struct {
uint32_t build;
@@ -62,6 +64,7 @@ typedef struct {
uint32_t version; /* +-> NtBuildNumber */
uint32_t modules; /* +-> PsLoadedModuleList */
uint32_t prcbs; /* +-> KiProcessorBlock */
+uint32_t kddl;
} kdd_os;
/* State of the debugger stub */
@@ -85,6 +88,106 @@ typedef struct {
kdd_os os; /* OS-specific magic numbers */
} kdd_state;
+/**
+ * @brief Size of pointer on 64 machine
+ */
+#define SIZE_PTR64 8
+
+/**
+ * @brief Size of pointer on 32 machine
+ */
+#define SIZE_PTR32 4
+
+
+/*
+ * PE and DOS Header related offsets
+ */
+
+/**
+ * @brief Offset in DOS header to look for PE header
+ */
+#define DOS_HDR_PE_OFF 0x3c
+
+/**
+ * @brief Size of PE header offset field in DOS header
+ */
+#define DOS_HDR_PE_SZ 4
+
+/**
+ * @brief Offset of number of sections field in PE header
+ */
+#define PE_NUM_SECTION_OFF 0x6
+
+/**
+ * @brief Size of number of sections field in PE header
+ */
+#define PE_NUM_SECTION_SZ 2
+
+/**
+ * @brief Offset of optional header size field in PE header
+ */
+#define PE_OPT_HDR_SZ_OFF 0x14
+
+/**
+ * @brief Size of optional header size field in PE header
+ */
+#define PE_OPT_HDR_SZ_SZ 2
+
+/**
+ * @brief Size of PE header
+ */
+#define PE_HDR_SZ 0x18
+
+/**
+ * @brief Size of section header entries in PE
+ */
+#define PE_SECT_ENT_SZ 0x28
+
+/**
+ * @brief Offset of name field in section header entry
+ */
+#define PE_SECT_NAME_OFF 0
+
+/**
+ * @brief Size of name field in section header entry
+ */
+#define PE_SECT_NAME_SZ 0x8
+
+/**
+ * @brief Offset of virtual address (RVA) field in section header entry
+ */
+#define PE_SECT_RVA_OFF 0xc
+
+/**
+ * @brief Offset of virtual size field in section header entry
+ */
+#define PE_SECT_VSIZE_OFF 0x8
+
+/**
+ * @brief Size of DBGKD_GET_VERSION64 struct
+ */
+#define DBGKD_GET_VERSION64_SZ 0x28
+
+/**
+ * @brief Offset of KERN_BASE in DBGKD_GET_VERSION64 struct
+ */
+#define DBGKD_KERN_BASE_OFF 0x10
+
+/**
+ * @brief Offset of PsLoadedModulesList in DBGKD_GET_VERSION64 struct
+ */
+#define DBGKD_MOD_LIST_OFF 0x18
+
+/**
+ * @brief Offset of DebuggerDataList in DBGKD_GET_VERSION64 struct
+ */
+#define DBGKD_KDDL_OFF 0x20
+
+/**
+ * @brief Offset of DebuggerDataList in DBGKD_GET_VERSION64 struct
+ */
+#define DBGKD_MINOR_OFF 0x2
+
/*
* Utility functions
*/
@@ -390,6 +493,284 @@ static void find_os(kdd_state *s)
s->os = unknown_os;
}
+#if 0
+/**
+ * @brief Temporary function for printing memory dump while debugging
+ * Dumps in the format of QWORD type
+ *
+ * @param s Pointer to the kdd_state structure
+ * @param addr Address to start dumping memory from
+ * @param size Number of bytes to print (automatically aligned to higher
+ * multiple of 8 bytes
+ *
+ * @note TODO: Remove this before pushing to master
+ * @note TODO: Maybe add level of logging to kdd (using -v option) - The
+ * idea of using printf instead of KDD_LOG was to not print all other unwanted
+ * logging output
+ */
+static void my_memdump(kdd_state *s, uint64_t addr, int size)
+{
+int ret;
+uint64_t buf;
+
+// we don't handle mis-aligned addresses
+if (addr & 7) {
+// XXX: TODO: don't do this
+return;
+}
+
+// dump memory 1 QWORD at a time
+//
[Xen-devel] [xtf test] 143721: all pass - PUSHED
flight 143721 xtf real [real] http://logs.test-lab.xenproject.org/osstest/logs/143721/ Perfect :-) All tests in this flight passed as required version targeted for testing: xtf 08a19af3c78e8a03f83bc354b50545136c03edd2 baseline version: xtf 1b74ec3374a6edf32fcf7709eed47736fff5 Last test of basis 143541 2019-11-01 17:09:59 Z4 days Testing same since 143721 2019-11-04 13:24:42 Z1 days1 attempts People who touched revisions under test: Andrew Cooper jobs: build-amd64-xtf pass build-amd64 pass build-amd64-pvopspass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xtf.git 1b74ec3..08a19af 08a19af3c78e8a03f83bc354b50545136c03edd2 -> xen-tested-master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-4.10-testing test] 143729: regressions - trouble: fail/pass/starved
flight 143729 xen-4.10-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/143729/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qcow2 19 guest-start/debian.repeat fail REGR. vs. 139091 test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail REGR. vs. 139091 test-amd64-i386-xl-raw 19 guest-start/debian.repeat fail REGR. vs. 139091 test-armhf-armhf-libvirt-raw 15 guest-start/debian.repeat fail REGR. vs. 139091 test-armhf-armhf-xl-vhd 15 guest-start/debian.repeat fail REGR. vs. 139091 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 139091 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 22 leak-check/check fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemut-win10-i386 10
Re: [Xen-devel] [PATCH v1 03/10] KVM: Prepare kvm_is_reserved_pfn() for PG_reserved changes
On Tue, Nov 5, 2019 at 4:03 PM Sean Christopherson
wrote:
>
> On Tue, Nov 05, 2019 at 03:43:29PM -0800, Dan Williams wrote:
> > On Tue, Nov 5, 2019 at 3:30 PM Dan Williams
> > wrote:
> > >
> > > On Tue, Nov 5, 2019 at 3:13 PM Sean Christopherson
> > > wrote:
> > > >
> > > > On Tue, Nov 05, 2019 at 03:02:40PM -0800, Dan Williams wrote:
> > > > > On Tue, Nov 5, 2019 at 12:31 PM David Hildenbrand
> > > > > wrote:
> > > > > > > The scarier code (for me) is transparent_hugepage_adjust() and
> > > > > > > kvm_mmu_zap_collapsible_spte(), as I don't at all understand the
> > > > > > > interaction between THP and _PAGE_DEVMAP.
> > > > > >
> > > > > > The x86 KVM MMU code is one of the ugliest code I know (sorry, but
> > > > > > it
> > > > > > had to be said :/ ). Luckily, this should be independent of the
> > > > > > PG_reserved thingy AFAIKs.
> > > > >
> > > > > Both transparent_hugepage_adjust() and kvm_mmu_zap_collapsible_spte()
> > > > > are honoring kvm_is_reserved_pfn(), so again I'm missing where the
> > > > > page count gets mismanaged and leads to the reported hang.
> > > >
> > > > When mapping pages into the guest, KVM gets the page via gup(), which
> > > > increments the page count for ZONE_DEVICE pages. But KVM puts the page
> > > > using kvm_release_pfn_clean(), which skips put_page() if PageReserved()
> > > > and so never puts its reference to ZONE_DEVICE pages.
> > >
> > > Oh, yeah, that's busted.
> >
> > Ugh, it's extra busted because every other gup user in the kernel
> > tracks the pages resulting from gup and puts them (put_page()) when
> > they are done. KVM wants to forget about whether it did a gup to get
> > the page and optionally trigger put_page() based purely on the pfn.
> > Outside of VFIO device assignment that needs pages pinned for DMA, why
> > does KVM itself need to pin pages? If pages are pinned over a return
> > to userspace that needs to be a FOLL_LONGTERM gup.
>
> Short answer, KVM pins the page to ensure correctness with respect to the
> primary MMU invalidating the associated host virtual address, e.g. when
> the page is being migrated or unmapped from host userspace.
>
> The main use of gup() is to handle guest page faults and map pages into
> the guest, i.e. into KVM's secondary MMU. KVM uses gup() to both get the
> PFN and to temporarily pin the page. The pin is held just long enough to
> guaranteed that any invalidation via the mmu_notifier will be stalled
> until after KVM finishes installing the page into the secondary MMU, i.e.
> the pin is short-term and not held across a return to userspace or entry
> into the guest. When a subsequent mmu_notifier invalidation occurs, KVM
> pulls the PFN from the secondary MMU and uses that to update accessed
> and dirty bits in the host.
>
> There are a few other KVM flows that eventually call into gup(), but those
> are "traditional" short-term pins and use put_page() directly.
Ok, I was misinterpreting the effect of the bug with what KVM is using
the reference to do.
To your other point:
> But David's proposed fix for the above refcount bug is to omit the patch
> so that KVM no longer treats ZONE_DEVICE pages as reserved. That seems
> like the right thing to do, including for thp_adjust(), e.g. it would
> naturally let KVM use 2mb pages for the guest when a ZONE_DEVICE page is
> mapped with a huge page (2mb or above) in the host. The only hiccup is
> figuring out how to correctly transfer the reference.
That might not be the only hiccup. There's currently no such thing as
huge pages for ZONE_DEVICE, there are huge *mappings* (pmd and pud),
but the result of pfn_to_page() on such a mapping does not yield a
huge 'struct page'. It seems there are other paths in KVM that assume
that more typical page machinery is active like SetPageDirty() based
on kvm_is_reserved_pfn(). While I told David that I did not want to
see more usage of is_zone_device_page(), this patch below (untested)
seems a cleaner path with less surprises:
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 4df0aa6b8e5c..fbea17c1810c 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -1831,7 +1831,8 @@ EXPORT_SYMBOL_GPL(kvm_release_page_clean);
void kvm_release_pfn_clean(kvm_pfn_t pfn)
{
- if (!is_error_noslot_pfn(pfn) && !kvm_is_reserved_pfn(pfn))
+ if ((!is_error_noslot_pfn(pfn) && !kvm_is_reserved_pfn(pfn)) ||
+ (pfn_valid(pfn) && is_zone_device_page(pfn_to_page(pfn
put_page(pfn_to_page(pfn));
}
EXPORT_SYMBOL_GPL(kvm_release_pfn_clean);
This is safe because the reference that KVM took earlier protects the
is_zone_device_page() lookup from racing device teardown. Otherwise,
if KVM does not have a reference it's unsafe, but that's already even
more broken because KVM would be releasing a page that it never
referenced. Every other KVM operation that assumes page allocator
pages would continue to honor kvm_is_reserved_pfn().
___
Xen-devel
Re: [Xen-devel] [PATCH v1 03/10] KVM: Prepare kvm_is_reserved_pfn() for PG_reserved changes
On Tue, Nov 05, 2019 at 03:43:29PM -0800, Dan Williams wrote: > On Tue, Nov 5, 2019 at 3:30 PM Dan Williams wrote: > > > > On Tue, Nov 5, 2019 at 3:13 PM Sean Christopherson > > wrote: > > > > > > On Tue, Nov 05, 2019 at 03:02:40PM -0800, Dan Williams wrote: > > > > On Tue, Nov 5, 2019 at 12:31 PM David Hildenbrand > > > > wrote: > > > > > > The scarier code (for me) is transparent_hugepage_adjust() and > > > > > > kvm_mmu_zap_collapsible_spte(), as I don't at all understand the > > > > > > interaction between THP and _PAGE_DEVMAP. > > > > > > > > > > The x86 KVM MMU code is one of the ugliest code I know (sorry, but it > > > > > had to be said :/ ). Luckily, this should be independent of the > > > > > PG_reserved thingy AFAIKs. > > > > > > > > Both transparent_hugepage_adjust() and kvm_mmu_zap_collapsible_spte() > > > > are honoring kvm_is_reserved_pfn(), so again I'm missing where the > > > > page count gets mismanaged and leads to the reported hang. > > > > > > When mapping pages into the guest, KVM gets the page via gup(), which > > > increments the page count for ZONE_DEVICE pages. But KVM puts the page > > > using kvm_release_pfn_clean(), which skips put_page() if PageReserved() > > > and so never puts its reference to ZONE_DEVICE pages. > > > > Oh, yeah, that's busted. > > Ugh, it's extra busted because every other gup user in the kernel > tracks the pages resulting from gup and puts them (put_page()) when > they are done. KVM wants to forget about whether it did a gup to get > the page and optionally trigger put_page() based purely on the pfn. > Outside of VFIO device assignment that needs pages pinned for DMA, why > does KVM itself need to pin pages? If pages are pinned over a return > to userspace that needs to be a FOLL_LONGTERM gup. Short answer, KVM pins the page to ensure correctness with respect to the primary MMU invalidating the associated host virtual address, e.g. when the page is being migrated or unmapped from host userspace. The main use of gup() is to handle guest page faults and map pages into the guest, i.e. into KVM's secondary MMU. KVM uses gup() to both get the PFN and to temporarily pin the page. The pin is held just long enough to guaranteed that any invalidation via the mmu_notifier will be stalled until after KVM finishes installing the page into the secondary MMU, i.e. the pin is short-term and not held across a return to userspace or entry into the guest. When a subsequent mmu_notifier invalidation occurs, KVM pulls the PFN from the secondary MMU and uses that to update accessed and dirty bits in the host. There are a few other KVM flows that eventually call into gup(), but those are "traditional" short-term pins and use put_page() directly. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Urgent for 4.13, Was dom0less + sched=null => broken in staging (fwd)
Hi Dario, I just checked and the patch is not in staging yet. Can we please make sure the patch goes in as soon as possible, given the looming release? Cheers, Stefano -- Forwarded message -- Date: Mon, 28 Oct 2019 11:40:23 -0700 (PDT) From: Stefano Stabellini To: Dario Faggioli Cc: "sstabell...@kernel.org" , "george.dun...@eu.citrix.com" , "jgr...@suse.de" , "xen-devel@lists.xenproject.org" , "julien.gr...@arm.com" Subject: Re: [Xen-devel] dom0less + sched=null => broken in staging On Mon, 28 Oct 2019, Dario Faggioli wrote: > On Fri, 2019-08-23 at 18:16 -0700, Stefano Stabellini wrote: > > On Wed, 21 Aug 2019, Dario Faggioli wrote: > > > Hey, Stefano, Julien, > > > > > > Here's another patch. > > > > > > Rather than a debug patch, this is rather an actual "proposed > > > solution". > > > > > > Can you give it a go? If it works, I'll spin it as a proper patch. > > > > Yes, this seems to solve the problem, thank you! > > > Hey, > > Sorry this is taking a little while. Can any of you please test the > attached, on top of current staging? > > In fact, I rebased the patch in my last email on top of that, and I'd > like to know if it still works, even now that core-scheduling is in. > > If it does, then a proper changelog is the only thing it'd be missing, > and I'll do it quickly, I promise :-) Tested-by: Stefano Stabellini ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] tools: pygrub actually cross-compiles just fine
+ xen-devel On Tue, 5 Nov 2019, Stefano Stabellini wrote: > Actually, pygrub cross-compiles without issues. The cross-compilation > work-around goes back to 2005 and it probably referred to PowerPC. > > Remove the work-around now. > > Signed-off-by: Stefano Stabellini > CC: Christopher Clark > --- > tools/Makefile | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/tools/Makefile b/tools/Makefile > index 7b1f6c4d28..0a293b4a30 100644 > --- a/tools/Makefile > +++ b/tools/Makefile > @@ -39,11 +39,11 @@ SUBDIRS-$(CONFIG_X86) += xenpaging > SUBDIRS-$(CONFIG_X86) += debugger/gdbsx > SUBDIRS-$(CONFIG_X86) += debugger/kdd > SUBDIRS-$(CONFIG_TESTS) += tests > +SUBDIRS-y += python > +SUBDIRS-y += pygrub > > # These don't cross-compile > ifeq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH)) > -SUBDIRS-y += python > -SUBDIRS-y += pygrub > SUBDIRS-$(OCAML_TOOLS) += ocaml > endif > > -- > 2.17.1 > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v1 03/10] KVM: Prepare kvm_is_reserved_pfn() for PG_reserved changes
On Tue, Nov 5, 2019 at 3:30 PM Dan Williams wrote: > > On Tue, Nov 5, 2019 at 3:13 PM Sean Christopherson > wrote: > > > > On Tue, Nov 05, 2019 at 03:02:40PM -0800, Dan Williams wrote: > > > On Tue, Nov 5, 2019 at 12:31 PM David Hildenbrand > > > wrote: > > > > > The scarier code (for me) is transparent_hugepage_adjust() and > > > > > kvm_mmu_zap_collapsible_spte(), as I don't at all understand the > > > > > interaction between THP and _PAGE_DEVMAP. > > > > > > > > The x86 KVM MMU code is one of the ugliest code I know (sorry, but it > > > > had to be said :/ ). Luckily, this should be independent of the > > > > PG_reserved thingy AFAIKs. > > > > > > Both transparent_hugepage_adjust() and kvm_mmu_zap_collapsible_spte() > > > are honoring kvm_is_reserved_pfn(), so again I'm missing where the > > > page count gets mismanaged and leads to the reported hang. > > > > When mapping pages into the guest, KVM gets the page via gup(), which > > increments the page count for ZONE_DEVICE pages. But KVM puts the page > > using kvm_release_pfn_clean(), which skips put_page() if PageReserved() > > and so never puts its reference to ZONE_DEVICE pages. > > Oh, yeah, that's busted. Ugh, it's extra busted because every other gup user in the kernel tracks the pages resulting from gup and puts them (put_page()) when they are done. KVM wants to forget about whether it did a gup to get the page and optionally trigger put_page() based purely on the pfn. Outside of VFIO device assignment that needs pages pinned for DMA, why does KVM itself need to pin pages? If pages are pinned over a return to userspace that needs to be a FOLL_LONGTERM gup. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v1 03/10] KVM: Prepare kvm_is_reserved_pfn() for PG_reserved changes
On Tue, Nov 05, 2019 at 03:30:00PM -0800, Dan Williams wrote: > On Tue, Nov 5, 2019 at 3:13 PM Sean Christopherson > wrote: > > > > On Tue, Nov 05, 2019 at 03:02:40PM -0800, Dan Williams wrote: > > > On Tue, Nov 5, 2019 at 12:31 PM David Hildenbrand > > > wrote: > > > > > The scarier code (for me) is transparent_hugepage_adjust() and > > > > > kvm_mmu_zap_collapsible_spte(), as I don't at all understand the > > > > > interaction between THP and _PAGE_DEVMAP. > > > > > > > > The x86 KVM MMU code is one of the ugliest code I know (sorry, but it > > > > had to be said :/ ). Luckily, this should be independent of the > > > > PG_reserved thingy AFAIKs. > > > > > > Both transparent_hugepage_adjust() and kvm_mmu_zap_collapsible_spte() > > > are honoring kvm_is_reserved_pfn(), so again I'm missing where the > > > page count gets mismanaged and leads to the reported hang. > > > > When mapping pages into the guest, KVM gets the page via gup(), which > > increments the page count for ZONE_DEVICE pages. But KVM puts the page > > using kvm_release_pfn_clean(), which skips put_page() if PageReserved() > > and so never puts its reference to ZONE_DEVICE pages. > > Oh, yeah, that's busted. > > > My transparent_hugepage_adjust() and kvm_mmu_zap_collapsible_spte() > > comments were for a post-patch/series scenario wheren PageReserved() is > > no longer true for ZONE_DEVICE pages. > > Ah, ok, for that David is preserving kvm_is_reserved_pfn() returning > true for ZONE_DEVICE because pfn_to_online_page() will fail for > ZONE_DEVICE. But David's proposed fix for the above refcount bug is to omit the patch so that KVM no longer treats ZONE_DEVICE pages as reserved. That seems like the right thing to do, including for thp_adjust(), e.g. it would naturally let KVM use 2mb pages for the guest when a ZONE_DEVICE page is mapped with a huge page (2mb or above) in the host. The only hiccup is figuring out how to correctly transfer the reference. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-4.12-testing test] 143677: regressions - FAIL
flight 143677 xen-4.12-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/143677/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-raw 19 guest-start/debian.repeat fail REGR. vs. 143190 test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail REGR. vs. 143190 test-armhf-armhf-libvirt-raw 15 guest-start/debian.repeat fail REGR. vs. 143190 test-armhf-armhf-xl-vhd 15 guest-start/debian.repeat fail REGR. vs. 143190 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-credit2 7 xen-boot fail in 143577 pass in 143677 test-amd64-i386-xl-qemut-win7-amd64 15 guest-saverestore.2 fail pass in 143577 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemut-win7-amd64 17 guest-stopfail in 143577 never pass test-amd64-amd64-xl-qcow217 guest-localmigrate/x10 fail like 143190 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass
Re: [Xen-devel] [PATCH v1 03/10] KVM: Prepare kvm_is_reserved_pfn() for PG_reserved changes
On Tue, Nov 5, 2019 at 3:13 PM Sean Christopherson wrote: > > On Tue, Nov 05, 2019 at 03:02:40PM -0800, Dan Williams wrote: > > On Tue, Nov 5, 2019 at 12:31 PM David Hildenbrand wrote: > > > > The scarier code (for me) is transparent_hugepage_adjust() and > > > > kvm_mmu_zap_collapsible_spte(), as I don't at all understand the > > > > interaction between THP and _PAGE_DEVMAP. > > > > > > The x86 KVM MMU code is one of the ugliest code I know (sorry, but it > > > had to be said :/ ). Luckily, this should be independent of the > > > PG_reserved thingy AFAIKs. > > > > Both transparent_hugepage_adjust() and kvm_mmu_zap_collapsible_spte() > > are honoring kvm_is_reserved_pfn(), so again I'm missing where the > > page count gets mismanaged and leads to the reported hang. > > When mapping pages into the guest, KVM gets the page via gup(), which > increments the page count for ZONE_DEVICE pages. But KVM puts the page > using kvm_release_pfn_clean(), which skips put_page() if PageReserved() > and so never puts its reference to ZONE_DEVICE pages. Oh, yeah, that's busted. > My transparent_hugepage_adjust() and kvm_mmu_zap_collapsible_spte() > comments were for a post-patch/series scenario wheren PageReserved() is > no longer true for ZONE_DEVICE pages. Ah, ok, for that David is preserving kvm_is_reserved_pfn() returning true for ZONE_DEVICE because pfn_to_online_page() will fail for ZONE_DEVICE. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v1 03/10] KVM: Prepare kvm_is_reserved_pfn() for PG_reserved changes
On Tue, Nov 05, 2019 at 03:02:40PM -0800, Dan Williams wrote: > On Tue, Nov 5, 2019 at 12:31 PM David Hildenbrand wrote: > > > The scarier code (for me) is transparent_hugepage_adjust() and > > > kvm_mmu_zap_collapsible_spte(), as I don't at all understand the > > > interaction between THP and _PAGE_DEVMAP. > > > > The x86 KVM MMU code is one of the ugliest code I know (sorry, but it > > had to be said :/ ). Luckily, this should be independent of the > > PG_reserved thingy AFAIKs. > > Both transparent_hugepage_adjust() and kvm_mmu_zap_collapsible_spte() > are honoring kvm_is_reserved_pfn(), so again I'm missing where the > page count gets mismanaged and leads to the reported hang. When mapping pages into the guest, KVM gets the page via gup(), which increments the page count for ZONE_DEVICE pages. But KVM puts the page using kvm_release_pfn_clean(), which skips put_page() if PageReserved() and so never puts its reference to ZONE_DEVICE pages. My transparent_hugepage_adjust() and kvm_mmu_zap_collapsible_spte() comments were for a post-patch/series scenario wheren PageReserved() is no longer true for ZONE_DEVICE pages. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v1 03/10] KVM: Prepare kvm_is_reserved_pfn() for PG_reserved changes
On Tue, Nov 5, 2019 at 12:31 PM David Hildenbrand wrote:
>
> >>> I think I know what's going wrong:
> >>>
> >>> Pages that are pinned via gfn_to_pfn() and friends take a references,
> >>> however are often released via
> >>> kvm_release_pfn_clean()/kvm_release_pfn_dirty()/kvm_release_page_clean()...
> >>>
> >>>
> >>> E.g., in arch/x86/kvm/x86.c:reexecute_instruction()
> >>>
> >>> ...
> >>> pfn = gfn_to_pfn(vcpu->kvm, gpa_to_gfn(gpa));
> >>> ...
> >>> kvm_release_pfn_clean(pfn);
> >>>
> >>>
> >>>
> >>> void kvm_release_pfn_clean(kvm_pfn_t pfn)
> >>> {
> >>> if (!is_error_noslot_pfn(pfn) && !kvm_is_reserved_pfn(pfn))
> >>> put_page(pfn_to_page(pfn));
> >>> }
> >>>
> >>> This function makes perfect sense as the counterpart for kvm_get_pfn():
> >>>
> >>> void kvm_get_pfn(kvm_pfn_t pfn)
> >>> {
> >>> if (!kvm_is_reserved_pfn(pfn))
> >>> get_page(pfn_to_page(pfn));
> >>> }
> >>>
> >>>
> >>> As all ZONE_DEVICE pages are currently reserved, pages pinned via
> >>> gfn_to_pfn() and friends will often not see a put_page() AFAIKS.
> >
> > Assuming gup() takes a reference for ZONE_DEVICE pages, yes, this is a
> > KVM bug.
>
> Yes, it does take a reference AFAIKs. E.g.,
>
> mm/gup.c:gup_pte_range():
> ...
> if (pte_devmap(pte)) {
> if (unlikely(flags & FOLL_LONGTERM))
> goto pte_unmap;
>
> pgmap = get_dev_pagemap(pte_pfn(pte), pgmap);
> if (unlikely(!pgmap)) {
> undo_dev_pagemap(nr, nr_start, pages);
> goto pte_unmap;
> }
> } else if (pte_special(pte))
> goto pte_unmap;
>
> VM_BUG_ON(!pfn_valid(pte_pfn(pte)));
> page = pte_page(pte);
>
> head = try_get_compound_head(page, 1);
>
> try_get_compound_head() will increment the reference count.
>
> >
> >>> Now, my patch does not change that, the result of
> >>> kvm_is_reserved_pfn(pfn) will be unchanged. A proper fix for that would
> >>> probably be
> >>>
> >>> a) To drop the reference to ZONE_DEVICE pages in gfn_to_pfn() and
> >>> friends, after you successfully pinned the pages. (not sure if that's
> >>> the right thing to do but you're the expert)
> >>>
> >>> b) To not use kvm_release_pfn_clean() and friends on pages that were
> >>> definitely pinned.
> >
> > This is already KVM's intent, i.e. the purpose of the PageReserved() check
> > is simply to avoid putting a non-existent reference. The problem is that
> > KVM assumes pages with PG_reserved set are never pinned, which AFAICT was
> > true when the code was first added.
> >
> >> (talking to myself, sorry)
> >>
> >> Thinking again, dropping this patch from this series could effectively also
> >> fix that issue. E.g., kvm_release_pfn_clean() and friends would always do a
> >> put_page() if "pfn_valid() and !PageReserved()", so after patch 9 also on
> >> ZONDE_DEVICE pages.
> >
> > Yeah, this appears to be the correct fix.
> >
> >> But it would have side effects that might not be desired. E.g.,:
> >>
> >> 1. kvm_pfn_to_page() would also return ZONE_DEVICE pages (might even be the
> >> right thing to do).
> >
> > This should be ok, at least on x86. There are only three users of
> > kvm_pfn_to_page(). Two of those are on allocations that are controlled by
> > KVM and are guaranteed to be vanilla MAP_ANONYMOUS. The third is on guest
> > memory when running a nested guest, and in that case supporting ZONE_DEVICE
> > memory is desirable, i.e. KVM should play nice with a guest that is backed
> > by ZONE_DEVICE memory.
> >
> >> 2. kvm_set_pfn_dirty() would also set ZONE_DEVICE pages dirty (might be
> >> okay)
> >
> > This is ok from a KVM perspective.
>
> What about
>
> void kvm_get_pfn(kvm_pfn_t pfn)
> {
> if (!kvm_is_reserved_pfn(pfn))
> get_page(pfn_to_page(pfn));
> }
>
> Is a pure get_page() sufficient in case of ZONE_DEVICE?
> (asking because of the live references obtained via
> get_dev_pagemap(pte_pfn(pte), pgmap) in mm/gup.c:gup_pte_range()
> somewhat confuse me :) )
It is not sufficient. PTE_DEVMAP is there to tell the gup path "be
careful, this pfn has device-lifetime, make sure the device is pinned
and not actively in the process of dying before pinning any pages
associated with this device".
However, if kvm_get_pfn() is honoring kvm_is_reserved_pfn() that
returns true for ZONE_DEVICE, I'm missing how it is messing up the
reference counts.
> > The scarier code (for me) is transparent_hugepage_adjust() and
> > kvm_mmu_zap_collapsible_spte(), as I don't at all understand the
> > interaction between THP and _PAGE_DEVMAP.
>
> The x86 KVM MMU code is one of the ugliest code I know (sorry, but it
> had to be said :/ ). Luckily, this should be independent of the
> PG_reserved thingy AFAIKs.
Both transparent_hugepage_adjust() and kvm_mmu_zap_collapsible_spte()
are
Re: [Xen-devel] [PATCH v1 03/10] KVM: Prepare kvm_is_reserved_pfn() for PG_reserved changes
On Tue, Nov 05, 2019 at 09:30:53PM +0100, David Hildenbrand wrote:
> >>>I think I know what's going wrong:
> >>>
> >>>Pages that are pinned via gfn_to_pfn() and friends take a references,
> >>>however are often released via
> >>>kvm_release_pfn_clean()/kvm_release_pfn_dirty()/kvm_release_page_clean()...
> >>>
> >>>
> >>>E.g., in arch/x86/kvm/x86.c:reexecute_instruction()
> >>>
> >>>...
> >>>pfn = gfn_to_pfn(vcpu->kvm, gpa_to_gfn(gpa));
> >>>...
> >>>kvm_release_pfn_clean(pfn);
> >>>
> >>>
> >>>
> >>>void kvm_release_pfn_clean(kvm_pfn_t pfn)
> >>>{
> >>> if (!is_error_noslot_pfn(pfn) && !kvm_is_reserved_pfn(pfn))
> >>> put_page(pfn_to_page(pfn));
> >>>}
> >>>
> >>>This function makes perfect sense as the counterpart for kvm_get_pfn():
> >>>
> >>>void kvm_get_pfn(kvm_pfn_t pfn)
> >>>{
> >>> if (!kvm_is_reserved_pfn(pfn))
> >>> get_page(pfn_to_page(pfn));
> >>>}
> >>>
> >>>
> >>>As all ZONE_DEVICE pages are currently reserved, pages pinned via
> >>>gfn_to_pfn() and friends will often not see a put_page() AFAIKS.
> >
> >Assuming gup() takes a reference for ZONE_DEVICE pages, yes, this is a
> >KVM bug.
>
> Yes, it does take a reference AFAIKs. E.g.,
>
> mm/gup.c:gup_pte_range():
> ...
> if (pte_devmap(pte)) {
> if (unlikely(flags & FOLL_LONGTERM))
> goto pte_unmap;
>
> pgmap = get_dev_pagemap(pte_pfn(pte), pgmap);
> if (unlikely(!pgmap)) {
> undo_dev_pagemap(nr, nr_start, pages);
> goto pte_unmap;
> }
> } else if (pte_special(pte))
> goto pte_unmap;
>
> VM_BUG_ON(!pfn_valid(pte_pfn(pte)));
> page = pte_page(pte);
>
> head = try_get_compound_head(page, 1);
>
> try_get_compound_head() will increment the reference count.
Doh, I looked right at that code and somehow didn't connect the dots.
Thanks!
> >>>Now, my patch does not change that, the result of
> >>>kvm_is_reserved_pfn(pfn) will be unchanged. A proper fix for that would
> >>>probably be
> >>>
> >>>a) To drop the reference to ZONE_DEVICE pages in gfn_to_pfn() and
> >>>friends, after you successfully pinned the pages. (not sure if that's
> >>>the right thing to do but you're the expert)
> >>>
> >>>b) To not use kvm_release_pfn_clean() and friends on pages that were
> >>>definitely pinned.
> >
> >This is already KVM's intent, i.e. the purpose of the PageReserved() check
> >is simply to avoid putting a non-existent reference. The problem is that
> >KVM assumes pages with PG_reserved set are never pinned, which AFAICT was
> >true when the code was first added.
> >
> >>(talking to myself, sorry)
> >>
> >>Thinking again, dropping this patch from this series could effectively also
> >>fix that issue. E.g., kvm_release_pfn_clean() and friends would always do a
> >>put_page() if "pfn_valid() and !PageReserved()", so after patch 9 also on
> >>ZONDE_DEVICE pages.
> >
> >Yeah, this appears to be the correct fix.
> >
> >>But it would have side effects that might not be desired. E.g.,:
> >>
> >>1. kvm_pfn_to_page() would also return ZONE_DEVICE pages (might even be the
> >>right thing to do).
> >
> >This should be ok, at least on x86. There are only three users of
> >kvm_pfn_to_page(). Two of those are on allocations that are controlled by
> >KVM and are guaranteed to be vanilla MAP_ANONYMOUS. The third is on guest
> >memory when running a nested guest, and in that case supporting ZONE_DEVICE
> >memory is desirable, i.e. KVM should play nice with a guest that is backed
> >by ZONE_DEVICE memory.
> >
> >>2. kvm_set_pfn_dirty() would also set ZONE_DEVICE pages dirty (might be
> >>okay)
> >
> >This is ok from a KVM perspective.
>
> What about
>
> void kvm_get_pfn(kvm_pfn_t pfn)
> {
> if (!kvm_is_reserved_pfn(pfn))
> get_page(pfn_to_page(pfn));
> }
>
> Is a pure get_page() sufficient in case of ZONE_DEVICE?
> (asking because of the live references obtained via
> get_dev_pagemap(pte_pfn(pte), pgmap) in mm/gup.c:gup_pte_range() somewhat
> confuse me :) )
This ties into my concern with thp_adjust(). On x86, kvm_get_pfn() is
only used in two flows, to manually get a ref for VM_IO/VM_PFNMAP pages
and to switch the ref when mapping a non-hugetlbfs compound page, i.e. a
THP.
I assume VM_IO and PFNMAP can't apply to ZONE_DEVICE pages.
In the thp_adjust() case, when a THP is encountered and the original PFN
is for a non-PG_head page, KVM transfers the reference to the associated
PG_head page[*] and maps the associated 2mb chunk/page. This is where KVM
uses kvm_get_pfn() and could run afoul of the get_dev_pagemap() refcounts.
[*] Technically I don't think it's guaranteed to be a PG_head, e.g. if the
THP is a 1gb page, as KVM currently only maps THP as 2mb pages. But
the idea is the same, transfer the refcount the PFN that's actually
going into
Re: [Xen-devel] [PATCH v5 0/3] x86/boot: Introduce the kernel_info et consortes
On 2019-11-04 07:13, Daniel Kiper wrote: > Hi, > > Due to very limited space in the setup_header this patch series introduces new > kernel_info struct which will be used to convey information from the kernel to > the bootloader. This way the boot protocol can be extended regardless of the > setup_header limitations. Additionally, the patch series introduces some > convenience features like the setup_indirect struct and the > kernel_info.setup_type_max field. > > Daniel > Looks great! Ship it! Reviewed-by: H. Peter Anvin (Intel) -hpa ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 01/15] mm/mmu_notifier: define the header pre-processor parts even if disabled
On 10/28/19 1:10 PM, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> Now that we have KERNEL_HEADER_TEST all headers are generally compile
> tested, so relying on makefile tricks to avoid compiling code that depends
> on CONFIG_MMU_NOTIFIER is more annoying.
>
> Instead follow the usual pattern and provide most of the header with only
> the functions stubbed out when CONFIG_MMU_NOTIFIER is disabled. This
> ensures code compiles no matter what the config setting is.
>
> While here, struct mmu_notifier_mm is private to mmu_notifier.c, move it.
and correct a minor spelling error in a comment. Good. :)
>
> Reviewed-by: Jérôme Glisse
> Signed-off-by: Jason Gunthorpe
> ---
> include/linux/mmu_notifier.h | 46 +---
> mm/mmu_notifier.c| 13 ++
> 2 files changed, 30 insertions(+), 29 deletions(-)
>
Because this is correct as-is, you can add:
Reviewed-by: John Hubbard
...whether or not you take the following recommendation, which is:
you've only done part of the job of making struct mmu_notifier_mm
private to mmu_notifier.c. There's more:
* struct mmu_notifier_mm is referred to in two places now: mm_types.h
and (still) mmu_notifier.h. Therefore:
a) Move the last two traces of it out of mmu_notifier.h, and
b) Put a forward declaration in mm_types.h, which is where it
belongs because that's where it's referred to.
So if you apply this incremental patch on top, I think it's where
you want to be:
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index fa795284..df93a3cc0da9 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -25,6 +25,7 @@
struct address_space;
struct mem_cgroup;
+struct mmu_notifier_mm;
/*
* Each physical page in the system has a struct page associated with
diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h
index 51b92ba013dd..84efd2c51f5c 100644
--- a/include/linux/mmu_notifier.h
+++ b/include/linux/mmu_notifier.h
@@ -8,7 +8,6 @@
#include
#include
-struct mmu_notifier_mm;
struct mmu_notifier;
struct mmu_notifier_range;
struct mmu_range_notifier;
@@ -263,10 +262,7 @@ struct mmu_notifier_range {
enum mmu_notifier_event event;
};
-static inline int mm_has_notifiers(struct mm_struct *mm)
-{
- return unlikely(mm->mmu_notifier_mm);
-}
+int mm_has_notifiers(struct mm_struct *mm);
struct mmu_notifier *mmu_notifier_get_locked(const struct mmu_notifier_ops
*ops,
struct mm_struct *mm);
@@ -477,10 +473,7 @@ static inline void mmu_notifier_invalidate_range(struct
mm_struct *mm,
__mmu_notifier_invalidate_range(mm, start, end);
}
-static inline void mmu_notifier_mm_init(struct mm_struct *mm)
-{
- mm->mmu_notifier_mm = NULL;
-}
+void mmu_notifier_mm_init(struct mm_struct *mm);
static inline void mmu_notifier_mm_destroy(struct mm_struct *mm)
{
diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c
index 2b7485919ecf..107f9406a92d 100644
--- a/mm/mmu_notifier.c
+++ b/mm/mmu_notifier.c
@@ -47,6 +47,16 @@ struct mmu_notifier_mm {
struct hlist_head deferred_list;
};
+int mm_has_notifiers(struct mm_struct *mm)
+{
+ return unlikely(mm->mmu_notifier_mm);
+}
+
+void mmu_notifier_mm_init(struct mm_struct *mm)
+{
+ mm->mmu_notifier_mm = NULL;
+}
+
/*
* This is a collision-retry read-side/write-side 'lock', a lot like a
* seqcount, however this allows multiple write-sides to hold it at
thanks,
John Hubbard
NVIDIA
> diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h
> index 1bd8e6a09a3c27..12bd603d318ce7 100644
> --- a/include/linux/mmu_notifier.h
> +++ b/include/linux/mmu_notifier.h
> @@ -7,8 +7,9 @@
> #include
> #include
>
> +struct mmu_notifier_mm;
> struct mmu_notifier;
> -struct mmu_notifier_ops;
> +struct mmu_notifier_range;
>
> /**
> * enum mmu_notifier_event - reason for the mmu notifier callback
> @@ -40,36 +41,8 @@ enum mmu_notifier_event {
> MMU_NOTIFY_SOFT_DIRTY,
> };
>
> -#ifdef CONFIG_MMU_NOTIFIER
> -
> -#ifdef CONFIG_LOCKDEP
> -extern struct lockdep_map __mmu_notifier_invalidate_range_start_map;
> -#endif
> -
> -/*
> - * The mmu notifier_mm structure is allocated and installed in
> - * mm->mmu_notifier_mm inside the mm_take_all_locks() protected
> - * critical section and it's released only when mm_count reaches zero
> - * in mmdrop().
> - */
> -struct mmu_notifier_mm {
> - /* all mmu notifiers registerd in this mm are queued in this list */
> - struct hlist_head list;
> - /* to serialize the list modifications and hlist_unhashed */
> - spinlock_t lock;
> -};
> -
> #define MMU_NOTIFIER_RANGE_BLOCKABLE (1 << 0)
>
> -struct mmu_notifier_range {
> - struct vm_area_struct *vma;
> - struct mm_struct *mm;
> - unsigned long start;
> - unsigned long end;
> - unsigned flags;
> - enum mmu_notifier_event event;
> -};
> -
> struct mmu_notifier_ops {
[Xen-devel] [freebsd-master test] 143704: regressions - trouble: blocked/fail
flight 143704 freebsd-master real [real] http://logs.test-lab.xenproject.org/osstest/logs/143704/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-freebsd 7 freebsd-buildfail REGR. vs. 141501 Tests which did not succeed, but are not blocking: build-amd64-freebsd-again 1 build-check(1) blocked n/a build-amd64-xen-freebsd 1 build-check(1) blocked n/a version targeted for testing: freebsd 47a6a041b50a6f7e5aa88d66f531fa4a737ea6da baseline version: freebsd 14aef6dfca96006e52b8fb920bde7c612ba58b79 Last test of basis 141501 2019-09-20 09:19:51 Z 46 days Failing since141701 2019-09-23 09:19:41 Z 43 days 18 attempts Testing same since 143704 2019-11-04 10:04:56 Z1 days1 attempts People who touched revisions under test: 0mp <0...@freebsd.org> ae alc Alek Pinchuk allanjude ambrisko andrew asomers avg bapt bdragon bdrewery br brooks brueffer bz cem chs cognet cperciva cy dab daichi dchagin dim dougm emaste erj eugen gallatin gjb glebius gonzo grembo grog hrs hselasky ian imp Jacob Keller jeff jhb jhibbits jilles jkim jlh jmg jtl kaktus kan karels kevans kib kibab kp lstewart luporl lwhsu manu marius markj mav mckusick mhorne mjg mm mmacy mmel mw np olivier oshogbo peterj philip phk Piotr Pietruszewski ray rmacklem royger rpokala rrs rstone samm schweikh scottl sef sjg tijl Tom Caputi trasz tsoome tuexen vangyzen vmaffione wulf yuripv Zach Vargas jobs: build-amd64-freebsd-againblocked build-amd64-freebsd fail build-amd64-xen-freebsd blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 16014 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v1 03/10] KVM: Prepare kvm_is_reserved_pfn() for PG_reserved changes
I think I know what's going wrong:
Pages that are pinned via gfn_to_pfn() and friends take a references,
however are often released via
kvm_release_pfn_clean()/kvm_release_pfn_dirty()/kvm_release_page_clean()...
E.g., in arch/x86/kvm/x86.c:reexecute_instruction()
...
pfn = gfn_to_pfn(vcpu->kvm, gpa_to_gfn(gpa));
...
kvm_release_pfn_clean(pfn);
void kvm_release_pfn_clean(kvm_pfn_t pfn)
{
if (!is_error_noslot_pfn(pfn) && !kvm_is_reserved_pfn(pfn))
put_page(pfn_to_page(pfn));
}
This function makes perfect sense as the counterpart for kvm_get_pfn():
void kvm_get_pfn(kvm_pfn_t pfn)
{
if (!kvm_is_reserved_pfn(pfn))
get_page(pfn_to_page(pfn));
}
As all ZONE_DEVICE pages are currently reserved, pages pinned via
gfn_to_pfn() and friends will often not see a put_page() AFAIKS.
Assuming gup() takes a reference for ZONE_DEVICE pages, yes, this is a
KVM bug.
Yes, it does take a reference AFAIKs. E.g.,
mm/gup.c:gup_pte_range():
...
if (pte_devmap(pte)) {
if (unlikely(flags & FOLL_LONGTERM))
goto pte_unmap;
pgmap = get_dev_pagemap(pte_pfn(pte), pgmap);
if (unlikely(!pgmap)) {
undo_dev_pagemap(nr, nr_start, pages);
goto pte_unmap;
}
} else if (pte_special(pte))
goto pte_unmap;
VM_BUG_ON(!pfn_valid(pte_pfn(pte)));
page = pte_page(pte);
head = try_get_compound_head(page, 1);
try_get_compound_head() will increment the reference count.
Now, my patch does not change that, the result of
kvm_is_reserved_pfn(pfn) will be unchanged. A proper fix for that would
probably be
a) To drop the reference to ZONE_DEVICE pages in gfn_to_pfn() and
friends, after you successfully pinned the pages. (not sure if that's
the right thing to do but you're the expert)
b) To not use kvm_release_pfn_clean() and friends on pages that were
definitely pinned.
This is already KVM's intent, i.e. the purpose of the PageReserved() check
is simply to avoid putting a non-existent reference. The problem is that
KVM assumes pages with PG_reserved set are never pinned, which AFAICT was
true when the code was first added.
(talking to myself, sorry)
Thinking again, dropping this patch from this series could effectively also
fix that issue. E.g., kvm_release_pfn_clean() and friends would always do a
put_page() if "pfn_valid() and !PageReserved()", so after patch 9 also on
ZONDE_DEVICE pages.
Yeah, this appears to be the correct fix.
But it would have side effects that might not be desired. E.g.,:
1. kvm_pfn_to_page() would also return ZONE_DEVICE pages (might even be the
right thing to do).
This should be ok, at least on x86. There are only three users of
kvm_pfn_to_page(). Two of those are on allocations that are controlled by
KVM and are guaranteed to be vanilla MAP_ANONYMOUS. The third is on guest
memory when running a nested guest, and in that case supporting ZONE_DEVICE
memory is desirable, i.e. KVM should play nice with a guest that is backed
by ZONE_DEVICE memory.
2. kvm_set_pfn_dirty() would also set ZONE_DEVICE pages dirty (might be
okay)
This is ok from a KVM perspective.
What about
void kvm_get_pfn(kvm_pfn_t pfn)
{
if (!kvm_is_reserved_pfn(pfn))
get_page(pfn_to_page(pfn));
}
Is a pure get_page() sufficient in case of ZONE_DEVICE?
(asking because of the live references obtained via
get_dev_pagemap(pte_pfn(pte), pgmap) in mm/gup.c:gup_pte_range()
somewhat confuse me :) )
The scarier code (for me) is transparent_hugepage_adjust() and
kvm_mmu_zap_collapsible_spte(), as I don't at all understand the
interaction between THP and _PAGE_DEVMAP.
The x86 KVM MMU code is one of the ugliest code I know (sorry, but it
had to be said :/ ). Luckily, this should be independent of the
PG_reserved thingy AFAIKs.
--
Thanks,
David / dhildenb
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PULL v2 0/3] Trivial branch patches
Le 05/11/2019 à 20:20, no-re...@patchew.org a écrit : > Patchew URL: https://patchew.org/QEMU/20191105175010.2591-1-laur...@vivier.eu/ > > > > Hi, > > This series seems to have some coding style problems. See output below for > more information: > > Subject: [Xen-devel] [PULL v2 0/3] Trivial branch patches > Type: series > Message-id: 20191105175010.2591-1-laur...@vivier.eu > > === TEST SCRIPT BEGIN === > #!/bin/bash > git rev-parse base > /dev/null || exit 0 > git config --local diff.renamelimit 0 > git config --local diff.renames True > git config --local diff.algorithm histogram > ./scripts/checkpatch.pl --mailback base.. > === TEST SCRIPT END === > > Switched to a new branch 'test' > 49a55f7 global: Squash 'the the' > c0b5513 hw/misc/grlib_ahb_apb_pnp: Fix 8-bit accesses > eb43395 hw/misc/grlib_ahb_apb_pnp: Avoid crash when writing to PnP registers > > === OUTPUT BEGIN === > 1/3 Checking commit eb43395bf8f1 (hw/misc/grlib_ahb_apb_pnp: Avoid crash when > writing to PnP registers) > 2/3 Checking commit c0b5513f971a (hw/misc/grlib_ahb_apb_pnp: Fix 8-bit > accesses) > 3/3 Checking commit 49a55f7feb19 (global: Squash 'the the') > ERROR: do not use C99 // comments > #26: FILE: disas/libvixl/vixl/invalset.h:105: > + // Note that this does not mean the backing storage is empty: it can still As reported by David Gilbert, this is a false positive as this file is a C++ file. Thanks, LAurent ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v1.5] x86/livepatch: Prevent patching with active waitqueues
The safety of livepatching depends on every stack having been unwound, but
there is one corner case where this is not true. The Sharing/Paging/Monitor
infrastructure may use waitqueues, which copy the stack frame sideways and
longjmp() to a different vcpu.
This case is rare, and can be worked around by pausing the offending
domain(s), waiting for their rings to drain, then performing a livepatch.
In the case that there is an active waitqueue, fail the livepatch attempt with
-EBUSY, which is preforable to the fireworks which occur from trying to unwind
the old stack frame at a later point.
Signed-off-by: Andrew Cooper
---
CC: Konrad Rzeszutek Wilk
CC: Ross Lagerwall
CC: Juergen Gross
This fix wants backporting, and is long overdue for posting upstream.
v1.5:
* Send out a non-stale patch this time.
---
xen/arch/arm/livepatch.c| 5 +
xen/arch/x86/livepatch.c| 40
xen/common/livepatch.c | 8
xen/include/xen/livepatch.h | 1 +
4 files changed, 54 insertions(+)
diff --git a/xen/arch/arm/livepatch.c b/xen/arch/arm/livepatch.c
index 00c5e2bc45..915e9d926a 100644
--- a/xen/arch/arm/livepatch.c
+++ b/xen/arch/arm/livepatch.c
@@ -18,6 +18,11 @@
void *vmap_of_xen_text;
+int arch_livepatch_safety_check(void)
+{
+return 0;
+}
+
int arch_livepatch_quiesce(void)
{
mfn_t text_mfn;
diff --git a/xen/arch/x86/livepatch.c b/xen/arch/x86/livepatch.c
index c82cf53b9e..2749cbc5cf 100644
--- a/xen/arch/x86/livepatch.c
+++ b/xen/arch/x86/livepatch.c
@@ -10,10 +10,50 @@
#include
#include
#include
+#include
#include
#include
+static bool has_active_waitqueue(const struct vm_event_domain *ved)
+{
+/* ved may be xzalloc()'d without INIT_LIST_HEAD() yet. */
+return (ved && !list_head_is_null(>wq.list) &&
+!list_empty(>wq.list));
+}
+
+/*
+ * x86's implementation of waitqueue violates the livepatching safey principle
+ * of having unwound every CPUs stack before modifying live content.
+ *
+ * Search through every domain and check that no vCPUs have an active
+ * waitqueue.
+ */
+int arch_livepatch_safety_check(void)
+{
+struct domain *d;
+
+for_each_domain ( d )
+{
+#ifdef CONFIG_MEM_SHARING
+if ( has_active_waitqueue(d->vm_event_share) )
+goto fail;
+#endif
+#ifdef CONFIG_MEM_PAGING
+if ( has_active_waitqueue(d->vm_event_paging) )
+goto fail;
+#endif
+if ( has_active_waitqueue(d->vm_event_monitor) )
+goto fail;
+}
+
+return 0;
+
+ fail:
+printk(XENLOG_ERR LIVEPATCH "%pd found with active waitqueue\n", d);
+return -EBUSY;
+}
+
int arch_livepatch_quiesce(void)
{
/* Disable WP to allow changes to read-only pages. */
diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
index 962647616a..8386e611f2 100644
--- a/xen/common/livepatch.c
+++ b/xen/common/livepatch.c
@@ -1060,6 +1060,14 @@ static int apply_payload(struct payload *data)
unsigned int i;
int rc;
+rc = arch_livepatch_safety_check();
+if ( rc )
+{
+printk(XENLOG_ERR LIVEPATCH "%s: Safety checks failed: %d\n",
+ data->name, rc);
+return rc;
+}
+
printk(XENLOG_INFO LIVEPATCH "%s: Applying %u functions\n",
data->name, data->nfuncs);
diff --git a/xen/include/xen/livepatch.h b/xen/include/xen/livepatch.h
index 1b1817ca0d..69ede75d20 100644
--- a/xen/include/xen/livepatch.h
+++ b/xen/include/xen/livepatch.h
@@ -104,6 +104,7 @@ static inline int livepatch_verify_distance(const struct
livepatch_func *func)
* These functions are called around the critical region patching live code,
* for an architecture to take make appropratie global state adjustments.
*/
+int arch_livepatch_safety_check(void);
int arch_livepatch_quiesce(void);
void arch_livepatch_revive(void);
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-linus test] 143581: regressions - FAIL
flight 143581 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/143581/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-win10-i386 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-qemuu-rhel6hvm-intel 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 133580 test-amd64-i386-libvirt 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 133580 test-amd64-i386-freebsd10-i386 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-examine 8 reboot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 133580 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 133580 test-amd64-i386-xl7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemut-win7-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-freebsd10-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-pvshim 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-qemuu-rhel6hvm-amd 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-ovmf-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-qemut-rhel6hvm-amd 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-win7-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemut-debianhvm-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemut-ws16-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 133580 test-amd64-i386-libvirt-xsm 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemut-win10-i386 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-shadow 7 xen-boot fail REGR. vs. 133580 test-amd64-amd64-xl-qcow2 19 guest-start/debian.repeat fail REGR. vs. 133580 test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail REGR. vs. 133580 test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail REGR. vs. 133580 test-armhf-armhf-libvirt-raw 15 guest-start/debian.repeat fail REGR. vs. 133580 test-armhf-armhf-xl-vhd 15 guest-start/debian.repeat fail REGR. vs. 133580 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail REGR. vs. 133580 test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail REGR. vs. 133580 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 7 xen-boot fail baseline untested test-amd64-i386-xl-qemut-debianhvm-i386-xsm 7 xen-boot fail baseline untested test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 133580 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 133580 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 133580 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 133580 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 133580 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 133580 test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass
[Xen-devel] [PATCH for-4.13 0/2] xen/livepatch: Safety fixes
This pair of patches is long overdue being posted upstream. For several years now, XenServer has shipped the 2nd patch as a safety check (seeing as we have both livepatching and introspection), implemented with some return address manipulation to turn a void load hook into one which can return -EBUSY. Andrew Cooper (2): xen/livepatch: Add a return value to load hooks x86/livepatch: Prevent patching with active waitqueues xen/arch/arm/livepatch.c | 5 + xen/arch/x86/livepatch.c | 39 xen/common/livepatch.c | 37 -- xen/include/xen/livepatch.h | 1 + xen/include/xen/livepatch_payload.h | 2 +- xen/test/livepatch/xen_hello_world.c | 12 --- 6 files changed, 81 insertions(+), 15 deletions(-) -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 1/2] xen/livepatch: Add a return value to load hooks
One use of load hooks is to perform a safety check of the system in its
quiesced state. Any non-zero return value from a load hook will abort the
apply attempt.
Signed-off-by: Andrew Cooper
---
CC: Konrad Rzeszutek Wilk
CC: Ross Lagerwall
CC: Juergen Gross
For several years, the following patch in the series has been shipped in every
XenServer livepatch, implemented as a void load hook which modifies its return
address to skip to the end of apply_payload(). This method is distinctly less
hacky.
---
xen/common/livepatch.c | 30 +++---
xen/include/xen/livepatch_payload.h | 2 +-
xen/test/livepatch/xen_hello_world.c | 12 +---
3 files changed, 29 insertions(+), 15 deletions(-)
diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
index 7caa30c202..962647616a 100644
--- a/xen/common/livepatch.c
+++ b/xen/common/livepatch.c
@@ -1076,25 +1076,33 @@ static int apply_payload(struct payload *data)
* temporarily disable the spin locks IRQ state checks.
*/
spin_debug_disable();
-for ( i = 0; i < data->n_load_funcs; i++ )
-data->load_funcs[i]();
+for ( i = 0; !rc && i < data->n_load_funcs; i++ )
+rc = data->load_funcs[i]();
spin_debug_enable();
+if ( rc )
+printk(XENLOG_ERR LIVEPATCH "%s: load_funcs[%u] failed: %d\n",
+ data->name, i, rc);
+
ASSERT(!local_irq_is_enabled());
-for ( i = 0; i < data->nfuncs; i++ )
-arch_livepatch_apply(>funcs[i]);
+if ( !rc )
+for ( i = 0; i < data->nfuncs; i++ )
+arch_livepatch_apply(>funcs[i]);
arch_livepatch_revive();
-/*
- * We need RCU variant (which has barriers) in case we crash here.
- * The applied_list is iterated by the trap code.
- */
-list_add_tail_rcu(>applied_list, _list);
-register_virtual_region(>region);
+if ( !rc )
+{
+/*
+ * We need RCU variant (which has barriers) in case we crash here.
+ * The applied_list is iterated by the trap code.
+ */
+list_add_tail_rcu(>applied_list, _list);
+register_virtual_region(>region);
+}
-return 0;
+return rc;
}
static int revert_payload(struct payload *data)
diff --git a/xen/include/xen/livepatch_payload.h
b/xen/include/xen/livepatch_payload.h
index 4a1a96d054..3788b52ddf 100644
--- a/xen/include/xen/livepatch_payload.h
+++ b/xen/include/xen/livepatch_payload.h
@@ -9,7 +9,7 @@
* The following definitions are to be used in patches. They are taken
* from kpatch.
*/
-typedef void livepatch_loadcall_t(void);
+typedef int livepatch_loadcall_t(void);
typedef void livepatch_unloadcall_t(void);
/*
diff --git a/xen/test/livepatch/xen_hello_world.c
b/xen/test/livepatch/xen_hello_world.c
index 02f3f85dc0..d720001f07 100644
--- a/xen/test/livepatch/xen_hello_world.c
+++ b/xen/test/livepatch/xen_hello_world.c
@@ -16,9 +16,11 @@ static const char hello_world_patch_this_fnc[] =
"xen_extra_version";
extern const char *xen_hello_world(void);
static unsigned int cnt;
-static void apply_hook(void)
+static int apply_hook(void)
{
printk(KERN_DEBUG "Hook executing.\n");
+
+return 0;
}
static void revert_hook(void)
@@ -26,10 +28,14 @@ static void revert_hook(void)
printk(KERN_DEBUG "Hook unloaded.\n");
}
-static void hi_func(void)
+static int hi_func(void)
{
printk(KERN_DEBUG "%s: Hi! (called %u times)\n", __func__, ++cnt);
+
+return 0;
};
+/* Safe to cast away the return value for this trivial case. */
+void (void_hi_func)(void) __attribute__((alias("hi_func")));
static void check_fnc(void)
{
@@ -43,7 +49,7 @@ LIVEPATCH_UNLOAD_HOOK(revert_hook);
/* Imbalance here. Two load and three unload. */
LIVEPATCH_LOAD_HOOK(hi_func);
-LIVEPATCH_UNLOAD_HOOK(hi_func);
+LIVEPATCH_UNLOAD_HOOK(void_hi_func);
LIVEPATCH_UNLOAD_HOOK(check_fnc);
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 2/2] x86/livepatch: Prevent patching with active waitqueues
The safety of livepatching depends on every stack having been unwound, but
there is one corner case where this is not true. The Sharing/Paging/Monitor
infrastructure may use waitqueues, which copy the stack frame sideways and
longjmp() to a different vcpu.
This case is rare, and can be worked around by pausing the offending
domain(s), waiting for their rings to drain, then performing a livepatch.
In the case that there is an active waitqueue, fail the livepatch attempt with
-EBUSY, which is preforable to the fireworks which occur from trying to unwind
the old stack frame at a later point.
Signed-off-by: Andrew Cooper
---
CC: Konrad Rzeszutek Wilk
CC: Ross Lagerwall
CC: Juergen Gross
This fix wants backporting, and is long overdue for posting upstream.
---
xen/arch/arm/livepatch.c| 5 +
xen/arch/x86/livepatch.c| 39 +++
xen/common/livepatch.c | 7 +++
xen/include/xen/livepatch.h | 1 +
4 files changed, 52 insertions(+)
diff --git a/xen/arch/arm/livepatch.c b/xen/arch/arm/livepatch.c
index 00c5e2bc45..915e9d926a 100644
--- a/xen/arch/arm/livepatch.c
+++ b/xen/arch/arm/livepatch.c
@@ -18,6 +18,11 @@
void *vmap_of_xen_text;
+int arch_livepatch_safety_check(void)
+{
+return 0;
+}
+
int arch_livepatch_quiesce(void)
{
mfn_t text_mfn;
diff --git a/xen/arch/x86/livepatch.c b/xen/arch/x86/livepatch.c
index c82cf53b9e..0f129fa6b2 100644
--- a/xen/arch/x86/livepatch.c
+++ b/xen/arch/x86/livepatch.c
@@ -14,6 +14,45 @@
#include
#include
+static bool has_active_waitqueue(const struct vm_event_domain *ved)
+{
+/* ved may be xzalloc()'d without INIT_LIST_HEAD() yet. */
+return (ved && !list_head_is_null(>wq.list) &&
+!list_empty(>wq.list));
+}
+
+/*
+ * x86's implementation of waitqueue violates the livepatching safey principle
+ * of having unwound every CPUs stack before modifying live content.
+ *
+ * Search through every domain and check that no vCPUs have an active
+ * waitqueue.
+ */
+int arch_livepatch_safety_check(void);
+{
+struct domain *d;
+
+for_each_domain ( d )
+{
+#ifdef CONFIG_MEM_SHARING
+if ( has_active_waitqueue(d->vm_event_share) )
+goto fail;
+#endif
+#ifdef CONFIG_MEM_PAGING
+if ( has_active_waitqueue(d->vm_event_paging) )
+goto fail;
+#endif
+if ( has_active_waitqueue(d->vm_event_monitor) )
+goto fail;
+}
+
+return 0;
+
+ fail:
+printk(XENLOG_ERR LIVEPATCH "%pd found with active waitqueue\n", d);
+return -EBUSY;
+}
+
int arch_livepatch_quiesce(void)
{
/* Disable WP to allow changes to read-only pages. */
diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
index 962647616a..27ee5bdeb7 100644
--- a/xen/common/livepatch.c
+++ b/xen/common/livepatch.c
@@ -1060,6 +1060,13 @@ static int apply_payload(struct payload *data)
unsigned int i;
int rc;
+rc = apply_safety_checks();
+if ( rc )
+{
+printk(XENLOG_ERR LIVEPATCH "%s: Safety checks failed\n", data->name);
+return rc;
+}
+
printk(XENLOG_INFO LIVEPATCH "%s: Applying %u functions\n",
data->name, data->nfuncs);
diff --git a/xen/include/xen/livepatch.h b/xen/include/xen/livepatch.h
index 1b1817ca0d..69ede75d20 100644
--- a/xen/include/xen/livepatch.h
+++ b/xen/include/xen/livepatch.h
@@ -104,6 +104,7 @@ static inline int livepatch_verify_distance(const struct
livepatch_func *func)
* These functions are called around the critical region patching live code,
* for an architecture to take make appropratie global state adjustments.
*/
+int arch_livepatch_safety_check(void);
int arch_livepatch_quiesce(void);
void arch_livepatch_revive(void);
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PULL v2 0/3] Trivial branch patches
Patchew URL: https://patchew.org/QEMU/20191105175010.2591-1-laur...@vivier.eu/ Hi, This series seems to have some coding style problems. See output below for more information: Subject: [Xen-devel] [PULL v2 0/3] Trivial branch patches Type: series Message-id: 20191105175010.2591-1-laur...@vivier.eu === TEST SCRIPT BEGIN === #!/bin/bash git rev-parse base > /dev/null || exit 0 git config --local diff.renamelimit 0 git config --local diff.renames True git config --local diff.algorithm histogram ./scripts/checkpatch.pl --mailback base.. === TEST SCRIPT END === Switched to a new branch 'test' 49a55f7 global: Squash 'the the' c0b5513 hw/misc/grlib_ahb_apb_pnp: Fix 8-bit accesses eb43395 hw/misc/grlib_ahb_apb_pnp: Avoid crash when writing to PnP registers === OUTPUT BEGIN === 1/3 Checking commit eb43395bf8f1 (hw/misc/grlib_ahb_apb_pnp: Avoid crash when writing to PnP registers) 2/3 Checking commit c0b5513f971a (hw/misc/grlib_ahb_apb_pnp: Fix 8-bit accesses) 3/3 Checking commit 49a55f7feb19 (global: Squash 'the the') ERROR: do not use C99 // comments #26: FILE: disas/libvixl/vixl/invalset.h:105: + // Note that this does not mean the backing storage is empty: it can still total: 1 errors, 0 warnings, 56 lines checked Patch 3/3 has style problems, please review. If any of these errors are false positives report them to the maintainer, see CHECKPATCH in MAINTAINERS. === OUTPUT END === Test command exited with code: 1 The full log is available at http://patchew.org/logs/20191105175010.2591-1-laur...@vivier.eu/testing.checkpatch/?type=message. --- Email generated automatically by Patchew [https://patchew.org/]. Please send your feedback to patchew-de...@redhat.com ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-4.4 test] 143646: regressions - FAIL
flight 143646 linux-4.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/143646/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qcow2 19 guest-start/debian.repeat fail REGR. vs. 139698 test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail REGR. vs. 139698 test-amd64-i386-xl-raw 19 guest-start/debian.repeat fail REGR. vs. 139698 test-armhf-armhf-libvirt-raw 15 guest-start/debian.repeat fail REGR. vs. 139698 test-armhf-armhf-xl-vhd 15 guest-start/debian.repeat fail REGR. vs. 139698 test-amd64-amd64-xl-pvshim 18 guest-localmigrate/x10 fail in 143425 REGR. vs. 139698 Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 143548 pass in 143425 test-amd64-amd64-xl-pvshim 12 guest-startfail pass in 143425 test-armhf-armhf-xl-credit2 7 xen-boot fail pass in 143548 test-armhf-armhf-xl-rtds 12 guest-startfail pass in 143548 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail REGR. vs. 139698 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-credit2 13 migrate-support-check fail in 143425 never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail in 143425 never pass test-armhf-armhf-xl-rtds13 migrate-support-check fail in 143425 never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail in 143425 never pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass version targeted for testing: linux
Re: [Xen-devel] [PULL 0/4] Trivial branch patches
Patchew URL: https://patchew.org/QEMU/20191105144247.10301-1-laur...@vivier.eu/ Hi, This series seems to have some coding style problems. See output below for more information: Subject: [PULL 0/4] Trivial branch patches Type: series Message-id: 20191105144247.10301-1-laur...@vivier.eu === TEST SCRIPT BEGIN === #!/bin/bash git rev-parse base > /dev/null || exit 0 git config --local diff.renamelimit 0 git config --local diff.renames True git config --local diff.algorithm histogram ./scripts/checkpatch.pl --mailback base.. === TEST SCRIPT END === Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384 Switched to a new branch 'test' 0102c79 global: Squash 'the the' 9c583b0 qom: Fix error message in object_class_property_add() 299eefd hw/misc/grlib_ahb_apb_pnp: Fix 8-bit accesses c931231 hw/misc/grlib_ahb_apb_pnp: Avoid crash when writing to PnP registers === OUTPUT BEGIN === 1/4 Checking commit c93123187df2 (hw/misc/grlib_ahb_apb_pnp: Avoid crash when writing to PnP registers) 2/4 Checking commit 299eefd37522 (hw/misc/grlib_ahb_apb_pnp: Fix 8-bit accesses) 3/4 Checking commit 9c583b04fdb1 (qom: Fix error message in object_class_property_add()) WARNING: line over 80 characters #31: FILE: qom/object.c:1109: +error_setg(errp, "attempt to add duplicate property '%s' to object (type '%s')", WARNING: line over 80 characters #43: FILE: qom/object.c:1141: +error_setg(errp, "attempt to add duplicate property '%s' to class (type '%s')", total: 0 errors, 2 warnings, 22 lines checked Patch 3/4 has style problems, please review. If any of these errors are false positives report them to the maintainer, see CHECKPATCH in MAINTAINERS. 4/4 Checking commit 0102c79a3068 (global: Squash 'the the') ERROR: do not use C99 // comments #26: FILE: disas/libvixl/vixl/invalset.h:105: + // Note that this does not mean the backing storage is empty: it can still total: 1 errors, 0 warnings, 56 lines checked Patch 4/4 has style problems, please review. If any of these errors are false positives report them to the maintainer, see CHECKPATCH in MAINTAINERS. === OUTPUT END === Test command exited with code: 1 The full log is available at http://patchew.org/logs/20191105144247.10301-1-laur...@vivier.eu/testing.checkpatch/?type=message. --- Email generated automatically by Patchew [https://patchew.org/]. Please send your feedback to patchew-de...@redhat.com ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PULL v2 2/3] hw/misc/grlib_ahb_apb_pnp: Fix 8-bit accesses
From: Philippe Mathieu-Daudé
The Plug & Play region of the AHB/APB bridge can be accessed
by various word size, however the implementation is clearly
restricted to 32-bit:
static uint64_t grlib_apb_pnp_read(void *opaque, hwaddr offset, unsigned size)
{
APBPnp *apb_pnp = GRLIB_APB_PNP(opaque);
return apb_pnp->regs[offset >> 2];
}
Set the MemoryRegionOps::impl min/max fields to 32-bit, so
memory.c::access_with_adjusted_size() can adjust when the
access is not 32-bit.
This is required to run RTEMS on leon3, the grlib scanning
functions do byte accesses.
Reported-by: Jiri Gaisler
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: KONRAD Frederic
Message-Id: <20191025110114.27091-3-phi...@redhat.com>
Signed-off-by: Laurent Vivier
---
hw/misc/grlib_ahb_apb_pnp.c | 4
1 file changed, 4 insertions(+)
diff --git a/hw/misc/grlib_ahb_apb_pnp.c b/hw/misc/grlib_ahb_apb_pnp.c
index f3c015d2c35f..e230e2536361 100644
--- a/hw/misc/grlib_ahb_apb_pnp.c
+++ b/hw/misc/grlib_ahb_apb_pnp.c
@@ -242,6 +242,10 @@ static const MemoryRegionOps grlib_apb_pnp_ops = {
.read = grlib_apb_pnp_read,
.write = grlib_apb_pnp_write,
.endianness = DEVICE_BIG_ENDIAN,
+.impl = {
+.min_access_size = 4,
+.max_access_size = 4,
+},
};
static void grlib_apb_pnp_realize(DeviceState *dev, Error **errp)
--
2.21.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PULL v2 3/3] global: Squash 'the the'
From: "Dr. David Alan Gilbert"
'the' has a tendency to double up; squash them back down.
Signed-off-by: Dr. David Alan Gilbert
Reviewed-by: Alex Bennée
Reviewed-by: Laurent Vivier
Reviewed-by: Philippe Mathieu-Daudé
Message-Id: <20191104185202.102504-1-dgilb...@redhat.com>
Signed-off-by: Laurent Vivier
---
disas/libvixl/vixl/invalset.h | 2 +-
docs/interop/pr-helper.rst | 2 +-
docs/specs/ppc-spapr-hotplug.txt| 2 +-
docs/specs/ppc-xive.rst | 2 +-
docs/specs/tpm.txt | 2 +-
include/hw/xen/interface/io/blkif.h | 2 +-
scripts/dump-guest-memory.py| 2 +-
7 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/disas/libvixl/vixl/invalset.h b/disas/libvixl/vixl/invalset.h
index ffdc0237b47c..ef5e49d6feb2 100644
--- a/disas/libvixl/vixl/invalset.h
+++ b/disas/libvixl/vixl/invalset.h
@@ -102,7 +102,7 @@ template class InvalSet {
size_t size() const;
// Returns true if no elements are stored in the set.
- // Note that this does not mean the the backing storage is empty: it can
still
+ // Note that this does not mean the backing storage is empty: it can still
// contain invalid elements.
bool empty() const;
diff --git a/docs/interop/pr-helper.rst b/docs/interop/pr-helper.rst
index 9f76d5bcf98f..e926f0a6c9cb 100644
--- a/docs/interop/pr-helper.rst
+++ b/docs/interop/pr-helper.rst
@@ -10,7 +10,7 @@ can delegate implementation of persistent reservations to an
external
restricting access to block devices to specific initiators in a shared
storage setup.
-For a more detailed reference please refer the the SCSI Primary
+For a more detailed reference please refer to the SCSI Primary
Commands standard, specifically the section on Reservations and the
"PERSISTENT RESERVE IN" and "PERSISTENT RESERVE OUT" commands.
diff --git a/docs/specs/ppc-spapr-hotplug.txt b/docs/specs/ppc-spapr-hotplug.txt
index cc7833108e12..859d52cce6c8 100644
--- a/docs/specs/ppc-spapr-hotplug.txt
+++ b/docs/specs/ppc-spapr-hotplug.txt
@@ -385,7 +385,7 @@ Each LMB list entry consists of the following elements:
is used to retrieve the right associativity list to be used for this
LMB.
- A 32bit flags word. The bit at bit position 0x0008 defines whether
- the LMB is assigned to the the partition as of boot time.
+ the LMB is assigned to the partition as of boot time.
ibm,dynamic-memory-v2
diff --git a/docs/specs/ppc-xive.rst b/docs/specs/ppc-xive.rst
index 148d57eb6ab2..83d43f658b90 100644
--- a/docs/specs/ppc-xive.rst
+++ b/docs/specs/ppc-xive.rst
@@ -163,7 +163,7 @@ Interrupt Priority Register (PIPR) is also updated using
the IPB. This
register represent the priority of the most favored pending
notification.
-The PIPR is then compared to the the Current Processor Priority
+The PIPR is then compared to the Current Processor Priority
Register (CPPR). If it is more favored (numerically less than), the
CPU interrupt line is raised and the EO bit of the Notification Source
Register (NSR) is updated to notify the presence of an exception for
diff --git a/docs/specs/tpm.txt b/docs/specs/tpm.txt
index 5d8c26b1adba..9c8cca042da8 100644
--- a/docs/specs/tpm.txt
+++ b/docs/specs/tpm.txt
@@ -89,7 +89,7 @@ TPM upon reboot. The PPI specification defines the operation
requests and the
actions the firmware has to take. The system administrator passes the operation
request number to the firmware through an ACPI interface which writes this
number to a memory location that the firmware knows. Upon reboot, the firmware
-finds the number and sends commands to the the TPM. The firmware writes the TPM
+finds the number and sends commands to the TPM. The firmware writes the TPM
result code and the operation request number to a memory location that ACPI can
read from and pass the result on to the administrator.
diff --git a/include/hw/xen/interface/io/blkif.h
b/include/hw/xen/interface/io/blkif.h
index 8b1be50ce81e..d07fa1e07822 100644
--- a/include/hw/xen/interface/io/blkif.h
+++ b/include/hw/xen/interface/io/blkif.h
@@ -341,7 +341,7 @@
* access (even when it should be read-only). If the frontend hits the
* maximum number of allowed persistently mapped grants, it can fallback
* to non persistent mode. This will cause a performance degradation,
- * since the the backend driver will still try to map those grants
+ * since the backend driver will still try to map those grants
* persistently. Since the persistent grants protocol is compatible with
* the previous protocol, a frontend driver can choose to work in
* persistent mode even when the backend doesn't support it.
diff --git a/scripts/dump-guest-memory.py b/scripts/dump-guest-memory.py
index 2c587cbefc57..9371e4581308 100644
--- a/scripts/dump-guest-memory.py
+++ b/scripts/dump-guest-memory.py
@@ -170,7 +170,7 @@ class ELF(object):
self.ehdr.e_phnum += 1
def to_file(self, elf_file):
-"""Writes all ELF structures
[Xen-devel] [PULL v2 1/3] hw/misc/grlib_ahb_apb_pnp: Avoid crash when writing to PnP registers
From: Philippe Mathieu-Daudé
Guests can crash QEMU when writting to PnP registers:
$ echo 'writeb 0x800ff042 69' | qemu-system-sparc -M leon3_generic -S -bios
/etc/magic -qtest stdio
[I 1571938309.932255] OPENED
[R +0.063474] writeb 0x800ff042 69
Segmentation fault (core dumped)
(gdb) bt
#0 0x in ()
#1 0x555f4bcdf0bc in memory_region_write_with_attrs_accessor
(mr=0x555f4d7be8c0, addr=66, value=0x7fff07d00f08, size=1, shift=0, mask=255,
attrs=...) at memory.c:503
#2 0x555f4bcdf185 in access_with_adjusted_size (addr=66,
value=0x7fff07d00f08, size=1, access_size_min=1, access_size_max=4,
access_fn=0x555f4bcdeff4 ,
mr=0x555f4d7be8c0, attrs=...) at memory.c:539
#3 0x555f4bce2243 in memory_region_dispatch_write (mr=0x555f4d7be8c0,
addr=66, data=69, op=MO_8, attrs=...) at memory.c:1489
#4 0x555f4bc80b20 in flatview_write_continue (fv=0x555f4d92c400,
addr=2148528194, attrs=..., buf=0x7fff07d01120 "E", len=1, addr1=66, l=1,
mr=0x555f4d7be8c0) at exec.c:3161
#5 0x555f4bc80c65 in flatview_write (fv=0x555f4d92c400, addr=2148528194,
attrs=..., buf=0x7fff07d01120 "E", len=1) at exec.c:3201
#6 0x555f4bc80fb0 in address_space_write (as=0x555f4d7aa460,
addr=2148528194, attrs=..., buf=0x7fff07d01120 "E", len=1) at exec.c:3291
#7 0x555f4bc8101d in address_space_rw (as=0x555f4d7aa460,
addr=2148528194, attrs=..., buf=0x7fff07d01120 "E", len=1, is_write=true) at
exec.c:3301
#8 0x555f4bcdb388 in qtest_process_command (chr=0x555f4c2ed7e0
, words=0x555f4db0c5d0) at qtest.c:432
Instead of crashing, log the access as unimplemented.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: KONRAD Frederic
Message-Id: <20191025110114.27091-2-phi...@redhat.com>
Signed-off-by: Laurent Vivier
---
hw/misc/grlib_ahb_apb_pnp.c | 8
1 file changed, 8 insertions(+)
diff --git a/hw/misc/grlib_ahb_apb_pnp.c b/hw/misc/grlib_ahb_apb_pnp.c
index 7338461694c9..f3c015d2c35f 100644
--- a/hw/misc/grlib_ahb_apb_pnp.c
+++ b/hw/misc/grlib_ahb_apb_pnp.c
@@ -22,6 +22,7 @@
*/
#include "qemu/osdep.h"
+#include "qemu/log.h"
#include "hw/sysbus.h"
#include "hw/misc/grlib_ahb_apb_pnp.h"
@@ -231,8 +232,15 @@ static uint64_t grlib_apb_pnp_read(void *opaque, hwaddr
offset, unsigned size)
return apb_pnp->regs[offset >> 2];
}
+static void grlib_apb_pnp_write(void *opaque, hwaddr addr,
+uint64_t val, unsigned size)
+{
+qemu_log_mask(LOG_UNIMP, "%s not implemented\n", __func__);
+}
+
static const MemoryRegionOps grlib_apb_pnp_ops = {
.read = grlib_apb_pnp_read,
+.write = grlib_apb_pnp_write,
.endianness = DEVICE_BIG_ENDIAN,
};
--
2.21.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PULL v2 0/3] Trivial branch patches
The following changes since commit 36609b4fa36f0ac934874371874416f7533a5408: Merge remote-tracking branch 'remotes/palmer/tags/palmer-for-master-4.2-sf1' into staging (2019-11-02 17:59:03 +) are available in the Git repository at: git://github.com/vivier/qemu.git tags/trivial-branch-pull-request for you to fetch changes up to e187e55ec65039ed6bd982debee632450ace3bae: global: Squash 'the the' (2019-11-05 18:39:14 +0100) Trivial fixes (20191105-v2) Dr. David Alan Gilbert (1): global: Squash 'the the' Philippe Mathieu-Daudé (2): hw/misc/grlib_ahb_apb_pnp: Avoid crash when writing to PnP registers hw/misc/grlib_ahb_apb_pnp: Fix 8-bit accesses disas/libvixl/vixl/invalset.h | 2 +- docs/interop/pr-helper.rst | 2 +- docs/specs/ppc-spapr-hotplug.txt| 2 +- docs/specs/ppc-xive.rst | 2 +- docs/specs/tpm.txt | 2 +- hw/misc/grlib_ahb_apb_pnp.c | 12 include/hw/xen/interface/io/blkif.h | 2 +- scripts/dump-guest-memory.py| 2 +- 8 files changed, 19 insertions(+), 7 deletions(-) -- v2: remove patch from Greg that has lines with more than 80 columns 2.21.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-4.19 test] 143600: regressions - FAIL
flight 143600 linux-4.19 real [real] http://logs.test-lab.xenproject.org/osstest/logs/143600/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qcow2 19 guest-start/debian.repeat fail REGR. vs. 142932 test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail REGR. vs. 142932 test-amd64-i386-xl-raw 19 guest-start/debian.repeat fail REGR. vs. 142932 test-armhf-armhf-libvirt-raw 15 guest-start/debian.repeat fail REGR. vs. 142932 Tests which are failing intermittently (not blocking): test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail in 143505 pass in 143600 test-armhf-armhf-xl-rtds 15 guest-stop fail in 143505 pass in 143600 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install fail in 143505 pass in 143600 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail pass in 143505 Tests which did not succeed, but are not blocking: test-arm64-arm64-examine 11 examine-serial/bootloader fail in 143505 like 142880 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 142880 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 142932 test-armhf-armhf-xl-vhd 15 guest-start/debian.repeatfail like 142932 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never
Re: [Xen-devel] [PULL 0/4] Trivial branch patches
Le 05/11/2019 à 17:03, Dr. David Alan Gilbert a écrit : > * Laurent Vivier (laur...@vivier.eu) wrote: >> Greg, Dave, >> >> could you fix that? >> >> Thanks, >> Laurent >> >> Le 05/11/2019 à 16:48, no-re...@patchew.org a écrit : >>> Patchew URL: >>> https://patchew.org/QEMU/20191105144247.10301-1-laur...@vivier.eu/ >>> >>> >>> >>> Hi, >>> >>> This series seems to have some coding style problems. See output below for >>> more information: >>> >>> Subject: [PULL 0/4] Trivial branch patches >>> Type: series >>> Message-id: 20191105144247.10301-1-laur...@vivier.eu >>> >>> === TEST SCRIPT BEGIN === >>> #!/bin/bash >>> git rev-parse base > /dev/null || exit 0 >>> git config --local diff.renamelimit 0 >>> git config --local diff.renames True >>> git config --local diff.algorithm histogram >>> ./scripts/checkpatch.pl --mailback base.. >>> === TEST SCRIPT END === >>> >>> Switched to a new branch 'test' >>> 85ac453 global: Squash 'the the' >>> 9dd7da4 qom: Fix error message in object_class_property_add() >>> 2b76b45 hw/misc/grlib_ahb_apb_pnp: Fix 8-bit accesses >>> bddcfd9 hw/misc/grlib_ahb_apb_pnp: Avoid crash when writing to PnP registers >>> >>> === OUTPUT BEGIN === >>> 1/4 Checking commit bddcfd9b6b24 (hw/misc/grlib_ahb_apb_pnp: Avoid crash >>> when writing to PnP registers) >>> 2/4 Checking commit 2b76b451f9b7 (hw/misc/grlib_ahb_apb_pnp: Fix 8-bit >>> accesses) >>> 3/4 Checking commit 9dd7da421bfb (qom: Fix error message in >>> object_class_property_add()) >>> WARNING: line over 80 characters >>> #31: FILE: qom/object.c:1109: >>> +error_setg(errp, "attempt to add duplicate property '%s' to object >>> (type '%s')", >>> >>> WARNING: line over 80 characters >>> #43: FILE: qom/object.c:1141: >>> +error_setg(errp, "attempt to add duplicate property '%s' to class >>> (type '%s')", >>> >>> total: 0 errors, 2 warnings, 22 lines checked >>> >>> Patch 3/4 has style problems, please review. If any of these errors >>> are false positives report them to the maintainer, see >>> CHECKPATCH in MAINTAINERS. >>> 4/4 Checking commit 85ac453d1520 (global: Squash 'the the') >>> ERROR: do not use C99 // comments >>> #26: FILE: disas/libvixl/vixl/invalset.h:105: >>> + // Note that this does not mean the backing storage is empty: it can >>> still > > That one is a false positive; libvixl is written in C++ ! OK, thank you. Laurent ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v1 09/10] mm/memory_hotplug: Don't mark pages PG_reserved when initializing the memmap
On 11/5/19 5:18 AM, David Hildenbrand wrote:
> On 04.11.19 23:44, Boris Ostrovsky wrote:
>> On 10/24/19 8:09 AM, David Hildenbrand wrote:
>>> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
>>> index 4f2e78a5e4db..af69f057913a 100644
>>> --- a/drivers/xen/balloon.c
>>> +++ b/drivers/xen/balloon.c
>>> @@ -374,6 +374,13 @@ static void xen_online_page(struct page *page,
>>> unsigned int order)
>>> mutex_lock(_mutex);
>>> for (i = 0; i < size; i++) {
>>> p = pfn_to_page(start_pfn + i);
>>> + /*
>>> + * TODO: The core used to mark the pages reserved. Most
>>> probably
>>> + * we can stop doing that now. However, especially
>>> + * alloc_xenballooned_pages() left PG_reserved set
>>> + * on pages that can get mapped to user space.
>>> + */
>>> + __SetPageReserved(p);
>>
>> I suspect this is not needed. Pages can get into balloon either from
>> here or from non-hotplug path (e.g. decrease_reservation()) and so when
>> we get a page from the balloon we would get a random page that may or
>> may not have Reserved bit set.
>
> Yeah, I also think it is fine. If you agree, I'll drop this hunk and
> add details to the patch description.
>
>
Yes, let's do that. Thanks.
-boris
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PULL 0/4] Trivial branch patches
* Laurent Vivier (laur...@vivier.eu) wrote: > Greg, Dave, > > could you fix that? > > Thanks, > Laurent > > Le 05/11/2019 à 16:48, no-re...@patchew.org a écrit : > > Patchew URL: > > https://patchew.org/QEMU/20191105144247.10301-1-laur...@vivier.eu/ > > > > > > > > Hi, > > > > This series seems to have some coding style problems. See output below for > > more information: > > > > Subject: [PULL 0/4] Trivial branch patches > > Type: series > > Message-id: 20191105144247.10301-1-laur...@vivier.eu > > > > === TEST SCRIPT BEGIN === > > #!/bin/bash > > git rev-parse base > /dev/null || exit 0 > > git config --local diff.renamelimit 0 > > git config --local diff.renames True > > git config --local diff.algorithm histogram > > ./scripts/checkpatch.pl --mailback base.. > > === TEST SCRIPT END === > > > > Switched to a new branch 'test' > > 85ac453 global: Squash 'the the' > > 9dd7da4 qom: Fix error message in object_class_property_add() > > 2b76b45 hw/misc/grlib_ahb_apb_pnp: Fix 8-bit accesses > > bddcfd9 hw/misc/grlib_ahb_apb_pnp: Avoid crash when writing to PnP registers > > > > === OUTPUT BEGIN === > > 1/4 Checking commit bddcfd9b6b24 (hw/misc/grlib_ahb_apb_pnp: Avoid crash > > when writing to PnP registers) > > 2/4 Checking commit 2b76b451f9b7 (hw/misc/grlib_ahb_apb_pnp: Fix 8-bit > > accesses) > > 3/4 Checking commit 9dd7da421bfb (qom: Fix error message in > > object_class_property_add()) > > WARNING: line over 80 characters > > #31: FILE: qom/object.c:1109: > > +error_setg(errp, "attempt to add duplicate property '%s' to object > > (type '%s')", > > > > WARNING: line over 80 characters > > #43: FILE: qom/object.c:1141: > > +error_setg(errp, "attempt to add duplicate property '%s' to class > > (type '%s')", > > > > total: 0 errors, 2 warnings, 22 lines checked > > > > Patch 3/4 has style problems, please review. If any of these errors > > are false positives report them to the maintainer, see > > CHECKPATCH in MAINTAINERS. > > 4/4 Checking commit 85ac453d1520 (global: Squash 'the the') > > ERROR: do not use C99 // comments > > #26: FILE: disas/libvixl/vixl/invalset.h:105: > > + // Note that this does not mean the backing storage is empty: it can > > still That one is a false positive; libvixl is written in C++ ! Dave > > total: 1 errors, 0 warnings, 56 lines checked > > > > Patch 4/4 has style problems, please review. If any of these errors > > are false positives report them to the maintainer, see > > CHECKPATCH in MAINTAINERS. > > > > === OUTPUT END === > > > > Test command exited with code: 1 > > > > > > The full log is available at > > http://patchew.org/logs/20191105144247.10301-1-laur...@vivier.eu/testing.checkpatch/?type=message. > > --- > > Email generated automatically by Patchew [https://patchew.org/]. > > Please send your feedback to patchew-de...@redhat.com > > > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [BUG] Invalid guest state in Xen master, dom0 linux-5.3.6, domU windows 10
Den 05.11.2019 02:15, skrev Andrew Cooper: On 05/11/2019 00:25, Andrew Cooper wrote: On 04/11/2019 23:42, Andrew Cooper wrote: On 04/11/2019 23:20, Håkon Alstadheim wrote: (XEN) RFLAGS=0x0193 (0x0193) DR7 = 0x0400 (XEN) *** Insn bytes from b8868f61d69a: 44 00 00 8c d0 9c 81 0c 24 00 01 00 00 9d 8e d0 9c 81 24 24 ff fe ff ff 9d c3 cc cc cc cc cc Ok. One question answered, several more WTF. <.data>: 0: 44 00 00 add %r8b,(%rax) 3: 8c d0 mov %ss,%eax 5: 9c pushfq 6: 81 0c 24 00 01 00 00 orl $0x100,(%rsp) d: 9d popfq e: 8e d0 mov %eax,%ss 10: f1 icebp 11: 9c pushfq 12: 81 24 24 ff fe ff ff andl $0xfeff,(%rsp) 19: 9d popfq 1a: c3 retq 1b: cc int3 1c: cc int3 1d: cc int3 1e: cc int3 1f: cc int3 This is a serious exercising of architectural corner cases, by layering a single step exception on top of a MovSS-deferred ICEBP. Now I've looked closer, this isn't a CVE-2018-8897 exploit as no breakpoints are configured in %dr7, so I'm going to revise my guess some new debugger-detection in DRM software. I've reproduced the VMEntry failure you were seeing. Now to figure out if there is sufficient control available to provide architectural behaviour to guest, because I'm not entirely certain there is, given some of ICEBP's extra magic properties. So, this is just another case of an issue I've already tried fixing once and haven't had time to fix in a way which doesn't break other pieces of functionality. I clearly need to dust off that series and get it working properly. In the short term, this will work around your problem. diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h index f86af09898..10daaa6f33 100644 --- a/xen/include/asm-x86/hvm/hvm.h +++ b/xen/include/asm-x86/hvm/hvm.h @@ -522,8 +522,7 @@ static inline void hvm_invlpg(struct vcpu *v, unsigned long linear) (X86_CR4_VMXE | X86_CR4_PAE | X86_CR4_MCE)) /* These exceptions must always be intercepted. */ -#define HVM_TRAP_MASK ((1U << TRAP_debug) | \ - (1U << TRAP_alignment_check) | \ +#define HVM_TRAP_MASK ((1U << TRAP_alignment_check) | \ (1U << TRAP_machine_check)) static inline int hvm_cpu_up(void) However, be aware that it will reintroduce http://xenbits.xen.org/xsa/advisory-156.html so isn't recommended for general use. Thank you kindly. Ever the optimist, I'll apply the patch. Seeing as this looks to be some DRM software, it isn't likely to mount an attack like that, as it would livelock a native system just as badly as it livelocks a virtualised system. I'm slightly relieved the malware running on my system is courtesy of big media rather than some Romanian consultant for the RNC. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v1 03/10] KVM: Prepare kvm_is_reserved_pfn() for PG_reserved changes
On Tue, Nov 05, 2019 at 11:02:46AM +0100, David Hildenbrand wrote:
> On 05.11.19 10:49, David Hildenbrand wrote:
> >On 05.11.19 10:17, David Hildenbrand wrote:
> >>On 05.11.19 05:38, Dan Williams wrote:
> >>>On Thu, Oct 24, 2019 at 5:11 AM David Hildenbrand wrote:
>
> Right now, ZONE_DEVICE memory is always set PG_reserved. We want to
> change that.
>
> KVM has this weird use case that you can map anything from /dev/mem
> into the guest. pfn_valid() is not a reliable check whether the memmap
> was initialized and can be touched. pfn_to_online_page() makes sure
> that we have an initialized memmap (and don't have ZONE_DEVICE memory).
>
> Rewrite kvm_is_reserved_pfn() to make sure the function produces the
> same result once we stop setting ZONE_DEVICE pages PG_reserved.
>
> Cc: Paolo Bonzini
> Cc: "Radim Krčmář"
> Cc: Michal Hocko
> Cc: Dan Williams
> Cc: KarimAllah Ahmed
> Signed-off-by: David Hildenbrand
> ---
> virt/kvm/kvm_main.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index e9eb666eb6e8..9d18cc67d124 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -151,9 +151,15 @@ __weak int
> kvm_arch_mmu_notifier_invalidate_range(struct kvm *kvm,
>
> bool kvm_is_reserved_pfn(kvm_pfn_t pfn)
> {
> - if (pfn_valid(pfn))
> - return PageReserved(pfn_to_page(pfn));
> + struct page *page = pfn_to_online_page(pfn);
>
> + /*
> +* We treat any pages that are not online (not managed by the
> buddy)
> +* as reserved - this includes ZONE_DEVICE pages and pages without
> +* a memmap (e.g., mapped via /dev/mem).
> +*/
> + if (page)
> + return PageReserved(page);
> return true;
> }
> >>>
> >>>So after this all the pfn_valid() usage in kvm_main.c is replaced with
> >>>pfn_to_online_page()? Looks correct to me.
> >>>
> >>>However, I'm worried that kvm is taking reference on ZONE_DEVICE pages
> >>>through some other path resulting in this:
> >>>
> >>>
> >>> https://lore.kernel.org/linux-nvdimm/20190919154708.ga24...@angband.pl/
> >>>
> >>>I'll see if this patch set modulates or maintains that failure mode.
> >>>
> >>
> >>I'd assume that the behavior is unchanged. Ithink we get a reference to
> >>these ZONE_DEVICE pages via __get_user_pages_fast() and friends in
> >>hva_to_pfn_fast() and friends in virt/kvm/kvm_main.c
> >>
> >
> >I think I know what's going wrong:
> >
> >Pages that are pinned via gfn_to_pfn() and friends take a references,
> >however are often released via
> >kvm_release_pfn_clean()/kvm_release_pfn_dirty()/kvm_release_page_clean()...
> >
> >
> >E.g., in arch/x86/kvm/x86.c:reexecute_instruction()
> >
> >...
> >pfn = gfn_to_pfn(vcpu->kvm, gpa_to_gfn(gpa));
> >...
> >kvm_release_pfn_clean(pfn);
> >
> >
> >
> >void kvm_release_pfn_clean(kvm_pfn_t pfn)
> >{
> > if (!is_error_noslot_pfn(pfn) && !kvm_is_reserved_pfn(pfn))
> > put_page(pfn_to_page(pfn));
> >}
> >
> >This function makes perfect sense as the counterpart for kvm_get_pfn():
> >
> >void kvm_get_pfn(kvm_pfn_t pfn)
> >{
> > if (!kvm_is_reserved_pfn(pfn))
> > get_page(pfn_to_page(pfn));
> >}
> >
> >
> >As all ZONE_DEVICE pages are currently reserved, pages pinned via
> >gfn_to_pfn() and friends will often not see a put_page() AFAIKS.
Assuming gup() takes a reference for ZONE_DEVICE pages, yes, this is a
KVM bug.
> >Now, my patch does not change that, the result of
> >kvm_is_reserved_pfn(pfn) will be unchanged. A proper fix for that would
> >probably be
> >
> >a) To drop the reference to ZONE_DEVICE pages in gfn_to_pfn() and
> >friends, after you successfully pinned the pages. (not sure if that's
> >the right thing to do but you're the expert)
> >
> >b) To not use kvm_release_pfn_clean() and friends on pages that were
> >definitely pinned.
This is already KVM's intent, i.e. the purpose of the PageReserved() check
is simply to avoid putting a non-existent reference. The problem is that
KVM assumes pages with PG_reserved set are never pinned, which AFAICT was
true when the code was first added.
> (talking to myself, sorry)
>
> Thinking again, dropping this patch from this series could effectively also
> fix that issue. E.g., kvm_release_pfn_clean() and friends would always do a
> put_page() if "pfn_valid() and !PageReserved()", so after patch 9 also on
> ZONDE_DEVICE pages.
Yeah, this appears to be the correct fix.
> But it would have side effects that might not be desired. E.g.,:
>
> 1. kvm_pfn_to_page() would also return ZONE_DEVICE pages (might even be the
> right thing to do).
This should be ok, at least on x86. There are only three users of
kvm_pfn_to_page(). Two of those are on allocations that are
Re: [Xen-devel] [PULL 0/4] Trivial branch patches
Greg, Dave, could you fix that? Thanks, Laurent Le 05/11/2019 à 16:48, no-re...@patchew.org a écrit : > Patchew URL: > https://patchew.org/QEMU/20191105144247.10301-1-laur...@vivier.eu/ > > > > Hi, > > This series seems to have some coding style problems. See output below for > more information: > > Subject: [PULL 0/4] Trivial branch patches > Type: series > Message-id: 20191105144247.10301-1-laur...@vivier.eu > > === TEST SCRIPT BEGIN === > #!/bin/bash > git rev-parse base > /dev/null || exit 0 > git config --local diff.renamelimit 0 > git config --local diff.renames True > git config --local diff.algorithm histogram > ./scripts/checkpatch.pl --mailback base.. > === TEST SCRIPT END === > > Switched to a new branch 'test' > 85ac453 global: Squash 'the the' > 9dd7da4 qom: Fix error message in object_class_property_add() > 2b76b45 hw/misc/grlib_ahb_apb_pnp: Fix 8-bit accesses > bddcfd9 hw/misc/grlib_ahb_apb_pnp: Avoid crash when writing to PnP registers > > === OUTPUT BEGIN === > 1/4 Checking commit bddcfd9b6b24 (hw/misc/grlib_ahb_apb_pnp: Avoid crash when > writing to PnP registers) > 2/4 Checking commit 2b76b451f9b7 (hw/misc/grlib_ahb_apb_pnp: Fix 8-bit > accesses) > 3/4 Checking commit 9dd7da421bfb (qom: Fix error message in > object_class_property_add()) > WARNING: line over 80 characters > #31: FILE: qom/object.c:1109: > +error_setg(errp, "attempt to add duplicate property '%s' to object > (type '%s')", > > WARNING: line over 80 characters > #43: FILE: qom/object.c:1141: > +error_setg(errp, "attempt to add duplicate property '%s' to class > (type '%s')", > > total: 0 errors, 2 warnings, 22 lines checked > > Patch 3/4 has style problems, please review. If any of these errors > are false positives report them to the maintainer, see > CHECKPATCH in MAINTAINERS. > 4/4 Checking commit 85ac453d1520 (global: Squash 'the the') > ERROR: do not use C99 // comments > #26: FILE: disas/libvixl/vixl/invalset.h:105: > + // Note that this does not mean the backing storage is empty: it can still > > total: 1 errors, 0 warnings, 56 lines checked > > Patch 4/4 has style problems, please review. If any of these errors > are false positives report them to the maintainer, see > CHECKPATCH in MAINTAINERS. > > === OUTPUT END === > > Test command exited with code: 1 > > > The full log is available at > http://patchew.org/logs/20191105144247.10301-1-laur...@vivier.eu/testing.checkpatch/?type=message. > --- > Email generated automatically by Patchew [https://patchew.org/]. > Please send your feedback to patchew-de...@redhat.com > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PULL 0/4] Trivial branch patches
Patchew URL: https://patchew.org/QEMU/20191105144247.10301-1-laur...@vivier.eu/ Hi, This series seems to have some coding style problems. See output below for more information: Subject: [PULL 0/4] Trivial branch patches Type: series Message-id: 20191105144247.10301-1-laur...@vivier.eu === TEST SCRIPT BEGIN === #!/bin/bash git rev-parse base > /dev/null || exit 0 git config --local diff.renamelimit 0 git config --local diff.renames True git config --local diff.algorithm histogram ./scripts/checkpatch.pl --mailback base.. === TEST SCRIPT END === Switched to a new branch 'test' 85ac453 global: Squash 'the the' 9dd7da4 qom: Fix error message in object_class_property_add() 2b76b45 hw/misc/grlib_ahb_apb_pnp: Fix 8-bit accesses bddcfd9 hw/misc/grlib_ahb_apb_pnp: Avoid crash when writing to PnP registers === OUTPUT BEGIN === 1/4 Checking commit bddcfd9b6b24 (hw/misc/grlib_ahb_apb_pnp: Avoid crash when writing to PnP registers) 2/4 Checking commit 2b76b451f9b7 (hw/misc/grlib_ahb_apb_pnp: Fix 8-bit accesses) 3/4 Checking commit 9dd7da421bfb (qom: Fix error message in object_class_property_add()) WARNING: line over 80 characters #31: FILE: qom/object.c:1109: +error_setg(errp, "attempt to add duplicate property '%s' to object (type '%s')", WARNING: line over 80 characters #43: FILE: qom/object.c:1141: +error_setg(errp, "attempt to add duplicate property '%s' to class (type '%s')", total: 0 errors, 2 warnings, 22 lines checked Patch 3/4 has style problems, please review. If any of these errors are false positives report them to the maintainer, see CHECKPATCH in MAINTAINERS. 4/4 Checking commit 85ac453d1520 (global: Squash 'the the') ERROR: do not use C99 // comments #26: FILE: disas/libvixl/vixl/invalset.h:105: + // Note that this does not mean the backing storage is empty: it can still total: 1 errors, 0 warnings, 56 lines checked Patch 4/4 has style problems, please review. If any of these errors are false positives report them to the maintainer, see CHECKPATCH in MAINTAINERS. === OUTPUT END === Test command exited with code: 1 The full log is available at http://patchew.org/logs/20191105144247.10301-1-laur...@vivier.eu/testing.checkpatch/?type=message. --- Email generated automatically by Patchew [https://patchew.org/]. Please send your feedback to patchew-de...@redhat.com ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH V1 2/2] x86/mm: Make use of the default access param from xc_altp2m_create_view
On 05.11.2019 17:38, George Dunlap wrote: > On 11/5/19 12:43 PM, Alexandru Stefan ISAILA wrote: >> At this moment the default_access param from xc_altp2m_create_view is >> not used. > > Weird! Indeed, it was bugging me every time I passed throughout that code. Alex > >> >> This patch assigns default_access to p2m->default_access at the time of >> initializing a new altp2m view. >> >> Signed-off-by: Alexandru Isaila > > Acked-by: George Dunlap > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH V1 1/2] x86/altp2m: Add hypercall to set a range of sve bits
>>
>> +/*
>> + * Set/clear the #VE suppress bit for multiple pages. Only available on
>> VMX.
>> + */
>> +long p2m_set_suppress_ve_multi(struct domain *d, uint32_t start, uint32_t
>> nr,
>> + bool suppress_ve, unsigned int altp2m_idx)
>> +{
>> +struct p2m_domain *host_p2m = p2m_get_hostp2m(d);
>> +struct p2m_domain *ap2m = NULL;
>> +struct p2m_domain *p2m;
>> +long rc = 0;
>> +
>> +if ( altp2m_idx > 0 )
>> +{
>> +if ( altp2m_idx >= MAX_ALTP2M ||
>> + d->arch.altp2m_eptp[altp2m_idx] == mfn_x(INVALID_MFN) )
>> +return -EINVAL;
>> +
>> +p2m = ap2m = d->arch.altp2m_p2m[altp2m_idx];
>> +}
>> +else
>> +p2m = host_p2m;
>> +
>> +p2m_lock(host_p2m);
>> +
>> +if ( ap2m )
>> +p2m_lock(ap2m);
>> +
>> +
>> +while ( start < nr )
>> +{
>> +p2m_access_t a;
>> +p2m_type_t t;
>> +mfn_t mfn;
>> +
>> +rc = altp2m_get_effective_entry(p2m, _gfn(start), , , ,
>> AP2MGET_query);
>> +
>> +if ( rc )
>> +a = p2m->default_access;
>> +
>> +rc = p2m->set_entry(p2m, _gfn(start), mfn, PAGE_ORDER_4K, t, a,
>> suppress_ve);
>> +
>> +/* Try best effort for setting the whole range. */
>> +if ( rc )
>> +continue;
>> +
>> +/* Check for continuation if it's not the last iteration. */
>> +if ( nr > ++start && hypercall_preempt_check() )
>> +{
>> +rc = start;
>> +break;
>> +}
>
> What's the point of the "if ( rc ) continue;"? All it's doing is
> preventing the loop from being preempted at that point; but there
> doesn't seem to be a good reason for that. In fact, if an attacker
> could engineer a situation where large swaths could fail, it could use
> this to lock up the cpu for an unreasonable amount of time.
Yes, that could be an issue. It will go in v2
>
> Everything else looks OK to me.
>
If the changes requested by Tamas are also ok with you then I will have
them all go in v2.
Alex
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH V1 2/2] x86/mm: Make use of the default access param from xc_altp2m_create_view
On 11/5/19 12:43 PM, Alexandru Stefan ISAILA wrote: > At this moment the default_access param from xc_altp2m_create_view is > not used. Weird! > > This patch assigns default_access to p2m->default_access at the time of > initializing a new altp2m view. > > Signed-off-by: Alexandru Isaila Acked-by: George Dunlap ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] create-diff-object: more precisely identify .rodata sections
This is needed for more precise patchability verification.
Only non-special .rodata sections should be subject
for such a non-referenced check in kpatch_verify_patchability().
Current check (non-standard, non-rela, non-debug) is too weak and
allows also non-rodata sections without referenced symbols to slip
through.
Detect .rodata section by checking section's type (SHT_PROGBITS),
flags (no exec, no write) and finally name prefix.
Signed-off-by: Pawel Wieczorkiewicz
Reviewed-by: Andra-Irina Paraschiv
Reviewed-by: Bjoern Doebel
Reviewed-by: Norbert Manthey
---
common.c | 7 +++
common.h | 1 +
create-diff-object.c | 13 ++---
3 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/common.c b/common.c
index 0ddc9fa..8f553ea 100644
--- a/common.c
+++ b/common.c
@@ -249,6 +249,13 @@ int is_text_section(struct section *sec)
(sec->sh.sh_flags & SHF_EXECINSTR));
}
+int is_rodata_section(struct section *sec)
+{
+ return sec->sh.sh_type == SHT_PROGBITS &&
+ !(sec->sh.sh_flags & (SHF_EXECINSTR | SHF_WRITE)) &&
+ !strncmp(sec->name, ".rodata", 7);
+}
+
int is_debug_section(struct section *sec)
{
char *name;
diff --git a/common.h b/common.h
index 7c6fb73..b6489db 100644
--- a/common.h
+++ b/common.h
@@ -159,6 +159,7 @@ struct symbol *find_symbol_by_index(struct list_head *list,
size_t index);
struct symbol *find_symbol_by_name(struct list_head *list, const char *name);
int is_text_section(struct section *sec);
+int is_rodata_section(struct section *sec);
int is_debug_section(struct section *sec);
int is_rela_section(struct section *sec);
int is_standard_section(struct section *sec);
diff --git a/create-diff-object.c b/create-diff-object.c
index e4592a6..2f0e162 100644
--- a/create-diff-object.c
+++ b/create-diff-object.c
@@ -1672,13 +1672,12 @@ static void kpatch_verify_patchability(struct
kpatch_elf *kelf)
}
if (sec->include) {
- if (!is_standard_section(sec) && !is_rela_section(sec)
&&
- !is_debug_section(sec) && !is_special_section(sec))
{
- if (!is_referenced_section(sec, kelf)) {
- log_normal("section %s included, but
not referenced\n",
- sec->name);
- errs++;
- }
+ if (is_rodata_section(sec) &&
+ !is_special_section(sec) &&
+ !is_referenced_section(sec, kelf)) {
+ log_normal(".rodata section %s included, but
not referenced\n",
+ sec->name);
+ errs++;
}
/* Check if a RELA section does not contain any entries
with
--
2.16.5
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] create-diff-object: do not strip STN_UNDEF symbols from *.fixup
The rela groups in the *.fixup sections vary in size. That makes it more complex to handle in the livepatch_strip_undefined_elements(). It is also unnecessary as the .fixup sections are unlikely to have any STN_UNDEF symbols anyway. Signed-off-by: Pawel Wieczorkiewicz --- create-diff-object.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/create-diff-object.c b/create-diff-object.c index 2f0e162..abf3cc7 100644 --- a/create-diff-object.c +++ b/create-diff-object.c @@ -2081,6 +2081,13 @@ static void livepatch_strip_undefined_elements(struct kpatch_elf *kelf) if (!is_rela_section(sec)) continue; + /* The rela groups in the .fixup sections vary in size. +* Ignore them as they are unlikely to have any STN_UNDEF +* symbols anyway. +*/ + if (strstr(sec->name, ".fixup")) + continue; + /* only known, fixed-size entries can be stripped */ entry_size = get_section_entry_size(sec->base, kelf); if (entry_size == 0) -- 2.16.5 Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B Sitz: Berlin Ust-ID: DE 289 237 879 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH V1 1/2] x86/altp2m: Add hypercall to set a range of sve bits
On 11/5/19 12:43 PM, Alexandru Stefan ISAILA wrote:
> By default the sve bits are not set.
> This patch adds a new hypercall, xc_altp2m_set_supress_ve_multi(),
> to set a range of sve bits.
> The core function, p2m_set_suppress_ve_multi(), does not brake in case
> of a error and it is doing a best effort for setting the bits in the
> given range. A check for continuation is made in order to have
> preemption on big ranges.
>
> Signed-off-by: Alexandru Isaila
> ---
> tools/libxc/include/xenctrl.h | 3 ++
> tools/libxc/xc_altp2m.c | 25 ++
> xen/arch/x86/hvm/hvm.c | 28 +--
> xen/arch/x86/mm/p2m.c | 61 +
> xen/include/public/hvm/hvm_op.h | 4 ++-
> xen/include/xen/mem_access.h| 3 ++
> 6 files changed, 121 insertions(+), 3 deletions(-)
>
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index f4431687b3..21b644f459 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -1923,6 +1923,9 @@ int xc_altp2m_switch_to_view(xc_interface *handle,
> uint32_t domid,
> uint16_t view_id);
> int xc_altp2m_set_suppress_ve(xc_interface *handle, uint32_t domid,
>uint16_t view_id, xen_pfn_t gfn, bool sve);
> +int xc_altp2m_set_supress_ve_multi(xc_interface *handle, uint32_t domid,
> + uint16_t view_id, xen_pfn_t start_gfn,
> + uint32_t nr, bool sve);
> int xc_altp2m_get_suppress_ve(xc_interface *handle, uint32_t domid,
>uint16_t view_id, xen_pfn_t gfn, bool *sve);
> int xc_altp2m_set_mem_access(xc_interface *handle, uint32_t domid,
> diff --git a/tools/libxc/xc_altp2m.c b/tools/libxc/xc_altp2m.c
> index 09dad0355e..6605d9abbe 100644
> --- a/tools/libxc/xc_altp2m.c
> +++ b/tools/libxc/xc_altp2m.c
> @@ -234,6 +234,31 @@ int xc_altp2m_set_suppress_ve(xc_interface *handle,
> uint32_t domid,
> return rc;
> }
>
> +int xc_altp2m_set_supress_ve_multi(xc_interface *handle, uint32_t domid,
> + uint16_t view_id, xen_pfn_t start_gfn,
> + uint32_t nr, bool sve)
> +{
> +int rc;
> +DECLARE_HYPERCALL_BUFFER(xen_hvm_altp2m_op_t, arg);
> +
> +arg = xc_hypercall_buffer_alloc(handle, arg, sizeof(*arg));
> +if ( arg == NULL )
> +return -1;
> +
> +arg->version = HVMOP_ALTP2M_INTERFACE_VERSION;
> +arg->cmd = HVMOP_altp2m_set_suppress_ve_multi;
> +arg->domain = domid;
> +arg->u.suppress_ve.view = view_id;
> +arg->u.suppress_ve.gfn = start_gfn;
> +arg->u.suppress_ve.suppress_ve = sve;
> +arg->u.suppress_ve.nr = nr;
> +
> +rc = xencall2(handle->xcall, __HYPERVISOR_hvm_op, HVMOP_altp2m,
> + HYPERCALL_BUFFER_AS_ARG(arg));
> +xc_hypercall_buffer_free(handle, arg);
> +return rc;
> +}
> +
> int xc_altp2m_set_mem_access(xc_interface *handle, uint32_t domid,
> uint16_t view_id, xen_pfn_t gfn,
> xenmem_access_t access)
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 06a7b40107..d3d9f8c30f 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -4535,6 +4535,7 @@ static int do_altp2m_op(
> case HVMOP_altp2m_destroy_p2m:
> case HVMOP_altp2m_switch_p2m:
> case HVMOP_altp2m_set_suppress_ve:
> +case HVMOP_altp2m_set_suppress_ve_multi:
> case HVMOP_altp2m_get_suppress_ve:
> case HVMOP_altp2m_set_mem_access:
> case HVMOP_altp2m_set_mem_access_multi:
> @@ -4681,7 +4682,7 @@ static int do_altp2m_op(
> break;
>
> case HVMOP_altp2m_set_suppress_ve:
> -if ( a.u.suppress_ve.pad1 || a.u.suppress_ve.pad2 )
> +if ( a.u.suppress_ve.pad1 )
> rc = -EINVAL;
> else
> {
> @@ -4693,8 +4694,31 @@ static int do_altp2m_op(
> }
> break;
>
> +case HVMOP_altp2m_set_suppress_ve_multi:
> +if ( a.u.suppress_ve.pad1 || !a.u.suppress_ve.nr )
> +rc = -EINVAL;
> +else
> +{
> +rc = p2m_set_suppress_ve_multi(d, a.u.suppress_ve.gfn,
> + a.u.suppress_ve.nr,
> + a.u.suppress_ve.suppress_ve,
> + a.u.suppress_ve.view);
> +
> +if ( rc > 0 )
> +{
> +a.u.suppress_ve.gfn = rc;
> +rc = -ERESTART;
> +
> +if ( __copy_field_to_guest(guest_handle_cast(arg,
> + xen_hvm_altp2m_op_t),
> + , u.suppress_ve.gfn) )
> +rc = -EFAULT;
> +}
> +}
> +break;
> +
> case HVMOP_altp2m_get_suppress_ve:
> -if ( a.u.suppress_ve.pad1 ||
Re: [Xen-devel] [XEN PATCH v2] MAINTAINERS: ARINC 653 scheduler maintainer updates
On Tuesday, November 5, 2019 10:09 AM, Wei Liu wrote: >On Tue, Nov 05, 2019 at 08:51:52AM -0500, Stewart Hildebrand wrote: >> Add DornerWorks internal list. This will forward to relevant people >> within DornerWorks. >> >> Add myself to MAINTAINERS for ARINC653 scheduler. >> >> Remove Robbie from MAINTAINERS for ARINC653 scheduler. >> > >Missing SoB here. > >No need to resend. The following can be added while committing: > > Signed-off-by: Stewart Hildebrand > >Let me know what you think. Yes, sorry about that. Please go ahead and add it. Signed-off-by: Stewart Hildebrand ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH V1 1/2] x86/altp2m: Add hypercall to set a range of sve bits
On 05.11.2019 17:18, Tamas K Lengyel wrote:
> On Tue, Nov 5, 2019 at 5:43 AM Alexandru Stefan ISAILA
> wrote:
>>
>> By default the sve bits are not set.
>> This patch adds a new hypercall, xc_altp2m_set_supress_ve_multi(),
>> to set a range of sve bits.
>> The core function, p2m_set_suppress_ve_multi(), does not brake in case
>> of a error and it is doing a best effort for setting the bits in the
>> given range. A check for continuation is made in order to have
>> preemption on big ranges.
>>
>> Signed-off-by: Alexandru Isaila
>> ---
>> tools/libxc/include/xenctrl.h | 3 ++
>> tools/libxc/xc_altp2m.c | 25 ++
>> xen/arch/x86/hvm/hvm.c | 28 +--
>> xen/arch/x86/mm/p2m.c | 61 +
>> xen/include/public/hvm/hvm_op.h | 4 ++-
>> xen/include/xen/mem_access.h| 3 ++
>> 6 files changed, 121 insertions(+), 3 deletions(-)
>>
>> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
>> index f4431687b3..21b644f459 100644
>> --- a/tools/libxc/include/xenctrl.h
>> +++ b/tools/libxc/include/xenctrl.h
>> @@ -1923,6 +1923,9 @@ int xc_altp2m_switch_to_view(xc_interface *handle,
>> uint32_t domid,
>>uint16_t view_id);
>> int xc_altp2m_set_suppress_ve(xc_interface *handle, uint32_t domid,
>> uint16_t view_id, xen_pfn_t gfn, bool sve);
>> +int xc_altp2m_set_supress_ve_multi(xc_interface *handle, uint32_t domid,
>> + uint16_t view_id, xen_pfn_t start_gfn,
>> + uint32_t nr, bool sve);
>> int xc_altp2m_get_suppress_ve(xc_interface *handle, uint32_t domid,
>> uint16_t view_id, xen_pfn_t gfn, bool *sve);
>> int xc_altp2m_set_mem_access(xc_interface *handle, uint32_t domid,
>> diff --git a/tools/libxc/xc_altp2m.c b/tools/libxc/xc_altp2m.c
>> index 09dad0355e..6605d9abbe 100644
>> --- a/tools/libxc/xc_altp2m.c
>> +++ b/tools/libxc/xc_altp2m.c
>> @@ -234,6 +234,31 @@ int xc_altp2m_set_suppress_ve(xc_interface *handle,
>> uint32_t domid,
>> return rc;
>> }
>>
>> +int xc_altp2m_set_supress_ve_multi(xc_interface *handle, uint32_t domid,
>> + uint16_t view_id, xen_pfn_t start_gfn,
>> + uint32_t nr, bool sve)
>> +{
>> +int rc;
>> +DECLARE_HYPERCALL_BUFFER(xen_hvm_altp2m_op_t, arg);
>> +
>> +arg = xc_hypercall_buffer_alloc(handle, arg, sizeof(*arg));
>> +if ( arg == NULL )
>> +return -1;
>> +
>> +arg->version = HVMOP_ALTP2M_INTERFACE_VERSION;
>> +arg->cmd = HVMOP_altp2m_set_suppress_ve_multi;
>> +arg->domain = domid;
>> +arg->u.suppress_ve.view = view_id;
>> +arg->u.suppress_ve.gfn = start_gfn;
>> +arg->u.suppress_ve.suppress_ve = sve;
>> +arg->u.suppress_ve.nr = nr;
>> +
>> +rc = xencall2(handle->xcall, __HYPERVISOR_hvm_op, HVMOP_altp2m,
>> + HYPERCALL_BUFFER_AS_ARG(arg));
>> +xc_hypercall_buffer_free(handle, arg);
>> +return rc;
>> +}
>> +
>> int xc_altp2m_set_mem_access(xc_interface *handle, uint32_t domid,
>>uint16_t view_id, xen_pfn_t gfn,
>>xenmem_access_t access)
>> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
>> index 06a7b40107..d3d9f8c30f 100644
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -4535,6 +4535,7 @@ static int do_altp2m_op(
>> case HVMOP_altp2m_destroy_p2m:
>> case HVMOP_altp2m_switch_p2m:
>> case HVMOP_altp2m_set_suppress_ve:
>> +case HVMOP_altp2m_set_suppress_ve_multi:
>> case HVMOP_altp2m_get_suppress_ve:
>> case HVMOP_altp2m_set_mem_access:
>> case HVMOP_altp2m_set_mem_access_multi:
>> @@ -4681,7 +4682,7 @@ static int do_altp2m_op(
>> break;
>>
>> case HVMOP_altp2m_set_suppress_ve:
>> -if ( a.u.suppress_ve.pad1 || a.u.suppress_ve.pad2 )
>> +if ( a.u.suppress_ve.pad1 )
>> rc = -EINVAL;
>> else
>> {
>> @@ -4693,8 +4694,31 @@ static int do_altp2m_op(
>> }
>> break;
>>
>> +case HVMOP_altp2m_set_suppress_ve_multi:
>> +if ( a.u.suppress_ve.pad1 || !a.u.suppress_ve.nr )
>> +rc = -EINVAL;
>> +else
>> +{
>> +rc = p2m_set_suppress_ve_multi(d, a.u.suppress_ve.gfn,
>> + a.u.suppress_ve.nr,
>> + a.u.suppress_ve.suppress_ve,
>> + a.u.suppress_ve.view);
>
> I have to say I'm not a fan of stuffing the current gfn progress into
> rc, perhaps a separate pointer being passed in for storing that and
> returning -ERESTART would be cleaner.
This sounds cleaner, I will have it changed in v2.
>
>> +if ( rc > 0 )
>> +{
>> +a.u.suppress_ve.gfn = rc;
>
[Xen-devel] [ovmf test] 143689: all pass - PUSHED
flight 143689 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/143689/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 8d3f428109623096cb8845779cdf9dc44949b8e9 baseline version: ovmf e2fc50812895b17e8b23f5a9c43cde29531b200f Last test of basis 143580 2019-11-02 11:45:14 Z3 days Testing same since 143689 2019-11-04 06:37:00 Z1 days1 attempts People who touched revisions under test: Huang, Qing Marvin Haeuser Pierre Gondois Qing Huang Shenglei Zhang jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git e2fc508128..8d3f428109 8d3f428109623096cb8845779cdf9dc44949b8e9 -> xen-tested-master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH V1 1/2] x86/altp2m: Add hypercall to set a range of sve bits
On Tue, Nov 5, 2019 at 5:43 AM Alexandru Stefan ISAILA
wrote:
>
> By default the sve bits are not set.
> This patch adds a new hypercall, xc_altp2m_set_supress_ve_multi(),
> to set a range of sve bits.
> The core function, p2m_set_suppress_ve_multi(), does not brake in case
> of a error and it is doing a best effort for setting the bits in the
> given range. A check for continuation is made in order to have
> preemption on big ranges.
>
> Signed-off-by: Alexandru Isaila
> ---
> tools/libxc/include/xenctrl.h | 3 ++
> tools/libxc/xc_altp2m.c | 25 ++
> xen/arch/x86/hvm/hvm.c | 28 +--
> xen/arch/x86/mm/p2m.c | 61 +
> xen/include/public/hvm/hvm_op.h | 4 ++-
> xen/include/xen/mem_access.h| 3 ++
> 6 files changed, 121 insertions(+), 3 deletions(-)
>
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index f4431687b3..21b644f459 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -1923,6 +1923,9 @@ int xc_altp2m_switch_to_view(xc_interface *handle,
> uint32_t domid,
> uint16_t view_id);
> int xc_altp2m_set_suppress_ve(xc_interface *handle, uint32_t domid,
>uint16_t view_id, xen_pfn_t gfn, bool sve);
> +int xc_altp2m_set_supress_ve_multi(xc_interface *handle, uint32_t domid,
> + uint16_t view_id, xen_pfn_t start_gfn,
> + uint32_t nr, bool sve);
> int xc_altp2m_get_suppress_ve(xc_interface *handle, uint32_t domid,
>uint16_t view_id, xen_pfn_t gfn, bool *sve);
> int xc_altp2m_set_mem_access(xc_interface *handle, uint32_t domid,
> diff --git a/tools/libxc/xc_altp2m.c b/tools/libxc/xc_altp2m.c
> index 09dad0355e..6605d9abbe 100644
> --- a/tools/libxc/xc_altp2m.c
> +++ b/tools/libxc/xc_altp2m.c
> @@ -234,6 +234,31 @@ int xc_altp2m_set_suppress_ve(xc_interface *handle,
> uint32_t domid,
> return rc;
> }
>
> +int xc_altp2m_set_supress_ve_multi(xc_interface *handle, uint32_t domid,
> + uint16_t view_id, xen_pfn_t start_gfn,
> + uint32_t nr, bool sve)
> +{
> +int rc;
> +DECLARE_HYPERCALL_BUFFER(xen_hvm_altp2m_op_t, arg);
> +
> +arg = xc_hypercall_buffer_alloc(handle, arg, sizeof(*arg));
> +if ( arg == NULL )
> +return -1;
> +
> +arg->version = HVMOP_ALTP2M_INTERFACE_VERSION;
> +arg->cmd = HVMOP_altp2m_set_suppress_ve_multi;
> +arg->domain = domid;
> +arg->u.suppress_ve.view = view_id;
> +arg->u.suppress_ve.gfn = start_gfn;
> +arg->u.suppress_ve.suppress_ve = sve;
> +arg->u.suppress_ve.nr = nr;
> +
> +rc = xencall2(handle->xcall, __HYPERVISOR_hvm_op, HVMOP_altp2m,
> + HYPERCALL_BUFFER_AS_ARG(arg));
> +xc_hypercall_buffer_free(handle, arg);
> +return rc;
> +}
> +
> int xc_altp2m_set_mem_access(xc_interface *handle, uint32_t domid,
> uint16_t view_id, xen_pfn_t gfn,
> xenmem_access_t access)
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 06a7b40107..d3d9f8c30f 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -4535,6 +4535,7 @@ static int do_altp2m_op(
> case HVMOP_altp2m_destroy_p2m:
> case HVMOP_altp2m_switch_p2m:
> case HVMOP_altp2m_set_suppress_ve:
> +case HVMOP_altp2m_set_suppress_ve_multi:
> case HVMOP_altp2m_get_suppress_ve:
> case HVMOP_altp2m_set_mem_access:
> case HVMOP_altp2m_set_mem_access_multi:
> @@ -4681,7 +4682,7 @@ static int do_altp2m_op(
> break;
>
> case HVMOP_altp2m_set_suppress_ve:
> -if ( a.u.suppress_ve.pad1 || a.u.suppress_ve.pad2 )
> +if ( a.u.suppress_ve.pad1 )
> rc = -EINVAL;
> else
> {
> @@ -4693,8 +4694,31 @@ static int do_altp2m_op(
> }
> break;
>
> +case HVMOP_altp2m_set_suppress_ve_multi:
> +if ( a.u.suppress_ve.pad1 || !a.u.suppress_ve.nr )
> +rc = -EINVAL;
> +else
> +{
> +rc = p2m_set_suppress_ve_multi(d, a.u.suppress_ve.gfn,
> + a.u.suppress_ve.nr,
> + a.u.suppress_ve.suppress_ve,
> + a.u.suppress_ve.view);
I have to say I'm not a fan of stuffing the current gfn progress into
rc, perhaps a separate pointer being passed in for storing that and
returning -ERESTART would be cleaner.
> +if ( rc > 0 )
> +{
> +a.u.suppress_ve.gfn = rc;
There had been discussion in the past whether its acceptable to
overwrite fields that were passed in like this. This may not be the
expected behavior. For the mem_sharing side at least we have
introduced an "opaque" field in the structure to store that
Re: [Xen-devel] [PATCH v2 09/15] xen/gntdev: use mmu_range_notifier_insert
On 11/4/19 9:31 PM, Jason Gunthorpe wrote:
> On Mon, Nov 04, 2019 at 05:03:31PM -0500, Boris Ostrovsky wrote:
>> On 10/28/19 4:10 PM, Jason Gunthorpe wrote:
>>> @@ -445,17 +438,9 @@ static void gntdev_vma_close(struct vm_area_struct
>>> *vma)
>>> struct gntdev_priv *priv = file->private_data;
>>>
>>> pr_debug("gntdev_vma_close %p\n", vma);
>>> - if (use_ptemod) {
>>> - /* It is possible that an mmu notifier could be running
>>> -* concurrently, so take priv->lock to ensure that the vma won't
>>> -* vanishing during the unmap_grant_pages call, since we will
>>> -* spin here until that completes. Such a concurrent call will
>>> -* not do any unmapping, since that has been done prior to
>>> -* closing the vma, but it may still iterate the unmap_ops list.
>>> -*/
>>> - mutex_lock(>lock);
>>> + if (use_ptemod && map->vma == vma) {
>>
>> Is it possible for map->vma not to be equal to vma?
> It could be NULL at least if use_ptemod is not set.
>
> Otherwise, I'm not sure, the confusing bit is that the map comes from
> here:
>
> map = gntdev_find_map_index(priv, index, count);
>
> It looks like the intent is that the map->vma is always set to the
> only vma that has the map as private_data.
I am not sure how this can work otherwise. We stash map pointer in vm's
vm_private_data and vice versa (for use_ptemod) gntdev_mmap() so if they
have to match.
That's why I was asking you to see if you had something particular in
mind when you added this test.
> So, I suppose it can be relaxed to a null test and a WARN_ON that it
> hasn't changed?
You mean
if (use_ptemod) {
WARN_ON(map->vma != vma);
...
Yes, that sounds good.
-boris
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH V1 2/2] x86/mm: Make use of the default access param from xc_altp2m_create_view
On Tue, Nov 5, 2019 at 5:43 AM Alexandru Stefan ISAILA wrote: > > At this moment the default_access param from xc_altp2m_create_view is > not used. > > This patch assigns default_access to p2m->default_access at the time of > initializing a new altp2m view. > > Signed-off-by: Alexandru Isaila Reviewed-by: Tamas K Lengyel ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [XEN PATCH v2] MAINTAINERS: ARINC 653 scheduler maintainer updates
On Tue, Nov 05, 2019 at 08:51:52AM -0500, Stewart Hildebrand wrote: > Add DornerWorks internal list. This will forward to relevant people > within DornerWorks. > > Add myself to MAINTAINERS for ARINC653 scheduler. > > Remove Robbie from MAINTAINERS for ARINC653 scheduler. > Missing SoB here. No need to resend. The following can be added while committing: Signed-off-by: Stewart Hildebrand Let me know what you think. > --- > > Note that get_maintainers.pl/add_maintainers.pl do not currently add > the DornerWorks list email address in CC. I tested add_maintainers.pl > on a patch modifying sched_arinc653.c, and I did not see the > DornerWorks list appear in CC. Lars, this is for you. As far as I can tell get_maintainers.pl does extract L:. The problem is probably with add_maintainers.pl. Wei. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 08/15] xen/gntdev: Use select for DMA_SHARED_BUFFER
On 01.11.19 19:26, Jason Gunthorpe wrote:
On Mon, Oct 28, 2019 at 05:10:25PM -0300, Jason Gunthorpe wrote:
From: Jason Gunthorpe
DMA_SHARED_BUFFER can not be enabled by the user (it represents a library
set in the kernel). The kconfig convention is to use select for such
symbols so they are turned on implicitly when the user enables a kconfig
that needs them.
Otherwise the XEN_GNTDEV_DMABUF kconfig is overly difficult to enable.
Fixes: 932d6562179e ("xen/gntdev: Add initial support for dma-buf UAPI")
Cc: Oleksandr Andrushchenko
Cc: Boris Ostrovsky
Cc: xen-devel@lists.xenproject.org
Cc: Juergen Gross
Cc: Stefano Stabellini
Reviewed-by: Juergen Gross
Reviewed-by: Oleksandr Andrushchenko
Signed-off-by: Jason Gunthorpe
---
drivers/xen/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Juergen/Oleksandr/Xen Maintainers:
Would you take this patch through a xen related tree? The only reason
I had in this series is to make it easier to compile-test the gntdev
changes.
Yes, I can take it for 5.5.
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PULL 0/4] Trivial branch patches
The following changes since commit 36609b4fa36f0ac934874371874416f7533a5408: Merge remote-tracking branch 'remotes/palmer/tags/palmer-for-master-4.2-sf1' into staging (2019-11-02 17:59:03 +) are available in the Git repository at: git://github.com/vivier/qemu.git tags/trivial-branch-pull-request for you to fetch changes up to a37a36a11b584e083b1c578f1d60e6e0f7878d5f: global: Squash 'the the' (2019-11-05 15:06:09 +0100) Trivial fixes (20191105) Dr. David Alan Gilbert (1): global: Squash 'the the' Greg Kurz (1): qom: Fix error message in object_class_property_add() Philippe Mathieu-Daudé (2): hw/misc/grlib_ahb_apb_pnp: Avoid crash when writing to PnP registers hw/misc/grlib_ahb_apb_pnp: Fix 8-bit accesses disas/libvixl/vixl/invalset.h | 2 +- docs/interop/pr-helper.rst | 2 +- docs/specs/ppc-spapr-hotplug.txt| 2 +- docs/specs/ppc-xive.rst | 2 +- docs/specs/tpm.txt | 2 +- hw/misc/grlib_ahb_apb_pnp.c | 12 include/hw/xen/interface/io/blkif.h | 2 +- qom/object.c| 10 -- scripts/dump-guest-memory.py| 2 +- 9 files changed, 23 insertions(+), 13 deletions(-) -- 2.21.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PULL 1/4] hw/misc/grlib_ahb_apb_pnp: Avoid crash when writing to PnP registers
From: Philippe Mathieu-Daudé
Guests can crash QEMU when writting to PnP registers:
$ echo 'writeb 0x800ff042 69' | qemu-system-sparc -M leon3_generic -S -bios
/etc/magic -qtest stdio
[I 1571938309.932255] OPENED
[R +0.063474] writeb 0x800ff042 69
Segmentation fault (core dumped)
(gdb) bt
#0 0x in ()
#1 0x555f4bcdf0bc in memory_region_write_with_attrs_accessor
(mr=0x555f4d7be8c0, addr=66, value=0x7fff07d00f08, size=1, shift=0, mask=255,
attrs=...) at memory.c:503
#2 0x555f4bcdf185 in access_with_adjusted_size (addr=66,
value=0x7fff07d00f08, size=1, access_size_min=1, access_size_max=4,
access_fn=0x555f4bcdeff4 ,
mr=0x555f4d7be8c0, attrs=...) at memory.c:539
#3 0x555f4bce2243 in memory_region_dispatch_write (mr=0x555f4d7be8c0,
addr=66, data=69, op=MO_8, attrs=...) at memory.c:1489
#4 0x555f4bc80b20 in flatview_write_continue (fv=0x555f4d92c400,
addr=2148528194, attrs=..., buf=0x7fff07d01120 "E", len=1, addr1=66, l=1,
mr=0x555f4d7be8c0) at exec.c:3161
#5 0x555f4bc80c65 in flatview_write (fv=0x555f4d92c400, addr=2148528194,
attrs=..., buf=0x7fff07d01120 "E", len=1) at exec.c:3201
#6 0x555f4bc80fb0 in address_space_write (as=0x555f4d7aa460,
addr=2148528194, attrs=..., buf=0x7fff07d01120 "E", len=1) at exec.c:3291
#7 0x555f4bc8101d in address_space_rw (as=0x555f4d7aa460,
addr=2148528194, attrs=..., buf=0x7fff07d01120 "E", len=1, is_write=true) at
exec.c:3301
#8 0x555f4bcdb388 in qtest_process_command (chr=0x555f4c2ed7e0
, words=0x555f4db0c5d0) at qtest.c:432
Instead of crashing, log the access as unimplemented.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: KONRAD Frederic
Message-Id: <20191025110114.27091-2-phi...@redhat.com>
Signed-off-by: Laurent Vivier
---
hw/misc/grlib_ahb_apb_pnp.c | 8
1 file changed, 8 insertions(+)
diff --git a/hw/misc/grlib_ahb_apb_pnp.c b/hw/misc/grlib_ahb_apb_pnp.c
index 7338461694c9..f3c015d2c35f 100644
--- a/hw/misc/grlib_ahb_apb_pnp.c
+++ b/hw/misc/grlib_ahb_apb_pnp.c
@@ -22,6 +22,7 @@
*/
#include "qemu/osdep.h"
+#include "qemu/log.h"
#include "hw/sysbus.h"
#include "hw/misc/grlib_ahb_apb_pnp.h"
@@ -231,8 +232,15 @@ static uint64_t grlib_apb_pnp_read(void *opaque, hwaddr
offset, unsigned size)
return apb_pnp->regs[offset >> 2];
}
+static void grlib_apb_pnp_write(void *opaque, hwaddr addr,
+uint64_t val, unsigned size)
+{
+qemu_log_mask(LOG_UNIMP, "%s not implemented\n", __func__);
+}
+
static const MemoryRegionOps grlib_apb_pnp_ops = {
.read = grlib_apb_pnp_read,
+.write = grlib_apb_pnp_write,
.endianness = DEVICE_BIG_ENDIAN,
};
--
2.21.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PULL 3/4] qom: Fix error message in object_class_property_add()
From: Greg Kurz
The error message in object_class_property_add() was copied from
object_property_add() in commit 16bf7f522a2ff. Clarify that it is
about a class, not an object.
While here, have the format string in both functions to fit in a
single line for better grep-ability, despite the checkpatch warning.
Signed-off-by: Greg Kurz
Reviewed-by: Laurent Vivier
Message-Id: <157287383591.234942.311840593519058490.st...@bahia.tlslab.ibm.com>
Signed-off-by: Laurent Vivier
---
qom/object.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/qom/object.c b/qom/object.c
index 6fa9c619fac4..d51b57fba11e 100644
--- a/qom/object.c
+++ b/qom/object.c
@@ -1106,9 +1106,8 @@ object_property_add(Object *obj, const char *name, const
char *type,
}
if (object_property_find(obj, name, NULL) != NULL) {
-error_setg(errp, "attempt to add duplicate property '%s'"
- " to object (type '%s')", name,
- object_get_typename(obj));
+error_setg(errp, "attempt to add duplicate property '%s' to object
(type '%s')",
+ name, object_get_typename(obj));
return NULL;
}
@@ -1139,9 +1138,8 @@ object_class_property_add(ObjectClass *klass,
ObjectProperty *prop;
if (object_class_property_find(klass, name, NULL) != NULL) {
-error_setg(errp, "attempt to add duplicate property '%s'"
- " to object (type '%s')", name,
- object_class_get_name(klass));
+error_setg(errp, "attempt to add duplicate property '%s' to class
(type '%s')",
+ name, object_class_get_name(klass));
return NULL;
}
--
2.21.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PULL 4/4] global: Squash 'the the'
From: "Dr. David Alan Gilbert"
'the' has a tendency to double up; squash them back down.
Signed-off-by: Dr. David Alan Gilbert
Reviewed-by: Alex Bennée
Reviewed-by: Laurent Vivier
Reviewed-by: Philippe Mathieu-Daudé
Message-Id: <20191104185202.102504-1-dgilb...@redhat.com>
Signed-off-by: Laurent Vivier
---
disas/libvixl/vixl/invalset.h | 2 +-
docs/interop/pr-helper.rst | 2 +-
docs/specs/ppc-spapr-hotplug.txt| 2 +-
docs/specs/ppc-xive.rst | 2 +-
docs/specs/tpm.txt | 2 +-
include/hw/xen/interface/io/blkif.h | 2 +-
scripts/dump-guest-memory.py| 2 +-
7 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/disas/libvixl/vixl/invalset.h b/disas/libvixl/vixl/invalset.h
index ffdc0237b47c..ef5e49d6feb2 100644
--- a/disas/libvixl/vixl/invalset.h
+++ b/disas/libvixl/vixl/invalset.h
@@ -102,7 +102,7 @@ template class InvalSet {
size_t size() const;
// Returns true if no elements are stored in the set.
- // Note that this does not mean the the backing storage is empty: it can
still
+ // Note that this does not mean the backing storage is empty: it can still
// contain invalid elements.
bool empty() const;
diff --git a/docs/interop/pr-helper.rst b/docs/interop/pr-helper.rst
index 9f76d5bcf98f..e926f0a6c9cb 100644
--- a/docs/interop/pr-helper.rst
+++ b/docs/interop/pr-helper.rst
@@ -10,7 +10,7 @@ can delegate implementation of persistent reservations to an
external
restricting access to block devices to specific initiators in a shared
storage setup.
-For a more detailed reference please refer the the SCSI Primary
+For a more detailed reference please refer to the SCSI Primary
Commands standard, specifically the section on Reservations and the
"PERSISTENT RESERVE IN" and "PERSISTENT RESERVE OUT" commands.
diff --git a/docs/specs/ppc-spapr-hotplug.txt b/docs/specs/ppc-spapr-hotplug.txt
index cc7833108e12..859d52cce6c8 100644
--- a/docs/specs/ppc-spapr-hotplug.txt
+++ b/docs/specs/ppc-spapr-hotplug.txt
@@ -385,7 +385,7 @@ Each LMB list entry consists of the following elements:
is used to retrieve the right associativity list to be used for this
LMB.
- A 32bit flags word. The bit at bit position 0x0008 defines whether
- the LMB is assigned to the the partition as of boot time.
+ the LMB is assigned to the partition as of boot time.
ibm,dynamic-memory-v2
diff --git a/docs/specs/ppc-xive.rst b/docs/specs/ppc-xive.rst
index 148d57eb6ab2..83d43f658b90 100644
--- a/docs/specs/ppc-xive.rst
+++ b/docs/specs/ppc-xive.rst
@@ -163,7 +163,7 @@ Interrupt Priority Register (PIPR) is also updated using
the IPB. This
register represent the priority of the most favored pending
notification.
-The PIPR is then compared to the the Current Processor Priority
+The PIPR is then compared to the Current Processor Priority
Register (CPPR). If it is more favored (numerically less than), the
CPU interrupt line is raised and the EO bit of the Notification Source
Register (NSR) is updated to notify the presence of an exception for
diff --git a/docs/specs/tpm.txt b/docs/specs/tpm.txt
index 5d8c26b1adba..9c8cca042da8 100644
--- a/docs/specs/tpm.txt
+++ b/docs/specs/tpm.txt
@@ -89,7 +89,7 @@ TPM upon reboot. The PPI specification defines the operation
requests and the
actions the firmware has to take. The system administrator passes the operation
request number to the firmware through an ACPI interface which writes this
number to a memory location that the firmware knows. Upon reboot, the firmware
-finds the number and sends commands to the the TPM. The firmware writes the TPM
+finds the number and sends commands to the TPM. The firmware writes the TPM
result code and the operation request number to a memory location that ACPI can
read from and pass the result on to the administrator.
diff --git a/include/hw/xen/interface/io/blkif.h
b/include/hw/xen/interface/io/blkif.h
index 8b1be50ce81e..d07fa1e07822 100644
--- a/include/hw/xen/interface/io/blkif.h
+++ b/include/hw/xen/interface/io/blkif.h
@@ -341,7 +341,7 @@
* access (even when it should be read-only). If the frontend hits the
* maximum number of allowed persistently mapped grants, it can fallback
* to non persistent mode. This will cause a performance degradation,
- * since the the backend driver will still try to map those grants
+ * since the backend driver will still try to map those grants
* persistently. Since the persistent grants protocol is compatible with
* the previous protocol, a frontend driver can choose to work in
* persistent mode even when the backend doesn't support it.
diff --git a/scripts/dump-guest-memory.py b/scripts/dump-guest-memory.py
index 2c587cbefc57..9371e4581308 100644
--- a/scripts/dump-guest-memory.py
+++ b/scripts/dump-guest-memory.py
@@ -170,7 +170,7 @@ class ELF(object):
self.ehdr.e_phnum += 1
def to_file(self, elf_file):
-"""Writes all ELF structures
[Xen-devel] [PULL 2/4] hw/misc/grlib_ahb_apb_pnp: Fix 8-bit accesses
From: Philippe Mathieu-Daudé
The Plug & Play region of the AHB/APB bridge can be accessed
by various word size, however the implementation is clearly
restricted to 32-bit:
static uint64_t grlib_apb_pnp_read(void *opaque, hwaddr offset, unsigned size)
{
APBPnp *apb_pnp = GRLIB_APB_PNP(opaque);
return apb_pnp->regs[offset >> 2];
}
Set the MemoryRegionOps::impl min/max fields to 32-bit, so
memory.c::access_with_adjusted_size() can adjust when the
access is not 32-bit.
This is required to run RTEMS on leon3, the grlib scanning
functions do byte accesses.
Reported-by: Jiri Gaisler
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: KONRAD Frederic
Message-Id: <20191025110114.27091-3-phi...@redhat.com>
Signed-off-by: Laurent Vivier
---
hw/misc/grlib_ahb_apb_pnp.c | 4
1 file changed, 4 insertions(+)
diff --git a/hw/misc/grlib_ahb_apb_pnp.c b/hw/misc/grlib_ahb_apb_pnp.c
index f3c015d2c35f..e230e2536361 100644
--- a/hw/misc/grlib_ahb_apb_pnp.c
+++ b/hw/misc/grlib_ahb_apb_pnp.c
@@ -242,6 +242,10 @@ static const MemoryRegionOps grlib_apb_pnp_ops = {
.read = grlib_apb_pnp_read,
.write = grlib_apb_pnp_write,
.endianness = DEVICE_BIG_ENDIAN,
+.impl = {
+.min_access_size = 4,
+.max_access_size = 4,
+},
};
static void grlib_apb_pnp_realize(DeviceState *dev, Error **errp)
--
2.21.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-4.14 test] 143610: regressions - FAIL
flight 143610 linux-4.14 real [real] http://logs.test-lab.xenproject.org/osstest/logs/143610/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qcow2 19 guest-start/debian.repeat fail REGR. vs. 142849 test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail REGR. vs. 142849 test-amd64-i386-xl-raw 19 guest-start/debian.repeat fail REGR. vs. 142849 test-armhf-armhf-xl-vhd 15 guest-start/debian.repeat fail REGR. vs. 142849 test-armhf-armhf-libvirt-raw 15 guest-start/debian.repeat fail REGR. vs. 142849 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 142849 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 142849 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
[Xen-devel] [XEN PATCH v2] MAINTAINERS: ARINC 653 scheduler maintainer updates
Add DornerWorks internal list. This will forward to relevant people within DornerWorks. Add myself to MAINTAINERS for ARINC653 scheduler. Remove Robbie from MAINTAINERS for ARINC653 scheduler. --- Note that get_maintainers.pl/add_maintainers.pl do not currently add the DornerWorks list email address in CC. I tested add_maintainers.pl on a patch modifying sched_arinc653.c, and I did not see the DornerWorks list appear in CC. v1: https://lists.xenproject.org/archives/html/xen-devel/2019-08/msg02217.html v2: Use L: designation for DornerWorks internal list Add myself and remove Robbie as maintainer --- MAINTAINERS | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index dcd5acb36a..28e7eb554e 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -171,8 +171,9 @@ F: xen/common/argo.c ARINC653 SCHEDULER M: Josh Whitehead -M: Robert VanVossen +M: Stewart Hildebrand S: Supported +L: DornerWorks Xen-Devel F: xen/common/sched_arinc653.c F: tools/libxc/xc_arinc653.c -- 2.23.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH V1 1/2] x86/altp2m: Add hypercall to set a range of sve bits
By default the sve bits are not set.
This patch adds a new hypercall, xc_altp2m_set_supress_ve_multi(),
to set a range of sve bits.
The core function, p2m_set_suppress_ve_multi(), does not brake in case
of a error and it is doing a best effort for setting the bits in the
given range. A check for continuation is made in order to have
preemption on big ranges.
Signed-off-by: Alexandru Isaila
---
tools/libxc/include/xenctrl.h | 3 ++
tools/libxc/xc_altp2m.c | 25 ++
xen/arch/x86/hvm/hvm.c | 28 +--
xen/arch/x86/mm/p2m.c | 61 +
xen/include/public/hvm/hvm_op.h | 4 ++-
xen/include/xen/mem_access.h| 3 ++
6 files changed, 121 insertions(+), 3 deletions(-)
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index f4431687b3..21b644f459 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1923,6 +1923,9 @@ int xc_altp2m_switch_to_view(xc_interface *handle,
uint32_t domid,
uint16_t view_id);
int xc_altp2m_set_suppress_ve(xc_interface *handle, uint32_t domid,
uint16_t view_id, xen_pfn_t gfn, bool sve);
+int xc_altp2m_set_supress_ve_multi(xc_interface *handle, uint32_t domid,
+ uint16_t view_id, xen_pfn_t start_gfn,
+ uint32_t nr, bool sve);
int xc_altp2m_get_suppress_ve(xc_interface *handle, uint32_t domid,
uint16_t view_id, xen_pfn_t gfn, bool *sve);
int xc_altp2m_set_mem_access(xc_interface *handle, uint32_t domid,
diff --git a/tools/libxc/xc_altp2m.c b/tools/libxc/xc_altp2m.c
index 09dad0355e..6605d9abbe 100644
--- a/tools/libxc/xc_altp2m.c
+++ b/tools/libxc/xc_altp2m.c
@@ -234,6 +234,31 @@ int xc_altp2m_set_suppress_ve(xc_interface *handle,
uint32_t domid,
return rc;
}
+int xc_altp2m_set_supress_ve_multi(xc_interface *handle, uint32_t domid,
+ uint16_t view_id, xen_pfn_t start_gfn,
+ uint32_t nr, bool sve)
+{
+int rc;
+DECLARE_HYPERCALL_BUFFER(xen_hvm_altp2m_op_t, arg);
+
+arg = xc_hypercall_buffer_alloc(handle, arg, sizeof(*arg));
+if ( arg == NULL )
+return -1;
+
+arg->version = HVMOP_ALTP2M_INTERFACE_VERSION;
+arg->cmd = HVMOP_altp2m_set_suppress_ve_multi;
+arg->domain = domid;
+arg->u.suppress_ve.view = view_id;
+arg->u.suppress_ve.gfn = start_gfn;
+arg->u.suppress_ve.suppress_ve = sve;
+arg->u.suppress_ve.nr = nr;
+
+rc = xencall2(handle->xcall, __HYPERVISOR_hvm_op, HVMOP_altp2m,
+ HYPERCALL_BUFFER_AS_ARG(arg));
+xc_hypercall_buffer_free(handle, arg);
+return rc;
+}
+
int xc_altp2m_set_mem_access(xc_interface *handle, uint32_t domid,
uint16_t view_id, xen_pfn_t gfn,
xenmem_access_t access)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 06a7b40107..d3d9f8c30f 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4535,6 +4535,7 @@ static int do_altp2m_op(
case HVMOP_altp2m_destroy_p2m:
case HVMOP_altp2m_switch_p2m:
case HVMOP_altp2m_set_suppress_ve:
+case HVMOP_altp2m_set_suppress_ve_multi:
case HVMOP_altp2m_get_suppress_ve:
case HVMOP_altp2m_set_mem_access:
case HVMOP_altp2m_set_mem_access_multi:
@@ -4681,7 +4682,7 @@ static int do_altp2m_op(
break;
case HVMOP_altp2m_set_suppress_ve:
-if ( a.u.suppress_ve.pad1 || a.u.suppress_ve.pad2 )
+if ( a.u.suppress_ve.pad1 )
rc = -EINVAL;
else
{
@@ -4693,8 +4694,31 @@ static int do_altp2m_op(
}
break;
+case HVMOP_altp2m_set_suppress_ve_multi:
+if ( a.u.suppress_ve.pad1 || !a.u.suppress_ve.nr )
+rc = -EINVAL;
+else
+{
+rc = p2m_set_suppress_ve_multi(d, a.u.suppress_ve.gfn,
+ a.u.suppress_ve.nr,
+ a.u.suppress_ve.suppress_ve,
+ a.u.suppress_ve.view);
+
+if ( rc > 0 )
+{
+a.u.suppress_ve.gfn = rc;
+rc = -ERESTART;
+
+if ( __copy_field_to_guest(guest_handle_cast(arg,
+ xen_hvm_altp2m_op_t),
+ , u.suppress_ve.gfn) )
+rc = -EFAULT;
+}
+}
+break;
+
case HVMOP_altp2m_get_suppress_ve:
-if ( a.u.suppress_ve.pad1 || a.u.suppress_ve.pad2 )
+if ( a.u.suppress_ve.pad1 )
rc = -EINVAL;
else
{
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index e5e4349dea..b2e63e75ff 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -3054,6 +3054,67 @@ out:
return rc;
}
[Xen-devel] [PATCH V1 2/2] x86/mm: Make use of the default access param from xc_altp2m_create_view
At this moment the default_access param from xc_altp2m_create_view is
not used.
This patch assigns default_access to p2m->default_access at the time of
initializing a new altp2m view.
Signed-off-by: Alexandru Isaila
---
xen/arch/x86/hvm/hvm.c| 3 ++-
xen/arch/x86/mm/p2m-ept.c | 5 +++--
xen/arch/x86/mm/p2m.c | 31 ++-
xen/include/asm-x86/hvm/vmx/vmx.h | 3 ++-
xen/include/asm-x86/p2m.h | 3 ++-
xen/include/public/hvm/hvm_op.h | 2 --
6 files changed, 35 insertions(+), 12 deletions(-)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index d3d9f8c30f..1239e4cbf0 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4669,7 +4669,8 @@ static int do_altp2m_op(
}
case HVMOP_altp2m_create_p2m:
-if ( !(rc = p2m_init_next_altp2m(d, )) )
+if ( !(rc = p2m_init_next_altp2m(d, ,
+ a.u.view.hvmmem_default_access)) )
rc = __copy_to_guest(arg, , 1) ? -EFAULT : 0;
break;
diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index 220990f017..e62e749ec5 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -1345,13 +1345,14 @@ void setup_ept_dump(void)
register_keyhandler('D', ept_dump_p2m_table, "dump VT-x EPT tables", 0);
}
-void p2m_init_altp2m_ept(struct domain *d, unsigned int i)
+void p2m_init_altp2m_ept(struct domain *d, unsigned int i,
+ p2m_access_t default_access)
{
struct p2m_domain *p2m = d->arch.altp2m_p2m[i];
struct p2m_domain *hostp2m = p2m_get_hostp2m(d);
struct ept_data *ept;
-p2m->default_access = hostp2m->default_access;
+p2m->default_access = default_access;
p2m->domain = hostp2m->domain;
p2m->global_logdirty = hostp2m->global_logdirty;
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index b2e63e75ff..c07e369359 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -2528,7 +2528,8 @@ void p2m_flush_altp2m(struct domain *d)
altp2m_list_unlock(d);
}
-static int p2m_activate_altp2m(struct domain *d, unsigned int idx)
+static int p2m_activate_altp2m(struct domain *d, unsigned int idx,
+ p2m_access_t hvmmem_default_access)
{
struct p2m_domain *hostp2m, *p2m;
int rc;
@@ -2554,7 +2555,7 @@ static int p2m_activate_altp2m(struct domain *d, unsigned
int idx)
goto out;
}
-p2m_init_altp2m_ept(d, idx);
+p2m_init_altp2m_ept(d, idx, hvmmem_default_access);
out:
p2m_unlock(p2m);
@@ -2565,6 +2566,7 @@ static int p2m_activate_altp2m(struct domain *d, unsigned
int idx)
int p2m_init_altp2m_by_id(struct domain *d, unsigned int idx)
{
int rc = -EINVAL;
+struct p2m_domain *hostp2m = p2m_get_hostp2m(d);
if ( idx >= MAX_ALTP2M )
return rc;
@@ -2572,17 +2574,36 @@ int p2m_init_altp2m_by_id(struct domain *d, unsigned
int idx)
altp2m_list_lock(d);
if ( d->arch.altp2m_eptp[idx] == mfn_x(INVALID_MFN) )
-rc = p2m_activate_altp2m(d, idx);
+rc = p2m_activate_altp2m(d, idx, hostp2m->default_access);
altp2m_list_unlock(d);
return rc;
}
-int p2m_init_next_altp2m(struct domain *d, uint16_t *idx)
+int p2m_init_next_altp2m(struct domain *d, uint16_t *idx,
+ uint16_t hvmmem_default_access)
{
int rc = -EINVAL;
unsigned int i;
+static const p2m_access_t memaccess[] = {
+#define ACCESS(ac) [XENMEM_access_##ac] = p2m_access_##ac
+ACCESS(n),
+ACCESS(r),
+ACCESS(w),
+ACCESS(rw),
+ACCESS(x),
+ACCESS(rx),
+ACCESS(wx),
+ACCESS(rwx),
+ACCESS(rx2rw),
+ACCESS(n2rwx),
+#undef ACCESS
+};
+
+if ( hvmmem_default_access > XENMEM_access_default )
+return rc;
+
altp2m_list_lock(d);
for ( i = 0; i < MAX_ALTP2M; i++ )
@@ -2590,7 +2611,7 @@ int p2m_init_next_altp2m(struct domain *d, uint16_t *idx)
if ( d->arch.altp2m_eptp[i] != mfn_x(INVALID_MFN) )
continue;
-rc = p2m_activate_altp2m(d, i);
+rc = p2m_activate_altp2m(d, i, memaccess[hvmmem_default_access]);
if ( !rc )
*idx = i;
diff --git a/xen/include/asm-x86/hvm/vmx/vmx.h
b/xen/include/asm-x86/hvm/vmx/vmx.h
index ebaa74449b..a9601e8f7e 100644
--- a/xen/include/asm-x86/hvm/vmx/vmx.h
+++ b/xen/include/asm-x86/hvm/vmx/vmx.h
@@ -598,7 +598,8 @@ void ept_p2m_uninit(struct p2m_domain *p2m);
void ept_walk_table(struct domain *d, unsigned long gfn);
bool_t ept_handle_misconfig(uint64_t gpa);
void setup_ept_dump(void);
-void p2m_init_altp2m_ept(struct domain *d, unsigned int i);
+void p2m_init_altp2m_ept(struct domain *d, unsigned int i,
+ p2m_access_t default_access);
/* Locate an alternate p2m by its EPTP */
unsigned int p2m_find_altp2m_by_eptp(struct domain *d, uint64_t eptp);
diff --git
[Xen-devel] [linux-4.9 test] 143630: regressions - FAIL
flight 143630 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/143630/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail REGR. vs. 142947 test-amd64-i386-xl-raw 19 guest-start/debian.repeat fail REGR. vs. 142947 test-amd64-amd64-xl-qcow2 19 guest-start/debian.repeat fail REGR. vs. 142947 test-armhf-armhf-xl-vhd 15 guest-start/debian.repeat fail REGR. vs. 142947 test-armhf-armhf-libvirt-raw 15 guest-start/debian.repeat fail REGR. vs. 142947 Tests which are failing intermittently (not blocking): test-amd64-amd64-amd64-pvgrub 7 xen-bootfail in 143526 pass in 143630 test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail pass in 143418 test-amd64-amd64-xl-rtds 15 guest-saverestore fail pass in 143526 test-armhf-armhf-xl-rtds 15 guest-stop fail pass in 143526 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail in 143418 like 142947 test-amd64-amd64-xl-rtds 16 guest-localmigrate fail in 143526 like 142893 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 142947 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 142947 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 142947 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 142947 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 142947 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass version targeted for testing: linux9e48f0c28dd505e39bd136ec92a042b311b127c6 baseline version: linux
Re: [Xen-devel] [XEN PATCH for-4.13] libxl: Fix setting vncpasswd to empty string
On Mon, Nov 04, 2019 at 03:30:47PM +, Anthony PERARD wrote: > Before 93dcc22, error from setting the vnc password to an empty > string, when QEMU wasn't expected a password, never prevented the creation > of a guest, and only logged an error message. > > Reported-by: Roger Pau Monné > Fixes: 93dcc22fe798c9fa5ce117f1ed6db0d8bd779020 > Signed-off-by: Anthony PERARD Acked-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-next v2 8/9] x86: be more verbose when running on a hypervisor
On Wed, Oct 23, 2019 at 03:22:24PM +0200, Jan Beulich wrote:
> On 21.10.2019 12:00, Roger Pau Monné wrote:
> > On Mon, Sep 30, 2019 at 04:00:42PM +0100, Wei Liu wrote:
> >> --- a/xen/include/asm-x86/guest/hypervisor.h
> >> +++ b/xen/include/asm-x86/guest/hypervisor.h
> >> @@ -36,6 +36,7 @@ bool hypervisor_probe(void);
> >> void hypervisor_setup(void);
> >> void hypervisor_ap_setup(void);
> >> void hypervisor_resume(void);
> >> +const char *hypervisor_name(void);
> >>
> >> #else
> >>
> >> @@ -45,6 +46,7 @@ static inline bool hypervisor_probe(void) { return
> >> false; }
> >> static inline void hypervisor_setup(void) {}
> >> static inline void hypervisor_ap_setup(void) {}
> >> static inline void hypervisor_resume(void) {}
> >> +static inline char *hypervisor_name(void) { return NULL; }
> >
> > I think you want an ASSERT_UNREACHABLE here, since hypervisor_name
> > shouldn't be called unless Xen has detected that's running as a guest,
> > which can only happen if CONFIG_GUEST is selected.
>
> And please bring prototype and stub in sync return-type-wise.
Missed this comment.
I will handle this if I haven't already.
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v1 02/10] KVM: x86/mmu: Prepare kvm_is_mmio_pfn() for PG_reserved changes
On 05.11.19 02:37, Dan Williams wrote:
On Thu, Oct 24, 2019 at 5:10 AM David Hildenbrand wrote:
Right now, ZONE_DEVICE memory is always set PG_reserved. We want to
change that.
KVM has this weird use case that you can map anything from /dev/mem
into the guest. pfn_valid() is not a reliable check whether the memmap
was initialized and can be touched. pfn_to_online_page() makes sure
that we have an initialized memmap (and don't have ZONE_DEVICE memory).
Rewrite kvm_is_mmio_pfn() to make sure the function produces the
same result once we stop setting ZONE_DEVICE pages PG_reserved.
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
Cc: Sean Christopherson
Cc: Vitaly Kuznetsov
Cc: Wanpeng Li
Cc: Jim Mattson
Cc: Joerg Roedel
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc: KarimAllah Ahmed
Cc: Michal Hocko
Cc: Dan Williams
Signed-off-by: David Hildenbrand
---
arch/x86/kvm/mmu.c | 29 +
1 file changed, 17 insertions(+), 12 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 24c23c66b226..f03089a336de 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -2962,20 +2962,25 @@ static bool mmu_need_write_protect(struct kvm_vcpu
*vcpu, gfn_t gfn,
static bool kvm_is_mmio_pfn(kvm_pfn_t pfn)
{
+ struct page *page = pfn_to_online_page(pfn);
+
+ /*
+* ZONE_DEVICE pages are never online. Online pages that are reserved
+* either indicate the zero page or MMIO pages.
+*/
+ if (page)
+ return !is_zero_pfn(pfn) && PageReserved(pfn_to_page(pfn));
+
+ /*
+* Anything with a valid (but not online) memmap could be ZONE_DEVICE.
+* Treat only UC/UC-/WC pages as MMIO.
You might clarify that ZONE_DEVICE pages that belong to WB cacheable
pmem have the correct memtype established by devm_memremap_pages().
/*
* Anything with a valid (but not online) memmap could be ZONE_DEVICE.
* Treat only UC/UC-/WC pages as MMIO. devm_memremap_pages() established
* the correct memtype for WB cacheable ZONE_DEVICE pages.
*/
Thanks!
Other than that, feel free to add:
Reviewed-by: Dan Williams
--
Thanks,
David / dhildenb
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/3] x86/boot: Cache cpu_has_hypervisor very early on boot
On 01/11/2019 20:25, Andrew Cooper wrote: > We cache Long Mode and No Execute early on boot, so take the opportunity to > cache HYPERVISOR early as well. Either: 1. the description needs clarifying that the whole 1c featureset is being stored, or 2. a mask should be applied to store only the hypervisor bit (this would be a safer option) > Replace opencoded early access to the feature bit. > > Signed-off-by: Andrew Cooper -- Thanks, Sergey ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v1] libxl: fix crash in helper_done due to uninitialized data
Am Fri, 27 Sep 2019 18:17:12 +0100
schrieb Ian Jackson :
> Olaf Hering writes ("[PATCH v1] libxl: fix crash in helper_done due to
> uninitialized data"):
> > A crash in helper_done, called from libxl_domain_suspend, was reported,
> > libxl_aoutils.c:328:datacopier_writable: unexpected poll event 0x1c on fd
> > 37 (should be POLLOUT) writing libxc header during copy of save v2 stream
> Ross and Andrew, you wrote much of this stream read stuff, what do you think ?
Did you have a chance to look at this issue?
Olaf
pgpmyuwziBjC8.pgp
Description: Digitale Signatur von OpenPGP
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v1 09/10] mm/memory_hotplug: Don't mark pages PG_reserved when initializing the memmap
On 04.11.19 23:44, Boris Ostrovsky wrote:
On 10/24/19 8:09 AM, David Hildenbrand wrote:
diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index 4f2e78a5e4db..af69f057913a 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -374,6 +374,13 @@ static void xen_online_page(struct page *page, unsigned
int order)
mutex_lock(_mutex);
for (i = 0; i < size; i++) {
p = pfn_to_page(start_pfn + i);
+ /*
+* TODO: The core used to mark the pages reserved. Most probably
+* we can stop doing that now. However, especially
+* alloc_xenballooned_pages() left PG_reserved set
+* on pages that can get mapped to user space.
+*/
+ __SetPageReserved(p);
I suspect this is not needed. Pages can get into balloon either from
here or from non-hotplug path (e.g. decrease_reservation()) and so when
we get a page from the balloon we would get a random page that may or
may not have Reserved bit set.
Yeah, I also think it is fine. If you agree, I'll drop this hunk and add
details to the patch description.
--
Thanks,
David / dhildenb
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v1 03/10] KVM: Prepare kvm_is_reserved_pfn() for PG_reserved changes
On 05.11.19 10:49, David Hildenbrand wrote:
On 05.11.19 10:17, David Hildenbrand wrote:
On 05.11.19 05:38, Dan Williams wrote:
On Thu, Oct 24, 2019 at 5:11 AM David Hildenbrand wrote:
Right now, ZONE_DEVICE memory is always set PG_reserved. We want to
change that.
KVM has this weird use case that you can map anything from /dev/mem
into the guest. pfn_valid() is not a reliable check whether the memmap
was initialized and can be touched. pfn_to_online_page() makes sure
that we have an initialized memmap (and don't have ZONE_DEVICE memory).
Rewrite kvm_is_reserved_pfn() to make sure the function produces the
same result once we stop setting ZONE_DEVICE pages PG_reserved.
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
Cc: Michal Hocko
Cc: Dan Williams
Cc: KarimAllah Ahmed
Signed-off-by: David Hildenbrand
---
virt/kvm/kvm_main.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index e9eb666eb6e8..9d18cc67d124 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -151,9 +151,15 @@ __weak int kvm_arch_mmu_notifier_invalidate_range(struct
kvm *kvm,
bool kvm_is_reserved_pfn(kvm_pfn_t pfn)
{
- if (pfn_valid(pfn))
- return PageReserved(pfn_to_page(pfn));
+ struct page *page = pfn_to_online_page(pfn);
+ /*
+* We treat any pages that are not online (not managed by the buddy)
+* as reserved - this includes ZONE_DEVICE pages and pages without
+* a memmap (e.g., mapped via /dev/mem).
+*/
+ if (page)
+ return PageReserved(page);
return true;
}
So after this all the pfn_valid() usage in kvm_main.c is replaced with
pfn_to_online_page()? Looks correct to me.
However, I'm worried that kvm is taking reference on ZONE_DEVICE pages
through some other path resulting in this:
https://lore.kernel.org/linux-nvdimm/20190919154708.ga24...@angband.pl/
I'll see if this patch set modulates or maintains that failure mode.
I'd assume that the behavior is unchanged. Ithink we get a reference to
these ZONE_DEVICE pages via __get_user_pages_fast() and friends in
hva_to_pfn_fast() and friends in virt/kvm/kvm_main.c
I think I know what's going wrong:
Pages that are pinned via gfn_to_pfn() and friends take a references,
however are often released via
kvm_release_pfn_clean()/kvm_release_pfn_dirty()/kvm_release_page_clean()...
E.g., in arch/x86/kvm/x86.c:reexecute_instruction()
...
pfn = gfn_to_pfn(vcpu->kvm, gpa_to_gfn(gpa));
...
kvm_release_pfn_clean(pfn);
void kvm_release_pfn_clean(kvm_pfn_t pfn)
{
if (!is_error_noslot_pfn(pfn) && !kvm_is_reserved_pfn(pfn))
put_page(pfn_to_page(pfn));
}
This function makes perfect sense as the counterpart for kvm_get_pfn():
void kvm_get_pfn(kvm_pfn_t pfn)
{
if (!kvm_is_reserved_pfn(pfn))
get_page(pfn_to_page(pfn));
}
As all ZONE_DEVICE pages are currently reserved, pages pinned via
gfn_to_pfn() and friends will often not see a put_page() AFAIKS.
Now, my patch does not change that, the result of
kvm_is_reserved_pfn(pfn) will be unchanged. A proper fix for that would
probably be
a) To drop the reference to ZONE_DEVICE pages in gfn_to_pfn() and
friends, after you successfully pinned the pages. (not sure if that's
the right thing to do but you're the expert)
b) To not use kvm_release_pfn_clean() and friends on pages that were
definitely pinned.
(talking to myself, sorry)
Thinking again, dropping this patch from this series could effectively
also fix that issue. E.g., kvm_release_pfn_clean() and friends would
always do a put_page() if "pfn_valid() and !PageReserved()", so after
patch 9 also on ZONDE_DEVICE pages.
But it would have side effects that might not be desired. E.g.,:
1. kvm_pfn_to_page() would also return ZONE_DEVICE pages (might even be
the right thing to do).
2. kvm_set_pfn_dirty() would also set ZONE_DEVICE pages dirty (might be
okay)
--
Thanks,
David / dhildenb
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v1 03/10] KVM: Prepare kvm_is_reserved_pfn() for PG_reserved changes
On 05.11.19 10:17, David Hildenbrand wrote:
On 05.11.19 05:38, Dan Williams wrote:
On Thu, Oct 24, 2019 at 5:11 AM David Hildenbrand wrote:
Right now, ZONE_DEVICE memory is always set PG_reserved. We want to
change that.
KVM has this weird use case that you can map anything from /dev/mem
into the guest. pfn_valid() is not a reliable check whether the memmap
was initialized and can be touched. pfn_to_online_page() makes sure
that we have an initialized memmap (and don't have ZONE_DEVICE memory).
Rewrite kvm_is_reserved_pfn() to make sure the function produces the
same result once we stop setting ZONE_DEVICE pages PG_reserved.
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
Cc: Michal Hocko
Cc: Dan Williams
Cc: KarimAllah Ahmed
Signed-off-by: David Hildenbrand
---
virt/kvm/kvm_main.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index e9eb666eb6e8..9d18cc67d124 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -151,9 +151,15 @@ __weak int kvm_arch_mmu_notifier_invalidate_range(struct
kvm *kvm,
bool kvm_is_reserved_pfn(kvm_pfn_t pfn)
{
- if (pfn_valid(pfn))
- return PageReserved(pfn_to_page(pfn));
+ struct page *page = pfn_to_online_page(pfn);
+ /*
+* We treat any pages that are not online (not managed by the buddy)
+* as reserved - this includes ZONE_DEVICE pages and pages without
+* a memmap (e.g., mapped via /dev/mem).
+*/
+ if (page)
+ return PageReserved(page);
return true;
}
So after this all the pfn_valid() usage in kvm_main.c is replaced with
pfn_to_online_page()? Looks correct to me.
However, I'm worried that kvm is taking reference on ZONE_DEVICE pages
through some other path resulting in this:
https://lore.kernel.org/linux-nvdimm/20190919154708.ga24...@angband.pl/
I'll see if this patch set modulates or maintains that failure mode.
I'd assume that the behavior is unchanged. Ithink we get a reference to
these ZONE_DEVICE pages via __get_user_pages_fast() and friends in
hva_to_pfn_fast() and friends in virt/kvm/kvm_main.c
I think I know what's going wrong:
Pages that are pinned via gfn_to_pfn() and friends take a references,
however are often released via
kvm_release_pfn_clean()/kvm_release_pfn_dirty()/kvm_release_page_clean()...
E.g., in arch/x86/kvm/x86.c:reexecute_instruction()
...
pfn = gfn_to_pfn(vcpu->kvm, gpa_to_gfn(gpa));
...
kvm_release_pfn_clean(pfn);
void kvm_release_pfn_clean(kvm_pfn_t pfn)
{
if (!is_error_noslot_pfn(pfn) && !kvm_is_reserved_pfn(pfn))
put_page(pfn_to_page(pfn));
}
This function makes perfect sense as the counterpart for kvm_get_pfn():
void kvm_get_pfn(kvm_pfn_t pfn)
{
if (!kvm_is_reserved_pfn(pfn))
get_page(pfn_to_page(pfn));
}
As all ZONE_DEVICE pages are currently reserved, pages pinned via
gfn_to_pfn() and friends will often not see a put_page() AFAIKS.
Now, my patch does not change that, the result of
kvm_is_reserved_pfn(pfn) will be unchanged. A proper fix for that would
probably be
a) To drop the reference to ZONE_DEVICE pages in gfn_to_pfn() and
friends, after you successfully pinned the pages. (not sure if that's
the right thing to do but you're the expert)
b) To not use kvm_release_pfn_clean() and friends on pages that were
definitely pinned.
--
Thanks,
David / dhildenb
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v1 01/10] mm/memory_hotplug: Don't allow to online/offline memory blocks with holes
On 05.11.19 02:30, Dan Williams wrote:
On Thu, Oct 24, 2019 at 5:10 AM David Hildenbrand wrote:
Our onlining/offlining code is unnecessarily complicated. Only memory
blocks added during boot can have holes (a range that is not
IORESOURCE_SYSTEM_RAM). Hotplugged memory never has holes (e.g., see
add_memory_resource()). All boot memory is alread online.
s/alread/already/
Thanks.
...also perhaps clarify "already online" by what point in time and why
that is relevant. For example a description of the difference between
the SetPageReserved() in the bootmem path and the one in the hotplug
path.
Will add.
Therefore, when we stop allowing to offline memory blocks with holes, we
implicitly no longer have to deal with onlining memory blocks with holes.
Maybe an explicit reference of the code areas that deal with holes
would help to back up that assertion. Certainly it would have saved me
some time for the review.
I can add a reference to the onlining code that will only online pages
that don't fall into memory holes.
This allows to simplify the code. For example, we no longer have to
worry about marking pages that fall into memory holes PG_reserved when
onlining memory. We can stop setting pages PG_reserved.
...but not for bootmem, right?
Yes, bootmem is not changed. (especially, early allocations and memory
holes are marked PG_reserved - basically everything not given to the
buddy after boot)
Offlining memory blocks added during boot is usually not guranteed to work
s/guranteed/guaranteed/
Thanks.
either way (unmovable data might have easily ended up on that memory during
boot). So stopping to do that should not really hurt (+ people are not
even aware of a setup where that used to work
Maybe put a "Link: https://lkml.kernel.org/r/$msg_id; to that discussion?
and that the existing code
still works correctly with memory holes). For the use case of offlining
memory to unplug DIMMs, we should see no change. (holes on DIMMs would be
weird).
However, less memory can be offlined than was theoretically allowed
previously, so I don't understand the "we should see no change"
comment. I still agree that's a price worth paying to get the code
cleanups and if someone screams we can look at adding it back, but the
fact that it was already fragile seems decent enough protection.
Hotplugged DIMMs (add_memory()) have no holes and will therefore see no
change.
Please note that hardware errors (PG_hwpoison) are not memory holes and
not affected by this change when offlining.
Cc: Andrew Morton
Cc: Michal Hocko
Cc: Oscar Salvador
Cc: Pavel Tatashin
Cc: Dan Williams
Cc: Anshuman Khandual
Signed-off-by: David Hildenbrand
---
mm/memory_hotplug.c | 26 --
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 561371ead39a..8d81730cf036 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -1447,10 +1447,19 @@ static void node_states_clear_node(int node, struct
memory_notify *arg)
node_clear_state(node, N_MEMORY);
}
+static int count_system_ram_pages_cb(unsigned long start_pfn,
+unsigned long nr_pages, void *data)
+{
+ unsigned long *nr_system_ram_pages = data;
+
+ *nr_system_ram_pages += nr_pages;
+ return 0;
+}
+
static int __ref __offline_pages(unsigned long start_pfn,
unsigned long end_pfn)
{
- unsigned long pfn, nr_pages;
+ unsigned long pfn, nr_pages = 0;
unsigned long offlined_pages = 0;
int ret, node, nr_isolate_pageblock;
unsigned long flags;
@@ -1461,6 +1470,20 @@ static int __ref __offline_pages(unsigned long start_pfn,
mem_hotplug_begin();
+ /*
+* Don't allow to offline memory blocks that contain holes.
+* Consecuently, memory blocks with holes can never get onlined
s/Consecuently/Consequently/
Thanks.
+* (hotplugged memory has no holes and all boot memory is online).
+* This allows to simplify the onlining/offlining code quite a lot.
+*/
The last sentence of this comment makes sense in the context of this
patch, but I don't think it stands by itself in the code base after
the fact. The person reading the comment can't see the simplifications
because the code is already gone. I'd clarify it to talk about why it
is safe to not mess around with PG_Reserved in the hotplug path
because of this check.
I'll think of something. It's not just the PG_reserved handling but the
whole pfn_valid()/walk_system_ram_range() handling that can be simplified.
After those clarifications you can add:
Reviewed-by: Dan Williams
Thanks!
--
Thanks,
David / dhildenb
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v1 03/10] KVM: Prepare kvm_is_reserved_pfn() for PG_reserved changes
On 05.11.19 05:38, Dan Williams wrote:
On Thu, Oct 24, 2019 at 5:11 AM David Hildenbrand wrote:
Right now, ZONE_DEVICE memory is always set PG_reserved. We want to
change that.
KVM has this weird use case that you can map anything from /dev/mem
into the guest. pfn_valid() is not a reliable check whether the memmap
was initialized and can be touched. pfn_to_online_page() makes sure
that we have an initialized memmap (and don't have ZONE_DEVICE memory).
Rewrite kvm_is_reserved_pfn() to make sure the function produces the
same result once we stop setting ZONE_DEVICE pages PG_reserved.
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
Cc: Michal Hocko
Cc: Dan Williams
Cc: KarimAllah Ahmed
Signed-off-by: David Hildenbrand
---
virt/kvm/kvm_main.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index e9eb666eb6e8..9d18cc67d124 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -151,9 +151,15 @@ __weak int kvm_arch_mmu_notifier_invalidate_range(struct
kvm *kvm,
bool kvm_is_reserved_pfn(kvm_pfn_t pfn)
{
- if (pfn_valid(pfn))
- return PageReserved(pfn_to_page(pfn));
+ struct page *page = pfn_to_online_page(pfn);
+ /*
+* We treat any pages that are not online (not managed by the buddy)
+* as reserved - this includes ZONE_DEVICE pages and pages without
+* a memmap (e.g., mapped via /dev/mem).
+*/
+ if (page)
+ return PageReserved(page);
return true;
}
So after this all the pfn_valid() usage in kvm_main.c is replaced with
pfn_to_online_page()? Looks correct to me.
However, I'm worried that kvm is taking reference on ZONE_DEVICE pages
through some other path resulting in this:
https://lore.kernel.org/linux-nvdimm/20190919154708.ga24...@angband.pl/
I'll see if this patch set modulates or maintains that failure mode.
I'd assume that the behavior is unchanged. Ithink we get a reference to
these ZONE_DEVICE pages via __get_user_pages_fast() and friends in
hva_to_pfn_fast() and friends in virt/kvm/kvm_main.c
--
Thanks,
David / dhildenb
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [BUG] Xen 4.13 rc1 can not boot up with new Domain0 kernel(linux5.4.0-rc3)
> > Bug detailed description: > > > > Can not boot up xen with new Domain0 kernel(linux5.4.0-rc3) > > > > Environment : > > > > HW: Cascade Lake server > > Xen: XEN 4.13.0rc1 > > Dom0: Linux 5.4.0-rc3 > > > > Reproduce steps: > > > > 1. install Xen and build Dom0 kernel(5.4.0-rc3) 2. restart host > > server(can not boot up) > > > > Current result: > > > > Can not boot up host > > The way you word things, you seem to suspect an issue in Xen. The log > you've provided suggests a Linux kernel side issue though. > Could you clarify that indeed this is an issue with Xen 4.13 RC1, i.e. that > the > same issue doesn't occur with older Xen, e.g. > 4.12.1? Update. We test Xen 4.13.0rc1 with Linux 5.4.0-rc6 Dom0, this problem disappeared. Best Regards, Jinwen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
