[Xen-devel] [PATCH RFC V4 1/3] KVM: X86: Memory ROE documentation
Following up with my previous threads on KVM assisted Anti rootkit protections. The current version doesn't address the attacks involving pages remapping. It is still design in progress, nevertheless, it will be in my later patch sets. Signed-off-by: Ahmed Abd El Mawgood --- Documentation/virtual/kvm/hypercalls.txt | 14 ++ 1 file changed, 14 insertions(+) diff --git a/Documentation/virtual/kvm/hypercalls.txt b/Documentation/virtual/kvm/hypercalls.txt index a890529c63ed..affd997eabfe 100644 --- a/Documentation/virtual/kvm/hypercalls.txt +++ b/Documentation/virtual/kvm/hypercalls.txt @@ -121,3 +121,17 @@ compute the CLOCK_REALTIME for its clock, at the same instant. Returns KVM_EOPNOTSUPP if the host does not use TSC clocksource, or if clock type is different than KVM_CLOCK_PAIRING_WALLCLOCK. + +7. KVM_HC_HMROE + +Architecture: x86 +Status: active +Purpose: Hypercall used to apply Read-Only Enforcement to guest pages +Usage: + a0: Start address aligned to page boundary. + a1: Number of pages to be protected. +This hypercall lets a guest kernel have part of its read/write memory +converted into read-only. This action is irreversible. KVM_HC_HMROE can +not be triggered from guest Ring 3 (user mode). The reason is that user +mode malicious software can make use of it to enforce read only protection +on an arbitrary memory page thus crashing the kernel. -- 2.16.4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Memory Read Only Enforcement: VMM assisted kernel rootkit mitigation for KVM V4
Here is change log from V3 To V4: - Fixing spelling/grammar mistakes suggested by Randy Dunlap - Changing the hypercall interface to be able to process multiple pages per one hypercall also suggested by Randy Dunlap. It turns out that this will save lots of vmexist/memory slot flushes when protecting many pages. [PATCH RFC V4 1/3] KVM: X86: Memory ROE documentation [PATCH RFC V4 2/3] KVM: X86: Adding arbitrary data pointer in kvm memslot iterator functions [PATCH RFC V4 3/3] KVM: X86: Adding skeleton for Memory ROE Summary: Documentation/virtual/kvm/hypercalls.txt | 14 arch/x86/include/asm/kvm_host.h | 11 ++- arch/x86/kvm/Kconfig | 7 ++ arch/x86/kvm/mmu.c | 127 ++- arch/x86/kvm/x86.c | 104 - include/linux/kvm_host.h | 3 + include/uapi/linux/kvm_para.h| 1 + virt/kvm/kvm_main.c | 29 ++- 8 files changed, 254 insertions(+), 42 deletions(-) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH RFC V4 3/3] KVM: X86: Adding skeleton for Memory ROE
This patch introduces a hypercall implemented for X86 that can assist
against subset of kernel rootkits, it works by place readonly protection in
shadow PTE. The end result protection is also kept in a bitmap for each
kvm_memory_slot and is used as reference when updating SPTEs. The whole
goal is to protect the guest kernel static data from modification if
attacker is running from guest ring 0, for this reason there is no
hypercall to revert effect of Memory ROE hypercall. This patch doesn't
implement integrity check on guest TLB so obvious attack on the current
implementation will involve guest virtual address -> guest physical
address remapping, but there are plans to fix that.
Signed-off-by: Ahmed Abd El Mawgood
---
arch/x86/include/asm/kvm_host.h | 11 -
arch/x86/kvm/Kconfig| 7 +++
arch/x86/kvm/mmu.c | 72 +++-
arch/x86/kvm/x86.c | 104 ++--
include/linux/kvm_host.h| 3 ++
include/uapi/linux/kvm_para.h | 1 +
virt/kvm/kvm_main.c | 29 +--
7 files changed, 208 insertions(+), 19 deletions(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index c13cd28d9d1b..128bcfa246a3 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -236,6 +236,15 @@ struct kvm_mmu_memory_cache {
void *objects[KVM_NR_MEM_OBJS];
};
+/*
+ * This is internal structure used to be be able to access kvm memory slot and
+ * have track of the number of current PTE when doing shadow PTE walk
+ */
+struct kvm_write_access_data {
+ int i;
+ struct kvm_memory_slot *memslot;
+};
+
/*
* the pages used as guest page table on soft mmu are tracked by
* kvm_memory_slot.arch.gfn_track which is 16 bits, so the role bits used
@@ -1130,7 +1139,7 @@ void kvm_mmu_set_mask_ptes(u64 user_mask, u64
accessed_mask,
u64 acc_track_mask, u64 me_mask);
void kvm_mmu_reset_context(struct kvm_vcpu *vcpu);
-void kvm_mmu_slot_remove_write_access(struct kvm *kvm,
+void kvm_mmu_slot_apply_write_access(struct kvm *kvm,
struct kvm_memory_slot *memslot);
void kvm_mmu_zap_collapsible_sptes(struct kvm *kvm,
const struct kvm_memory_slot *memslot);
diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig
index 1bbec387d289..487e02de4e76 100644
--- a/arch/x86/kvm/Kconfig
+++ b/arch/x86/kvm/Kconfig
@@ -96,6 +96,13 @@ config KVM_MMU_AUDIT
This option adds a R/W kVM module parameter 'mmu_audit', which allows
auditing of KVM MMU events at runtime.
+config KVM_MROE
+ bool "Hypercall Memory Read-Only Enforcement"
+ depends on KVM && X86
+ help
+ This option adds KVM_HC_HMROE hypercall to kvm as a hardening
+ mechanism to protect memory pages from being edited.
+
# OK, it's a little counter-intuitive to do this, but it puts it neatly under
# the virtualization menu.
source drivers/vhost/Kconfig
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 77661530b2c4..4ce6a9a19a23 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -1416,9 +1416,8 @@ static bool spte_write_protect(u64 *sptep, bool
pt_protect)
return mmu_spte_update(sptep, spte);
}
-static bool __rmap_write_protect(struct kvm *kvm,
-struct kvm_rmap_head *rmap_head,
-bool pt_protect, void *data)
+static bool __rmap_write_protection(struct kvm *kvm,
+ struct kvm_rmap_head *rmap_head, bool pt_protect)
{
u64 *sptep;
struct rmap_iterator iter;
@@ -1430,6 +1429,38 @@ static bool __rmap_write_protect(struct kvm *kvm,
return flush;
}
+#ifdef CONFIG_KVM_MROE
+static bool __rmap_write_protect_mroe(struct kvm *kvm,
+ struct kvm_rmap_head *rmap_head,
+ bool pt_protect,
+ struct kvm_write_access_data *d)
+{
+ u64 *sptep;
+ struct rmap_iterator iter;
+ bool prot;
+ bool flush = false;
+
+ for_each_rmap_spte(rmap_head, , sptep) {
+ prot = !test_bit(d->i, d->memslot->mroe_bitmap) && pt_protect;
+ flush |= spte_write_protect(sptep, prot);
+ d->i++;
+ }
+ return flush;
+}
+#endif
+
+static bool __rmap_write_protect(struct kvm *kvm,
+ struct kvm_rmap_head *rmap_head,
+ bool pt_protect,
+ struct kvm_write_access_data *d)
+{
+#ifdef CONFIG_KVM_MROE
+ if (d != NULL)
+ return __rmap_write_protect_mroe(kvm, rmap_head, pt_protect, d);
+#endif
+ return __rmap_write_protection(kvm, rmap_head, pt_protect);
+}
+
static bool spte_clear_dirty(u64 *sptep)
{
u64 spte = *sptep;
@@ -1517,7 +1548,7 @@ static void kvm_mmu_write_protect_pt_masked(struct kvm
*kvm,
while (mask) {
rmap_head = __gfn_to_rmap(slot->base_gfn + gfn_offset
[Xen-devel] [PATCH RFC V4 2/3] KVM: X86: Adding arbitrary data pointer in kvm memslot iterator functions
This will help sharing data into the slot_level_handler callback. In my
case I need to a share a counter for the pages traversed to use it in some
bitmap. Being able to send arbitrary memory pointer into the
slot_level_handler callback made it easy.
Signed-off-by: Ahmed Abd El Mawgood
---
arch/x86/kvm/mmu.c | 65 +++---
1 file changed, 37 insertions(+), 28 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index d594690d8b95..77661530b2c4 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -1418,7 +1418,7 @@ static bool spte_write_protect(u64 *sptep, bool
pt_protect)
static bool __rmap_write_protect(struct kvm *kvm,
struct kvm_rmap_head *rmap_head,
-bool pt_protect)
+bool pt_protect, void *data)
{
u64 *sptep;
struct rmap_iterator iter;
@@ -1457,7 +1457,8 @@ static bool wrprot_ad_disabled_spte(u64 *sptep)
* - W bit on ad-disabled SPTEs.
* Returns true iff any D or W bits were cleared.
*/
-static bool __rmap_clear_dirty(struct kvm *kvm, struct kvm_rmap_head
*rmap_head)
+static bool __rmap_clear_dirty(struct kvm *kvm, struct kvm_rmap_head
*rmap_head,
+ void *data)
{
u64 *sptep;
struct rmap_iterator iter;
@@ -1483,7 +1484,8 @@ static bool spte_set_dirty(u64 *sptep)
return mmu_spte_update(sptep, spte);
}
-static bool __rmap_set_dirty(struct kvm *kvm, struct kvm_rmap_head *rmap_head)
+static bool __rmap_set_dirty(struct kvm *kvm, struct kvm_rmap_head *rmap_head,
+ void *data)
{
u64 *sptep;
struct rmap_iterator iter;
@@ -1515,7 +1517,7 @@ static void kvm_mmu_write_protect_pt_masked(struct kvm
*kvm,
while (mask) {
rmap_head = __gfn_to_rmap(slot->base_gfn + gfn_offset +
__ffs(mask),
PT_PAGE_TABLE_LEVEL, slot);
- __rmap_write_protect(kvm, rmap_head, false);
+ __rmap_write_protect(kvm, rmap_head, false, NULL);
/* clear the first set bit */
mask &= mask - 1;
@@ -1541,7 +1543,7 @@ void kvm_mmu_clear_dirty_pt_masked(struct kvm *kvm,
while (mask) {
rmap_head = __gfn_to_rmap(slot->base_gfn + gfn_offset +
__ffs(mask),
PT_PAGE_TABLE_LEVEL, slot);
- __rmap_clear_dirty(kvm, rmap_head);
+ __rmap_clear_dirty(kvm, rmap_head, NULL);
/* clear the first set bit */
mask &= mask - 1;
@@ -1594,7 +1596,8 @@ bool kvm_mmu_slot_gfn_write_protect(struct kvm *kvm,
for (i = PT_PAGE_TABLE_LEVEL; i <= PT_MAX_HUGEPAGE_LEVEL; ++i) {
rmap_head = __gfn_to_rmap(gfn, i, slot);
- write_protected |= __rmap_write_protect(kvm, rmap_head, true);
+ write_protected |= __rmap_write_protect(kvm, rmap_head, true,
+ NULL);
}
return write_protected;
@@ -1608,7 +1611,8 @@ static bool rmap_write_protect(struct kvm_vcpu *vcpu, u64
gfn)
return kvm_mmu_slot_gfn_write_protect(vcpu->kvm, slot, gfn);
}
-static bool kvm_zap_rmapp(struct kvm *kvm, struct kvm_rmap_head *rmap_head)
+static bool kvm_zap_rmapp(struct kvm *kvm, struct kvm_rmap_head *rmap_head,
+ void *data)
{
u64 *sptep;
struct rmap_iterator iter;
@@ -1628,7 +1632,7 @@ static int kvm_unmap_rmapp(struct kvm *kvm, struct
kvm_rmap_head *rmap_head,
struct kvm_memory_slot *slot, gfn_t gfn, int level,
unsigned long data)
{
- return kvm_zap_rmapp(kvm, rmap_head);
+ return kvm_zap_rmapp(kvm, rmap_head, NULL);
}
static int kvm_set_pte_rmapp(struct kvm *kvm, struct kvm_rmap_head *rmap_head,
@@ -5086,13 +5090,15 @@ void kvm_mmu_uninit_vm(struct kvm *kvm)
}
/* The return value indicates if tlb flush on all vcpus is needed. */
-typedef bool (*slot_level_handler) (struct kvm *kvm, struct kvm_rmap_head
*rmap_head);
+typedef bool (*slot_level_handler) (struct kvm *kvm,
+ struct kvm_rmap_head *rmap_head, void *data);
/* The caller should hold mmu-lock before calling this function. */
static __always_inline bool
slot_handle_level_range(struct kvm *kvm, struct kvm_memory_slot *memslot,
slot_level_handler fn, int start_level, int end_level,
- gfn_t start_gfn, gfn_t end_gfn, bool lock_flush_tlb)
+ gfn_t start_gfn, gfn_t end_gfn, bool lock_flush_tlb,
+ void *data)
{
struct slot_rmap_walk_iterator iterator;
bool flush = false;
@@ -5100,7 +5106,7 @@ slot_handle_level_range(struct kvm *kvm, struct
kvm_memory_slot *memslot,
for_each_slot_rmap_range(memslot, start_level, end_level, start_gfn,
end_gfn, )
[Xen-devel] [libvirt test] 125428: regressions - FAIL
flight 125428 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/125428/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 123814 build-i386-libvirt6 libvirt-buildfail REGR. vs. 123814 build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 123814 build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 123814 Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a version targeted for testing: libvirt 359b938b8b37254e3e714a2a50e4b9a444516133 baseline version: libvirt 076a2b409667dd9f716a2a2085e1ffea9d58fe8b Last test of basis 123814 2018-06-05 04:19:23 Z 45 days Failing since123840 2018-06-06 04:19:28 Z 44 days 33 attempts Testing same since 125428 2018-07-19 12:36:15 Z1 days1 attempts People who touched revisions under test: Ales Musil Andrea Bolognani Anya Harter Bjoern Walk Bobo Du Boris Fiuczynski Brijesh Singh Changkuo Shi Chen Hanxiao Christian Ehrhardt Cole Robinson Daniel Nicoletti Daniel P. Berrangé Daniel Veillard Eric Blake Erik Skultety Fabiano Fidêncio Filip Alac Han Han intrigeri intrigeri Jamie Strandboge Jie Wang Jiri Denemark John Ferlan Julio Faracco Ján Tomko Kashyap Chamarthy Katerina Koukiou Laine Stump Laszlo Ersek Luyao Huang Marc Hartmayer Marcos Paulo de Souza Martin Kletzander Michal Privoznik Michal Prívozník Nikolay Shirokovskiy Pavel Hrdina Peter Krempa Pino Toscano Radostin Stoyanov Ramy Elkest ramyelkest Richard W.M. Jones Roman Bogorodskiy Shichangkuo Simon Kobyda Stefan Bader Stefan Berger Sukrit Bhatnagar Tomáš Golembiovský w00251574 Weilun Zhu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt fail build-arm64-libvirt fail build-armhf-libvirt fail build-i386-libvirt fail build-amd64-pvopspass build-arm64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked test-amd64-amd64-libvirt-xsm blocked test-arm64-arm64-libvirt-xsm blocked test-amd64-i386-libvirt-xsm blocked test-amd64-amd64-libvirt blocked test-arm64-arm64-libvirt blocked test-armhf-armhf-libvirt blocked test-amd64-i386-libvirt blocked test-amd64-amd64-libvirt-pairblocked test-amd64-i386-libvirt-pair blocked test-arm64-arm64-libvirt-qcow2 blocked
[Xen-devel] [PATCH] xenconsole: add option to avoid escape sequences in log
Add --replace-escape, -e option to xenconsoled, which replaces ESC with
'.' in console output written to log file. This makes it slightly safer
to do tail -f on a console output of untrusted guest.
The pty output is unaffected by this option.
Signed-off-by: Marek Marczykowski-Górecki
---
Is there any more documentation to be updated? I didn't found
xenconsoled man page or such.
---
tools/console/daemon/io.c | 18 ++
tools/console/daemon/main.c | 9 +++--
2 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/tools/console/daemon/io.c b/tools/console/daemon/io.c
index e22009aa39..c8280e0b7c 100644
--- a/tools/console/daemon/io.c
+++ b/tools/console/daemon/io.c
@@ -68,6 +68,7 @@ extern int log_time_hv;
extern int log_time_guest;
extern char *log_dir;
extern int discard_overflowed_data;
+extern int replace_escape;
static int log_time_hv_needts = 1;
static int log_time_guest_needts = 1;
@@ -227,8 +228,25 @@ static inline int console_iter_int_arg3(struct domain *d,
return ret;
}
+static void do_replace_escape(const char *buf, char *dest, int len) {
+ int i;
+
+ memcpy(dest, buf, len);
+ for (i = 0; i < len; i++) {
+ if (dest[i] == '\033')
+ dest[i] = '.';
+ }
+}
+
static int write_all(int fd, const char* buf, size_t len)
{
+ char buf_replaced[len];
+
+ if (replace_escape) {
+ do_replace_escape(buf, buf_replaced, len);
+ buf = buf_replaced;
+ }
+
while (len) {
ssize_t ret = write(fd, buf, len);
if (ret == -1 && errno == EINTR)
diff --git a/tools/console/daemon/main.c b/tools/console/daemon/main.c
index 806d2fd611..b716e38c27 100644
--- a/tools/console/daemon/main.c
+++ b/tools/console/daemon/main.c
@@ -40,6 +40,7 @@ int log_time_hv = 0;
int log_time_guest = 0;
char *log_dir = NULL;
int discard_overflowed_data = 1;
+int replace_escape = 0;
static void handle_hup(int sig)
{
@@ -48,7 +49,7 @@ static void handle_hup(int sig)
static void usage(char *name)
{
- printf("Usage: %s [-h] [-V] [-v] [-i] [--log=none|guest|hv|all]
[--log-dir=DIR] [--pid-file=PATH] [-t, --timestamp=none|guest|hv|all] [-o,
--overflow-data=discard|keep]\n", name);
+ printf("Usage: %s [-h] [-V] [-v] [-i] [--log=none|guest|hv|all]
[--log-dir=DIR] [--pid-file=PATH] [-t, --timestamp=none|guest|hv|all] [-o,
--overflow-data=discard|keep] [-e, --replace-escape]\n", name);
}
static void version(char *name)
@@ -93,7 +94,7 @@ static void increase_fd_limit(void)
int main(int argc, char **argv)
{
- const char *sopts = "hVvit:o:";
+ const char *sopts = "hVvit:o:e";
struct option lopts[] = {
{ "help", 0, 0, 'h' },
{ "version", 0, 0, 'V' },
@@ -104,6 +105,7 @@ int main(int argc, char **argv)
{ "pid-file", 1, 0, 'p' },
{ "timestamp", 1, 0, 't' },
{ "overflow-data", 1, 0, 'o'},
+ { "replace-escape", 0, 0, 'e'},
{ 0 },
};
bool is_interactive = false;
@@ -168,6 +170,9 @@ int main(int argc, char **argv)
discard_overflowed_data = 1;
}
break;
+ case 'e':
+ replace_escape = 1;
+ break;
case '?':
fprintf(stderr,
"Try `%s --help' for more information\n",
--
2.17.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] mm, oom: distinguish blockable mode for mmu notifiers
On Mon, 16 Jul 2018 13:50:58 +0200 Michal Hocko wrote:
> From: Michal Hocko
>
> There are several blockable mmu notifiers which might sleep in
> mmu_notifier_invalidate_range_start and that is a problem for the
> oom_reaper because it needs to guarantee a forward progress so it cannot
> depend on any sleepable locks.
>
> ...
>
> @@ -571,7 +565,12 @@ static bool oom_reap_task_mm(struct task_struct *tsk,
> struct mm_struct *mm)
>
> trace_start_task_reaping(tsk->pid);
>
> - __oom_reap_task_mm(mm);
> + /* failed to reap part of the address space. Try again later */
> + if (!__oom_reap_task_mm(mm)) {
> + up_read(>mmap_sem);
> + ret = false;
> + goto unlock_oom;
> + }
This function is starting to look a bit screwy.
: static bool oom_reap_task_mm(struct task_struct *tsk, struct mm_struct *mm)
: {
: if (!down_read_trylock(>mmap_sem)) {
: trace_skip_task_reaping(tsk->pid);
: return false;
: }
:
: /*
:* MMF_OOM_SKIP is set by exit_mmap when the OOM reaper can't
:* work on the mm anymore. The check for MMF_OOM_SKIP must run
:* under mmap_sem for reading because it serializes against the
:* down_write();up_write() cycle in exit_mmap().
:*/
: if (test_bit(MMF_OOM_SKIP, >flags)) {
: up_read(>mmap_sem);
: trace_skip_task_reaping(tsk->pid);
: return true;
: }
:
: trace_start_task_reaping(tsk->pid);
:
: /* failed to reap part of the address space. Try again later */
: if (!__oom_reap_task_mm(mm)) {
: up_read(>mmap_sem);
: return true;
: }
:
: pr_info("oom_reaper: reaped process %d (%s), now anon-rss:%lukB,
file-rss:%lukB, shmem-rss:%lukB\n",
: task_pid_nr(tsk), tsk->comm,
: K(get_mm_counter(mm, MM_ANONPAGES)),
: K(get_mm_counter(mm, MM_FILEPAGES)),
: K(get_mm_counter(mm, MM_SHMEMPAGES)));
: up_read(>mmap_sem);
:
: trace_finish_task_reaping(tsk->pid);
: return true;
: }
- Undocumented return value.
- comment "failed to reap part..." is misleading - sounds like it's
referring to something which happened in the past, is in fact
referring to something which might happen in the future.
- fails to call trace_finish_task_reaping() in one case
- code duplication.
I'm thinking it wants to be something like this?
: /*
: * Return true if we successfully acquired (then released) mmap_sem
: */
: static bool oom_reap_task_mm(struct task_struct *tsk, struct mm_struct *mm)
: {
: if (!down_read_trylock(>mmap_sem)) {
: trace_skip_task_reaping(tsk->pid);
: return false;
: }
:
: /*
:* MMF_OOM_SKIP is set by exit_mmap when the OOM reaper can't
:* work on the mm anymore. The check for MMF_OOM_SKIP must run
:* under mmap_sem for reading because it serializes against the
:* down_write();up_write() cycle in exit_mmap().
:*/
: if (test_bit(MMF_OOM_SKIP, >flags)) {
: trace_skip_task_reaping(tsk->pid);
: goto out;
: }
:
: trace_start_task_reaping(tsk->pid);
:
: if (!__oom_reap_task_mm(mm)) {
: /* Failed to reap part of the address space. Try again later */
: goto finish;
: }
:
: pr_info("oom_reaper: reaped process %d (%s), now anon-rss:%lukB,
file-rss:%lukB, shmem-rss:%lukB\n",
: task_pid_nr(tsk), tsk->comm,
: K(get_mm_counter(mm, MM_ANONPAGES)),
: K(get_mm_counter(mm, MM_FILEPAGES)),
: K(get_mm_counter(mm, MM_SHMEMPAGES)));
: finish:
: trace_finish_task_reaping(tsk->pid);
: out:
: up_read(>mmap_sem);
: return true;
: }
- Increases mmap_sem hold time a little by moving
trace_finish_task_reaping() inside the locked region. So sue me ;)
- Sharing the finish: path means that the trace event won't
distinguish between the two sources of finishing.
Please take a look?
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-4.9-testing test] 125416: regressions - FAIL
flight 125416 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/125416/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stopfail REGR. vs. 124248 test-amd64-amd64-libvirt-pair 23 guest-migrate/dst_host/src_host fail in 125253 REGR. vs. 124328 Tests which are failing intermittently (not blocking): test-arm64-arm64-xl-credit2 7 xen-boot fail in 125171 pass in 125416 test-amd64-amd64-xl-qemut-debianhvm-amd64 7 xen-boot fail in 125253 pass in 125416 test-amd64-amd64-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail pass in 125144 test-amd64-amd64-xl-qemut-debianhvm-amd64 10 debian-hvm-install fail pass in 125171 test-amd64-i386-libvirt-xsm 10 debian-install fail pass in 125171 test-amd64-i386-xl-raw 10 debian-di-install fail pass in 125171 test-amd64-amd64-libvirt-pair 22 guest-migrate/src_host/dst_host fail pass in 125253 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail in 125144 like 124328 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail in 125144 like 124328 test-amd64-i386-libvirt-xsm 13 migrate-support-check fail in 125144 never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail in 125171 blocked in 124328 test-amd64-i386-xl-qemuu-ws16-amd64 18 guest-start/win.repeat fail in 125171 blocked in 124328 test-amd64-i386-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail in 125171 like 124328 test-amd64-amd64-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail in 125253 like 124328 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail in 125253 like 124328 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 125253 like 124328 test-amd64-i386-libvirt-pair 22 guest-migrate/src_host/dst_host fail like 124248 test-amd64-amd64-xl-qemuu-ws16-amd64 14 guest-localmigratefail like 124248 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 124248 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 124248 test-amd64-i386-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail like 124248 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 124328 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 124328 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 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-amd64-amd64-libvirt 13 migrate-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-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-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-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-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 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-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-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-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
Re: [Xen-devel] [PATCH] mm, oom: distinguish blockable mode for mmu notifiers
On Tue, 17 Jul 2018 10:12:01 +0200 Michal Hocko wrote: > > Any suggestions regarding how the driver developers can test this code > > path? I don't think we presently have a way to fake an oom-killing > > event? Perhaps we should add such a thing, given the problems we're > > having with that feature. > > The simplest way is to wrap an userspace code which uses these notifiers > into a memcg and set the hard limit to hit the oom. This can be done > e.g. after the test faults in all the mmu notifier managed memory and > set the hard limit to something really small. Then we are looking for a > proper process tear down. Chances are, some of the intended audience don't know how to do this and will either have to hunt down a lot of documentation or will just not test it. But we want them to test it, so a little worked step-by-step example would help things along please. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xtf test] 125478: all pass - PUSHED
flight 125478 xtf real [real] http://logs.test-lab.xenproject.org/osstest/logs/125478/ Perfect :-) All tests in this flight passed as required version targeted for testing: xtf f3702a5d29e94814991988bf8747341e18a2e8f5 baseline version: xtf e4007918fa9a4edaa3a649ecc34ac54831750a68 Last test of basis 124222 2018-06-15 15:10:30 Z 35 days Testing same since 125478 2018-07-20 13:10:54 Z0 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 e400791..f3702a5 f3702a5d29e94814991988bf8747341e18a2e8f5 -> xen-tested-master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] firmware/shim : filter output files during Xen tree setup
Exclude named output files from the Xen tree setup. The linkfarm.stamp content will differ between top level "make" and "make install" invocations, due to the introduction of these output files that are produced during the "make" build. Filter these out to prevent an unnecessary rebuild of the shim during "make install". Signed-off-by: Christopher Clark --- tools/firmware/xen-dir/Makefile | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/tools/firmware/xen-dir/Makefile b/tools/firmware/xen-dir/Makefile index 84648c3..e490dca 100644 --- a/tools/firmware/xen-dir/Makefile +++ b/tools/firmware/xen-dir/Makefile @@ -11,6 +11,9 @@ D=xen-root LINK_DIRS=config xen LINK_FILES=Config.mk +# Files to exclude from the link farm +EXCLUDE_FILES=xen xen.gz xen-syms xen-syms.map efi.lds xen.lds mkelf32 mkreloc + DEP_DIRS=$(foreach i, $(LINK_DIRS), $(XEN_ROOT)/$(i)) DEP_FILES=$(foreach i, $(LINK_FILES), $(XEN_ROOT)/$(i)) @@ -26,7 +29,8 @@ linkfarm.stamp: $(DEP_DIRS) $(DEP_FILES) FORCE $(foreach d, $(LINK_DIRS), \ (cd $(XEN_ROOT); \ find $(d) ! -type l -type f \ -$(addprefix ! -name , '*.[isoa]' '.*.d' '.*.d2')) \ +$(addprefix ! -name , '*.[isoa]' '.*.d' '.*.d2' \ + $(EXCLUDE_FILES) )) \ >> linkfarm.stamp.tmp ; ) \ $(foreach f, $(LINK_FILES), \ echo $(f) >> linkfarm.stamp.tmp ;) -- 2.7.4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [qemu-mainline test] 125410: regressions - FAIL
flight 125410 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/125410/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl 10 debian-install fail REGR. vs. 125169 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qcow217 guest-localmigrate/x10 fail pass in 125287 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail pass in 125287 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stopfail in 125287 never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 125169 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 125169 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 125169 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 125169 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 125169 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-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-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 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-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-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 13 migrate-support-checkfail never pass test-armhf-armhf-xl 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-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-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 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-armhf-armhf-libvirt-raw 12 migrate-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-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass version targeted for testing: qemuuea6abffa8a08d832feb759d359d5b935e3087cf7 baseline version: qemuu9277d81f5c2c6f4d0b5e47c8476eb7ee7e5c0beb Last test of basis 125169 2018-07-14 20:30:43 Z6 days Failing since125246 2018-07-16 15:53:25 Z4 days3 attempts Testing same since 125287 2018-07-17 23:08:06 Z2 days2 attempts People who touched revisions under test: Alex Bennée Andrew Jeffery BALATON Zoltan Calvin Lee Daniel P. Berrangé David Gibson Eduardo Habkost Emanuele Giuseppe Esposito Greg Kurz Guenter Roeck Igor Mammedov Jonas Schievink Laurent Vivier Marc-André Lureau Marc-André Lureau Markus Armbruster Michael Davidsaver Michael Roth Paolo Bonzini Peter Maydell Richard Henderson Roman Kagan Shivaprasad G Bhat Stefan Hajnoczi Stefan Weil Thomas Huth Viktor Prutyanov jobs: build-amd64-xsm pass build-arm64-xsm pass
[Xen-devel] [linux-linus test] 125401: regressions - FAIL
flight 125401 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/125401/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-libvirt-xsm 12 guest-start fail REGR. vs. 123554 test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 123554 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 123554 test-amd64-amd64-xl-qcow210 debian-di-installfail REGR. vs. 123554 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 123554 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 123554 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 123554 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 123554 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 123554 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 123554 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 123554 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 123554 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-amd64-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-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail 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-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-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 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-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 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-libvirt 13 migrate-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-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-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-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-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-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 version targeted for testing: linux05df204549c510c7c56e58d25098c448998a0cd5 baseline version: linux0512e0134582ef85dee77d51aae77dcd1edec495 Last test of basis 123554 2018-06-01 13:09:41 Z 49 days Failing since123655 2018-06-03 01:45:35 Z 47 days 28 attempts Testing same since 125401 2018-07-19 02:51:29 Z1 days1 attempts 2254 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm
Re: [Xen-devel] [PATCH V5] x86/altp2m: Fix crash with INVALID_ALTP2M EPTP index
On 07/20/2018 08:18 PM, George Dunlap wrote: > Furthermore, imagine the following scenario: > > * dom0 enables altp2m on domain A > * dom0 switches altp2m to view 1 on domain A > * dom0 enables #VE on domain A > * domain A has a vmexit > -> At this point, EPTP_INDEX is 0, so the vmexit code will drop a > reference on altp2m index 1 and increase the reference count on altp2m > index 0 # > > My patch fixes the above issue, but your patch doesn't (AFAICT). What > altp2m_vcpu_destroy() did wasn't fundamentally buggy; it just > highlighted the issue by doing the equivalent of putting 0xDEADBEEF in > EPTP_INDEX; and what your patch did was to reverse that, by making > EPTP_INDEX accidentally correct again the next time you ran your test. > > (Let me know if I'm wrong about that!) I do prefer your patch, but unless I'm missing something my patch is doing the same thing (albeit in a slightly more convoluted manner): it's calling altp2m_vcpu_update_p2m(v) _inside_ altp2m_vcpu_update_vmfunc_ve(v). That's all it does, other than removing the (now redundant) explicit altp2m_vcpu_update_p2m(v) call from altp2m_vcpu_destroy(): https://lists.xenproject.org/archives/html/xen-devel/2018-06/msg01898.html So for every hvm_funcs.altp2m_vcpu_update_vmfunc_ve(v) (i.e. the vmx.c function) that gets called, I also call altp2m_vcpu_update_p2m(v), which properly sets EPTP_INDEX (just as your patch does by __vmwrite()ing it directly in vmx_vcpu_update_vmfunc_ve(), but in a roundabout manner). Did I misunderstand something? Thanks, Razvan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH V5] x86/altp2m: Fix crash with INVALID_ALTP2M EPTP index
On 07/20/2018 05:29 PM, Razvan Cojocaru wrote: > On 07/20/2018 06:07 PM, George Dunlap wrote: >> On 06/28/2018 03:35 PM, Razvan Cojocaru wrote: >>> A VM exit handler executed immediately after enabling #VE might >>> find a stale __vmsave()d EPTP_INDEX, stored by calling >>> altp2m_vcpu_destroy() when SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS >>> had been enabled by altp2m_vcpu_update_vmfunc_ve(). >>> >>> vmx_vmexit_handler() __vmread()s EPTP_INDEX as soon as >>> SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS is set, so if an >>> application enables altp2m on a domain, succesfully calls >>> xc_altp2m_set_vcpu_enable_notify(), then disables altp2m and >>> exits, a second run of said application will likely read the >>> INVALID_ALTP2M EPTP_INDEX set when disabling altp2m in the first >>> run, and crash the host with the BUG_ON(idx >= MAX_ALTP2M), >>> between xc_altp2m_set_vcpu_enable_notify() and >>> xc_altp2m_set_domain_state(..., false). >>> >>> The problem is not restricted to an INVALID_ALTP2M EPTP_INDEX >>> (which can only sanely happen on altp2m uninit), but applies >>> to any stale index previously saved - which means that all >>> altp2m_vcpu_update_vmfunc_ve() calls must also call >>> altp2m_vcpu_update_p2m() after setting >>> SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS, in order to make sure >>> that the stored EPTP_INDEX is always valid at >>> vmx_vmexit_handler() time. >> >> I'm sorry, this description still doesn't make hardly any sense to me, >> nor the solution, even after reading all the previous threads on the >> issue. The description doesn't, for instance, mention vcpu_pause() at >> all, in spite of the fact that it seems (from the previous discussion) >> that this is a critical part of why this solution works; nor is there >> any comment in the code about the required discipline regarding >> SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS, making it fairly likely that >> someone will re-introduce a bug like this in the future. >> >> My normal template for something like this is >> 1. Explain what the current situation is >> 2. Explain why that's a problem >> 3. Describe what you're changing and how it fixes it. >> >> I can't help but think the right thing to do here is in vmx.c somewhere >> -- it is, after all, code in vmx.c that: >> 1. Sets and clears SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS >> 2. Writes EPTP_INDEX >> 3. Assumes that SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS => EPTP_INDEX is >> valid. >> >> What about something like the attached, instead (compile-tested only)? > George, thanks for the review, comments and new patch! You're the third > person telling me that the patch description is hard to parse - I'll > definitely work on that skill in the future (and sorry for the > inconvenience). No worries -- everything here is a bit of a tangled mess. > The vcpu_pause() lead was a red herring in my initial investigation of > the issue, and that is the reason why it didn't make it into the patch > description. The pausing already done is fine. > > I've tested your patch on my system (where I can reproduce the crash > with a 100% reproduction rate without it), and I've had no crashes - so > it does seem to have fixed the problem. Thinking about the crash path, > it also makes sense that it would fix the problem - I can't think of any > objections to it. > > Let me try the explanation again: > > The current situation: when we run twice an altp2m client application > which uses altp2m_vcpu_update_vmfunc_ve() (it _has_ to be twice), the > following happens: after the first run of the application, > altp2m_vcpu_destroy() gets called as part of the cleanup process, and > this stores INVALID_ALTP2M EPTP_INDEX in the VMCS. Right, I meant, the current situation in terms of the way the code in Xen / the processor currently behaves / what it expects. I tried to follow that pattern in my own patch. The key to the whole bug is this: * vmx_vmexit_handler() assumes that is VIRT_EXCEPTION is set, that EPTP_INDEX is valid Once you state it that way, you realize, OK that's false. But why is it false? * Because VIRT_EXCEPTION is enabled without touching EPTP_INDEX That's the core problem. That description by itself should make anyone go, "Yeah, that will be a a problem." The details of how that can go wrong is just icing on the cake / grep fodder for people looking for how to fix their own problem. The reason this ever worked, AFAICT, is that EPTP_INDEX was accidentally correct. If we'd initialized EPTP_INDEX with 0xDEADBEEF on VMCS creation, then you also would have hit the bug. (In fact, that might not be a bad idea.) Furthermore, imagine the following scenario: * dom0 enables altp2m on domain A * dom0 switches altp2m to view 1 on domain A * dom0 enables #VE on domain A * domain A has a vmexit -> At this point, EPTP_INDEX is 0, so the vmexit code will drop a reference on altp2m index 1 and increase the reference count on altp2m index 0 # My patch fixes the above issue, but your patch doesn't (AFAICT). What
Re: [Xen-devel] [PATCH net-next] xen-netfront: fix queue name setting
On 07/20/2018 05:33 PM, Vitaly Kuznetsov wrote:
Commit f599c64fdf7d ("xen-netfront: Fix race between device setup and
open") changed the initialization order: xennet_create_queues() now
happens before we do register_netdev() so using netdev->name in
xennet_init_queue() is incorrect, we end up with the following in
/proc/interrupts:
60:139 0 xen-dyn-event eth%d-q0-tx
61:265 0 xen-dyn-event eth%d-q0-rx
62:234 0 xen-dyn-event eth%d-q1-tx
63: 1 0 xen-dyn-event eth%d-q1-rx
and this looks ugly. Actually, using early netdev name (even when it's
already set) is also not ideal: nowadays we tend to rename eth devices
and queue name may end up not corresponding to the netdev name.
Use nodename from xenbus device for queue naming: this can't change in VM's
lifetime. Now /proc/interrupts looks like
62:202 0 xen-dyn-event device/vif/0-q0-tx
63:317 0 xen-dyn-event device/vif/0-q0-rx
64:262 0 xen-dyn-event device/vif/0-q1-tx
65: 17 0 xen-dyn-event device/vif/0-q1-rx
Fixes: f599c64fdf7d ("xen-netfront: Fix race between device setup and open")
Signed-off-by: Vitaly Kuznetsov
---
Reviewed-by: Ross Lagerwall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH net-next] xen-netfront: fix queue name setting
Commit f599c64fdf7d ("xen-netfront: Fix race between device setup and
open") changed the initialization order: xennet_create_queues() now
happens before we do register_netdev() so using netdev->name in
xennet_init_queue() is incorrect, we end up with the following in
/proc/interrupts:
60:139 0 xen-dyn-event eth%d-q0-tx
61:265 0 xen-dyn-event eth%d-q0-rx
62:234 0 xen-dyn-event eth%d-q1-tx
63: 1 0 xen-dyn-event eth%d-q1-rx
and this looks ugly. Actually, using early netdev name (even when it's
already set) is also not ideal: nowadays we tend to rename eth devices
and queue name may end up not corresponding to the netdev name.
Use nodename from xenbus device for queue naming: this can't change in VM's
lifetime. Now /proc/interrupts looks like
62:202 0 xen-dyn-event device/vif/0-q0-tx
63:317 0 xen-dyn-event device/vif/0-q0-rx
64:262 0 xen-dyn-event device/vif/0-q1-tx
65: 17 0 xen-dyn-event device/vif/0-q1-rx
Fixes: f599c64fdf7d ("xen-netfront: Fix race between device setup and open")
Signed-off-by: Vitaly Kuznetsov
---
drivers/net/xen-netfront.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index a57daecf1d57..1b40b648ed5c 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1604,7 +1604,7 @@ static int xennet_init_queue(struct netfront_queue *queue)
timer_setup(>rx_refill_timer, rx_refill_timeout, 0);
snprintf(queue->name, sizeof(queue->name), "%s-q%u",
-queue->info->netdev->name, queue->id);
+queue->info->xbdev->nodename, queue->id);
/* Initialise tx_skbs as a free chain containing every entry. */
queue->tx_skb_freelist = 0;
--
2.14.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH V5] x86/altp2m: Fix crash with INVALID_ALTP2M EPTP index
On 07/20/2018 06:07 PM, George Dunlap wrote:
> On 06/28/2018 03:35 PM, Razvan Cojocaru wrote:
>> A VM exit handler executed immediately after enabling #VE might
>> find a stale __vmsave()d EPTP_INDEX, stored by calling
>> altp2m_vcpu_destroy() when SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS
>> had been enabled by altp2m_vcpu_update_vmfunc_ve().
>>
>> vmx_vmexit_handler() __vmread()s EPTP_INDEX as soon as
>> SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS is set, so if an
>> application enables altp2m on a domain, succesfully calls
>> xc_altp2m_set_vcpu_enable_notify(), then disables altp2m and
>> exits, a second run of said application will likely read the
>> INVALID_ALTP2M EPTP_INDEX set when disabling altp2m in the first
>> run, and crash the host with the BUG_ON(idx >= MAX_ALTP2M),
>> between xc_altp2m_set_vcpu_enable_notify() and
>> xc_altp2m_set_domain_state(..., false).
>>
>> The problem is not restricted to an INVALID_ALTP2M EPTP_INDEX
>> (which can only sanely happen on altp2m uninit), but applies
>> to any stale index previously saved - which means that all
>> altp2m_vcpu_update_vmfunc_ve() calls must also call
>> altp2m_vcpu_update_p2m() after setting
>> SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS, in order to make sure
>> that the stored EPTP_INDEX is always valid at
>> vmx_vmexit_handler() time.
>
> I'm sorry, this description still doesn't make hardly any sense to me,
> nor the solution, even after reading all the previous threads on the
> issue. The description doesn't, for instance, mention vcpu_pause() at
> all, in spite of the fact that it seems (from the previous discussion)
> that this is a critical part of why this solution works; nor is there
> any comment in the code about the required discipline regarding
> SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS, making it fairly likely that
> someone will re-introduce a bug like this in the future.
>
> My normal template for something like this is
> 1. Explain what the current situation is
> 2. Explain why that's a problem
> 3. Describe what you're changing and how it fixes it.
>
> I can't help but think the right thing to do here is in vmx.c somewhere
> -- it is, after all, code in vmx.c that:
> 1. Sets and clears SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS
> 2. Writes EPTP_INDEX
> 3. Assumes that SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS => EPTP_INDEX is
> valid.
>
> What about something like the attached, instead (compile-tested only)?
George, thanks for the review, comments and new patch! You're the third
person telling me that the patch description is hard to parse - I'll
definitely work on that skill in the future (and sorry for the
inconvenience).
The vcpu_pause() lead was a red herring in my initial investigation of
the issue, and that is the reason why it didn't make it into the patch
description. The pausing already done is fine.
I've tested your patch on my system (where I can reproduce the crash
with a 100% reproduction rate without it), and I've had no crashes - so
it does seem to have fixed the problem. Thinking about the crash path,
it also makes sense that it would fix the problem - I can't think of any
objections to it.
Let me try the explanation again:
The current situation: when we run twice an altp2m client application
which uses altp2m_vcpu_update_vmfunc_ve() (it _has_ to be twice), the
following happens: after the first run of the application,
altp2m_vcpu_destroy() gets called as part of the cleanup process, and
this stores INVALID_ALTP2M EPTP_INDEX in the VMCS.
altp2m_vcpu_destroy() is what saves INVALID_ALTP2M after the first run
of the client application:
48 void
49 altp2m_vcpu_destroy(struct vcpu *v)
50 {
51 struct p2m_domain *p2m;
52
53 if ( v != current )
54 vcpu_pause(v);
55
56 if ( (p2m = p2m_get_altp2m(v)) )
57 atomic_dec(>active_vcpus);
58
59 altp2m_vcpu_reset(v);
60
61 altp2m_vcpu_update_p2m(v);
62 altp2m_vcpu_update_vmfunc_ve(v);
63
64 if ( v != current )
65 vcpu_unpause(v);
66 }
altp2m_vcpu_reset(v) sets av->p2midx = INVALID_ALTP2M, then
altp2m_vcpu_update_p2m(v) saves it.
The _second_ run of the application then calls
altp2m_vcpu_update_vmfunc_ve() again. At this point, EPTP_INDEX ==
INVALID_ALTP2M, and vmx_vcpu_update_vmfunc_ve() only sets
SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS (but _not_ EPTP_INDEX also, as
your patch now does). The only function that updates EPTP_INDEX is
vmx_vcpu_update_eptp() - so altp2m_vcpu_update_p2m(v) in my patch.
The pausing is fine, but altp2m_vcpu_update_vmfunc_ve() did not save
EPTP_INDEX.
altp2m_vcpu_update_p2m(v) is called in only 4 places now:
p2m_switch_domain_altp2m_by_id(), p2m_switch_vcpu_altp2m_by_id(),
altp2m_vcpu_initialise() and altp2m_vcpu_destroy().
So at the time of the second run of the application, EPTP_INDEX is still
INVALID_ALTP2M, and vmx_vcpu_update_vmfunc_ve() does nothing about it.
At this point, the first call of vmx_vmexit_handler() will find
SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS set and will try to work
Re: [Xen-devel] [PATCH V5] x86/altp2m: Fix crash with INVALID_ALTP2M EPTP index
On 06/28/2018 03:35 PM, Razvan Cojocaru wrote:
> A VM exit handler executed immediately after enabling #VE might
> find a stale __vmsave()d EPTP_INDEX, stored by calling
> altp2m_vcpu_destroy() when SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS
> had been enabled by altp2m_vcpu_update_vmfunc_ve().
>
> vmx_vmexit_handler() __vmread()s EPTP_INDEX as soon as
> SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS is set, so if an
> application enables altp2m on a domain, succesfully calls
> xc_altp2m_set_vcpu_enable_notify(), then disables altp2m and
> exits, a second run of said application will likely read the
> INVALID_ALTP2M EPTP_INDEX set when disabling altp2m in the first
> run, and crash the host with the BUG_ON(idx >= MAX_ALTP2M),
> between xc_altp2m_set_vcpu_enable_notify() and
> xc_altp2m_set_domain_state(..., false).
>
> The problem is not restricted to an INVALID_ALTP2M EPTP_INDEX
> (which can only sanely happen on altp2m uninit), but applies
> to any stale index previously saved - which means that all
> altp2m_vcpu_update_vmfunc_ve() calls must also call
> altp2m_vcpu_update_p2m() after setting
> SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS, in order to make sure
> that the stored EPTP_INDEX is always valid at
> vmx_vmexit_handler() time.
I'm sorry, this description still doesn't make hardly any sense to me,
nor the solution, even after reading all the previous threads on the
issue. The description doesn't, for instance, mention vcpu_pause() at
all, in spite of the fact that it seems (from the previous discussion)
that this is a critical part of why this solution works; nor is there
any comment in the code about the required discipline regarding
SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS, making it fairly likely that
someone will re-introduce a bug like this in the future.
My normal template for something like this is
1. Explain what the current situation is
2. Explain why that's a problem
3. Describe what you're changing and how it fixes it.
I can't help but think the right thing to do here is in vmx.c somewhere
-- it is, after all, code in vmx.c that:
1. Sets and clears SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS
2. Writes EPTP_INDEX
3. Assumes that SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS => EPTP_INDEX is
valid.
What about something like the attached, instead (compile-tested only)?
-George
From 03c71cda215fd9183a0fe10cb42394d63e3879c5 Mon Sep 17 00:00:00 2001
From: George Dunlap
Date: Fri, 20 Jul 2018 16:04:01 +0100
Subject: [PATCH] x86/altp2m: Make sure EPTP_INDEX is up-to-date when enabling
#VE
vmx_vmexit_handler() assumes that if
SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS is set, that the value in
EPTP_INDEX is valid. Unfortunately, the function which sets this bit
(vmx_vcpu_update_vmfunc_ve) doesn't actually set EPTP_INDEX; it will
only be set the next time vmx_vcpu_update_eptp() is called.
This means that if a vcpu makes a vmexit between these two points, the
EPTP_INDEX it reads will be invalid. The first time this race happens
for a domain, EPTP_INDEX will most likely be zero, which is the index
for the "host" p2m -- and thus is often correct. But the second time
this race happens, the value will typically be INVALID_ALTP2M, which
will hit the following BUG:
BUG_ON(idx >= MAX_ALTP2M);
Worse, if for some reason the current altp2m was *not* `0` during this
window (say, because a toolstack changed the VM to a different view),
then the accounting of active vcpus for an altp2m will be thrown off.
Fix this by always updating EPTP_INDEX to the current altp2m index
when enabling #VE.
Reported-by: Razvan Cojocaru
Signed-off-by: George Dunlap
---
xen/arch/x86/hvm/vmx/vmx.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index bcf95f9a5f..bc25daed2c 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2191,7 +2191,14 @@ static void vmx_vcpu_update_vmfunc_ve(struct vcpu *v)
mfn = get_gfn_query_unlocked(d, gfn_x(vcpu_altp2m(v).veinfo_gfn), );
if ( !mfn_eq(mfn, INVALID_MFN) )
+{
__vmwrite(VIRT_EXCEPTION_INFO, mfn_x(mfn) << PAGE_SHIFT);
+/*
+ * Make sure we have an up-to-date EPTP_INDEX when
+ * setting SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS
+ */
+__vmwrite(EPTP_INDEX, vcpu_altp2m(v).p2midx);
+}
else
v->arch.hvm_vmx.secondary_exec_control &=
~SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS;
--
2.18.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 0/3] SSBD AMD via LS CFG Enablement
This series of patches is for enabling SSBD via the LS_CFG MSR for family 15h-17h. The first patch make it so that the information is correctly displayed on boot. The last two patches are for further enablement for Xen switching SSBD on or off internally, or for further control of SSBD for guests via the VIRT_SPEC_CTRL. Note: these should be applied after Jan's patch: x86/AMD: distinguish compute units from hyper-threads Brian Woods (3): x86/spec-ctrl: add AMD SSBD LS_CFG in init print x86/spec-ctrl: Add defines and variables for AMD SSBD support x86/spec-ctrl: Add support for modifying SSBD AMD VIA LS_CFG MSR xen/arch/x86/cpu/amd.c| 7 +- xen/arch/x86/setup.c | 2 + xen/arch/x86/smpboot.c| 3 + xen/arch/x86/spec_ctrl.c | 218 +- xen/include/asm-x86/cpufeatures.h | 1 + xen/include/asm-x86/spec_ctrl.h | 5 + 6 files changed, 231 insertions(+), 5 deletions(-) -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 2/3] x86/spec-ctrl: Add defines and variables for AMD SSBD support
In preparation for adding switchable SSBD, add some defines and
variables.
Signed-off-by: Brian Woods
---
xen/arch/x86/spec_ctrl.c| 10 ++
xen/include/asm-x86/spec_ctrl.h | 3 +++
2 files changed, 13 insertions(+)
diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
index 62e6519d93..baef907322 100644
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
@@ -50,7 +51,16 @@ bool __initdata bsp_delay_spec_ctrl;
uint8_t __read_mostly default_xen_spec_ctrl;
uint8_t __read_mostly default_spec_ctrl_flags;
+/* for SSBD support for AMD via LS_CFG */
+#define SSBD_AMD_MAX_SOCKET 2
+struct ssbd_amd_ls_cfg_smt_status {
+spinlock_t lock;
+uint32_t mask;
+} __attribute__ ((aligned (64)));
+bool __read_mostly ssbd_amd_smt_en = false;
+bool __read_mostly xen_ssbd_amd_ls_cfg_en = false;
uint64_t __read_mostly ssbd_amd_ls_cfg_mask = 0ull;
+struct ssbd_amd_ls_cfg_smt_status *ssbd_amd_smt_status[SSBD_AMD_MAX_SOCKET] =
{NULL};
static int __init parse_bti(const char *s)
{
diff --git a/xen/include/asm-x86/spec_ctrl.h b/xen/include/asm-x86/spec_ctrl.h
index 6aebfa9e4f..c47647771a 100644
--- a/xen/include/asm-x86/spec_ctrl.h
+++ b/xen/include/asm-x86/spec_ctrl.h
@@ -39,6 +39,9 @@ extern uint8_t opt_xpti;
#define OPT_XPTI_DOMU 0x02
extern uint64_t ssbd_amd_ls_cfg_mask;
+extern bool xen_ssbd_amd_ls_cfg_en;
+extern void ssbd_amd_ls_cfg_init(void);
+extern void ssbd_amd_ls_cfg_set(bool enable_ssbd);
static inline void init_shadow_spec_ctrl_state(void)
{
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 1/3] x86/spec-ctrl: add AMD SSBD LS_CFG in init print
Edit the initialization code for AMD's SSBD via the LS_CFG MSR and
enable it to pass the status to the initial spec-ctrl print_details at
boot.
Signed-off-by: Brian Woods
---
xen/arch/x86/cpu/amd.c| 13 ++---
xen/arch/x86/spec_ctrl.c | 9 +++--
xen/include/asm-x86/cpufeatures.h | 1 +
xen/include/asm-x86/spec_ctrl.h | 2 ++
4 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c
index bad5b43628..06c9e9661b 100644
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -598,7 +598,7 @@ static void init_amd(struct cpuinfo_x86 *c)
* If the user has explicitly chosen to disable Memory Disambiguation
* to mitigiate Speculative Store Bypass, poke the appropriate MSR.
*/
- if (opt_ssbd) {
+ if (!ssbd_amd_ls_cfg_mask) {
int bit = -1;
switch (c->x86) {
@@ -607,8 +607,15 @@ static void init_amd(struct cpuinfo_x86 *c)
case 0x17: bit = 10; break;
}
- if (bit >= 0 && !rdmsr_safe(MSR_AMD64_LS_CFG, value)) {
- value |= 1ull << bit;
+ if (bit >= 0)
+ ssbd_amd_ls_cfg_mask = 1ull << bit;
+ }
+
+ if (ssbd_amd_ls_cfg_mask && !rdmsr_safe(MSR_AMD64_LS_CFG, value)) {
+ if (!boot_cpu_has(X86_FEATURE_SSBD_AMD_LS_CFG))
+ setup_force_cpu_cap(X86_FEATURE_SSBD_AMD_LS_CFG);
+ if (opt_ssbd) {
+ value |= ssbd_amd_ls_cfg_mask;
wrmsr_safe(MSR_AMD64_LS_CFG, value);
}
}
diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
index 08e6784c4c..62e6519d93 100644
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -50,6 +50,8 @@ bool __initdata bsp_delay_spec_ctrl;
uint8_t __read_mostly default_xen_spec_ctrl;
uint8_t __read_mostly default_spec_ctrl_flags;
+uint64_t __read_mostly ssbd_amd_ls_cfg_mask = 0ull;
+
static int __init parse_bti(const char *s)
{
const char *ss;
@@ -210,10 +212,11 @@ static void __init print_details(enum ind_thunk thunk,
uint64_t caps)
printk("Speculative mitigation facilities:\n");
/* Hardware features which pertain to speculative mitigations. */
-printk(" Hardware features:%s%s%s%s%s%s%s%s\n",
+printk(" Hardware features:%s%s%s%s%s%s%s%s%s\n",
(_7d0 & cpufeat_mask(X86_FEATURE_IBRSB)) ? " IBRS/IBPB" : "",
(_7d0 & cpufeat_mask(X86_FEATURE_STIBP)) ? " STIBP" : "",
(_7d0 & cpufeat_mask(X86_FEATURE_SSBD)) ? " SSBD" : "",
+ boot_cpu_has(X86_FEATURE_SSBD_AMD_LS_CFG)? " SSBD" : "",
(e8b & cpufeat_mask(X86_FEATURE_IBPB)) ? " IBPB" : "",
(caps & ARCH_CAPABILITIES_IBRS_ALL) ? " IBRS_ALL" : "",
(caps & ARCH_CAPABILITIES_RDCL_NO) ? " RDCL_NO" : "",
@@ -225,7 +228,7 @@ static void __init print_details(enum ind_thunk thunk,
uint64_t caps)
printk(" Compiled-in support: INDIRECT_THUNK\n");
/* Settings for Xen's protection, irrespective of guests. */
-printk(" Xen settings: BTI-Thunk %s, SPEC_CTRL: %s%s, Other:%s\n",
+printk(" Xen settings: BTI-Thunk %s, SPEC_CTRL: %s%s%s, Other:%s\n",
thunk == THUNK_NONE ? "N/A" :
thunk == THUNK_RETPOLINE ? "RETPOLINE" :
thunk == THUNK_LFENCE? "LFENCE" :
@@ -234,6 +237,8 @@ static void __init print_details(enum ind_thunk thunk,
uint64_t caps)
(default_xen_spec_ctrl & SPEC_CTRL_IBRS) ? "IBRS+" : "IBRS-",
!boot_cpu_has(X86_FEATURE_SSBD) ? "" :
(default_xen_spec_ctrl & SPEC_CTRL_SSBD) ? " SSBD+" : " SSBD-",
+ !boot_cpu_has(X86_FEATURE_SSBD_AMD_LS_CFG)? "" :
+ (opt_ssbd && ssbd_amd_ls_cfg_mask)? " SSBD+" : " SSBD-",
opt_ibpb ? " IBPB" : "");
/*
diff --git a/xen/include/asm-x86/cpufeatures.h
b/xen/include/asm-x86/cpufeatures.h
index b90aa2d046..9383d4058b 100644
--- a/xen/include/asm-x86/cpufeatures.h
+++ b/xen/include/asm-x86/cpufeatures.h
@@ -32,3 +32,4 @@ XEN_CPUFEATURE(SC_RSB_PV, (FSCAPINTS+0)*32+18) /* RSB
overwrite needed for
XEN_CPUFEATURE(SC_RSB_HVM, (FSCAPINTS+0)*32+19) /* RSB overwrite needed
for HVM */
XEN_CPUFEATURE(NO_XPTI, (FSCAPINTS+0)*32+20) /* XPTI mitigation not in
use */
XEN_CPUFEATURE(SC_MSR_IDLE, (FSCAPINTS+0)*32+21) /* (SC_MSR_PV ||
SC_MSR_HVM) && default_xen_spec_ctrl */
+XEN_CPUFEATURE(SSBD_AMD_LS_CFG, (FSCAPINTS+0)*32+22) /* if SSBD support is
enabled via LS_CGF MSR on AMD hardware */
diff --git a/xen/include/asm-x86/spec_ctrl.h b/xen/include/asm-x86/spec_ctrl.h
index 5b40afbab0..6aebfa9e4f 100644
--- a/xen/include/asm-x86/spec_ctrl.h
+++ b/xen/include/asm-x86/spec_ctrl.h
@@ -38,6 +38,8 @@ extern uint8_t opt_xpti;
#define OPT_XPTI_DOM0 0x01
#define OPT_XPTI_DOMU 0x02
[Xen-devel] [PATCH 3/3] x86/spec-ctrl: Add support for modifying SSBD AMD VIA LS_CFG MSR
Adds support for modifying the LS_CFG MSR to enable SSBD on supporting
AMD CPUs. There needs to be locking logic for family 17h with SMT
enabled since both threads share the same MSR. Otherwise, a core just
needs to write to the LS_CFG MSR. For more information see:
https://developer.amd.com/wp-content/resources/124441_AMD64_SpeculativeStoreBypassDisable_Whitepaper_final.pdf
Signed-off-by: Brian Woods
---
xen/arch/x86/cpu/amd.c | 10 +--
xen/arch/x86/setup.c | 2 +
xen/arch/x86/smpboot.c | 3 +
xen/arch/x86/spec_ctrl.c | 201 ++-
4 files changed, 207 insertions(+), 9 deletions(-)
diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c
index 06c9e9661b..e7ec0d99a7 100644
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -607,16 +607,10 @@ static void init_amd(struct cpuinfo_x86 *c)
case 0x17: bit = 10; break;
}
- if (bit >= 0)
- ssbd_amd_ls_cfg_mask = 1ull << bit;
- }
- if (ssbd_amd_ls_cfg_mask && !rdmsr_safe(MSR_AMD64_LS_CFG, value)) {
- if (!boot_cpu_has(X86_FEATURE_SSBD_AMD_LS_CFG))
+ if (bit >= 0 && !rdmsr_safe(MSR_AMD64_LS_CFG, value)) {
+ ssbd_amd_ls_cfg_mask = 1ull << bit;
setup_force_cpu_cap(X86_FEATURE_SSBD_AMD_LS_CFG);
- if (opt_ssbd) {
- value |= ssbd_amd_ls_cfg_mask;
- wrmsr_safe(MSR_AMD64_LS_CFG, value);
}
}
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 419b46c033..b551852cbd 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1579,6 +1579,8 @@ void __init noreturn __start_xen(unsigned long mbi_p)
arch_init_memory();
+ssbd_amd_ls_cfg_init();
+
alternative_instructions();
local_irq_enable();
diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
index d4478e6132..07760c920d 100644
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -366,6 +366,9 @@ void start_secondary(void *unused)
if ( boot_cpu_has(X86_FEATURE_IBRSB) )
wrmsrl(MSR_SPEC_CTRL, default_xen_spec_ctrl);
+if ( xen_ssbd_amd_ls_cfg_en )
+ssbd_amd_ls_cfg_set(true);
+
if ( xen_guest )
hypervisor_ap_setup();
diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
index baef907322..006e8fb14b 100644
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -248,7 +248,7 @@ static void __init print_details(enum ind_thunk thunk,
uint64_t caps)
!boot_cpu_has(X86_FEATURE_SSBD) ? "" :
(default_xen_spec_ctrl & SPEC_CTRL_SSBD) ? " SSBD+" : " SSBD-",
!boot_cpu_has(X86_FEATURE_SSBD_AMD_LS_CFG)? "" :
- (opt_ssbd && ssbd_amd_ls_cfg_mask)? " SSBD+" : " SSBD-",
+ xen_ssbd_amd_ls_cfg_en? " SSBD+" : " SSBD-",
opt_ibpb ? " IBPB" : "");
/*
@@ -497,6 +497,201 @@ static __init int parse_xpti(const char *s)
}
custom_param("xpti", parse_xpti);
+/*
+ * For family 15h and 16h, there are no SMT enabled processors, so there
+ * is no need for locking, just need to set an MSR bit. For 17h, it
+ * depends if SMT is enabled. If SMT, are two threads share a single
+ * MSR so there needs to be a lock and a virtual bit for each thread.
+ */
+
+/* used for non SMT mitigations (no shared MSRs) */
+static void ssbd_amd_ls_cfg_set_nonsmt(bool enable_ssbd)
+{
+unsigned long ls_cfg;
+
+if ( enable_ssbd )
+{
+rdmsrl(MSR_AMD64_LS_CFG, ls_cfg);
+if ( !(ls_cfg & ssbd_amd_ls_cfg_mask) )
+{
+ls_cfg |= ssbd_amd_ls_cfg_mask;
+wrmsrl(MSR_AMD64_LS_CFG, ls_cfg);
+}
+}
+else
+{
+rdmsrl(MSR_AMD64_LS_CFG, ls_cfg);
+if (ls_cfg & ssbd_amd_ls_cfg_mask)
+{
+ls_cfg &= ~ssbd_amd_ls_cfg_mask;
+wrmsrl(MSR_AMD64_LS_CFG, ls_cfg);
+}
+}
+}
+
+/* used for family 17h with SMT enabled (shared MSRs) */
+static void ssbd_amd_ls_cfg_set_smt(bool enable_ssbd)
+{
+__u32 socket, core, thread;
+uint64_t enable_mask;
+unsigned long ls_cfg;
+struct ssbd_amd_ls_cfg_smt_status *status;
+struct cpuinfo_x86 *c = _cpu_data;
+
+socket = c->phys_proc_id;
+core = c->cpu_core_id;
+thread = c->apicid && (c->x86_num_siblings - 1);
+
+status = ssbd_amd_smt_status[socket] + core;
+enable_mask = (1ull << thread);
+spin_lock(>lock);
+
+if ( enable_ssbd )
+{
+if ( !(status->mask & enable_mask) )
+{
+status->mask |= enable_mask;
+rdmsrl(MSR_AMD64_LS_CFG, ls_cfg);
+if ( !(ls_cfg & ssbd_amd_ls_cfg_mask) )
+{
+ls_cfg |= ssbd_amd_ls_cfg_mask;
+wrmsrl(MSR_AMD64_LS_CFG, ls_cfg);
+}
+}
+}
+else
+{
+if (
[Xen-devel] [xen-unstable-smoke test] 125473: tolerable all pass - PUSHED
flight 125473 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/125473/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: 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-libvirt 13 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 version targeted for testing: xen 5437bdcd48e9812e66ec3ea656fd655289d08435 baseline version: xen 3cdac2805692c7accde2f405d81cc0be799aee48 Last test of basis 125432 2018-07-19 14:00:40 Z1 days Failing since125439 2018-07-19 19:00:36 Z0 days7 attempts Testing same since 125473 2018-07-20 12:00:39 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Doug Goldstein Jan Beulich Roger Pau Monne Roger Pau Monné Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt 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/xen.git 3cdac28056..5437bdcd48 5437bdcd48e9812e66ec3ea656fd655289d08435 -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 0/8] xen: dma-buf support for grant device
On 07/20/2018 05:01 AM, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > This work is in response to my previous attempt to introduce Xen/DRM > zero-copy driver [1] to enable Linux dma-buf API [2] for Xen based > frontends/backends. There is also an existing hyper_dmabuf approach > available [3] which, if reworked to utilize the proposed solution, > can greatly benefit as well. Lot of warnings on i386 build: In file included from /data/upstream/linux-xen/drivers/gpu/drm/xen/xen_drm_front.c:24: /data/upstream/linux-xen/drivers/gpu/drm/xen/xen_drm_front.h: In function ‘xen_drm_front_fb_to_cookie’: /data/upstream/linux-xen/drivers/gpu/drm/xen/xen_drm_front.h:129:9: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] return (u64)fb; ^ /data/upstream/linux-xen/drivers/gpu/drm/xen/xen_drm_front.h: In function ‘xen_drm_front_dbuf_to_cookie’: /data/upstream/linux-xen/drivers/gpu/drm/xen/xen_drm_front.h:134:9: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] return (u64)gem_obj; ^ CC [M] net/netfilter/ipset/ip_set_hash_ipport.o CC drivers/media/rc/keymaps/rc-tango.o CC [M] drivers/gpu/drm/vmwgfx/vmwgfx_fifo.o AR drivers/misc/built-in.a In file included from /data/upstream/linux-xen/drivers/gpu/drm/xen/xen_drm_front_kms.c:20: /data/upstream/linux-xen/drivers/gpu/drm/xen/xen_drm_front.h: In function ‘xen_drm_front_fb_to_cookie’: CC [M] drivers/gpu/drm/xen/xen_drm_front_conn.o /data/upstream/linux-xen/drivers/gpu/drm/xen/xen_drm_front.h:129:9: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] return (u64)fb; (and more) and then data/upstream/linux-xen/drivers/xen/gntdev-dmabuf.c: In function ‘gntdev_ioctl_dmabuf_exp_from_refs’: /data/upstream/linux-xen/drivers/xen/gntdev-dmabuf.c:503:6: warning: ‘args.fd’ may be used uninitialized in this function [-Wmaybe-uninitialized] *fd = args.fd; ^ /data/upstream/linux-xen/drivers/xen/gntdev-dmabuf.c:467:35: note: ‘args.fd’ was declared here struct gntdev_dmabuf_export_args args; ^~~~ -boris ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3] x86/mm: Add mem access rights to NPT
> I will absolutely nack any interface where if the caller says, > "Please > remove read permission", the hypervisor says, "OK!" but then allows > read > permission anyway -- particularly in one which is allegedly designed > for > security tools. > > If it's not practical / more work than it's worth doing at the moment > to > implement p2m_access_n on NPT, then you should return an error when > it's > requested. > > The same really should be true for write-only permission as well -- > if > it's not possible to allow writes but not reads, then you should > return > an error when such permissions are requested. I will limit the supported access rights and return error for read/write only and _n. Regards, Alex ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [freebsd-master test] 125467: regressions - trouble: blocked/fail
flight 125467 freebsd-master real [real] http://logs.test-lab.xenproject.org/osstest/logs/125467/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-freebsd 7 freebsd-buildfail REGR. vs. 125317 Tests which did not succeed, but are not blocking: build-amd64-freebsd-again 1 build-check(1) blocked n/a version targeted for testing: freebsd 94b5fd4fb9370f3f5e0094f5fbe98c7edbe34295 baseline version: freebsd bf65d05707104df94117a293327d797d71a0118d Last test of basis 125317 2018-07-18 09:19:47 Z2 days Testing same since 125467 2018-07-20 09:19:59 Z0 days1 attempts People who touched revisions under test: 0mp <0...@freebsd.org> alc andrew asomers bde br cem cy dab delphij dim eugen hselasky ian imp jhibbits kib manu markj mmel oshogbo royger rrs sef trasz tuexen zleslie jobs: build-amd64-freebsd-againblocked build-amd64-freebsd fail 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 855 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 125463: regressions - FAIL
flight 125463 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/125463/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 125432 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-debianhvm-i386 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a 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 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen d6371ccb93012db4ad6615fe666205b86308cb4e baseline version: xen 3cdac2805692c7accde2f405d81cc0be799aee48 Last test of basis 125432 2018-07-19 14:00:40 Z0 days Testing same since 125439 2018-07-19 19:00:36 Z0 days6 attempts People who touched revisions under test: Andrew Cooper Jan Beulich Roger Pau Monné jobs: build-arm64-xsm pass build-amd64 fail build-armhf pass build-amd64-libvirt blocked test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386 blocked test-amd64-amd64-libvirt 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. commit d6371ccb93012db4ad6615fe666205b86308cb4e Author: Andrew Cooper Date: Wed Jul 18 12:22:55 2018 +0100 x86/xstate: Make errors in xstate calculations more obvious by crashing the domain If xcr0_max exceeds xfeature_mask, then something is broken with the CPUID policy derivation or auditing logic. If hardware rejects new_bv, then something is broken with Xen's xstate logic. In both cases, crash the domain with an obvious error message, to help highlight the issues. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich commit 361b835fa00d9f45167c50a60e054ccf22c065d7 Author: Andrew Cooper Date: Wed Jul 18 11:56:44 2018 +0100 x86/xstate: Use a guests CPUID policy, rather than allowing all features It turns out that Xen has never enforced that a domain remain within the xstate features advertised in CPUID. The check of new_bv against xfeature_mask ensures that a domain stays within the set of features that Xen has enabled in hardware (and therefore isn't a security problem), but this does means that attempts to level a guest for migration safety might not be effective if the guest ignores CPUID. Check the CPUID policy in validate_xstate() (for incoming migration) and in handle_xsetbv() (for guest XSETBV instructions). This subsumes the PKRU check for PV guests in handle_xsetbv() (and also demonstrates that I should have spotted this problem while reviewing c/s fbf9971241f). For migration, this is correct despite the current (mis)ordering of data because d->arch.cpuid is the applicable max policy. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich commit 2e2bd5a29e481d0e7f163a19d663d959e09550fd Author: Andrew Cooper Date: Fri Jun 29 13:05:52 2018 + libx86: Introduce lib/x86/msr.h and share msr_policy with userspace To facilitate the shared Xen and toolstack code in libx86, struct msr_policy needs to be available in the same way as struct cpuid_policy. Signed-off-by: Andrew Cooper Reviewed-by: Wei Liu Reviewed-by: Roger Pau Monné Acked-by: Jan Beulich commit fea2fab9635613d5be83482da5d79160ef928941 Author: Roger Pau Monné Date: Thu Jun 21 15:35:48 2018 +0100 libx86: introduce a libx86 shared library Move x86_cpuid_lookup_deep_deps() into the shared library,
Re: [Xen-devel] [PATCH] x86/physdev: Remove redundant assignment in allocate_and_map_msi_pirq()
On 20/07/18 11:13, Roger Pau Monné wrote: > On Fri, Jul 20, 2018 at 02:29:34AM -0700, Zhenzhong Duan wrote: >> No functional change. >> >> Signed-off-by: Zhenzhong Duan >> --- >> xen/arch/x86/irq.c |2 -- >> 1 files changed, 0 insertions(+), 2 deletions(-) >> >> diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c >> index 87ef2e8..5253fd1 100644 >> --- a/xen/arch/x86/irq.c >> +++ b/xen/arch/x86/irq.c >> @@ -2701,8 +2701,6 @@ int allocate_and_map_msi_pirq(struct domain *d, int >> index, int *pirq_p, >> return -EINVAL; >> } >> >> -msi->irq = irq; > I would prefer to remove the assignment in the MAP_PIRQ_TYPE_MULTI_MSI > case rather than here. IMO this one makes it clearer that msi->irq is > always set. Me too. I can fix this up on commit. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/physdev: Remove redundant assignment in allocate_and_map_msi_pirq()
On Fri, Jul 20, 2018 at 02:29:34AM -0700, Zhenzhong Duan wrote: > No functional change. > > Signed-off-by: Zhenzhong Duan > --- > xen/arch/x86/irq.c |2 -- > 1 files changed, 0 insertions(+), 2 deletions(-) > > diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c > index 87ef2e8..5253fd1 100644 > --- a/xen/arch/x86/irq.c > +++ b/xen/arch/x86/irq.c > @@ -2701,8 +2701,6 @@ int allocate_and_map_msi_pirq(struct domain *d, int > index, int *pirq_p, > return -EINVAL; > } > > -msi->irq = irq; I would prefer to remove the assignment in the MAP_PIRQ_TYPE_MULTI_MSI case rather than here. IMO this one makes it clearer that msi->irq is always set. In any case: Reviewed-by: Roger Pau Monné Thanks, Roger. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] CPU flags disappear on Spectre enabled host
On 20/07/18 10:58, Olaf Hering wrote: > Am Fri, 20 Jul 2018 10:38:30 +0100 > schrieb Andrew Cooper : > >> On 20/07/18 10:21, Olaf Hering wrote: >>> Is the loss of cpuflags intentional? >> Yes, but they've got nothing to do with Spectre. > Thank you, Andrew. After a few more reboots I figured that booting without > any cmdline option makes no difference. > > From the original report that I got, these additional flags disappeared: > > cqm_llc > cqm_occup_llc > pln > pts > > I assume a domU can not make use of them either? They are not listed in CPUID > in wikipedia, perhaps just not with those names. CQM is the quality-of-service measurement infrastructure on newer Intel hardware. They are behind the `psr` command line option, and can be used with `xl psr-*` but only by the privileged domain, as they monitor system-wide shared resources. PLN is Power Limit Notification (apparently) which surely means that to be used, we'd need a Xen driver. PTS is Package Thermal Status and is presumably the same. Neither are things which even dom0 could use. Having looked over the code, we actually hide all of the Thermal leaf even from dom0. It was the monitor leaf we conditionally leak back in. For the gory details, read xen/arch/x86/cpuid.c:guest_cpuid() ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3] x86/mm: Add mem access rights to NPT
On 07/19/2018 09:18 AM, Isaila Alexandru wrote:
> On Mi, 2018-07-18 at 15:33 +, George Dunlap wrote:
>>
>>>
>>> On Jul 2, 2018, at 8:42 AM, Alexandru Isaila >> om> wrote:
>>>
>>> From: Isaila Alexandru
>>>
>>> This patch adds access rights for the NPT pages. The access rights
>>> are
>>> saved in a radix tree with the root saved in p2m_domain. The rights
>>> are manipulated through p2m_set_access()
>>> and p2m_get_access() functions.
>>> The patch follows the ept logic.
>> This description needs to be much more complete. Something like
>> this:
>>
>> ---
>> This patch adds access control for NPT mode.
>>
>> There aren’t enough extra bits to store the access rights in the NPT
>> p2m table, so we add a radix tree to store the rights. For
>> efficiency, remove entries which match the default permissions rather
>> than continuing to store them.
>>
>> Modify p2m-pt.c:p2m_type_to_flags() to mirror the ept version: taking
>> an access, and removing / adding RW or NX flags as appropriate.
>> ---
>>
> I will update the patch description.
>>>
>>>
>>> Note: It was tested with xen-access write
>>>
>>> Signed-off-by: Alexandru Isaila
>>
>>>
>>>
>>> ---
>>> Changes since V2:
>>> - Delete blak line
>>> - Add return if p2m_access_rwx = a
>>> - Delete the comment from p2m_pt_get_entry()
>>> - Moved radix_tree_init() to arch_monitor_init_domain().
>>> ---
>>> xen/arch/x86/mm/mem_access.c | 3 ++
>>> xen/arch/x86/mm/p2m-pt.c | 109
>>> ++-
>>> xen/arch/x86/mm/p2m.c| 6 +++
>>> xen/arch/x86/monitor.c | 13 +
>>> xen/include/asm-x86/mem_access.h | 2 +-
>>> xen/include/asm-x86/p2m.h| 6 +++
>>> 6 files changed, 124 insertions(+), 15 deletions(-)
>>>
>>> diff --git a/xen/arch/x86/mm/mem_access.c
>>> b/xen/arch/x86/mm/mem_access.c
>>> index c0cd017..d78c82c 100644
>>> --- a/xen/arch/x86/mm/mem_access.c
>>> +++ b/xen/arch/x86/mm/mem_access.c
>>> @@ -221,7 +221,10 @@ bool p2m_mem_access_check(paddr_t gpa,
>>> unsigned long gla,
>>> {
>>> req->u.mem_access.flags |= MEM_ACCESS_GLA_VALID;
>>> req->u.mem_access.gla = gla;
>>> +}
>>>
>>> +if ( npfec.gla_valid || cpu_has_svm )
>>> +{
>> I can’t immediately tell what this is about, which means it needs a
>> comment.
>>
>> It may also be (depending on why this is here) that “cpu_has_svm”
>> makes this more fragile — if this is really about having a radix
>> tree, for instance, then you should probably check for a radix tree.
>
> This is about the different npfec on SVN. The gla in never valid so the
> fault flag will not be set.
Right -- then really this check was always a VMX-ism, and should really
have been:
/* VMX can only tell the fault type if gla_valid is set */
if ( !(cpu_has_vmx && !npfec.gla_valid) ) {
...
But in any case, if cpu_has_vmx && !npfec.gla_valid, then npfec.kind
should be npfec_kind_unknown (==0); so is there any reason not to read
npfec.kind here unconditionally? i.e., like below?
if ( npfec.gla_valid )
{
req->u.mem_access.flags |= MEM_ACCESS_GLA_VALID;
req->u.mem_access.gla = gla;
}
if ( npfec.kind == npfec_kind_with_gla )
req->u.mem_access.flags |= MEM_ACCESS_FAULT_WITH_GLA;
else if ( npfec.kind == npfec_kind_in_gpt )
req->u.mem_access.flags |= MEM_ACCESS_FAULT_IN_GPT;
-George
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] CPU flags disappear on Spectre enabled host
Am Fri, 20 Jul 2018 10:38:30 +0100 schrieb Andrew Cooper : > On 20/07/18 10:21, Olaf Hering wrote: > > Is the loss of cpuflags intentional? > Yes, but they've got nothing to do with Spectre. Thank you, Andrew. After a few more reboots I figured that booting without any cmdline option makes no difference. From the original report that I got, these additional flags disappeared: cqm_llc cqm_occup_llc pln pts I assume a domU can not make use of them either? They are not listed in CPUID in wikipedia, perhaps just not with those names. Olaf pgpToGmV5rkO7.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] CPU flags disappear on Spectre enabled host
On 20/07/18 10:21, Olaf Hering wrote: > On a host that is booted with the following command line, certain cpu flags > disappear in xen-4.9 and later: > > (XEN) Command line: loglvl=all guest_loglvl=all console=com1 com1=57600 > cpuid=ibrsb,stibp,ibpb,ssbd spec-ctrl=ibrs,ibpb,ssbd,bti-thunk=retpoline > xpti=yes > > On my test system the difference in dom0s /proc/cpuinfo is like that: > --- xen-dom0-4.8-spectre.txt > +++ xen-dom0-4.12-spectre.txt > -arat > -arch_perfmon > -dtherm > -epb > -ida > +ss > > The concern is that a domU started on a xen-4.8 or earlier host, which is > then migrated to xen-4.9 or later may miss these cpu flags at runtime. > > Is the loss of cpuflags intentional? Yes, but they've got nothing to do with Spectre. ARAT pertains to the Local APIC which doesn't exist for PV. ARCH_PERFMON is genuinely unavailable (hidden behind the vpmu Xen cmdline parameter, and off for security reasons). DTHERM/EPB/IDA should be (for backwards compatibility, not correctness) leaked through into the dom0 kernel only, because classic-xen and PVOps Linux makes some false and broken assumptions. None of these bits should be visible even to dom0, because dom0 can't actually use any of the associated MSRs, but hiding them causes dom0 not to try parsing the ACPI tables and feeding data to Xen. SS on the other hand was unilaterally clobbered for reasons I can't work out, and should have always been available to guests. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 10/13] x86: add iommu_op to enable modification of IOMMU mappings
On Fri, Jul 20, 2018 at 10:19:44AM +0100, Paul Durrant wrote: > > > > > > I think this flag currently serves two purposes: one is to indicate > > > whether there are resources allocated within xen, the other it indicate > > > whether it is in use (as suggested in the comment). > > > > > > Suppose a domain gets all its devices deassigned after this call, > > > original iommu_teardown would have been called, but now it won't. The > > > iommu will still be torn down when it is destroyed, but this is a very > > > subtle change in behaviour. > > > > That is pretty subtle. > > Actually, thinking a bit more, that is the semantic I want. The domain > is taking control of its own mappings. It doesn't want Xen to tear > them down under its feet. Oh, this makes sense. > > > > > > > > > IMHO we should clearly separate these two cases if possible. > > > > > > > Agreed. I never liked the 'need_iommu' name anyway. I'll add a patch before > > this one to do the rename/split. > > > > I still think this renaming/clarification is worthwhile so I'll still > add something into the series. > Thanks. Wei. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] x86/physdev: Remove redundant assignment in allocate_and_map_msi_pirq()
No functional change. Signed-off-by: Zhenzhong Duan --- xen/arch/x86/irq.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c index 87ef2e8..5253fd1 100644 --- a/xen/arch/x86/irq.c +++ b/xen/arch/x86/irq.c @@ -2701,8 +2701,6 @@ int allocate_and_map_msi_pirq(struct domain *d, int index, int *pirq_p, return -EINVAL; } -msi->irq = irq; - pcidevs_lock(); /* Verify or get pirq. */ spin_lock(>event_lock); -- 1.7.3 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [distros-debian-jessie test] 74991: tolerable FAIL
flight 74991 distros-debian-jessie real [real] http://osstest.xensource.com/osstest/logs/74991/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-armhf-jessie-netboot-pygrub 10 debian-di-install fail like 74964 baseline version: flight 74964 jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-amd64-jessie-netboot-pvgrub pass test-amd64-i386-i386-jessie-netboot-pvgrub pass test-amd64-i386-amd64-jessie-netboot-pygrub pass test-armhf-armhf-armhf-jessie-netboot-pygrub fail test-amd64-amd64-i386-jessie-netboot-pygrub pass sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xensource.com/osstest/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-4.9 test] 125342: regressions - FAIL
flight 125342 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/125342/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 125183 Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-credit2 7 xen-boot fail pass in 125271 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-credit2 13 migrate-support-check fail in 125271 never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail in 125271 never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 125183 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 125183 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 125183 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 125183 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 125183 test-amd64-amd64-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-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim12 guest-start 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-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-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-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-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-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-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 13 migrate-support-checkfail never pass test-armhf-armhf-xl 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-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-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-win10-i386 10 windows-installfail 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 version targeted for testing: linuxf77982e6911294725180897ff726ab708381 baseline version: linux060744011e93679f03932f050619744be895b772 Last test of basis 125183 2018-07-15 16:46:53 Z4 days Testing same since 125271 2018-07-17 10:12:19 Z2 days2 attempts People who touched
Re: [Xen-devel] [PATCH] lzma: fix hypervisor build
On Fri, Jul 20, 2018 at 11:17:18AM +0200, Juergen Gross wrote: > On 20/07/18 11:00, Wei Liu wrote: > > On Fri, Jul 20, 2018 at 10:32:42AM +0200, Roger Pau Monne wrote: > >> Remove local definition of MIN and instead include the kernel.h header > >> for the hypervisor build. Fixes the following error on the tools build: > >> > >> In file included from xc_dom_decompress_unsafe_lzma.c:8:0: > >> ../../xen/common/unlzma.c:33:0: error: "MIN" redefined [-Werror] > >> #define MIN(a, b) (((a) < (b)) ? (a) : (b)) > >> ^ > >> In file included from xc_private.h:43:0, > >> from xg_private.h:29, > >> from xc_dom_decompress_unsafe_lzma.c:5: > >> /home/osstest/build.125458.build-amd64/xen/stubdom/libxc-x86_64/../../tools/include/xen-tools/libs.h:21:0: > >> note: this is the location of the previous definition > >> #define MIN(x, y) ((x) < (y) ? (x) : (y)) > >> ^ > >> > >> Signed-off-by: Roger Pau Monné > > > > Acked-by: Wei Liu > > > > Strangely I never saw this during my build. > > What did your ./configure run say about lzma support? It appears that it got broken yesterday-ish so I never had a chance to see it. :-) Wei. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] CPU flags disappear on Spectre enabled host
On a host that is booted with the following command line, certain cpu flags disappear in xen-4.9 and later: (XEN) Command line: loglvl=all guest_loglvl=all console=com1 com1=57600 cpuid=ibrsb,stibp,ibpb,ssbd spec-ctrl=ibrs,ibpb,ssbd,bti-thunk=retpoline xpti=yes On my test system the difference in dom0s /proc/cpuinfo is like that: --- xen-dom0-4.8-spectre.txt +++ xen-dom0-4.12-spectre.txt -arat -arch_perfmon -dtherm -epb -ida +ss The concern is that a domU started on a xen-4.8 or earlier host, which is then migrated to xen-4.9 or later may miss these cpu flags at runtime. Is the loss of cpuflags intentional? I just noticed that at least in staging a boot with "no-ibrsb no-stibp no-ibpb no-ssbd spec-ctrl=no-xen,rsb=no xpti=no" does still not show these flags in dom0. Olaf pgpkCtmTwnGCi.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 v3 10/13] x86: add iommu_op to enable modification of IOMMU mappings
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Paul Durrant
> Sent: 20 July 2018 10:05
> To: Wei Liu
> Cc: Stefano Stabellini ; Wei Liu
> ; Andrew Cooper ; Tim
> (Xen.org) ; George Dunlap ;
> Julien Grall ; Jan Beulich ; Ian
> Jackson ; xen-devel@lists.xenproject.org
> Subject: Re: [Xen-devel] [PATCH v3 10/13] x86: add iommu_op to enable
> modification of IOMMU mappings
>
> > -Original Message-
> > From: Wei Liu [mailto:wei.l...@citrix.com]
> > Sent: 20 July 2018 09:59
> > To: Paul Durrant
> > Cc: xen-devel@lists.xenproject.org; Jan Beulich ;
> > Andrew Cooper ; George Dunlap
> > ; Ian Jackson ;
> Julien
> > Grall ; Konrad Rzeszutek Wilk
> > ; Stefano Stabellini ;
> Tim
> > (Xen.org) ; Wei Liu
> > Subject: Re: [PATCH v3 10/13] x86: add iommu_op to enable modification
> of
> > IOMMU mappings
> >
> > On Tue, Jul 17, 2018 at 02:38:13PM +0100, Paul Durrant wrote:
> > > +static int iommu_op_enable_modification(void)
> > > +{
> > > +struct domain *currd = current->domain;
> > > +struct domain_iommu *iommu = dom_iommu(currd);
> > > +const struct iommu_ops *ops = iommu->platform_ops;
> > > +
> > > +/* Has modification already been enabled? */
> > > +if ( iommu->iommu_op_ranges )
> > > +return 0;
> > > +
> > > +/*
> > > + * The IOMMU mappings cannot be modified if:
> > > + * - the IOMMU is not enabled or,
> > > + * - the current domain is dom0 and tranlsation is disabled or,
> > > + * - HAP is enabled and the IOMMU shares the mappings.
> > > + */
> > > +if ( !iommu_enabled ||
> > > + (is_hardware_domain(currd) && iommu_passthrough) ||
> > > + iommu_use_hap_pt(currd) )
> > > +return -EACCES;
> > > +
> > > +/*
> > > + * The IOMMU implementation must provide the lookup method if
> > > + * modification of the mappings is to be supported.
> > > + */
> > > +if ( !ops->lookup_page )
> > > +return -EOPNOTSUPP;
> > > +
> > > +iommu->iommu_op_ranges = rangeset_new(currd, NULL, 0);
> > > +if ( !iommu->iommu_op_ranges )
> > > +return -ENOMEM;
> > > +
> > > +currd->need_iommu = 0; /* Disable identity GFN mapping */
> >
> > I think this flag currently serves two purposes: one is to indicate
> > whether there are resources allocated within xen, the other it indicate
> > whether it is in use (as suggested in the comment).
> >
> > Suppose a domain gets all its devices deassigned after this call,
> > original iommu_teardown would have been called, but now it won't. The
> > iommu will still be torn down when it is destroyed, but this is a very
> > subtle change in behaviour.
>
> That is pretty subtle.
Actually, thinking a bit more, that is the semantic I want. The domain is
taking control of its own mappings. It doesn't want Xen to tear them down under
its feet.
>
> >
> > IMHO we should clearly separate these two cases if possible.
> >
>
> Agreed. I never liked the 'need_iommu' name anyway. I'll add a patch before
> this one to do the rename/split.
>
I still think this renaming/clarification is worthwhile so I'll still add
something into the series.
Paul
> Paul
>
> > > +return 0;
> > > +}
> > > +
> > [...]
> > > diff --git a/xen/drivers/passthrough/iommu.c
> > b/xen/drivers/passthrough/iommu.c
> > > index fb9d0e1848..c517428621 100644
> > > --- a/xen/drivers/passthrough/iommu.c
> > > +++ b/xen/drivers/passthrough/iommu.c
> > > @@ -26,7 +26,6 @@ static void iommu_dump_p2m_table(unsigned char
> > key);
> > >
> > > unsigned int __read_mostly iommu_dev_iotlb_timeout = 1000;
> > > integer_param("iommu_dev_iotlb_timeout",
> iommu_dev_iotlb_timeout);
> > > -
> >
> > Please keep the blank line here.
> >
> > Wei.
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] lzma: fix hypervisor build
On 20/07/18 11:00, Wei Liu wrote: > On Fri, Jul 20, 2018 at 10:32:42AM +0200, Roger Pau Monne wrote: >> Remove local definition of MIN and instead include the kernel.h header >> for the hypervisor build. Fixes the following error on the tools build: >> >> In file included from xc_dom_decompress_unsafe_lzma.c:8:0: >> ../../xen/common/unlzma.c:33:0: error: "MIN" redefined [-Werror] >> #define MIN(a, b) (((a) < (b)) ? (a) : (b)) >> ^ >> In file included from xc_private.h:43:0, >> from xg_private.h:29, >> from xc_dom_decompress_unsafe_lzma.c:5: >> /home/osstest/build.125458.build-amd64/xen/stubdom/libxc-x86_64/../../tools/include/xen-tools/libs.h:21:0: >> note: this is the location of the previous definition >> #define MIN(x, y) ((x) < (y) ? (x) : (y)) >> ^ >> >> Signed-off-by: Roger Pau Monné > > Acked-by: Wei Liu > > Strangely I never saw this during my build. What did your ./configure run say about lzma support? Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3] x86/mm: Add mem access rights to NPT
On 07/19/2018 02:08 PM, Isaila Alexandru wrote:
> On Jo, 2018-07-19 at 04:02 -0600, Jan Beulich wrote:
>>>
>
> On 19.07.18 at 10:43, wrote:
>>> On 07/19/2018 11:30 AM, Jan Beulich wrote:
>
>>
>>>
>>> On 19.07.18 at 10:18, wrote:
> On Mi, 2018-07-18 at 15:33 +, George Dunlap wrote:
>>
>>>
>>> On Jul 2, 2018, at 8:42 AM, Alexandru Isaila >> fender.c
>>> +break;
>>> +case p2m_access_x:
>>> +flags &= ~_PAGE_RW;
>>> +break;
>>> +case p2m_access_rwx:
>>> +default:
>>> +break;
>>> }
>> I think you want another blank line here too.
>>
>> Also, this doesn’t seem to capture the ‘r’ part of the
>> equation —
>> shouldn’t p2m_access_n end up with a not-present p2m entry?
> SVM dosen't explicitly provide a read access bit so we treat
> read and
> write the same way.
Read and write can't possibly be treated the same. You ought to
use
the present bit to deny read (really: any) access, as also
implied by
George's response.
>>> They aren't treated the same as far sending out a vm_event goes.
>>> However, if we understand this correctly, there is no way to cause
>>> only
>>> read, or only write exits for NPT. They are bundled together under
>>> _PAGE_RW.
>>>
>>> So svm_do_nested_pgfault() tries to sort these out:
>>>
>>> 1781 struct npfec npfec = {
>>> 1782 .read_access = !(pfec & PFEC_insn_fetch),
>>> 1783 .write_access = !!(pfec & PFEC_write_access),
>>> 1784 .insn_fetch = !!(pfec & PFEC_insn_fetch),
>>> 1785 .present = !!(pfec & PFEC_page_present),
>>> 1786 };
>>> 1787
>>> 1788 /* These bits are mutually exclusive */
>>> 1789 if ( pfec & NPT_PFEC_with_gla )
>>> 1790 npfec.kind = npfec_kind_with_gla;
>>> 1791 else if ( pfec & NPT_PFEC_in_gpt )
>>> 1792 npfec.kind = npfec_kind_in_gpt;
>>> 1793
>>> 1794 ret = hvm_hap_nested_page_fault(gpa, ~0ul, npfec);
>>>
>>> but a read access is considered to be something that's not an insn
>>> fetch, and we only have a specific bit set for the write.
>>>
>>> Since hvm_hap_nested_page_fault() looks at npfec to decide when to
>>> send
>>> out a vm_event, this takes care of handling reads and writes
>>> differently
>>> at this level; however it's not possible to set separate single
>>> "don't
>>> read" or "don't write" exit-causing flags with NPT.
>> All fine, but George's question was raised in the context of
>> permission
>> conversion from p2m to pte representation.
>
> I've tried a test with xen access that sets XENMEM_access_n on all the
> pages and in p2m_type_to_flags() remove the _PAGE_PRESENT flag for
> the p2m_access_n case and the guest fails with triple fault. There are
> a lot of checks against _PAGE_PRESENT in p2m-pt and a lot of return
> invalid if the flag is not present. I don't think this is the way to go
> with the p2m_access_n flags.
I will absolutely nack any interface where if the caller says, "Please
remove read permission", the hypervisor says, "OK!" but then allows read
permission anyway -- particularly in one which is allegedly designed for
security tools.
If it's not practical / more work than it's worth doing at the moment to
implement p2m_access_n on NPT, then you should return an error when it's
requested.
The same really should be true for write-only permission as well -- if
it's not possible to allow writes but not reads, then you should return
an error when such permissions are requested.
-George
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [qemu-upstream-4.11-testing test] 125345: regressions - FAIL
flight 125345 qemu-upstream-4.11-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/125345/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail REGR. vs. 124797 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-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-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-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-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-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-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 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-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 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-amd64-amd64-libvirt-vhd 12 migrate-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 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-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-win7-amd64 17 guest-stop fail 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-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass version targeted for testing: qemuu20c76f9a5fbf16d58c6add2ace2ff0fabd785926 baseline version: qemuu43139135a8938de44f66333831d3a8655d07663a Last test of basis 124797 2018-06-28 16:27:31 Z 21 days Testing same since 125273 2018-07-17 11:38:59 Z2 days2 attempts People who touched revisions under test: Alberto Garcia Alexandro Sanchez Bach Anthony PERARD Brijesh Singh Bruce Rogers Christian Borntraeger Cornelia Huck Daniel P. Berrange Daniel P. Berrangé David Gibson Dr. David Alan Gilbert Eduardo Habkost Eric Blake Fam Zheng Geert Uytterhoeven Gerd Hoffmann Greg Kurz Halil Pasic Henry Wertz Jack Schwartz Jan Kiszka Jason Andryuk Jason Wang Jeff Cody Jintack Lim John Snow John Thomson Kevin Wolf KONRAD Frederic Konrad Rzeszutek Wilk Laszlo Ersek Laurent Vivier Laurent Vivier linzhecheng Marc-André Lureau Mark Cave-Ayland Max Filippov Max Reitz Michael Roth Michael S. Tsirkin Michael Walle Michal Privoznik
Re: [Xen-devel] [PATCH v3 10/13] x86: add iommu_op to enable modification of IOMMU mappings
> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: 20 July 2018 09:59
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Jan Beulich ;
> Andrew Cooper ; George Dunlap
> ; Ian Jackson ; Julien
> Grall ; Konrad Rzeszutek Wilk
> ; Stefano Stabellini ; Tim
> (Xen.org) ; Wei Liu
> Subject: Re: [PATCH v3 10/13] x86: add iommu_op to enable modification of
> IOMMU mappings
>
> On Tue, Jul 17, 2018 at 02:38:13PM +0100, Paul Durrant wrote:
> > +static int iommu_op_enable_modification(void)
> > +{
> > +struct domain *currd = current->domain;
> > +struct domain_iommu *iommu = dom_iommu(currd);
> > +const struct iommu_ops *ops = iommu->platform_ops;
> > +
> > +/* Has modification already been enabled? */
> > +if ( iommu->iommu_op_ranges )
> > +return 0;
> > +
> > +/*
> > + * The IOMMU mappings cannot be modified if:
> > + * - the IOMMU is not enabled or,
> > + * - the current domain is dom0 and tranlsation is disabled or,
> > + * - HAP is enabled and the IOMMU shares the mappings.
> > + */
> > +if ( !iommu_enabled ||
> > + (is_hardware_domain(currd) && iommu_passthrough) ||
> > + iommu_use_hap_pt(currd) )
> > +return -EACCES;
> > +
> > +/*
> > + * The IOMMU implementation must provide the lookup method if
> > + * modification of the mappings is to be supported.
> > + */
> > +if ( !ops->lookup_page )
> > +return -EOPNOTSUPP;
> > +
> > +iommu->iommu_op_ranges = rangeset_new(currd, NULL, 0);
> > +if ( !iommu->iommu_op_ranges )
> > +return -ENOMEM;
> > +
> > +currd->need_iommu = 0; /* Disable identity GFN mapping */
>
> I think this flag currently serves two purposes: one is to indicate
> whether there are resources allocated within xen, the other it indicate
> whether it is in use (as suggested in the comment).
>
> Suppose a domain gets all its devices deassigned after this call,
> original iommu_teardown would have been called, but now it won't. The
> iommu will still be torn down when it is destroyed, but this is a very
> subtle change in behaviour.
That is pretty subtle.
>
> IMHO we should clearly separate these two cases if possible.
>
Agreed. I never liked the 'need_iommu' name anyway. I'll add a patch before
this one to do the rename/split.
Paul
> > +return 0;
> > +}
> > +
> [...]
> > diff --git a/xen/drivers/passthrough/iommu.c
> b/xen/drivers/passthrough/iommu.c
> > index fb9d0e1848..c517428621 100644
> > --- a/xen/drivers/passthrough/iommu.c
> > +++ b/xen/drivers/passthrough/iommu.c
> > @@ -26,7 +26,6 @@ static void iommu_dump_p2m_table(unsigned char
> key);
> >
> > unsigned int __read_mostly iommu_dev_iotlb_timeout = 1000;
> > integer_param("iommu_dev_iotlb_timeout", iommu_dev_iotlb_timeout);
> > -
>
> Please keep the blank line here.
>
> Wei.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v5 5/8] xen/gntdev: Make private routines/structures accessible
From: Oleksandr Andrushchenko
This is in preparation for adding support of DMA buffer
functionality: make map/unmap related code and structures, used
privately by gntdev, ready for dma-buf extension, which will re-use
these. Rename corresponding structures as those become non-private
to gntdev now.
Signed-off-by: Oleksandr Andrushchenko
Reviewed-by: Boris Ostrovsky
---
drivers/xen/gntdev-common.h | 88 +++
drivers/xen/gntdev.c| 134
2 files changed, 131 insertions(+), 91 deletions(-)
create mode 100644 drivers/xen/gntdev-common.h
diff --git a/drivers/xen/gntdev-common.h b/drivers/xen/gntdev-common.h
new file mode 100644
index ..2346c198f72e
--- /dev/null
+++ b/drivers/xen/gntdev-common.h
@@ -0,0 +1,88 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+/*
+ * Common functionality of grant device.
+ *
+ * Copyright (c) 2006-2007, D G Murray.
+ * (c) 2009 Gerd Hoffmann
+ * (c) 2018 Oleksandr Andrushchenko, EPAM Systems Inc.
+ */
+
+#ifndef _GNTDEV_COMMON_H
+#define _GNTDEV_COMMON_H
+
+#include
+#include
+#include
+#include
+
+struct gntdev_priv {
+ /* Maps with visible offsets in the file descriptor. */
+ struct list_head maps;
+ /*
+* Maps that are not visible; will be freed on munmap.
+* Only populated if populate_freeable_maps == 1
+*/
+ struct list_head freeable_maps;
+ /* lock protects maps and freeable_maps. */
+ struct mutex lock;
+ struct mm_struct *mm;
+ struct mmu_notifier mn;
+
+#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
+ /* Device for which DMA memory is allocated. */
+ struct device *dma_dev;
+#endif
+};
+
+struct gntdev_unmap_notify {
+ int flags;
+ /* Address relative to the start of the gntdev_grant_map. */
+ int addr;
+ int event;
+};
+
+struct gntdev_grant_map {
+ struct list_head next;
+ struct vm_area_struct *vma;
+ int index;
+ int count;
+ int flags;
+ refcount_t users;
+ struct gntdev_unmap_notify notify;
+ struct ioctl_gntdev_grant_ref *grants;
+ struct gnttab_map_grant_ref *map_ops;
+ struct gnttab_unmap_grant_ref *unmap_ops;
+ struct gnttab_map_grant_ref *kmap_ops;
+ struct gnttab_unmap_grant_ref *kunmap_ops;
+ struct page **pages;
+ unsigned long pages_vm_start;
+
+#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
+ /*
+* If dmabuf_vaddr is not NULL then this mapping is backed by DMA
+* capable memory.
+*/
+
+ struct device *dma_dev;
+ /* Flags used to create this DMA buffer: GNTDEV_DMA_FLAG_XXX. */
+ int dma_flags;
+ void *dma_vaddr;
+ dma_addr_t dma_bus_addr;
+ /* Needed to avoid allocation in gnttab_dma_free_pages(). */
+ xen_pfn_t *frames;
+#endif
+};
+
+struct gntdev_grant_map *gntdev_alloc_map(struct gntdev_priv *priv, int count,
+ int dma_flags);
+
+void gntdev_add_map(struct gntdev_priv *priv, struct gntdev_grant_map *add);
+
+void gntdev_put_map(struct gntdev_priv *priv, struct gntdev_grant_map *map);
+
+bool gntdev_account_mapped_pages(int count);
+
+int gntdev_map_grant_pages(struct gntdev_grant_map *map);
+
+#endif
diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index 173332f439d8..e03f50052f3e 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -6,6 +6,7 @@
*
* Copyright (c) 2006-2007, D G Murray.
* (c) 2009 Gerd Hoffmann
+ * (c) 2018 Oleksandr Andrushchenko, EPAM Systems Inc.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
@@ -26,10 +27,6 @@
#include
#include
#include
-#include
-#include
-#include
-#include
#include
#include
#include
@@ -50,6 +47,8 @@
#include
#include
+#include "gntdev-common.h"
+
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Derek G. Murray , "
"Gerd Hoffmann ");
@@ -65,73 +64,23 @@ static atomic_t pages_mapped = ATOMIC_INIT(0);
static int use_ptemod;
#define populate_freeable_maps use_ptemod
-struct gntdev_priv {
- /* maps with visible offsets in the file descriptor */
- struct list_head maps;
- /* maps that are not visible; will be freed on munmap.
-* Only populated if populate_freeable_maps == 1 */
- struct list_head freeable_maps;
- /* lock protects maps and freeable_maps */
- struct mutex lock;
- struct mm_struct *mm;
- struct mmu_notifier mn;
-
-#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
- /* Device for which DMA memory is allocated. */
- struct device *dma_dev;
-#endif
-};
-
-struct unmap_notify {
- int flags;
- /* Address relative to the start of the grant_map */
- int addr;
- int event;
-};
-
-struct grant_map {
- struct list_head next;
- struct vm_area_struct *vma;
- int index;
-
[Xen-devel] [PATCH v5 3/8] xen/grant-table: Allow allocating buffers suitable for DMA
From: Oleksandr Andrushchenko
Extend grant table module API to allow allocating buffers that can
be used for DMA operations and mapping foreign grant references
on top of those.
The resulting buffer is similar to the one allocated by the balloon
driver in that proper memory reservation is made by
({increase|decrease}_reservation and VA mappings are updated if
needed).
This is useful for sharing foreign buffers with HW drivers which
cannot work with scattered buffers provided by the balloon driver,
but require DMAable memory instead.
Signed-off-by: Oleksandr Andrushchenko
Reviewed-by: Boris Ostrovsky
---
drivers/xen/Kconfig | 14 ++
drivers/xen/grant-table.c | 97 +++
include/xen/grant_table.h | 18
3 files changed, 129 insertions(+)
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index e5d0c28372ea..75e5c40f80a5 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -161,6 +161,20 @@ config XEN_GRANT_DEV_ALLOC
to other domains. This can be used to implement frontend drivers
or as part of an inter-domain shared memory channel.
+config XEN_GRANT_DMA_ALLOC
+ bool "Allow allocating DMA capable buffers with grant reference module"
+ depends on XEN && HAS_DMA
+ help
+ Extends grant table module API to allow allocating DMA capable
+ buffers and mapping foreign grant references on top of it.
+ The resulting buffer is similar to one allocated by the balloon
+ driver in that proper memory reservation is made by
+ ({increase|decrease}_reservation and VA mappings are updated if
+ needed).
+ This is useful for sharing foreign buffers with HW drivers which
+ cannot work with scattered buffers provided by the balloon driver,
+ but require DMAable memory instead.
+
config SWIOTLB_XEN
def_bool y
select SWIOTLB
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index bb4840653bf2..7bafa703a992 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -45,6 +45,9 @@
#include
#include
#include
+#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
+#include
+#endif
#include
#include
@@ -57,6 +60,7 @@
#ifdef CONFIG_X86
#include
#endif
+#include
#include
#include
@@ -838,6 +842,99 @@ void gnttab_free_pages(int nr_pages, struct page **pages)
}
EXPORT_SYMBOL_GPL(gnttab_free_pages);
+#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
+/**
+ * gnttab_dma_alloc_pages - alloc DMAable pages suitable for grant mapping into
+ * @args: arguments to the function
+ */
+int gnttab_dma_alloc_pages(struct gnttab_dma_alloc_args *args)
+{
+ unsigned long pfn, start_pfn;
+ size_t size;
+ int i, ret;
+
+ size = args->nr_pages << PAGE_SHIFT;
+ if (args->coherent)
+ args->vaddr = dma_alloc_coherent(args->dev, size,
+>dev_bus_addr,
+GFP_KERNEL | __GFP_NOWARN);
+ else
+ args->vaddr = dma_alloc_wc(args->dev, size,
+ >dev_bus_addr,
+ GFP_KERNEL | __GFP_NOWARN);
+ if (!args->vaddr) {
+ pr_debug("Failed to allocate DMA buffer of size %zu\n", size);
+ return -ENOMEM;
+ }
+
+ start_pfn = __phys_to_pfn(args->dev_bus_addr);
+ for (pfn = start_pfn, i = 0; pfn < start_pfn + args->nr_pages;
+ pfn++, i++) {
+ struct page *page = pfn_to_page(pfn);
+
+ args->pages[i] = page;
+ args->frames[i] = xen_page_to_gfn(page);
+ xenmem_reservation_scrub_page(page);
+ }
+
+ xenmem_reservation_va_mapping_reset(args->nr_pages, args->pages);
+
+ ret = xenmem_reservation_decrease(args->nr_pages, args->frames);
+ if (ret != args->nr_pages) {
+ pr_debug("Failed to decrease reservation for DMA buffer\n");
+ ret = -EFAULT;
+ goto fail;
+ }
+
+ ret = gnttab_pages_set_private(args->nr_pages, args->pages);
+ if (ret < 0)
+ goto fail;
+
+ return 0;
+
+fail:
+ gnttab_dma_free_pages(args);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(gnttab_dma_alloc_pages);
+
+/**
+ * gnttab_dma_free_pages - free DMAable pages
+ * @args: arguments to the function
+ */
+int gnttab_dma_free_pages(struct gnttab_dma_alloc_args *args)
+{
+ size_t size;
+ int i, ret;
+
+ gnttab_pages_clear_private(args->nr_pages, args->pages);
+
+ for (i = 0; i < args->nr_pages; i++)
+ args->frames[i] = page_to_xen_pfn(args->pages[i]);
+
+ ret = xenmem_reservation_increase(args->nr_pages, args->frames);
+ if (ret != args->nr_pages) {
+ pr_debug("Failed to decrease reservation for DMA buffer\n");
+ ret = -EFAULT;
+ } else {
+ ret = 0;
+
[Xen-devel] [PATCH v5 1/8] xen/grant-table: Make set/clear page private code shared
From: Oleksandr Andrushchenko
Make set/clear page private code shared and accessible to
other kernel modules which can re-use these instead of open-coding.
Signed-off-by: Oleksandr Andrushchenko
Reviewed-by: Boris Ostrovsky
---
drivers/xen/grant-table.c | 54 +--
include/xen/grant_table.h | 3 +++
2 files changed, 38 insertions(+), 19 deletions(-)
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index ba9f3eec2bd0..bb4840653bf2 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -769,29 +769,18 @@ void gnttab_free_auto_xlat_frames(void)
}
EXPORT_SYMBOL_GPL(gnttab_free_auto_xlat_frames);
-/**
- * gnttab_alloc_pages - alloc pages suitable for grant mapping into
- * @nr_pages: number of pages to alloc
- * @pages: returns the pages
- */
-int gnttab_alloc_pages(int nr_pages, struct page **pages)
+int gnttab_pages_set_private(int nr_pages, struct page **pages)
{
int i;
- int ret;
-
- ret = alloc_xenballooned_pages(nr_pages, pages);
- if (ret < 0)
- return ret;
for (i = 0; i < nr_pages; i++) {
#if BITS_PER_LONG < 64
struct xen_page_foreign *foreign;
foreign = kzalloc(sizeof(*foreign), GFP_KERNEL);
- if (!foreign) {
- gnttab_free_pages(nr_pages, pages);
+ if (!foreign)
return -ENOMEM;
- }
+
set_page_private(pages[i], (unsigned long)foreign);
#endif
SetPagePrivate(pages[i]);
@@ -799,14 +788,30 @@ int gnttab_alloc_pages(int nr_pages, struct page **pages)
return 0;
}
-EXPORT_SYMBOL_GPL(gnttab_alloc_pages);
+EXPORT_SYMBOL_GPL(gnttab_pages_set_private);
/**
- * gnttab_free_pages - free pages allocated by gnttab_alloc_pages()
- * @nr_pages; number of pages to free
- * @pages: the pages
+ * gnttab_alloc_pages - alloc pages suitable for grant mapping into
+ * @nr_pages: number of pages to alloc
+ * @pages: returns the pages
*/
-void gnttab_free_pages(int nr_pages, struct page **pages)
+int gnttab_alloc_pages(int nr_pages, struct page **pages)
+{
+ int ret;
+
+ ret = alloc_xenballooned_pages(nr_pages, pages);
+ if (ret < 0)
+ return ret;
+
+ ret = gnttab_pages_set_private(nr_pages, pages);
+ if (ret < 0)
+ gnttab_free_pages(nr_pages, pages);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(gnttab_alloc_pages);
+
+void gnttab_pages_clear_private(int nr_pages, struct page **pages)
{
int i;
@@ -818,6 +823,17 @@ void gnttab_free_pages(int nr_pages, struct page **pages)
ClearPagePrivate(pages[i]);
}
}
+}
+EXPORT_SYMBOL_GPL(gnttab_pages_clear_private);
+
+/**
+ * gnttab_free_pages - free pages allocated by gnttab_alloc_pages()
+ * @nr_pages; number of pages to free
+ * @pages: the pages
+ */
+void gnttab_free_pages(int nr_pages, struct page **pages)
+{
+ gnttab_pages_clear_private(nr_pages, pages);
free_xenballooned_pages(nr_pages, pages);
}
EXPORT_SYMBOL_GPL(gnttab_free_pages);
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index 2e37741f6b8d..de03f2542bb7 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -198,6 +198,9 @@ void gnttab_free_auto_xlat_frames(void);
int gnttab_alloc_pages(int nr_pages, struct page **pages);
void gnttab_free_pages(int nr_pages, struct page **pages);
+int gnttab_pages_set_private(int nr_pages, struct page **pages);
+void gnttab_pages_clear_private(int nr_pages, struct page **pages);
+
int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
struct gnttab_map_grant_ref *kmap_ops,
struct page **pages, unsigned int count);
--
2.18.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v5 8/8] xen/gntdev: Implement dma-buf import functionality
From: Oleksandr Andrushchenko
1. Import a dma-buf with the file descriptor provided and export
granted references to the pages of that dma-buf into the array
of grant references.
2. Add API to close all references to an imported buffer, so it can be
released by the owner. This is only valid for buffers created with
IOCTL_GNTDEV_DMABUF_IMP_TO_REFS.
Signed-off-by: Oleksandr Andrushchenko
Reviewed-by: Boris Ostrovsky
---
drivers/xen/gntdev-dmabuf.c | 239 +++-
1 file changed, 234 insertions(+), 5 deletions(-)
diff --git a/drivers/xen/gntdev-dmabuf.c b/drivers/xen/gntdev-dmabuf.c
index cc4f16c81919..e4c9f1f74476 100644
--- a/drivers/xen/gntdev-dmabuf.c
+++ b/drivers/xen/gntdev-dmabuf.c
@@ -21,6 +21,15 @@
#include "gntdev-common.h"
#include "gntdev-dmabuf.h"
+#ifndef GRANT_INVALID_REF
+/*
+ * Note on usage of grant reference 0 as invalid grant reference:
+ * grant reference 0 is valid, but never exposed to a driver,
+ * because of the fact it is already in use/reserved by the PV console.
+ */
+#define GRANT_INVALID_REF 0
+#endif
+
struct gntdev_dmabuf {
struct gntdev_dmabuf_priv *priv;
struct dma_buf *dmabuf;
@@ -35,6 +44,14 @@ struct gntdev_dmabuf {
struct gntdev_priv *priv;
struct gntdev_grant_map *map;
} exp;
+ struct {
+ /* Granted references of the imported buffer. */
+ grant_ref_t *refs;
+ /* Scatter-gather table of the imported buffer. */
+ struct sg_table *sgt;
+ /* dma-buf attachment of the imported buffer. */
+ struct dma_buf_attachment *attach;
+ } imp;
} u;
/* Number of pages this buffer has. */
@@ -59,6 +76,8 @@ struct gntdev_dmabuf_priv {
struct list_head exp_list;
/* List of wait objects. */
struct list_head exp_wait_list;
+ /* List of imported DMA buffers. */
+ struct list_head imp_list;
/* This is the lock which protects dma_buf_xxx lists. */
struct mutex lock;
};
@@ -491,21 +510,230 @@ static int dmabuf_exp_from_refs(struct gntdev_priv
*priv, int flags,
/* DMA buffer import support. */
+static int
+dmabuf_imp_grant_foreign_access(struct page **pages, u32 *refs,
+ int count, int domid)
+{
+ grant_ref_t priv_gref_head;
+ int i, ret;
+
+ ret = gnttab_alloc_grant_references(count, _gref_head);
+ if (ret < 0) {
+ pr_debug("Cannot allocate grant references, ret %d\n", ret);
+ return ret;
+ }
+
+ for (i = 0; i < count; i++) {
+ int cur_ref;
+
+ cur_ref = gnttab_claim_grant_reference(_gref_head);
+ if (cur_ref < 0) {
+ ret = cur_ref;
+ pr_debug("Cannot claim grant reference, ret %d\n", ret);
+ goto out;
+ }
+
+ gnttab_grant_foreign_access_ref(cur_ref, domid,
+ xen_page_to_gfn(pages[i]), 0);
+ refs[i] = cur_ref;
+ }
+
+ return 0;
+
+out:
+ gnttab_free_grant_references(priv_gref_head);
+ return ret;
+}
+
+static void dmabuf_imp_end_foreign_access(u32 *refs, int count)
+{
+ int i;
+
+ for (i = 0; i < count; i++)
+ if (refs[i] != GRANT_INVALID_REF)
+ gnttab_end_foreign_access(refs[i], 0, 0UL);
+}
+
+static void dmabuf_imp_free_storage(struct gntdev_dmabuf *gntdev_dmabuf)
+{
+ kfree(gntdev_dmabuf->pages);
+ kfree(gntdev_dmabuf->u.imp.refs);
+ kfree(gntdev_dmabuf);
+}
+
+static struct gntdev_dmabuf *dmabuf_imp_alloc_storage(int count)
+{
+ struct gntdev_dmabuf *gntdev_dmabuf;
+ int i;
+
+ gntdev_dmabuf = kzalloc(sizeof(*gntdev_dmabuf), GFP_KERNEL);
+ if (!gntdev_dmabuf)
+ goto fail;
+
+ gntdev_dmabuf->u.imp.refs = kcalloc(count,
+
sizeof(gntdev_dmabuf->u.imp.refs[0]),
+ GFP_KERNEL);
+ if (!gntdev_dmabuf->u.imp.refs)
+ goto fail;
+
+ gntdev_dmabuf->pages = kcalloc(count,
+ sizeof(gntdev_dmabuf->pages[0]),
+ GFP_KERNEL);
+ if (!gntdev_dmabuf->pages)
+ goto fail;
+
+ gntdev_dmabuf->nr_pages = count;
+
+ for (i = 0; i < count; i++)
+ gntdev_dmabuf->u.imp.refs[i] = GRANT_INVALID_REF;
+
+ return gntdev_dmabuf;
+
+fail:
+ dmabuf_imp_free_storage(gntdev_dmabuf);
+ return ERR_PTR(-ENOMEM);
+}
+
static struct gntdev_dmabuf *
dmabuf_imp_to_refs(struct gntdev_dmabuf_priv *priv, struct device *dev,
int fd, int count, int domid)
{
- return ERR_PTR(-ENOMEM);
+
[Xen-devel] [PATCH v5 0/8] xen: dma-buf support for grant device
From: Oleksandr Andrushchenko This work is in response to my previous attempt to introduce Xen/DRM zero-copy driver [1] to enable Linux dma-buf API [2] for Xen based frontends/backends. There is also an existing hyper_dmabuf approach available [3] which, if reworked to utilize the proposed solution, can greatly benefit as well. RFC for this series was published and discussed [9], comments addressed. The original rationale behind this work was to enable zero-copying use-cases while working with Xen para-virtual display driver [4]: when using Xen PV DRM frontend driver then on backend side one will need to do copying of display buffers' contents (filled by the frontend's user-space) into buffers allocated at the backend side. Taking into account the size of display buffers and frames per second it may result in unneeded huge data bus occupation and performance loss. The helper driver [4] allows implementing zero-copying use-cases when using Xen para-virtualized frontend display driver by implementing a DRM/KMS helper driver running on backend's side. It utilizes PRIME buffers API (implemented on top of Linux dma-buf) to share frontend's buffers with physical device drivers on backend's side: - a dumb buffer created on backend's side can be shared with the Xen PV frontend driver, so it directly writes into backend's domain memory (into the buffer exported from DRM/KMS driver of a physical display device) - a dumb buffer allocated by the frontend can be imported into physical device DRM/KMS driver, thus allowing to achieve no copying as well Finally, it was discussed and decided ([1], [5]) that it is worth implementing such use-cases via extension of the existing Xen gntdev driver instead of introducing new DRM specific driver. Please note, that the support of dma-buf is Linux only, as dma-buf is a Linux only thing. Now to the proposed solution. The changes to the existing Xen drivers in the Linux kernel fall into 2 categories: 1. DMA-able memory buffer allocation and increasing/decreasing memory reservation of the pages of such a buffer. This is required if we are about to share dma-buf with the hardware that does require those to be allocated with dma_alloc_xxx API. (It is still possible to allocate a dma-buf from any system memory, e.g. system pages). 2. Extension of the gntdev driver to enable it to import/export dma-buf’s. The first five patches are in preparation for Xen dma-buf support, but I consider those usable regardless of the dma-buf use-case, e.g. other frontend/backend kernel modules may also benefit from these for better code reuse: 0001-xen-grant-table-Make-set-clear-page-private-code-sha.patch 0002-xen-balloon-Share-common-memory-reservation-routines.patch 0003-xen-grant-table-Allow-allocating-buffers-suitable-fo.patch 0004-xen-gntdev-Allow-mappings-for-DMA-buffers.patch 0005-xen-gntdev-Make-private-routines-structures-accessib.patch The next three patches are Xen implementation of dma-buf as part of the grant device: 0006-xen-gntdev-Add-initial-support-for-dma-buf-UAPI.patch 0007-xen-gntdev-Implement-dma-buf-export-functionality.patch 0008-xen-gntdev-Implement-dma-buf-import-functionality.patch The corresponding libxengnttab changes are available at [6]. All the above was tested with display backend [7] and its accompanying helper library [8] on Renesas ARM64 based board. Basic balloon tests on x86. *To all the communities*: I would like to ask you to review the proposed solution and give feedback on it, so I can improve and send final patches for review (this is still work in progress, but enough to start discussing the implementation). Thank you in advance, Oleksandr Andrushchenko [1] https://lists.freedesktop.org/archives/dri-devel/2018-April/173163.html [2] https://elixir.bootlin.com/linux/v4.17-rc5/source/Documentation/driver-api/dma-buf.rst [3] https://lists.xenproject.org/archives/html/xen-devel/2018-02/msg01202.html [4] https://cgit.freedesktop.org/drm/drm-misc/tree/drivers/gpu/drm/xen [5] https://patchwork.kernel.org/patch/10279681/ [6] https://github.com/andr2000/xen/tree/xen_dma_buf_v1 [7] https://github.com/andr2000/displ_be/tree/xen_dma_buf_v1 [8] https://github.com/andr2000/libxenbe/tree/xen_dma_buf_v1 [9] https://lkml.org/lkml/2018/5/17/215 Changes since v4: * - added r-b tags - rebased onto v4.18-rc5 Changes since v3: * - added r-b tags - minor fixes - removed gntdev_remove_map as it can be coded directly now - moved IOCTL code to gntdev-dmabuf.c - removed usless wait list walks and changed some walks to use normal version of list iterators instead of safe ones as we run under a lock anyways - cleaned up comments, descriptions, pr_debug messages Changes since v2: * - fixed missed break in dmabuf_exp_wait_obj_signal - re-worked debug and error messages, be less verbose - removed patch for making gntdev functions available to other drivers -
[Xen-devel] [PATCH v5 7/8] xen/gntdev: Implement dma-buf export functionality
From: Oleksandr Andrushchenko
1. Create a dma-buf from grant references provided by the foreign
domain. By default dma-buf is backed by system memory pages, but
by providing GNTDEV_DMA_FLAG_XXX flags it can also be created
as a DMA write-combine/coherent buffer, e.g. allocated with
corresponding dma_alloc_xxx API.
Export the resulting buffer as a new dma-buf.
2. Implement waiting for the dma-buf to be released: block until the
dma-buf with the file descriptor provided is released.
If within the time-out provided the buffer is not released then
-ETIMEDOUT error is returned. If the buffer with the file descriptor
does not exist or has already been released, then -ENOENT is
returned. For valid file descriptors this must not be treated as
error.
3. Make gntdev's common code and structures available to dma-buf.
Signed-off-by: Oleksandr Andrushchenko
Reviewed-by: Boris Ostrovsky
---
drivers/xen/gntdev-dmabuf.c | 455 +++-
1 file changed, 452 insertions(+), 3 deletions(-)
diff --git a/drivers/xen/gntdev-dmabuf.c b/drivers/xen/gntdev-dmabuf.c
index af782c0a8a19..cc4f16c81919 100644
--- a/drivers/xen/gntdev-dmabuf.c
+++ b/drivers/xen/gntdev-dmabuf.c
@@ -3,11 +3,14 @@
/*
* Xen dma-buf functionality for gntdev.
*
+ * DMA buffer implementation is based on drivers/gpu/drm/drm_prime.c.
+ *
* Copyright (c) 2018 Oleksandr Andrushchenko, EPAM Systems Inc.
*/
#include
#include
+#include
#include
#include
#include
@@ -18,6 +21,39 @@
#include "gntdev-common.h"
#include "gntdev-dmabuf.h"
+struct gntdev_dmabuf {
+ struct gntdev_dmabuf_priv *priv;
+ struct dma_buf *dmabuf;
+ struct list_head next;
+ int fd;
+
+ union {
+ struct {
+ /* Exported buffers are reference counted. */
+ struct kref refcount;
+
+ struct gntdev_priv *priv;
+ struct gntdev_grant_map *map;
+ } exp;
+ } u;
+
+ /* Number of pages this buffer has. */
+ int nr_pages;
+ /* Pages of this buffer. */
+ struct page **pages;
+};
+
+struct gntdev_dmabuf_wait_obj {
+ struct list_head next;
+ struct gntdev_dmabuf *gntdev_dmabuf;
+ struct completion completion;
+};
+
+struct gntdev_dmabuf_attachment {
+ struct sg_table *sgt;
+ enum dma_data_direction dir;
+};
+
struct gntdev_dmabuf_priv {
/* List of exported DMA buffers. */
struct list_head exp_list;
@@ -31,17 +67,426 @@ struct gntdev_dmabuf_priv {
/* Implementation of wait for exported DMA buffer to be released. */
+static void dmabuf_exp_release(struct kref *kref);
+
+static struct gntdev_dmabuf_wait_obj *
+dmabuf_exp_wait_obj_new(struct gntdev_dmabuf_priv *priv,
+ struct gntdev_dmabuf *gntdev_dmabuf)
+{
+ struct gntdev_dmabuf_wait_obj *obj;
+
+ obj = kzalloc(sizeof(*obj), GFP_KERNEL);
+ if (!obj)
+ return ERR_PTR(-ENOMEM);
+
+ init_completion(>completion);
+ obj->gntdev_dmabuf = gntdev_dmabuf;
+
+ mutex_lock(>lock);
+ list_add(>next, >exp_wait_list);
+ /* Put our reference and wait for gntdev_dmabuf's release to fire. */
+ kref_put(_dmabuf->u.exp.refcount, dmabuf_exp_release);
+ mutex_unlock(>lock);
+ return obj;
+}
+
+static void dmabuf_exp_wait_obj_free(struct gntdev_dmabuf_priv *priv,
+struct gntdev_dmabuf_wait_obj *obj)
+{
+ mutex_lock(>lock);
+ list_del(>next);
+ mutex_unlock(>lock);
+ kfree(obj);
+}
+
+static int dmabuf_exp_wait_obj_wait(struct gntdev_dmabuf_wait_obj *obj,
+ u32 wait_to_ms)
+{
+ if (wait_for_completion_timeout(>completion,
+ msecs_to_jiffies(wait_to_ms)) <= 0)
+ return -ETIMEDOUT;
+
+ return 0;
+}
+
+static void dmabuf_exp_wait_obj_signal(struct gntdev_dmabuf_priv *priv,
+ struct gntdev_dmabuf *gntdev_dmabuf)
+{
+ struct gntdev_dmabuf_wait_obj *obj;
+
+ list_for_each_entry(obj, >exp_wait_list, next)
+ if (obj->gntdev_dmabuf == gntdev_dmabuf) {
+ pr_debug("Found gntdev_dmabuf in the wait list,
wake\n");
+ complete_all(>completion);
+ break;
+ }
+}
+
+static struct gntdev_dmabuf *
+dmabuf_exp_wait_obj_get_dmabuf(struct gntdev_dmabuf_priv *priv, int fd)
+{
+ struct gntdev_dmabuf *gntdev_dmabuf, *ret = ERR_PTR(-ENOENT);
+
+ mutex_lock(>lock);
+ list_for_each_entry(gntdev_dmabuf, >exp_list, next)
+ if (gntdev_dmabuf->fd == fd) {
+ pr_debug("Found gntdev_dmabuf in the wait list\n");
+ kref_get(_dmabuf->u.exp.refcount);
+ ret = gntdev_dmabuf;
+ break;
+ }
+
[Xen-devel] [PATCH v5 6/8] xen/gntdev: Add initial support for dma-buf UAPI
From: Oleksandr Andrushchenko
Add UAPI and IOCTLs for dma-buf grant device driver extension:
the extension allows userspace processes and kernel modules to
use Xen backed dma-buf implementation. With this extension grant
references to the pages of an imported dma-buf can be exported
for other domain use and grant references coming from a foreign
domain can be converted into a local dma-buf for local export.
Implement basic initialization and stubs for Xen DMA buffers'
support.
Signed-off-by: Oleksandr Andrushchenko
Reviewed-by: Boris Ostrovsky
---
drivers/xen/Kconfig | 10 ++
drivers/xen/Makefile| 1 +
drivers/xen/gntdev-common.h | 6 ++
drivers/xen/gntdev-dmabuf.c | 177
drivers/xen/gntdev-dmabuf.h | 33 +++
drivers/xen/gntdev.c| 31 +++
include/uapi/xen/gntdev.h | 91 ++
7 files changed, 349 insertions(+)
create mode 100644 drivers/xen/gntdev-dmabuf.c
create mode 100644 drivers/xen/gntdev-dmabuf.h
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 75e5c40f80a5..b459edfacff3 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -152,6 +152,16 @@ config XEN_GNTDEV
help
Allows userspace processes to use grants.
+config XEN_GNTDEV_DMABUF
+ bool "Add support for dma-buf grant access device driver extension"
+ depends on XEN_GNTDEV && XEN_GRANT_DMA_ALLOC && DMA_SHARED_BUFFER
+ help
+ Allows userspace processes and kernel modules to use Xen backed
+ dma-buf implementation. With this extension grant references to
+ the pages of an imported dma-buf can be exported for other domain
+ use and grant references coming from a foreign domain can be
+ converted into a local dma-buf for local export.
+
config XEN_GRANT_DEV_ALLOC
tristate "User-space grant reference allocator driver"
depends on XEN
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 129dd1cc1b83..3e542f60f29f 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -41,5 +41,6 @@ obj-$(CONFIG_XEN_PVCALLS_BACKEND) += pvcalls-back.o
obj-$(CONFIG_XEN_PVCALLS_FRONTEND) += pvcalls-front.o
xen-evtchn-y := evtchn.o
xen-gntdev-y := gntdev.o
+xen-gntdev-$(CONFIG_XEN_GNTDEV_DMABUF) += gntdev-dmabuf.o
xen-gntalloc-y := gntalloc.o
xen-privcmd-y := privcmd.o privcmd-buf.o
diff --git a/drivers/xen/gntdev-common.h b/drivers/xen/gntdev-common.h
index 2346c198f72e..2f8b949c3eeb 100644
--- a/drivers/xen/gntdev-common.h
+++ b/drivers/xen/gntdev-common.h
@@ -16,6 +16,8 @@
#include
#include
+struct gntdev_dmabuf_priv;
+
struct gntdev_priv {
/* Maps with visible offsets in the file descriptor. */
struct list_head maps;
@@ -33,6 +35,10 @@ struct gntdev_priv {
/* Device for which DMA memory is allocated. */
struct device *dma_dev;
#endif
+
+#ifdef CONFIG_XEN_GNTDEV_DMABUF
+ struct gntdev_dmabuf_priv *dmabuf_priv;
+#endif
};
struct gntdev_unmap_notify {
diff --git a/drivers/xen/gntdev-dmabuf.c b/drivers/xen/gntdev-dmabuf.c
new file mode 100644
index ..af782c0a8a19
--- /dev/null
+++ b/drivers/xen/gntdev-dmabuf.c
@@ -0,0 +1,177 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/*
+ * Xen dma-buf functionality for gntdev.
+ *
+ * Copyright (c) 2018 Oleksandr Andrushchenko, EPAM Systems Inc.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include "gntdev-common.h"
+#include "gntdev-dmabuf.h"
+
+struct gntdev_dmabuf_priv {
+ /* List of exported DMA buffers. */
+ struct list_head exp_list;
+ /* List of wait objects. */
+ struct list_head exp_wait_list;
+ /* This is the lock which protects dma_buf_xxx lists. */
+ struct mutex lock;
+};
+
+/* DMA buffer export support. */
+
+/* Implementation of wait for exported DMA buffer to be released. */
+
+static int dmabuf_exp_wait_released(struct gntdev_dmabuf_priv *priv, int fd,
+ int wait_to_ms)
+{
+ return -EINVAL;
+}
+
+static int dmabuf_exp_from_refs(struct gntdev_priv *priv, int flags,
+ int count, u32 domid, u32 *refs, u32 *fd)
+{
+ *fd = -1;
+ return -EINVAL;
+}
+
+/* DMA buffer import support. */
+
+static struct gntdev_dmabuf *
+dmabuf_imp_to_refs(struct gntdev_dmabuf_priv *priv, struct device *dev,
+ int fd, int count, int domid)
+{
+ return ERR_PTR(-ENOMEM);
+}
+
+static u32 *dmabuf_imp_get_refs(struct gntdev_dmabuf *gntdev_dmabuf)
+{
+ return NULL;
+}
+
+static int dmabuf_imp_release(struct gntdev_dmabuf_priv *priv, u32 fd)
+{
+ return -EINVAL;
+}
+
+/* DMA buffer IOCTL support. */
+
+long gntdev_ioctl_dmabuf_exp_from_refs(struct gntdev_priv *priv, int
use_ptemod,
+ struct ioctl_gntdev_dmabuf_exp_from_refs
[Xen-devel] [PATCH v5 2/8] xen/balloon: Share common memory reservation routines
From: Oleksandr Andrushchenko
Memory {increase|decrease}_reservation and VA mappings update/reset
code used in balloon driver can be made common, so other drivers can
also re-use the same functionality without open-coding.
Create a dedicated file for the shared code and export corresponding
symbols for other kernel modules.
Signed-off-by: Oleksandr Andrushchenko
Reviewed-by: Boris Ostrovsky
---
drivers/xen/Makefile | 1 +
drivers/xen/balloon.c | 75 ++---
drivers/xen/mem-reservation.c | 118 ++
include/xen/mem-reservation.h | 59 +
4 files changed, 184 insertions(+), 69 deletions(-)
create mode 100644 drivers/xen/mem-reservation.c
create mode 100644 include/xen/mem-reservation.h
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 48b154276179..129dd1cc1b83 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -2,6 +2,7 @@
obj-$(CONFIG_HOTPLUG_CPU) += cpu_hotplug.o
obj-$(CONFIG_X86) += fallback.o
obj-y += grant-table.o features.o balloon.o manage.o preempt.o time.o
+obj-y += mem-reservation.o
obj-y += events/
obj-y += xenbus/
diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index 065f0b607373..e12bb256036f 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -71,6 +71,7 @@
#include
#include
#include
+#include
static int xen_hotplug_unpopulated;
@@ -157,13 +158,6 @@ static DECLARE_DELAYED_WORK(balloon_worker,
balloon_process);
#define GFP_BALLOON \
(GFP_HIGHUSER | __GFP_NOWARN | __GFP_NORETRY | __GFP_NOMEMALLOC)
-static void scrub_page(struct page *page)
-{
-#ifdef CONFIG_XEN_SCRUB_PAGES
- clear_highpage(page);
-#endif
-}
-
/* balloon_append: add the given page to the balloon. */
static void __balloon_append(struct page *page)
{
@@ -463,11 +457,6 @@ static enum bp_state increase_reservation(unsigned long
nr_pages)
int rc;
unsigned long i;
struct page *page;
- struct xen_memory_reservation reservation = {
- .address_bits = 0,
- .extent_order = EXTENT_ORDER,
- .domid= DOMID_SELF
- };
if (nr_pages > ARRAY_SIZE(frame_list))
nr_pages = ARRAY_SIZE(frame_list);
@@ -479,16 +468,11 @@ static enum bp_state increase_reservation(unsigned long
nr_pages)
break;
}
- /* XENMEM_populate_physmap requires a PFN based on Xen
-* granularity.
-*/
frame_list[i] = page_to_xen_pfn(page);
page = balloon_next_page(page);
}
- set_xen_guest_handle(reservation.extent_start, frame_list);
- reservation.nr_extents = nr_pages;
- rc = HYPERVISOR_memory_op(XENMEM_populate_physmap, );
+ rc = xenmem_reservation_increase(nr_pages, frame_list);
if (rc <= 0)
return BP_EAGAIN;
@@ -496,29 +480,7 @@ static enum bp_state increase_reservation(unsigned long
nr_pages)
page = balloon_retrieve(false);
BUG_ON(page == NULL);
-#ifdef CONFIG_XEN_HAVE_PVMMU
- /*
-* We don't support PV MMU when Linux and Xen is using
-* different page granularity.
-*/
- BUILD_BUG_ON(XEN_PAGE_SIZE != PAGE_SIZE);
-
- if (!xen_feature(XENFEAT_auto_translated_physmap)) {
- unsigned long pfn = page_to_pfn(page);
-
- set_phys_to_machine(pfn, frame_list[i]);
-
- /* Link back into the page tables if not highmem. */
- if (!PageHighMem(page)) {
- int ret;
- ret = HYPERVISOR_update_va_mapping(
- (unsigned long)__va(pfn <<
PAGE_SHIFT),
- mfn_pte(frame_list[i],
PAGE_KERNEL),
- 0);
- BUG_ON(ret);
- }
- }
-#endif
+ xenmem_reservation_va_mapping_update(1, , _list[i]);
/* Relinquish the page back to the allocator. */
free_reserved_page(page);
@@ -535,11 +497,6 @@ static enum bp_state decrease_reservation(unsigned long
nr_pages, gfp_t gfp)
unsigned long i;
struct page *page, *tmp;
int ret;
- struct xen_memory_reservation reservation = {
- .address_bits = 0,
- .extent_order = EXTENT_ORDER,
- .domid= DOMID_SELF
- };
LIST_HEAD(pages);
if (nr_pages > ARRAY_SIZE(frame_list))
@@ -553,7 +510,7 @@ static enum bp_state decrease_reservation(unsigned long
nr_pages, gfp_t gfp)
break;
}
adjust_managed_page_count(page, -1);
-
Re: [Xen-devel] [PATCH] lzma: fix hypervisor build
On Fri, Jul 20, 2018 at 10:32:42AM +0200, Roger Pau Monne wrote: > Remove local definition of MIN and instead include the kernel.h header > for the hypervisor build. Fixes the following error on the tools build: > > In file included from xc_dom_decompress_unsafe_lzma.c:8:0: > ../../xen/common/unlzma.c:33:0: error: "MIN" redefined [-Werror] > #define MIN(a, b) (((a) < (b)) ? (a) : (b)) > ^ > In file included from xc_private.h:43:0, > from xg_private.h:29, > from xc_dom_decompress_unsafe_lzma.c:5: > /home/osstest/build.125458.build-amd64/xen/stubdom/libxc-x86_64/../../tools/include/xen-tools/libs.h:21:0: > note: this is the location of the previous definition > #define MIN(x, y) ((x) < (y) ? (x) : (y)) > ^ > > Signed-off-by: Roger Pau Monné Acked-by: Wei Liu Strangely I never saw this during my build. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 10/13] x86: add iommu_op to enable modification of IOMMU mappings
On Tue, Jul 17, 2018 at 02:38:13PM +0100, Paul Durrant wrote:
> +static int iommu_op_enable_modification(void)
> +{
> +struct domain *currd = current->domain;
> +struct domain_iommu *iommu = dom_iommu(currd);
> +const struct iommu_ops *ops = iommu->platform_ops;
> +
> +/* Has modification already been enabled? */
> +if ( iommu->iommu_op_ranges )
> +return 0;
> +
> +/*
> + * The IOMMU mappings cannot be modified if:
> + * - the IOMMU is not enabled or,
> + * - the current domain is dom0 and tranlsation is disabled or,
> + * - HAP is enabled and the IOMMU shares the mappings.
> + */
> +if ( !iommu_enabled ||
> + (is_hardware_domain(currd) && iommu_passthrough) ||
> + iommu_use_hap_pt(currd) )
> +return -EACCES;
> +
> +/*
> + * The IOMMU implementation must provide the lookup method if
> + * modification of the mappings is to be supported.
> + */
> +if ( !ops->lookup_page )
> +return -EOPNOTSUPP;
> +
> +iommu->iommu_op_ranges = rangeset_new(currd, NULL, 0);
> +if ( !iommu->iommu_op_ranges )
> +return -ENOMEM;
> +
> +currd->need_iommu = 0; /* Disable identity GFN mapping */
I think this flag currently serves two purposes: one is to indicate
whether there are resources allocated within xen, the other it indicate
whether it is in use (as suggested in the comment).
Suppose a domain gets all its devices deassigned after this call,
original iommu_teardown would have been called, but now it won't. The
iommu will still be torn down when it is destroyed, but this is a very
subtle change in behaviour.
IMHO we should clearly separate these two cases if possible.
> +return 0;
> +}
> +
[...]
> diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
> index fb9d0e1848..c517428621 100644
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -26,7 +26,6 @@ static void iommu_dump_p2m_table(unsigned char key);
>
> unsigned int __read_mostly iommu_dev_iotlb_timeout = 1000;
> integer_param("iommu_dev_iotlb_timeout", iommu_dev_iotlb_timeout);
> -
Please keep the blank line here.
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] lzma: fix hypervisor build
The subject should be 'lzma: fix tools build'. Roger. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] lzma: fix hypervisor build
Remove local definition of MIN and instead include the kernel.h header
for the hypervisor build. Fixes the following error on the tools build:
In file included from xc_dom_decompress_unsafe_lzma.c:8:0:
../../xen/common/unlzma.c:33:0: error: "MIN" redefined [-Werror]
#define MIN(a, b) (((a) < (b)) ? (a) : (b))
^
In file included from xc_private.h:43:0,
from xg_private.h:29,
from xc_dom_decompress_unsafe_lzma.c:5:
/home/osstest/build.125458.build-amd64/xen/stubdom/libxc-x86_64/../../tools/include/xen-tools/libs.h:21:0:
note: this is the location of the previous definition
#define MIN(x, y) ((x) < (y) ? (x) : (y))
^
Signed-off-by: Roger Pau Monné
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
---
xen/common/unlzma.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/xen/common/unlzma.c b/xen/common/unlzma.c
index e072e21599..9134277bba 100644
--- a/xen/common/unlzma.c
+++ b/xen/common/unlzma.c
@@ -30,8 +30,6 @@
#include "decompress.h"
-#defineMIN(a, b) (((a) < (b)) ? (a) : (b))
-
static long long INIT read_int(unsigned char *ptr, int size)
{
int i;
@@ -55,6 +53,7 @@ static long long INIT read_int(unsigned char *ptr, int size)
#ifdef __XEN__
#include
+#include
#endif
#define LZMA_IOBUF_SIZE0x1
--
2.18.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf baseline-only test] 74990: regressions - FAIL
This run is configured for baseline tests only. flight 74990 ovmf real [real] http://osstest.xensource.com/osstest/logs/74990/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 74986 version targeted for testing: ovmf da417eb8ed4bbaf149c31d197eb56fc8a5abbf68 baseline version: ovmf d900d7c9857a676d9271a0ab499c12b379dc3652 Last test of basis74986 2018-07-18 06:58:33 Z2 days Testing same since74990 2018-07-20 06:26:46 Z0 days1 attempts People who touched revisions under test: Achin Gupta Dandan Bi Eric Dong Jian J Wang Laszlo Ersek Sughosh Ganu Supreeth Venkatesh 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 fail test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xensource.com/osstest/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. (No revision log; it would be 411 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 125458: regressions - FAIL
flight 125458 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/125458/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 125432 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a 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 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen d6371ccb93012db4ad6615fe666205b86308cb4e baseline version: xen 3cdac2805692c7accde2f405d81cc0be799aee48 Last test of basis 125432 2018-07-19 14:00:40 Z0 days Testing same since 125439 2018-07-19 19:00:36 Z0 days5 attempts People who touched revisions under test: Andrew Cooper Jan Beulich Roger Pau Monné jobs: build-arm64-xsm pass build-amd64 fail build-armhf pass build-amd64-libvirt blocked test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386 blocked test-amd64-amd64-libvirt 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. commit d6371ccb93012db4ad6615fe666205b86308cb4e Author: Andrew Cooper Date: Wed Jul 18 12:22:55 2018 +0100 x86/xstate: Make errors in xstate calculations more obvious by crashing the domain If xcr0_max exceeds xfeature_mask, then something is broken with the CPUID policy derivation or auditing logic. If hardware rejects new_bv, then something is broken with Xen's xstate logic. In both cases, crash the domain with an obvious error message, to help highlight the issues. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich commit 361b835fa00d9f45167c50a60e054ccf22c065d7 Author: Andrew Cooper Date: Wed Jul 18 11:56:44 2018 +0100 x86/xstate: Use a guests CPUID policy, rather than allowing all features It turns out that Xen has never enforced that a domain remain within the xstate features advertised in CPUID. The check of new_bv against xfeature_mask ensures that a domain stays within the set of features that Xen has enabled in hardware (and therefore isn't a security problem), but this does means that attempts to level a guest for migration safety might not be effective if the guest ignores CPUID. Check the CPUID policy in validate_xstate() (for incoming migration) and in handle_xsetbv() (for guest XSETBV instructions). This subsumes the PKRU check for PV guests in handle_xsetbv() (and also demonstrates that I should have spotted this problem while reviewing c/s fbf9971241f). For migration, this is correct despite the current (mis)ordering of data because d->arch.cpuid is the applicable max policy. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich commit 2e2bd5a29e481d0e7f163a19d663d959e09550fd Author: Andrew Cooper Date: Fri Jun 29 13:05:52 2018 + libx86: Introduce lib/x86/msr.h and share msr_policy with userspace To facilitate the shared Xen and toolstack code in libx86, struct msr_policy needs to be available in the same way as struct cpuid_policy. Signed-off-by: Andrew Cooper Reviewed-by: Wei Liu Reviewed-by: Roger Pau Monné Acked-by: Jan Beulich commit fea2fab9635613d5be83482da5d79160ef928941 Author: Roger Pau Monné Date: Thu Jun 21 15:35:48 2018 +0100 libx86: introduce a libx86 shared library Move x86_cpuid_lookup_deep_deps() into the shared library,
[Xen-devel] [ovmf test] 125454: all pass - PUSHED
flight 125454 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/125454/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf da417eb8ed4bbaf149c31d197eb56fc8a5abbf68 baseline version: ovmf d900d7c9857a676d9271a0ab499c12b379dc3652 Last test of basis 125295 2018-07-18 03:40:40 Z2 days Failing since125302 2018-07-18 07:10:48 Z1 days 16 attempts Testing same since 125454 2018-07-20 03:10:39 Z0 days1 attempts People who touched revisions under test: Achin Gupta Dandan Bi Eric Dong Jian J Wang Laszlo Ersek Sughosh Ganu Supreeth Venkatesh 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 d900d7c985..da417eb8ed da417eb8ed4bbaf149c31d197eb56fc8a5abbf68 -> xen-tested-master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
