[Xen-devel] [xen-4.7-testing test] 119182: regressions - FAIL

[osstest service owner]

flight 119182 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/119182/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-xsm6 xen-buildfail REGR. vs. 118721
 build-amd64-xsm   6 xen-buildfail REGR. vs. 118721
 build-i3866 xen-buildfail REGR. vs. 118721
 build-amd64   6 xen-buildfail REGR. vs. 118721

Tests which did not succeed, but are not blocking:
 build-amd64-rumprun   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win10-i386  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-migrupgrade  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win10-i386  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-ws16-amd64  1 build-check(1) blocked n/a
 test-xtf-amd64-amd64-31 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)  blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-libvirt  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-qemut-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-xtf-amd64-amd64-11 build-check(1)   blocked  n/a
 build-i386-rumprun1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win10-i386  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-win10-i386  1 build-check(1)  blocked n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-41 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-ws16-amd64  1 build-check(1)  blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-migrupgrade   1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a

Re: [Xen-devel] [RFC XEN PATCH v4 00/41] Add vNVDIMM support to HVM domains

[Haozhong Zhang]

On 02/13/18 15:39 +, Roger Pau Monné wrote:
> On Tue, Feb 13, 2018 at 06:40:20AM -0700, Jan Beulich wrote:
> > >>> On 13.02.18 at 12:13,  wrote:
> > > On Tue, Feb 13, 2018 at 04:05:45AM -0700, Jan Beulich wrote:
> > >> >>> On 13.02.18 at 11:29,  wrote:
> > >> > On Tue, Feb 13, 2018 at 03:06:24AM -0700, Jan Beulich wrote:
> > >> >> >>> On 12.02.18 at 11:05,  wrote:
> > >> >> > If you map the NVDIMM as MMIO to Dom0 you don't need the M2P entries
> > >> >> > IIRC, and if it's mapped using 1GB pages it shouldn't use that much
> > >> >> > memory for the page tables (ie: you could just use normal RAM for 
> > >> >> > the
> > >> >> > page tables that map the NVDIMM IMO). Of course that only applies to
> > >> >> > PVH/HVM.
> > >> >> 
> > >> >> But in order to use (part of) it in a RAM-like manner we need struct
> > >> >> page_info for it.
> > >> > 
> > >> > I guess the main use of this would be to grant NVDIMM pages? And
> > >> > without a page_info that's not possible.
> > >> 
> > >> Why grant? Simply giving such a page as RAM to a guest would
> > >> already be a problem without struct page_info (as then we can't
> > >> track the page owner, nor can we refcount the page).
> > > 
> > > My point was to avoid doing that, and always assign the pages as
> > > MMIO, which IIRC doesn't require a struct page_info.
> > 
> > MMIO pages can't be used for things like page tables, because of
> > the refcounting that's needed. The page being like RAM, however,
> > implies that the guest needs to be able to use it as anything a RAM
> > page can be used for.
> 
> OK, I'm quite unsure about what people actually use NVDIMM for, I
> thought it was mostly used as some kind of storage, but if it's
> actually used as plain RAM then yes, we likely need struct page_info
> for them, which is a PITA.
> 
> My worries are that if you boot bare metal Linux and use NVDIMM, and
> then reboot into Xen you won't be able to access the NVDIMM data
> anymore AFAICT because Xen will have taken over it, and already used
> part of it to store it's own page tables, which is problematic IMO.
> 

The page tables for NVDIMM whose size is not large are still kept in
RAM.

This patchset does not let Xen use any NVDIMM at boot time, just
because of your worries. Part 2 of this patchset introduces a set of
xl subcommands to allow users to educate Xen after boot up which parts
of NVDIMM can be safely used by Xen without corrupting the real useful
data. That is, I suppose users to pre-partition the NVDIMM (before
using it with Xen) to at least two parts, one for hypervisor
management purpose and the data in it does not need to preserve across
power cycles, and others for user data which may need to be
non-volatile.

Haozhong

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [RFC XEN PATCH v4 00/41] Add vNVDIMM support to HVM domains

[Haozhong Zhang]

On 02/12/18 10:05 +, Roger Pau Monné wrote:
> On Mon, Feb 12, 2018 at 09:25:42AM +0800, Haozhong Zhang wrote:
> > On 02/09/18 12:33 +, Roger Pau Monné wrote:
> > > Thanks for the series, I'm however wondering whether it's appropriate
> > > to post a v4 as RFC. Ie: at v4 the reviewer expects the submitter to
> > > have a clear picture of what needs to be implemented.
> > > 
> > > On Thu, Dec 07, 2017 at 06:09:49PM +0800, Haozhong Zhang wrote:
> > > > All patches can also be found at
> > > >   Xen:  https://github.com/hzzhan9/xen.git nvdimm-rfc-v4
> > > >   QEMU: https://github.com/hzzhan9/qemu.git xen-nvdimm-rfc-v4
> > > > 
> > > > RFC v3 can be found at
> > > >   https://lists.xen.org/archives/html/xen-devel/2017-09/msg00964.html
> > > > 
> > > > Changes in v4:
> > > >   * Move the functionality of management util 'xen-ndctl' to Xne
> > > > management tool 'xl'.
> > > >   * Load QEMU ACPI via QEMU fw_cfg and BIOSLinkerLoader interface.
> > > >   * Other changes are documented in patches separately.
> > > > 
> > > > 
> > > > - Part 0. Bug fix and code cleanup
> > > >   [01/41] x86_64/mm: fix the PDX group check in mem_hotadd_check()
> > > >   [02/41] x86_64/mm: avoid cleaning the unmapped frame table
> > > >   [03/41] hvmloader/util: do not compare characters after '\0' in 
> > > > strncmp
> > > > 
> > > > - Part 1. Detect host PMEM
> > > >   Detect host PMEM via NFIT. No frametable and M2P table for them are
> > > >   created in this part.
> > > > 
> > > >   [04/41] xen/common: add Kconfig item for pmem support
> > > >   [05/41] x86/mm: exclude PMEM regions from initial frametable
> > > >   [06/41] acpi: probe valid PMEM regions via NFIT
> > > >   [07/41] xen/pmem: register valid PMEM regions to Xen hypervisor
> > > >   [08/41] xen/pmem: hide NFIT and deny access to PMEM from Dom0
> > > 
> > > I'm afraid I might ask stupied questions, since I haven't followed the
> > > design discussion of this series very closely.
> > > 
> > > So you basically hide the NVDIMM from Dom0, and only allow guests to
> > > use it?
> > 
> > Yes, though I have some unsent patches (for vNVDIMM label support) to
> > allow QEMU in dom0 to access NVDIMM via DMOP.
> > 
> > > 
> > > What happens when you boot the same system without Xen? Will the
> > > NVDIMM get corrupted because for example Linux will write something to
> > > it?
> > 
> > Bare metal OS without Xen may write to NVDIMM which may or may not
> > corrupt the data, depending on the existing data on NVDIMM and how
> > other OS uses NVDIMM.
> > 
> > If the bare-metal OS uses NVDIMM, for example, as the volatile memory
> > or the fast disk cache, then the random data may be dumped to NVDIMM
> > and corrupt the existing data.
> > 
> > If the bare-metal OS treats NVDIMM as storage, it may probe certain
> > structures (e.g., file systems) on NVDIMM before further operations
> > and stop if such structures are not probed. In such case, the existing
> > data on NVDIMM will not be corrupted.
> 
> OK. I have to admit my knowledge of NVDIMM is very limited. Is it
> expected to for example partition a NVDIMM into several partitions and
> maybe use one as disk cache and others as storage?
> 
> How would that be accomplished, using GPT for example? Or there's some
> NVDIMM specific way to describe the layout?

NVDIMM is mapped to CPU address space just as regular RAM. Basically
SW can access it via the normal memory access instructions (e.g, mov
on x86) with necessary cache flush operations (e.g, clwb/clflushopt/clflush)
to guarantee the write persistence. Beyond this basic byte-addressable
interface, SW can choose to, for example, use it as the typical
memory, use it as a persistent storage, and even implement a block
interface over it. SW can choose its own method to partition NVDIMM,
maybe via the typical disk partitions and file systems, or the labels
which are provided by NVDIMM.

When those SW runs in a HVM domain, the primary work of Xen is to map
the host NVDIMM address to guest address space in EPT as RW just like
the normal memory virtualization.

> 
> Would it be conceivable to store Dom0 root filesystem in a NVDIMM
> while also using it to provide storage to the guests?

Yes, it's possible, though it's not allowed in this patchset.  We need
to configure Xen hypervisor before booting, to know which part of
NVDIMM is needed to map to Dom0 and where the management structures of
that part of NVDIMM are maintained (e.g., in another part of NVDIM or
in RAM).

Haozhong

> 
> > > 
> > > >   [09/41] xen/pmem: add framework for hypercall XEN_SYSCTL_nvdimm_op
> > > >   [10/41] xen/pmem: add XEN_SYSCTL_nvdimm_pmem_get_rgions_nr
> > > >   [11/41] xen/pmem: add XEN_SYSCTL_nvdimm_pmem_get_regions
> > > >   [12/41] tools/xl: add xl command 'pmem-list'
> > > > 
> > > > - Part 2. Setup host PMEM for management and guest data usage
> > > >   Allow users or admins in Dom0 to setup host PMEM pages for
> > > >   management and guest data usages.
> > > >* Management PMEM pages are 

[Xen-devel] [qemu-mainline test] 119177: regressions - FAIL

[osstest service owner]

flight 119177 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/119177/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-libvirt6 libvirt-buildfail REGR. vs. 119036

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 119036
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 119036
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 119036
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 119036
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 119036
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 119036
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-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-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   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-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-xsm  14 saverestore-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-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  14 saverestore-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-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-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:
 qemuubec9c64ef7be8063f1192608b83877bc5c9ea217
baseline version:
 qemuu7d848450b6e2a3e14a776b4c93704710e7f3d233

Last test of basis   119036  2018-02-13 00:48:14 Z2 days
Failing since119084  2018-02-13 13:53:59 Z1 days2 attempts
Testing same since   119177  2018-02-14 10:35:01 Z0 days1 attempts


People who touched revisions under test:
  Alistair Francis 
  Changpeng Liu 
  Daniel P. Berrange 
  Deniz Eren 
  Dr. David Alan Gilbert 
  Eric Blake 
  Gal Hammer 
  Greg Kurz 
  Hervé Poussineau 
  Igor Mammedov 
  Laszlo Ersek 
  Marc-André Lureau 
  Marcel Apfelbaum 
  Michael S. Tsirkin 
  Paolo Bonzini 
  Pavel Pisa 
  Peter Maydell 
  Peter Xu 
  Philippe Mathieu-Daudé 
  Philippe Mathieu-Daudé 
  Sai Pavan Boddu 
  Tiwei Bie 
  Tomáš G

[Xen-devel] [PATCH 30/30] xen: use the BYTE-based definitions

[Philippe Mathieu-Daudé]

It ease code review, unit is explicit.

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/block/xen_disk.c|  4 ++--
 hw/xenpv/xen_domainbuild.c | 10 +-
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
index f74fcd42d1..557005b5e5 100644
--- a/hw/block/xen_disk.c
+++ b/hw/block/xen_disk.c
@@ -1153,9 +1153,9 @@ static int blk_connect(struct XenDevice *xendev)
 }
 
 xen_pv_printf(xendev, 1, "type \"%s\", fileproto \"%s\", filename \"%s\","
-  " size %" PRId64 " (%" PRId64 " MB)\n",
+  " size %" PRId64 " (%llu MB)\n",
   blkdev->type, blkdev->fileproto, blkdev->filename,
-  blkdev->file_size, blkdev->file_size >> 20);
+  blkdev->file_size, blkdev->file_size / M_BYTE);
 
 /* Fill in number of sector size and number of sectors */
 xenstore_write_be_int(&blkdev->xendev, "sector-size", blkdev->file_blk);
diff --git a/hw/xenpv/xen_domainbuild.c b/hw/xenpv/xen_domainbuild.c
index 027f76fad1..083fb80ee5 100644
--- a/hw/xenpv/xen_domainbuild.c
+++ b/hw/xenpv/xen_domainbuild.c
@@ -75,9 +75,9 @@ int xenstore_domain_init1(const char *kernel, const char 
*ramdisk,
 xenstore_write_str(dom, "vm", vm);
 
 /* memory */
-xenstore_write_int(dom, "memory/target", ram_size >> 10);  // kB
-xenstore_write_int(vm, "memory", ram_size >> 20);  // MB
-xenstore_write_int(vm, "maxmem", ram_size >> 20);  // MB
+xenstore_write_int(dom, "memory/target", ram_size * K_BYTE);
+xenstore_write_int(vm, "memory", ram_size * M_BYTE);
+xenstore_write_int(vm, "maxmem", ram_size * M_BYTE);
 
 /* cpus */
 for (i = 0; i < smp_cpus; i++) {
@@ -260,7 +260,7 @@ int xen_domain_build_pv(const char *kernel, const char 
*ramdisk,
 }
 #endif
 
-rc = xc_domain_setmaxmem(xen_xc, xen_domid, ram_size >> 10);
+rc = xc_domain_setmaxmem(xen_xc, xen_domid, ram_size / K_BYTE);
 if (rc < 0) {
 fprintf(stderr, "xen: xc_domain_setmaxmem() failed\n");
 goto err;
@@ -269,7 +269,7 @@ int xen_domain_build_pv(const char *kernel, const char 
*ramdisk,
 xenstore_port = xc_evtchn_alloc_unbound(xen_xc, xen_domid, 0);
 console_port = xc_evtchn_alloc_unbound(xen_xc, xen_domid, 0);
 
-rc = xc_linux_build(xen_xc, xen_domid, ram_size >> 20,
+rc = xc_linux_build(xen_xc, xen_domid, ram_size / M_BYTE,
 kernel, ramdisk, cmdline,
 0, flags,
 xenstore_port, &xenstore_mfn,
-- 
2.16.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH 22/30] hw/display: use the BYTE-based definitions

[Philippe Mathieu-Daudé]

It ease code review, unit is explicit.

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/display/cirrus_vga.c |  9 -
 hw/display/g364fb.c |  2 +-
 hw/display/qxl.c| 26 +++---
 hw/display/vga-isa-mm.c |  4 ++--
 hw/display/vga.c|  4 ++--
 hw/display/virtio-gpu.c |  3 +--
 hw/display/vmware_vga.c |  2 +-
 hw/display/xenfb.c  |  2 +-
 8 files changed, 23 insertions(+), 29 deletions(-)

diff --git a/hw/display/cirrus_vga.c b/hw/display/cirrus_vga.c
index 138ae961b9..e888056d75 100644
--- a/hw/display/cirrus_vga.c
+++ b/hw/display/cirrus_vga.c
@@ -2218,7 +2218,7 @@ static inline void 
cirrus_cursor_compute_yrange(CirrusVGAState *s)
 uint32_t content;
 int y, y_min, y_max;
 
-src = s->vga.vram_ptr + s->real_vram_size - 16 * 1024;
+src = s->vga.vram_ptr + s->real_vram_size - 16 * K_BYTE;
 if (s->vga.sr[0x12] & CIRRUS_CURSOR_LARGE) {
 src += (s->vga.sr[0x13] & 0x3c) * 256;
 y_min = 64;
@@ -2347,7 +2347,7 @@ static void cirrus_cursor_draw_line(VGACommonState *s1, 
uint8_t *d1, int scr_y)
 return;
 }
 
-src = s->vga.vram_ptr + s->real_vram_size - 16 * 1024;
+src = s->vga.vram_ptr + s->real_vram_size - 16 * K_BYTE;
 if (s->vga.sr[0x12] & CIRRUS_CURSOR_LARGE) {
 src += (s->vga.sr[0x13] & 0x3c) * 256;
 src += (scr_y - s->vga.hw_cursor_y) * 16;
@@ -2995,8 +2995,7 @@ static void cirrus_init_common(CirrusVGAState *s, Object 
*owner,
 
 /* I/O handler for LFB */
 memory_region_init_io(&s->cirrus_linear_io, owner, &cirrus_linear_io_ops, 
s,
-  "cirrus-linear-io", s->vga.vram_size_mb
-  * 1024 * 1024);
+  "cirrus-linear-io", s->vga.vram_size_mb * M_BYTE);
 memory_region_set_flush_coalesced(&s->cirrus_linear_io);
 
 /* I/O handler for LFB */
@@ -3013,7 +3012,7 @@ static void cirrus_init_common(CirrusVGAState *s, Object 
*owner,
 memory_region_set_flush_coalesced(&s->cirrus_mmio_io);
 
 s->real_vram_size =
-(s->device_id == CIRRUS_ID_CLGD5446) ? 4096 * 1024 : 2048 * 1024;
+(s->device_id == CIRRUS_ID_CLGD5446) ? 4 * M_BYTE : 2 * M_BYTE;
 
 /* XXX: s->vga.vram_size must be a power of two */
 s->cirrus_addr_mask = s->real_vram_size - 1;
diff --git a/hw/display/g364fb.c b/hw/display/g364fb.c
index 819f8be05d..009f07333b 100644
--- a/hw/display/g364fb.c
+++ b/hw/display/g364fb.c
@@ -510,7 +510,7 @@ static void g364fb_sysbus_reset(DeviceState *d)
 
 static Property g364fb_sysbus_properties[] = {
 DEFINE_PROP_UINT32("vram_size", G364SysBusState, g364.vram_size,
-8 * 1024 * 1024),
+   8 * M_BYTE),
 DEFINE_PROP_END_OF_LIST(),
 };
 
diff --git a/hw/display/qxl.c b/hw/display/qxl.c
index a71714ccb4..4863f894ad 100644
--- a/hw/display/qxl.c
+++ b/hw/display/qxl.c
@@ -2012,11 +2012,11 @@ static void qxl_init_ramsize(PCIQXLDevice *qxl)
 if (qxl->vgamem_size_mb > 256) {
 qxl->vgamem_size_mb = 256;
 }
-qxl->vgamem_size = qxl->vgamem_size_mb * 1024 * 1024;
+qxl->vgamem_size = qxl->vgamem_size_mb * M_BYTE;
 
 /* vga ram (bar 0, total) */
 if (qxl->ram_size_mb != -1) {
-qxl->vga.vram_size = qxl->ram_size_mb * 1024 * 1024;
+qxl->vga.vram_size = qxl->ram_size_mb * M_BYTE;
 }
 if (qxl->vga.vram_size < qxl->vgamem_size * 2) {
 qxl->vga.vram_size = qxl->vgamem_size * 2;
@@ -2024,7 +2024,7 @@ static void qxl_init_ramsize(PCIQXLDevice *qxl)
 
 /* vram32 (surfaces, 32bit, bar 1) */
 if (qxl->vram32_size_mb != -1) {
-qxl->vram32_size = qxl->vram32_size_mb * 1024 * 1024;
+qxl->vram32_size = qxl->vram32_size_mb * M_BYTE;
 }
 if (qxl->vram32_size < 4096) {
 qxl->vram32_size = 4096;
@@ -2032,7 +2032,7 @@ static void qxl_init_ramsize(PCIQXLDevice *qxl)
 
 /* vram (surfaces, 64bit, bar 4+5) */
 if (qxl->vram_size_mb != -1) {
-qxl->vram_size = (uint64_t)qxl->vram_size_mb * 1024 * 1024;
+qxl->vram_size = (uint64_t)qxl->vram_size_mb * M_BYTE;
 }
 if (qxl->vram_size < qxl->vram32_size) {
 qxl->vram_size = qxl->vram32_size;
@@ -2134,13 +2134,10 @@ static void qxl_realize_common(PCIQXLDevice *qxl, Error 
**errp)
 }
 
 /* print pci bar details */
-dprint(qxl, 1, "ram/%s: %d MB [region 0]\n",
-   qxl->id == 0 ? "pri" : "sec",
-   qxl->vga.vram_size / (1024*1024));
-dprint(qxl, 1, "vram/32: %" PRIx64 "d MB [region 1]\n",
-   qxl->vram32_size / (1024*1024));
-dprint(qxl, 1, "vram/64: %" PRIx64 "d MB %s\n",
-   qxl->vram_size / (1024*1024),
+dprint(qxl, 1, "ram/%s: %llu MB [region 0]\n",
+   qxl->id == 0 ? "pri" : "sec", qxl->vga.vram_size / M_BYTE);
+dprint(qxl, 1, "vram/32: %llu MB [region 1]\n", qxl->vram32_size / M_BYTE);
+dprint(qxl, 1, "vram/64: %llu MB %s\n", qxl->vram_size / M_BYTE,
qxl->vram32_size < qxl->vram_size ? "[region 4]" : "[unmapped]");

[Xen-devel] [PATCH 08/30] hw/i386: use the BYTE-based definitions

[Philippe Mathieu-Daudé]

It ease code review, unit is explicit.

Signed-off-by: Philippe Mathieu-Daudé 
---
 include/hw/i386/ich9.h |  2 +-
 hw/i386/acpi-build.c   |  4 ++--
 hw/i386/pc.c   | 18 +-
 hw/i386/pc_piix.c  |  2 +-
 hw/i386/pc_q35.c   |  2 +-
 hw/i386/pc_sysfw.c |  8 
 hw/i386/xen/xen-mapcache.c |  2 +-
 hw/intc/apic_common.c  |  2 +-
 hw/pci-host/gpex.c |  2 +-
 hw/pci-host/piix.c |  4 ++--
 hw/pci-host/q35.c  | 16 
 11 files changed, 31 insertions(+), 31 deletions(-)

diff --git a/include/hw/i386/ich9.h b/include/hw/i386/ich9.h
index 673d13d28f..87628dd867 100644
--- a/include/hw/i386/ich9.h
+++ b/include/hw/i386/ich9.h
@@ -22,7 +22,7 @@ I2CBus *ich9_smb_init(PCIBus *bus, int devfn, uint32_t 
smb_io_base);
 
 void ich9_generate_smi(void);
 
-#define ICH9_CC_SIZE (16 * 1024) /* 16KB. Chipset configuration registers */
+#define ICH9_CC_SIZE (16 * K_BYTE) /* Chipset configuration registers */
 
 #define TYPE_ICH9_LPC_DEVICE "ICH9-LPC"
 #define ICH9_LPC_DEVICE(obj) \
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index deb440f286..9ccc6192b5 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -2320,8 +2320,8 @@ build_tpm2(GArray *table_data, BIOSLinker *linker, GArray 
*tcpalog)
  (void *)tpm2_ptr, "TPM2", sizeof(*tpm2_ptr), 4, NULL, NULL);
 }
 
-#define HOLE_640K_START  (640 * 1024)
-#define HOLE_640K_END   (1024 * 1024)
+#define HOLE_640K_START  (640 * K_BYTE)
+#define HOLE_640K_END   (1024 * K_BYTE)
 
 static void
 build_srat(GArray *table_data, BIOSLinker *linker, MachineState *machine)
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 55e69d66fe..94a1f3bc7b 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -452,8 +452,8 @@ void pc_cmos_init(PCMachineState *pcms,
 rtc_set_memory(s, 0x15, val);
 rtc_set_memory(s, 0x16, val >> 8);
 /* extended memory (next 64MiB) */
-if (pcms->below_4g_mem_size > 1024 * 1024) {
-val = (pcms->below_4g_mem_size - 1024 * 1024) / 1024;
+if (pcms->below_4g_mem_size > 1 * M_BYTE) {
+val = (pcms->below_4g_mem_size - 1 * M_BYTE) / 1024;
 } else {
 val = 0;
 }
@@ -464,8 +464,8 @@ void pc_cmos_init(PCMachineState *pcms,
 rtc_set_memory(s, 0x30, val);
 rtc_set_memory(s, 0x31, val >> 8);
 /* memory between 16MiB and 4GiB */
-if (pcms->below_4g_mem_size > 16 * 1024 * 1024) {
-val = (pcms->below_4g_mem_size - 16 * 1024 * 1024) / 65536;
+if (pcms->below_4g_mem_size > 16 * M_BYTE) {
+val = (pcms->below_4g_mem_size - 16 * M_BYTE) / 65536;
 } else {
 val = 0;
 }
@@ -1390,11 +1390,11 @@ void pc_memory_init(PCMachineState *pcms,
 }
 
 pcms->hotplug_memory.base =
-ROUND_UP(0x1ULL + pcms->above_4g_mem_size, 1ULL << 30);
+ROUND_UP(0x1ULL + pcms->above_4g_mem_size, G_BYTE);
 
 if (pcmc->enforce_aligned_dimm) {
 /* size hotplug region assuming 1G page max alignment per slot */
-hotplug_mem_size += (1ULL << 30) * machine->ram_slots;
+hotplug_mem_size += machine->ram_slots * G_BYTE;
 }
 
 if ((pcms->hotplug_memory.base + hotplug_mem_size) <
@@ -1436,7 +1436,7 @@ void pc_memory_init(PCMachineState *pcms,
 if (!pcmc->broken_reserved_end) {
 res_mem_end += memory_region_size(&pcms->hotplug_memory.mr);
 }
-*val = cpu_to_le64(ROUND_UP(res_mem_end, 0x1ULL << 30));
+*val = cpu_to_le64(ROUND_UP(res_mem_end, G_BYTE));
 fw_cfg_add_file(fw_cfg, "etc/reserved-memory-end", val, sizeof(*val));
 }
 
@@ -1472,7 +1472,7 @@ uint64_t pc_pci_hole64_start(void)
 hole64_start = 0x1ULL + pcms->above_4g_mem_size;
 }
 
-return ROUND_UP(hole64_start, 1ULL << 30);
+return ROUND_UP(hole64_start, G_BYTE);
 }
 
 qemu_irq pc_allocate_cpu_irq(void)
@@ -2114,7 +2114,7 @@ static void pc_machine_set_max_ram_below_4g(Object *obj, 
Visitor *v,
 return;
 }
 
-if (value < (1ULL << 20)) {
+if (value < 1 * M_BYTE) {
 warn_report("Only %" PRIu64 " bytes of RAM below the 4GiB boundary,"
 "BIOS may not work with less than 1MiB", value);
 }
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 456dc9e9f0..975dfc848e 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -131,7 +131,7 @@ static void pc_init1(MachineState *machine,
 if (lowmem > 0xc000) {
 lowmem = 0xc000;
 }
-if (lowmem & ((1ULL << 30) - 1)) {
+if (lowmem & ((1 * G_BYTE) - 1)) {
 warn_report("Large machine and max_ram_below_4g "
 "(%" PRIu64 ") not a multiple of 1G; "
 "possible bad performance.",
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index aba7541a82..79b84bc559 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q

[Xen-devel] [linux-next test] 119169: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

flight 119169 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/119169/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-libvirt  broken
 test-amd64-i386-freebsd10-i386 broken
 test-amd64-amd64-rumprun-amd64 broken
 test-amd64-amd64-libvirt-xsm broken
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm  broken
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 4 host-install(4) broken 
REGR. vs. 119064
 test-amd64-amd64-libvirt-xsm  4 host-install(4)broken REGR. vs. 119064
 test-amd64-amd64-rumprun-amd64  4 host-install(4)  broken REGR. vs. 119064
 test-amd64-i386-libvirt   4 host-install(4)broken REGR. vs. 119064
 test-amd64-i386-freebsd10-i386  4 host-install(4)  broken REGR. vs. 119064
 build-arm64-pvops 6 kernel-build fail REGR. vs. 119064
 test-armhf-armhf-xl-arndale  10 debian-install   fail REGR. vs. 119064
 test-armhf-armhf-xl-credit2  10 debian-install   fail REGR. vs. 119064
 test-armhf-armhf-xl-multivcpu 10 debian-install  fail REGR. vs. 119064
 test-armhf-armhf-xl-xsm  10 debian-install   fail REGR. vs. 119064
 test-armhf-armhf-libvirt-raw 10 debian-di-installfail REGR. vs. 119064
 test-armhf-armhf-xl-cubietruck 10 debian-install fail REGR. vs. 119064
 test-armhf-armhf-xl  10 debian-install   fail REGR. vs. 119064

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 10 debian-install   fail REGR. vs. 119064

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-examine   8 reboot   fail  like 119064
 test-amd64-i386-xl-qemuu-win10-i386  7 xen-boot   fail like 119064
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 xen-boot   fail like 119064
 test-amd64-i386-pair 10 xen-boot/src_hostfail  like 119064
 test-amd64-i386-pair 11 xen-boot/dst_hostfail  like 119064
 test-amd64-i386-qemut-rhel6hvm-intel  7 xen-boot  fail like 119064
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail like 
119064
 test-amd64-i386-freebsd10-amd64  7 xen-boot   fail like 119064
 test-amd64-i386-xl7 xen-boot fail  like 119064
 test-amd64-i386-rumprun-i386  7 xen-boot fail  like 119064
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm  7 xen-boot fail like 119064
 test-amd64-i386-xl-qemut-win10-i386  7 xen-boot   fail like 119064
 test-amd64-i386-libvirt-xsm   7 xen-boot fail  like 119064
 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail  like 119064
 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail  like 119064
 test-amd64-i386-xl-xsm7 xen-boot fail  like 119064
 test-amd64-i386-xl-qemut-debianhvm-amd64  7 xen-boot  fail like 119064
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  7 xen-boot  fail like 119064
 test-amd64-i386-qemut-rhel6hvm-amd  7 xen-bootfail like 119064
 test-amd64-i386-xl-qemut-ws16-amd64  7 xen-boot   fail like 119064
 test-amd64-i386-xl-qemuu-debianhvm-amd64  7 xen-boot  fail like 119064
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail like 119064
 test-amd64-i386-xl-raw7 xen-boot fail  like 119064
 test-amd64-i386-xl-qemuu-ws16-amd64  7 xen-boot   fail like 119064
 test-amd64-i386-qemuu-rhel6hvm-intel  7 xen-boot  fail like 119064
 test-amd64-i386-xl-qemuu-win7-amd64  7 xen-boot   fail like 119064
 test-amd64-i386-qemuu-rhel6hvm-amd  7 xen-bootfail like 119064
 test-amd64-i386-xl-qemut-win7-amd64  7 xen-boot   fail like 119064
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  7 xen-boot  fail like 119064
 test-amd64-amd64-xl-pvhv2-intel 12 guest-startfail like 119064
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 119064
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 119064
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 119064
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 119064
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 119064
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 11

Re: [Xen-devel] [RFC PATCH 01/60] hyper_dmabuf: initial working version of hyper_dmabuf drv

[Dongwon Kim]

Abandoning this series as a new version was submitted for the review

"[RFC PATCH v2 0/9] hyper_dmabuf: Hyper_DMABUF driver"

On Tue, Dec 19, 2017 at 11:29:17AM -0800, Kim, Dongwon wrote:
> Upload of intial version of hyper_DMABUF driver enabling
> DMA_BUF exchange between two different VMs in virtualized
> platform based on hypervisor such as KVM or XEN.
> 
> Hyper_DMABUF drv's primary role is to import a DMA_BUF
> from originator then re-export it to another Linux VM
> so that it can be mapped and accessed by it.
> 
> The functionality of this driver highly depends on
> Hypervisor's native page sharing mechanism and inter-VM
> communication support.
> 
> This driver has two layers, one is main hyper_DMABUF
> framework for scatter-gather list management that handles
> actual import and export of DMA_BUF. Lower layer is about
> actual memory sharing and communication between two VMs,
> which is hypervisor-specific interface.
> 
> This driver is initially designed to enable DMA_BUF
> sharing across VMs in Xen environment, so currently working
> with Xen only.
> 
> This also adds Kernel configuration for hyper_DMABUF drv
> under Device Drivers->Xen driver support->hyper_dmabuf
> options.
> 
> To give some brief information about each source file,
> 
> hyper_dmabuf/hyper_dmabuf_conf.h
> : configuration info
> 
> hyper_dmabuf/hyper_dmabuf_drv.c
> : driver interface and initialization
> 
> hyper_dmabuf/hyper_dmabuf_imp.c
> : scatter-gather list generation and management. DMA_BUF
> ops for DMA_BUF reconstructed from hyper_DMABUF
> 
> hyper_dmabuf/hyper_dmabuf_ioctl.c
> : IOCTLs calls for export/import and comm channel creation
> unexport.
> 
> hyper_dmabuf/hyper_dmabuf_list.c
> : Database (linked-list) for exported and imported
> hyper_DMABUF
> 
> hyper_dmabuf/hyper_dmabuf_msg.c
> : creation and management of messages between exporter and
> importer
> 
> hyper_dmabuf/xen/hyper_dmabuf_xen_comm.c
> : comm ch management and ISRs for incoming messages.
> 
> hyper_dmabuf/xen/hyper_dmabuf_xen_comm_list.c
> : Database (linked-list) for keeping information about
> existing comm channels among VMs
> 
> Signed-off-by: Dongwon Kim 
> Signed-off-by: Mateusz Polrola 
> ---
>  drivers/xen/Kconfig|   2 +
>  drivers/xen/Makefile   |   1 +
>  drivers/xen/hyper_dmabuf/Kconfig   |  14 +
>  drivers/xen/hyper_dmabuf/Makefile  |  34 +
>  drivers/xen/hyper_dmabuf/hyper_dmabuf_conf.h   |   2 +
>  drivers/xen/hyper_dmabuf/hyper_dmabuf_drv.c|  54 ++
>  drivers/xen/hyper_dmabuf/hyper_dmabuf_drv.h| 101 +++
>  drivers/xen/hyper_dmabuf/hyper_dmabuf_imp.c| 852 
> +
>  drivers/xen/hyper_dmabuf/hyper_dmabuf_imp.h|  31 +
>  drivers/xen/hyper_dmabuf/hyper_dmabuf_ioctl.c  | 462 +++
>  drivers/xen/hyper_dmabuf/hyper_dmabuf_list.c   | 119 +++
>  drivers/xen/hyper_dmabuf/hyper_dmabuf_list.h   |  40 +
>  drivers/xen/hyper_dmabuf/hyper_dmabuf_msg.c| 212 +
>  drivers/xen/hyper_dmabuf/hyper_dmabuf_msg.h|  45 ++
>  drivers/xen/hyper_dmabuf/hyper_dmabuf_query.h  |  16 +
>  drivers/xen/hyper_dmabuf/hyper_dmabuf_struct.h |  70 ++
>  .../xen/hyper_dmabuf/xen/hyper_dmabuf_xen_comm.c   | 328 
>  .../xen/hyper_dmabuf/xen/hyper_dmabuf_xen_comm.h   |  62 ++
>  .../hyper_dmabuf/xen/hyper_dmabuf_xen_comm_list.c  | 106 +++
>  .../hyper_dmabuf/xen/hyper_dmabuf_xen_comm_list.h  |  35 +
>  20 files changed, 2586 insertions(+)
>  create mode 100644 drivers/xen/hyper_dmabuf/Kconfig
>  create mode 100644 drivers/xen/hyper_dmabuf/Makefile
>  create mode 100644 drivers/xen/hyper_dmabuf/hyper_dmabuf_conf.h
>  create mode 100644 drivers/xen/hyper_dmabuf/hyper_dmabuf_drv.c
>  create mode 100644 drivers/xen/hyper_dmabuf/hyper_dmabuf_drv.h
>  create mode 100644 drivers/xen/hyper_dmabuf/hyper_dmabuf_imp.c
>  create mode 100644 drivers/xen/hyper_dmabuf/hyper_dmabuf_imp.h
>  create mode 100644 drivers/xen/hyper_dmabuf/hyper_dmabuf_ioctl.c
>  create mode 100644 drivers/xen/hyper_dmabuf/hyper_dmabuf_list.c
>  create mode 100644 drivers/xen/hyper_dmabuf/hyper_dmabuf_list.h
>  create mode 100644 drivers/xen/hyper_dmabuf/hyper_dmabuf_msg.c
>  create mode 100644 drivers/xen/hyper_dmabuf/hyper_dmabuf_msg.h
>  create mode 100644 drivers/xen/hyper_dmabuf/hyper_dmabuf_query.h
>  create mode 100644 drivers/xen/hyper_dmabuf/hyper_dmabuf_struct.h
>  create mode 100644 drivers/xen/hyper_dmabuf/xen/hyper_dmabuf_xen_comm.c
>  create mode 100644 drivers/xen/hyper_dmabuf/xen/hyper_dmabuf_xen_comm.h
>  create mode 100644 drivers/xen/hyper_dmabuf/xen/hyper_dmabuf_xen_comm_list.c
>  create mode 100644 drivers/xen/hyper_dmabuf/xen/hyper_dmabuf_xen_comm_list.h
> 
> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index d8dd546..b59b0e3 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -321,4 +321,6 @@ config XEN_SYMS
>  config XEN_HAVE_VPMU
> bool
>  
> +source "drivers/x

[Xen-devel] [xen-4.6-testing test] 119187: regressions - FAIL

[osstest service owner]

flight 119187 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/119187/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-xtf-amd64-amd64-2 49 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 118166
 test-amd64-i386-xl-qemuu-ovmf-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
118166
 test-armhf-armhf-xl-vhd 15 guest-start/debian.repeat fail REGR. vs. 118166

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-rtds   16 guest-start/debian.repeat fail blocked in 118166
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 118166
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 118166
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 118166
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 118166
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 118166
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 118166
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 118166
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 118166
 test-xtf-amd64-amd64-1   73 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-2   73 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-4   73 xtf/test-pv32pae-xsa-194 fail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-3   73 xtf/test-pv32pae-xsa-194 fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-5   73 xtf/test-pv32pae-xsa-194 fail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-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-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-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-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-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  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-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-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-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 xen  75bdd693033e6dbd6fe5ae235f79961d2f0aa84d
baseline version:
 xen  44ad7f6895da9861042d7a41e635d42d83cb2660

Last test of basis   118166  2018-01-17 16:49:59 Z   28 days
Testing same since   119187  2018-02-14 13:11:25 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Ingo Molnar 
  Jan Beulich 
  Thomas Gleixner 
  Tom Lendacky 
  Wei Liu 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm 

[Xen-devel] [libvirt test] 119148: trouble: broken/pass

[osstest service owner]

flight 119148 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/119148/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-libvirt-xsm  broken
 test-amd64-i386-libvirt-xsm   4 host-install(4)broken REGR. vs. 119049

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 119049
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 119049
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 119049
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 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-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-arm64-arm64-libvirt-qcow2 12 migrate-support-checkfail never pass
 test-arm64-arm64-libvirt-qcow2 13 saverestore-support-checkfail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  6fc33b6f37af2310fd5bb1246e194eed96741df8
baseline version:
 libvirt  554a5edcb46ff972fed45b851d70823b923fec6a

Last test of basis   119049  2018-02-13 04:20:05 Z1 days
Testing same since   119148  2018-02-14 04:23:35 Z0 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Bjoern Walk 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-arm64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-arm64-arm64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  broken  
 test-amd64-amd64-libvirt pass
 test-arm64-arm64-libvirt pass
 test-armhf-armhf-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-arm64-arm64-libvirt-qcow2   pass
 test-armhf-armhf-libvirt-raw pass
 test-amd64-amd64-libvirt-vhd 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;

Re: [Xen-devel] [PATCH v2 1/4] asm-x86/monitor: Enable svm monitor events

[Boris Ostrovsky]

On 02/08/2018 10:25 AM, Alexandru Isaila wrote:

This commit separates the svm caps from the vmx caps.

Signed-off-by: Alexandru Isaila 

---
Changes since V1:
- Removed the if ( cpu_has_svm )
---
  xen/include/asm-x86/monitor.h | 34 +++---
  1 file changed, 19 insertions(+), 15 deletions(-)

diff --git a/xen/include/asm-x86/monitor.h b/xen/include/asm-x86/monitor.h
index a0444d1..b2b4e6a 100644
--- a/xen/include/asm-x86/monitor.h
+++ b/xen/include/asm-x86/monitor.h
@@ -71,24 +71,28 @@ static inline uint32_t arch_monitor_get_capabilities(struct 
domain *d)
  uint32_t capabilities = 0;
  
  /*

- * At the moment only Intel HVM domains are supported. However, event
- * delivery could be extended to AMD and PV domains.
+ * At the moment only Intel and AMD HVM domains are supported. However, 
event
+ * delivery could be extended to and PV domains.
   */
-if ( !is_hvm_domain(d) || !cpu_has_vmx )
+if ( !is_hvm_domain(d) )
  return capabilities;
  
-capabilities = (1U << XEN_DOMCTL_MONITOR_EVENT_WRITE_CTRLREG) |

-   (1U << XEN_DOMCTL_MONITOR_EVENT_MOV_TO_MSR) |
-   (1U << XEN_DOMCTL_MONITOR_EVENT_SOFTWARE_BREAKPOINT) |
-   (1U << XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST) |
-   (1U << XEN_DOMCTL_MONITOR_EVENT_DEBUG_EXCEPTION) |
-   (1U << XEN_DOMCTL_MONITOR_EVENT_CPUID) |
-   (1U << XEN_DOMCTL_MONITOR_EVENT_INTERRUPT) |
-   (1U << XEN_DOMCTL_MONITOR_EVENT_EMUL_UNIMPLEMENTED);
-
-/* Since we know this is on VMX, we can just call the hvm func */
-if ( hvm_is_singlestep_supported() )
-capabilities |= (1U << XEN_DOMCTL_MONITOR_EVENT_SINGLESTEP);
+if( cpu_has_vmx )
+{
+capabilities = (1U << XEN_DOMCTL_MONITOR_EVENT_WRITE_CTRLREG) |
+   (1U << XEN_DOMCTL_MONITOR_EVENT_MOV_TO_MSR) |
+   (1U << XEN_DOMCTL_MONITOR_EVENT_SOFTWARE_BREAKPOINT) |
+   (1U << XEN_DOMCTL_MONITOR_EVENT_DEBUG_EXCEPTION) |
+   (1U << XEN_DOMCTL_MONITOR_EVENT_CPUID) |
+   (1U << XEN_DOMCTL_MONITOR_EVENT_INTERRUPT) |
+   (1U << XEN_DOMCTL_MONITOR_EVENT_EMUL_UNIMPLEMENTED);
+
+/* Since we know this is on VMX, we can just call the hvm func */
+if ( hvm_is_singlestep_supported() )
+capabilities |= (1U << XEN_DOMCTL_MONITOR_EVENT_SINGLESTEP);
+}
+
+capabilities |= (1U << XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST);



It's a nit but I'd start with setting common options and the OR in 
arch-specific ones. (i.e. move the line above to right after 
!is_hvm_domain(d) test).


-boris



  
  if ( hvm_funcs.set_descriptor_access_exiting )

  capabilities |= (1U << XEN_DOMCTL_MONITOR_EVENT_DESC_ACCESS);



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2 3/4] hvm/svm: Enable MSR events

[Boris Ostrovsky]

On 02/08/2018 10:25 AM, Alexandru Isaila wrote:

This commit enables MSR events for svm.

Signed-off-by: Alexandru Isaila 


Reviewed-by: Boris Ostrovsky 



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Excited for Xen Project in Outreachy

[Stefano Stabellini]

Hello Kanika,

Thanks for your interest in Xen Project!
One reply inline below.

On Wed, 14 Feb 2018, Lars Kurth wrote:
> Hi Kanika,
> 
> I CC'ed two lists and the mentors of projects. Thank you for your interest in 
> the project.
> 
> > I seek guidance in choosing the suitable sub-project in Xen according to my 
> > skill set.
> We have two sets of projects on 
> https://www.outreachy.org/communities/cfp/xen-project/
> * 3 around Unikraft (mentor: Simon the technical side, I on the 
> process/people side). We are both based in UTC+1 - IRC is #unikraft
> * 1 for Xen on ARM (mentors: Stefano & Edgar). Stefano is in UTC-8, Edgar is 
> UTC-7 or 6 (can't quite recall) - IRC is #xendevel
> 
> > I wish to begin my contribution as soon as possible. I request you to 
> > connect me to the mentors in case IRC is not the best way to get in touch 
> > with them.
> Simon is unfortunately not around this week but will be next week.
> Stefano and Edgar, are around I believe
> 
> For practical reasons:
> * Please sign up to the minios-de...@lists.xenproject.org or 
> xen-devel@lists.xenproject.org (as appropriate)
>(see http://lists.xenproject.org for instructions: if you use the 
> "subscribe subject pattern" make sure you send the mail to 
> minios-devel-requ...@lists.xenproject.org, ...) 
> * Please double check time requirements: This is because in the past there 
> frequently were issues with Outreachy and University course time requirements 
> in particular with Universities from India. I believe that there will be 
> extra checks later in the application process, which may require letters from 
> your University. We had one case, where an applicant did a small project, but 
> we were not allowed to accept her due to time requirements.
> * Let us know timezone you are in and when you can hang out on IRC 
> * Your registered IRC nickname (please register your nick - see 
> https://www.xenproject.org/help/irc.html under Netiquette)
> 
> Note that my IRC nick is lars_kurth, Simon's is skuezer, Stefano's is 
> sstabellini, and I am afraid I can't remember Edgar's
> 
> If you are interested in Unikraft
> * Build the hello world unikraft app: see 
> https://wiki.xenproject.org/wiki/Category:Unikraft & 
> http://unikraft.neclab.eu/ and report back
> * Familiarize yourself with the workflow at 
> https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#How_to_Generate.2C_and_Submit_a_Xen_Project_Patch_to_MiniOS_and_Unikraft
>  (please read the entire document) 
> 
> For the ARM project, I will let Stefano and Edgar decide.

For the ARM project, it would be good to get familiar with Xen on ARM,
to learn how to build it:

https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions#Building_Xen_on_ARM

and use QEMU to emulate an ARM board to run Xen on it, for testing and
development:

https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/qemu-system-aarch64

Feel free to ask any questions!


> Regards
> Lars
> 
> 
> From: KANIKA SAINI 
> Date: Wednesday, 14 February 2018 at 17:25
> To: Lars Kurth 
> Subject: Excited for Xen Project in Outreachy
> 
> Greetings, Lars.
> 
> I'm Kanika Saini and I'm super excited to begin contributing to Xen!
> 
> I seek guidance in choosing the suitable sub-project in Xen according to my 
> skill set. I'm currently pursuing a course in Operating Systems and hence, 
> have been gaining knowledge in kernel programming by short assignments like 
> the implementation of a system call. I'm familiar with assembly programming 
> in MIPS, ARM and x86 as well. 
> About high-level programming - I have experience with Java and have used it 
> for desktop applications and parallel programming.
> 
> There are certain projects listed on the project page and I'm looking for 
> mentors' suggestion on what could be the best for both me and Xen. I have 
> introduced myself on the #unikraft channel and I'm expecting a reply from the 
> community.
> 
> I wish to begin my contribution as soon as possible. I request you to connect 
> me to the mentors in case IRC is not the best way to get in touch with them.
> 
> Thank you!
> 
> 
> -- 
> Yours sincerely,
> Kanika Saini
> CSE, IIITD Class of 2020
> 
> 
> 
> ‌
> 
> ___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [xen-unstable test] 119137: regressions - trouble: broken/fail/pass

[osstest service owner]

flight 119137 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/119137/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-ws16-amd64 broken
 test-amd64-i386-qemut-rhel6hvm-amd broken
 test-amd64-amd64-xl-qemut-ws16-amd64 4 host-install(4) broken REGR. vs. 118698
 test-amd64-i386-qemut-rhel6hvm-amd  4 host-install(4)  broken REGR. vs. 118698
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-saverestore fail REGR. vs. 118698
 test-armhf-armhf-libvirt-raw  6 xen-install  fail REGR. vs. 118698

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 118698
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 118698
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 118698
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 118698
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 118698
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 118698
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 118698
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail 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-amd64-amd64-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-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-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-xsm 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
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-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-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  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-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-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-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:
 xen  3f491d6873be9caa77f02ad8d98f174f0152b819
baseline version:
 xen  c93014ad3aa6aa88dfa5e96f66e8adb561483b8d

Last test of basis   118698  2018-02-08 19:23:11 Z6 days
Failing since118802  2018-02-10 00:36:18 Z4 days6 attempts
Testing same since   119137  2018-02-14 03:01:39 Z0 days1 attempts

---

Re: [Xen-devel] [PATCH v3 1/4] asm-x86/monitor: Fix monitor capability reporting on SVM systems

[Tamas K Lengyel]

On Wed, Feb 14, 2018 at 10:56 AM, Razvan Cojocaru
 wrote:
> On 02/14/2018 07:47 PM, Andrew Cooper wrote:
>> On 12/02/18 15:13, Andrew Cooper wrote:
>>> On 12/02/18 15:08, Alexandru Isaila wrote:
 No monitor features are available on AMD and all
 capabilities are passed only to the Intel processor architecture.
 This means that the arch_monitor_get_capabilities returns
 capabilities = 0.

 This patch is separating out features which are implemented on both
 systems from those implemented only on Intel, so that we advertize the
 working capabilities on AMD.

 Signed-off-by: Alexandru Isaila 
>>
>> This patch still needs an ack from Tamas or Razvan, but there is no
>> comment so far that I can find.
>
> I think Tamas probably wouldn't object, so FWIW:
>
> Acked-by: Razvan Cojocaru 

Yes, this looks fine to me too:

Acked-by: Tamas K Lengyel 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [xen-unstable-smoke test] 119208: tolerable all pass - PUSHED

[osstest service owner]

flight 119208 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/119208/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  27196d4cc917d91b5b5daee50173565139ca9c9d
baseline version:
 xen  a2b08fbed388f18235fda5ba1655c1483ef3e215

Last test of basis   119190  2018-02-14 14:01:20 Z0 days
Testing same since   119208  2018-02-14 19:01:09 Z0 days1 attempts


People who touched revisions under test:
  Acked-by: Razvan Cojocaru 
  Alexandru Isaila 
  Andrew Cooper 
  Julien Grall 
  Stefano Stabellini 

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
   a2b08fbed3..27196d4cc9  27196d4cc917d91b5b5daee50173565139ca9c9d -> smoke

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2 02/15] xen/arm: vpsci: Add support for PSCI 1.1

[Mirela Simonovic]

Hi Julien,


On 02/13/2018 12:44 AM, Julien Grall wrote:



On 12/02/2018 23:16, Mirela Simonovic wrote:

Hi Julien,


Hi,


On 02/12/2018 10:41 PM, Julien Grall wrote:



On 12/02/2018 20:12, Mirela Simonovic wrote:

Hi Julien,


Hi Mirela,

Thank you for the review.

I've done pretty much the same work in parallel, but there are few 
additional minor changes I've made. Briefly, the difference is in 
return values that some already implemented functions should return 
starting from v1.0 (and even v0.2 errata). Please let me know 
whether you omitted that intentionally.


Could you give a bit more details here? From a brief look we don't 
seem to implement correctly:
- CPU_OFF: PSCI_DENY should be return on failure (though it 
should never fail in Xen case) and the check on the vCPU state is 
pointless.


I believe CPU_OFF is fine today, it never returns.

- MIGRATE_INFO_TYPE: should technically return int32_t instead 
of uint32_t. That not really matter for now.


If you speak about denying SMC64 call from AArch32, then this is 
already done in vsmccc.c (see vsmccc_call).


Agreed on above, there are 2 more:

1. MIGRATE_INFO_TYPE should return PSCI_NOT_SUPPORTED instead 
PSCI_0_2_TOS_MP_OR_NOT_PRESENT. The function is effectively not 
implemented, but in v0.2 it was mandatory, so it couldn't return 
PSCI_NOT_SUPPORTED (I guess this was some kind of a workaround). 
Since v0.2 errata and v1.0 release the function is made optional and 
it should return "not supported" error - just removing the function 
should be fine (and mismatching return type issue would be gone).


Looking at the spec:

"2 Trusted OS is either not present or does not require migration. A 
system of this type does not require the caller to use the MIGRATE 
function. MIGRATE function calls return NOT_SUPPORTED."


So returning 2 in our case seems to be valid.



2. A new error code has been introduced in PSCI v1.0: 
PSCI_INVALID_ADDRESS. This error should be returned by PSCI functions 
which receive an address as the argument when the provided address is 
incorrect. In implementation in Xen this affects CPU_ON and 
CPU_SUSPEND. CPU_ON today returns invalid parameter error and that 
needs to be replaced with invalid address error. I'm not sure for 
CPU_SUSPEND since its implementation doesn't use/check any of the 
arguments today...
I disagree, not all PSCI_INVALID_PARAMETERS should be replaced by 
PSCI_INVALID_ADDRESS. They have two distinct meaning. However, I am 
not sure where we would need to use it in Xen. The error is described 
as "INVALID_ADDRESS is returned when the entry point address is known 
by the implementation to be invalid, because it is in a range that is 
known not to be available to the caller."


The only potential one would be the check on is_thumb, but even there 
it does not match the description. The range is still available to the 
guest. I think that check should just be dropped.


To be more specific, I was thinking that in xen/arch/arm/vpsci.c line 41 
for psci version other than 0.1 the PSCI_INVALID_ADDRESS error should be 
returned instead PSCI_INVALID_PARAMETERS.


Cheers,
Mirela



Cheers,




___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v3 2/4] hvm/svm: Enable Breakpoint events

[Andrew Cooper]

On 14/02/18 18:22, Andrew Cooper wrote:
> On 14/02/18 16:10, Alexandru Stefan ISAILA wrote:
>> On Lu, 2018-02-12 at 15:54 +, Andrew Cooper wrote:
>>> On 12/02/18 15:08, Alexandru Isaila wrote:
 @@ -2619,14 +2634,31 @@ void svm_vmexit_handler(struct
 cpu_user_regs *regs)
  break;

  case VMEXIT_EXCEPTION_BP:
 -if ( !v->domain->debugger_attached )
 -goto unexpected_exit_type;
 -/* AMD Vol2, 15.11: INT3, INTO, BOUND intercepts do not
 update RIP. */
 -if ( (inst_len = __get_instruction_length(v, INSTR_INT3))
 == 0 )
 +inst_len = __get_instruction_length(v, INSTR_INT3);
>>> There are multiple ways of ending up with this vmexit, and INT3 is
>>> not
>>> the only way.
>>>
>>> The old code was somewhat broken (but only in the case that a
>>> debugger
>>> was attached), but now with  this introspection hook active,
>>> executing
>>> `0xcd 0x03` will end up crashing the domain because of a length
>>> mismatch
>>> looking for 0xcc.
>>>
>>> You need to inspect EXITINTINFO to work out what went on here, and
>>> distinguish INT3 from INT $3.
>>>
>>> Can I suggest that you run this unit test
>>> http://xenbits.xen.org/docs/xtf/test-swint-emulation.html under debug
>>> introspection an check that you get all expected events?  Every time
>>> we
>>> touch this code, we seem to break it :(
>>>
>>> ~Andrew
>>>
>> I've tested on Intel and AMD and I only get events on int3. Further
>> more, I don't think there is any way to use the vmcb->exitintinfo
>> because all the fields are 0 on the time of VMEXIT_EXCEPTION_BP. Did I
>> understand the test scenario correctly?
> Quite possibly, but now I'm even more confused.  I'll have a quick play.

Ok - after some investigation, executing `int $3` triggers VMEXIT_SWINT,
with the vector in EXITINFO1, as opposed to triggering VMEXIT_EXCP3,
except that we don't have INTERCEPT_SWINT active, so it completes
internally.

Therefore, in your patch, we do expect only ever to find an int3
triggering VMEXIT_EXCEPTION_BP.  Sorry for the noise.

However, do you mind rebasing the remainder of your series onto
staging?  It doesn't apply cleanly any more.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] xen/arm: cpuerrata: Actually check errata on non-boot CPUs

[Stefano Stabellini]

On Wed, 14 Feb 2018, Julien Grall wrote:
> The cpu errata framework was introduced in commit 8b01f6364f "xen/arm:
> Detect silicon revision and set cap bits accordingly" and was meant to
> detect errata present on any CPUs (via check_local_cpu_errata). However,
> the function to check the MIDR (is_affected_midr_range) mistakenly
> always use the boot CPU MIDR.
> 
> Fix is_affected_midr_range to use the current CPU MIDR.
> 
> Reported-by: Stefano Stabellini 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


> ---
> This should be backported up to Xen 4.7 as the cpu errata framework
> was backported for XSA-254.
> ---
>  xen/arch/arm/cpuerrata.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
> index 9c7458ef06..c243521ed4 100644
> --- a/xen/arch/arm/cpuerrata.c
> +++ b/xen/arch/arm/cpuerrata.c
> @@ -230,7 +230,7 @@ static int enable_ic_inv_hardening(void *data)
>  static bool __maybe_unused
>  is_affected_midr_range(const struct arm_cpu_capabilities *entry)
>  {
> -return MIDR_IS_CPU_MODEL_RANGE(boot_cpu_data.midr.bits, 
> entry->midr_model,
> +return MIDR_IS_CPU_MODEL_RANGE(current_cpu_data.midr.bits, 
> entry->midr_model,
> entry->midr_range_min,
> entry->midr_range_max);
>  }
> -- 
> 2.11.0
> 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2 2/2] xen/arm: Blacklist SMMU on Thunder-X

[Stefano Stabellini]

On Wed, 14 Feb 2018, Julien Grall wrote:
> Xen does not yet support Cavium SMMU because it requires some
> workaround. For the time being, blacklist them.
> 
> Signed-off-by: Julien Grall 

Acked-by: Stefano Stabellini 


> ---
> Changes in v2:
> - Fix compatible string
> ---
>  xen/arch/arm/platforms/Makefile   |  1 +
>  xen/arch/arm/platforms/thunderx.c | 39 
> +++
>  2 files changed, 40 insertions(+)
>  create mode 100644 xen/arch/arm/platforms/thunderx.c
> 
> diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile
> index 53a47e48d2..80e555cc14 100644
> --- a/xen/arch/arm/platforms/Makefile
> +++ b/xen/arch/arm/platforms/Makefile
> @@ -6,5 +6,6 @@ obj-$(CONFIG_ARM_32) += omap5.o
>  obj-$(CONFIG_ARM_32) += rcar2.o
>  obj-$(CONFIG_ARM_64) += seattle.o
>  obj-y += sunxi.o
> +obj-$(CONFIG_ARM_64) += thunderx.o
>  obj-$(CONFIG_ARM_64) += xgene-storm.o
>  obj-$(CONFIG_ARM_64) += xilinx-zynqmp.o
> diff --git a/xen/arch/arm/platforms/thunderx.c 
> b/xen/arch/arm/platforms/thunderx.c
> new file mode 100644
> index 00..9b32a29c6b
> --- /dev/null
> +++ b/xen/arch/arm/platforms/thunderx.c
> @@ -0,0 +1,39 @@
> +/*
> + * xen/arch/arm/platforms/thunderx.c
> + *
> + * Cavium Thunder-X specific settings
> + *
> + * Copyright (c) 2018 ARM Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; under version 2 of the License.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; If not, see .
> + */
> +
> +#include 
> +
> +static const char * const thunderx_dt_compat[] __initconst =
> +{
> +"cavium,thunder-88xx",
> +NULL
> +};
> +
> +static const struct dt_device_match thunderx_blacklist_dev[] __initconst =
> +{
> +/* Cavium has its own SMMU which is not yet supported. */
> +DT_MATCH_COMPATIBLE("cavium,smmu-v2"),
> +{ /* sentinel */ },
> +};
> +
> +PLATFORM_START(thunderx, "THUNDERX")
> +.compatible = thunderx_dt_compat,
> +.blacklist_dev = thunderx_blacklist_dev,
> +PLATFORM_END
> -- 
> 2.11.0
> 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2 1/2] xen/arm: Extend the number of memory banks supported

[Stefano Stabellini]

On Wed, 14 Feb 2018, Julien Grall wrote:
> When booting using Grub on Thunder-X, the number of memory available is
> greater than 64. Bump the number to 128, so we can take advantage of all
> the memory.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


> ---
> 
> Note that I wasn't able to boot without this patch, because EFI stub
> is printing an error when the number of region exceed 64. This will
> result to fragment in bit more the memory (sounds like print
> allocate memory) and will fail to get the memory on retry.
> ---
>  xen/include/asm-arm/setup.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
> index 7ff2c34dab..0cc3330807 100644
> --- a/xen/include/asm-arm/setup.h
> +++ b/xen/include/asm-arm/setup.h
> @@ -6,7 +6,7 @@
>  #define MIN_FDT_ALIGN 8
>  #define MAX_FDT_SIZE SZ_2M
>  
> -#define NR_MEM_BANKS 64
> +#define NR_MEM_BANKS 128
>  
>  #define MAX_MODULES 5 /* Current maximum useful modules */
>  
> -- 
> 2.11.0
> 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [seabios test] 119162: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

flight 119162 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/119162/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-libvirt  broken
 build-amd64-libvirt   4 host-install(4)broken REGR. vs. 115539
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop   fail REGR. vs. 115539

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 115539
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 115539
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 115539
 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-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:
 seabios  4a6dbcea3e412fe12effa2f812f50dd7eae90955
baseline version:
 seabios  0ca6d6277dfafc671a5b3718cbeb5c78e2a888ea

Last test of basis   115539  2017-11-03 20:48:58 Z  102 days
Failing since115733  2017-11-10 17:19:59 Z   96 days  121 attempts
Testing same since   118668  2018-02-08 04:50:43 Z6 days9 attempts


People who touched revisions under test:
  Kevin O'Connor 
  Marcel Apfelbaum 
  Michael S. Tsirkin 
  Nikolay Nikolov 
  Paul Menzel 
  Stefan Berger 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  broken  
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-ws16-amd64 fail
 test-amd64-i386-xl-qemuu-ws16-amd64  fail
 test-amd64-amd64-xl-qemuu-win10-i386 fail
 test-amd64-i386-xl-qemuu-win10-i386  fail
 test-amd64-amd64-qemuu-nested-intel  pass
 test-amd64-i386-qemuu-rhel6hvm-intel 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

broken-job build-amd64-libvirt broken
broken-step build-amd64-libvirt host-install(4)

Not pushing.


commit 4a6dbcea3e412fe12effa2f812f50dd7eae90955
Author: Nikolay Nikolov 
Date:   Sun Feb 4 17:27:01 2018 +0200

floppy: Use timer_check() in floppy_wait_irq()

Use timer_check() instead of using floppy_motor_counter in BDA for the
timeout check in floppy_wait_irq().

The problem with using floppy_motor_counter was that, after it reaches
0, it immediately stops the floppy motors, which is not what is
supposed to happen on real hardware. Instead, after a timeout (like in
the end of every floppy operation, regardless of the result - success,
timeout or error), the floppy motors must be kept spinning for
additional 2 seconds (the FLOPPY_MOTOR_TICKS). So, now the
floppy_motor_counter is initialized to 255 (the max value) in the
beginning of the floppy operation. For IRQ timeou

[Xen-devel] [PATCH v3 1/2] pvcalls-front: introduce a per sock_mapping refcount

[Stefano Stabellini]

Introduce a per sock_mapping refcount, in addition to the existing
global refcount. Thanks to the sock_mapping refcount, we can safely wait
for it to be 1 in pvcalls_front_release before freeing an active socket,
instead of waiting for the global refcount to be 1.

Signed-off-by: Stefano Stabellini 

---
Changes in v3:
- remove pointless initializers
- reorder pvcalls_enter_sock
---
 drivers/xen/pvcalls-front.c | 191 ++--
 1 file changed, 79 insertions(+), 112 deletions(-)

diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c
index 4c789e6..18d1bac 100644
--- a/drivers/xen/pvcalls-front.c
+++ b/drivers/xen/pvcalls-front.c
@@ -60,6 +60,7 @@ struct sock_mapping {
bool active_socket;
struct list_head list;
struct socket *sock;
+   atomic_t refcount;
union {
struct {
int irq;
@@ -93,6 +94,32 @@ struct sock_mapping {
};
 };
 
+static inline struct sock_mapping *pvcalls_enter_sock(struct socket *sock)
+{
+   struct sock_mapping *map;
+
+   if (!pvcalls_front_dev ||
+   dev_get_drvdata(&pvcalls_front_dev->dev) == NULL)
+   return ERR_PTR(-ENOTCONN);
+
+   map = (struct sock_mapping *)sock->sk->sk_send_head;
+   if (map == NULL)
+   return ERR_PTR(-ENOTSOCK);
+
+   pvcalls_enter();
+   atomic_inc(&map->refcount);
+   return map;
+}
+
+static inline void pvcalls_exit_sock(struct socket *sock)
+{
+   struct sock_mapping *map;
+
+   map = (struct sock_mapping *)sock->sk->sk_send_head;
+   atomic_dec(&map->refcount);
+   pvcalls_exit();
+}
+
 static inline int get_request(struct pvcalls_bedata *bedata, int *req_id)
 {
*req_id = bedata->ring.req_prod_pvt & (RING_SIZE(&bedata->ring) - 1);
@@ -369,31 +396,23 @@ int pvcalls_front_connect(struct socket *sock, struct 
sockaddr *addr,
if (addr->sa_family != AF_INET || sock->type != SOCK_STREAM)
return -EOPNOTSUPP;
 
-   pvcalls_enter();
-   if (!pvcalls_front_dev) {
-   pvcalls_exit();
-   return -ENOTCONN;
-   }
+   map = pvcalls_enter_sock(sock);
+   if (IS_ERR(map))
+   return PTR_ERR(map);
 
bedata = dev_get_drvdata(&pvcalls_front_dev->dev);
 
-   map = (struct sock_mapping *)sock->sk->sk_send_head;
-   if (!map) {
-   pvcalls_exit();
-   return -ENOTSOCK;
-   }
-
spin_lock(&bedata->socket_lock);
ret = get_request(bedata, &req_id);
if (ret < 0) {
spin_unlock(&bedata->socket_lock);
-   pvcalls_exit();
+   pvcalls_exit_sock(sock);
return ret;
}
ret = create_active(map, &evtchn);
if (ret < 0) {
spin_unlock(&bedata->socket_lock);
-   pvcalls_exit();
+   pvcalls_exit_sock(sock);
return ret;
}
 
@@ -423,7 +442,7 @@ int pvcalls_front_connect(struct socket *sock, struct 
sockaddr *addr,
smp_rmb();
ret = bedata->rsp[req_id].ret;
bedata->rsp[req_id].req_id = PVCALLS_INVALID_ID;
-   pvcalls_exit();
+   pvcalls_exit_sock(sock);
return ret;
 }
 
@@ -488,23 +507,15 @@ int pvcalls_front_sendmsg(struct socket *sock, struct 
msghdr *msg,
if (flags & (MSG_CONFIRM|MSG_DONTROUTE|MSG_EOR|MSG_OOB))
return -EOPNOTSUPP;
 
-   pvcalls_enter();
-   if (!pvcalls_front_dev) {
-   pvcalls_exit();
-   return -ENOTCONN;
-   }
+   map = pvcalls_enter_sock(sock);
+   if (IS_ERR(map))
+   return PTR_ERR(map);
bedata = dev_get_drvdata(&pvcalls_front_dev->dev);
 
-   map = (struct sock_mapping *) sock->sk->sk_send_head;
-   if (!map) {
-   pvcalls_exit();
-   return -ENOTSOCK;
-   }
-
mutex_lock(&map->active.out_mutex);
if ((flags & MSG_DONTWAIT) && !pvcalls_front_write_todo(map)) {
mutex_unlock(&map->active.out_mutex);
-   pvcalls_exit();
+   pvcalls_exit_sock(sock);
return -EAGAIN;
}
if (len > INT_MAX)
@@ -526,7 +537,7 @@ int pvcalls_front_sendmsg(struct socket *sock, struct 
msghdr *msg,
tot_sent = sent;
 
mutex_unlock(&map->active.out_mutex);
-   pvcalls_exit();
+   pvcalls_exit_sock(sock);
return tot_sent;
 }
 
@@ -591,19 +602,11 @@ int pvcalls_front_recvmsg(struct socket *sock, struct 
msghdr *msg, size_t len,
if (flags & (MSG_CMSG_CLOEXEC|MSG_ERRQUEUE|MSG_OOB|MSG_TRUNC))
return -EOPNOTSUPP;
 
-   pvcalls_enter();
-   if (!pvcalls_front_dev) {
-   pvcalls_exit();
-   return -ENOTCONN;
-   }
+   map = pvcalls_enter_sock(sock);
+   if (IS_ERR(map))
+   return PTR_ERR(map);
bedata = dev_get_drvdata(&pvcalls_front_dev->

[Xen-devel] [PATCH v3 2/2] pvcalls-front: wait for other operations to return when release passive sockets

[Stefano Stabellini]

Passive sockets can have ongoing operations on them, specifically, we
have two wait_event_interruptable calls in pvcalls_front_accept.

Add two wake_up calls in pvcalls_front_release, then wait for the
potential waiters to return and release the sock_mapping refcount.

Signed-off-by: Stefano Stabellini 
Acked-by: Juergen Gross 
---
 drivers/xen/pvcalls-front.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c
index 18d1bac..ca5b773 100644
--- a/drivers/xen/pvcalls-front.c
+++ b/drivers/xen/pvcalls-front.c
@@ -1018,6 +1018,12 @@ int pvcalls_front_release(struct socket *sock)
 
pvcalls_front_free_map(bedata, map);
} else {
+   wake_up(&bedata->inflight_req);
+   wake_up(&map->passive.inflight_accept_req);
+
+   while (atomic_read(&map->refcount) > 1)
+   cpu_relax();
+
spin_lock(&bedata->socket_lock);
list_del(&map->list);
spin_unlock(&bedata->socket_lock);
-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v3 0/2] pvcalls-front improvements

[Stefano Stabellini]

Hi all,

this small series introduces a per socket refcount to increase the
efficiency on socket release operations, and makes releasing passive
sockets safe.

Cheers,

Stefano


Changes in v3:
- remove pointless initializers
- reorder pvcalls_enter_sock

Changes in v2:
- add acked-by
- fix check in pvcalls_enter_soc
- fix code style
- nicer checks in pvcalls_front_release


Stefano Stabellini (2):
  pvcalls-front: introduce a per sock_mapping refcount
  pvcalls-front: wait for other operations to return when release passive 
sockets

 drivers/xen/pvcalls-front.c | 197 +++-
 1 file changed, 85 insertions(+), 112 deletions(-)

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v3 2/4] hvm/svm: Enable Breakpoint events

[Andrew Cooper]

On 14/02/18 16:10, Alexandru Stefan ISAILA wrote:
> On Lu, 2018-02-12 at 15:54 +, Andrew Cooper wrote:
>> On 12/02/18 15:08, Alexandru Isaila wrote:
>>> @@ -2619,14 +2634,31 @@ void svm_vmexit_handler(struct
>>> cpu_user_regs *regs)
>>>  break;
>>>
>>>  case VMEXIT_EXCEPTION_BP:
>>> -if ( !v->domain->debugger_attached )
>>> -goto unexpected_exit_type;
>>> -/* AMD Vol2, 15.11: INT3, INTO, BOUND intercepts do not
>>> update RIP. */
>>> -if ( (inst_len = __get_instruction_length(v, INSTR_INT3))
>>> == 0 )
>>> +inst_len = __get_instruction_length(v, INSTR_INT3);
>> There are multiple ways of ending up with this vmexit, and INT3 is
>> not
>> the only way.
>>
>> The old code was somewhat broken (but only in the case that a
>> debugger
>> was attached), but now with  this introspection hook active,
>> executing
>> `0xcd 0x03` will end up crashing the domain because of a length
>> mismatch
>> looking for 0xcc.
>>
>> You need to inspect EXITINTINFO to work out what went on here, and
>> distinguish INT3 from INT $3.
>>
>> Can I suggest that you run this unit test
>> http://xenbits.xen.org/docs/xtf/test-swint-emulation.html under debug
>> introspection an check that you get all expected events?  Every time
>> we
>> touch this code, we seem to break it :(
>>
>> ~Andrew
>>
> I've tested on Intel and AMD and I only get events on int3. Further
> more, I don't think there is any way to use the vmcb->exitintinfo
> because all the fields are 0 on the time of VMEXIT_EXCEPTION_BP. Did I
> understand the test scenario correctly?

Quite possibly, but now I'm even more confused.  I'll have a quick play.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2 1/2] pvcalls-front: introduce a per sock_mapping refcount

[Stefano Stabellini]

On Wed, 14 Feb 2018, Juergen Gross wrote:
> On 13/02/18 03:13, Stefano Stabellini wrote:
> > Introduce a per sock_mapping refcount, in addition to the existing
> > global refcount. Thanks to the sock_mapping refcount, we can safely wait
> > for it to be 1 in pvcalls_front_release before freeing an active socket,
> > instead of waiting for the global refcount to be 1.
> > 
> > Signed-off-by: Stefano Stabellini 
> > 
> > ---
> > Changes in v2:
> > - fix code style
> > - nicer checks in pvcalls_front_release
> > - fix check in pvcalls_enter_sock
> > ---
> >  drivers/xen/pvcalls-front.c | 193 
> > +++-
> >  1 file changed, 81 insertions(+), 112 deletions(-)
> > 
> > diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c
> > index 4c789e6..163bf8c 100644
> > --- a/drivers/xen/pvcalls-front.c
> > +++ b/drivers/xen/pvcalls-front.c
> > @@ -60,6 +60,7 @@ struct sock_mapping {
> > bool active_socket;
> > struct list_head list;
> > struct socket *sock;
> > +   atomic_t refcount;
> > union {
> > struct {
> > int irq;
> > @@ -93,6 +94,34 @@ struct sock_mapping {
> > };
> >  };
> >  
> > +static inline struct sock_mapping *pvcalls_enter_sock(struct socket *sock)
> > +{
> > +   struct sock_mapping *map = NULL;
> 
> Pointless initializer.

I'll fix


> > +
> > +   if (!pvcalls_front_dev ||
> > +   dev_get_drvdata(&pvcalls_front_dev->dev) == NULL)
> > +   return ERR_PTR(-ENOTCONN);
> > +
> > +   pvcalls_enter();
> > +   map = (struct sock_mapping *)sock->sk->sk_send_head;
> > +   if (map == NULL) {
> > +   pvcalls_exit()
> > +   return ERR_PTR(-ENOTSOCK);
> > +   }
> 
> Sorry for noticing this only now: any reason you don't call
> pvcalls_enter() only here instead? This would remove the need of
> calling pvcalls_exit() if map == NULL.
> 
> I can't see pvcalls_enter() protecting sock->sk->sk_send_head in any
> way.

You are right. I'll move it down a couple of lines.


> > +
> > +   atomic_inc(&map->refcount);
> > +   return map;
> > +}
> > +
> > +static inline void pvcalls_exit_sock(struct socket *sock)
> > +{
> > +   struct sock_mapping *map = NULL;
> 
> Pointless initializer again.

I'll fix

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v3 1/4] asm-x86/monitor: Fix monitor capability reporting on SVM systems

[Razvan Cojocaru]

On 02/14/2018 07:47 PM, Andrew Cooper wrote:
> On 12/02/18 15:13, Andrew Cooper wrote:
>> On 12/02/18 15:08, Alexandru Isaila wrote:
>>> No monitor features are available on AMD and all
>>> capabilities are passed only to the Intel processor architecture.
>>> This means that the arch_monitor_get_capabilities returns
>>> capabilities = 0.
>>>
>>> This patch is separating out features which are implemented on both
>>> systems from those implemented only on Intel, so that we advertize the
>>> working capabilities on AMD.
>>>
>>> Signed-off-by: Alexandru Isaila 
> 
> This patch still needs an ack from Tamas or Razvan, but there is no
> comment so far that I can find.

I think Tamas probably wouldn't object, so FWIW:

Acked-by: Razvan Cojocaru 


Thanks,
Razvan

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v3 1/4] asm-x86/monitor: Fix monitor capability reporting on SVM systems

[Andrew Cooper]

On 12/02/18 15:13, Andrew Cooper wrote:
> On 12/02/18 15:08, Alexandru Isaila wrote:
>> No monitor features are available on AMD and all
>> capabilities are passed only to the Intel processor architecture.
>> This means that the arch_monitor_get_capabilities returns
>> capabilities = 0.
>>
>> This patch is separating out features which are implemented on both
>> systems from those implemented only on Intel, so that we advertize the
>> working capabilities on AMD.
>>
>> Signed-off-by: Alexandru Isaila 

This patch still needs an ack from Tamas or Razvan, but there is no
comment so far that I can find.

~Andrew


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Excited for Xen Project in Outreachy

[Lars Kurth]

Hi Kanika,

I CC'ed two lists and the mentors of projects. Thank you for your interest in 
the project.

> I seek guidance in choosing the suitable sub-project in Xen according to my 
> skill set.
We have two sets of projects on 
https://www.outreachy.org/communities/cfp/xen-project/
* 3 around Unikraft (mentor: Simon the technical side, I on the process/people 
side). We are both based in UTC+1 - IRC is #unikraft
* 1 for Xen on ARM (mentors: Stefano & Edgar). Stefano is in UTC-8, Edgar is 
UTC-7 or 6 (can't quite recall) - IRC is #xendevel

> I wish to begin my contribution as soon as possible. I request you to connect 
> me to the mentors in case IRC is not the best way to get in touch with them.
Simon is unfortunately not around this week but will be next week.
Stefano and Edgar, are around I believe

For practical reasons:
* Please sign up to the minios-de...@lists.xenproject.org or 
xen-devel@lists.xenproject.org (as appropriate)
   (see http://lists.xenproject.org for instructions: if you use the "subscribe 
subject pattern" make sure you send the mail to 
minios-devel-requ...@lists.xenproject.org, ...) 
* Please double check time requirements: This is because in the past there 
frequently were issues with Outreachy and University course time requirements 
in particular with Universities from India. I believe that there will be extra 
checks later in the application process, which may require letters from your 
University. We had one case, where an applicant did a small project, but we 
were not allowed to accept her due to time requirements.
* Let us know timezone you are in and when you can hang out on IRC 
* Your registered IRC nickname (please register your nick - see 
https://www.xenproject.org/help/irc.html under Netiquette)

Note that my IRC nick is lars_kurth, Simon's is skuezer, Stefano's is 
sstabellini, and I am afraid I can't remember Edgar's

If you are interested in Unikraft
* Build the hello world unikraft app: see 
https://wiki.xenproject.org/wiki/Category:Unikraft & http://unikraft.neclab.eu/ 
and report back
* Familiarize yourself with the workflow at 
https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#How_to_Generate.2C_and_Submit_a_Xen_Project_Patch_to_MiniOS_and_Unikraft
 (please read the entire document) 

For the ARM project, I will let Stefano and Edgar decide.

Regards
Lars


From: KANIKA SAINI 
Date: Wednesday, 14 February 2018 at 17:25
To: Lars Kurth 
Subject: Excited for Xen Project in Outreachy

Greetings, Lars.

I'm Kanika Saini and I'm super excited to begin contributing to Xen!

I seek guidance in choosing the suitable sub-project in Xen according to my 
skill set. I'm currently pursuing a course in Operating Systems and hence, have 
been gaining knowledge in kernel programming by short assignments like the 
implementation of a system call. I'm familiar with assembly programming in 
MIPS, ARM and x86 as well. 
About high-level programming - I have experience with Java and have used it for 
desktop applications and parallel programming.

There are certain projects listed on the project page and I'm looking for 
mentors' suggestion on what could be the best for both me and Xen. I have 
introduced myself on the #unikraft channel and I'm expecting a reply from the 
community.

I wish to begin my contribution as soon as possible. I request you to connect 
me to the mentors in case IRC is not the best way to get in touch with them.

Thank you!


-- 
Yours sincerely,
Kanika Saini
CSE, IIITD Class of 2020



‌

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v4 2/7] xen: xsm: flask: introduce XENMAPSPACE_gmfn_share for memory sharing

[Zhongze Liu]

Hi Jan,

2018-02-14 16:37 GMT+08:00 Jan Beulich :
 On 14.02.18 at 08:15,  wrote:
>> Hi Jan,
>>
>> 2018-02-13 23:26 GMT+08:00 Jan Beulich :
>> On 13.02.18 at 16:15,  wrote:
 I've updated the comments according to your previous suggestions,
 do they look good to you?
>>>
>>> The one in the public header is way too verbose. I specifically don't
>>> see why you would need to spell out XSM privilege requirements
>>> there. Please make new comments match existing ones in style and
>>> verbosity if at all possible, while still conveying all necessary /
>>> relevant information.
>>>
>>
>> I shortened it a little bit, and now it looks like:
>>
>> #define XENMAPSPACE_gmfn_share   6 /* GMFN from another dom. Unlike
>> gmfn_foreign,
>>   if (c) tries to map pages from (t) into
>>   (d), this doesn't require that (d) 
>> itself
>>   has the privilege to map the pages, but
>>   instead requires that (c) has the
>>   privilege to do so, as long as (d) and 
>> (t)
>>   are allowed to share memory pages.
>>   This is XENMEM_add_to_physmap_batch 
>> only,
>>   and currently ARM only. */
>
> Which leaves unclear what (c), (d), and (t) are. How about
>
> "GMFN from another dom, XENMEM_add_to_physmap_batch (and
> currently ARM) only. Other than XENMAPSPACE_gmfn_foreign this
> ."
>
> (You can and should go into further detail in the commit message.)
> Without this _properly_ explained, I'll continue to ask why you
> can't simply make XENMAPSPACE_gmfn_foreign do what you want
> (as it already takes two domid_t-s as input), by suitably adjusting
> its XSM check(s).

I'm sorry that I failed to see the reason why you say "which leaves
unclear what (c), (d), and (t) are". I think "if (c) tries to map pages
from (t) into (d)" has already included the necessary information
about this: (c) is the caller of the hypercall (current), (d) is the
dest domain, and (t) the source domain.
I think I still need more of your explanation here.

>
> You'd also need to adjust the comment on the foreign_domid
> structure field, as it saying "gmfn_foreign" would otherwise become
> stale with your change.

Thanks for pointing out that. I've already updated it.

>
> I don't, btw, like the ARM only part here - there's nothing
> inherently wrong with the same operation being sensible on x86.
>

I agree that we should make this also available to x86 guests, but
we have to fix the FIXME in x86/mm/p2m.c: p2m_add_foreign() first.
And that, I think, should be done in another patch set. And "currently"
here also means that it's planned to be fixed. I just don't want to
disappoint the users who are eager to try this new subop out but end
up getting weired errors.

Cheers,

Zhongze Liu

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [xen-unstable-smoke test] 119190: tolerable all pass - PUSHED

[osstest service owner]

flight 119190 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/119190/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  a2b08fbed388f18235fda5ba1655c1483ef3e215
baseline version:
 xen  f25dce4a2adf518678280495712d66e627adec1e

Last test of basis   119170  2018-02-14 09:35:11 Z0 days
Testing same since   119190  2018-02-14 14:01:20 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

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
   f25dce4a2a..a2b08fbed3  a2b08fbed388f18235fda5ba1655c1483ef3e215 -> smoke

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [linux-linus test] 119117: regressions - FAIL

[osstest service owner]

flight 119117 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/119117/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 118324
 test-amd64-i386-libvirt   7 xen-boot fail REGR. vs. 118324
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 xen-boot  fail REGR. vs. 118324
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
118324
 test-amd64-i386-xl-qemuu-win10-i386  7 xen-boot  fail REGR. vs. 118324
 test-amd64-i386-freebsd10-amd64  7 xen-boot  fail REGR. vs. 118324
 test-amd64-i386-xl-qemut-win7-amd64  7 xen-boot  fail REGR. vs. 118324
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  7 xen-boot fail REGR. vs. 118324
 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 118324
 test-amd64-i386-xl-qemut-debianhvm-amd64  7 xen-boot fail REGR. vs. 118324
 test-amd64-i386-qemut-rhel6hvm-amd  7 xen-boot   fail REGR. vs. 118324
 test-amd64-i386-qemuu-rhel6hvm-amd  7 xen-boot   fail REGR. vs. 118324
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start   fail REGR. vs. 118324
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail REGR. vs. 118324
 test-amd64-i386-examine   8 reboot   fail REGR. vs. 118324
 test-amd64-i386-qemuu-rhel6hvm-intel  7 xen-boot fail REGR. vs. 118324
 test-amd64-i386-xl-qemut-ws16-amd64  7 xen-boot  fail REGR. vs. 118324
 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 118324
 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 118324
 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 118324
 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 118324
 test-amd64-i386-qemut-rhel6hvm-intel  7 xen-boot fail REGR. vs. 118324
 test-amd64-i386-xl-qemut-win10-i386  7 xen-boot  fail REGR. vs. 118324
 test-amd64-i386-rumprun-i386  7 xen-boot fail REGR. vs. 118324
 test-amd64-i386-xl-qemuu-win7-amd64  7 xen-boot  fail REGR. vs. 118324
 test-amd64-i386-xl-qemuu-debianhvm-amd64  7 xen-boot fail REGR. vs. 118324
 test-amd64-i386-libvirt-xsm   7 xen-boot fail REGR. vs. 118324
 test-amd64-i386-xl7 xen-boot fail REGR. vs. 118324
 test-amd64-i386-freebsd10-i386  7 xen-boot   fail REGR. vs. 118324
 test-amd64-i386-xl-qemuu-ws16-amd64  7 xen-boot  fail REGR. vs. 118324
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  7 xen-boot fail REGR. vs. 118324
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
118324

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 118324
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 118324
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 118324
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 118324
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 118324
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 118324
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 118324
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-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-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 

[Xen-devel] [PATCH] x86/xpti: Hide almost all of .text and all .data/.rodata/.bss mappings

[Andrew Cooper]

The current XPTI implementation isolates the directmap (and therefore a lot of
guest data), but a large quantity of CPU0's state (including its stack)
remains visible.

Furthermore, an attacker able to read .text is in a vastly superior position
to normal when it comes to fingerprinting Xen for known vulnerabilities, or
scanning for ROP/Spectre gadgets.

Collect together the entrypoints in .text.entry (currently 3x4k frames, but
can almost certainly be slimmed down), and create a common mapping which is
inserted into each per-cpu shadow.  The stubs are also inserted into this
mapping by pointing at the in-use L2.  This allows stubs allocated later (SMP
boot, or CPU hotplug) to work without further changes to the common mappings.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
CC: Juergen Gross 

v2:
 * Drop "incomplete" warning from the docs.  This is about as complete as it
   can reasonably get.
 * Correct BUILD_BUG_ON() calculation, duplicate in the common_pgt code
 * scope/const improvements
 * Use .push/.popsection in preference to .previous
 * Exclude {compat_}create_bounce_frame from .text.entry
 * Extend the sanity checking of linear in clone_mapping().  There is a latent
   bug where a bad linear parameter would cause Xen to fall over a NULL pointer.
---
 docs/misc/xen-command-line.markdown |  3 --
 xen/arch/x86/smpboot.c  | 56 +
 xen/arch/x86/x86_64/compat/entry.S  |  5 
 xen/arch/x86/x86_64/entry.S | 11 ++--
 xen/arch/x86/xen.lds.S  |  7 +
 5 files changed, 71 insertions(+), 11 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 79feba6..8317639 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1935,9 +1935,6 @@ mode.
 Override default selection of whether to isolate 64-bit PV guest page
 tables.
 
-** WARNING: Not yet a complete isolation implementation, but better than
-nothing. **
-
 ### xsave
 > `= `
 
diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
index 2ebef03..10bf2f3 100644
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -622,6 +622,9 @@ unsigned long alloc_stub_page(unsigned int cpu, unsigned 
long *mfn)
 unmap_domain_page(memset(__map_domain_page(pg), 0xcc, PAGE_SIZE));
 }
 
+/* Confirm that all stubs fit in a single L2 pagetable. */
+BUILD_BUG_ON(NR_CPUS * PAGE_SIZE > (1u << L3_PAGETABLE_SHIFT));
+
 stub_va = XEN_VIRT_END - (cpu + 1) * PAGE_SIZE;
 if ( map_pages_to_xen(stub_va, mfn_x(page_to_mfn(pg)), 1,
   PAGE_HYPERVISOR_RX | MAP_SMALL_PAGES) )
@@ -646,13 +649,23 @@ static int clone_mapping(const void *ptr, root_pgentry_t 
*rpt)
 {
 unsigned long linear = (unsigned long)ptr, pfn;
 unsigned int flags;
-l3_pgentry_t *pl3e = l4e_to_l3e(idle_pg_table[root_table_offset(linear)]) +
- l3_table_offset(linear);
+l3_pgentry_t *pl3e;
 l2_pgentry_t *pl2e;
 l1_pgentry_t *pl1e;
 
-if ( linear < DIRECTMAP_VIRT_START )
-return 0;
+/*
+ * Sanity check 'linear'.  We only allow cloning from the Xen virtual
+ * range, and in particular, only from the directmap and .text ranges.
+ */
+if ( root_table_offset(linear) > ROOT_PAGETABLE_LAST_XEN_SLOT ||
+ root_table_offset(linear) < ROOT_PAGETABLE_FIRST_XEN_SLOT )
+return -EINVAL;
+if ( !(linear >= DIRECTMAP_VIRT_START ||
+   (linear >= XEN_VIRT_START && linear < XEN_VIRT_END)) )
+return -EINVAL;
+
+pl3e = l4e_to_l3e(idle_pg_table[root_table_offset(linear)]) +
+l3_table_offset(linear);
 
 flags = l3e_get_flags(*pl3e);
 ASSERT(flags & _PAGE_PRESENT);
@@ -744,8 +757,12 @@ static __read_mostly int8_t opt_xpti = -1;
 boolean_param("xpti", opt_xpti);
 DEFINE_PER_CPU(root_pgentry_t *, root_pgt);
 
+extern const char _stextentry[], _etextentry[];
+
 static int setup_cpu_root_pgt(unsigned int cpu)
 {
+static root_pgentry_t common_pgt;
+
 root_pgentry_t *rpt;
 unsigned int off;
 int rc;
@@ -764,8 +781,35 @@ static int setup_cpu_root_pgt(unsigned int cpu)
 idle_pg_table[root_table_offset(RO_MPT_VIRT_START)];
 /* SH_LINEAR_PT inserted together with guest mappings. */
 /* PERDOMAIN inserted during context switch. */
-rpt[root_table_offset(XEN_VIRT_START)] =
-idle_pg_table[root_table_offset(XEN_VIRT_START)];
+
+/* One-time setup of common_pgt, which maps .text.entry and the stubs. */
+if ( unlikely(!root_get_intpte(common_pgt)) )
+{
+unsigned long stubs_linear = XEN_VIRT_END - 1;
+l3_pgentry_t *stubs_main, *stubs_shadow;
+const char *ptr;
+
+for ( rc = 0, ptr = _stextentry;
+  !rc && ptr < _etextentry; ptr += PAGE_SIZE )
+rc = clone_mapping(ptr, rpt);
+
+if ( rc )
+return rc;
+
+/* Confirm that all stubs fit in a single L2 paget

Re: [Xen-devel] [PATCH v3 2/4] hvm/svm: Enable Breakpoint events

[Alexandru Stefan ISAILA]

On Lu, 2018-02-12 at 15:54 +, Andrew Cooper wrote:
> On 12/02/18 15:08, Alexandru Isaila wrote:
> >
> > @@ -2619,14 +2634,31 @@ void svm_vmexit_handler(struct
> > cpu_user_regs *regs)
> >  break;
> >
> >  case VMEXIT_EXCEPTION_BP:
> > -if ( !v->domain->debugger_attached )
> > -goto unexpected_exit_type;
> > -/* AMD Vol2, 15.11: INT3, INTO, BOUND intercepts do not
> > update RIP. */
> > -if ( (inst_len = __get_instruction_length(v, INSTR_INT3))
> > == 0 )
> > +inst_len = __get_instruction_length(v, INSTR_INT3);
> There are multiple ways of ending up with this vmexit, and INT3 is
> not
> the only way.
>
> The old code was somewhat broken (but only in the case that a
> debugger
> was attached), but now with  this introspection hook active,
> executing
> `0xcd 0x03` will end up crashing the domain because of a length
> mismatch
> looking for 0xcc.
>
> You need to inspect EXITINTINFO to work out what went on here, and
> distinguish INT3 from INT $3.
>
> Can I suggest that you run this unit test
> http://xenbits.xen.org/docs/xtf/test-swint-emulation.html under debug
> introspection an check that you get all expected events?  Every time
> we
> touch this code, we seem to break it :(
>
> ~Andrew
>
I've tested on Intel and AMD and I only get events on int3. Further
more, I don't think there is any way to use the vmcb->exitintinfo
because all the fields are 0 on the time of VMEXIT_EXCEPTION_BP. Did I
understand the test scenario correctly?

Thanks,
Alex


This email was scanned by Bitdefender
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH V4] x86/hvm: fix domain crash when CR3 has the noflush bit set

[Razvan Cojocaru]

On 02/14/2018 05:35 PM, Tamas K Lengyel wrote:
> On Fri, Feb 9, 2018 at 4:01 AM, Razvan Cojocaru
>  wrote:
>> The emulation layers of Xen lack PCID support, and as we only offer
>> PCID to HAP guests, all writes to CR3 are handled by hardware,
>> except when introspection is involved. Consequently, trying to set
>> CR3 when the noflush bit is set in hvm_set_cr3() leads to domain
>> crashes. The workaround is to clear the noflush bit in
>> hvm_set_cr3(). CR3 values in hvm_monitor_cr() are also sanitized.
>> Additionally, a bool parameter now propagates to
>> {svm,vmx}_update_guest_cr(), so that no flushes occur when
>> the bit was set.
>>
>> Signed-off-by: Razvan Cojocaru 
>> Reported-by: Bitweasil 
>> Suggested-by: Andrew Cooper 
> 
> Acked-by: Tamas K Lengyel 

Thanks!

Razvan

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH V4] x86/hvm: fix domain crash when CR3 has the noflush bit set

[Tamas K Lengyel]

On Fri, Feb 9, 2018 at 4:01 AM, Razvan Cojocaru
 wrote:
> The emulation layers of Xen lack PCID support, and as we only offer
> PCID to HAP guests, all writes to CR3 are handled by hardware,
> except when introspection is involved. Consequently, trying to set
> CR3 when the noflush bit is set in hvm_set_cr3() leads to domain
> crashes. The workaround is to clear the noflush bit in
> hvm_set_cr3(). CR3 values in hvm_monitor_cr() are also sanitized.
> Additionally, a bool parameter now propagates to
> {svm,vmx}_update_guest_cr(), so that no flushes occur when
> the bit was set.
>
> Signed-off-by: Razvan Cojocaru 
> Reported-by: Bitweasil 
> Suggested-by: Andrew Cooper 

Acked-by: Tamas K Lengyel 

>
> ---
> Changes since V3:
>  - Removed unnecessary !! from "noflush = !!(value & X86_CR3_NOFLUSH);"
>  - Moved the X86_CR3_NOFLUSH #define to x86-defns.h.
>  - Removed X86_CR3_NOFLUSH_DISABLE_MASK (using ~X86_CR3_NOFLUSH).
>  - Reverted changes to hvm_update_guest_cr() and callers, and added
>hvm_update_guest_cr3() instead.
>  - Added HVM_UPDATE_GUEST_CR3_NO_FLUSH as a potential flag to pass
>to update_guest_cr(), instead of a simple bool which did not
>apply to all CRs.
> ---
>  xen/arch/x86/hvm/hvm.c| 13 ++---
>  xen/arch/x86/hvm/monitor.c|  3 +++
>  xen/arch/x86/hvm/svm/svm.c| 22 ++
>  xen/arch/x86/hvm/vmx/vmx.c| 18 +++---
>  xen/arch/x86/mm.c |  2 +-
>  xen/arch/x86/mm/hap/hap.c |  6 +++---
>  xen/arch/x86/mm/shadow/common.c   |  2 +-
>  xen/arch/x86/mm/shadow/multi.c|  6 +++---
>  xen/arch/x86/mm/shadow/none.c |  2 +-
>  xen/include/asm-x86/hvm/hvm.h | 15 +--
>  xen/include/asm-x86/hvm/svm/svm.h |  2 +-
>  xen/include/asm-x86/paging.h  |  7 ---
>  xen/include/asm-x86/x86-defns.h   |  5 +
>  13 files changed, 70 insertions(+), 33 deletions(-)
>
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 18d721d..f17163e 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -2297,6 +2297,7 @@ int hvm_set_cr3(unsigned long value, bool_t may_defer)
>  struct vcpu *v = current;
>  struct page_info *page;
>  unsigned long old = v->arch.hvm_vcpu.guest_cr[3];
> +bool noflush = false;
>
>  if ( may_defer && unlikely(v->domain->arch.monitor.write_ctrlreg_enabled 
> &
> monitor_ctrlreg_bitmask(VM_EVENT_X86_CR3)) )
> @@ -2313,6 +2314,12 @@ int hvm_set_cr3(unsigned long value, bool_t may_defer)
>  }
>  }
>
> +if ( hvm_pcid_enabled(v) ) /* Clear the noflush bit. */
> +{
> +noflush = value & X86_CR3_NOFLUSH;
> +value &= ~X86_CR3_NOFLUSH;
> +}
> +
>  if ( hvm_paging_enabled(v) && !paging_mode_hap(v->domain) &&
>   (value != v->arch.hvm_vcpu.guest_cr[3]) )
>  {
> @@ -2330,7 +2337,7 @@ int hvm_set_cr3(unsigned long value, bool_t may_defer)
>  }
>
>  v->arch.hvm_vcpu.guest_cr[3] = value;
> -paging_update_cr3(v);
> +paging_update_cr3(v, noflush);
>  return X86EMUL_OKAY;
>
>   bad_cr3:
> @@ -4031,7 +4038,7 @@ static int hvmop_flush_tlb_all(void)
>
>  /* Flush paging-mode soft state (e.g., va->gfn cache; PAE PDPE cache). */
>  for_each_vcpu ( d, v )
> -paging_update_cr3(v);
> +paging_update_cr3(v, false);
>
>  /* Flush all dirty TLBs. */
>  flush_tlb_mask(d->dirty_cpumask);
> @@ -4193,7 +4200,7 @@ static int hvmop_set_param(
>  domain_pause(d);
>  d->arch.hvm_domain.params[a.index] = a.value;
>  for_each_vcpu ( d, v )
> -paging_update_cr3(v);
> +paging_update_cr3(v, false);
>  domain_unpause(d);
>
>  domctl_lock_release();
> diff --git a/xen/arch/x86/hvm/monitor.c b/xen/arch/x86/hvm/monitor.c
> index 131b852..87e7e31 100644
> --- a/xen/arch/x86/hvm/monitor.c
> +++ b/xen/arch/x86/hvm/monitor.c
> @@ -36,6 +36,9 @@ bool hvm_monitor_cr(unsigned int index, unsigned long 
> value, unsigned long old)
>  struct arch_domain *ad = &curr->domain->arch;
>  unsigned int ctrlreg_bitmask = monitor_ctrlreg_bitmask(index);
>
> +if ( index == VM_EVENT_X86_CR3 && hvm_pcid_enabled(curr) )
> +value &= ~X86_CR3_NOFLUSH; /* Clear the noflush bit. */
> +
>  if ( (ad->monitor.write_ctrlreg_enabled & ctrlreg_bitmask) &&
>   (!(ad->monitor.write_ctrlreg_onchangeonly & ctrlreg_bitmask) ||
>value != old) &&
> diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
> index 81cf5b8..4e74f62 100644
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -315,9 +315,9 @@ static int svm_vmcb_restore(struct vcpu *v, struct 
> hvm_hw_cpu *c)
>  v->arch.hvm_vcpu.guest_cr[2] = c->cr2;
>  v->arch.hvm_vcpu.guest_cr[3] = c->cr3;
>  v->arch.hvm_vcpu.guest_cr[4] = c->cr4;
> -svm_update_guest_cr(v, 0);
> -svm_update_guest_cr(v, 2);
> -svm_update_guest_cr(v, 4);
> +svm_update_

Re: [Xen-devel] [PATCH v2] xen/arm: Park CPUs with a MIDR different from the boot CPU.

[Oleksandr Tyshchenko]

Hi

On Wed, Feb 14, 2018 at 4:47 PM, Oleksandr Tyshchenko
 wrote:
> Hi, Julien.
>
> On Wed, Feb 14, 2018 at 4:17 PM, Julien Grall  wrote:
>> Xen does not properly support big.LITTLE platform. All vCPUs of a guest
>> will always have the MIDR of the boot CPU (see arch_domain_create).
>> At best the guest may see unreliable performance (vCPU switching between
>> big and LITTLE), at worst the guest will become unreliable or insecure.
>>
>> This is becoming more apparent with branch predictor hardening in Linux
>> because they target a specific kind of CPUs and may not work on other
>> CPUs.
>>
>> For the time being, park any CPUs with a MDIR different from the boot
>> CPU. This will be revisited in the future once Xen gains understanding
>> of big.LITTLE.
>>
>> [1] 
>> https://lists.xenproject.org/archives/html/xen-devel/2016-12/msg00826.html
>>
>> Signed-off-by: Julien Grall 
>>
>> ---
>>
>> We probably want to backport this as part of XSA-254. Using big.LITTLE
>> on Xen has never been supported but we didn't make it clearly. This is
>> becoming more apparent with code targeting specific CPUs.
>>
>> Changes in v2:
>> - Add a command line option to override the default behavior.
>> ---
>>  docs/misc/xen-command-line.markdown | 10 ++
>>  xen/arch/arm/smpboot.c  | 26 ++
>>  2 files changed, 36 insertions(+)
>>
>> diff --git a/docs/misc/xen-command-line.markdown 
>> b/docs/misc/xen-command-line.markdown
>> index 79feba6bcd..cf5997b8db 100644
>> --- a/docs/misc/xen-command-line.markdown
>> +++ b/docs/misc/xen-command-line.markdown
>> @@ -1000,6 +1000,16 @@ supported only when compiled with XSM on x86.
>>
>>  Control Xens use of the APEI Hardware Error Source Table, should one be 
>> found.
>>
>> +### hmp_unsafe (arm)
>> +> `= `
>> +
>> +> Default : `false`
>> +
>> +Say yes at your own risk if you want to enable heterogenous computing
>> +(such as big.LITTLE). This may result to an unstable and insecure
>> +platform. When the option is disabled (default), CPUs that are not
>> +identical to the boot CPU will be parked and not used by Xen.
>> +
>>  ### hpetbroadcast
>>  > `= `
>>
>> diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
>> index 1255185a9c..5c05cadb0a 100644
>> --- a/xen/arch/arm/smpboot.c
>> +++ b/xen/arch/arm/smpboot.c
>> @@ -27,6 +27,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -69,6 +70,13 @@ DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, 
>> cpu_sibling_mask);
>>  /* representing HT and core siblings of each logical CPU */
>>  DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_core_mask);
>>
>> +/*
>> + * By default non-boot CPUs not identical to the boot CPU will be
>> + * parked.
>> + */
>> +static bool __read_mostly opt_hmp_unsafe = false;
I think, you can remove the initialization of variable.

>> +boolean_param("hmp_unsafe", opt_hmp_unsafe);
>> +
>>  static void setup_cpu_sibling_map(int cpu)
>>  {
>>  if ( !zalloc_cpumask_var(&per_cpu(cpu_sibling_mask, cpu)) ||
>> @@ -255,6 +263,9 @@ void __init smp_init_cpus(void)
>>  else
>>  acpi_smp_init_cpus();
>>
>> +if ( opt_hmp_unsafe )
>> +warning_add("WARNING: HMP COMPUTING HAS BEEN ENABLED.\n"
>> +"It has implications on the security and stability of 
>> the system.\n");
>>  }
>>
>>  int __init
>> @@ -292,6 +303,21 @@ void start_secondary(unsigned long boot_phys_offset,
>>
>>  init_traps();
>>
>> +/*
>> + * Currently Xen assumes the platform has only one kind of CPUs.
>> + * This assumption does not hold on big.LITTLE platform and may
>> + * result to instability and insecure platform. Better to park them
>> + * for now.
>> + */
>> +if ( !opt_hmp_unsafe &&
>> + current_cpu_data.midr.bits != boot_cpu_data.midr.bits )
>> +{
>> +printk(XENLOG_ERR "CPU%u MIDR (0x%x) does not match boot CPU MIDR 
>> (0x%x).\n",
>> +   smp_processor_id(), current_cpu_data.midr.bits,
>> +   boot_cpu_data.midr.bits);
>> +stop_cpu();
>> +}
>> +
>>  mmu_init_secondary_cpu();
>>
>>  gic_init_secondary_cpu();
>> --
>> 2.11.0
>>
>>
>> ___
>> Xen-devel mailing list
>> Xen-devel@lists.xenproject.org
>> https://lists.xenproject.org/mailman/listinfo/xen-devel
>
> Thanks for leaving an option to enable hmp back. We understand the
> possible risks, but we are playing with big and LITTLE cores for test
> purposes
> and without such option we will have to revert the patch to allow
> LITTLE cores to up and running.
>
> --
> Regards,
>
> Oleksandr Tyshchenko

Reviewed-by: Oleksandr Tyshchenko 

-- 
Regards,

Oleksandr Tyshchenko

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v2 1/2] xen/arm: Extend the number of memory banks supported

[Julien Grall]

When booting using Grub on Thunder-X, the number of memory available is
greater than 64. Bump the number to 128, so we can take advantage of all
the memory.

Signed-off-by: Julien Grall 

---

Note that I wasn't able to boot without this patch, because EFI stub
is printing an error when the number of region exceed 64. This will
result to fragment in bit more the memory (sounds like print
allocate memory) and will fail to get the memory on retry.
---
 xen/include/asm-arm/setup.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index 7ff2c34dab..0cc3330807 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -6,7 +6,7 @@
 #define MIN_FDT_ALIGN 8
 #define MAX_FDT_SIZE SZ_2M
 
-#define NR_MEM_BANKS 64
+#define NR_MEM_BANKS 128
 
 #define MAX_MODULES 5 /* Current maximum useful modules */
 
-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v2 2/2] xen/arm: Blacklist SMMU on Thunder-X

[Julien Grall]

Xen does not yet support Cavium SMMU because it requires some
workaround. For the time being, blacklist them.

Signed-off-by: Julien Grall 

---
Changes in v2:
- Fix compatible string
---
 xen/arch/arm/platforms/Makefile   |  1 +
 xen/arch/arm/platforms/thunderx.c | 39 +++
 2 files changed, 40 insertions(+)
 create mode 100644 xen/arch/arm/platforms/thunderx.c

diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile
index 53a47e48d2..80e555cc14 100644
--- a/xen/arch/arm/platforms/Makefile
+++ b/xen/arch/arm/platforms/Makefile
@@ -6,5 +6,6 @@ obj-$(CONFIG_ARM_32) += omap5.o
 obj-$(CONFIG_ARM_32) += rcar2.o
 obj-$(CONFIG_ARM_64) += seattle.o
 obj-y += sunxi.o
+obj-$(CONFIG_ARM_64) += thunderx.o
 obj-$(CONFIG_ARM_64) += xgene-storm.o
 obj-$(CONFIG_ARM_64) += xilinx-zynqmp.o
diff --git a/xen/arch/arm/platforms/thunderx.c 
b/xen/arch/arm/platforms/thunderx.c
new file mode 100644
index 00..9b32a29c6b
--- /dev/null
+++ b/xen/arch/arm/platforms/thunderx.c
@@ -0,0 +1,39 @@
+/*
+ * xen/arch/arm/platforms/thunderx.c
+ *
+ * Cavium Thunder-X specific settings
+ *
+ * Copyright (c) 2018 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; under version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; If not, see .
+ */
+
+#include 
+
+static const char * const thunderx_dt_compat[] __initconst =
+{
+"cavium,thunder-88xx",
+NULL
+};
+
+static const struct dt_device_match thunderx_blacklist_dev[] __initconst =
+{
+/* Cavium has its own SMMU which is not yet supported. */
+DT_MATCH_COMPATIBLE("cavium,smmu-v2"),
+{ /* sentinel */ },
+};
+
+PLATFORM_START(thunderx, "THUNDERX")
+.compatible = thunderx_dt_compat,
+.blacklist_dev = thunderx_blacklist_dev,
+PLATFORM_END
-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v2 0/2] Fixup for booting Xen on Thunder-X using Grub

[Julien Grall]

Hi all,

This small series will help to boot Xen on Thunder-X using Grub. This part
of my work to use Thunder-X in Osstest

Cheers,

Julien Grall (2):
  xen/arm: Extend the number of memory banks supported
  xen/arm: Blacklist SMMU on Thunder-X

 xen/arch/arm/platforms/Makefile   |  1 +
 xen/arch/arm/platforms/thunderx.c | 39 +++
 xen/include/asm-arm/setup.h   |  2 +-
 3 files changed, 41 insertions(+), 1 deletion(-)
 create mode 100644 xen/arch/arm/platforms/thunderx.c

-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] Osstest linux-arm-xen moved to 4.14

[Julien Grall]

Hi,

I have updated the linux-arm-xen branch to use Linux 4.14.19. This is 
the latest stable and should have better support for Arm64 hardware.


At the moment, I merged the linux-stable/linux-4.14.y to linux-arm-xen 
avoiding a rebase. Once it has pushed by osstest, we should reset the 
tree to get the logs a bit more streamlined and do a force push.


Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2] xen/arm: Park CPUs with a MIDR different from the boot CPU.

[Oleksandr Tyshchenko]

Hi, Julien.

On Wed, Feb 14, 2018 at 4:17 PM, Julien Grall  wrote:
> Xen does not properly support big.LITTLE platform. All vCPUs of a guest
> will always have the MIDR of the boot CPU (see arch_domain_create).
> At best the guest may see unreliable performance (vCPU switching between
> big and LITTLE), at worst the guest will become unreliable or insecure.
>
> This is becoming more apparent with branch predictor hardening in Linux
> because they target a specific kind of CPUs and may not work on other
> CPUs.
>
> For the time being, park any CPUs with a MDIR different from the boot
> CPU. This will be revisited in the future once Xen gains understanding
> of big.LITTLE.
>
> [1] https://lists.xenproject.org/archives/html/xen-devel/2016-12/msg00826.html
>
> Signed-off-by: Julien Grall 
>
> ---
>
> We probably want to backport this as part of XSA-254. Using big.LITTLE
> on Xen has never been supported but we didn't make it clearly. This is
> becoming more apparent with code targeting specific CPUs.
>
> Changes in v2:
> - Add a command line option to override the default behavior.
> ---
>  docs/misc/xen-command-line.markdown | 10 ++
>  xen/arch/arm/smpboot.c  | 26 ++
>  2 files changed, 36 insertions(+)
>
> diff --git a/docs/misc/xen-command-line.markdown 
> b/docs/misc/xen-command-line.markdown
> index 79feba6bcd..cf5997b8db 100644
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -1000,6 +1000,16 @@ supported only when compiled with XSM on x86.
>
>  Control Xens use of the APEI Hardware Error Source Table, should one be 
> found.
>
> +### hmp_unsafe (arm)
> +> `= `
> +
> +> Default : `false`
> +
> +Say yes at your own risk if you want to enable heterogenous computing
> +(such as big.LITTLE). This may result to an unstable and insecure
> +platform. When the option is disabled (default), CPUs that are not
> +identical to the boot CPU will be parked and not used by Xen.
> +
>  ### hpetbroadcast
>  > `= `
>
> diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
> index 1255185a9c..5c05cadb0a 100644
> --- a/xen/arch/arm/smpboot.c
> +++ b/xen/arch/arm/smpboot.c
> @@ -27,6 +27,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -69,6 +70,13 @@ DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, 
> cpu_sibling_mask);
>  /* representing HT and core siblings of each logical CPU */
>  DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_core_mask);
>
> +/*
> + * By default non-boot CPUs not identical to the boot CPU will be
> + * parked.
> + */
> +static bool __read_mostly opt_hmp_unsafe = false;
> +boolean_param("hmp_unsafe", opt_hmp_unsafe);
> +
>  static void setup_cpu_sibling_map(int cpu)
>  {
>  if ( !zalloc_cpumask_var(&per_cpu(cpu_sibling_mask, cpu)) ||
> @@ -255,6 +263,9 @@ void __init smp_init_cpus(void)
>  else
>  acpi_smp_init_cpus();
>
> +if ( opt_hmp_unsafe )
> +warning_add("WARNING: HMP COMPUTING HAS BEEN ENABLED.\n"
> +"It has implications on the security and stability of 
> the system.\n");
>  }
>
>  int __init
> @@ -292,6 +303,21 @@ void start_secondary(unsigned long boot_phys_offset,
>
>  init_traps();
>
> +/*
> + * Currently Xen assumes the platform has only one kind of CPUs.
> + * This assumption does not hold on big.LITTLE platform and may
> + * result to instability and insecure platform. Better to park them
> + * for now.
> + */
> +if ( !opt_hmp_unsafe &&
> + current_cpu_data.midr.bits != boot_cpu_data.midr.bits )
> +{
> +printk(XENLOG_ERR "CPU%u MIDR (0x%x) does not match boot CPU MIDR 
> (0x%x).\n",
> +   smp_processor_id(), current_cpu_data.midr.bits,
> +   boot_cpu_data.midr.bits);
> +stop_cpu();
> +}
> +
>  mmu_init_secondary_cpu();
>
>  gic_init_secondary_cpu();
> --
> 2.11.0
>
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel

Thanks for leaving an option to enable hmp back. We understand the
possible risks, but we are playing with big and LITTLE cores for test
purposes
and without such option we will have to revert the patch to allow
LITTLE cores to up and running.

-- 
Regards,

Oleksandr Tyshchenko

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v4 5/7] libxl: support unmapping static shared memory areas during domain destruction

[Wei Liu]

On Mon, Feb 12, 2018 at 03:24:26PM +, Julien Grall wrote:
> 
> 
> On 12/02/18 15:17, Zhongze Liu wrote:
> > Hi Julien,
> 
> Hi,
> 
> > 
> > 2018-02-12 23:09 GMT+08:00 Julien Grall :
> > > Hi,
> > > 
> > > On 12/02/18 14:52, Zhongze Liu wrote:
> > > > 
> > > > 2018-02-08 0:54 GMT+08:00 Julien Grall :
> > > > > 
> > > > > On 07/02/18 16:27, Zhongze Liu wrote:
> > > > 
> > > > It seems that I mistakenly use transaction as a global lock. Now I don't
> > > > have
> > > > any reasons not putting the unmap out of the transaction, but this will
> > > > break
> > > > the original transaction into two, and I do think that we need some
> > > > explicit
> > > > locking here.
> > > 
> > > 
> > > Can you explain why you need specific locking here? What are you trying to
> > > protect? Are you trying to protect against two process doing the unmap?
> > > 
> > 
> > Yes.
> 
> I don't think you have to worry about the locking here. With the current
> interface, the regions cannot be modified after the guest has booted. So the
> addresses will always stay valid.
> 
> This code path should never be called concurrently, as a lot of code in
> libxl, so I think someone else will take care about that for you (I will let
> Wei confirm here).
> 
> In any case, the worst that could happen is the unmap is called twice on the
> same region. So you would get spurious error message. Not that bad.

Yeah, not that bad. Not going to be a security issue, not going to leak
resources in the end.

To avoid spurious unmap, can we maybe unmap the pages after the xenstore
transaction is committed? In that case, only the successful one gets to
unmap, the ones that aren't committed will bail.

(Just tossing around ideas)

Wei.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v4 5/7] libxl: support unmapping static shared memory areas during domain destruction

[Wei Liu]

On Mon, Feb 12, 2018 at 03:24:26PM +, Julien Grall wrote:
> 
> 
> On 12/02/18 15:17, Zhongze Liu wrote:
> > Hi Julien,
> 
> Hi,
> 
> > 
> > 2018-02-12 23:09 GMT+08:00 Julien Grall :
> > > Hi,
> > > 
> > > On 12/02/18 14:52, Zhongze Liu wrote:
> > > > 
> > > > 2018-02-08 0:54 GMT+08:00 Julien Grall :
> > > > > 
> > > > > On 07/02/18 16:27, Zhongze Liu wrote:
> > > > 
> > > > It seems that I mistakenly use transaction as a global lock. Now I don't
> > > > have
> > > > any reasons not putting the unmap out of the transaction, but this will
> > > > break
> > > > the original transaction into two, and I do think that we need some
> > > > explicit
> > > > locking here.
> > > 
> > > 
> > > Can you explain why you need specific locking here? What are you trying to
> > > protect? Are you trying to protect against two process doing the unmap?
> > > 
> > 
> > Yes.
> 
> I don't think you have to worry about the locking here. With the current
> interface, the regions cannot be modified after the guest has booted. So the
> addresses will always stay valid.
> 
> This code path should never be called concurrently, as a lot of code in
> libxl, so I think someone else will take care about that for you (I will let
> Wei confirm here).

I think you mean "can be called concurrently but locking is taken care
of".

If two processes / threads with different libxl ctx (not just xl. xl has
a global lock) try to manipulate the same domain, libxl APIs use file
locks. For the same same process, multiple threads but sharing one
libxl_ctx there is pthread mutex in libxl_ctx.

In a way, "someone else" (in libxl code) has already taken care of the
locking.

Fundamentally We need to assume the code can be called concurrently. It
would be good thing if this is taken into consideration if new code is
added.

Wei.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] 回复: Re: 回复: [PATCH] x86/spec_ctrl: Fix several bugs in SPEC_CTRL_ENTRY_FROM_INTR_IST

[Andrew Cooper]

On 14/02/18 13:04, zhenzhong.duan wrote:
>
> 2018年2月14日 20:21于 Andrew Cooper  >写道：
> >
> > On 14/02/18 12:08, zhenzhong.duan wrote:
> > >
> > > > @@ -286,13 +286,13 @@
> > > >  setz %dl
> > > >  and %dl, STACK_CPUINFO_FIELD(use_shadow_spec_ctrl)(%r14)
> > > Is it safe to remove the 'xor %edx, %edx' above? setz set whole
> byte 1
> > > or 0.
> > >
> >
> > It is safe, but it is not a good idea.
> >
> > Using setz is an 8bit operation, which will suffer a register merge
> > stall in the pipeline as we know for certain at this point that the
> > upper bits of %edx are nonzero at this point.  (An encoding which
> > allowed setz %eax would have been far more useful in 64bit code.)
> >
> Thanks for explain. But just curious does processor has ideas the
> whole register is zeroed and avoid a merge?
>

Yes.  See the Zeroing Idioms section in the optimisation manual. 
Tracking which registers are zero helps breaks read-after-write data
dependences in the pipeline.

~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v4 4/7] libxl: support mapping static shared memory areas during domain creation

[Wei Liu]

On Mon, Feb 12, 2018 at 11:08:01PM +0800, Zhongze Liu wrote:
> >> > [...]
> >> >
> >> > > > +
> >> > > > +/*   libxl__sshm_do_map -- map pages into slave's physmap
> >> > > > + *
> >> > > > + *   This functions maps
> >> > > > + * master gfn: [@msshm->begin + @sshm->offset, @msshm->end +
> >> > > > @sshm->offset)
> >> > > > + *   into
> >> > > > + * slave gfn: [@sshm->begin, @sshm->end)
> >> > > > + *
> >> > > > + *   The gfns of the pages that are successfully mapped will be 
> >> > > > stored
> >> > > > + *   in @mapped, and the number of the gfns will be stored in 
> >> > > > @nmapped.
> >> > > > + *
> >> > > > + *   The caller have to guarentee that sshm->begin < sshm->end and 
> >> > > > all
> >> > > > the
> >> > >
> >> > >
> >> > > s/have to/has to/ I think.
> >> > > s/guarentee/guarantee/
> >> > >
> >> > > > + *   values are page-aligned.
> >> > >
> >> > >
> >> > > Hmmm, I don't see the alignement check in libxl. So do you rely on the
> >> > > toolstack to do it?
> >> >
> >> > Yes, This was done in libxlu_sshm.c.
> >>
> >> Same remark as above regarding libxlu. Note that I am maintaining the 
> >> tools.
> >> Ian and Wei may have a different opinion here.
> >>
> >
> > Please move the check to libxl.
> 
> I agree that we should move the alignment check to libxl.
> 
> But I still think that re-specification checks could only be done in
> libxlu, because
> this could only be spotted in the parsing phase -- it shouldn't be
> libxl's job. For
> libxl, an *_UNKNOWN values just indicates that the user of libxl
> didn't explicitly
> assign a value to the option upon calling the constructor of the sshm struct,
> and the code in libxl will set the option to its default value.
> However, I do think
> I failed to  handle the possibilities where an option value is not
> not *_UNKNOWN and
> not any valid values, which might occur if the user of libxl didn't
> use the constructor
> to initialize the sshm struct.

So there are two problems under discussion. One is parsing, which should
be done in the parser library (libxlu); the other is checking the
validity of the value in the struct, which should be done in libxl. I
don't think we fundamentally disagree with each other. Sorry for my
terse reply earlier.

Wei.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v2] xen/arm: Park CPUs with a MIDR different from the boot CPU.

[Julien Grall]

Xen does not properly support big.LITTLE platform. All vCPUs of a guest
will always have the MIDR of the boot CPU (see arch_domain_create).
At best the guest may see unreliable performance (vCPU switching between
big and LITTLE), at worst the guest will become unreliable or insecure.

This is becoming more apparent with branch predictor hardening in Linux
because they target a specific kind of CPUs and may not work on other
CPUs.

For the time being, park any CPUs with a MDIR different from the boot
CPU. This will be revisited in the future once Xen gains understanding
of big.LITTLE.

[1] https://lists.xenproject.org/archives/html/xen-devel/2016-12/msg00826.html

Signed-off-by: Julien Grall 

---

We probably want to backport this as part of XSA-254. Using big.LITTLE
on Xen has never been supported but we didn't make it clearly. This is
becoming more apparent with code targeting specific CPUs.

Changes in v2:
- Add a command line option to override the default behavior.
---
 docs/misc/xen-command-line.markdown | 10 ++
 xen/arch/arm/smpboot.c  | 26 ++
 2 files changed, 36 insertions(+)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 79feba6bcd..cf5997b8db 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1000,6 +1000,16 @@ supported only when compiled with XSM on x86.
 
 Control Xens use of the APEI Hardware Error Source Table, should one be found.
 
+### hmp_unsafe (arm)
+> `= `
+
+> Default : `false`
+
+Say yes at your own risk if you want to enable heterogenous computing
+(such as big.LITTLE). This may result to an unstable and insecure
+platform. When the option is disabled (default), CPUs that are not
+identical to the boot CPU will be parked and not used by Xen.
+
 ### hpetbroadcast
 > `= `
 
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index 1255185a9c..5c05cadb0a 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -69,6 +70,13 @@ DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_sibling_mask);
 /* representing HT and core siblings of each logical CPU */
 DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_core_mask);
 
+/*
+ * By default non-boot CPUs not identical to the boot CPU will be
+ * parked.
+ */
+static bool __read_mostly opt_hmp_unsafe = false;
+boolean_param("hmp_unsafe", opt_hmp_unsafe);
+
 static void setup_cpu_sibling_map(int cpu)
 {
 if ( !zalloc_cpumask_var(&per_cpu(cpu_sibling_mask, cpu)) ||
@@ -255,6 +263,9 @@ void __init smp_init_cpus(void)
 else
 acpi_smp_init_cpus();
 
+if ( opt_hmp_unsafe )
+warning_add("WARNING: HMP COMPUTING HAS BEEN ENABLED.\n"
+"It has implications on the security and stability of the 
system.\n");
 }
 
 int __init
@@ -292,6 +303,21 @@ void start_secondary(unsigned long boot_phys_offset,
 
 init_traps();
 
+/*
+ * Currently Xen assumes the platform has only one kind of CPUs.
+ * This assumption does not hold on big.LITTLE platform and may
+ * result to instability and insecure platform. Better to park them
+ * for now.
+ */
+if ( !opt_hmp_unsafe &&
+ current_cpu_data.midr.bits != boot_cpu_data.midr.bits )
+{
+printk(XENLOG_ERR "CPU%u MIDR (0x%x) does not match boot CPU MIDR 
(0x%x).\n",
+   smp_processor_id(), current_cpu_data.midr.bits,
+   boot_cpu_data.midr.bits);
+stop_cpu();
+}
+
 mmu_init_secondary_cpu();
 
 gic_init_secondary_cpu();
-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2 1/2] pvcalls-front: introduce a per sock_mapping refcount

[Juergen Gross]

On 13/02/18 03:13, Stefano Stabellini wrote:
> Introduce a per sock_mapping refcount, in addition to the existing
> global refcount. Thanks to the sock_mapping refcount, we can safely wait
> for it to be 1 in pvcalls_front_release before freeing an active socket,
> instead of waiting for the global refcount to be 1.
> 
> Signed-off-by: Stefano Stabellini 
> 
> ---
> Changes in v2:
> - fix code style
> - nicer checks in pvcalls_front_release
> - fix check in pvcalls_enter_sock
> ---
>  drivers/xen/pvcalls-front.c | 193 
> +++-
>  1 file changed, 81 insertions(+), 112 deletions(-)
> 
> diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c
> index 4c789e6..163bf8c 100644
> --- a/drivers/xen/pvcalls-front.c
> +++ b/drivers/xen/pvcalls-front.c
> @@ -60,6 +60,7 @@ struct sock_mapping {
>   bool active_socket;
>   struct list_head list;
>   struct socket *sock;
> + atomic_t refcount;
>   union {
>   struct {
>   int irq;
> @@ -93,6 +94,34 @@ struct sock_mapping {
>   };
>  };
>  
> +static inline struct sock_mapping *pvcalls_enter_sock(struct socket *sock)
> +{
> + struct sock_mapping *map = NULL;

Pointless initializer.

> +
> + if (!pvcalls_front_dev ||
> + dev_get_drvdata(&pvcalls_front_dev->dev) == NULL)
> + return ERR_PTR(-ENOTCONN);
> +
> + pvcalls_enter();
> + map = (struct sock_mapping *)sock->sk->sk_send_head;
> + if (map == NULL) {
> + pvcalls_exit()
> + return ERR_PTR(-ENOTSOCK);
> + }

Sorry for noticing this only now: any reason you don't call
pvcalls_enter() only here instead? This would remove the need of
calling pvcalls_exit() if map == NULL.

I can't see pvcalls_enter() protecting sock->sk->sk_send_head in any
way.

> +
> + atomic_inc(&map->refcount);
> + return map;
> +}
> +
> +static inline void pvcalls_exit_sock(struct socket *sock)
> +{
> + struct sock_mapping *map = NULL;

Pointless initializer again.


Juergen

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH] x86/entry: Use 32bit xors rater than 64bit xors for clearing GPRs

[Andrew Cooper]

Intel's Silvermont/Knights Landing architecture treats them as full ALU
operations, rather than zeroing idoms.

No functional change, and no change in code volume (only changing the bit
selection in the REX prefix).

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 

If anyone is interested, <20180211104949.12992-5-li...@dominikbrodowski.net>
is the LKML discusson on the subject.  It is most likely that this is a
deliberate simplification in the Knights* architecture because compilers
follow optimisation instructions of "use xors for zeroing" and "use 32bit
operations in preference to 64bit ones wherever possible".
---
 xen/include/asm-x86/asm_defns.h | 32 
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/xen/include/asm-x86/asm_defns.h b/xen/include/asm-x86/asm_defns.h
index aee14ba..6fc13d3 100644
--- a/xen/include/asm-x86/asm_defns.h
+++ b/xen/include/asm-x86/asm_defns.h
@@ -269,10 +269,10 @@ static always_inline void stac(void)
 movq  %r10,UREGS_r10(%rsp)
 movq  %r11,UREGS_r11(%rsp)
 .endif
-xor   %r8, %r8
-xor   %r9, %r9
-xor   %r10, %r10
-xor   %r11, %r11
+xor   %r8d, %r8d
+xor   %r9d, %r9d
+xor   %r10d, %r10d
+xor   %r11d, %r11d
 movq  %rbx,UREGS_rbx(%rsp)
 xor   %ebx, %ebx
 movq  %rbp,UREGS_rbp(%rsp)
@@ -289,10 +289,10 @@ static always_inline void stac(void)
 movq  %r14,UREGS_r14(%rsp)
 movq  %r15,UREGS_r15(%rsp)
 .endif
-xor   %r12, %r12
-xor   %r13, %r13
-xor   %r14, %r14
-xor   %r15, %r15
+xor   %r12d, %r12d
+xor   %r13d, %r13d
+xor   %r14d, %r14d
+xor   %r15d, %r15d
 .endm
 
 #define LOAD_ONE_REG(reg, compat) \
@@ -317,10 +317,10 @@ static always_inline void stac(void)
 movq  UREGS_r13(%rsp), %r13
 movq  UREGS_r12(%rsp), %r12
 .else
-xor %r15, %r15
-xor %r14, %r14
-xor %r13, %r13
-xor %r12, %r12
+xor %r15d, %r15d
+xor %r14d, %r14d
+xor %r13d, %r13d
+xor %r12d, %r12d
 .endif
 LOAD_ONE_REG(bp, \compat)
 LOAD_ONE_REG(bx, \compat)
@@ -330,10 +330,10 @@ static always_inline void stac(void)
 movq  UREGS_r9(%rsp),%r9
 movq  UREGS_r8(%rsp),%r8
 .else
-xor %r11, %r11
-xor %r10, %r10
-xor %r9, %r9
-xor %r8, %r8
+xor %r11d, %r11d
+xor %r10d, %r10d
+xor %r9d, %r9d
+xor %r8d, %r8d
 .endif
 LOAD_ONE_REG(ax, \compat)
 LOAD_ONE_REG(cx, \compat)
-- 
2.1.4


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] 回复: Re: 回复: [PATCH] x86/spec_ctrl: Fix several bugs in SPEC_CTRL_ENTRY_FROM_INTR_IST

[zhenzhong.duan]

2018年2月14日 20:21于 Andrew Cooper 写道：
>
> On 14/02/18 12:08, zhenzhong.duan wrote: 
> > 
> > > @@ -286,13 +286,13 @@ 
> > >  setz %dl 
> > >  and %dl, STACK_CPUINFO_FIELD(use_shadow_spec_ctrl)(%r14) 
> > Is it safe to remove the 'xor %edx, %edx' above? setz set whole byte 1 
> > or 0. 
> > 
>
> It is safe, but it is not a good idea. 
>
> Using setz is an 8bit operation, which will suffer a register merge 
> stall in the pipeline as we know for certain at this point that the 
> upper bits of %edx are nonzero at this point.  (An encoding which 
> allowed setz %eax would have been far more useful in 64bit code.) 
>
Thanks for explain. But just curious does processor has ideas the whole 
register is zeroed and avoid a merge?

thanks
zduan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] x86/xpti: Hide almost all of .text and all .data/.rodata/.bss mappings

[Jan Beulich]

>>> On 14.02.18 at 13:34,  wrote:
> On 14/02/18 09:14, Jan Beulich wrote:
> On 13.02.18 at 20:45,  wrote:
>>> @@ -651,9 +654,6 @@ static int clone_mapping(const void *ptr, 
>>> root_pgentry_t *rpt)
>>>  l2_pgentry_t *pl2e;
>>>  l1_pgentry_t *pl1e;
>>>  
>>> -if ( linear < DIRECTMAP_VIRT_START )
>>> -return 0;
>> Isn't outright removing this going a little too far?
> 
> Considering it is buggy, no.  Retuning success after doing nothing is
> very antisocial.
> 
> If anything, it should return -EINVAL so the caller knows that something
> expected happened, but it should also reject attempts to clone mappings
> beyond the end of the directmap (as those will explode when we switch to
> PV context), and the XEN_VIRT_* range needs white-listing as ok to clone
> for this usecase to work.

Returning -EINVAL would have been wrong without excluding the
XEN_VIRT_* range - the boot CPU has at least its IDT there.
Tightening the check would be fine with me.

>>> --- a/xen/arch/x86/x86_64/compat/entry.S
>>> +++ b/xen/arch/x86/x86_64/compat/entry.S
>>> @@ -13,6 +13,8 @@
>>>  #include 
>>>  #include 
>>>  
>>> +.section .text.entry, "ax", @progbits
>>> +
>>>  ENTRY(entry_int82)
>>>  ASM_CLAC
>>>  pushq $0
>> This also puts compat_create_bounce_frame into the entry section,
>> which surely isn't needed. Same for the non-compat variant.
> 
> I considered that.  Excluding those ranges won't reduce the number of
> allocations we make, but it does complicate backports.

Complicate backports? The context of the section directive may
change some, but that's not a significant complication imo.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2 13/16] Save/Restore Support: Add suspend/restore support for Grant Tables.

[Juergen Gross]

On 14/02/18 03:27, Bruno Alvisio wrote:
> Signed-off-by: Bruno Alvisio 
> ---
> Changed since v1:
> - Moved suspend/resume _gnttab to arch specific files
> ---
>  arch/x86/mm.c| 34 ++
>  gnttab.c | 10 ++
>  include/gnttab.h |  4 
>  kernel.c |  4 
>  4 files changed, 52 insertions(+)
> 
> diff --git a/arch/x86/mm.c b/arch/x86/mm.c
> index 1b163ac..2597c5b 100644
> --- a/arch/x86/mm.c
> +++ b/arch/x86/mm.c
> @@ -917,6 +917,40 @@ grant_entry_v1_t *arch_init_gnttab(int nr_grant_frames)
>  return map_frames(frames, nr_grant_frames);
>  }
>  
> +void arch_suspend_gnttab(grant_entry_v1_t *gnttab_table, int nr_grant_frames)
> +{
> +#ifdef CONFIG_PARAVIRT
> +int i;
> +
> +for (i = 0; i < nr_grant_frames; i++) {
> +HYPERVISOR_update_va_mapping((unsigned long)(((char *)gnttab_table) 
> + PAGE_SIZE*i),
> +(pte_t){0x0<


Juergen

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] x86/xpti: Hide almost all of .text and all .data/.rodata/.bss mappings

[Andrew Cooper]

On 14/02/18 12:27, Juergen Gross wrote:
> On 14/02/18 13:19, Andrew Cooper wrote:
>> On 14/02/18 12:15, Juergen Gross wrote:
>>> On 14/02/18 13:03, Juergen Gross wrote:
 On 14/02/18 12:48, Andrew Cooper wrote:
> On 14/02/18 07:54, Juergen Gross wrote:
>> On 13/02/18 20:45, Andrew Cooper wrote:
>>> The current XPTI implementation isolates the directmap (and therefore a 
>>> lot of
>>> guest data), but a large quantity of CPU0's state (including its stack)
>>> remains visible.
>>>
>>> Furthermore, an attacker able to read .text is in a vastly superior 
>>> position
>>> to normal when it comes to fingerprinting Xen for known 
>>> vulnerabilities, or
>>> scanning for ROP/Spectre gadgets.
>>>
>>> Collect together the entrypoints in .text.entry (currently 3x4k frames, 
>>> but
>>> can almost certainly be slimmed down), and create a common mapping 
>>> which is
>>> inserted into each per-cpu shadow.  The stubs are also inserted into 
>>> this
>>> mapping by pointing at the in-use L2.  This allows stubs allocated 
>>> later (SMP
>>> boot, or CPU hotplug) to work without further changes to the common 
>>> mappings.
>>>
>>> Signed-off-by: Andrew Cooper 
>>> ---
>>> CC: Jan Beulich 
>>> CC: Wei Liu 
>>> CC: Juergen Gross 
>>>
>>> RFC, because I don't think the stubs handling is particularly sensible.
>>>
>>> We allocate 4k of virtual address space per CPU, but squash loads of 
>>> CPUs
>>> together onto a single MFN.  The stubs ought to be isolated as well (as 
>>> they
>>> leak the virtual addresses of each stack), which can be done by 
>>> allocating an
>>> MFN per CPU (and simplifies cpu_smpboot_alloc() somewhat).  At this 
>>> point, we
>>> can't use a common set of mappings, and will have to clone the single 
>>> stub and
>>> .entry.text into each PCPUs copy of the pagetables.
>>>
>>> Also, my plan to cause .text.entry to straddle a 512TB boundary (and 
>>> therefore
>>> avoid any further pagetable allocations) has come a little unstuck 
>>> because of
>>> CONFIG_BIGMEM.  I'm still working out whether there is a sensible way to
>>> rearrange the virtual layout for this plan to work.
>>> ---
>>>  xen/arch/x86/smpboot.c | 37 
>>> -
>>>  xen/arch/x86/x86_64/compat/entry.S |  2 ++
>>>  xen/arch/x86/x86_64/entry.S|  4 +++-
>>>  xen/arch/x86/xen.lds.S |  7 +++
>>>  4 files changed, 44 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
>>> index 2ebef03..2519141 100644
>>> --- a/xen/arch/x86/smpboot.c
>>> +++ b/xen/arch/x86/smpboot.c
>>> @@ -622,6 +622,9 @@ unsigned long alloc_stub_page(unsigned int cpu, 
>>> unsigned long *mfn)
>>>  unmap_domain_page(memset(__map_domain_page(pg), 0xcc, 
>>> PAGE_SIZE));
>>>  }
>>>  
>>> +/* Confirm that all stubs fit in a single L2 pagetable. */
>>> +BUILD_BUG_ON(NR_CPUS * PAGE_SIZE > (1u << L2_PAGETABLE_SHIFT));
>> So we limit NR_CPUS to be max 512 now?
> Not intentionally.  The PAGE_SIZE should be dropped.  (One full L2
> pagetable allows us to map 512*512 pages).
 L2_PAGETABLE_SHIFT is 21. So I still don't get why dropping PAGE_SIZE
 will correct it. OTOH I'm quite sure the BUILD_BUG_ON() won't trigger
 any more with PAGE_SIZE being dropped. :-)

>> Maybe you should use STUB_BUF_SIZE instead of PAGE_SIZE?
> No - that would be incorrect because of the physical packing of stubs
> which occurs.
>
>> BTW: Is there any reason we don't use a common stub page mapped to each
>> per-cpu stack area? The stack address can easily be obtained via %rip
>> relative addressing then (see my patch for the per-vcpu stacks:
>> https://lists.xen.org/archives/html/xen-devel/2018-02/msg00773.html )
> I don't understand what you are asking here.  We cannot access the
> per-cpu area with plain rip-retaliative addressing without using gs base
> (and we really don't want to go down that route), or without per-cpu
> pagetables (which would have to be a compile time choice).
 The stub-page of a cpu is currently mapped as the 3rd page of the
 stack area. So the distance to the primary stack would be the same
 for all cpus (a little bit less than 20kB).

> As for why the per-cpu areas aren't mapped, that's because they aren't
> needed at the moment.  Any decision to change this needs to weigh the
> utility of mapping the areas vs the additional data leakage, which is
> substantial.
 The stack area is mapped. And that's where the stub is living.
>>> Oh, did I mix up something? I followed the comments in current.h. The
>>> code suggests the syscall trampoline page isn't used at the moment

Re: [Xen-devel] [PATCH] x86/xpti: Hide almost all of .text and all .data/.rodata/.bss mappings

[Andrew Cooper]

On 14/02/18 09:14, Jan Beulich wrote:
 On 13.02.18 at 20:45,  wrote:
>> RFC, because I don't think the stubs handling is particularly sensible.
>>
>> We allocate 4k of virtual address space per CPU, but squash loads of CPUs
>> together onto a single MFN.  The stubs ought to be isolated as well (as they
>> leak the virtual addresses of each stack), which can be done by allocating an
>> MFN per CPU (and simplifies cpu_smpboot_alloc() somewhat).  At this point, we
>> can't use a common set of mappings, and will have to clone the single stub 
>> and
>> .entry.text into each PCPUs copy of the pagetables.
> The 4k-per-CPU allocation of VA space is probably not strictly
> necessary - quoting the original commit message:
> "While sharing physical pages among certain CPUs on the same node, for
>  now the virtual mappings get established in distinct pages for each
>  CPU. This isn't a strict requirement, but simplifies VA space
>  management for this initial implementation: Sharing VA space would
>  require additional tracking of which areas are currently in use. If
>  the VA and/or TLB overhead turned out to be a problem, such extra code
>  could easily be added."
>
> Without allocating a page per CPU I think what you do is sensible.
> And I don't see how hiding stubs of other CPUs would help much -
> an attacker can gather stack locations from various CPUs as its
> vCPU is being moved around, and you can't hide the current CPU's
> stub space.

Well - scenarios with pinning or cpupools would have a restricted access
to other cpu stack locations.

If the stubs were split in half, we could at least separate the syscall
stubs from the emulation stubs, and leave the latter unmapped.

>
>> --- a/xen/arch/x86/smpboot.c
>> +++ b/xen/arch/x86/smpboot.c
>> @@ -622,6 +622,9 @@ unsigned long alloc_stub_page(unsigned int cpu, unsigned 
>> long *mfn)
>>  unmap_domain_page(memset(__map_domain_page(pg), 0xcc, PAGE_SIZE));
>>  }
>>  
>> +/* Confirm that all stubs fit in a single L2 pagetable. */
>> +BUILD_BUG_ON(NR_CPUS * PAGE_SIZE > (1u << L2_PAGETABLE_SHIFT));
> Perhaps duplicate this in setup_cpu_root_pgt() (suitably adjusted
> of course, as Jürgen has already pointed out)?
>
>> @@ -651,9 +654,6 @@ static int clone_mapping(const void *ptr, root_pgentry_t 
>> *rpt)
>>  l2_pgentry_t *pl2e;
>>  l1_pgentry_t *pl1e;
>>  
>> -if ( linear < DIRECTMAP_VIRT_START )
>> -return 0;
> Isn't outright removing this going a little too far?

Considering it is buggy, no.  Retuning success after doing nothing is
very antisocial.

If anything, it should return -EINVAL so the caller knows that something
expected happened, but it should also reject attempts to clone mappings
beyond the end of the directmap (as those will explode when we switch to
PV context), and the XEN_VIRT_* range needs white-listing as ok to clone
for this usecase to work.

>> --- a/xen/arch/x86/x86_64/compat/entry.S
>> +++ b/xen/arch/x86/x86_64/compat/entry.S
>> @@ -13,6 +13,8 @@
>>  #include 
>>  #include 
>>  
>> +.section .text.entry, "ax", @progbits
>> +
>>  ENTRY(entry_int82)
>>  ASM_CLAC
>>  pushq $0
> This also puts compat_create_bounce_frame into the entry section,
> which surely isn't needed. Same for the non-compat variant.

I considered that.  Excluding those ranges won't reduce the number of
allocations we make, but it does complicate backports.

Also, I still fully intend to make the functions disappear into C and
move out of .text.entry that way.

>
>> @@ -854,7 +856,7 @@ GLOBAL(autogen_entrypoints)
>>  .popsection
>>  .endm
>>  
>> -.text
>> +.previous
>>  autogen_stubs: /* Automatically generated stubs. */
> Perhaps better to switch the earlier .section to .pushsection, and
> use .popsection here?

Will do.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] x86/xpti: Hide almost all of .text and all .data/.rodata/.bss mappings

[Juergen Gross]

On 14/02/18 13:19, Andrew Cooper wrote:
> On 14/02/18 12:15, Juergen Gross wrote:
>> On 14/02/18 13:03, Juergen Gross wrote:
>>> On 14/02/18 12:48, Andrew Cooper wrote:
 On 14/02/18 07:54, Juergen Gross wrote:
> On 13/02/18 20:45, Andrew Cooper wrote:
>> The current XPTI implementation isolates the directmap (and therefore a 
>> lot of
>> guest data), but a large quantity of CPU0's state (including its stack)
>> remains visible.
>>
>> Furthermore, an attacker able to read .text is in a vastly superior 
>> position
>> to normal when it comes to fingerprinting Xen for known vulnerabilities, 
>> or
>> scanning for ROP/Spectre gadgets.
>>
>> Collect together the entrypoints in .text.entry (currently 3x4k frames, 
>> but
>> can almost certainly be slimmed down), and create a common mapping which 
>> is
>> inserted into each per-cpu shadow.  The stubs are also inserted into this
>> mapping by pointing at the in-use L2.  This allows stubs allocated later 
>> (SMP
>> boot, or CPU hotplug) to work without further changes to the common 
>> mappings.
>>
>> Signed-off-by: Andrew Cooper 
>> ---
>> CC: Jan Beulich 
>> CC: Wei Liu 
>> CC: Juergen Gross 
>>
>> RFC, because I don't think the stubs handling is particularly sensible.
>>
>> We allocate 4k of virtual address space per CPU, but squash loads of CPUs
>> together onto a single MFN.  The stubs ought to be isolated as well (as 
>> they
>> leak the virtual addresses of each stack), which can be done by 
>> allocating an
>> MFN per CPU (and simplifies cpu_smpboot_alloc() somewhat).  At this 
>> point, we
>> can't use a common set of mappings, and will have to clone the single 
>> stub and
>> .entry.text into each PCPUs copy of the pagetables.
>>
>> Also, my plan to cause .text.entry to straddle a 512TB boundary (and 
>> therefore
>> avoid any further pagetable allocations) has come a little unstuck 
>> because of
>> CONFIG_BIGMEM.  I'm still working out whether there is a sensible way to
>> rearrange the virtual layout for this plan to work.
>> ---
>>  xen/arch/x86/smpboot.c | 37 
>> -
>>  xen/arch/x86/x86_64/compat/entry.S |  2 ++
>>  xen/arch/x86/x86_64/entry.S|  4 +++-
>>  xen/arch/x86/xen.lds.S |  7 +++
>>  4 files changed, 44 insertions(+), 6 deletions(-)
>>
>> diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
>> index 2ebef03..2519141 100644
>> --- a/xen/arch/x86/smpboot.c
>> +++ b/xen/arch/x86/smpboot.c
>> @@ -622,6 +622,9 @@ unsigned long alloc_stub_page(unsigned int cpu, 
>> unsigned long *mfn)
>>  unmap_domain_page(memset(__map_domain_page(pg), 0xcc, 
>> PAGE_SIZE));
>>  }
>>  
>> +/* Confirm that all stubs fit in a single L2 pagetable. */
>> +BUILD_BUG_ON(NR_CPUS * PAGE_SIZE > (1u << L2_PAGETABLE_SHIFT));
> So we limit NR_CPUS to be max 512 now?
 Not intentionally.  The PAGE_SIZE should be dropped.  (One full L2
 pagetable allows us to map 512*512 pages).
>>> L2_PAGETABLE_SHIFT is 21. So I still don't get why dropping PAGE_SIZE
>>> will correct it. OTOH I'm quite sure the BUILD_BUG_ON() won't trigger
>>> any more with PAGE_SIZE being dropped. :-)
>>>
> Maybe you should use STUB_BUF_SIZE instead of PAGE_SIZE?
 No - that would be incorrect because of the physical packing of stubs
 which occurs.

> BTW: Is there any reason we don't use a common stub page mapped to each
> per-cpu stack area? The stack address can easily be obtained via %rip
> relative addressing then (see my patch for the per-vcpu stacks:
> https://lists.xen.org/archives/html/xen-devel/2018-02/msg00773.html )
 I don't understand what you are asking here.  We cannot access the
 per-cpu area with plain rip-retaliative addressing without using gs base
 (and we really don't want to go down that route), or without per-cpu
 pagetables (which would have to be a compile time choice).
>>> The stub-page of a cpu is currently mapped as the 3rd page of the
>>> stack area. So the distance to the primary stack would be the same
>>> for all cpus (a little bit less than 20kB).
>>>
 As for why the per-cpu areas aren't mapped, that's because they aren't
 needed at the moment.  Any decision to change this needs to weigh the
 utility of mapping the areas vs the additional data leakage, which is
 substantial.
>>> The stack area is mapped. And that's where the stub is living.
>> Oh, did I mix up something? I followed the comments in current.h. The
>> code suggests the syscall trampoline page isn't used at the moment for
>> the stubs...
> 
> That will be stale from the work Jan did to make the stack fully NX. 
> The syscall stubs used to be on the stack, but are no longer.

[Xen-devel] [PATCH] xen/arm: cpuerrata: Actually check errata on non-boot CPUs

[Julien Grall]

The cpu errata framework was introduced in commit 8b01f6364f "xen/arm:
Detect silicon revision and set cap bits accordingly" and was meant to
detect errata present on any CPUs (via check_local_cpu_errata). However,
the function to check the MIDR (is_affected_midr_range) mistakenly
always use the boot CPU MIDR.

Fix is_affected_midr_range to use the current CPU MIDR.

Reported-by: Stefano Stabellini 
Signed-off-by: Julien Grall 

---
This should be backported up to Xen 4.7 as the cpu errata framework
was backported for XSA-254.
---
 xen/arch/arm/cpuerrata.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index 9c7458ef06..c243521ed4 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -230,7 +230,7 @@ static int enable_ic_inv_hardening(void *data)
 static bool __maybe_unused
 is_affected_midr_range(const struct arm_cpu_capabilities *entry)
 {
-return MIDR_IS_CPU_MODEL_RANGE(boot_cpu_data.midr.bits, entry->midr_model,
+return MIDR_IS_CPU_MODEL_RANGE(current_cpu_data.midr.bits, 
entry->midr_model,
entry->midr_range_min,
entry->midr_range_max);
 }
-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] 回复: [PATCH] x86/spec_ctrl: Fix several bugs in SPEC_CTRL_ENTRY_FROM_INTR_IST

[Andrew Cooper]

On 14/02/18 12:08, zhenzhong.duan wrote:
>
> > @@ -286,13 +286,13 @@
> >  setz %dl
> >  and %dl, STACK_CPUINFO_FIELD(use_shadow_spec_ctrl)(%r14)
> Is it safe to remove the 'xor %edx, %edx' above? setz set whole byte 1
> or 0.
>

It is safe, but it is not a good idea.

Using setz is an 8bit operation, which will suffer a register merge
stall in the pipeline as we know for certain at this point that the
upper bits of %edx are nonzero at this point.  (An encoding which
allowed setz %eax would have been far more useful in 64bit code.)

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] x86/xpti: Hide almost all of .text and all .data/.rodata/.bss mappings

[Andrew Cooper]

On 14/02/18 12:15, Juergen Gross wrote:
> On 14/02/18 13:03, Juergen Gross wrote:
>> On 14/02/18 12:48, Andrew Cooper wrote:
>>> On 14/02/18 07:54, Juergen Gross wrote:
 On 13/02/18 20:45, Andrew Cooper wrote:
> The current XPTI implementation isolates the directmap (and therefore a 
> lot of
> guest data), but a large quantity of CPU0's state (including its stack)
> remains visible.
>
> Furthermore, an attacker able to read .text is in a vastly superior 
> position
> to normal when it comes to fingerprinting Xen for known vulnerabilities, 
> or
> scanning for ROP/Spectre gadgets.
>
> Collect together the entrypoints in .text.entry (currently 3x4k frames, 
> but
> can almost certainly be slimmed down), and create a common mapping which 
> is
> inserted into each per-cpu shadow.  The stubs are also inserted into this
> mapping by pointing at the in-use L2.  This allows stubs allocated later 
> (SMP
> boot, or CPU hotplug) to work without further changes to the common 
> mappings.
>
> Signed-off-by: Andrew Cooper 
> ---
> CC: Jan Beulich 
> CC: Wei Liu 
> CC: Juergen Gross 
>
> RFC, because I don't think the stubs handling is particularly sensible.
>
> We allocate 4k of virtual address space per CPU, but squash loads of CPUs
> together onto a single MFN.  The stubs ought to be isolated as well (as 
> they
> leak the virtual addresses of each stack), which can be done by 
> allocating an
> MFN per CPU (and simplifies cpu_smpboot_alloc() somewhat).  At this 
> point, we
> can't use a common set of mappings, and will have to clone the single 
> stub and
> .entry.text into each PCPUs copy of the pagetables.
>
> Also, my plan to cause .text.entry to straddle a 512TB boundary (and 
> therefore
> avoid any further pagetable allocations) has come a little unstuck 
> because of
> CONFIG_BIGMEM.  I'm still working out whether there is a sensible way to
> rearrange the virtual layout for this plan to work.
> ---
>  xen/arch/x86/smpboot.c | 37 
> -
>  xen/arch/x86/x86_64/compat/entry.S |  2 ++
>  xen/arch/x86/x86_64/entry.S|  4 +++-
>  xen/arch/x86/xen.lds.S |  7 +++
>  4 files changed, 44 insertions(+), 6 deletions(-)
>
> diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
> index 2ebef03..2519141 100644
> --- a/xen/arch/x86/smpboot.c
> +++ b/xen/arch/x86/smpboot.c
> @@ -622,6 +622,9 @@ unsigned long alloc_stub_page(unsigned int cpu, 
> unsigned long *mfn)
>  unmap_domain_page(memset(__map_domain_page(pg), 0xcc, 
> PAGE_SIZE));
>  }
>  
> +/* Confirm that all stubs fit in a single L2 pagetable. */
> +BUILD_BUG_ON(NR_CPUS * PAGE_SIZE > (1u << L2_PAGETABLE_SHIFT));
 So we limit NR_CPUS to be max 512 now?
>>> Not intentionally.  The PAGE_SIZE should be dropped.  (One full L2
>>> pagetable allows us to map 512*512 pages).
>> L2_PAGETABLE_SHIFT is 21. So I still don't get why dropping PAGE_SIZE
>> will correct it. OTOH I'm quite sure the BUILD_BUG_ON() won't trigger
>> any more with PAGE_SIZE being dropped. :-)
>>
 Maybe you should use STUB_BUF_SIZE instead of PAGE_SIZE?
>>> No - that would be incorrect because of the physical packing of stubs
>>> which occurs.
>>>
 BTW: Is there any reason we don't use a common stub page mapped to each
 per-cpu stack area? The stack address can easily be obtained via %rip
 relative addressing then (see my patch for the per-vcpu stacks:
 https://lists.xen.org/archives/html/xen-devel/2018-02/msg00773.html )
>>> I don't understand what you are asking here.  We cannot access the
>>> per-cpu area with plain rip-retaliative addressing without using gs base
>>> (and we really don't want to go down that route), or without per-cpu
>>> pagetables (which would have to be a compile time choice).
>> The stub-page of a cpu is currently mapped as the 3rd page of the
>> stack area. So the distance to the primary stack would be the same
>> for all cpus (a little bit less than 20kB).
>>
>>> As for why the per-cpu areas aren't mapped, that's because they aren't
>>> needed at the moment.  Any decision to change this needs to weigh the
>>> utility of mapping the areas vs the additional data leakage, which is
>>> substantial.
>> The stack area is mapped. And that's where the stub is living.
> Oh, did I mix up something? I followed the comments in current.h. The
> code suggests the syscall trampoline page isn't used at the moment for
> the stubs...

That will be stale from the work Jan did to make the stack fully NX. 
The syscall stubs used to be on the stack, but are no longer.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/l

Re: [Xen-devel] [PATCH] x86/xpti: Hide almost all of .text and all .data/.rodata/.bss mappings

[Juergen Gross]

On 14/02/18 13:03, Juergen Gross wrote:
> On 14/02/18 12:48, Andrew Cooper wrote:
>> On 14/02/18 07:54, Juergen Gross wrote:
>>> On 13/02/18 20:45, Andrew Cooper wrote:
 The current XPTI implementation isolates the directmap (and therefore a 
 lot of
 guest data), but a large quantity of CPU0's state (including its stack)
 remains visible.

 Furthermore, an attacker able to read .text is in a vastly superior 
 position
 to normal when it comes to fingerprinting Xen for known vulnerabilities, or
 scanning for ROP/Spectre gadgets.

 Collect together the entrypoints in .text.entry (currently 3x4k frames, but
 can almost certainly be slimmed down), and create a common mapping which is
 inserted into each per-cpu shadow.  The stubs are also inserted into this
 mapping by pointing at the in-use L2.  This allows stubs allocated later 
 (SMP
 boot, or CPU hotplug) to work without further changes to the common 
 mappings.

 Signed-off-by: Andrew Cooper 
 ---
 CC: Jan Beulich 
 CC: Wei Liu 
 CC: Juergen Gross 

 RFC, because I don't think the stubs handling is particularly sensible.

 We allocate 4k of virtual address space per CPU, but squash loads of CPUs
 together onto a single MFN.  The stubs ought to be isolated as well (as 
 they
 leak the virtual addresses of each stack), which can be done by allocating 
 an
 MFN per CPU (and simplifies cpu_smpboot_alloc() somewhat).  At this point, 
 we
 can't use a common set of mappings, and will have to clone the single stub 
 and
 .entry.text into each PCPUs copy of the pagetables.

 Also, my plan to cause .text.entry to straddle a 512TB boundary (and 
 therefore
 avoid any further pagetable allocations) has come a little unstuck because 
 of
 CONFIG_BIGMEM.  I'm still working out whether there is a sensible way to
 rearrange the virtual layout for this plan to work.
 ---
  xen/arch/x86/smpboot.c | 37 
 -
  xen/arch/x86/x86_64/compat/entry.S |  2 ++
  xen/arch/x86/x86_64/entry.S|  4 +++-
  xen/arch/x86/xen.lds.S |  7 +++
  4 files changed, 44 insertions(+), 6 deletions(-)

 diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
 index 2ebef03..2519141 100644
 --- a/xen/arch/x86/smpboot.c
 +++ b/xen/arch/x86/smpboot.c
 @@ -622,6 +622,9 @@ unsigned long alloc_stub_page(unsigned int cpu, 
 unsigned long *mfn)
  unmap_domain_page(memset(__map_domain_page(pg), 0xcc, PAGE_SIZE));
  }
  
 +/* Confirm that all stubs fit in a single L2 pagetable. */
 +BUILD_BUG_ON(NR_CPUS * PAGE_SIZE > (1u << L2_PAGETABLE_SHIFT));
>>> So we limit NR_CPUS to be max 512 now?
>>
>> Not intentionally.  The PAGE_SIZE should be dropped.  (One full L2
>> pagetable allows us to map 512*512 pages).
> 
> L2_PAGETABLE_SHIFT is 21. So I still don't get why dropping PAGE_SIZE
> will correct it. OTOH I'm quite sure the BUILD_BUG_ON() won't trigger
> any more with PAGE_SIZE being dropped. :-)
> 
>>> Maybe you should use STUB_BUF_SIZE instead of PAGE_SIZE?
>>
>> No - that would be incorrect because of the physical packing of stubs
>> which occurs.
>>
>>> BTW: Is there any reason we don't use a common stub page mapped to each
>>> per-cpu stack area? The stack address can easily be obtained via %rip
>>> relative addressing then (see my patch for the per-vcpu stacks:
>>> https://lists.xen.org/archives/html/xen-devel/2018-02/msg00773.html )
>>
>> I don't understand what you are asking here.  We cannot access the
>> per-cpu area with plain rip-retaliative addressing without using gs base
>> (and we really don't want to go down that route), or without per-cpu
>> pagetables (which would have to be a compile time choice).
> 
> The stub-page of a cpu is currently mapped as the 3rd page of the
> stack area. So the distance to the primary stack would be the same
> for all cpus (a little bit less than 20kB).
> 
>> As for why the per-cpu areas aren't mapped, that's because they aren't
>> needed at the moment.  Any decision to change this needs to weigh the
>> utility of mapping the areas vs the additional data leakage, which is
>> substantial.
> 
> The stack area is mapped. And that's where the stub is living.

Oh, did I mix up something? I followed the comments in current.h. The
code suggests the syscall trampoline page isn't used at the moment for
the stubs...


Juergen

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] 回复: [PATCH] x86/spec_ctrl: Fix several bugs in SPEC_CTRL_ENTRY_FROM_INTR_IST

[zhenzhong.duan]

2018年2月14日 19:10于 Andrew Cooper 写道：
>
> DO_OVERWRITE_RSB clobbers %rax, meaning in practice that that the 
> bti_ist_info 
> field gets zeroed.  Older versions of this code had the DO_OVERWRITE_RSB 
> register selectable, so reintroduce this ability and use it to cause the 
> INTR_IST path to use %rdx instead. 
>
> The use of %dl for the %cs.rpl check means that when an IST interrupt hits 
> Xen, we try to load 1 into the high 32 bits of MSR_SPEC_CTRL, suffering a #GP 
> fault instead. 
>
> Also, drop an unused label which was a copy/paste mistake. 
>
> Reported-by: Boris Ostrovsky  
> Reported-by: Zhenzhong Duan  
> Signed-off-by: Andrew Cooper  
> --- 
> CC: Jan Beulich  
> CC: Zhenzhong Duan  
> CC: Boris Ostrovsky  
> CC: Wei Liu  
> CC: Roger Pau Monné  
> --- 
> xen/include/asm-x86/spec_ctrl_asm.h | 12 ++-- 
> 1 file changed, 6 insertions(+), 6 deletions(-) 
>
> diff --git a/xen/include/asm-x86/spec_ctrl_asm.h 
> b/xen/include/asm-x86/spec_ctrl_asm.h 
> index 814f53d..1f78599 100644 
> --- a/xen/include/asm-x86/spec_ctrl_asm.h 
> +++ b/xen/include/asm-x86/spec_ctrl_asm.h 
> @@ -79,10 +79,10 @@ 
>   *  - SPEC_CTRL_EXIT_TO_GUEST 
>   */ 
>
> -.macro DO_OVERWRITE_RSB 
> +.macro DO_OVERWRITE_RSB tmp=%rax 
> /* 
>   * Requires nothing 
> - * Clobbers %rax, %rcx 
> + * Clobbers \tmp (%rax by default), %rcx 
>   * 
>   * Requires 256 bytes of stack space, but %rsp has no net change. Based on 
>   * Google's performance numbers, the loop is unrolled to 16 iterations and 
> two 
> @@ -97,7 +97,7 @@ 
>   * optimised with mov-elimination in modern cores. 
>   */ 
>  mov $16, %ecx   /* 16 iterations, two calls per loop */ 
> -    mov %rsp, %rax  /* Store the current %rsp */ 
> +    mov %rsp, \tmp  /* Store the current %rsp */ 
>
> .L\@_fill_rsb_loop: 
>
> @@ -114,7 +114,7 @@ 
>
>  sub $1, %ecx 
>  jnz .L\@_fill_rsb_loop 
> -    mov %rax, %rsp  /* Restore old %rsp */ 
> +    mov \tmp, %rsp  /* Restore old %rsp */ 
> .endm 
>
> .macro DO_SPEC_CTRL_ENTRY_FROM_VMEXIT ibrs_val:req 
> @@ -274,7 +274,7 @@ 
>  testb $BTI_IST_RSB, %al 
>  jz .L\@_skip_rsb 
>
> -    DO_OVERWRITE_RSB 
> +    DO_OVERWRITE_RSB tmp=%rdx /* Clobbers %ecx/%rdx */ 
>
> .L\@_skip_rsb: 
>
> @@ -286,13 +286,13 @@ 
>  setz %dl 
>  and %dl, STACK_CPUINFO_FIELD(use_shadow_spec_ctrl)(%r14) 
Is it safe to remove the 'xor %edx, %edx' above? setz set whole byte 1 or 0.
---
thanks
zduan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] x86/xpti: Hide almost all of .text and all .data/.rodata/.bss mappings

[Juergen Gross]

On 14/02/18 12:48, Andrew Cooper wrote:
> On 14/02/18 07:54, Juergen Gross wrote:
>> On 13/02/18 20:45, Andrew Cooper wrote:
>>> The current XPTI implementation isolates the directmap (and therefore a lot 
>>> of
>>> guest data), but a large quantity of CPU0's state (including its stack)
>>> remains visible.
>>>
>>> Furthermore, an attacker able to read .text is in a vastly superior position
>>> to normal when it comes to fingerprinting Xen for known vulnerabilities, or
>>> scanning for ROP/Spectre gadgets.
>>>
>>> Collect together the entrypoints in .text.entry (currently 3x4k frames, but
>>> can almost certainly be slimmed down), and create a common mapping which is
>>> inserted into each per-cpu shadow.  The stubs are also inserted into this
>>> mapping by pointing at the in-use L2.  This allows stubs allocated later 
>>> (SMP
>>> boot, or CPU hotplug) to work without further changes to the common 
>>> mappings.
>>>
>>> Signed-off-by: Andrew Cooper 
>>> ---
>>> CC: Jan Beulich 
>>> CC: Wei Liu 
>>> CC: Juergen Gross 
>>>
>>> RFC, because I don't think the stubs handling is particularly sensible.
>>>
>>> We allocate 4k of virtual address space per CPU, but squash loads of CPUs
>>> together onto a single MFN.  The stubs ought to be isolated as well (as they
>>> leak the virtual addresses of each stack), which can be done by allocating 
>>> an
>>> MFN per CPU (and simplifies cpu_smpboot_alloc() somewhat).  At this point, 
>>> we
>>> can't use a common set of mappings, and will have to clone the single stub 
>>> and
>>> .entry.text into each PCPUs copy of the pagetables.
>>>
>>> Also, my plan to cause .text.entry to straddle a 512TB boundary (and 
>>> therefore
>>> avoid any further pagetable allocations) has come a little unstuck because 
>>> of
>>> CONFIG_BIGMEM.  I'm still working out whether there is a sensible way to
>>> rearrange the virtual layout for this plan to work.
>>> ---
>>>  xen/arch/x86/smpboot.c | 37 
>>> -
>>>  xen/arch/x86/x86_64/compat/entry.S |  2 ++
>>>  xen/arch/x86/x86_64/entry.S|  4 +++-
>>>  xen/arch/x86/xen.lds.S |  7 +++
>>>  4 files changed, 44 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
>>> index 2ebef03..2519141 100644
>>> --- a/xen/arch/x86/smpboot.c
>>> +++ b/xen/arch/x86/smpboot.c
>>> @@ -622,6 +622,9 @@ unsigned long alloc_stub_page(unsigned int cpu, 
>>> unsigned long *mfn)
>>>  unmap_domain_page(memset(__map_domain_page(pg), 0xcc, PAGE_SIZE));
>>>  }
>>>  
>>> +/* Confirm that all stubs fit in a single L2 pagetable. */
>>> +BUILD_BUG_ON(NR_CPUS * PAGE_SIZE > (1u << L2_PAGETABLE_SHIFT));
>> So we limit NR_CPUS to be max 512 now?
> 
> Not intentionally.  The PAGE_SIZE should be dropped.  (One full L2
> pagetable allows us to map 512*512 pages).

L2_PAGETABLE_SHIFT is 21. So I still don't get why dropping PAGE_SIZE
will correct it. OTOH I'm quite sure the BUILD_BUG_ON() won't trigger
any more with PAGE_SIZE being dropped. :-)

>> Maybe you should use STUB_BUF_SIZE instead of PAGE_SIZE?
> 
> No - that would be incorrect because of the physical packing of stubs
> which occurs.
> 
>> BTW: Is there any reason we don't use a common stub page mapped to each
>> per-cpu stack area? The stack address can easily be obtained via %rip
>> relative addressing then (see my patch for the per-vcpu stacks:
>> https://lists.xen.org/archives/html/xen-devel/2018-02/msg00773.html )
> 
> I don't understand what you are asking here.  We cannot access the
> per-cpu area with plain rip-retaliative addressing without using gs base
> (and we really don't want to go down that route), or without per-cpu
> pagetables (which would have to be a compile time choice).

The stub-page of a cpu is currently mapped as the 3rd page of the
stack area. So the distance to the primary stack would be the same
for all cpus (a little bit less than 20kB).

> As for why the per-cpu areas aren't mapped, that's because they aren't
> needed at the moment.  Any decision to change this needs to weigh the
> utility of mapping the areas vs the additional data leakage, which is
> substantial.

The stack area is mapped. And that's where the stub is living.


Juergen

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] x86/spec_ctrl: Fix several bugs in SPEC_CTRL_ENTRY_FROM_INTR_IST

[Andrew Cooper]

On 14/02/18 11:47, Roger Pau Monné wrote:
>
>> diff --git a/xen/include/asm-x86/spec_ctrl_asm.h 
>> b/xen/include/asm-x86/spec_ctrl_asm.h
>> index 814f53d..1f78599 100644
>> --- a/xen/include/asm-x86/spec_ctrl_asm.h
>> +++ b/xen/include/asm-x86/spec_ctrl_asm.h
>> @@ -79,10 +79,10 @@
>>   *  - SPEC_CTRL_EXIT_TO_GUEST
>>   */
>>  
>> -.macro DO_OVERWRITE_RSB
>> +.macro DO_OVERWRITE_RSB tmp=%rax
>>  /*
>>   * Requires nothing
>> - * Clobbers %rax, %rcx
>> + * Clobbers \tmp (%rax by default), %rcx
> Is it worth changing %rcx to %ecx here...

No, because a mov to %ecx clobbers %rcx.  I'll adjust the comment.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] x86/xpti: Hide almost all of .text and all .data/.rodata/.bss mappings

[Andrew Cooper]

On 14/02/18 07:54, Juergen Gross wrote:
> On 13/02/18 20:45, Andrew Cooper wrote:
>> The current XPTI implementation isolates the directmap (and therefore a lot 
>> of
>> guest data), but a large quantity of CPU0's state (including its stack)
>> remains visible.
>>
>> Furthermore, an attacker able to read .text is in a vastly superior position
>> to normal when it comes to fingerprinting Xen for known vulnerabilities, or
>> scanning for ROP/Spectre gadgets.
>>
>> Collect together the entrypoints in .text.entry (currently 3x4k frames, but
>> can almost certainly be slimmed down), and create a common mapping which is
>> inserted into each per-cpu shadow.  The stubs are also inserted into this
>> mapping by pointing at the in-use L2.  This allows stubs allocated later (SMP
>> boot, or CPU hotplug) to work without further changes to the common mappings.
>>
>> Signed-off-by: Andrew Cooper 
>> ---
>> CC: Jan Beulich 
>> CC: Wei Liu 
>> CC: Juergen Gross 
>>
>> RFC, because I don't think the stubs handling is particularly sensible.
>>
>> We allocate 4k of virtual address space per CPU, but squash loads of CPUs
>> together onto a single MFN.  The stubs ought to be isolated as well (as they
>> leak the virtual addresses of each stack), which can be done by allocating an
>> MFN per CPU (and simplifies cpu_smpboot_alloc() somewhat).  At this point, we
>> can't use a common set of mappings, and will have to clone the single stub 
>> and
>> .entry.text into each PCPUs copy of the pagetables.
>>
>> Also, my plan to cause .text.entry to straddle a 512TB boundary (and 
>> therefore
>> avoid any further pagetable allocations) has come a little unstuck because of
>> CONFIG_BIGMEM.  I'm still working out whether there is a sensible way to
>> rearrange the virtual layout for this plan to work.
>> ---
>>  xen/arch/x86/smpboot.c | 37 
>> -
>>  xen/arch/x86/x86_64/compat/entry.S |  2 ++
>>  xen/arch/x86/x86_64/entry.S|  4 +++-
>>  xen/arch/x86/xen.lds.S |  7 +++
>>  4 files changed, 44 insertions(+), 6 deletions(-)
>>
>> diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
>> index 2ebef03..2519141 100644
>> --- a/xen/arch/x86/smpboot.c
>> +++ b/xen/arch/x86/smpboot.c
>> @@ -622,6 +622,9 @@ unsigned long alloc_stub_page(unsigned int cpu, unsigned 
>> long *mfn)
>>  unmap_domain_page(memset(__map_domain_page(pg), 0xcc, PAGE_SIZE));
>>  }
>>  
>> +/* Confirm that all stubs fit in a single L2 pagetable. */
>> +BUILD_BUG_ON(NR_CPUS * PAGE_SIZE > (1u << L2_PAGETABLE_SHIFT));
> So we limit NR_CPUS to be max 512 now?

Not intentionally.  The PAGE_SIZE should be dropped.  (One full L2
pagetable allows us to map 512*512 pages).

> Maybe you should use STUB_BUF_SIZE instead of PAGE_SIZE?

No - that would be incorrect because of the physical packing of stubs
which occurs.

> BTW: Is there any reason we don't use a common stub page mapped to each
> per-cpu stack area? The stack address can easily be obtained via %rip
> relative addressing then (see my patch for the per-vcpu stacks:
> https://lists.xen.org/archives/html/xen-devel/2018-02/msg00773.html )

I don't understand what you are asking here.  We cannot access the
per-cpu area with plain rip-retaliative addressing without using gs base
(and we really don't want to go down that route), or without per-cpu
pagetables (which would have to be a compile time choice).

As for why the per-cpu areas aren't mapped, that's because they aren't
needed at the moment.  Any decision to change this needs to weigh the
utility of mapping the areas vs the additional data leakage, which is
substantial.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] x86/spec_ctrl: Fix several bugs in SPEC_CTRL_ENTRY_FROM_INTR_IST

[Wei Liu]

On Wed, Feb 14, 2018 at 11:10:55AM +, Andrew Cooper wrote:
> DO_OVERWRITE_RSB clobbers %rax, meaning in practice that that the bti_ist_info
> field gets zeroed.  Older versions of this code had the DO_OVERWRITE_RSB
> register selectable, so reintroduce this ability and use it to cause the
> INTR_IST path to use %rdx instead.
> 
> The use of %dl for the %cs.rpl check means that when an IST interrupt hits
> Xen, we try to load 1 into the high 32 bits of MSR_SPEC_CTRL, suffering a #GP
> fault instead.
> 
> Also, drop an unused label which was a copy/paste mistake.
> 
> Reported-by: Boris Ostrovsky 
> Reported-by: Zhenzhong Duan 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Wei Liu 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] x86/spec_ctrl: Fix several bugs in SPEC_CTRL_ENTRY_FROM_INTR_IST

[Roger Pau Monné]

On Wed, Feb 14, 2018 at 11:10:55AM +, Andrew Cooper wrote:
> DO_OVERWRITE_RSB clobbers %rax, meaning in practice that that the bti_ist_info
   ^dup
> field gets zeroed.  Older versions of this code had the DO_OVERWRITE_RSB
> register selectable, so reintroduce this ability and use it to cause the
> INTR_IST path to use %rdx instead.
> 
> The use of %dl for the %cs.rpl check means that when an IST interrupt hits
> Xen, we try to load 1 into the high 32 bits of MSR_SPEC_CTRL, suffering a #GP
> fault instead.
> 
> Also, drop an unused label which was a copy/paste mistake.
> 
> Reported-by: Boris Ostrovsky 
> Reported-by: Zhenzhong Duan 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Roger Pau Monné 

> ---
> CC: Jan Beulich 
> CC: Zhenzhong Duan 
> CC: Boris Ostrovsky 
> CC: Wei Liu 
> CC: Roger Pau Monné 
> ---
>  xen/include/asm-x86/spec_ctrl_asm.h | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/xen/include/asm-x86/spec_ctrl_asm.h 
> b/xen/include/asm-x86/spec_ctrl_asm.h
> index 814f53d..1f78599 100644
> --- a/xen/include/asm-x86/spec_ctrl_asm.h
> +++ b/xen/include/asm-x86/spec_ctrl_asm.h
> @@ -79,10 +79,10 @@
>   *  - SPEC_CTRL_EXIT_TO_GUEST
>   */
>  
> -.macro DO_OVERWRITE_RSB
> +.macro DO_OVERWRITE_RSB tmp=%rax
>  /*
>   * Requires nothing
> - * Clobbers %rax, %rcx
> + * Clobbers \tmp (%rax by default), %rcx

Is it worth changing %rcx to %ecx here...

>   *
>   * Requires 256 bytes of stack space, but %rsp has no net change. Based on
>   * Google's performance numbers, the loop is unrolled to 16 iterations and 
> two
> @@ -97,7 +97,7 @@
>   * optimised with mov-elimination in modern cores.
>   */
>  mov $16, %ecx   /* 16 iterations, two calls per loop */
> -mov %rsp, %rax  /* Store the current %rsp */
> +mov %rsp, \tmp  /* Store the current %rsp */
>  
>  .L\@_fill_rsb_loop:
>  
> @@ -114,7 +114,7 @@
>  
>  sub $1, %ecx
>  jnz .L\@_fill_rsb_loop
> -mov %rax, %rsp  /* Restore old %rsp */
> +mov \tmp, %rsp  /* Restore old %rsp */
>  .endm
>  
>  .macro DO_SPEC_CTRL_ENTRY_FROM_VMEXIT ibrs_val:req
> @@ -274,7 +274,7 @@
>  testb $BTI_IST_RSB, %al
>  jz .L\@_skip_rsb
>  
> -DO_OVERWRITE_RSB
> +DO_OVERWRITE_RSB tmp=%rdx /* Clobbers %ecx/%rdx */

... to match the comment here?

Thanks, Roger.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [xen-unstable-smoke test] 119170: tolerable all pass - PUSHED

[osstest service owner]

flight 119170 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/119170/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  f25dce4a2adf518678280495712d66e627adec1e
baseline version:
 xen  3f491d6873be9caa77f02ad8d98f174f0152b819

Last test of basis   119098  2018-02-13 17:01:30 Z0 days
Failing since119108  2018-02-13 20:01:33 Z0 days6 attempts
Testing same since   119170  2018-02-14 09:35:11 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 

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
   3f491d6873..f25dce4a2a  f25dce4a2adf518678280495712d66e627adec1e -> smoke

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] x86/spec_ctrl: Fix several bugs in SPEC_CTRL_ENTRY_FROM_INTR_IST

[Jan Beulich]

>>> On 14.02.18 at 12:10,  wrote:
> DO_OVERWRITE_RSB clobbers %rax, meaning in practice that that the bti_ist_info
> field gets zeroed.  Older versions of this code had the DO_OVERWRITE_RSB
> register selectable, so reintroduce this ability and use it to cause the
> INTR_IST path to use %rdx instead.
> 
> The use of %dl for the %cs.rpl check means that when an IST interrupt hits
> Xen, we try to load 1 into the high 32 bits of MSR_SPEC_CTRL, suffering a #GP
> fault instead.
> 
> Also, drop an unused label which was a copy/paste mistake.
> 
> Reported-by: Boris Ostrovsky 
> Reported-by: Zhenzhong Duan 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 
with one remark/suggestion:

> --- a/xen/include/asm-x86/spec_ctrl_asm.h
> +++ b/xen/include/asm-x86/spec_ctrl_asm.h
> @@ -79,10 +79,10 @@
>   *  - SPEC_CTRL_EXIT_TO_GUEST
>   */
>  
> -.macro DO_OVERWRITE_RSB
> +.macro DO_OVERWRITE_RSB tmp=%rax

If only registers are supposed to be passed as macro arguments,
I generally consider it better to leave specifying at least the % to
the macro body - that way nothing else (like a memory operand,
perhaps referencing %rsp in a dangerous way) can be passed, as
the assembler will choke on invalid names following %. In order to
have the flexibility to also use the 32-bit register name inside the
macro, I would also generally omit the r (but this is less of a concern
here, as it's quite unlikely for the 32-bit name to be needed).

Jan

Jan


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH] x86/spec_ctrl: Fix several bugs in SPEC_CTRL_ENTRY_FROM_INTR_IST

[Andrew Cooper]

DO_OVERWRITE_RSB clobbers %rax, meaning in practice that that the bti_ist_info
field gets zeroed.  Older versions of this code had the DO_OVERWRITE_RSB
register selectable, so reintroduce this ability and use it to cause the
INTR_IST path to use %rdx instead.

The use of %dl for the %cs.rpl check means that when an IST interrupt hits
Xen, we try to load 1 into the high 32 bits of MSR_SPEC_CTRL, suffering a #GP
fault instead.

Also, drop an unused label which was a copy/paste mistake.

Reported-by: Boris Ostrovsky 
Reported-by: Zhenzhong Duan 
Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Zhenzhong Duan 
CC: Boris Ostrovsky 
CC: Wei Liu 
CC: Roger Pau Monné 
---
 xen/include/asm-x86/spec_ctrl_asm.h | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/xen/include/asm-x86/spec_ctrl_asm.h 
b/xen/include/asm-x86/spec_ctrl_asm.h
index 814f53d..1f78599 100644
--- a/xen/include/asm-x86/spec_ctrl_asm.h
+++ b/xen/include/asm-x86/spec_ctrl_asm.h
@@ -79,10 +79,10 @@
  *  - SPEC_CTRL_EXIT_TO_GUEST
  */
 
-.macro DO_OVERWRITE_RSB
+.macro DO_OVERWRITE_RSB tmp=%rax
 /*
  * Requires nothing
- * Clobbers %rax, %rcx
+ * Clobbers \tmp (%rax by default), %rcx
  *
  * Requires 256 bytes of stack space, but %rsp has no net change. Based on
  * Google's performance numbers, the loop is unrolled to 16 iterations and two
@@ -97,7 +97,7 @@
  * optimised with mov-elimination in modern cores.
  */
 mov $16, %ecx   /* 16 iterations, two calls per loop */
-mov %rsp, %rax  /* Store the current %rsp */
+mov %rsp, \tmp  /* Store the current %rsp */
 
 .L\@_fill_rsb_loop:
 
@@ -114,7 +114,7 @@
 
 sub $1, %ecx
 jnz .L\@_fill_rsb_loop
-mov %rax, %rsp  /* Restore old %rsp */
+mov \tmp, %rsp  /* Restore old %rsp */
 .endm
 
 .macro DO_SPEC_CTRL_ENTRY_FROM_VMEXIT ibrs_val:req
@@ -274,7 +274,7 @@
 testb $BTI_IST_RSB, %al
 jz .L\@_skip_rsb
 
-DO_OVERWRITE_RSB
+DO_OVERWRITE_RSB tmp=%rdx /* Clobbers %ecx/%rdx */
 
 .L\@_skip_rsb:
 
@@ -286,13 +286,13 @@
 setz %dl
 and %dl, STACK_CPUINFO_FIELD(use_shadow_spec_ctrl)(%r14)
 
-.L\@_entry_from_xen:
 /*
  * Load Xen's intended value.  SPEC_CTRL_IBRS vs 0 is encoded in the
  * bottom bit of bti_ist_info, via a deliberate alias with BTI_IST_IBRS.
  */
 mov $MSR_SPEC_CTRL, %ecx
 and $BTI_IST_IBRS, %eax
+xor %edx, %edx
 wrmsr
 
 /* Opencoded UNLIKELY_START() with no condition. */
-- 
2.1.4


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [qemu-mainline test] 119084: regressions - FAIL

[osstest service owner]

flight 119084 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/119084/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl   6 xen-install  fail REGR. vs. 119036

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 119036
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 119036
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 119036
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 119036
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 119036
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 119036
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-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-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  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-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  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-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-xsm  14 saverestore-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-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  14 saverestore-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-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  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-amd64-libvirt-vhd 12 migrate-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:
 qemuufb68096da3d35e64c88cd610c1fa42766c58e92a
baseline version:
 qemuu7d848450b6e2a3e14a776b4c93704710e7f3d233

Last test of basis   119036  2018-02-13 00:48:14 Z1 days
Testing same since   119084  2018-02-13 13:53:59 Z0 days1 attempts


People who touched revisions under test:
  Peter Maydell 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt 

[Xen-devel] PVH Dom0 ACPI tables

[Roger Pau Monné]

Hello,

After the comments on the ACPI whitelisting patch for PVH Dom0 I've
decided to post the list of ACPI tables that I've used to create the
current whitelist, together with other tables that I've not yet added.

Allowed tables

DSDT*, FACP*, FACS*, PSDT*, SSDT*, SBST*, ASF, MCFG*, SLIC*, MSDM*,
UEFI, WDAT*, BGRT, FPDT*, S3PT*, IBFT.

* Already whitelisted.

Tables that might need mappings

BERT, MCHI, SPCR, SPMI, TCPA, WDDT, WDRT, PCCT, WPBT

Tables that could point to devices being used by Xen

DBG2, DBGP

Tables related to devices in use by Xen (or not available to Dom0)

HPET, DMAR, IVRS, WAET, CSRT, BOOT, MADT,

System topology related

SLIT, SRAT, MPST, PMTT, RASF*

* Not sure allowing Dom0 to activate 'patrol scrub' is safe.

ARM only

IORT, GTDT, STAO

Missing documentation

DRTM

This is based on the table signatures currently know to Xen (from the
actblX.h headers). I guess there are more that I'm missing.

Thanks, Roger.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [xen-unstable-coverity test] 119171: all pass - PUSHED

[osstest service owner]

flight 119171 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/119171/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xen  3f491d6873be9caa77f02ad8d98f174f0152b819
baseline version:
 xen  c9d46c6fba9496478fa9f42c4bbebce8a191527d

Last test of basis   118906  2018-02-11 09:18:48 Z3 days
Testing same since   119171  2018-02-14 09:35:07 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Daniel De Graaf 
  George Dunlap 
  Haozhong Zhang 
  Jan Beulich 
  Juergen Gross 
  Kevin Tian 
  Paul Semel 
  Roger Pau Monne 
  Roger Pau Monné 
  Sameer Goel 
  Simon Gaiser 
  Tim Deegan 
  Wei Liu 

jobs:
 coverity-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/xen.git
   c9d46c6fba..3f491d6873  3f491d6873be9caa77f02ad8d98f174f0152b819 -> 
coverity-tested/smoke

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v3] x86: fix a crash in SPEC_CTRL_ENTRY_FROM_INTR_IST

[Zhenzhong Duan]

在 2018/2/14 17:58, Jan Beulich 写道:

On 14.02.18 at 10:25,  wrote:

--- a/xen/include/asm-x86/spec_ctrl_asm.h
+++ b/xen/include/asm-x86/spec_ctrl_asm.h
@@ -269,28 +269,29 @@
   * This is logical merge of DO_OVERWRITE_RSB and DO_SPEC_CTRL_ENTRY
   * maybexen=1, but with conditionals rather than alternatives.
   */
-movzbl STACK_CPUINFO_FIELD(bti_ist_info)(%r14), %eax
+movzbl STACK_CPUINFO_FIELD(bti_ist_info)(%r14), %edx
  
-testb $BTI_IST_RSB, %al

+testb $BTI_IST_RSB, %dl
  jz .L\@_skip_rsb
  
  DO_OVERWRITE_RSB
  
  .L\@_skip_rsb:
  
-testb $BTI_IST_WRMSR, %al

+testb $BTI_IST_WRMSR, %dl
  jz .L\@_skip_wrmsr
  
+mov %edx, %eax

  xor %edx, %edx
  testb $3, UREGS_cs(%rsp)
  setz %dl
  and %dl, STACK_CPUINFO_FIELD(use_shadow_spec_ctrl)(%r14)
  
-.L\@_entry_from_xen:

  /*
   * Load Xen's intended value.  SPEC_CTRL_IBRS vs 0 is encoded in the
   * bottom bit of bti_ist_info, via a deliberate alias with BTI_IST_IBRS.
   */
+xor %edx, %edx
  mov $MSR_SPEC_CTRL, %ecx
  and $BTI_IST_IBRS, %eax
  wrmsr

While indeed you add one less instruction, you don't shrink overall
code size compared to v2. I also prefer v2 because of being more
explicit about the register needing to be preserved across
DO_OVERWRITE_RSB.
Then Ok, in fact my inital thought is to avoid unnecessory mov 
instructions around DO_OVERWRITE_RSB in the 'jmp _skip_wrmsr' case, so 
tried to remove them.


--
thanks
zduan


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 1/7] x86/alt: Drop unused alternative infrastructure

[Jan Beulich]

>>> On 13.02.18 at 15:41,  wrote:
> On 13/02/18 14:22, Jan Beulich wrote:
> On 12.02.18 at 12:23,  wrote:
>>> --- a/xen/include/asm-x86/alternative.h
>>> +++ b/xen/include/asm-x86/alternative.h
>>> @@ -65,11 +65,6 @@ extern void alternative_instructions(void);
>>> ALTERNATIVE(oldinstr, newinstr1, feature1)\
>>> ALTERNATIVE_N(newinstr2, feature2, 2)
>>>  
>>> -#define ALTERNATIVE_3(oldinstr, newinstr1, feature1, newinstr2, feature2, \
>>> - newinstr3, feature3)\
>>> -   ALTERNATIVE_2(oldinstr, newinstr1, feature1, newinstr2, feature2) \
>>> -   ALTERNATIVE_N(newinstr3, feature3, 3)
>>> -
>>>  /*
>>>   * Alternative instructions for different CPU types or capabilities.
>>>   *
>> While this one is fine, ...
>>
>>> @@ -118,26 +113,6 @@ extern void alternative_instructions(void);
>>>newinstr2, feature2) \
>>>  : output : input)
>>>  
>>> -/*
>>> - * This is similar to alternative_io. But it has three features and
>>> - * respective instructions.
>>> - *
>>> - * If CPU has feature3, newinstr3 is used.
>>> - * Otherwise, if CPU has feature2, newinstr2 is used.
>>> - * Otherwise, if CPU has feature1, newinstr1 is used.
>>> - * Otherwise, oldinstr is used.
>>> - */
>>> -#define alternative_io_3(oldinstr, newinstr1, feature1, newinstr2, \
>>> -feature2, newinstr3, feature3, output, \
>>> -input...)  \
>>> -   asm volatile(ALTERNATIVE_3(oldinstr, newinstr1, feature1,   \
>>> -  newinstr2, feature2, newinstr3,  \
>>> -  feature3)\
>>> -: output : input)
>>> -
>>> -/* Use this macro(s) if you need more than one output parameter. */
>>> -#define ASM_OUTPUT2(a...) a
>> ... I'm having patches to post which use both of these, so I'd
>> very much prefer them to not go away. It is simply a lack of time
>> which resulted in me not having posted that series already.
> 
> In which case I'll need to review that patch before commenting on this
> one (i.e. whether it actually needs to be an alternative_3, or whether
> there is a shorter way to do it).
> 
> The problem is that the gas_max() expression expands its parameters 5
> times, and ISTR a report on LKML saying that older version of GAS
> couldn't cope with the eventual expansion of the 3-replacement version.

As per my earlier reply, with ASM_OUTPUT2() retained
Reviewed-by: Jan Beulich 
provided all of this (minus patch 7) goes in together (at which
point I'll have quite some re-basing fun).

Jan


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v3] x86: fix a crash in SPEC_CTRL_ENTRY_FROM_INTR_IST

[Jan Beulich]

>>> On 14.02.18 at 10:25,  wrote:
> --- a/xen/include/asm-x86/spec_ctrl_asm.h
> +++ b/xen/include/asm-x86/spec_ctrl_asm.h
> @@ -269,28 +269,29 @@
>   * This is logical merge of DO_OVERWRITE_RSB and DO_SPEC_CTRL_ENTRY
>   * maybexen=1, but with conditionals rather than alternatives.
>   */
> -movzbl STACK_CPUINFO_FIELD(bti_ist_info)(%r14), %eax
> +movzbl STACK_CPUINFO_FIELD(bti_ist_info)(%r14), %edx
>  
> -testb $BTI_IST_RSB, %al
> +testb $BTI_IST_RSB, %dl
>  jz .L\@_skip_rsb
>  
>  DO_OVERWRITE_RSB
>  
>  .L\@_skip_rsb:
>  
> -testb $BTI_IST_WRMSR, %al
> +testb $BTI_IST_WRMSR, %dl
>  jz .L\@_skip_wrmsr
>  
> +mov %edx, %eax
>  xor %edx, %edx
>  testb $3, UREGS_cs(%rsp)
>  setz %dl
>  and %dl, STACK_CPUINFO_FIELD(use_shadow_spec_ctrl)(%r14)
>  
> -.L\@_entry_from_xen:
>  /*
>   * Load Xen's intended value.  SPEC_CTRL_IBRS vs 0 is encoded in the
>   * bottom bit of bti_ist_info, via a deliberate alias with BTI_IST_IBRS.
>   */
> +xor %edx, %edx
>  mov $MSR_SPEC_CTRL, %ecx
>  and $BTI_IST_IBRS, %eax
>  wrmsr

While indeed you add one less instruction, you don't shrink overall
code size compared to v2. I also prefer v2 because of being more
explicit about the register needing to be preserved across
DO_OVERWRITE_RSB.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 6/7] x86/alt: Drop explicit padding of origin sites

[Jan Beulich]

>>> On 12.02.18 at 12:23,  wrote:
> Now that the alternatives infrastructure can calculate the required padding
> automatically, there is no need to hard code it.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 4/7] x86/asm: Remove opencoded uses of altinstruction_entry

[Jan Beulich]

>>> On 12.02.18 at 12:23,  wrote:
> --- a/xen/arch/x86/x86_64/compat/entry.S
> +++ b/xen/arch/x86/x86_64/compat/entry.S
> @@ -109,13 +109,10 @@ ENTRY(compat_restore_all_guest)
>  ASSERT_INTERRUPTS_DISABLED
>  mov   $~(X86_EFLAGS_IOPL|X86_EFLAGS_NT|X86_EFLAGS_VM),%r11d
>  and   UREGS_eflags(%rsp),%r11d
> -.Lcr4_orig:
> -.skip .Lcr4_alt_end - .Lcr4_alt, 0x90
> -.Lcr4_orig_end:
> -.pushsection .altinstr_replacement, "ax"
> -.Lcr4_alt:
> +
> +.macro alt_cr4_pv32
>  testb $3,UREGS_cs(%rsp)
> -jpe   .Lcr4_alt_end
> +jpe   2f
>  mov   CPUINFO_cr4-CPUINFO_guest_cpu_user_regs(%rsp), %rax
>  and   $~XEN_CR4_PV32_BITS, %rax
>  1:
> @@ -133,17 +130,12 @@ ENTRY(compat_restore_all_guest)
>   */
>  cmp   %rax, CPUINFO_cr4-CPUINFO_guest_cpu_user_regs(%rsp)
>  jne   1b
> -.Lcr4_alt_end:
> -.section .altinstructions, "a"
> -altinstruction_entry .Lcr4_orig, .Lcr4_orig, X86_FEATURE_ALWAYS, \
> - (.Lcr4_orig_end - .Lcr4_orig), 0
> -altinstruction_entry .Lcr4_orig, .Lcr4_alt, X86_FEATURE_XEN_SMEP, \
> - (.Lcr4_orig_end - .Lcr4_orig), \
> - (.Lcr4_alt_end - .Lcr4_alt)
> -altinstruction_entry .Lcr4_orig, .Lcr4_alt, X86_FEATURE_XEN_SMAP, \
> - (.Lcr4_orig_end - .Lcr4_orig), \
> - (.Lcr4_alt_end - .Lcr4_alt)
> -.popsection
> +2:
> +.endm
> + ALTERNATIVE_2 ".skip 45, 0x90", \
> +alt_cr4_pv32, X86_FEATURE_XEN_SMEP, \
> +alt_cr4_pv32, X86_FEATURE_XEN_SMAP

I'm not particularly in favor of this, but considering the end result
(after patch 6) it looks reasonable to accept the code duplication.
Down the road we may want to think about ways to re-use
replacement code sequences when they're identical.

Reviewed-by: Jan Beulich 



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 5/7] x86/alt: Support for automatic padding calculations

[Jan Beulich]

>>> On 12.02.18 at 12:23,  wrote:
> --- a/xen/arch/x86/alternative.c
> +++ b/xen/arch/x86/alternative.c
> @@ -180,13 +180,37 @@ void init_or_livepatch apply_alternatives(const struct 
> alt_instr *start,
>  uint8_t *orig = ALT_ORIG_PTR(a);
>  uint8_t *repl = ALT_REPL_PTR(a);
>  uint8_t buf[MAX_PATCH_LEN];
> +unsigned int total_len = a->orig_len + a->pad_len;
>  
> -BUG_ON(a->repl_len > a->orig_len);
> -BUG_ON(a->orig_len > sizeof(buf));
> +BUG_ON(a->repl_len > total_len);
> +BUG_ON(total_len > sizeof(buf));
>  BUG_ON(a->cpuid >= NCAPINTS * 32);
>  
>  if ( !boot_cpu_has(a->cpuid) )
> +{
> +unsigned int i;
> +
> +/* No replacement to make, but try to optimise any padding. */

Better move the comment ahead of the declaration?

> @@ -26,44 +27,64 @@ extern void apply_alternatives(const struct alt_instr 
> *start,
> const struct alt_instr *end);
>  extern void alternative_instructions(void);
>  
> -#define OLDINSTR(oldinstr)  ".L%=_orig_s:\n\t" oldinstr 
> "\n.L%=_orig_e:\n"
> -
>  #define repl_s(num) ".L%=_repl_s"#num
>  #define repl_e(num) ".L%=_repl_e"#num
>  
>  #define alt_orig_len"(.L%=_orig_e - .L%=_orig_s)"
> +#define alt_pad_len "(.L%=_orig_p - .L%=_orig_e)"
> +#define alt_total_len   "(.L%=_orig_p - .L%=_orig_s)"
>  #define alt_repl_len(num)   "(" repl_e(num) " - " repl_s(num) ")"
> +#define gas_max(a, b) \
> +"((" a ") ^ (((" a ") ^ (" b ")) & -(-((" a ") < (" b ")"
> +
> +#define OLDINSTR_1(oldinstr, n1)  \
> +".L%=_orig_s:\n\t" oldinstr "\n .L%=_orig_e:\n\t" \
> +".skip (-(("alt_repl_len(n1)"-"alt_orig_len") > 0) * "\
> + "("alt_repl_len(n1)"-"alt_orig_len")), 0x90\n\t" \
> +".L%=_orig_p:\n\t"
> +
> +#define ALT_PADDING_LEN(n1, n2) \
> +gas_max((alt_repl_len(n1), alt_repl_len(n2))"-"alt_orig_len
> +
> +#define OLDINSTR_2(oldinstr, n1, n2)  \
> +".L%=_orig_s:\n\t" oldinstr "\n .L%=_orig_e:\n\t" \
> +".skip (-(("ALT_PADDING_LEN(n1, n2)") > 0) * "\
> + "("ALT_PADDING_LEN(n1, n2)")), 0x90\n\t" \
> +".L%=_orig_p:\n\t"
>  
>  #define ALTINSTR_ENTRY(feature, num)\
>  " .long .L%=_orig_s - .\n"/* label   */ \
>  " .long " repl_s(num)" - .\n" /* new instruction */ \
>  " .word " __stringify(feature) "\n"   /* feature bit */ \
>  " .byte " alt_orig_len "\n"   /* source len  */ \
> -" .byte " alt_repl_len(num) "\n"  /* replacement len */
> +" .byte " alt_repl_len(num) "\n"  /* replacement len */ \
> +" .byte " alt_pad_len "\n"/* padding len */
>  
> -#define DISCARD_ENTRY(num)/* repl <= orig */\
> -" .byte 0xff + (" alt_repl_len(num) ") - (" alt_orig_len ")\n"
> +#define DISCARD_ENTRY(num)/* repl <= total */   \
> +" .byte 0xff + (" alt_repl_len(num) ") - (" alt_total_len ")\n"

I don't think this is of much use anymore, now that you add the
padding automatically (same for the respective part of the
check in the assembler macro). Use

".byte " alt_total_len "\n" /* total_len <= 255 */

here instead (eliminating their explicit uses below)?

Jan


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2] x86: fix a crash in SPEC_CTRL_ENTRY_FROM_INTR_IST

[Roger Pau Monné]

On Wed, Feb 14, 2018 at 01:09:28AM -0700, Jan Beulich wrote:
> In an IBRS available env, bootup panic when bti=0 like below:
> 
> (XEN) Speculative mitigation facilities:
> (XEN)   Hardware features: SMEP IBRS/IBPB STIBP
> (XEN) BTI mitigations: Thunk N/A, Others: IBRS- SMEP
> (XEN) [ Xen-4.4.4OVM  x86_64  debug=n  Tainted:C ]
> (XEN) CPU:0
> (XEN) RIP:e008:[]
> entry.o#handle_ist_exception+0xd1/0x176
> (XEN) RFLAGS: 00010046   CONTEXT: hypervisor
> (XEN) rax:    rbx:    rcx: 0048
> (XEN) rdx: 0001   rsi:    rdi: 
> (XEN) rbp:    rsp: 82d080529f58   r8:  
> (XEN) r9:     r10:    r11: 
> (XEN) r12:    r13:    r14: 82d08052
> (XEN) r15:    cr0: 8005003b   cr4: 001506f0
> (XEN) cr3: 76fbe000   cr2: 
> (XEN) ds:    es:    fs:    gs:    ss:    cs: e008
> (XEN) Xen stack trace from rsp=82d080529f58:
> (XEN)0018  0002 82d080528000
> (XEN) 82d0802a50e0 82d08052fd98 82d08072fc00
> (XEN) 0001 0400 0830
> (XEN) 000a 82d0803f0fc0 0002
> (XEN)82d080298876 e008 0046 82d08052fdf8
> (XEN)
> (XEN) Xen call trace:
> (XEN)[] entry.o#handle_ist_exception+0xd1/0x176
> (XEN)
> (XEN)
> (XEN) 
> (XEN) Panic on CPU 0:
> (XEN) GENERAL PROTECTION FAULT
> (XEN) [error_code=]
> (XEN) 
> 
> It's due to %edx isn't cleared to zero before wrmsr.
> 
> DO_OVERWRITE_RSB clobbers %eax and happend to cover the bug in certain case so
> we didn't reproduce without bti=0.
> 
> Signed-off-by: Zhenzhong Duan 
> 
> Re-do actual code change. Also drop an unused label.
> 
> Signed-off-by: Jan Beulich 

Reviewed-by: Roger Pau Monné 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v3] x86: fix a crash in SPEC_CTRL_ENTRY_FROM_INTR_IST

[Zhenzhong Duan]

In an IBRS available env, bootup panic when bti=0 like below:

(XEN) Speculative mitigation facilities:
(XEN)   Hardware features: SMEP IBRS/IBPB STIBP
(XEN) BTI mitigations: Thunk N/A, Others: IBRS- SMEP
(XEN) [ Xen-4.4.4OVM  x86_64  debug=n  Tainted:C ]
(XEN) CPU:0
(XEN) RIP:e008:[] entry.o#handle_ist_exception+0xd1/0x176
(XEN) RFLAGS: 00010046   CONTEXT: hypervisor
(XEN) rax:    rbx:    rcx: 0048
(XEN) rdx: 0001   rsi:    rdi: 
(XEN) rbp:    rsp: 82d080529f58   r8:  
(XEN) r9:     r10:    r11: 
(XEN) r12:    r13:    r14: 82d08052
(XEN) r15:    cr0: 8005003b   cr4: 001506f0
(XEN) cr3: 76fbe000   cr2: 
(XEN) ds:    es:    fs:    gs:    ss:    cs: e008
(XEN) Xen stack trace from rsp=82d080529f58:
(XEN)0018  0002 82d080528000
(XEN) 82d0802a50e0 82d08052fd98 82d08072fc00
(XEN) 0001 0400 0830
(XEN) 000a 82d0803f0fc0 0002
(XEN)82d080298876 e008 0046 82d08052fdf8
(XEN)
(XEN) Xen call trace:
(XEN)[] entry.o#handle_ist_exception+0xd1/0x176
(XEN)
(XEN)
(XEN) 
(XEN) Panic on CPU 0:
(XEN) GENERAL PROTECTION FAULT
(XEN) [error_code=]
(XEN) 

It's due to %edx isn't cleared to zero before wrmsr.

DO_OVERWRITE_RSB clobbers %eax and happend to cover the bug in certain case so
we didn't reproduce without bti=0. Change to use %edx.

Also drop an unused label per Jan.

Reported-by: Boris Ostrovsky 
Signed-off-by: Zhenzhong Duan 
Signed-off-by: Jan Beulich 
---
 xen/include/asm-x86/spec_ctrl_asm.h |9 +
 1 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/xen/include/asm-x86/spec_ctrl_asm.h 
b/xen/include/asm-x86/spec_ctrl_asm.h
index 814f53d..7b259c4 100644
--- a/xen/include/asm-x86/spec_ctrl_asm.h
+++ b/xen/include/asm-x86/spec_ctrl_asm.h
@@ -269,28 +269,29 @@
  * This is logical merge of DO_OVERWRITE_RSB and DO_SPEC_CTRL_ENTRY
  * maybexen=1, but with conditionals rather than alternatives.
  */
-movzbl STACK_CPUINFO_FIELD(bti_ist_info)(%r14), %eax
+movzbl STACK_CPUINFO_FIELD(bti_ist_info)(%r14), %edx
 
-testb $BTI_IST_RSB, %al
+testb $BTI_IST_RSB, %dl
 jz .L\@_skip_rsb
 
 DO_OVERWRITE_RSB
 
 .L\@_skip_rsb:
 
-testb $BTI_IST_WRMSR, %al
+testb $BTI_IST_WRMSR, %dl
 jz .L\@_skip_wrmsr
 
+mov %edx, %eax
 xor %edx, %edx
 testb $3, UREGS_cs(%rsp)
 setz %dl
 and %dl, STACK_CPUINFO_FIELD(use_shadow_spec_ctrl)(%r14)
 
-.L\@_entry_from_xen:
 /*
  * Load Xen's intended value.  SPEC_CTRL_IBRS vs 0 is encoded in the
  * bottom bit of bti_ist_info, via a deliberate alias with BTI_IST_IBRS.
  */
+xor %edx, %edx
 mov $MSR_SPEC_CTRL, %ecx
 and $BTI_IST_IBRS, %eax
 wrmsr
-- 
1.7.3

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2] x86: fix a crash in SPEC_CTRL_ENTRY_FROM_INTR_IST

[Zhenzhong Duan]

在 2018/2/14 16:09, Jan Beulich 写道:

In an IBRS available env, bootup panic when bti=0 like below:

(XEN) Speculative mitigation facilities:
(XEN)   Hardware features: SMEP IBRS/IBPB STIBP
(XEN) BTI mitigations: Thunk N/A, Others: IBRS- SMEP
(XEN) [ Xen-4.4.4OVM  x86_64  debug=n  Tainted:C ]
(XEN) CPU:0
(XEN) RIP:e008:[]
entry.o#handle_ist_exception+0xd1/0x176
(XEN) RFLAGS: 00010046   CONTEXT: hypervisor
(XEN) rax:    rbx:    rcx: 0048
(XEN) rdx: 0001   rsi:    rdi: 
(XEN) rbp:    rsp: 82d080529f58   r8:  
(XEN) r9:     r10:    r11: 
(XEN) r12:    r13:    r14: 82d08052
(XEN) r15:    cr0: 8005003b   cr4: 001506f0
(XEN) cr3: 76fbe000   cr2: 
(XEN) ds:    es:    fs:    gs:    ss:    cs: e008
(XEN) Xen stack trace from rsp=82d080529f58:
(XEN)0018  0002 82d080528000
(XEN) 82d0802a50e0 82d08052fd98 82d08072fc00
(XEN) 0001 0400 0830
(XEN) 000a 82d0803f0fc0 0002
(XEN)82d080298876 e008 0046 82d08052fdf8
(XEN)
(XEN) Xen call trace:
(XEN)[] entry.o#handle_ist_exception+0xd1/0x176
(XEN)
(XEN)
(XEN) 
(XEN) Panic on CPU 0:
(XEN) GENERAL PROTECTION FAULT
(XEN) [error_code=]
(XEN) 

It's due to %edx isn't cleared to zero before wrmsr.

DO_OVERWRITE_RSB clobbers %eax and happend to cover the bug in certain case so
we didn't reproduce without bti=0.

Signed-off-by: Zhenzhong Duan 

Re-do actual code change. Also drop an unused label.

Signed-off-by: Jan Beulich 

--- a/xen/include/asm-x86/spec_ctrl_asm.h
+++ b/xen/include/asm-x86/spec_ctrl_asm.h
@@ -274,7 +274,9 @@
  testb $BTI_IST_RSB, %al
  jz .L\@_skip_rsb
  
+mov %eax, %edx

  DO_OVERWRITE_RSB
+mov %edx, %eax
  
  .L\@_skip_rsb:
  
@@ -286,13 +288,13 @@

  setz %dl
  and %dl, STACK_CPUINFO_FIELD(use_shadow_spec_ctrl)(%r14)
  
-.L\@_entry_from_xen:

  /*
   * Load Xen's intended value.  SPEC_CTRL_IBRS vs 0 is encoded in the
   * bottom bit of bti_ist_info, via a deliberate alias with BTI_IST_IBRS.
   */
  mov $MSR_SPEC_CTRL, %ecx
  and $BTI_IST_IBRS, %eax
+xor %edx, %edx
  wrmsr
  
  /* Opencoded UNLIKELY_START() with no condition. */




I just found this patch could be optimized a bit actually by only adding 
two instructions. Let me prepare a v3 patch, a few minutes.


--
thanks
zduan


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] x86/xpti: Hide almost all of .text and all .data/.rodata/.bss mappings

[Jan Beulich]

>>> On 13.02.18 at 20:45,  wrote:
> RFC, because I don't think the stubs handling is particularly sensible.
> 
> We allocate 4k of virtual address space per CPU, but squash loads of CPUs
> together onto a single MFN.  The stubs ought to be isolated as well (as they
> leak the virtual addresses of each stack), which can be done by allocating an
> MFN per CPU (and simplifies cpu_smpboot_alloc() somewhat).  At this point, we
> can't use a common set of mappings, and will have to clone the single stub and
> .entry.text into each PCPUs copy of the pagetables.

The 4k-per-CPU allocation of VA space is probably not strictly
necessary - quoting the original commit message:
"While sharing physical pages among certain CPUs on the same node, for
 now the virtual mappings get established in distinct pages for each
 CPU. This isn't a strict requirement, but simplifies VA space
 management for this initial implementation: Sharing VA space would
 require additional tracking of which areas are currently in use. If
 the VA and/or TLB overhead turned out to be a problem, such extra code
 could easily be added."

Without allocating a page per CPU I think what you do is sensible.
And I don't see how hiding stubs of other CPUs would help much -
an attacker can gather stack locations from various CPUs as its
vCPU is being moved around, and you can't hide the current CPU's
stub space.

> --- a/xen/arch/x86/smpboot.c
> +++ b/xen/arch/x86/smpboot.c
> @@ -622,6 +622,9 @@ unsigned long alloc_stub_page(unsigned int cpu, unsigned 
> long *mfn)
>  unmap_domain_page(memset(__map_domain_page(pg), 0xcc, PAGE_SIZE));
>  }
>  
> +/* Confirm that all stubs fit in a single L2 pagetable. */
> +BUILD_BUG_ON(NR_CPUS * PAGE_SIZE > (1u << L2_PAGETABLE_SHIFT));

Perhaps duplicate this in setup_cpu_root_pgt() (suitably adjusted
of course, as Jürgen has already pointed out)?

> @@ -651,9 +654,6 @@ static int clone_mapping(const void *ptr, root_pgentry_t 
> *rpt)
>  l2_pgentry_t *pl2e;
>  l1_pgentry_t *pl1e;
>  
> -if ( linear < DIRECTMAP_VIRT_START )
> -return 0;

Isn't outright removing this going a little too far?

> @@ -744,6 +744,9 @@ static __read_mostly int8_t opt_xpti = -1;
>  boolean_param("xpti", opt_xpti);
>  DEFINE_PER_CPU(root_pgentry_t *, root_pgt);
>  
> +static root_pgentry_t common_pgt;

Move into setup_cpu_root_pgt()?

> +extern char _stextentry[], _etextentry[];

const?

> --- a/xen/arch/x86/x86_64/compat/entry.S
> +++ b/xen/arch/x86/x86_64/compat/entry.S
> @@ -13,6 +13,8 @@
>  #include 
>  #include 
>  
> +.section .text.entry, "ax", @progbits
> +
>  ENTRY(entry_int82)
>  ASM_CLAC
>  pushq $0

This also puts compat_create_bounce_frame into the entry section,
which surely isn't needed. Same for the non-compat variant.

> @@ -854,7 +856,7 @@ GLOBAL(autogen_entrypoints)
>  .popsection
>  .endm
>  
> -.text
> +.previous
>  autogen_stubs: /* Automatically generated stubs. */

Perhaps better to switch the earlier .section to .pushsection, and
use .popsection here?

Jan

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [xen-unstable-smoke test] 119150: regressions - FAIL

[osstest service owner]

flight 119150 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/119150/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   6 xen-buildfail REGR. vs. 119098

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-i386  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  e139d34a1c4b7775d5855458a325e0e4176bdf7e
baseline version:
 xen  3f491d6873be9caa77f02ad8d98f174f0152b819

Last test of basis   119098  2018-02-13 17:01:30 Z0 days
Testing same since   119108  2018-02-13 20:01:33 Z0 days5 attempts


People who touched revisions under test:
  Jan Beulich 

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 e139d34a1c4b7775d5855458a325e0e4176bdf7e
Author: Jan Beulich 
Date:   Tue Feb 13 18:19:33 2018 +0100

firmware/shim: correctly handle errors during Xen tree setup

"set -e" on a separate Makefile line is meaningless. Glue together all
the lines that this is supposed to cover.

Signed-off-by: Jan Beulich 
Reviewed-by: Roger Pau Monné 
Reviewed-by: Wei Liu 
(qemu changes not included)

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [linux-4.9 test] 119074: tolerable FAIL - PUSHED

[osstest service owner]

flight 119074 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/119074/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail REGR. vs. 118552

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 118552
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 118552
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 118552
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 118552
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 118552
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-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  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  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-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-xsm  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-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 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-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 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-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:
 linux7f3bd8db99746a60bcae1ec4059a4756d19b63c2
baseline version:
 linux331b057d4f3ccf2290e6e651b5728db81e9249c6

Last test of basis   118552  2018-02-03 16:18:29 Z   10 days
Testing same since   119074  2018-02-13 12:04:22 Z0 days1 attempts


People who touched revisions under test:
  Andi Kleen 
  Andy Lutomirski 
  Arnd Bergmann 
  Ashok Raj 
  Balbir Singh

Re: [Xen-devel] [PATCH v4 2/7] xen: xsm: flask: introduce XENMAPSPACE_gmfn_share for memory sharing

[Jan Beulich]

>>> On 14.02.18 at 08:15,  wrote:
> Hi Jan,
> 
> 2018-02-13 23:26 GMT+08:00 Jan Beulich :
> On 13.02.18 at 16:15,  wrote:
>>> I've updated the comments according to your previous suggestions,
>>> do they look good to you?
>>
>> The one in the public header is way too verbose. I specifically don't
>> see why you would need to spell out XSM privilege requirements
>> there. Please make new comments match existing ones in style and
>> verbosity if at all possible, while still conveying all necessary /
>> relevant information.
>>
> 
> I shortened it a little bit, and now it looks like:
> 
> #define XENMAPSPACE_gmfn_share   6 /* GMFN from another dom. Unlike
> gmfn_foreign,
>   if (c) tries to map pages from (t) into
>   (d), this doesn't require that (d) 
> itself
>   has the privilege to map the pages, but
>   instead requires that (c) has the
>   privilege to do so, as long as (d) and 
> (t)
>   are allowed to share memory pages.
>   This is XENMEM_add_to_physmap_batch 
> only,
>   and currently ARM only. */

Which leaves unclear what (c), (d), and (t) are. How about

"GMFN from another dom, XENMEM_add_to_physmap_batch (and
currently ARM) only. Other than XENMAPSPACE_gmfn_foreign this
."

(You can and should go into further detail in the commit message.)
Without this _properly_ explained, I'll continue to ask why you
can't simply make XENMAPSPACE_gmfn_foreign do what you want
(as it already takes two domid_t-s as input), by suitably adjusting
its XSM check(s).

You'd also need to adjust the comment on the foreign_domid
structure field, as it saying "gmfn_foreign" would otherwise become
stale with your change.

I don't, btw, like the ARM only part here - there's nothing
inherently wrong with the same operation being sensible on x86.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] Fix a panic in SPEC_CTRL_ENTRY_FROM_INTR_IST

[Zhenzhong Duan]

在 2018/2/14 15:56, Jan Beulich 写道:

On 14.02.18 at 05:03,  wrote:

On on IBRS available env, bootup panic when bti=0 like below:

(XEN) Speculative mitigation facilities:
(XEN)   Hardware features: SMEP IBRS/IBPB STIBP
(XEN) BTI mitigations: Thunk N/A, Others: IBRS- SMEP
(XEN) [ Xen-4.4.4OVM  x86_64  debug=n  Tainted:C ]
(XEN) CPU:0
(XEN) RIP:e008:[]
entry.o#handle_ist_exception+0xd1/0x176
(XEN) RFLAGS: 00010046   CONTEXT: hypervisor
(XEN) rax:    rbx:    rcx: 0048
(XEN) rdx: 0001   rsi:    rdi: 
(XEN) rbp:    rsp: 82d080529f58   r8:  
(XEN) r9:     r10:    r11: 
(XEN) r12:    r13:    r14: 82d08052
(XEN) r15:    cr0: 8005003b   cr4: 001506f0
(XEN) cr3: 76fbe000   cr2: 
(XEN) ds:    es:    fs:    gs:    ss:    cs: e008
(XEN) Xen stack trace from rsp=82d080529f58:
(XEN)0018  0002 82d080528000
(XEN) 82d0802a50e0 82d08052fd98 82d08072fc00
(XEN) 0001 0400 0830
(XEN) 000a 82d0803f0fc0 0002
(XEN)82d080298876 e008 0046 82d08052fdf8
(XEN)
(XEN) Xen call trace:
(XEN)[] entry.o#handle_ist_exception+0xd1/0x176
(XEN)
(XEN)
(XEN) 
(XEN) Panic on CPU 0:
(XEN) GENERAL PROTECTION FAULT
(XEN) [error_code=]
(XEN) 

It's due to %edx isn't cleared to zero before wrmsr.

DO_OVERWRITE_RSB clobbers %eax and happend to cover the bug in certain case so
we didn't reproduce without bti=0. Change to use %edx.

Reviewed-by: Boris Ostrovsky 
Tested-by: Boris Ostrovsky 
Signed-off-by: Zhenzhong Duan 

Two formal things: Please put tags in sequential (in time) order:
reporter, author(s), reviewers/testers. And please follow patch
submission rules - send them _to_ the list, with maintainers (and
other interested parties) on _cc_.

Got it.



--- a/xen/include/asm-x86/spec_ctrl_asm.h
+++ b/xen/include/asm-x86/spec_ctrl_asm.h
@@ -269,16 +269,16 @@
   * This is logical merge of DO_OVERWRITE_RSB and DO_SPEC_CTRL_ENTRY
   * maybexen=1, but with conditionals rather than alternatives.
   */
-movzbl STACK_CPUINFO_FIELD(bti_ist_info)(%r14), %eax
+movzbl STACK_CPUINFO_FIELD(bti_ist_info)(%r14), %edx
  
-testb $BTI_IST_RSB, %al

+testb $BTI_IST_RSB, %dl
  jz .L\@_skip_rsb
  
  DO_OVERWRITE_RSB
  
  .L\@_skip_rsb:
  
-testb $BTI_IST_WRMSR, %al

+testb $BTI_IST_WRMSR, %dl
  jz .L\@_skip_wrmsr
  
  xor %edx, %edx

@@ -291,6 +291,7 @@
   * Load Xen's intended value.  SPEC_CTRL_IBRS vs 0 is encoded in the
   * bottom bit of bti_ist_info, via a deliberate alias with BTI_IST_IBRS.
   */
+xor %edx, %edx
  mov $MSR_SPEC_CTRL, %ecx
  and $BTI_IST_IBRS, %eax
  wrmsr

This is wrong now, and the comment very clearly states why. I think
rather than switching %eax to %edx it would be better to preserve
%eax (e.g. by saving into %edx) around DO_OVERWRITE_RSB. I'll
send an updated patch in a few minutes.

Right, I missed this part, thanks for point.
Your v2 patch looks good for me.

--
thanks
zduan


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2 10/16] Save/Restore Support: Add suspend/resume support for timers

[Juergen Gross]

On 14/02/18 03:27, Bruno Alvisio wrote:
> Signed-off-by: Bruno Alvisio 

Reviewed-by: Juergen Gross 


Juergen

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2 05/16] Save/Restore Support: Add kernel shutdown logic to shutdown.c

[Juergen Gross]

On 14/02/18 03:27, Bruno Alvisio wrote:
> Created shutdown.c for the shutdown thread and all the shutdown related
> functions.
> 
> Signed-off-by: Bruno Alvisio 
> ---
> Changesd since v1:
>* Updated license to a BSD 3-clause. This license was taken
> from the updated original file. (Repo: sysml/mini-os)
> ---
>  Makefile   |   1 +
>  include/shutdown.h |  11 
>  shutdown.c | 188 
> +
>  3 files changed, 200 insertions(+)
>  create mode 100644 include/shutdown.h
>  create mode 100644 shutdown.c
> 
> diff --git a/Makefile b/Makefile
> index 88315c4..6a05de6 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -53,6 +53,7 @@ src-y += mm.c
>  src-$(CONFIG_NETFRONT) += netfront.c
>  src-$(CONFIG_PCIFRONT) += pcifront.c
>  src-y += sched.c
> +src-y += shutdown.c
>  src-$(CONFIG_TEST) += test.c
>  src-$(CONFIG_BALLOON) += balloon.c
>  
> diff --git a/include/shutdown.h b/include/shutdown.h
> new file mode 100644
> index 000..a5ec019
> --- /dev/null
> +++ b/include/shutdown.h
> @@ -0,0 +1,11 @@
> +#ifndef _SHUTDOWN_H_
> +#define _SHUTDOWN_H_
> +
> +#include 
> +
> +void init_shutdown(start_info_t *si);
> +
> +void kernel_shutdown(int reason) __attribute__((noreturn));
> +void kernel_suspend(void);
> +
> +#endif
> diff --git a/shutdown.c b/shutdown.c
> new file mode 100644
> index 000..aba146e
> --- /dev/null
> +++ b/shutdown.c
> @@ -0,0 +1,188 @@
> +/*
> + *  MiniOS
> + *
> + *   file: fromdevice.cc

shutdown.c?

> + *
> + * Authors: Joao Martins 
> + *
> + *
> + * Copyright (c) 2014, NEC Europe Ltd., NEC Corporation. All rights reserved.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + *
> + * 1. Redistributions of source code must retain the above copyright
> + *notice, this list of conditions and the following disclaimer.
> + * 2. Redistributions in binary form must reproduce the above copyright
> + *notice, this list of conditions and the following disclaimer in the
> + *documentation and/or other materials provided with the distribution.
> + * 3. Neither the name of the copyright holder nor the names of its
> + *contributors may be used to endorse or promote products derived from
> + *this software without specific prior written permission.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS 
> IS"
> + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
> + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
> + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> + * POSSIBILITY OF SUCH DAMAGE.
> + *
> + * THIS HEADER MAY NOT BE EXTRACTED OR MODIFIED IN ANY WAY.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +
> +static start_info_t *start_info_ptr;
> +
> +static const char *path = "control/shutdown";
> +static const char *token = "control/shutdown";
> +static xenbus_event_queue events = NULL;
> +static int end_shutdown_thread = 0;
> +
> +#ifdef CONFIG_XENBUS
> +/* This should be overridden by the application we are linked against. */
> +__attribute__((weak)) void app_shutdown(unsigned reason)
> +{
> +printk("Shutdown requested: %d\n", reason);
> +if (reason == SHUTDOWN_suspend) {
> +kernel_suspend();
> +} else {
> +struct sched_shutdown sched_shutdown = { .reason = reason };
> +HYPERVISOR_sched_op(SCHEDOP_shutdown, &sched_shutdown);
> +}
> +}
> +
> +static void shutdown_thread(void *p)
> +{
> +char *shutdown, *err;
> +unsigned int shutdown_reason;
> +
> +xenbus_watch_path_token(XBT_NIL, path, token, &events);
> +
> +for ( ;; ) {
> +xenbus_wait_for_watch(&events);
> +if ((err = xenbus_read(XBT_NIL, path, &shutdown))) {
> +free(err);
> +do_exit();
> +}
> +
> +if (end_shutdown_thread)
> +break;
> +
> +if (!strcmp(shutdown, "")) {
> +/* Avoid spurious event on xenbus */
> +/* FIXME: investigate the reason of the spurious event */

Remove the FIXME, please.

Watches will fire e.g. directly after setting them up once.


With above issues fixed you can add my:

Reviewed-by: Juergen Gross 


Juergen

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https

[Xen-devel] [PATCH v2] x86: fix a crash in SPEC_CTRL_ENTRY_FROM_INTR_IST

[Jan Beulich]

In an IBRS available env, bootup panic when bti=0 like below:

(XEN) Speculative mitigation facilities:
(XEN)   Hardware features: SMEP IBRS/IBPB STIBP
(XEN) BTI mitigations: Thunk N/A, Others: IBRS- SMEP
(XEN) [ Xen-4.4.4OVM  x86_64  debug=n  Tainted:C ]
(XEN) CPU:0
(XEN) RIP:e008:[]
entry.o#handle_ist_exception+0xd1/0x176
(XEN) RFLAGS: 00010046   CONTEXT: hypervisor
(XEN) rax:    rbx:    rcx: 0048
(XEN) rdx: 0001   rsi:    rdi: 
(XEN) rbp:    rsp: 82d080529f58   r8:  
(XEN) r9:     r10:    r11: 
(XEN) r12:    r13:    r14: 82d08052
(XEN) r15:    cr0: 8005003b   cr4: 001506f0
(XEN) cr3: 76fbe000   cr2: 
(XEN) ds:    es:    fs:    gs:    ss:    cs: e008
(XEN) Xen stack trace from rsp=82d080529f58:
(XEN)0018  0002 82d080528000
(XEN) 82d0802a50e0 82d08052fd98 82d08072fc00
(XEN) 0001 0400 0830
(XEN) 000a 82d0803f0fc0 0002
(XEN)82d080298876 e008 0046 82d08052fdf8
(XEN)
(XEN) Xen call trace:
(XEN)[] entry.o#handle_ist_exception+0xd1/0x176
(XEN)
(XEN)
(XEN) 
(XEN) Panic on CPU 0:
(XEN) GENERAL PROTECTION FAULT
(XEN) [error_code=]
(XEN) 

It's due to %edx isn't cleared to zero before wrmsr.

DO_OVERWRITE_RSB clobbers %eax and happend to cover the bug in certain case so
we didn't reproduce without bti=0.

Signed-off-by: Zhenzhong Duan 

Re-do actual code change. Also drop an unused label.

Signed-off-by: Jan Beulich 

--- a/xen/include/asm-x86/spec_ctrl_asm.h
+++ b/xen/include/asm-x86/spec_ctrl_asm.h
@@ -274,7 +274,9 @@
 testb $BTI_IST_RSB, %al
 jz .L\@_skip_rsb
 
+mov %eax, %edx
 DO_OVERWRITE_RSB
+mov %edx, %eax
 
 .L\@_skip_rsb:
 
@@ -286,13 +288,13 @@
 setz %dl
 and %dl, STACK_CPUINFO_FIELD(use_shadow_spec_ctrl)(%r14)
 
-.L\@_entry_from_xen:
 /*
  * Load Xen's intended value.  SPEC_CTRL_IBRS vs 0 is encoded in the
  * bottom bit of bti_ist_info, via a deliberate alias with BTI_IST_IBRS.
  */
 mov $MSR_SPEC_CTRL, %ecx
 and $BTI_IST_IBRS, %eax
+xor %edx, %edx
 wrmsr
 
 /* Opencoded UNLIKELY_START() with no condition. */




___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2 0/7] x86: Meltdown band-aid overhead reduction

[Jan Beulich]

>>> On 13.02.18 at 19:39,  wrote:
> On Feb 7, 2018, at 11:05, Jan Beulich  wrote:
>> 
>> 1: slightly reduce Meltdown band-aid overhead
>> 2: remove CR reads from exit-to-guest path
>> 3: introduce altinstruction_nop assembler macro
>> 4: NOP out most XPTI entry/exit code when it's not in use
>> 5: avoid double CR3 reload when switching to guest user mode
>> 6: disable XPTI when RDCL_NO
>> 7: x86: log XPTI enabled status
> 
> Since work on XPTI is ongoing, will these improvements to XPTI-stage-1 be 
> published via http://xenbits.xen.org/xsa/xsa254/README.pti? 

They first of all need to go in (or whatever sub-portion of it is
deemed acceptable). And then I'm not sure we should further
clutter the XSA with performance improvements - I'd be
inclined to add further commits to the list only if we find issues
with the current approach.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v3 2/3] x86/svm: add EFER SVME support for VGIF/VLOAD

[Jan Beulich]

>>> On 13.02.18 at 19:37,  wrote:
> Pardon any weird formatting, I'm replying on my phone. 
> 
> Because they are two different things.  One is an assert to make sure 
> nothing wrong is happening with the EFER.SVME bit, and the other changes what 
> features are enabled.  
> 
> IIRC, most asserts are on their on ifs and not in a if statement with 
> something else.  I guess I should have put the assert higher in the function 
> though but that's a small detail.  
> 
> Yes, you can squeeze both in one if statement but, but it being cleaner and 
> easier to read (at least more logical) is better than getting rid of one if 
> in my opinion.  Plus assuming asserts are disabled for release, I'd assume 
> the extra if would get optimized out by gcc anyway. 

In that case it would better be

ASSERT(nestedhvm_enabled(v->domain) || !(v->arch.hvm_vcpu.guest_efer & 
EFER_SVME));

(suitably line wrapped if necessary). But I continue to think the
if/else variant looks better overall. It'll be the SVM maintainers to
decide, though.

Jan

> On February 13, 2018 03:31:40 Jan Beulich  wrote:
> 
> On 08.02.18 at 18:01,  wrote:
>>> --- a/xen/arch/x86/hvm/svm/svm.c
>>> +++ b/xen/arch/x86/hvm/svm/svm.c
>>> @@ -611,6 +611,12 @@ static void svm_update_guest_efer(struct vcpu *v)
>>>  if ( lma )
>>>  new_efer |= EFER_LME;
>>>  vmcb_set_efer(vmcb, new_efer);
>>> +
>>> +if ( !nestedhvm_enabled(v->domain) )
>>> +ASSERT(!(v->arch.hvm_vcpu.guest_efer & EFER_SVME));
>>> +
>>> +if ( nestedhvm_enabled(v->domain) )
>>> +svm_nested_features_on_efer_update(v);
>>>  }
>>
>> Why not
>>
>> if ( nestedhvm_enabled(v->domain) )
>> svm_nested_features_on_efer_update(v);
>> else
>> ASSERT(!(v->arch.hvm_vcpu.guest_efer & EFER_SVME));
>>
>> ?
>>
>> Jan
>>
>>
>>




___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel