Re: [Xen-devel] [PATCH v2 1/2] docs/process: Add RUBRIC

[Juergen Gross]

On 22/05/18 18:45, Ian Jackson wrote:
> Signed-off-by: Ian Jackson 

Acked-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 2/2] docs/process/xen-release-management: Lesson to learn

[Juergen Gross]

On 22/05/18 18:45, Ian Jackson wrote:
> The 4.10 release preparation was significantly more hairy than ideal.
> (We seem to have a good overall outcome despite, rather than because
> of, our approach.)
> 
> This is the second time (at least) that we have come close to failure
> by committing to a release date before the exact code to be released
> is known and has been made and tested.
> 
> Evidently our docs makes it insufficiently clear not to do that.
> 
> CC: Lars Kurth 
> CC: Julien Grall 
> Acked-by: Juergen Gross 
> Signed-off-by: Ian Jackson 
> ---
>  docs/process/xen-release-management.pandoc | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/docs/process/xen-release-management.pandoc 
> b/docs/process/xen-release-management.pandoc
> index 2ff0665..eee5dcf 100644
> --- a/docs/process/xen-release-management.pandoc
> +++ b/docs/process/xen-release-management.pandoc
> @@ -211,6 +211,11 @@ https://wiki.xenproject.org/wiki/Category:Xen_4.9
>  Ask them to dry-run their checklist and confirm everything is OK. If not,
>  arrange another RC and restart this checklist.
>  
> +7. Do not commit to a release date until
> +
> +* The exact xen.git commit id to be released is known.
> +* That commit id has been satisfactorily tested.
> +
>  7. Give PR Personnel final go-ahead, and instruct Release Technician to make

Just seeing it now: this should be "8.".


Juergen

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

Re: [Xen-devel] [for-4.11] Re: [PATCH 00/13] xen/arm: SSBD (aka Spectre-v4) mitigation (XSA-263)

[Juergen Gross]

On 22/05/18 19:46, Julien Grall wrote:
> I forgot to CC Juergen as RM. This series is candidate for Xen 4.11 as
> part of XSA-263.

For XSA patches I don't think you need it, but you can have my

Release-acked-by: Juergen Gross 

for the series, of course.


Juergen

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

Re: [Xen-devel] [PATCH] tools/kdd: alternative way of muting spurious gcc warning

[Juergen Gross]

On 22/05/18 21:47, Marek Marczykowski-Górecki wrote:
> Older gcc does not support #pragma GCC diagnostics, so use alternative
> approach - change variable type to uint32_t (this code handle 32-bit
> requests only anyway), which apparently also avoid gcc complaining about
> this (otherwise correct) code.
> 
> Fixes 437e00fea04becc91c1b6bc1c0baa636b067a5cc "tools/kdd: mute spurious
> gcc warning"
> 
> Signed-off-by: Marek Marczykowski-Górecki 

Release-acked-by: Juergen Gross 


Juergen

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

[Xen-devel] [xen-4.10-testing test] 122987: FAIL

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-arm64-arm64-xl-xsm  broken  in 122915

Tests which are failing intermittently (not blocking):
 test-arm64-arm64-xl-xsm  4 host-install(4) broken in 122915 pass in 122987
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail 
in 122915 pass in 122987
 test-amd64-amd64-xl-qemut-debianhvm-amd64 16 guest-localmigrate/x10 fail in 
122915 pass in 122987
 test-amd64-amd64-pygrub  17 guest-localmigrate/x10 fail pass in 122915
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 16 guest-localmigrate/x10 fail pass 
in 122915

Tests which did not succeed, but are not blocking:
 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-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-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-credit2  13 migrate-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-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop 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-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-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-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-armhf-armhf-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-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail 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-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 

Re: [Xen-devel] Draft NVDIMM proposal

[Dan Williams]

On Thu, May 17, 2018 at 7:52 AM, George Dunlap  wrote:
> On 05/15/2018 07:06 PM, Dan Williams wrote:
>> On Tue, May 15, 2018 at 7:19 AM, George Dunlap  
>> wrote:
>>> So, who decides what this SPA range and interleave set is?  Can the
>>> operating system change these interleave sets and mappings, or change
>>> data from PMEM to BLK, and is so, how?
>>
>> The interleave-set to SPA range association and delineation of
>> capacity between PMEM and BLK access modes is current out-of-scope for
>> ACPI. The BIOS reports the configuration to the OS via the NFIT, but
>> the configuration is currently written by vendor specific tooling.
>> Longer term it would be great for this mechanism to become
>> standardized and available to the OS, but for now it requires platform
>> specific tooling to change the DIMM interleave configuration.
>
> OK -- I was sort of assuming that different hardware would have
> different drivers in Linux that ndctl knew how to drive (just like any
> other hardware with vendor-specific interfaces);

That way potentially lies madness, at least for me as a Linux
sub-system maintainer. There is no value for the kernel to help enable
vendors to do the same thing slightly differently ways. libnvdimm +
nfit is 100% an open standards driver and the hope is to be able to
deprecate non-public vendor-specific support over time, and
consolidate work-alike support from vendor specs into ACPI. The public
standards that the kernel enables are:

http://www.uefi.org/sites/default/files/resources/ACPI%206_2_A_Sept29.pdf
http://www.uefi.org/sites/default/files/resources/UEFI%20Spec%202_7_A%20Sept%206.pdf
http://pmem.io/documents/NVDIMM_DSM_Interface-V1.6.pdf
https://github.com/HewlettPackard/hpe-nvm/blob/master/Documentation/
https://msdn.microsoft.com/library/windows/hardware/mt604741

> but it sounds a bit
> more like at the moment it's binary blobs either in the BIOS/firmware,
> or a vendor-supplied tool.

Only for the functionality, like interleave set configuration, that is
not defined in those standards. Even then the impact is only userspace
tooling, not the kernel. Also, we are seeing that functionality bleed
into the standards over time. For example label methods used to only
exist in the Intel DSM document, but have now been standardized in
ACPI 6.2. Firmware update which was a private interface has now
graduated to the public Intel DSM document. Hopefully more and more
functionality transitions into an ACPI definition over time. Any
common functionality in those Intel, HPE, and MSFT command formats is
comprehended / abstracted by the ndctl tool.

>
>>> And so (here's another guess) -- when you're talking about namespaces
>>> and label areas, you're talking about namespaces stored *within a
>>> pre-existing SPA range*.  You use the same format as described in the
>>> UEFI spec, but ignore all the stuff about interleave sets and whatever,
>>> and use system physical addresses relative to the SPA range rather than
>>> DPAs.
>>
>> Well, we don't ignore it because we need to validate in the driver
>> that the interleave set configuration matches a checksum that we
>> generated when the namespace was first instantiated on the interleave
>> set. However, you are right, for accesses at run time all we care
>> about is the SPA for PMEM accesses.
> [snip]
>> They can change, but only under the control of the BIOS. All changes
>> to the interleave set configuration need a reboot because the memory
>> controller needs to be set up differently at system-init time.
> [snip]
>> No, the checksum I'm referring to is the interleave set cookie (see:
>> "SetCookie" in the UEFI 2.7 specification). It validates that the
>> interleave set backing the SPA has not changed configuration since the
>> last boot.
> [snip]
>> The NVDIMM just provides storage area for the OS to write opaque data
>> that just happens to conform to the UEFI Namespace label format. The
>> interleave-set configuration is stored in yet another out-of-band
>> location on the DIMM or on some platform-specific storage location and
>> is consulted / restored by the BIOS each boot. The NFIT is the output
>> from the platform specific physical mappings of the DIMMs, and
>> Namespaces are logical volumes built on top of those hard-defined NFIT
>> boundaries.
>
> OK, so what I'm hearing is:
>
> The label area isn't "within a pre-existing SPA range" as I was guessing
> (i.e., similar to a partition table residing within a disk); it is the
> per-DIMM label area as described by UEFI spec.
>
> But, the interleave set data in the label area doesn't *control* the
> hardware -- the NVDIMM controller / bios / firmware don't read it or do
> anything based on what's in it.  Rather, the interleave set data in the
> label area is there to *record*, for the operating system's benefit,
> what the hardware configuration was when the labels were created, so
> that if it changes, the OS knows that the label area is 

[Xen-devel] [PATCH v3 03/10] arm: rename HAS_GICV3 to GICV3

[Stefano Stabellini]

HAS_GICV3 has become selectable by the user. To mark the change, rename
the option from HAS_GICV3 to GICV3.

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

---
Changes in v3:
- no changes

Changes in v2:
- patch added
---
 xen/arch/arm/Kconfig   | 4 ++--
 xen/arch/arm/Makefile  | 4 ++--
 xen/arch/arm/vgic.c| 2 +-
 xen/arch/arm/vgic/vgic.c   | 2 +-
 xen/include/asm-arm/gic.h  | 4 ++--
 xen/include/asm-arm/vgic.h | 4 ++--
 6 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index fb69a66..66adce4 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -39,7 +39,7 @@ config ACPI
  Advanced Configuration and Power Interface (ACPI) support for Xen is
  an alternative to device tree on ARM64.
 
-config HAS_GICV3
+config GICV3
bool
prompt "GICv3 driver"
depends on ARM_64
@@ -52,7 +52,7 @@ config HAS_GICV3
 config HAS_ITS
 bool
 prompt "GICv3 ITS MSI controller support" if EXPERT = "y"
-depends on HAS_GICV3 && !NEW_VGIC
+depends on GICV3 && !NEW_VGIC
 
 config NEW_VGIC
bool
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index a9533b1..b9c2fb7 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -17,7 +17,7 @@ obj-y += domctl.o
 obj-$(EARLY_PRINTK) += early_printk.o
 obj-y += gic.o
 obj-y += gic-v2.o
-obj-$(CONFIG_HAS_GICV3) += gic-v3.o
+obj-$(CONFIG_GICV3) += gic-v3.o
 obj-$(CONFIG_HAS_ITS) += gic-v3-its.o
 obj-$(CONFIG_HAS_ITS) += gic-v3-lpi.o
 obj-y += guestcopy.o
@@ -51,7 +51,7 @@ ifneq ($(CONFIG_NEW_VGIC),y)
 obj-y += gic-vgic.o
 obj-y += vgic.o
 obj-y += vgic-v2.o
-obj-$(CONFIG_HAS_GICV3) += vgic-v3.o
+obj-$(CONFIG_GICV3) += vgic-v3.o
 obj-$(CONFIG_HAS_ITS) += vgic-v3-its.o
 endif
 obj-y += vm_event.o
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 3fafdd0..7a2c455 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -98,7 +98,7 @@ int domain_vgic_register(struct domain *d, int *mmio_count)
 {
 switch ( d->arch.vgic.version )
 {
-#ifdef CONFIG_HAS_GICV3
+#ifdef CONFIG_GICV3
 case GIC_V3:
 if ( vgic_v3_init(d, mmio_count) )
return -ENODEV;
diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
index a35449b..832632a 100644
--- a/xen/arch/arm/vgic/vgic.c
+++ b/xen/arch/arm/vgic/vgic.c
@@ -974,7 +974,7 @@ unsigned int vgic_max_vcpus(const struct domain *d)
 return min_t(unsigned int, MAX_VIRT_CPUS, vgic_vcpu_limit);
 }
 
-#ifdef CONFIG_HAS_GICV3
+#ifdef CONFIG_GICV3
 /* Dummy implementation to allow building without actual vGICv3 support. */
 void vgic_v3_setup_hw(paddr_t dbase,
   unsigned int nr_rdist_regions,
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 58b910f..22fa122 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -166,7 +166,7 @@
 
 #define DT_MATCH_GIC_V3 DT_MATCH_COMPATIBLE("arm,gic-v3")
 
-#ifdef CONFIG_HAS_GICV3
+#ifdef CONFIG_GICV3
 /*
  * GICv3 registers that needs to be saved/restored
  */
@@ -194,7 +194,7 @@ struct gic_v2 {
  */
 union gic_state_data {
 struct gic_v2 v2;
-#ifdef CONFIG_HAS_GICV3
+#ifdef CONFIG_GICV3
 struct gic_v3 v3;
 #endif
 };
diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index 2a58ea3..374fdaa 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -156,7 +156,7 @@ struct vgic_dist {
 struct pending_irq *pending_irqs;
 /* Base address for guest GIC */
 paddr_t dbase; /* Distributor base address */
-#ifdef CONFIG_HAS_GICV3
+#ifdef CONFIG_GICV3
 /* GIC V3 addressing */
 /* List of contiguous occupied by the redistributors */
 struct vgic_rdist_region {
@@ -359,7 +359,7 @@ unsigned int vgic_max_vcpus(const struct domain *d);
 void vgic_v2_setup_hw(paddr_t dbase, paddr_t cbase, paddr_t csize,
   paddr_t vbase, uint32_t aliased_offset);
 
-#ifdef CONFIG_HAS_GICV3
+#ifdef CONFIG_GICV3
 struct rdist_region;
 void vgic_v3_setup_hw(paddr_t dbase,
   unsigned int nr_rdist_regions,
-- 
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/10] arm: more kconfig configurability and small default configs

[Stefano Stabellini]

Hi all,

This patch series is the first step toward building a small certifiable
Xen hypervisor for ARM boards.

First, the series makes a few changes to allow disabling more kconfig
options: most of them already exist but cannot be disabled.

Then, it introduces a reference kconfig for Renesas RCar (due to popular
demand, candidate for certifications) and for QEMU aarch64 (not for
certifications, but useful for debugging).

The last patch in the series adds a convenient cloc target to count the
total lines of code of the source files built.

As a consequence of these changes, some options will become user-visible
and not dependent on CONFIG_EXPERT. It does not mean that Xen Project
will security support all possible combinations of kconfig options.
Instead, there will be a small set of pre-canned configurations that
will be supported.  See: https://marc.info/?l=xen-devel=152424389512432

One note about Kconfig renaming: I can see the benefit of being
consistent with the naming and using HAS_ only for options that are
always enabled, but I really don't have a strong opinion on this topic.

Cheers,

Stefano

Stefano Stabellini (10):
  arm: remove the ARM HDLCD driver
  arm: make it possible to disable HAS_GICV3
  arm: rename HAS_GICV3 to GICV3
  Make MEM_ACCESS configurable
  make it possible to enable/disable UART drivers
  xen: remove HAS_ prefix from UART Kconfig options
  arm: make it possible to disable the SMMU driver
  arm: add a tiny kconfig configuration
  arm: add QEMU, Rcar3 and MPSoC configs
  xen: add cloc target

 tools/firmware/xen-dir/shim.config   |   4 +-
 xen/Makefile |  11 ++
 xen/arch/arm/Kconfig |  47 +-
 xen/arch/arm/Makefile|   4 +-
 xen/arch/arm/configs/tiny.conf   |  44 +
 xen/arch/arm/platforms/Kconfig   |  30 
 xen/arch/arm/platforms/vexpress.c|  35 
 xen/arch/arm/vgic.c  |   2 +-
 xen/arch/arm/vgic/vgic.c |   2 +-
 xen/arch/x86/Kconfig |  21 +++
 xen/common/Kconfig   |   9 +-
 xen/common/Makefile  |   2 +-
 xen/common/domctl.c  |   2 +-
 xen/drivers/char/Kconfig |  40 +++--
 xen/drivers/char/Makefile|  16 +-
 xen/drivers/passthrough/Kconfig  |  12 ++
 xen/drivers/passthrough/arm/Makefile |   2 +-
 xen/drivers/video/Kconfig|   3 -
 xen/drivers/video/Makefile   |   1 -
 xen/drivers/video/arm_hdlcd.c| 281 ---
 xen/include/asm-arm/gic.h|   4 +-
 xen/include/asm-arm/platforms/vexpress.h |   6 -
 xen/include/asm-arm/vgic.h   |   4 +-
 xen/include/xen/mem_access.h |   4 +-
 xen/include/xsm/dummy.h  |   2 +-
 xen/include/xsm/xsm.h|   4 +-
 xen/xsm/dummy.c  |   2 +-
 xen/xsm/flask/hooks.c|   4 +-
 28 files changed, 221 insertions(+), 377 deletions(-)
 create mode 100644 xen/arch/arm/configs/tiny.conf
 create mode 100644 xen/arch/arm/platforms/Kconfig
 delete mode 100644 xen/drivers/video/arm_hdlcd.c

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

[Xen-devel] [PATCH v3 10/10] xen: add cloc target

[Stefano Stabellini]

Add a Xen build target to count the lines of code of the source files
built. Uses `cloc' to do the job.

With Xen on ARM taking off in embedded, IoT, and automotive, we are
seeing more and more uses of Xen in constrained environments. Users and
system integrators want the smallest Xen and Dom0 configurations. Some
of these deployments require certifications, where you definitely want
the smallest lines of code count. I provided this patch to give us the
lines of code count for that purpose.

Use the .o.d files to account for all the built source files. Generate a
list for the `cloc' utility and invoke `cloc'.

Signed-off-by: Stefano Stabellini 
CC: jbeul...@suse.com
CC: andrew.coop...@citrix.com
---
Changes in v3:
- remove build as dependecy for the cloc target

Changes in v2:
- change implementation to use .o.d to find built source files
---
 xen/Makefile | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/xen/Makefile b/xen/Makefile
index 62d479c..ac6fe41 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -267,3 +267,14 @@ $(KCONFIG_CONFIG):
 include/config/auto.conf.cmd: ;
 
 -include $(BASEDIR)/include/config/auto.conf.cmd
+
+.PHONY: cloc
+cloc:
+   $(eval tmpfile := $(shell mktemp))
+   $(foreach f, $(shell find $(BASEDIR) -name *.o.d), \
+   $(eval path := $(dir $(f))) \
+   $(eval name := $(shell cat $(f) | head -1 | cut -d " " -f 2)) \
+   $(shell if test -f $(path)/$(name) ; then echo $(path)/$(name) 
>> $(tmpfile); fi;))
+   cloc --list-file=$(tmpfile)
+   rm $(tmpfile)
+
-- 
1.9.1


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

[Xen-devel] [PATCH v3 06/10] xen: remove HAS_ prefix from UART Kconfig options

[Stefano Stabellini]

UART drivers are now selectable by the user. To mark the change, remove
the HAS_ prefix.

Use HAS_* options to mark which options are available on which
architecture. Use HAS_*_ALWAYS_ON options to mark which options are
silent and always enabled on a given architecture.

Make NS16550 and EHCI silent and always enabled on x86.
Make all the others selectable on ARM, default on.

Suggested-by: Julien Grall 
Signed-off-by: Stefano Stabellini 
CC: andrew.coop...@citrix.com
CC: george.dun...@eu.citrix.com
CC: ian.jack...@eu.citrix.com
CC: jbeul...@suse.com
CC: julien.gr...@arm.com
CC: konrad.w...@oracle.com
CC: sstabell...@kernel.org
CC: t...@xen.org
CC: wei.l...@citrix.com


---
Changes in v3:
- use HAS_* options to mark which options are available on which arch
- use HAS_*_ALWAYS_ON options to mark which options are silent and
  always enabled on a given arch
- mark UART appropriately on x86 and arm
- remove HAS_ prefix everywhere else

Changes in v2:
- patch added
---
 tools/firmware/xen-dir/shim.config |  2 +-
 xen/arch/arm/Kconfig   | 28 ++
 xen/arch/x86/Kconfig   | 14 +
 xen/drivers/char/Kconfig   | 41 ++
 xen/drivers/char/Makefile  | 16 +++
 5 files changed, 75 insertions(+), 26 deletions(-)

diff --git a/tools/firmware/xen-dir/shim.config 
b/tools/firmware/xen-dir/shim.config
index 21d7075..d3a40e7 100644
--- a/tools/firmware/xen-dir/shim.config
+++ b/tools/firmware/xen-dir/shim.config
@@ -63,7 +63,7 @@ CONFIG_ACPI=y
 CONFIG_ACPI_LEGACY_TABLES_LOOKUP=y
 CONFIG_NUMA=y
 CONFIG_HAS_NS16550=y
-CONFIG_HAS_EHCI=y
+CONFIG_EHCI=y
 CONFIG_HAS_CPUFREQ=y
 CONFIG_HAS_PASSTHROUGH=y
 CONFIG_HAS_PCI=y
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 164cdc3..a5a6943 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -20,6 +20,13 @@ config ARM
select HAS_MEM_ACCESS
select HAS_PASSTHROUGH
select HAS_PDX
+   select HAS_NS16550
+   select HAS_CADENCE_UART
+   select HAS_MVEBU
+   select HAS_PL011
+   select HAS_EXYNOS4210
+   select HAS_OMAP
+   select HAS_SCIF
 
 config ARCH_DEFCONFIG
string
@@ -29,6 +36,27 @@ config ARCH_DEFCONFIG
 config HAS_MEM_ACCESS
def_bool y
 
+config HAS_NS16550
+   def_bool y
+
+config HAS_CADENCE_UART
+   def_bool y
+
+config HAS_MVEBU
+   def_bool y
+
+config HAS_PL011
+   def_bool y
+
+config HAS_EXYNOS4210
+   def_bool y
+
+config HAS_OMAP
+   def_bool y
+
+config HAS_SCIF
+   def_bool y
+
 menu "Architecture Features"
 
 source "arch/Kconfig"
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 0c49d71..e69f5ac 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -11,6 +11,7 @@ config X86
select HAS_ALTERNATIVE
select HAS_CPUFREQ
select HAS_EHCI
+   select HAS_EHCI_ALWAYS_ON
select HAS_EX_TABLE
select HAS_GDBSX
select HAS_IOPORTS
@@ -20,6 +21,7 @@ config X86
select HAS_MEM_PAGING
select HAS_MEM_SHARING
select HAS_NS16550
+   select HAS_NS16550_ALWAYS_ON
select HAS_PASSTHROUGH
select HAS_PCI
select HAS_PDX
@@ -37,6 +39,18 @@ config HAS_MEM_ACCESS
 config MEM_ACCESS_ALWAYS_ON
def_bool y
 
+config HAS_NS16550
+   def_bool y
+
+config HAS_NS16550_ALWAYS_ON
+   def_bool y
+
+config HAS_EHCI
+   def_bool y
+
+config HAS_EHCI_ALWAYS_ON
+   def_bool y
+
 menu "Architecture Features"
 
 source "arch/Kconfig"
diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
index c8f30b8..7204d38 100644
--- a/xen/drivers/char/Kconfig
+++ b/xen/drivers/char/Kconfig
@@ -1,60 +1,67 @@
-config HAS_NS16550
-   bool "NS16550 UART driver" if ARM
+config NS16550
+   bool "NS16550 UART driver" if !HAS_NS16550_ALWAYS_ON
+   depends on HAS_NS16550
default y
help
  This selects the 16550-series UART support. For most systems, say Y.
 
-config HAS_CADENCE_UART
-   bool "Xilinx Cadence UART driver"
+config CADENCE_UART
+   bool "Xilinx Cadence UART driver" if !HAS_CADENCE_UART_ALWAYS_ON
+   depends on HAS_CADENCE_UART
default y
depends on ARM_64
help
  This selects the Xilinx Zynq Cadence UART. If you have a Xilinx Zynq
  based board, say Y.
 
-config HAS_MVEBU
-   bool "Marvell MVEBU UART driver"
+config MVEBU
+   bool "Marvell MVEBU UART driver" if !HAS_MVEBU_ALWAYS_ON
+   depends on HAS_MVEBU
default y
depends on ARM_64
help
  This selects the Marvell MVEBU UART. If you have a ARMADA 3700
  based board, say Y.
 
-config HAS_PL011
-   bool "ARM PL011 UART driver"
+config PL011
+   bool "ARM PL011 UART driver" if !HAS_PL011_ALWAYS_ON
+   depends on HAS_PL011
default y
depends on ARM
help
  This 

[Xen-devel] [PATCH v3 05/10] make it possible to enable/disable UART drivers

[Stefano Stabellini]

All the UART drivers are silent options. Add one line descriptions so
that can be de/selected via menuconfig.

Signed-off-by: Stefano Stabellini 
CC: jbeul...@suse.com
CC: andrew.coop...@citrix.com
---
The next patch will take care of fixing arch dependencies.

Changes in v3:
- NS16550 prompt if ARM

Changes in v2:
- make HAS_EHCI depend on x86
---
 xen/drivers/char/Kconfig | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
index cc78ec3..c8f30b8 100644
--- a/xen/drivers/char/Kconfig
+++ b/xen/drivers/char/Kconfig
@@ -1,11 +1,11 @@
 config HAS_NS16550
-   bool
+   bool "NS16550 UART driver" if ARM
default y
help
  This selects the 16550-series UART support. For most systems, say Y.
 
 config HAS_CADENCE_UART
-   bool
+   bool "Xilinx Cadence UART driver"
default y
depends on ARM_64
help
@@ -13,7 +13,7 @@ config HAS_CADENCE_UART
  based board, say Y.
 
 config HAS_MVEBU
-   bool
+   bool "Marvell MVEBU UART driver"
default y
depends on ARM_64
help
@@ -21,7 +21,7 @@ config HAS_MVEBU
  based board, say Y.
 
 config HAS_PL011
-   bool
+   bool "ARM PL011 UART driver"
default y
depends on ARM
help
@@ -29,7 +29,7 @@ config HAS_PL011
  an Integrator/PP2, Integrator/CP or Versatile platform, say Y.
 
 config HAS_EXYNOS4210
-   bool
+   bool "Samsung Exynos 4210 UART driver"
default y
depends on ARM_32
help
@@ -37,7 +37,7 @@ config HAS_EXYNOS4210
  Exynos based board, say Y.
 
 config HAS_OMAP
-   bool
+   bool "Texas Instruments OMAP UART driver"
default y
depends on ARM_32
help
@@ -45,7 +45,7 @@ config HAS_OMAP
  Instruments based CPU, say Y.
 
 config HAS_SCIF
-   bool
+   bool "SuperH SCI(F) UART driver"
default y
depends on ARM
help
@@ -53,7 +53,8 @@ config HAS_SCIF
  or Renesas R-Car Gen 2/3 based board say Y.
 
 config HAS_EHCI
-   bool
+   bool "EHCI UART driver"
+   depends on X86
help
  This selects the USB based EHCI debug port to be used as a UART. If
  you have an x86 based system with USB, say Y.
-- 
1.9.1


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

[Xen-devel] [PATCH v3 07/10] arm: make it possible to disable the SMMU driver

[Stefano Stabellini]

Introduce a Kconfig option for the ARM SMMUv1 and SMMUv2 driver.

Signed-off-by: Stefano Stabellini 
CC: jbeul...@suse.com

---
Changes in v3:
- rename SMMUv2 to ARM_SMMU
- improve help message
- use if ARM

Changes in v2:
- rename HAS_SMMUv2 to SMMUv2
- move SMMUv2 to xen/drivers/passthrough/Kconfig
---
 xen/drivers/passthrough/Kconfig  | 12 
 xen/drivers/passthrough/arm/Makefile |  2 +-
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/xen/drivers/passthrough/Kconfig b/xen/drivers/passthrough/Kconfig
index 8d90b67..a3c0649 100644
--- a/xen/drivers/passthrough/Kconfig
+++ b/xen/drivers/passthrough/Kconfig
@@ -1,3 +1,15 @@
 
 config HAS_PASSTHROUGH
bool
+
+if ARM
+config ARM_SMMU
+   bool "ARM SMMUv1 and v2 driver"
+   default y
+   ---help---
+ Support for implementations of the ARM System MMU architecture
+ versions 1 and 2.
+
+ Say Y here if your SoC includes an IOMMU device implementing the
+ ARM SMMU architecture.
+endif
diff --git a/xen/drivers/passthrough/arm/Makefile 
b/xen/drivers/passthrough/arm/Makefile
index f4cd26e..0156431 100644
--- a/xen/drivers/passthrough/arm/Makefile
+++ b/xen/drivers/passthrough/arm/Makefile
@@ -1,2 +1,2 @@
 obj-y += iommu.o
-obj-y += smmu.o
+obj-$(ARM_SMMU) += smmu.o
-- 
1.9.1


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

[Xen-devel] [PATCH v3 02/10] arm: make it possible to disable HAS_GICV3

[Stefano Stabellini]

Today it is a silent option. This patch adds a one line description and
makes it optional.

Signed-off-by: Stefano Stabellini 

---
Changes in v3:
- remove any changes to MEM_ACCESS
- update commit message

Changes in v2:
- make HAS_GICv3 depend on ARM_64
- remove modifications to ARM_HDLCD kconfig, it has been removed
---
 xen/arch/arm/Kconfig | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 4dc7ef5..fb69a66 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -12,7 +12,6 @@ config ARM_32
 config ARM_64
def_bool y
depends on 64BIT
-   select HAS_GICV3
 
 config ARM
def_bool y
@@ -42,6 +41,13 @@ config ACPI
 
 config HAS_GICV3
bool
+   prompt "GICv3 driver"
+   depends on ARM_64
+   default y
+   ---help---
+
+ Driver for the ARM Generic Interrupt Controller v3.
+ If unsure, say Y
 
 config HAS_ITS
 bool
-- 
1.9.1


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

[Xen-devel] [PATCH v3 01/10] arm: remove the ARM HDLCD driver

[Stefano Stabellini]

The ARM HDLCD driver is unused. The device itself can only be found on
Virtual Express boards that are for early development only. Remove the
driver.

Also remove vexpress_syscfg, now unused, and "select VIDEO" that is not
useful anymore.

Suggested-by: Julien Grall 
Signed-off-by: Stefano Stabellini 
---
Changes in v3:
- remove "select VIDEO"
- remove vexpress_syscfg
Changes in v2:
- patch added
---
 xen/arch/arm/Kconfig |   2 -
 xen/arch/arm/platforms/vexpress.c|  35 
 xen/drivers/video/Kconfig|   3 -
 xen/drivers/video/Makefile   |   1 -
 xen/drivers/video/arm_hdlcd.c| 281 ---
 xen/include/asm-arm/platforms/vexpress.h |   6 -
 6 files changed, 328 deletions(-)
 delete mode 100644 xen/drivers/video/arm_hdlcd.c

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 8174c0c..4dc7ef5 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -17,12 +17,10 @@ config ARM_64
 config ARM
def_bool y
select HAS_ALTERNATIVE
-   select HAS_ARM_HDLCD
select HAS_DEVICE_TREE
select HAS_MEM_ACCESS
select HAS_PASSTHROUGH
select HAS_PDX
-   select VIDEO
 
 config ARCH_DEFCONFIG
string
diff --git a/xen/arch/arm/platforms/vexpress.c 
b/xen/arch/arm/platforms/vexpress.c
index 70839d6..b6193f7 100644
--- a/xen/arch/arm/platforms/vexpress.c
+++ b/xen/arch/arm/platforms/vexpress.c
@@ -59,41 +59,6 @@ static inline int vexpress_ctrl_start(uint32_t *syscfg, int 
write,
 return 0;
 }
 
-int vexpress_syscfg(int write, int function, int device, uint32_t *data)
-{
-uint32_t *syscfg = (uint32_t *) FIXMAP_ADDR(FIXMAP_MISC);
-int ret = -1;
-
-set_fixmap(FIXMAP_MISC, maddr_to_mfn(V2M_SYS_MMIO_BASE),
-   PAGE_HYPERVISOR_NOCACHE);
-
-if ( syscfg[V2M_SYS_CFGCTRL/4] & V2M_SYS_CFG_START )
-goto out;
-
-/* clear the complete bit in the V2M_SYS_CFGSTAT status register */
-syscfg[V2M_SYS_CFGSTAT/4] = 0;
-
-if ( write )
-{
-/* write data */
-syscfg[V2M_SYS_CFGDATA/4] = *data;
-
-if ( vexpress_ctrl_start(syscfg, write, function, device) < 0 )
-goto out;
-} else {
-if ( vexpress_ctrl_start(syscfg, write, function, device) < 0 )
-goto out;
-else
-/* read data */
-*data = syscfg[V2M_SYS_CFGDATA/4];
-}
-
-ret = 0;
-out:
-clear_fixmap(FIXMAP_MISC);
-return ret;
-}
-
 /*
  * TODO: Get base address from the device tree
  * See arm,vexpress-reset node
diff --git a/xen/drivers/video/Kconfig b/xen/drivers/video/Kconfig
index 52e8ce6..41ca503 100644
--- a/xen/drivers/video/Kconfig
+++ b/xen/drivers/video/Kconfig
@@ -11,6 +11,3 @@ config VGA
  Enable VGA output for the Xen hypervisor.
 
  If unsure, say Y.
-
-config HAS_ARM_HDLCD
-   bool
diff --git a/xen/drivers/video/Makefile b/xen/drivers/video/Makefile
index 2bb91d6..2b3fc76 100644
--- a/xen/drivers/video/Makefile
+++ b/xen/drivers/video/Makefile
@@ -4,4 +4,3 @@ obj-$(CONFIG_VIDEO) += font_8x16.o
 obj-$(CONFIG_VIDEO) += font_8x8.o
 obj-$(CONFIG_VIDEO) += lfb.o
 obj-$(CONFIG_VGA) += vesa.o
-obj-$(CONFIG_HAS_ARM_HDLCD) += arm_hdlcd.o
diff --git a/xen/drivers/video/arm_hdlcd.c b/xen/drivers/video/arm_hdlcd.c
deleted file mode 100644
index e1174b2..000
--- a/xen/drivers/video/arm_hdlcd.c
+++ /dev/null
@@ -1,281 +0,0 @@
-/*
- * xen/drivers/video/arm_hdlcd.c
- *
- * Driver for ARM HDLCD Controller
- *
- * Stefano Stabellini 
- * Copyright (c) 2013 Citrix Systems.
- *
- * 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; either version 2 of the License, or
- * (at your option) any later version.
- *
- * 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.
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include "font.h"
-#include "lfb.h"
-#include "modelines.h"
-
-#define HDLCD ((volatile uint32_t *) FIXMAP_ADDR(FIXMAP_MISC))
-
-#define HDLCD_INTMASK   (0x18/4)
-#define HDLCD_FBBASE(0x100/4)
-#define HDLCD_LINELENGTH(0x104/4)
-#define HDLCD_LINECOUNT (0x108/4)
-#define HDLCD_LINEPITCH (0x10C/4)
-#define HDLCD_BUS   (0x110/4)
-#define HDLCD_VSYNC (0x200/4)
-#define HDLCD_VBACK (0x204/4)
-#define HDLCD_VDATA (0x208/4)
-#define HDLCD_VFRONT(0x20C/4)
-#define HDLCD_HSYNC (0x210/4)
-#define HDLCD_HBACK (0x214/4)
-#define HDLCD_HDATA (0x218/4)
-#define HDLCD_HFRONT(0x21C/4)
-#define HDLCD_POLARITIES(0x220/4)
-#define HDLCD_COMMAND   

[Xen-devel] [PATCH v3 08/10] arm: add a tiny kconfig configuration

[Stefano Stabellini]

Add a tiny kconfig configuration. Enabled NULL and Credit schedulers.
Support only 4 cpus. It only carries non-default options (use make
olddefconfig to produce a complete .config file).

Signed-off-by: Stefano Stabellini 
---
 xen/arch/arm/configs/tiny.conf | 44 ++
 1 file changed, 44 insertions(+)
 create mode 100644 xen/arch/arm/configs/tiny.conf

diff --git a/xen/arch/arm/configs/tiny.conf b/xen/arch/arm/configs/tiny.conf
new file mode 100644
index 000..13e67d2
--- /dev/null
+++ b/xen/arch/arm/configs/tiny.conf
@@ -0,0 +1,44 @@
+CONFIG_ARM_64=y
+CONFIG_ARM=y
+
+#
+# Architecture Features
+#
+CONFIG_NR_CPUS=4
+# CONFIG_GICV3 is not set
+# CONFIG_MEM_ACCESS is not set
+# CONFIG_SBSA_VUART_CONSOLE is not set
+
+#
+# Common Features
+#
+# CONFIG_TMEM is not set
+
+#
+# Schedulers
+#
+# CONFIG_SCHED_CREDIT2 is not set
+# CONFIG_SCHED_RTDS is not set
+# CONFIG_SCHED_ARINC653 is not set
+CONFIG_SCHED_NULL=y
+CONFIG_SCHED_NULL_DEFAULT=y
+CONFIG_SCHED_DEFAULT="null"
+# CONFIG_SUPPRESS_DUPLICATE_SYMBOL_WARNINGS is not set
+
+#
+# Device Drivers
+#
+# CONFIG_NS16550 is not set
+# CONFIG_CADENCE_UART is not set
+# CONFIG_MVEBU is not set
+# CONFIG_PL011 is not set
+# CONFIG_SCIF is not set
+# CONFIG_ARM_SMMU is not set
+
+#
+# Debugging Options
+#
+# CONFIG_DEBUG is not set
+# CONFIG_FRAME_POINTER is not set
+# CONFIG_VERBOSE_DEBUG is not set
+# CONFIG_SCRUB_DEBUG is not set
-- 
1.9.1


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

[Xen-devel] [PATCH v3 09/10] arm: add QEMU, Rcar3 and MPSoC configs

[Stefano Stabellini]

Add a "Platform Support" menu with three umbrella kconfig options: QEMU,
RCAR3 and MPSOC. They enable the required options for their hardware
platform.

They are introduced for convience: the user will be able to simply open
the menu and enable the right config for her platform.

Signed-off-by: Stefano Stabellini 
CC: artem_myga...@epam.com
CC: volodymyr_babc...@epam.com

---
Note that this approach has a limitation: it is not possible to "select
a range". In other words, using tiny.config NR_CPUS is set to 4. It is
not possible to increase it to 8 from config RCAR3.

Suggestions are welcome.
---
 xen/arch/arm/Kconfig   |  2 ++
 xen/arch/arm/platforms/Kconfig | 30 ++
 2 files changed, 32 insertions(+)
 create mode 100644 xen/arch/arm/platforms/Kconfig

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index a5a6943..b5ddd12 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -245,6 +245,8 @@ config ARM64_HARDEN_BRANCH_PREDICTOR
 config ARM32_HARDEN_BRANCH_PREDICTOR
 def_bool y if ARM_32 && HARDEN_BRANCH_PREDICTOR
 
+source "arch/arm/platforms/Kconfig"
+
 source "common/Kconfig"
 
 source "drivers/Kconfig"
diff --git a/xen/arch/arm/platforms/Kconfig b/xen/arch/arm/platforms/Kconfig
new file mode 100644
index 000..0eafbef
--- /dev/null
+++ b/xen/arch/arm/platforms/Kconfig
@@ -0,0 +1,30 @@
+menu "Platform Support"
+
+config QEMU
+   bool "QEMU aarch virt machine support"
+   default n
+   depends on ARM_64
+   select GICv3
+   select PL011
+   ---help---
+   Enable all the required drivers for QEMU aarch64 virt emulated
+   machine.
+
+config RCAR3
+   bool "Renesas RCar3 support"
+   default n
+   depends on ARM_64
+   select SCIF
+   ---help---
+   Enable all the required drivers for Renesas RCar3
+
+config MPSOC
+   bool "Xilinx Ultrascale+ MPSoC support"
+   default n
+   depends on ARM_64
+   select CADENCE_UART
+   select ARM_SMMU
+   ---help---
+   Enable all the required drivers for Xilinx Ultrascale+ MPSoC
+
+endmenu
-- 
1.9.1


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

Re: [Xen-devel] [PATCH v2 08/10] arm: add a small kconfig for Renesas RCar H3

[Stefano Stabellini]

On Tue, 22 May 2018, Julien Grall wrote:
> Hi,
> 
> On 22/05/2018 22:00, Stefano Stabellini wrote:
> > On Tue, 22 May 2018, Julien Grall wrote:
> > > Hi,
> > > 
> > > On 05/22/2018 01:53 AM, Stefano Stabellini wrote:
> > > > This is a reference tiny kconfig for Renesas RCar.  In terms of
> > > > schedulers, it selects credit and NULL only.  It enables all the ARM64
> > > > errata.
> > > 
> > > It still does not feel right that you select only credit and NULL. Why not
> > > credit2 and NULL? Or other combination.
> > 
> > We have to pick a combination of options for certifications and this is
> > the one I am proposing: we need the null scheduler for latency sensitive
> > mission critical VMs and we need credit (the default today) for the
> > others.
> > 
> > I am happy to discuss the pros and cons of other combinations.
> 
> The .config is very subjective and I don't think we can possible cater
> everyone here. For instance, someone might want a different .config for that
> board with credit2... If someone ask for adding this option, what would you
> answer to them? You can't turn them down because this .config is for
> certification.
> 
> But I don't think your solution is the right way to go. See more below for
> some suggestion.
> 
> > 
> >   
> > > > Signed-off-by: Stefano Stabellini 
> > > > CC: artem_myga...@epam.com
> > > > CC: volodymyr_babc...@epam.com
> > > > 
> > > > ---
> > > > 
> > > > This patch is untested on Renesas RCar, please test!
> > > > Also, I am not sure whether some of the errata workarounds can be
> > > > disabled on the RCar.
> > > > 
> > > > Changes in v2:
> > > > - rename to rcar3
> > > > - only add required symbols, let the defauls take care of the rest
> > > 
> > > I am not sure what you mean here. Your .config below seems contains all
> > > the
> > > options including the non-selected one.
> > > 
> > > Also, this still not solving the problem raised by Andrew regarding keep
> > > them
> > > updated.
> > 
> > It does not have all the options: it only contains the non-default
> > options as per Juergen's suggestion:
> > 
> > https://marc.info/?l=xen-devel=152419926530183
> 
> Are you sure? For instance, CONFIG_ACPI is turned off by default but still
> present in the .config. Maybe I am missing something.

That was my mistake.  The process of removing everything but the
non-default options was manual, I might have missed a couple of other
things. I don't know if there is a better way.


> > > It might be easier to maintain if we provide a per platform config option
> > > (e.g
> > > CONFIG_RCAR3) that will select driver for that specific board.
> > > 
> > > The user is then free to select other components (e.g scheduler...). So
> > > you
> > > don't impose memaccess disabled, NULL scheduler...
> > > 
> > > (Thank you Andrii for the suggestion!)
> > 
> > This is a good idea, it would be great to have CONFIG_RCAR3, but it does
> > not take away the need for this kconfig. CONFIG_RCAR3 and rcar3.config
> > are orthogonal, let me explain.
> > 
> > Let's say that we have a CONFIG_RCAR3 that selects everything needed for
> > the Rcar3, such as:
> > 
> > NR_CPUS, SCIF
> > 
> > and deselects:
> > 
> > ACPI, GICV3, the other UARTs, ARM_SMMU.
> > 
> > We still need a reference kconfig with other not platform specific
> > options, for instance:
> > 
> > SCHED_NULL
> > 
> > For two reasons:
> > 1) we need a reference kconfig for certifications, it has to include the
> > choice of schedulers, debug options, etc, which are not Rcar3 specific
> 
> As you said it is not Rcar3 specific. So this would have to be duplicated on
> each .config (QEMU...).
> 
> It really feels like we want some sort of partial .config (similar to what
> Linux has [1]) that will select non-specific platform option. We could have a
> tiny one, certifiable, "all", server...

Uhm... This is a good suggestion! Following on this line of thinking, is
the idea that the user would:

1) cp configs/certifiable.config .config
2) make olddefconfig # this set to default any missing options
3) make menuconfig -> enable CONFIG_RCAR3
4) make

?

This way, tiny.config doesn't have to have all options, only the
non-default. CONFIG_RCAR3 takes care of enabling the platform specific
stuff.

This could actually work :-)


> > 2) as per previous discussions, we need a set of pre-canned kconfigs to
> > establish what we security support
> > 
> > rcar3.config is meant to address these two points. CONFIG_RCAR3 would
> > not take away the need for rcar3.config, but it would make rcar3.config
> > shorter and easier to maintain.
> > 
> > CONFIG_RCAR3 was not on my roadmap but I'll see what I can do. Maybe it
> > is best if I do the work for QEMU only (both CONFIG_QEMU and
> > qemu.config) and leave the Renesas work (both CONFIG_RCAR3 and
> > rcar3.config) to EPAM. I cannot test it anyway.
> > 
> 
> Cheers,
> 
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/configs

Re: [Xen-devel] [PATCH v2 06/10] xen: remove HAS_ prefix from UART Kconfig options

[Stefano Stabellini]

On Tue, 22 May 2018, Jan Beulich wrote:
> >>> Stefano Stabellini  05/22/18 2:53 AM >>>
> >UART drivers are now selectable by the user. To mark the change, remove
> >the HAS_ prefix.
> 
> Same comment as on patch 3.

I'll do. That will also solve your comments to the previous patch in a
cleaner way.

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

Re: [Xen-devel] Test for osstest, features used in Qubes OS

[Simon Gaiser]

George Dunlap:
> On Fri, May 18, 2018 at 5:19 PM, Marek Marczykowski
>  wrote:
>> On Fri, May 18, 2018 at 09:54:37AM -0600, Jan Beulich wrote:
>> On 18.05.18 at 17:33,  wrote:
 Yes, I'm happy to help with that. As I've said, the basic test is very
 simple (rtcwake command) and already very useful. The fact that it is(?)
 broken on staging doesn't make it easier,
>>>
>>> Details on the breakage would be appreciated (on a separate thread),
>>> unless you plan to address it yourself. I recall Simon(?) mentioning this as
>>> well, but also not providing sufficient data to consider looking into it
>>> (perhaps simply because it wasn't easy to obtain useful data, as
>>> frequently is the case with S3 resume). I think it would be nice if we could
>>> release 4.11 without a regression here.
>>
>> I only know that Simon have tested it and it fails. Cc'ing him.

I run into the same problem as George below (see [1] for the inital
report).

> Well I tried it with a post-RC 4.11 and got the below.  I haven't done
> any investigation.
> 
>  -George
> 
[...]
> (XEN) *** DOUBLE FAULT ***
> (XEN) [ Xen-4.11-rc  x86_64  debug=y   Not tainted ]
> (XEN) CPU:0
> (XEN) RIP:e008:[] handle_exception+0x9c/0xf7
> (XEN) RFLAGS: 00010006   CONTEXT: hypervisor
> (XEN) rax: c900422480b8   rbx:    rcx: 0005
> (XEN) rdx:    rsi:    rdi: 
> (XEN) rbp: 36ffbddb7f27   rsp: c90042248000   r8:  
> (XEN) r9:     r10:    r11: 
> (XEN) r12:    r13:    r14: c9004224
> (XEN) r15:    cr0: 8005003b   cr4: 26e0
> (XEN) cr3: 00018a10   cr2: c90042247ff8
> (XEN) fsb: 7f6242d95700   gsb: 88003dc0   gss: 
> (XEN) ds:    es:    fs:    gs:    ss: e010   cs: e008
> (XEN) Current stack base c90042248000 differs from expected 
> 8300dfa8
> (XEN) Valid stack range: c9004224e000-c9004225,
> sp=c90042248000, tss.rsp0=8300dfa87fa0
> (XEN) No stack overflow detected. Skipping stack trace.
> (XEN)
> (XEN) 
> (XEN) Panic on CPU 0:
> (XEN) DOUBLE FAULT -- system shutdown
> (XEN) 
> (XEN)
> (XEN) Reboot in five seconds...

I have done some more testing in the meantime. The issue also affect
4.10.1, but not 4.10.0. That's useful since it makes the bisect shorter.
A bisect identifies 8462c575d9 "x86/xpti: Hide almost all of .text and
all .data/.rodata/.bss mappings" as the commit which breaks suspend.

8462c575d9 is a squashed backport of:

  422588e885 x86/xpti: Hide almost all of .text and all .data/.rodata/.bss 
mappings
  d1d6fc97d6 x86/xpti: really hide almost all of Xen image
  044fedfaa2 x86/traps: Put idt_table[] back into .bss

And indeed, reverting those on staging fixes suspend. (This also matches
the behavior that xpti=off fixes suspend as George already reported
earlier today).

[1]: https://lists.xenproject.org/archives/html/xen-devel/2018-04/msg01137.html



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2 03/10] Rename HAS_MEM_ACCESS to MEM_ACCESS

[Stefano Stabellini]

On Tue, 22 May 2018, Jan Beulich wrote:
> >>> Stefano Stabellini  05/22/18 2:53 AM >>>
> >HAS_MEM_ACCESS has become selectable by the user on ARM32 and ARM64. To
> >mark the change, rename the option from HAS_MEM_ACCESS to MEM_ACCESS.
> 
> I have a different suggestion, a model used (iirc) in a couple of places in 
> Linux:
> The feature controlling option is, as you make it here, MEM_ACCESS. It should
> live in a non-arch-specific Kconfig though, and should be controlled by two 
> further
> options: HAS_MEM_ACCESS (telling whether the arch actually is capable of
> doing this, i.e. MEM_ACCESS to depend on it) and something like
> MEM_ACCESS_ALWAYS_ON (telling whether the prompt should be hidden and,
> if the default with prompt enabled was "no", also controlling the default).

I like this suggestion very much, I'll do that.

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

Re: [Xen-devel] [PATCH v2 08/10] arm: add a small kconfig for Renesas RCar H3

[Julien Grall]

Hi,

On 22/05/2018 22:00, Stefano Stabellini wrote:

On Tue, 22 May 2018, Julien Grall wrote:

Hi,

On 05/22/2018 01:53 AM, Stefano Stabellini wrote:

This is a reference tiny kconfig for Renesas RCar.  In terms of
schedulers, it selects credit and NULL only.  It enables all the ARM64
errata.


It still does not feel right that you select only credit and NULL. Why not
credit2 and NULL? Or other combination.


We have to pick a combination of options for certifications and this is
the one I am proposing: we need the null scheduler for latency sensitive
mission critical VMs and we need credit (the default today) for the
others.

I am happy to discuss the pros and cons of other combinations.


The .config is very subjective and I don't think we can possible cater 
everyone here. For instance, someone might want a different .config for 
that board with credit2... If someone ask for adding this option, what 
would you answer to them? You can't turn them down because this .config 
is for certification.


But I don't think your solution is the right way to go. See more below 
for some suggestion.




  

Signed-off-by: Stefano Stabellini 
CC: artem_myga...@epam.com
CC: volodymyr_babc...@epam.com

---

This patch is untested on Renesas RCar, please test!
Also, I am not sure whether some of the errata workarounds can be
disabled on the RCar.

Changes in v2:
- rename to rcar3
- only add required symbols, let the defauls take care of the rest


I am not sure what you mean here. Your .config below seems contains all the
options including the non-selected one.

Also, this still not solving the problem raised by Andrew regarding keep them
updated.


It does not have all the options: it only contains the non-default
options as per Juergen's suggestion:

https://marc.info/?l=xen-devel=152419926530183


Are you sure? For instance, CONFIG_ACPI is turned off by default but 
still present in the .config. Maybe I am missing something.






It might be easier to maintain if we provide a per platform config option (e.g
CONFIG_RCAR3) that will select driver for that specific board.

The user is then free to select other components (e.g scheduler...). So you
don't impose memaccess disabled, NULL scheduler...

(Thank you Andrii for the suggestion!)


This is a good idea, it would be great to have CONFIG_RCAR3, but it does
not take away the need for this kconfig. CONFIG_RCAR3 and rcar3.config
are orthogonal, let me explain.

Let's say that we have a CONFIG_RCAR3 that selects everything needed for
the Rcar3, such as:

NR_CPUS, SCIF

and deselects:

ACPI, GICV3, the other UARTs, ARM_SMMU.

We still need a reference kconfig with other not platform specific
options, for instance:

SCHED_NULL

For two reasons:
1) we need a reference kconfig for certifications, it has to include the
choice of schedulers, debug options, etc, which are not Rcar3 specific


As you said it is not Rcar3 specific. So this would have to be 
duplicated on each .config (QEMU...).


It really feels like we want some sort of partial .config (similar to 
what Linux has [1]) that will select non-specific platform option. We 
could have a tiny one, certifiable, "all", server...



2) as per previous discussions, we need a set of pre-canned kconfigs to
establish what we security support

rcar3.config is meant to address these two points. CONFIG_RCAR3 would
not take away the need for rcar3.config, but it would make rcar3.config
shorter and easier to maintain.

CONFIG_RCAR3 was not on my roadmap but I'll see what I can do. Maybe it
is best if I do the work for QEMU only (both CONFIG_QEMU and
qemu.config) and leave the Renesas work (both CONFIG_RCAR3 and
rcar3.config) to EPAM. I cannot test it anyway.



Cheers,

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/configs


--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 08/10] arm: add a small kconfig for Renesas RCar H3

[Stefano Stabellini]

On Tue, 22 May 2018, Julien Grall wrote:
> Hi,
> 
> On 05/22/2018 01:53 AM, Stefano Stabellini wrote:
> > This is a reference tiny kconfig for Renesas RCar.  In terms of
> > schedulers, it selects credit and NULL only.  It enables all the ARM64
> > errata.
> 
> It still does not feel right that you select only credit and NULL. Why not
> credit2 and NULL? Or other combination.

We have to pick a combination of options for certifications and this is
the one I am proposing: we need the null scheduler for latency sensitive
mission critical VMs and we need credit (the default today) for the
others.

I am happy to discuss the pros and cons of other combinations.

 
> > Signed-off-by: Stefano Stabellini 
> > CC: artem_myga...@epam.com
> > CC: volodymyr_babc...@epam.com
> > 
> > ---
> > 
> > This patch is untested on Renesas RCar, please test!
> > Also, I am not sure whether some of the errata workarounds can be
> > disabled on the RCar.
> > 
> > Changes in v2:
> > - rename to rcar3
> > - only add required symbols, let the defauls take care of the rest
> 
> I am not sure what you mean here. Your .config below seems contains all the
> options including the non-selected one.
>
> Also, this still not solving the problem raised by Andrew regarding keep them
> updated.

It does not have all the options: it only contains the non-default
options as per Juergen's suggestion:

https://marc.info/?l=xen-devel=152419926530183


> It might be easier to maintain if we provide a per platform config option (e.g
> CONFIG_RCAR3) that will select driver for that specific board.
> 
> The user is then free to select other components (e.g scheduler...). So you
> don't impose memaccess disabled, NULL scheduler...
> 
> (Thank you Andrii for the suggestion!)

This is a good idea, it would be great to have CONFIG_RCAR3, but it does
not take away the need for this kconfig. CONFIG_RCAR3 and rcar3.config
are orthogonal, let me explain.

Let's say that we have a CONFIG_RCAR3 that selects everything needed for
the Rcar3, such as:

NR_CPUS, SCIF

and deselects:

ACPI, GICV3, the other UARTs, ARM_SMMU.

We still need a reference kconfig with other not platform specific
options, for instance:

SCHED_NULL

For two reasons:
1) we need a reference kconfig for certifications, it has to include the
   choice of schedulers, debug options, etc, which are not Rcar3 specific
2) as per previous discussions, we need a set of pre-canned kconfigs to
   establish what we security support

rcar3.config is meant to address these two points. CONFIG_RCAR3 would
not take away the need for rcar3.config, but it would make rcar3.config
shorter and easier to maintain.

CONFIG_RCAR3 was not on my roadmap but I'll see what I can do. Maybe it
is best if I do the work for QEMU only (both CONFIG_QEMU and
qemu.config) and leave the Renesas work (both CONFIG_RCAR3 and
rcar3.config) to EPAM. I cannot test it anyway.

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt 12 guest-start  fail REGR. vs. 118324
 test-armhf-armhf-libvirt-raw 10 debian-di-installfail REGR. vs. 118324
 test-armhf-armhf-xl-credit2   7 xen-boot fail REGR. vs. 118324
 test-armhf-armhf-xl-multivcpu 10 debian-install  fail REGR. vs. 118324
 test-armhf-armhf-xl-xsm  10 debian-install   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-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 118324
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 118324
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 118324
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail 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-i386-xl-pvshim12 guest-start  fail   never pass
 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-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  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-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-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-amd64-amd64-libvirt-vhd 12 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  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-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:
 linux203ec2fed17ade9582277570eb234be52085f8c5
baseline version:
 linux5b7d27967dabfb17c21b0d98b29153b9e3ee71e5

Last test of basis   118324  2018-01-25 07:31:24 Z  117 days
Failing since118362  2018-01-26 16:56:17 Z  116 days   87 attempts
Testing same since   122982  2018-05-20 08:59:43 Z2 days1 attempts


3497 people touched revisions under test,
not listing them all

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  

Re: [Xen-devel] [PATCH v2 02/10] arm: make it possible to disable more kconfig options

[Stefano Stabellini]

On Tue, 22 May 2018, Julien Grall wrote:
> On 05/22/2018 01:53 AM, Stefano Stabellini wrote:
> > Make it possible to disable the following existing kconfig options:
> >HAS_GICV3
> >HAS_MEM_ACCESS
> > 
> > Today they are silent option. This patch adds one line descriptions and
> > make them de/selectable.
> > 
> > Also, do not select VIDEO.
> > 
> > Signed-off-by: Stefano Stabellini 
> > 
> > ---
> > Changes in v2:
> > - make HAS_GICv3 depend on ARM_64
> > - remove modifications to ARM_HDLCD kconfig, it has been removed
> > ---
> >   xen/arch/arm/Kconfig | 15 ---
> >   1 file changed, 12 insertions(+), 3 deletions(-)
> > 
> > diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> > index cbd9f1b..0b22cfa 100644
> > --- a/xen/arch/arm/Kconfig
> > +++ b/xen/arch/arm/Kconfig
> > @@ -12,16 +12,13 @@ config ARM_32
> >   config ARM_64
> > def_bool y
> > depends on 64BIT
> > -   select HAS_GICV3
> > config ARM
> > def_bool y
> > select HAS_ALTERNATIVE
> > select HAS_DEVICE_TREE
> > -   select HAS_MEM_ACCESS
> > select HAS_PASSTHROUGH
> > select HAS_PDX
> > -   select VIDEO
> > config ARCH_DEFCONFIG
> > string
> > @@ -43,6 +40,18 @@ config ACPI
> > config HAS_GICV3
> > bool
> > +   prompt "GICv3 driver"
> > +   depends on ARM_64
> > +   default y
> 
> All the new options should have a description.

Yes, I'll add a description


> > +
> > +config HAS_MEM_ACCESS
> > +   bool
> > +   prompt "Memory Access and VM events"
> > +   default y
> > +   ---help---
> > +
> > + Framework to configure memory access types for guests and receive
> > + related events in userspace.
> > config HAS_ITS
> >   bool
> > 
> 
> -- 
> Julien Grall
> 

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

Re: [Xen-devel] [PATCH v2 02/10] arm: make it possible to disable more kconfig options

[Stefano Stabellini]

On Tue, 22 May 2018, Julien Grall wrote:
> Hi,
> 
> On 05/22/2018 01:53 AM, Stefano Stabellini wrote:
> > Make it possible to disable the following existing kconfig options:
> >HAS_GICV3
> >HAS_MEM_ACCESS
> > 
> > Today they are silent option. This patch adds one line descriptions and
> > make them de/selectable.
> > 
> > Also, do not select VIDEO.
> 
> IHMO, this belongs to patch #1.

You are right, I made the change.

> > 
> > Signed-off-by: Stefano Stabellini 
> > 
> > ---
> > Changes in v2:
> > - make HAS_GICv3 depend on ARM_64
> > - remove modifications to ARM_HDLCD kconfig, it has been removed
> > ---
> >   xen/arch/arm/Kconfig | 15 ---
> >   1 file changed, 12 insertions(+), 3 deletions(-)
> > 
> > diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> > index cbd9f1b..0b22cfa 100644
> > --- a/xen/arch/arm/Kconfig
> > +++ b/xen/arch/arm/Kconfig
> > @@ -12,16 +12,13 @@ config ARM_32
> >   config ARM_64
> > def_bool y
> > depends on 64BIT
> > -   select HAS_GICV3
> > config ARM
> > def_bool y
> > select HAS_ALTERNATIVE
> > select HAS_DEVICE_TREE
> > -   select HAS_MEM_ACCESS
> > select HAS_PASSTHROUGH
> > select HAS_PDX
> > -   select VIDEO
> > config ARCH_DEFCONFIG
> > string
> > @@ -43,6 +40,18 @@ config ACPI
> > config HAS_GICV3
> > bool
> > +   prompt "GICv3 driver"
> > +   depends on ARM_64
> > +   default y
> > +
> > +config HAS_MEM_ACCESS
> > +   bool
> > +   prompt "Memory Access and VM events"
> > +   default y
> > +   ---help---
> > +
> > + Framework to configure memory access types for guests and receive
> > + related events in userspace.
> 
> See my reply on v1 of this patch.

I replied there. I would prefer to keep it. At least, I would like to do
the renaming of HAS_MEM_ACCESS to MEM_ACCESS as part of this series to
make my work easier.

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

Re: [Xen-devel] [PATCH 1/6] arm: make it possible to disable more kconfig options

[Stefano Stabellini]

On Tue, 22 May 2018, Julien Grall wrote:
> Hi,
> 
> On 05/21/2018 08:58 PM, Stefano Stabellini wrote:
> > On Thu, 19 Apr 2018, Julien Grall wrote:
> > > > +
> > > > +config HAS_MEM_ACCESS
> > > > +   bool
> > > > +   prompt "Memory Access and VM events"
> > > > +   default y
> > > 
> > > Most of the memaccess code is not protected by HAS_MEM_ACCESS.  So you are
> > > going to drop just a couple of hundreds line. Not sure if it is worth it
> > > in
> > > the actual state.
> > 
> > Yes, the LOC count it is not worth it today, but I would still like to
> > make it selectable because I don't want Xen to come to rely on having
> > HAS_MEM_ACCESS enabled all the time. !MEM_ACCESS is a good and valid
> > configuration. Also, we can go forward in making more stuff protected by
> > HAS_MEM_ACCESS soon.
> 
> The common code already doesn't rely on memaccess thanks to when Arm was not
> support it. While I agree that we don't want HAS_MEM_ACCESS enabled all the
> time, I question the usefulness of that possibility today. What you are going
> to remove is about ~150 lines of pumbling to the userspace. That's it.
> 
> All the meat (and complexity) of memaccess is still here (~500 lines). You can
> achieve the same situation with using XSM. So I don't see the real benefits of
> it here.
> 
> It would be better to first guard all memaccess code and then expose the
> config if we still think it is useful.

I am happy to hear that you also don't want HAS_MEM_ACCESS enabled all
the time. Then, it is just a question on when and how. Given that I am
doing kconfig changes now, I prefer to do them all at once, then move to
adding more #define (which I definitely intend to do next). It is very
easy to break these patches, they don't rebase easily, especially the
HAS_MEM_ACCESS rename. This is why I would prefer to make MEM_ACCES
optional as part of this series.

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

Re: [Xen-devel] [PATCH v2 07/10] arm: make it possible to disable the SMMU driver

[Stefano Stabellini]

On Tue, 22 May 2018, Jan Beulich wrote:
> >--- a/xen/drivers/passthrough/Kconfig
> >+++ b/xen/drivers/passthrough/Kconfig
> >@@ -1,3 +1,11 @@
>  >
> >config HAS_PASSTHROUGH
> >bool
> >+
> >+config SMMUv2
> >+bool "ARM SMMUv1 and v2 driver"
> >+default y
> >+depends on ARM
> 
> Anticipating further additions here, I would prefer the "if ARM" form, but as 
> it
> doesn't really matter right now I won't insist.

I'll make the change

 
> >--- a/xen/drivers/passthrough/arm/Makefile
> >+++ b/xen/drivers/passthrough/arm/Makefile
> >@@ -1,2 +1,2 @@
> >obj-y += iommu.o
> >-obj-y += smmu.o
> >+obj-$(SMMUv2) += smmu.o
> 
> Is iommu.o in any way useful without smmu.o?

Things like iommu_domain_init are called unconditionally from ARM code
at the moment, it is not quite possible to skip compilation today. Also,
it is small, so it is not worth it I think.

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

Re: [Xen-devel] [PATCH v2 07/10] arm: make it possible to disable the SMMU driver

[Stefano Stabellini]

On Tue, 22 May 2018, Julien Grall wrote:
> Hi,
> 
> On 05/22/2018 01:53 AM, Stefano Stabellini wrote:
> > Introduce a Kconfig option for the ARM SMMUv1 and SMMUv2 driver.
> > 
> > Signed-off-by: Stefano Stabellini 
> > CC: jbeul...@suse.com
> > 
> > ---
> > Changes in v2:
> > - rename HAS_SMMUv2 to SMMUv2
> > - move SMMUv2 to xen/drivers/passthrough/Kconfig
> > ---
> >   xen/drivers/passthrough/Kconfig  | 8 
> >   xen/drivers/passthrough/arm/Makefile | 2 +-
> >   2 files changed, 9 insertions(+), 1 deletion(-)
> > 
> > diff --git a/xen/drivers/passthrough/Kconfig
> > b/xen/drivers/passthrough/Kconfig
> > index 8d90b67..9bdce65 100644
> > --- a/xen/drivers/passthrough/Kconfig
> > +++ b/xen/drivers/passthrough/Kconfig
> > @@ -1,3 +1,11 @@
> > config HAS_PASSTHROUGH
> > bool
> > +
> > +config SMMUv2
> 
> It would make sense to have ARM in the name because there are other using SMMU
> in their device name (see Tegra). Furthermore this is not only v2 specific.
> 
> A better name would be ARM_SMMU.
> 
> > +   bool "ARM SMMUv1 and v2 driver"
> > +   default y
> > +   depends on ARM
> > +   ---help---
> > + Driver for the ARM SMMU version 1 and 2, a popular IOMMU by
> > + ARM.
> 
> The driver enables support for any IOMMU based on the ARM System MMU
> architecture versions 1 and 2. ARM provides implementation (SMMU-400,
> SMMU-401, SMMU-500 & co) but there are other existing in the wild (e.g Cavium
> one).
> 
> Also, in general it would be useful to state why someone would want to enable
> a driver. So I would rework this message as:
> 
> "Support for implementations of the ARM System MMU architecture versions 1 and
> 2.
> 
> Say Y here if your SoC includes an IOMMU device implementing the ARM SMMU
> architecture".

I'll use ARM_SMMU and use your suggestion for the help message.

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

Re: [Xen-devel] [PATCH v2 01/10] arm: remove the ARM HDLCD driver

[Stefano Stabellini]

On Tue, 22 May 2018, Julien Grall wrote:
> Hi Stefano,
> 
> On 05/22/2018 01:53 AM, Stefano Stabellini wrote:
> > The ARM HDLCD driver is unused. The device itself can only be found on
> > Virtual Express boards that are for early development only. Remove the
> > driver.
> > 
> > Suggested-by: Julien Grall 
> > Signed-off-by: Stefano Stabellini 
> > ---
> > Changes in v2:
> > - patch added
> > ---
> >   xen/arch/arm/Kconfig  |   1 -
> >   xen/drivers/video/Kconfig |   3 -
> >   xen/drivers/video/Makefile|   1 -
> >   xen/drivers/video/arm_hdlcd.c | 281
> > --
> >   4 files changed, 286 deletions(-)
> >   delete mode 100644 xen/drivers/video/arm_hdlcd.c
> > 
> > diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> > index 8174c0c..cbd9f1b 100644
> > --- a/xen/arch/arm/Kconfig
> > +++ b/xen/arch/arm/Kconfig
> > @@ -17,7 +17,6 @@ config ARM_64
> >   config ARM
> > def_bool y
> > select HAS_ALTERNATIVE
> > -   select HAS_ARM_HDLCD
> 
> As you drop this, you might also want to remove "select VIDEO" below
> 
> You probably want to remove "select VIDEO" below and remove vexpress_syscfg
> that only exists for vexpress.

Good suggestions, I'll make the changes

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

[Xen-devel] [PATCH] tools/kdd: alternative way of muting spurious gcc warning

[Marek Marczykowski-Górecki]

Older gcc does not support #pragma GCC diagnostics, so use alternative
approach - change variable type to uint32_t (this code handle 32-bit
requests only anyway), which apparently also avoid gcc complaining about
this (otherwise correct) code.

Fixes 437e00fea04becc91c1b6bc1c0baa636b067a5cc "tools/kdd: mute spurious
gcc warning"

Signed-off-by: Marek Marczykowski-Górecki 
---
 tools/debugger/kdd/kdd.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/tools/debugger/kdd/kdd.c b/tools/debugger/kdd/kdd.c
index 61d769ece9..5a019a0a0c 100644
--- a/tools/debugger/kdd/kdd.c
+++ b/tools/debugger/kdd/kdd.c
@@ -687,7 +687,7 @@ static void kdd_handle_read_ctrl(kdd_state *s)
 }
 } else {
 /* 32-bit control-register space starts at 0x[2]cc, for 84 bytes */
-uint64_t offset = addr;
+uint32_t offset = addr;
 if (offset > 0x200)
 offset -= 0x200;
 offset -= 0xcc;
@@ -695,10 +695,7 @@ static void kdd_handle_read_ctrl(kdd_state *s)
 KDD_LOG(s, "Request outside of known control space\n");
 len = 0;
 } else {
-#pragma GCC diagnostic push
-#pragma GCC diagnostic ignored "-Warray-bounds"
 memcpy(buf, ((uint8_t *)) + offset, len);
-#pragma GCC diagnostic pop
 }
 }
 
-- 
2.13.6


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

Re: [Xen-devel] [PATCH] tools/kdd: silence gcc 8 warning a different way

[Marek Marczykowski]

On Tue, May 22, 2018 at 11:54:36AM +0100, Wei Liu wrote:
> I have tried to revert 437e00fea04becc91c1b6bc1c0baa636b067a5cc and
> reproduce the gcc 8.1 warning with Arch Linux's gcc 8.1 compiler.
> Strangely it doesn't complain.
> 
> I haven't got a Fedora 28 around (which Marek used). It will take some
> time to set that up.

I've tried it again and it still fails, even on gcc 8.1 on Fedora 28.
Maybe that's about some extra CFLAGS in rpm build environment (there are
quite a few of them, including -fcf-protection -fstack-clash-protection
etc)?

Anyway, I'll send updated patch in a moment (instead of the revert).

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


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

Re: [Xen-devel] [PATCH v2 05/10] arm: make it possible to enable/disable UART drivers

[Stefano Stabellini]

On Tue, 22 May 2018, Jan Beulich wrote:
> >>> Stefano Stabellini  05/22/18 2:53 AM >>>
> >All the UART drivers are silent options. Add one line descriptions so
> >that can be de/selected via menuconfig.
> >
> >Signed-off-by: Stefano Stabellini 
> 
> Please don't forget to Cc maintainers.

You and Andrew will be CCed on this patch from now on


> >--- a/xen/drivers/char/Kconfig
> >+++ b/xen/drivers/char/Kconfig
> >@@ -1,11 +1,11 @@
> >config HAS_NS16550
> >-bool
> >+bool "NS16550 UART driver"
> 
> Here as well as ...
> 
> 
> >@@ -53,7 +53,8 @@ config HAS_SCIF
> >or Renesas R-Car Gen 2/3 based board say Y.
>  >
> >config HAS_EHCI
> >-bool
> >+bool "EHCI UART driver"
> 
> ... here iirc Julien had already pointed out that the drivers should not 
> become
> optional on x86,

I see, not only they should be enabled by default, but it should NOT be
possible to disable them.

I got it, I'll fix.


> i.e. in the former case you want to attach a conditional to the
> prompt while in the latter case I don't see why you add the prompt in the 
> first
> place if you mean to make it x86-specific. Which by itself is questionable
> though: Why would this driver be x86-specific, when so far it (consciously)
> hasn't been? If anything I could see it depend on HAS_PCI.

I'll reply here, but I have read the rest of the thread on this point. I
think we might as well disable it for now on ARM until somebody tells us
that it is useful to have.


> >+depends on x86
> 
> Is Kconfig case-insensitive? The option is X86.

I'll fix

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

Re: [Xen-devel] [PATCHv3] xen: Add EFI_LOAD_OPTION support

[Tamas K Lengyel]

On Tue, May 22, 2018 at 6:24 AM, Jan Beulich  wrote:
 On 21.05.18 at 18:59,  wrote:
>> After closer inspection the problem is with the following line here:
>>
  for ( i = 1; i < argc; ++i )
>>
>> This assumes that argv[0] is the EFI executable filename, which is not
>> true when EFI_LOAD_OPTION is used. That's why in my v3 patch I had the
>> "elo_active" variable to determine whether to start the iteration from
>> 0 or from 1.
>
> How about this one then?
>

Success! Although I have to say it's pretty hard to follow the code
and what it's actually doing. Perhaps adding more comments would be
helpful.

Tamas

>
>
> EFI: add EFI_LOAD_OPTION support
>
> When booting Xen via UEFI the Xen config file can contain multiple
> sections each describing different boot options. It is currently only
> possible to choose which section to boot with if the buffer contains a
> string. UEFI provides a different standard to pass optional arguments
> to an application, and in this patch we make Xen properly parse this
> buffer, thus making it possible to have separate EFI boot options
> present for the different config sections.
>
> Signed-off-by: Tamas K Lengyel 
> Signed-off-by: Jan Beulich 
> ---
> v4: Address my own review comments.
>
> --- unstable.orig/xen/common/efi/boot.c
> +++ unstable/xen/common/efi/boot.c
> @@ -88,6 +88,14 @@ typedef struct _EFI_APPLE_PROPERTIES {
>  EFI_APPLE_PROPERTIES_GETALL GetAll;
>  } EFI_APPLE_PROPERTIES;
>
> +typedef struct _EFI_LOAD_OPTION {
> +UINT32 Attributes;
> +UINT16 FilePathListLength;
> +CHAR16 Description[];
> +} EFI_LOAD_OPTION;
> +
> +#define LOAD_OPTION_ACTIVE  0x0001
> +
>  union string {
>  CHAR16 *w;
>  char *s;
> @@ -275,6 +283,16 @@ static int __init wstrncmp(const CHAR16
>  return n ? *s1 - *s2 : 0;
>  }
>
> +static const CHAR16 *__init wmemchr(const CHAR16 *s, CHAR16 c, UINTN n)
> +{
> +while ( n && *s != c )
> +{
> +--n;
> +++s;
> +}
> +return n ? s : NULL;
> +}
> +
>  static CHAR16 *__init s2w(union string *str)
>  {
>  const char *s = str->s;
> @@ -374,14 +392,58 @@ static void __init PrintErrMesg(const CH
>  }
>
>  static unsigned int __init get_argv(unsigned int argc, CHAR16 **argv,
> -CHAR16 *cmdline, UINTN cmdsize,
> +VOID *data, UINTN size, UINTN *offset,
>  CHAR16 **options)
>  {
> -CHAR16 *ptr = (CHAR16 *)(argv + argc + 1), *prev = NULL;
> +CHAR16 *ptr = (CHAR16 *)(argv + argc + 1), *prev = NULL, *cmdline = NULL;
>  bool prev_sep = true;
>
> -for ( ; cmdsize > sizeof(*cmdline) && *cmdline;
> -cmdsize -= sizeof(*cmdline), ++cmdline )
> +if ( argc )
> +{
> +cmdline = data + *offset;
> +/* EFI_LOAD_OPTION does not supply an image name as first component. 
> */
> +if ( *offset )
> +*argv++ = NULL;
> +}
> +else if ( size > sizeof(*cmdline) && !(size % sizeof(*cmdline)) &&
> +  (wmemchr(data, 0, size / sizeof(*cmdline)) ==
> +   data + size - sizeof(*cmdline)) )
> +{
> +*offset = 0;
> +cmdline = data;
> +}
> +else if ( size > sizeof(EFI_LOAD_OPTION) )
> +{
> +const EFI_LOAD_OPTION *elo = data;
> +/* The minimum size the buffer needs to be. */
> +size_t elo_min = offsetof(EFI_LOAD_OPTION, Description[1]) +
> + elo->FilePathListLength;
> +
> +if ( (elo->Attributes & LOAD_OPTION_ACTIVE) && size > elo_min &&
> + !((size - elo_min) % sizeof(*cmdline)) )
> +{
> +const CHAR16 *desc = elo->Description;
> +const CHAR16 *end = wmemchr(desc, 0,
> +(size - elo_min) / sizeof(*desc) + 
> 1);
> +
> +if ( end )
> +{
> +*offset = elo_min + (end - desc) * sizeof(*desc);
> +if ( (size -= *offset) > sizeof(*cmdline) )
> +{
> +cmdline = data + *offset;
> +/* Cater for the image name as first component. */
> +++argc;
> +}
> +}
> +}
> +}
> +
> +if ( !cmdline )
> +return 0;
> +
> +for ( ; size > sizeof(*cmdline) && *cmdline;
> +size -= sizeof(*cmdline), ++cmdline )
>  {
>  bool cur_sep = *cmdline == L' ' || *cmdline == L'\t';
>
> @@ -1095,15 +1157,17 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SY
>
>  if ( use_cfg_file )
>  {
> +UINTN offset = 0;
> +
>  argc = get_argv(0, NULL, loaded_image->LoadOptions,
> -loaded_image->LoadOptionsSize, NULL);
> +loaded_image->LoadOptionsSize, , NULL);
>  if ( argc > 0 &&
>   efi_bs->AllocatePool(EfiLoaderData,

Re: [Xen-devel] [RFC 1/3] xen/balloon: Allow allocating DMA buffers

[Boris Ostrovsky]

On 05/22/2018 02:27 PM, Oleksandr Andrushchenko wrote:
> On 05/22/2018 09:02 PM, Boris Ostrovsky wrote:
>> On 05/22/2018 11:00 AM, Oleksandr Andrushchenko wrote:
>>> On 05/22/2018 05:33 PM, Boris Ostrovsky wrote:
 On 05/22/2018 01:55 AM, Oleksandr Andrushchenko wrote:
> On 05/21/2018 11:36 PM, Boris Ostrovsky wrote:
>> On 05/21/2018 03:13 PM, Oleksandr Andrushchenko wrote:
>>> On 05/21/2018 09:53 PM, Boris Ostrovsky wrote:
 On 05/21/2018 01:32 PM, Oleksandr Andrushchenko wrote:
> On 05/21/2018 07:35 PM, Boris Ostrovsky wrote:
>> On 05/21/2018 01:40 AM, Oleksandr Andrushchenko wrote:
>>> On 05/19/2018 01:04 AM, Boris Ostrovsky wrote:
 On 05/17/2018 04:26 AM, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
> 
 A commit message would be useful.
>>> Sure, v1 will have it
> Signed-off-by: Oleksandr Andrushchenko
> 
>
>    for (i = 0; i < nr_pages; i++) {
> -    page = alloc_page(gfp);
> -    if (page == NULL) {
> -    nr_pages = i;
> -    state = BP_EAGAIN;
> -    break;
> +    if (ext_pages) {
> +    page = ext_pages[i];
> +    } else {
> +    page = alloc_page(gfp);
> +    if (page == NULL) {
> +    nr_pages = i;
> +    state = BP_EAGAIN;
> +    break;
> +    }
>    }
>    scrub_page(page);
>    list_add(>lru, );
> @@ -529,7 +565,7 @@ static enum bp_state
> decrease_reservation(unsigned long nr_pages, gfp_t gfp)
>    i = 0;
>    list_for_each_entry_safe(page, tmp, , lru) {
>    /* XENMEM_decrease_reservation requires a
> GFN */
> -    frame_list[i++] = xen_page_to_gfn(page);
> +    frames[i++] = xen_page_to_gfn(page);
>      #ifdef CONFIG_XEN_HAVE_PVMMU
>    /*
> @@ -552,18 +588,22 @@ static enum bp_state
> decrease_reservation(unsigned long nr_pages, gfp_t gfp)
>    #endif
>    list_del(>lru);
>    -    balloon_append(page);
> +    if (!ext_pages)
> +    balloon_append(page);
 So what you are proposing is not really ballooning. You are
 just
 piggybacking on existing interfaces, aren't you?
>>> Sort of. Basically I need to
>>> {increase|decrease}_reservation, not
>>> actually
>>> allocating ballooned pages.
>>> Do you think I can simply EXPORT_SYMBOL for
>>> {increase|decrease}_reservation?
>>> Any other suggestion?
>> I am actually wondering how much of that code you end up
>> reusing.
>> You
>> pretty much create new code paths in both routines and common
>> code
>> ends
>> up being essentially the hypercall.
> Well, I hoped that it would be easier to maintain if I modify
> existing
> code
> to support both use-cases, but I am also ok to create new
> routines if
> this
> seems to be reasonable - please let me know
>>   So the question is --- would it make
>> sense to do all of this separately from the balloon driver?
> This can be done, but which driver will host this code then?
> If we
> move from
> the balloon driver, then this could go to either gntdev or
> grant-table.
> What's your preference?
 A separate module?
 Is there any use for this feature outside of your zero-copy DRM
 driver?
>>> Intel's hyper dma-buf (Dongwon/Matt CC'ed), V4L/GPU at least.
>>>
>>> At the time I tried to upstream zcopy driver it was discussed and
>>> decided that
>>> it would be better if I remove all DRM specific code and move it to
>>> Xen drivers.
>>> Thus, this RFC.
>>>
>>> But it can also be implemented as a dedicated Xen dma-buf driver
>>> which
>>> will have all the
>>> code from this RFC + a bit more (char/misc device handling at
>>> least).
>>> This will also require a dedicated user-space library, just like
>>> libxengnttab.so
>>> for gntdev (now I have all new IOCTLs covered there).
>>>
>>> If the idea of a dedicated Xen dma-buf driver seems to be more
>>> attractive we
>>> can work toward this solution. BTW, I do support this idea, but
>>> was not
>>> sure if Xen 

[Xen-devel] [PULL v2 08/15] xen_backend: add grant table helpers

[Stefano Stabellini]

From: Paul Durrant 

This patch adds grant table helper functions to the xen_backend code to
localize error reporting and use of xen_domid.

The patch also defers the call to xengnttab_open() until just before the
initialise method in XenDevOps is invoked. This method is responsible for
mapping the shared ring. No prior method requires access to the grant table.

Signed-off-by: Paul Durrant 
Acked-by: Anthony PERARD 
Signed-off-by: Stefano Stabellini 
---
 hw/xen/xen_backend.c | 123 ++-
 include/hw/xen/xen_backend.h |  33 
 2 files changed, 144 insertions(+), 12 deletions(-)

diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
index 7445b50..50412d6 100644
--- a/hw/xen/xen_backend.c
+++ b/hw/xen/xen_backend.c
@@ -106,6 +106,103 @@ int xen_be_set_state(struct XenDevice *xendev, enum 
xenbus_state state)
 return 0;
 }
 
+void xen_be_set_max_grant_refs(struct XenDevice *xendev,
+   unsigned int nr_refs)
+{
+assert(xendev->ops->flags & DEVOPS_FLAG_NEED_GNTDEV);
+
+if (xengnttab_set_max_grants(xendev->gnttabdev, nr_refs)) {
+xen_pv_printf(xendev, 0, "xengnttab_set_max_grants failed: %s\n",
+  strerror(errno));
+}
+}
+
+void *xen_be_map_grant_refs(struct XenDevice *xendev, uint32_t *refs,
+unsigned int nr_refs, int prot)
+{
+void *ptr;
+
+assert(xendev->ops->flags & DEVOPS_FLAG_NEED_GNTDEV);
+
+ptr = xengnttab_map_domain_grant_refs(xendev->gnttabdev, nr_refs,
+  xen_domid, refs, prot);
+if (!ptr) {
+xen_pv_printf(xendev, 0,
+  "xengnttab_map_domain_grant_refs failed: %s\n",
+  strerror(errno));
+}
+
+return ptr;
+}
+
+void xen_be_unmap_grant_refs(struct XenDevice *xendev, void *ptr,
+ unsigned int nr_refs)
+{
+assert(xendev->ops->flags & DEVOPS_FLAG_NEED_GNTDEV);
+
+if (xengnttab_unmap(xendev->gnttabdev, ptr, nr_refs)) {
+xen_pv_printf(xendev, 0, "xengnttab_unmap failed: %s\n",
+  strerror(errno));
+}
+}
+
+int xen_be_copy_grant_refs(struct XenDevice *xendev,
+   bool to_domain,
+   XenGrantCopySegment segs[],
+   unsigned int nr_segs)
+{
+xengnttab_grant_copy_segment_t *xengnttab_segs;
+unsigned int i;
+int rc;
+
+assert(xendev->ops->flags & DEVOPS_FLAG_NEED_GNTDEV);
+
+xengnttab_segs = g_new0(xengnttab_grant_copy_segment_t, nr_segs);
+
+for (i = 0; i < nr_segs; i++) {
+XenGrantCopySegment *seg = [i];
+xengnttab_grant_copy_segment_t *xengnttab_seg = _segs[i];
+
+if (to_domain) {
+xengnttab_seg->flags = GNTCOPY_dest_gref;
+xengnttab_seg->dest.foreign.domid = xen_domid;
+xengnttab_seg->dest.foreign.ref = seg->dest.foreign.ref;
+xengnttab_seg->dest.foreign.offset = seg->dest.foreign.offset;
+xengnttab_seg->source.virt = seg->source.virt;
+} else {
+xengnttab_seg->flags = GNTCOPY_source_gref;
+xengnttab_seg->source.foreign.domid = xen_domid;
+xengnttab_seg->source.foreign.ref = seg->source.foreign.ref;
+xengnttab_seg->source.foreign.offset =
+seg->source.foreign.offset;
+xengnttab_seg->dest.virt = seg->dest.virt;
+}
+
+xengnttab_seg->len = seg->len;
+}
+
+rc = xengnttab_grant_copy(xendev->gnttabdev, nr_segs, xengnttab_segs);
+
+if (rc) {
+xen_pv_printf(xendev, 0, "xengnttab_copy failed: %s\n",
+  strerror(errno));
+}
+
+for (i = 0; i < nr_segs; i++) {
+xengnttab_grant_copy_segment_t *xengnttab_seg =
+_segs[i];
+
+if (xengnttab_seg->status != GNTST_okay) {
+xen_pv_printf(xendev, 0, "segment[%u] status: %d\n", i,
+  xengnttab_seg->status);
+rc = -1;
+}
+}
+
+g_free(xengnttab_segs);
+return rc;
+}
+
 /*
  * get xen backend device, allocate a new one if it doesn't exist.
  */
@@ -149,18 +246,6 @@ static struct XenDevice *xen_be_get_xendev(const char 
*type, int dom, int dev,
 }
 qemu_set_cloexec(xenevtchn_fd(xendev->evtchndev));
 
-if (ops->flags & DEVOPS_FLAG_NEED_GNTDEV) {
-xendev->gnttabdev = xengnttab_open(NULL, 0);
-if (xendev->gnttabdev == NULL) {
-xen_pv_printf(NULL, 0, "can't open gnttab device\n");
-xenevtchn_close(xendev->evtchndev);
-qdev_unplug(DEVICE(xendev), NULL);
-return NULL;
-}
-} else {
-xendev->gnttabdev = NULL;
-}
-
 xen_pv_insert_xendev(xendev);
 
 if (xendev->ops->alloc) {
@@ -322,6 +407,16 @@ static int xen_be_try_initialise(struct 

[Xen-devel] [PULL v2 05/15] xen-hvm: create separate function for ioreq server initialization

[Stefano Stabellini]

From: Paul Durrant 

The code is sufficiently substantial that it improves code readability
to put it in a new function called by xen_hvm_init() rather than having
it inline.

Signed-off-by: Paul Durrant 
Reviewed-by: Anthony Perard 
Signed-off-by: Stefano Stabellini 
---
 hw/i386/xen/xen-hvm.c | 76 +++
 1 file changed, 46 insertions(+), 30 deletions(-)

diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
index caa563b..6ffa3c2 100644
--- a/hw/i386/xen/xen-hvm.c
+++ b/hw/i386/xen/xen-hvm.c
@@ -95,7 +95,8 @@ typedef struct XenIOState {
 CPUState **cpu_by_vcpu_id;
 /* the evtchn port for polling the notification, */
 evtchn_port_t *ioreq_local_port;
-/* evtchn local port for buffered io */
+/* evtchn remote and local ports for buffered io */
+evtchn_port_t bufioreq_remote_port;
 evtchn_port_t bufioreq_local_port;
 /* the evtchn fd for polling */
 xenevtchn_handle *xce_handle;
@@ -1236,12 +1237,52 @@ static void xen_wakeup_notifier(Notifier *notifier, 
void *data)
 xc_set_hvm_param(xen_xc, xen_domid, HVM_PARAM_ACPI_S_STATE, 0);
 }
 
-void xen_hvm_init(PCMachineState *pcms, MemoryRegion **ram_memory)
+static int xen_map_ioreq_server(XenIOState *state)
 {
-int i, rc;
 xen_pfn_t ioreq_pfn;
 xen_pfn_t bufioreq_pfn;
 evtchn_port_t bufioreq_evtchn;
+int rc;
+
+rc = xen_get_ioreq_server_info(xen_domid, state->ioservid,
+   _pfn, _pfn,
+   _evtchn);
+if (rc < 0) {
+error_report("failed to get ioreq server info: error %d handle=%p",
+ errno, xen_xc);
+return rc;
+}
+
+DPRINTF("shared page at pfn %lx\n", ioreq_pfn);
+DPRINTF("buffered io page at pfn %lx\n", bufioreq_pfn);
+DPRINTF("buffered io evtchn is %x\n", bufioreq_evtchn);
+
+state->shared_page = xenforeignmemory_map(xen_fmem, xen_domid,
+  PROT_READ | PROT_WRITE,
+  1, _pfn, NULL);
+if (state->shared_page == NULL) {
+error_report("map shared IO page returned error %d handle=%p",
+ errno, xen_xc);
+return -1;
+}
+
+state->buffered_io_page = xenforeignmemory_map(xen_fmem, xen_domid,
+   PROT_READ | PROT_WRITE,
+   1, _pfn, NULL);
+if (state->buffered_io_page == NULL) {
+error_report("map buffered IO page returned error %d", errno);
+return -1;
+}
+
+state->bufioreq_remote_port = bufioreq_evtchn;
+
+return 0;
+}
+
+void xen_hvm_init(PCMachineState *pcms, MemoryRegion **ram_memory)
+{
+int i, rc;
+xen_pfn_t ioreq_pfn;
 XenIOState *state;
 
 state = g_malloc0(sizeof (XenIOState));
@@ -1269,25 +1310,8 @@ void xen_hvm_init(PCMachineState *pcms, MemoryRegion 
**ram_memory)
 state->wakeup.notify = xen_wakeup_notifier;
 qemu_register_wakeup_notifier(>wakeup);
 
-rc = xen_get_ioreq_server_info(xen_domid, state->ioservid,
-   _pfn, _pfn,
-   _evtchn);
+rc = xen_map_ioreq_server(state);
 if (rc < 0) {
-error_report("failed to get ioreq server info: error %d handle=%p",
- errno, xen_xc);
-goto err;
-}
-
-DPRINTF("shared page at pfn %lx\n", ioreq_pfn);
-DPRINTF("buffered io page at pfn %lx\n", bufioreq_pfn);
-DPRINTF("buffered io evtchn is %x\n", bufioreq_evtchn);
-
-state->shared_page = xenforeignmemory_map(xen_fmem, xen_domid,
-  PROT_READ|PROT_WRITE,
-  1, _pfn, NULL);
-if (state->shared_page == NULL) {
-error_report("map shared IO page returned error %d handle=%p",
- errno, xen_xc);
 goto err;
 }
 
@@ -1308,14 +1332,6 @@ void xen_hvm_init(PCMachineState *pcms, MemoryRegion 
**ram_memory)
 goto err;
 }
 
-state->buffered_io_page = xenforeignmemory_map(xen_fmem, xen_domid,
-   PROT_READ|PROT_WRITE,
-   1, _pfn, NULL);
-if (state->buffered_io_page == NULL) {
-error_report("map buffered IO page returned error %d", errno);
-goto err;
-}
-
 /* Note: cpus is empty at this point in init */
 state->cpu_by_vcpu_id = g_malloc0(max_cpus * sizeof(CPUState *));
 
@@ -1340,7 +1356,7 @@ void xen_hvm_init(PCMachineState *pcms, MemoryRegion 
**ram_memory)
 }
 
 rc = xenevtchn_bind_interdomain(state->xce_handle, xen_domid,
-bufioreq_evtchn);
+state->bufioreq_remote_port);
 if (rc == -1) {
 

[Xen-devel] [PULL v2 07/15] xen: add a meaningful declaration of grant_copy_segment into xen_common.h

[Stefano Stabellini]

From: Paul Durrant 

Currently the xen_disk source has to carry #ifdef exclusions to compile
against Xen older then 4.8. This is a bit messy so this patch lifts the
definition of struct xengnttab_grant_copy_segment and adds it into the
pre-4.8 compat area in xen_common.h, which allows xen_disk to be cleaned
up.

Signed-off-by: Paul Durrant 
Acked-by: Anthony PERARD 
Signed-off-by: Stefano Stabellini 
---
 hw/block/xen_disk.c | 18 --
 include/hw/xen/xen_common.h | 17 +++--
 2 files changed, 15 insertions(+), 20 deletions(-)

diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
index f74fcd4..78bfb41 100644
--- a/hw/block/xen_disk.c
+++ b/hw/block/xen_disk.c
@@ -496,8 +496,6 @@ static int ioreq_map(struct ioreq *ioreq)
 return 0;
 }
 
-#if CONFIG_XEN_CTRL_INTERFACE_VERSION >= 40800
-
 static void ioreq_free_copy_buffers(struct ioreq *ioreq)
 {
 int i;
@@ -579,22 +577,6 @@ static int ioreq_grant_copy(struct ioreq *ioreq)
 
 return rc;
 }
-#else
-static void ioreq_free_copy_buffers(struct ioreq *ioreq)
-{
-abort();
-}
-
-static int ioreq_init_copy_buffers(struct ioreq *ioreq)
-{
-abort();
-}
-
-static int ioreq_grant_copy(struct ioreq *ioreq)
-{
-abort();
-}
-#endif
 
 static int ioreq_runio_qemu_aio(struct ioreq *ioreq);
 
diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
index 5f1402b..bbf207d 100644
--- a/include/hw/xen/xen_common.h
+++ b/include/hw/xen/xen_common.h
@@ -667,8 +667,21 @@ static inline int xen_domain_create(xc_interface *xc, 
uint32_t ssidref,
 
 #if CONFIG_XEN_CTRL_INTERFACE_VERSION < 40800
 
-
-typedef void *xengnttab_grant_copy_segment_t;
+struct xengnttab_grant_copy_segment {
+union xengnttab_copy_ptr {
+void *virt;
+struct {
+uint32_t ref;
+uint16_t offset;
+uint16_t domid;
+} foreign;
+} source, dest;
+uint16_t len;
+uint16_t flags;
+int16_t status;
+};
+
+typedef struct xengnttab_grant_copy_segment xengnttab_grant_copy_segment_t;
 
 static inline int xengnttab_grant_copy(xengnttab_handle *xgt, uint32_t count,
xengnttab_grant_copy_segment_t *segs)
-- 
1.9.1


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

[Xen-devel] [PULL v2 01/15] xen-pvdevice: Introduce a simplistic xen-pvdevice save state

[Stefano Stabellini]

From: Igor Druzhinin 

This should help to avoid problems with accessing the device after
migration/resume without PV drivers by migrating its PCI configuration
space state. Without an explicitly defined state record it resets
every time a VM migrates which confuses the OS and makes every
access to xen-pvdevice MMIO region to fail. PV tools enable some
logic to save and restore PCI configuration state from within the VM
every time it migrates which basically hides the issue.

Older systems will acquire the new record when migrated which should
not change their state for worse.

Signed-off-by: Igor Druzhinin 
Reviewed-by: Paul Durrant 
Acked-by: Anthony PERARD 
Signed-off-by: Stefano Stabellini 
---
 hw/i386/xen/xen_pvdevice.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/hw/i386/xen/xen_pvdevice.c b/hw/i386/xen/xen_pvdevice.c
index f748823..a146f18 100644
--- a/hw/i386/xen/xen_pvdevice.c
+++ b/hw/i386/xen/xen_pvdevice.c
@@ -71,6 +71,16 @@ static const MemoryRegionOps xen_pv_mmio_ops = {
 .endianness = DEVICE_LITTLE_ENDIAN,
 };
 
+static const VMStateDescription vmstate_xen_pvdevice = {
+.name = "xen-pvdevice",
+.version_id = 1,
+.minimum_version_id = 1,
+.fields = (VMStateField[]) {
+VMSTATE_PCI_DEVICE(parent_obj, XenPVDevice),
+VMSTATE_END_OF_LIST()
+}
+};
+
 static void xen_pv_realize(PCIDevice *pci_dev, Error **errp)
 {
 XenPVDevice *d = XEN_PV_DEVICE(pci_dev);
@@ -120,6 +130,7 @@ static void xen_pv_class_init(ObjectClass *klass, void 
*data)
 k->class_id = PCI_CLASS_SYSTEM_OTHER;
 dc->desc = "Xen PV Device";
 dc->props = xen_pv_props;
+dc->vmsd = _xen_pvdevice;
 }
 
 static const TypeInfo xen_pv_type_info = {
-- 
1.9.1


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

[Xen-devel] [PULL v2 09/15] xen_disk: remove open-coded use of libxengnttab

[Stefano Stabellini]

From: Paul Durrant 

Now that helpers are present in xen_backend, this patch removes open-coded
calls to libxengnttab from the xen_disk code.

This patch also fixes one whitspace error in the assignment of the
XenDevOps initialise method.

Signed-off-by: Paul Durrant 
Acked-by: Anthony Perard 
Signed-off-by: Stefano Stabellini 
---
 hw/block/xen_disk.c | 122 ++--
 1 file changed, 32 insertions(+), 90 deletions(-)

diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
index 78bfb41..d3be45a 100644
--- a/hw/block/xen_disk.c
+++ b/hw/block/xen_disk.c
@@ -68,7 +68,6 @@ struct ioreq {
 uint8_t mapped;
 
 /* grant mapping */
-uint32_tdomids[BLKIF_MAX_SEGMENTS_PER_REQUEST];
 uint32_trefs[BLKIF_MAX_SEGMENTS_PER_REQUEST];
 int prot;
 void*page[BLKIF_MAX_SEGMENTS_PER_REQUEST];
@@ -142,7 +141,6 @@ static void ioreq_reset(struct ioreq *ioreq)
 ioreq->presync = 0;
 ioreq->mapped = 0;
 
-memset(ioreq->domids, 0, sizeof(ioreq->domids));
 memset(ioreq->refs, 0, sizeof(ioreq->refs));
 ioreq->prot = 0;
 memset(ioreq->page, 0, sizeof(ioreq->page));
@@ -168,16 +166,12 @@ static gint int_cmp(gconstpointer a, gconstpointer b, 
gpointer user_data)
 static void destroy_grant(gpointer pgnt)
 {
 PersistentGrant *grant = pgnt;
-xengnttab_handle *gnt = grant->blkdev->xendev.gnttabdev;
+struct XenBlkDev *blkdev = grant->blkdev;
+struct XenDevice *xendev = >xendev;
 
-if (xengnttab_unmap(gnt, grant->page, 1) != 0) {
-xen_pv_printf(>blkdev->xendev, 0,
-  "xengnttab_unmap failed: %s\n",
-  strerror(errno));
-}
+xen_be_unmap_grant_ref(xendev, grant->page);
 grant->blkdev->persistent_gnt_count--;
-xen_pv_printf(>blkdev->xendev, 3,
-  "unmapped grant %p\n", grant->page);
+xen_pv_printf(xendev, 3, "unmapped grant %p\n", grant->page);
 g_free(grant);
 }
 
@@ -185,15 +179,10 @@ static void remove_persistent_region(gpointer data, 
gpointer dev)
 {
 PersistentRegion *region = data;
 struct XenBlkDev *blkdev = dev;
-xengnttab_handle *gnt = blkdev->xendev.gnttabdev;
+struct XenDevice *xendev = >xendev;
 
-if (xengnttab_unmap(gnt, region->addr, region->num) != 0) {
-xen_pv_printf(>xendev, 0,
-  "xengnttab_unmap region %p failed: %s\n",
-  region->addr, strerror(errno));
-}
-xen_pv_printf(>xendev, 3,
-  "unmapped grant region %p with %d pages\n",
+xen_be_unmap_grant_refs(xendev, region->addr, region->num);
+xen_pv_printf(xendev, 3, "unmapped grant region %p with %d pages\n",
   region->addr, region->num);
 g_free(region);
 }
@@ -304,7 +293,6 @@ static int ioreq_parse(struct ioreq *ioreq)
 goto err;
 }
 
-ioreq->domids[i] = blkdev->xendev.dom;
 ioreq->refs[i]   = ioreq->req.seg[i].gref;
 
 mem = ioreq->req.seg[i].first_sect * blkdev->file_blk;
@@ -324,7 +312,8 @@ err:
 
 static void ioreq_unmap(struct ioreq *ioreq)
 {
-xengnttab_handle *gnt = ioreq->blkdev->xendev.gnttabdev;
+struct XenBlkDev *blkdev = ioreq->blkdev;
+struct XenDevice *xendev = >xendev;
 int i;
 
 if (ioreq->num_unmap == 0 || ioreq->mapped == 0) {
@@ -334,11 +323,7 @@ static void ioreq_unmap(struct ioreq *ioreq)
 if (!ioreq->pages) {
 return;
 }
-if (xengnttab_unmap(gnt, ioreq->pages, ioreq->num_unmap) != 0) {
-xen_pv_printf(>blkdev->xendev, 0,
-  "xengnttab_unmap failed: %s\n",
-  strerror(errno));
-}
+xen_be_unmap_grant_refs(xendev, ioreq->pages, ioreq->num_unmap);
 ioreq->blkdev->cnt_map -= ioreq->num_unmap;
 ioreq->pages = NULL;
 } else {
@@ -346,11 +331,7 @@ static void ioreq_unmap(struct ioreq *ioreq)
 if (!ioreq->page[i]) {
 continue;
 }
-if (xengnttab_unmap(gnt, ioreq->page[i], 1) != 0) {
-xen_pv_printf(>blkdev->xendev, 0,
-  "xengnttab_unmap failed: %s\n",
-  strerror(errno));
-}
+xen_be_unmap_grant_ref(xendev, ioreq->page[i]);
 ioreq->blkdev->cnt_map--;
 ioreq->page[i] = NULL;
 }
@@ -360,14 +341,14 @@ static void ioreq_unmap(struct ioreq *ioreq)
 
 static int ioreq_map(struct ioreq *ioreq)
 {
-xengnttab_handle *gnt = ioreq->blkdev->xendev.gnttabdev;
-uint32_t domids[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+struct XenBlkDev *blkdev = ioreq->blkdev;
+struct XenDevice *xendev = >xendev;
 uint32_t refs[BLKIF_MAX_SEGMENTS_PER_REQUEST];
 void *page[BLKIF_MAX_SEGMENTS_PER_REQUEST];
 int i, j, new_maps = 0;

[Xen-devel] [PULL v2 10/15] xen: remove other open-coded use of libxengnttab

[Stefano Stabellini]

From: Paul Durrant 

Now that helpers are available in xen_backend, use them throughout all
Xen PV backends.

Signed-off-by: Paul Durrant 
Acked-by: Anthony Perard 
Signed-off-by: Stefano Stabellini 
---
 hw/9pfs/xen-9p-backend.c | 32 +++-
 hw/char/xen_console.c|  9 -
 hw/net/xen_nic.c | 33 ++---
 hw/usb/xen-usb.c | 37 +
 4 files changed, 50 insertions(+), 61 deletions(-)

diff --git a/hw/9pfs/xen-9p-backend.c b/hw/9pfs/xen-9p-backend.c
index 95e50c4..6026780 100644
--- a/hw/9pfs/xen-9p-backend.c
+++ b/hw/9pfs/xen-9p-backend.c
@@ -331,14 +331,14 @@ static int xen_9pfs_free(struct XenDevice *xendev)
 
 for (i = 0; i < xen_9pdev->num_rings; i++) {
 if (xen_9pdev->rings[i].data != NULL) {
-xengnttab_unmap(xen_9pdev->xendev.gnttabdev,
-xen_9pdev->rings[i].data,
-(1 << xen_9pdev->rings[i].ring_order));
+xen_be_unmap_grant_refs(_9pdev->xendev,
+xen_9pdev->rings[i].data,
+(1 << xen_9pdev->rings[i].ring_order));
 }
 if (xen_9pdev->rings[i].intf != NULL) {
-xengnttab_unmap(xen_9pdev->xendev.gnttabdev,
-xen_9pdev->rings[i].intf,
-1);
+xen_be_unmap_grant_refs(_9pdev->xendev,
+xen_9pdev->rings[i].intf,
+1);
 }
 if (xen_9pdev->rings[i].bh != NULL) {
 qemu_bh_delete(xen_9pdev->rings[i].bh);
@@ -390,11 +390,10 @@ static int xen_9pfs_connect(struct XenDevice *xendev)
 }
 g_free(str);
 
-xen_9pdev->rings[i].intf =  xengnttab_map_grant_ref(
-xen_9pdev->xendev.gnttabdev,
-xen_9pdev->xendev.dom,
-xen_9pdev->rings[i].ref,
-PROT_READ | PROT_WRITE);
+xen_9pdev->rings[i].intf =
+xen_be_map_grant_ref(_9pdev->xendev,
+ xen_9pdev->rings[i].ref,
+ PROT_READ | PROT_WRITE);
 if (!xen_9pdev->rings[i].intf) {
 goto out;
 }
@@ -403,12 +402,11 @@ static int xen_9pfs_connect(struct XenDevice *xendev)
 goto out;
 }
 xen_9pdev->rings[i].ring_order = ring_order;
-xen_9pdev->rings[i].data = xengnttab_map_domain_grant_refs(
-xen_9pdev->xendev.gnttabdev,
-(1 << ring_order),
-xen_9pdev->xendev.dom,
-xen_9pdev->rings[i].intf->ref,
-PROT_READ | PROT_WRITE);
+xen_9pdev->rings[i].data =
+xen_be_map_grant_refs(_9pdev->xendev,
+  xen_9pdev->rings[i].intf->ref,
+  (1 << ring_order),
+  PROT_READ | PROT_WRITE);
 if (!xen_9pdev->rings[i].data) {
 goto out;
 }
diff --git a/hw/char/xen_console.c b/hw/char/xen_console.c
index bdfaa40..8b4b4bf 100644
--- a/hw/char/xen_console.c
+++ b/hw/char/xen_console.c
@@ -233,12 +233,11 @@ static int con_initialise(struct XenDevice *xendev)
 if (!xendev->dev) {
 xen_pfn_t mfn = con->ring_ref;
 con->sring = xenforeignmemory_map(xen_fmem, con->xendev.dom,
-  PROT_READ|PROT_WRITE,
+  PROT_READ | PROT_WRITE,
   1, , NULL);
 } else {
-con->sring = xengnttab_map_grant_ref(xendev->gnttabdev, 
con->xendev.dom,
- con->ring_ref,
- PROT_READ|PROT_WRITE);
+con->sring = xen_be_map_grant_ref(xendev, con->ring_ref,
+  PROT_READ | PROT_WRITE);
 }
 if (!con->sring)
return -1;
@@ -267,7 +266,7 @@ static void con_disconnect(struct XenDevice *xendev)
 if (!xendev->dev) {
 xenforeignmemory_unmap(xen_fmem, con->sring, 1);
 } else {
-xengnttab_unmap(xendev->gnttabdev, con->sring, 1);
+xen_be_unmap_grant_ref(xendev, con->sring);
 }
 con->sring = NULL;
 }
diff --git a/hw/net/xen_nic.c b/hw/net/xen_nic.c
index 20c43a6..46a8dbf 100644
--- a/hw/net/xen_nic.c
+++ b/hw/net/xen_nic.c
@@ -160,9 +160,8 @@ static void net_tx_packets(struct XenNetDev *netdev)
   (txreq.flags & NETTXF_more_data)  ? " more_data" 
 : "",
   (txreq.flags & NETTXF_extra_info) ? " 
extra_info" : "");
 
-page = xengnttab_map_grant_ref(netdev->xendev.gnttabdev,
-   netdev->xendev.dom,
-

[Xen-devel] [PULL v2 15/15] xen_disk: be consistent with use of xendev and blkdev->xendev

[Stefano Stabellini]

From: Paul Durrant 

Certain functions in xen_disk are called with a pointer to xendev
(struct XenDevice *). They then use container_of() to acces the surrounding
blkdev (struct XenBlkDev) but then in various places use >xendev
when use of the original xendev pointer is shorter to express and clearly
equivalent.

This patch is a purely cosmetic patch which makes sure there is a xendev
pointer on stack for any function where the pointer is need on multiple
occasions modified those functions to use it consistently.

Signed-off-by: Paul Durrant 
Acked-by: Anthony PERARD 
Signed-off-by: Stefano Stabellini 
---
 hw/block/xen_disk.c | 90 +++--
 1 file changed, 46 insertions(+), 44 deletions(-)

diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
index 28651c5..9fbc0cd 100644
--- a/hw/block/xen_disk.c
+++ b/hw/block/xen_disk.c
@@ -178,10 +178,11 @@ static void ioreq_release(struct ioreq *ioreq, bool 
finish)
 static int ioreq_parse(struct ioreq *ioreq)
 {
 struct XenBlkDev *blkdev = ioreq->blkdev;
+struct XenDevice *xendev = >xendev;
 size_t len;
 int i;
 
-xen_pv_printf(>xendev, 3,
+xen_pv_printf(xendev, 3,
   "op %d, nr %d, handle %d, id %" PRId64 ", sector %" PRId64 
"\n",
   ioreq->req.operation, ioreq->req.nr_segments,
   ioreq->req.handle, ioreq->req.id, ioreq->req.sector_number);
@@ -199,28 +200,28 @@ static int ioreq_parse(struct ioreq *ioreq)
 case BLKIF_OP_DISCARD:
 return 0;
 default:
-xen_pv_printf(>xendev, 0, "error: unknown operation (%d)\n",
+xen_pv_printf(xendev, 0, "error: unknown operation (%d)\n",
   ioreq->req.operation);
 goto err;
 };
 
 if (ioreq->req.operation != BLKIF_OP_READ && blkdev->mode[0] != 'w') {
-xen_pv_printf(>xendev, 0, "error: write req for ro device\n");
+xen_pv_printf(xendev, 0, "error: write req for ro device\n");
 goto err;
 }
 
 ioreq->start = ioreq->req.sector_number * blkdev->file_blk;
 for (i = 0; i < ioreq->req.nr_segments; i++) {
 if (i == BLKIF_MAX_SEGMENTS_PER_REQUEST) {
-xen_pv_printf(>xendev, 0, "error: nr_segments too big\n");
+xen_pv_printf(xendev, 0, "error: nr_segments too big\n");
 goto err;
 }
 if (ioreq->req.seg[i].first_sect > ioreq->req.seg[i].last_sect) {
-xen_pv_printf(>xendev, 0, "error: first > last sector\n");
+xen_pv_printf(xendev, 0, "error: first > last sector\n");
 goto err;
 }
 if (ioreq->req.seg[i].last_sect * BLOCK_SIZE >= XC_PAGE_SIZE) {
-xen_pv_printf(>xendev, 0, "error: page crossing\n");
+xen_pv_printf(xendev, 0, "error: page crossing\n");
 goto err;
 }
 
@@ -228,7 +229,7 @@ static int ioreq_parse(struct ioreq *ioreq)
 ioreq->size += len;
 }
 if (ioreq->start + ioreq->size > blkdev->file_size) {
-xen_pv_printf(>xendev, 0, "error: access beyond end of 
file\n");
+xen_pv_printf(xendev, 0, "error: access beyond end of file\n");
 goto err;
 }
 return 0;
@@ -244,7 +245,7 @@ static int ioreq_grant_copy(struct ioreq *ioreq)
 struct XenDevice *xendev = >xendev;
 XenGrantCopySegment segs[BLKIF_MAX_SEGMENTS_PER_REQUEST];
 int i, count, rc;
-int64_t file_blk = ioreq->blkdev->file_blk;
+int64_t file_blk = blkdev->file_blk;
 bool to_domain = (ioreq->req.operation == BLKIF_OP_READ);
 void *virt = ioreq->buf;
 
@@ -272,7 +273,7 @@ static int ioreq_grant_copy(struct ioreq *ioreq)
 rc = xen_be_copy_grant_refs(xendev, to_domain, segs, count);
 
 if (rc) {
-xen_pv_printf(>blkdev->xendev, 0,
+xen_pv_printf(xendev, 0,
   "failed to copy data %d\n", rc);
 ioreq->aio_errors++;
 return -1;
@@ -287,11 +288,12 @@ static void qemu_aio_complete(void *opaque, int ret)
 {
 struct ioreq *ioreq = opaque;
 struct XenBlkDev *blkdev = ioreq->blkdev;
+struct XenDevice *xendev = >xendev;
 
 aio_context_acquire(blkdev->ctx);
 
 if (ret != 0) {
-xen_pv_printf(>xendev, 0, "%s I/O error\n",
+xen_pv_printf(xendev, 0, "%s I/O error\n",
   ioreq->req.operation == BLKIF_OP_READ ? "read" : 
"write");
 ioreq->aio_errors++;
 }
@@ -625,16 +627,17 @@ static void blk_alloc(struct XenDevice *xendev)
 
 static void blk_parse_discard(struct XenBlkDev *blkdev)
 {
+struct XenDevice *xendev = >xendev;
 int enable;
 
 blkdev->feature_discard = true;
 
-if (xenstore_read_be_int(>xendev, "discard-enable", ) == 0) 
{
+if (xenstore_read_be_int(xendev, "discard-enable", ) == 0) {
 blkdev->feature_discard = !!enable;
 }
 
 if (blkdev->feature_discard) {
-

[Xen-devel] [PULL v2 14/15] xen_disk: use a single entry iovec

[Stefano Stabellini]

From: Paul Durrant 

Since xen_disk now always copies data to and from a guest there is no need
to maintain a vector entry corresponding to every page of a request.
This means there is less per-request state to maintain so the ioreq
structure can shrink significantly.

Signed-off-by: Paul Durrant 
Acked-by: Anthony Perard 
Signed-off-by: Stefano Stabellini 
---
 hw/block/xen_disk.c | 76 +++--
 1 file changed, 21 insertions(+), 55 deletions(-)

diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
index 28be8b6..28651c5 100644
--- a/hw/block/xen_disk.c
+++ b/hw/block/xen_disk.c
@@ -46,13 +46,10 @@ struct ioreq {
 /* parsed request */
 off_t   start;
 QEMUIOVectorv;
+void*buf;
+size_t  size;
 int presync;
 
-/* grant mapping */
-uint32_trefs[BLKIF_MAX_SEGMENTS_PER_REQUEST];
-void*page[BLKIF_MAX_SEGMENTS_PER_REQUEST];
-void*pages;
-
 /* aio status */
 int aio_inflight;
 int aio_errors;
@@ -110,12 +107,10 @@ static void ioreq_reset(struct ioreq *ioreq)
 memset(>req, 0, sizeof(ioreq->req));
 ioreq->status = 0;
 ioreq->start = 0;
+ioreq->buf = NULL;
+ioreq->size = 0;
 ioreq->presync = 0;
 
-memset(ioreq->refs, 0, sizeof(ioreq->refs));
-memset(ioreq->page, 0, sizeof(ioreq->page));
-ioreq->pages = NULL;
-
 ioreq->aio_inflight = 0;
 ioreq->aio_errors = 0;
 
@@ -138,7 +133,7 @@ static struct ioreq *ioreq_start(struct XenBlkDev *blkdev)
 ioreq = g_malloc0(sizeof(*ioreq));
 ioreq->blkdev = blkdev;
 blkdev->requests_total++;
-qemu_iovec_init(>v, BLKIF_MAX_SEGMENTS_PER_REQUEST);
+qemu_iovec_init(>v, 1);
 } else {
 /* get one from freelist */
 ioreq = QLIST_FIRST(>freelist);
@@ -183,7 +178,6 @@ static void ioreq_release(struct ioreq *ioreq, bool finish)
 static int ioreq_parse(struct ioreq *ioreq)
 {
 struct XenBlkDev *blkdev = ioreq->blkdev;
-uintptr_t mem;
 size_t len;
 int i;
 
@@ -230,13 +224,10 @@ static int ioreq_parse(struct ioreq *ioreq)
 goto err;
 }
 
-ioreq->refs[i]   = ioreq->req.seg[i].gref;
-
-mem = ioreq->req.seg[i].first_sect * blkdev->file_blk;
 len = (ioreq->req.seg[i].last_sect - ioreq->req.seg[i].first_sect + 1) 
* blkdev->file_blk;
-qemu_iovec_add(>v, (void*)mem, len);
+ioreq->size += len;
 }
-if (ioreq->start + ioreq->v.size > blkdev->file_size) {
+if (ioreq->start + ioreq->size > blkdev->file_size) {
 xen_pv_printf(>xendev, 0, "error: access beyond end of 
file\n");
 goto err;
 }
@@ -247,35 +238,6 @@ err:
 return -1;
 }
 
-static void ioreq_free_copy_buffers(struct ioreq *ioreq)
-{
-int i;
-
-for (i = 0; i < ioreq->v.niov; i++) {
-ioreq->page[i] = NULL;
-}
-
-qemu_vfree(ioreq->pages);
-}
-
-static int ioreq_init_copy_buffers(struct ioreq *ioreq)
-{
-int i;
-
-if (ioreq->v.niov == 0) {
-return 0;
-}
-
-ioreq->pages = qemu_memalign(XC_PAGE_SIZE, ioreq->v.niov * XC_PAGE_SIZE);
-
-for (i = 0; i < ioreq->v.niov; i++) {
-ioreq->page[i] = ioreq->pages + i * XC_PAGE_SIZE;
-ioreq->v.iov[i].iov_base = ioreq->page[i];
-}
-
-return 0;
-}
-
 static int ioreq_grant_copy(struct ioreq *ioreq)
 {
 struct XenBlkDev *blkdev = ioreq->blkdev;
@@ -284,25 +246,27 @@ static int ioreq_grant_copy(struct ioreq *ioreq)
 int i, count, rc;
 int64_t file_blk = ioreq->blkdev->file_blk;
 bool to_domain = (ioreq->req.operation == BLKIF_OP_READ);
+void *virt = ioreq->buf;
 
-if (ioreq->v.niov == 0) {
+if (ioreq->req.nr_segments == 0) {
 return 0;
 }
 
-count = ioreq->v.niov;
+count = ioreq->req.nr_segments;
 
 for (i = 0; i < count; i++) {
 if (to_domain) {
-segs[i].dest.foreign.ref = ioreq->refs[i];
+segs[i].dest.foreign.ref = ioreq->req.seg[i].gref;
 segs[i].dest.foreign.offset = ioreq->req.seg[i].first_sect * 
file_blk;
-segs[i].source.virt = ioreq->v.iov[i].iov_base;
+segs[i].source.virt = virt;
 } else {
-segs[i].source.foreign.ref = ioreq->refs[i];
+segs[i].source.foreign.ref = ioreq->req.seg[i].gref;
 segs[i].source.foreign.offset = ioreq->req.seg[i].first_sect * 
file_blk;
-segs[i].dest.virt = ioreq->v.iov[i].iov_base;
+segs[i].dest.virt = virt;
 }
 segs[i].len = (ioreq->req.seg[i].last_sect
- ioreq->req.seg[i].first_sect + 1) * file_blk;
+virt += segs[i].len;
 }
 
 rc = xen_be_copy_grant_refs(xendev, to_domain, segs, count);
@@ -348,14 +312,14 @@ static void 

[Xen-devel] [PULL v2 02/15] xen/pt: use address_space_memory object for memory region hooks

[Stefano Stabellini]

From: Igor Druzhinin 

Commit 99605175c (xen-pt: Fix PCI devices re-attach failed) introduced
a subtle bug. As soon as the guest switches off Bus Mastering on the
device it immediately causes all the BARs be unmapped due to the DMA
address space of the device being changed. This is undesired behavior
because the guest may try to communicate with the device after that
which triggers the following errors in the logs:

[00:05.0] xen_pt_bar_read: Error: Should not read BAR through QEMU. 
@0x0200
[00:05.0] xen_pt_bar_write: Error: Should not write BAR through QEMU. 
@0x0200

The issue that the original patch tried to workaround (uneven number of
region_add/del calls on device attach/detach) was fixed in d25836cafd
(memory: do explicit cleanup when remove listeners).

Signed-off-by: Igor Druzhinin 
Reported-by: Ross Lagerwall 
Acked-by: Anthony PERARD 
Signed-off-by: Stefano Stabellini 
---
 hw/xen/xen_pt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
index 9b7a960..e5a6eff 100644
--- a/hw/xen/xen_pt.c
+++ b/hw/xen/xen_pt.c
@@ -907,7 +907,7 @@ out:
 }
 }
 
-memory_listener_register(>memory_listener, >dev.bus_master_as);
+memory_listener_register(>memory_listener, _space_memory);
 memory_listener_register(>io_listener, _space_io);
 s->listener_set = true;
 XEN_PT_LOG(d,
-- 
1.9.1


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

[Xen-devel] [PULL v2 12/15] xen_disk: remove use of grant map/unmap

[Stefano Stabellini]

From: Paul Durrant 

Now that the (native or emulated) xen_be_copy_grant_refs() helper is
always available, the xen_disk code can be significantly simplified by
removing direct use of grant map and unmap operations.

Signed-off-by: Paul Durrant 
Acked-by: Anthony Perard 
Signed-off-by: Stefano Stabellini 
---
 hw/block/xen_disk.c | 352 
 1 file changed, 25 insertions(+), 327 deletions(-)

diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
index d3be45a..28be8b6 100644
--- a/hw/block/xen_disk.c
+++ b/hw/block/xen_disk.c
@@ -36,27 +36,9 @@
 
 /* - */
 
-static int batch_maps   = 0;
-
-/* - */
-
 #define BLOCK_SIZE  512
 #define IOCB_COUNT  (BLKIF_MAX_SEGMENTS_PER_REQUEST + 2)
 
-struct PersistentGrant {
-void *page;
-struct XenBlkDev *blkdev;
-};
-
-typedef struct PersistentGrant PersistentGrant;
-
-struct PersistentRegion {
-void *addr;
-int num;
-};
-
-typedef struct PersistentRegion PersistentRegion;
-
 struct ioreq {
 blkif_request_t req;
 int16_t status;
@@ -65,14 +47,11 @@ struct ioreq {
 off_t   start;
 QEMUIOVectorv;
 int presync;
-uint8_t mapped;
 
 /* grant mapping */
 uint32_trefs[BLKIF_MAX_SEGMENTS_PER_REQUEST];
-int prot;
 void*page[BLKIF_MAX_SEGMENTS_PER_REQUEST];
 void*pages;
-int num_unmap;
 
 /* aio status */
 int aio_inflight;
@@ -103,7 +82,6 @@ struct XenBlkDev {
 int protocol;
 blkif_back_rings_t  rings;
 int more_work;
-int cnt_map;
 
 /* request lists */
 QLIST_HEAD(inflight_head, ioreq) inflight;
@@ -114,13 +92,7 @@ struct XenBlkDev {
 int requests_finished;
 unsigned intmax_requests;
 
-/* Persistent grants extension */
 gbooleanfeature_discard;
-gbooleanfeature_persistent;
-GTree   *persistent_gnts;
-GSList  *persistent_regions;
-unsigned intpersistent_gnt_count;
-unsigned intmax_grants;
 
 /* qemu block driver */
 DriveInfo   *dinfo;
@@ -139,10 +111,8 @@ static void ioreq_reset(struct ioreq *ioreq)
 ioreq->status = 0;
 ioreq->start = 0;
 ioreq->presync = 0;
-ioreq->mapped = 0;
 
 memset(ioreq->refs, 0, sizeof(ioreq->refs));
-ioreq->prot = 0;
 memset(ioreq->page, 0, sizeof(ioreq->page));
 ioreq->pages = NULL;
 
@@ -156,37 +126,6 @@ static void ioreq_reset(struct ioreq *ioreq)
 qemu_iovec_reset(>v);
 }
 
-static gint int_cmp(gconstpointer a, gconstpointer b, gpointer user_data)
-{
-uint ua = GPOINTER_TO_UINT(a);
-uint ub = GPOINTER_TO_UINT(b);
-return (ua > ub) - (ua < ub);
-}
-
-static void destroy_grant(gpointer pgnt)
-{
-PersistentGrant *grant = pgnt;
-struct XenBlkDev *blkdev = grant->blkdev;
-struct XenDevice *xendev = >xendev;
-
-xen_be_unmap_grant_ref(xendev, grant->page);
-grant->blkdev->persistent_gnt_count--;
-xen_pv_printf(xendev, 3, "unmapped grant %p\n", grant->page);
-g_free(grant);
-}
-
-static void remove_persistent_region(gpointer data, gpointer dev)
-{
-PersistentRegion *region = data;
-struct XenBlkDev *blkdev = dev;
-struct XenDevice *xendev = >xendev;
-
-xen_be_unmap_grant_refs(xendev, region->addr, region->num);
-xen_pv_printf(xendev, 3, "unmapped grant region %p with %d pages\n",
-  region->addr, region->num);
-g_free(region);
-}
-
 static struct ioreq *ioreq_start(struct XenBlkDev *blkdev)
 {
 struct ioreq *ioreq = NULL;
@@ -254,7 +193,6 @@ static int ioreq_parse(struct ioreq *ioreq)
   ioreq->req.handle, ioreq->req.id, ioreq->req.sector_number);
 switch (ioreq->req.operation) {
 case BLKIF_OP_READ:
-ioreq->prot = PROT_WRITE; /* to memory */
 break;
 case BLKIF_OP_FLUSH_DISKCACHE:
 ioreq->presync = 1;
@@ -263,7 +201,6 @@ static int ioreq_parse(struct ioreq *ioreq)
 }
 /* fall through */
 case BLKIF_OP_WRITE:
-ioreq->prot = PROT_READ; /* from memory */
 break;
 case BLKIF_OP_DISCARD:
 return 0;
@@ -310,171 +247,6 @@ err:
 return -1;
 }
 
-static void ioreq_unmap(struct ioreq *ioreq)
-{
-struct XenBlkDev *blkdev = ioreq->blkdev;
-struct XenDevice *xendev = >xendev;
-int i;
-
-if (ioreq->num_unmap == 0 || ioreq->mapped == 0) {
-return;
-}
-if (batch_maps) {
-if (!ioreq->pages) {
-return;
-}
-xen_be_unmap_grant_refs(xendev, ioreq->pages, ioreq->num_unmap);
-

[Xen-devel] [PULL v2 11/15] xen_backend: add an emulation of grant copy

[Stefano Stabellini]

From: Paul Durrant 

Not all Xen environments support the xengnttab_grant_copy() operation.
E.g. where the OS is FreeBSD or Xen is older than 4.8.0.

This patch introduces an emulation of that operation using
xengnttab_map_domain_grant_refs() and memcpy() for those environments.

Signed-off-by: Paul Durrant 
Acked-by: Anthony PERARD 
Signed-off-by: Stefano Stabellini 
---
 hw/xen/xen_backend.c | 53 
 1 file changed, 53 insertions(+)

diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
index 50412d6..3c3fc2c 100644
--- a/hw/xen/xen_backend.c
+++ b/hw/xen/xen_backend.c
@@ -146,6 +146,55 @@ void xen_be_unmap_grant_refs(struct XenDevice *xendev, 
void *ptr,
 }
 }
 
+static int compat_copy_grant_refs(struct XenDevice *xendev,
+  bool to_domain,
+  XenGrantCopySegment segs[],
+  unsigned int nr_segs)
+{
+uint32_t *refs = g_new(uint32_t, nr_segs);
+int prot = to_domain ? PROT_WRITE : PROT_READ;
+void *pages;
+unsigned int i;
+
+for (i = 0; i < nr_segs; i++) {
+XenGrantCopySegment *seg = [i];
+
+refs[i] = to_domain ?
+seg->dest.foreign.ref : seg->source.foreign.ref;
+}
+
+pages = xengnttab_map_domain_grant_refs(xendev->gnttabdev, nr_segs,
+xen_domid, refs, prot);
+if (!pages) {
+xen_pv_printf(xendev, 0,
+  "xengnttab_map_domain_grant_refs failed: %s\n",
+  strerror(errno));
+g_free(refs);
+return -1;
+}
+
+for (i = 0; i < nr_segs; i++) {
+XenGrantCopySegment *seg = [i];
+void *page = pages + (i * XC_PAGE_SIZE);
+
+if (to_domain) {
+memcpy(page + seg->dest.foreign.offset, seg->source.virt,
+   seg->len);
+} else {
+memcpy(seg->dest.virt, page + seg->source.foreign.offset,
+   seg->len);
+}
+}
+
+if (xengnttab_unmap(xendev->gnttabdev, pages, nr_segs)) {
+xen_pv_printf(xendev, 0, "xengnttab_unmap failed: %s\n",
+  strerror(errno));
+}
+
+g_free(refs);
+return 0;
+}
+
 int xen_be_copy_grant_refs(struct XenDevice *xendev,
bool to_domain,
XenGrantCopySegment segs[],
@@ -157,6 +206,10 @@ int xen_be_copy_grant_refs(struct XenDevice *xendev,
 
 assert(xendev->ops->flags & DEVOPS_FLAG_NEED_GNTDEV);
 
+if (!xen_feature_grant_copy) {
+return compat_copy_grant_refs(xendev, to_domain, segs, nr_segs);
+}
+
 xengnttab_segs = g_new0(xengnttab_grant_copy_segment_t, nr_segs);
 
 for (i = 0; i < nr_segs; i++) {
-- 
1.9.1


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

[Xen-devel] [PULL v2 04/15] xen_pt: Present the size of 64 bit BARs correctly

[Stefano Stabellini]

From: Ross Lagerwall 

The full size of the BAR is stored in the lower PCIIORegion.size. The
upper PCIIORegion.size is 0.  Calculate the size of the upper half
correctly from the lower half otherwise the size read by the guest will
be incorrect.

Signed-off-by: Ross Lagerwall 
Acked-by: Anthony PERARD 
Signed-off-by: Stefano Stabellini 
---
 hw/xen/xen_pt_config_init.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/hw/xen/xen_pt_config_init.c b/hw/xen/xen_pt_config_init.c
index a3ce33e..aee31c6 100644
--- a/hw/xen/xen_pt_config_init.c
+++ b/hw/xen/xen_pt_config_init.c
@@ -504,6 +504,8 @@ static int xen_pt_bar_reg_write(XenPCIPassthroughState *s, 
XenPTReg *cfg_entry,
 bar_ro_mask = XEN_PT_BAR_IO_RO_MASK | (r_size - 1);
 break;
 case XEN_PT_BAR_FLAG_UPPER:
+assert(index > 0);
+r_size = d->io_regions[index - 1].size >> 32;
 bar_emu_mask = XEN_PT_BAR_ALLF;
 bar_ro_mask = r_size ? r_size - 1 : 0;
 break;
-- 
1.9.1


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

Re: [Xen-devel] [RFC PATCH v2 00/12] get rid of GFP_ZONE_TABLE/BAD

[Michal Hocko]

On Mon 21-05-18 23:20:21, Huaisheng Ye wrote:
> From: Huaisheng Ye 
> 
> Replace GFP_ZONE_TABLE and GFP_ZONE_BAD with encoded zone number.
> 
> Delete ___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 from GFP bitmasks,
> the bottom three bits of GFP mask is reserved for storing encoded
> zone number.
> 
> The encoding method is XOR. Get zone number from enum zone_type,
> then encode the number with ZONE_NORMAL by XOR operation.
> The goal is to make sure ZONE_NORMAL can be encoded to zero. So,
> the compatibility can be guaranteed, such as GFP_KERNEL and GFP_ATOMIC
> can be used as before.
> 
> Reserve __GFP_MOVABLE in bit 3, so that it can continue to be used as
> a flag. Same as before, __GFP_MOVABLE respresents movable migrate type
> for ZONE_DMA, ZONE_DMA32, and ZONE_NORMAL. But when it is enabled with
> __GFP_HIGHMEM, ZONE_MOVABLE shall be returned instead of ZONE_HIGHMEM.
> __GFP_ZONE_MOVABLE is created to realize it.
> 
> With this patch, just enabling __GFP_MOVABLE and __GFP_HIGHMEM is not
> enough to get ZONE_MOVABLE from gfp_zone. All callers should use
> GFP_HIGHUSER_MOVABLE or __GFP_ZONE_MOVABLE directly to achieve that.
> 
> Decode zone number directly from bottom three bits of flags in gfp_zone.
> The theory of encoding and decoding is,
> A ^ B ^ B = A

So why is this any better than the current code. Sure I am not a great
fan of GFP_ZONE_TABLE because of how it is incomprehensible but this
doesn't look too much better, yet we are losing a check for incompatible
gfp flags. The diffstat looks really sound but then you just look and
see that the large part is the comment that at least explained the gfp
zone modifiers somehow and the debugging code. So what is the selling
point?

> Changes since v1,
> 
> v2: Add __GFP_ZONE_MOVABLE and modify GFP_HIGHUSER_MOVABLE to help
> callers to get ZONE_MOVABLE. Add __GFP_ZONE_MASK to mask lowest 3
> bits of GFP bitmasks.
> Modify some callers' gfp flag to update usage of address zone
> modifiers.
> Modify inline function gfp_zone to get better performance according
> to Matthew's suggestion.
> 
> Link: https://marc.info/?l=linux-mm=152596791931266=2
> 
> Huaisheng Ye (12):
>   include/linux/gfp.h: get rid of GFP_ZONE_TABLE/BAD
>   arch/x86/kernel/amd_gart_64: update usage of address zone modifiers
>   arch/x86/kernel/pci-calgary_64: update usage of address zone modifiers
>   drivers/iommu/amd_iommu: update usage of address zone modifiers
>   include/linux/dma-mapping: update usage of address zone modifiers
>   drivers/xen/swiotlb-xen: update usage of address zone modifiers
>   fs/btrfs/extent_io: update usage of address zone modifiers
>   drivers/block/zram/zram_drv: update usage of address zone modifiers
>   mm/vmpressure: update usage of address zone modifiers
>   mm/zsmalloc: update usage of address zone modifiers
>   include/linux/highmem: update usage of movableflags
>   arch/x86/include/asm/page.h: update usage of movableflags
> 
>  arch/x86/include/asm/page.h  |  3 +-
>  arch/x86/kernel/amd_gart_64.c|  2 +-
>  arch/x86/kernel/pci-calgary_64.c |  2 +-
>  drivers/block/zram/zram_drv.c|  6 +--
>  drivers/iommu/amd_iommu.c|  2 +-
>  drivers/xen/swiotlb-xen.c|  2 +-
>  fs/btrfs/extent_io.c |  2 +-
>  include/linux/dma-mapping.h  |  2 +-
>  include/linux/gfp.h  | 98 
> +---
>  include/linux/highmem.h  |  4 +-
>  mm/vmpressure.c  |  2 +-
>  mm/zsmalloc.c|  4 +-
>  12 files changed, 26 insertions(+), 103 deletions(-)
> 
> -- 
> 1.8.3.1
> 

-- 
Michal Hocko
SUSE Labs

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

Re: [Xen-devel] [PULL 00/15] xen-20180521-tag

[Stefano Stabellini]

On Tue, 22 May 2018, Peter Maydell wrote:
> On 21 May 2018 at 20:34, Stefano Stabellini  wrote:
> > The following changes since commit d32e41a1188e929cc0fb16829ce3736046951e39:
> >
> >   Merge remote-tracking branch 
> > 'remotes/famz/tags/docker-and-block-pull-request' into staging (2018-05-18 
> > 14:11:52 +0100)
> >
> > are available in the git repository at:
> >
> >
> >   http://xenbits.xenproject.org/git-http/people/sstabellini/qemu-dm.git 
> > tags/xen-20180521-tag
> >
> > for you to fetch changes up to f03df99f09ee0ca27ea2298a1b77438e7999044d:
> >
> >   xen_disk: be consistent with use of xendev and blkdev->xendev (2018-05-18 
> > 11:13:01 -0700)
> >
> > 
> > Xen 2018/05/21
> >
> 
> Hi Stefano -- my scripts can't find this tag. Did you forget to push
> it, perhaps?

Yes, I did. I'll take the opportunity to resend the whole series given
that there is a small mistake on patch #6.

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

Re: [Xen-devel] Xen and safety certification, Minutes of the meeting on Apr 4th

[Stefano Stabellini]

On Tue, 22 May 2018, Jarvis Roach wrote:
> > > For instance, here is another idea: we could have Xen boot multiple
> > > domains at boot time from device tree, as suggested in the dom0-less
> > > approach. All of the domains booted from Xen are "mission-critical".
> > > The first domain could still be dom0. Once booted, Dom0 can start
> > > other VMs, however, Xen would restrict Dom0 from doing any operations
> > > affecting the first set of mission-critical domains.
> > >
> 
> Does the first domain have to be dom0? Would it be possible to have domains 
> boot in parallel (especially if allocated to separate CPU cores) such that a 
> simple OS (like FreeRTOS) would complete booting before dom0/Linux? In other 
> words, does the hypervisor have any dependencies on dom0 having performed 
> certain functions (interrupt configuration, MMU table initialization, timers, 
> etc.) before it can create and start additional VMs?
> 

I don't think there are any dependencies except for xenstore and PV
protocol access. It should be possible to boot Dom0 and the other domain
in parallel, as long as the other domain is like a baremetal guest (no
PV network/disk access).

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

[Xen-devel] [PATCH 13/13] xen/arm: Avoid to use current everywhere in enter_hypervisor_head

[Julien Grall]

Using current is fairly expensive, so save up into a variable.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/traps.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 020b0b8eef..b1546f6907 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2024,8 +2024,10 @@ static void enter_hypervisor_head(struct cpu_user_regs 
*regs)
 {
 if ( guest_mode(regs) )
 {
+struct vcpu *v = current;
+
 /* If the guest has disabled the workaround, bring it back on. */
-if ( needs_ssbd_flip(current) )
+if ( needs_ssbd_flip(v) )
 arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 1, NULL);
 
 /*
@@ -2034,8 +2036,8 @@ static void enter_hypervisor_head(struct cpu_user_regs 
*regs)
  * but the crucial bit is "On taking a vSError interrupt, HCR_EL2.VSE
  * (alias of HCR.VA) is cleared to 0."
  */
-if ( current->arch.hcr_el2 & HCR_VA )
-current->arch.hcr_el2 = READ_SYSREG(HCR_EL2);
+if ( v->arch.hcr_el2 & HCR_VA )
+v->arch.hcr_el2 = READ_SYSREG(HCR_EL2);
 
 #ifdef CONFIG_NEW_VGIC
 /*
@@ -2045,11 +2047,11 @@ static void enter_hypervisor_head(struct cpu_user_regs 
*regs)
  * TODO: Investigate whether this is necessary to do on every
  * trap and how it can be optimised.
  */
-vtimer_update_irqs(current);
-vcpu_update_evtchn_irq(current);
+vtimer_update_irqs(v);
+vcpu_update_evtchn_irq(v);
 #endif
 
-vgic_sync_from_lrs(current);
+vgic_sync_from_lrs(v);
 }
 }
 
-- 
2.11.0


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

[Xen-devel] [PATCH 05/13] xen/arm: Add command line option to control SSBD mitigation

[Julien Grall]

On a system where the firmware implements ARCH_WORKAROUND_2, it may be
useful to either permanently enable or disable the workaround for cases
where the user decides that they'd rather not get a trap overhead, and
keep the mitigation permanently on or off instead of switching it on
exception entry/exit.

In any case, default to mitigation being enabled.

At the same time provide a accessor to know the state of the mitigation.

SIgned-off-by: Julien Grall 
---
 docs/misc/xen-command-line.markdown |  18 ++
 xen/arch/arm/cpuerrata.c| 115 
 xen/include/asm-arm/cpuerrata.h |  21 +++
 xen/include/asm-arm/smccc.h |   1 +
 4 files changed, 144 insertions(+), 11 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 8712a833a2..962028b6ed 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1756,6 +1756,24 @@ enforces the maximum theoretically necessary timeout of 
670ms. Any number
 is being interpreted as a custom timeout in milliseconds. Zero or boolean
 false disable the quirk workaround, which is also the default.
 
+### spec-ctrl (Arm)
+> `= List of [ ssbd=force-disable|runtime|force-enable ]`
+
+Controls for speculative execution sidechannel mitigations.
+
+The option `ssbd=` is used to control the state of Speculative Store
+Bypass Disable (SSBD) mitigation.
+
+* `ssbd=force-disable` will keep the mitigation permanently off. The guest
+will not be able to control the state of the mitigation.
+* `ssbd=runtime` will always turn on the mitigation when running in the
+hypervisor context. The guest will be to turn on/off the mitigation for
+itself by using the firmware interface ARCH\_WORKAROUND\_2.
+* `ssbd=force-enable` will keep the mitigation permanently on. The guest will
+not be able to control the state of the mitigation.
+
+By default SSBD will be mitigated at runtime (i.e `ssbd=runtime`).
+
 ### spec-ctrl (x86)
 > `= List of [ , xen=, {pv,hvm,msr-sc,rsb}=,
 >  bti-thunk=retpoline|lfence|jmp, {ibrs,ibpb,ssbd}= ]`
diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index bcea2eb6e5..f921721a66 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -237,6 +237,41 @@ static int enable_ic_inv_hardening(void *data)
 
 #ifdef CONFIG_ARM_SSBD
 
+enum ssbd_state ssbd_state = ARM_SSBD_RUNTIME;
+
+static int __init parse_spec_ctrl(const char *s)
+{
+const char *ss;
+int rc = 0;
+
+do {
+ss = strchr(s, ',');
+if ( !ss )
+ss = strchr(s, '\0');
+
+if ( !strncmp(s, "ssbd=", 5) )
+{
+s += 5;
+
+if ( !strncmp(s, "force-disable", ss - s) )
+ssbd_state = ARM_SSBD_FORCE_DISABLE;
+else if ( !strncmp(s, "runtime", ss - s) )
+ssbd_state = ARM_SSBD_RUNTIME;
+else if ( !strncmp(s, "force-enable", ss - s) )
+ssbd_state = ARM_SSBD_FORCE_ENABLE;
+else
+rc = -EINVAL;
+}
+else
+rc = -EINVAL;
+
+s = ss + 1;
+} while ( *ss );
+
+return rc;
+}
+custom_param("spec-ctrl", parse_spec_ctrl);
+
 /*
  * Assembly code may use the variable directly, so we need to make sure
  * it fits in a register.
@@ -246,25 +281,82 @@ DEFINE_PER_CPU_READ_MOSTLY(register_t, 
ssbd_callback_required);
 static bool has_ssbd_mitigation(const struct arm_cpu_capabilities *entry)
 {
 struct arm_smccc_res res;
-bool supported = true;
+bool required = true;
 
 if ( smccc_ver < SMCCC_VERSION(1, 1) )
 return false;
 
-/*
- * The probe function return value is either negative (unsupported
- * or mitigated), positive (unaffected), or zero (requires
- * mitigation). We only need to do anything in the last case.
- */
 arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID,
   ARM_SMCCC_ARCH_WORKAROUND_2_FID, );
-if ( (int)res.a0 != 0 )
-supported = false;
 
-if ( supported )
-this_cpu(ssbd_callback_required) = 1;
+switch ( (int)res.a0 )
+{
+case ARM_SMCCC_NOT_SUPPORTED:
+ssbd_state = ARM_SSBD_UNKNOWN;
+return false;
+
+case ARM_SMCCC_NOT_REQUIRED:
+ssbd_state = ARM_SSBD_MITIGATED;
+return false;
+
+case ARM_SMCCC_SUCCESS:
+required = true;
+break;
+
+case 1: /* Mitigation not required on this CPU. */
+required = false;
+break;
+
+default:
+ASSERT_UNREACHABLE();
+return false;
+}
+
+switch ( ssbd_state )
+{
+case ARM_SSBD_FORCE_DISABLE:
+{
+static bool once = true;
+
+if ( once )
+printk("%s disabled from command-line\n", entry->desc);
+once = false;
+
+arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 0, NULL);
+required = false;
+
+break;
+}
+
+case 

[Xen-devel] [PATCH 08/13] xen/arm: alternatives: Add dynamic patching feature

[Julien Grall]

This is based on the Linux commit dea5e2a4c5bc "arm64: alternatives: Add
dynamic patching feature" written by Marc Zyngier:

We've so far relied on a patching infrastructure that only gave us
a single alternative, without any way to provide a range of potential
replacement instructions. For a single feature, this is an all or
nothing thing.

It would be interesting to have a more flexible grained way of patching the
kernel though, where we could dynamically tune the code that gets injected.

In order to achive this, let's introduce a new form of dynamic patching,
assiciating a callback to a patching site. This callback gets source and
target locations of the patching request, as well as the number of
instructions to be patched.

Dynamic patching is declared with the new ALTERNATIVE_CB and alternative_cb
directives:
asm volatile(ALTERNATIVE_CB("mov %0, #0\n", callback)
 : "r" (v));
or

alternative_cb callback
mov x0, #0
alternative_cb_end

where callback is the C function computing the alternative.

Reviewed-by: Christoffer Dall 
Reviewed-by: Catalin Marinas 
Signed-off-by: Marc Zyngier 

This is patch of XSA-263.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/alternative.c| 48 +--
 xen/include/asm-arm/alternative.h | 44 +++
 2 files changed, 75 insertions(+), 17 deletions(-)

diff --git a/xen/arch/arm/alternative.c b/xen/arch/arm/alternative.c
index bd62183def..673150d1c0 100644
--- a/xen/arch/arm/alternative.c
+++ b/xen/arch/arm/alternative.c
@@ -30,6 +30,8 @@
 #include 
 #include 
 #include 
+/* XXX: Move ARCH_PATCH_INSN_SIZE out of livepatch.h */
+#include 
 #include 
 
 /* Override macros from asm/page.h to make them work with mfn_t */
@@ -94,6 +96,23 @@ static u32 get_alt_insn(const struct alt_instr *alt,
 return insn;
 }
 
+static void patch_alternative(const struct alt_instr *alt,
+  const uint32_t *origptr,
+  uint32_t *updptr, int nr_inst)
+{
+const uint32_t *replptr;
+unsigned int i;
+
+replptr = ALT_REPL_PTR(alt);
+for ( i = 0; i < nr_inst; i++ )
+{
+uint32_t insn;
+
+insn = get_alt_insn(alt, origptr + i, replptr + i);
+updptr[i] = cpu_to_le32(insn);
+}
+}
+
 /*
  * The region patched should be read-write to allow __apply_alternatives
  * to replacing the instructions when necessary.
@@ -105,33 +124,38 @@ static int __apply_alternatives(const struct alt_region 
*region,
 paddr_t update_offset)
 {
 const struct alt_instr *alt;
-const u32 *replptr, *origptr;
+const u32 *origptr;
 u32 *updptr;
+alternative_cb_t alt_cb;
 
 printk(XENLOG_INFO "alternatives: Patching with alt table %p -> %p\n",
region->begin, region->end);
 
 for ( alt = region->begin; alt < region->end; alt++ )
 {
-u32 insn;
-int i, nr_inst;
+int nr_inst;
 
-if ( !cpus_have_cap(alt->cpufeature) )
+/* Use ARM_CB_PATCH as an unconditional patch */
+if ( alt->cpufeature < ARM_CB_PATCH &&
+ !cpus_have_cap(alt->cpufeature) )
 continue;
 
-BUG_ON(alt->alt_len != alt->orig_len);
+if ( alt->cpufeature == ARM_CB_PATCH )
+BUG_ON(alt->alt_len != 0);
+else
+BUG_ON(alt->alt_len != alt->orig_len);
 
 origptr = ALT_ORIG_PTR(alt);
 updptr = (void *)origptr + update_offset;
-replptr = ALT_REPL_PTR(alt);
 
-nr_inst = alt->alt_len / sizeof(insn);
+nr_inst = alt->orig_len / ARCH_PATCH_INSN_SIZE;
 
-for ( i = 0; i < nr_inst; i++ )
-{
-insn = get_alt_insn(alt, origptr + i, replptr + i);
-*(updptr + i) = cpu_to_le32(insn);
-}
+if ( alt->cpufeature < ARM_CB_PATCH )
+alt_cb = patch_alternative;
+else
+alt_cb = ALT_REPL_PTR(alt);
+
+alt_cb(alt, origptr, updptr, nr_inst);
 
 /* Ensure the new instructions reached the memory and nuke */
 clean_and_invalidate_dcache_va_range(origptr,
diff --git a/xen/include/asm-arm/alternative.h 
b/xen/include/asm-arm/alternative.h
index 4e33d1cdf7..9b4b02811b 100644
--- a/xen/include/asm-arm/alternative.h
+++ b/xen/include/asm-arm/alternative.h
@@ -3,6 +3,8 @@
 
 #include 
 
+#define ARM_CB_PATCH ARM_NCAPS
+
 #ifndef __ASSEMBLY__
 
 #include 
@@ -18,16 +20,24 @@ struct alt_instr {
 };
 
 /* Xen: helpers used by common code. */
-#define __ALT_PTR(a,f) ((u32 *)((void *)&(a)->f + (a)->f))
+#define __ALT_PTR(a,f) ((void *)&(a)->f + (a)->f)
 #define ALT_ORIG_PTR(a)__ALT_PTR(a, orig_offset)
 

[Xen-devel] [PATCH 06/13] xen/arm: Add ARCH_WORKAROUND_2 support for guests

[Julien Grall]

In order to offer ARCH_WORKAROUND_2 support to guests, we need to track the
state of the workaround per-vCPU. The field 'pad' in cpu_info is now
repurposed to store flags easily accessible in assembly.

As the hypervisor will always run with the workaround enabled, we may
need to enable (on guest exit) or disable (on guest entry) the
workaround.

A follow-up patch will add fastpath for the workaround for arm64 guests.

This is part of XSA-263.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/domain.c |  8 
 xen/arch/arm/traps.c  | 20 
 xen/arch/arm/vsmc.c   | 37 +
 xen/include/asm-arm/current.h |  6 +-
 4 files changed, 70 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index e7b33e92fb..9168195a9c 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -21,6 +21,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -575,6 +576,13 @@ int vcpu_initialise(struct vcpu *v)
 if ( (rc = vcpu_vtimer_init(v)) != 0 )
 goto fail;
 
+/*
+ * The workaround 2 (i.e SSBD mitigation) is enabled by default if
+ * supported.
+ */
+if ( get_ssbd_state() == ARM_SSBD_RUNTIME )
+v->arch.cpu_info->flags |= CPUINFO_WORKAROUND_2_FLAG;
+
 return rc;
 
 fail:
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 5c18e918b0..020b0b8eef 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2011,10 +2011,23 @@ inject_abt:
 inject_iabt_exception(regs, gva, hsr.len);
 }
 
+static inline bool needs_ssbd_flip(struct vcpu *v)
+{
+if ( !check_workaround_ssbd() )
+return false;
+
+return !((v->arch.cpu_info->flags & CPUINFO_WORKAROUND_2_FLAG) &&
+ cpu_require_ssbd_mitigation());
+}
+
 static void enter_hypervisor_head(struct cpu_user_regs *regs)
 {
 if ( guest_mode(regs) )
 {
+/* If the guest has disabled the workaround, bring it back on. */
+if ( needs_ssbd_flip(current) )
+arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 1, NULL);
+
 /*
  * If we pended a virtual abort, preserve it until it gets cleared.
  * See ARM ARM DDI 0487A.j D1.14.3 (Virtual Interrupts) for details,
@@ -2260,6 +2273,13 @@ void leave_hypervisor_tail(void)
  */
 SYNCHRONIZE_SERROR(SKIP_SYNCHRONIZE_SERROR_ENTRY_EXIT);
 
+/*
+ * The hypervisor runs with the workaround always present.
+ * If the guest wants it disabled, so be it...
+ */
+if ( needs_ssbd_flip(current) )
+arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 0, NULL);
+
 return;
 }
 local_irq_enable();
diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
index 40a80d5760..c4ccae6030 100644
--- a/xen/arch/arm/vsmc.c
+++ b/xen/arch/arm/vsmc.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -104,6 +105,23 @@ static bool handle_arch(struct cpu_user_regs *regs)
 if ( cpus_have_cap(ARM_HARDEN_BRANCH_PREDICTOR) )
 ret = 0;
 break;
+case ARM_SMCCC_ARCH_WORKAROUND_2_FID:
+switch ( get_ssbd_state() )
+{
+case ARM_SSBD_UNKNOWN:
+case ARM_SSBD_FORCE_DISABLE:
+break;
+
+case ARM_SSBD_RUNTIME:
+ret = ARM_SMCCC_SUCCESS;
+break;
+
+case ARM_SSBD_FORCE_ENABLE:
+case ARM_SSBD_MITIGATED:
+ret = ARM_SMCCC_NOT_REQUIRED;
+break;
+}
+break;
 }
 
 set_user_reg(regs, 0, ret);
@@ -114,6 +132,25 @@ static bool handle_arch(struct cpu_user_regs *regs)
 case ARM_SMCCC_ARCH_WORKAROUND_1_FID:
 /* No return value */
 return true;
+
+case ARM_SMCCC_ARCH_WORKAROUND_2_FID:
+{
+bool enable = (uint32_t)get_user_reg(regs, 1);
+
+/*
+ * ARM_WORKAROUND_2_FID should only be called when mitigation
+ * state can be changed at runtime.
+ */
+if ( unlikely(get_ssbd_state() != ARM_SSBD_RUNTIME) )
+return true;
+
+if ( enable )
+get_cpu_info()->flags |= CPUINFO_WORKAROUND_2_FLAG;
+else
+get_cpu_info()->flags &= ~CPUINFO_WORKAROUND_2_FLAG;
+
+return true;
+}
 }
 
 return false;
diff --git a/xen/include/asm-arm/current.h b/xen/include/asm-arm/current.h
index 7a0971fdea..f9819b34fc 100644
--- a/xen/include/asm-arm/current.h
+++ b/xen/include/asm-arm/current.h
@@ -7,6 +7,10 @@
 #include 
 #include 
 
+/* Tell whether the guest vCPU enabled Workaround 2 (i.e variant 4) */
+#define CPUINFO_WORKAROUND_2_FLAG_SHIFT   0
+#define CPUINFO_WORKAROUND_2_FLAG (_AC(1, U) << 
CPUINFO_WORKAROUND_2_FLAG_SHIFT)
+
 #ifndef __ASSEMBLY__
 
 struct vcpu;
@@ -21,7 +25,7 

[Xen-devel] [PATCH 10/13] xen/arm64: Implement a fast path for handling SMCCC_ARCH_WORKAROUND_2

[Julien Grall]

The function ARM_SMCCC_ARCH_WORKAROUND_2 will be called by the guest for
enabling/disabling the ssbd mitigation. So we want the handling to
be as fast as possible.

The new sequence will forward guest's ARCH_WORKAROUND_2 call to EL3 and
also track the state of the workaround per-vCPU.

Note that since we need to execute branches, this always executes after
the spectre-v2 mitigation.

This code is based on KVM counterpart "arm64: KVM: Handle guest's
ARCH_WORKAROUND_2 requests" written by Marc Zyngier.

This is part of XSA-263.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/arm64/asm-offsets.c |  2 ++
 xen/arch/arm/arm64/entry.S   | 43 +++-
 xen/arch/arm/cpuerrata.c | 18 +
 3 files changed, 62 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/arm64/asm-offsets.c b/xen/arch/arm/arm64/asm-offsets.c
index ce24e44473..f5c696d092 100644
--- a/xen/arch/arm/arm64/asm-offsets.c
+++ b/xen/arch/arm/arm64/asm-offsets.c
@@ -22,6 +22,7 @@
 void __dummy__(void)
 {
OFFSET(UREGS_X0, struct cpu_user_regs, x0);
+   OFFSET(UREGS_X1, struct cpu_user_regs, x1);
OFFSET(UREGS_LR, struct cpu_user_regs, lr);
 
OFFSET(UREGS_SP, struct cpu_user_regs, sp);
@@ -45,6 +46,7 @@ void __dummy__(void)
BLANK();
 
DEFINE(CPUINFO_sizeof, sizeof(struct cpu_info));
+   OFFSET(CPUINFO_flags, struct cpu_info, flags);
 
OFFSET(VCPU_arch_saved_context, struct vcpu, arch.saved_context);
 
diff --git a/xen/arch/arm/arm64/entry.S b/xen/arch/arm/arm64/entry.S
index e2344e565f..8e25ff3997 100644
--- a/xen/arch/arm/arm64/entry.S
+++ b/xen/arch/arm/arm64/entry.S
@@ -1,4 +1,6 @@
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -241,7 +243,7 @@ guest_sync:
  * be encoded as an immediate for cmp.
  */
 eor w0, w0, #ARM_SMCCC_ARCH_WORKAROUND_1_FID
-cbnzw0, guest_sync_slowpath
+cbnzw0, check_wa2
 
 /*
  * Clobber both x0 and x1 to prevent leakage. Note that thanks
@@ -250,6 +252,45 @@ guest_sync:
 mov x1, xzr
 eret
 
+check_wa2:
+/* ARM_SMCCC_ARCH_WORKAROUND_2 handling */
+eor w0, w0, #ARM_SMCCC_ARCH_WORKAROUND_1_FID
+eor w0, w0, #ARM_SMCCC_ARCH_WORKAROUND_2_FID
+cbnzw0, guest_sync_slowpath
+#ifdef CONFIG_ARM_SSBD
+alternative_cb arm_enable_wa2_handling
+b   wa2_end
+alternative_cb_end
+/* Sanitize the argument */
+mov x0, #-(UREGS_kernel_sizeof - UREGS_X1)  /* x0 := offset of 
guest's x1 on the stack */
+ldr x1, [sp, x0]/* Load guest's x1 */
+cmp w1, wzr
+csetx1, ne
+
+/*
+ * Update the guest flag. At this stage sp point after the field
+ * guest_cpu_user_regs in cpu_info.
+ */
+adr_cpu_info x2
+ldr x0, [x2, #CPUINFO_flags]
+bfi x0, x1, #CPUINFO_WORKAROUND_2_FLAG_SHIFT, #1
+str x0, [x2, #CPUINFO_flags]
+
+/* Check that we actually need to perform the call */
+ldr_this_cpu x0, ssbd_callback_required, x2
+cbz x0, wa2_end
+
+mov w0, #ARM_SMCCC_ARCH_WORKAROUND_2_FID
+smc #0
+
+wa2_end:
+/* Don't leak data from the SMC call */
+mov x1, xzr
+mov x2, xzr
+mov x3, xzr
+#endif /* !CONFIG_ARM_SSBD */
+mov x0, xzr
+eret
 guest_sync_slowpath:
 /*
  * x0/x1 may have been scratch by the fast path above, so avoid
diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index f921721a66..54df4ff445 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /* Override macros from asm/page.h to make them work with mfn_t */
@@ -272,6 +273,23 @@ static int __init parse_spec_ctrl(const char *s)
 }
 custom_param("spec-ctrl", parse_spec_ctrl);
 
+/* Arm64 only for now as for Arm32 the workaround is currently handled in C. */
+#ifdef CONFIG_ARM_64
+void __init arm_enable_wa2_handling(const struct alt_instr *alt,
+const uint32_t *origptr,
+uint32_t *updptr, int nr_inst)
+{
+BUG_ON(nr_inst != 1);
+
+/*
+ * Only allow mitigation on guest ARCH_WORKAROUND_2 if the SSBD
+ * state allow it to be flipped.
+ */
+if ( get_ssbd_state() == ARM_SSBD_RUNTIME )
+*updptr = aarch64_insn_gen_nop();
+}
+#endif
+
 /*
  * Assembly code may use the variable directly, so we need to make sure
  * it fits in a register.
-- 
2.11.0


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

[Xen-devel] [PATCH 07/13] xen/arm: Simplify alternative patching

[Julien Grall]

This is part of XSA-263.

Signed-off-by: Julien Grall 

---
I am aware of the missing commit message here. I wanted to send the
series on the ML to get some feedback first.
---
 xen/arch/arm/alternative.c | 35 +--
 1 file changed, 13 insertions(+), 22 deletions(-)

diff --git a/xen/arch/arm/alternative.c b/xen/arch/arm/alternative.c
index 9ffdc475d6..bd62183def 100644
--- a/xen/arch/arm/alternative.c
+++ b/xen/arch/arm/alternative.c
@@ -97,12 +97,16 @@ static u32 get_alt_insn(const struct alt_instr *alt,
 /*
  * The region patched should be read-write to allow __apply_alternatives
  * to replacing the instructions when necessary.
+ *
+ * @update_offset: Offset between the region patched and the writable
+ * region for the update. 0 if the patched region is writable.
  */
-static int __apply_alternatives(const struct alt_region *region)
+static int __apply_alternatives(const struct alt_region *region,
+paddr_t update_offset)
 {
 const struct alt_instr *alt;
-const u32 *replptr;
-u32 *origptr;
+const u32 *replptr, *origptr;
+u32 *updptr;
 
 printk(XENLOG_INFO "alternatives: Patching with alt table %p -> %p\n",
region->begin, region->end);
@@ -118,6 +122,7 @@ static int __apply_alternatives(const struct alt_region 
*region)
 BUG_ON(alt->alt_len != alt->orig_len);
 
 origptr = ALT_ORIG_PTR(alt);
+updptr = (void *)origptr + update_offset;
 replptr = ALT_REPL_PTR(alt);
 
 nr_inst = alt->alt_len / sizeof(insn);
@@ -125,7 +130,7 @@ static int __apply_alternatives(const struct alt_region 
*region)
 for ( i = 0; i < nr_inst; i++ )
 {
 insn = get_alt_insn(alt, origptr + i, replptr + i);
-*(origptr + i) = cpu_to_le32(insn);
+*(updptr + i) = cpu_to_le32(insn);
 }
 
 /* Ensure the new instructions reached the memory and nuke */
@@ -162,9 +167,6 @@ static int __apply_alternatives_multi_stop(void *unused)
 paddr_t xen_size = _end - _start;
 unsigned int xen_order = get_order_from_bytes(xen_size);
 void *xenmap;
-struct virtual_region patch_region = {
-.list = LIST_HEAD_INIT(patch_region.list),
-};
 
 BUG_ON(patched);
 
@@ -178,30 +180,19 @@ static int __apply_alternatives_multi_stop(void *unused)
 BUG_ON(!xenmap);
 
 /*
- * If we generate a new branch instruction, the target will be
- * calculated in this re-mapped Xen region. So we have to register
- * this re-mapped Xen region as a virtual region temporarily.
- */
-patch_region.start = xenmap;
-patch_region.end = xenmap + xen_size;
-register_virtual_region(_region);
-
-/*
  * Find the virtual address of the alternative region in the new
  * mapping.
  * alt_instr contains relative offset, so the function
  * __apply_alternatives will patch in the re-mapped version of
  * Xen.
  */
-region.begin = (void *)__alt_instructions - (void *)_start + xenmap;
-region.end = (void *)__alt_instructions_end - (void *)_start + xenmap;
+region.begin = __alt_instructions;
+region.end = __alt_instructions_end;
 
-ret = __apply_alternatives();
+ret = __apply_alternatives(, xenmap - (void *)_start);
 /* The patching is not expected to fail during boot. */
 BUG_ON(ret != 0);
 
-unregister_virtual_region(_region);
-
 vunmap(xenmap);
 
 /* Barriers provided by the cache flushing */
@@ -235,7 +226,7 @@ int apply_alternatives(const struct alt_instr *start, const 
struct alt_instr *en
 .end = end,
 };
 
-return __apply_alternatives();
+return __apply_alternatives(, 0);
 }
 
 /*
-- 
2.11.0


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

[Xen-devel] [PATCH 09/13] xen/arm64: Add generic assembly macros

[Julien Grall]

Add assembly macros to simplify assembly code:
- adr_cpu_info: Get the address to the current cpu_info structure
- ldr_this_cpu: Load a per-cpu value

This is part of XSA-263.

Signed-off-by: Julien Grall 
---
 xen/include/asm-arm/arm64/macros.h | 25 +
 xen/include/asm-arm/macros.h   |  2 +-
 2 files changed, 26 insertions(+), 1 deletion(-)
 create mode 100644 xen/include/asm-arm/arm64/macros.h

diff --git a/xen/include/asm-arm/arm64/macros.h 
b/xen/include/asm-arm/arm64/macros.h
new file mode 100644
index 00..9c5e676b37
--- /dev/null
+++ b/xen/include/asm-arm/arm64/macros.h
@@ -0,0 +1,25 @@
+#ifndef __ASM_ARM_ARM64_MACROS_H
+#define __ASM_ARM_ARM64_MACROS_H
+
+/*
+ * @dst: Result of get_cpu_info()
+ */
+.macro  adr_cpu_info, dst
+add \dst, sp, #STACK_SIZE
+and \dst, \dst, #~(STACK_SIZE - 1)
+sub \dst, \dst, #CPUINFO_sizeof
+.endm
+
+/*
+ * @dst: Result of READ_ONCE(per_cpu(sym, smp_processor_id()))
+ * @sym: The name of the per-cpu variable
+ * @tmp: scratch register
+ */
+.macro  ldr_this_cpu, dst, sym, tmp
+ldr \dst, =per_cpu__\sym
+mrs \tmp, tpidr_el2
+ldr \dst, [\dst, \tmp]
+.endm
+
+#endif /* __ASM_ARM_ARM64_MACROS_H */
+
diff --git a/xen/include/asm-arm/macros.h b/xen/include/asm-arm/macros.h
index 5d837cb38b..1d4bb41d15 100644
--- a/xen/include/asm-arm/macros.h
+++ b/xen/include/asm-arm/macros.h
@@ -8,7 +8,7 @@
 #if defined (CONFIG_ARM_32)
 # include 
 #elif defined(CONFIG_ARM_64)
-/* No specific ARM64 macros for now */
+# include 
 #else
 # error "unknown ARM variant"
 #endif
-- 
2.11.0


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

[Xen-devel] [PATCH 03/13] xen/arm: setup: Check errata for boot CPU later on

[Julien Grall]

Some errata will rely on the SMCCC version which is detected by
psci_init().

This is part of XSA-263.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/setup.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 1d6f6bf37e..ac93de4786 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -171,8 +171,6 @@ static void __init processor_id(void)
 }
 
 processor_setup();
-
-check_local_cpu_errata();
 }
 
 void dt_unreserved_regions(paddr_t s, paddr_t e,
@@ -779,6 +777,12 @@ void __init start_xen(unsigned long boot_phys_offset,
 printk(XENLOG_INFO "SMP: Allowing %u CPUs\n", cpus);
 nr_cpu_ids = cpus;
 
+/*
+ * Some errata relies on SMCCC version which is detected by psci_init()
+ * (called from smp_init_cpus()).
+ */
+check_local_cpu_errata();
+
 init_xen_time();
 
 gic_init();
-- 
2.11.0


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

[Xen-devel] [PATCH 04/13] xen/arm: Add ARCH_WORKAROUND_2 probing

[Julien Grall]

As for Spectre variant-2, we rely on SMCCC 1.1 to provide the discovery
mechanism for detecting the SSBD mitigation.

A new capability is also allocated for that purpose, and a config
option.

This is part of XSA-263.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/Kconfig | 10 ++
 xen/arch/arm/cpuerrata.c | 39 +++
 xen/include/asm-arm/cpuerrata.h  | 21 +
 xen/include/asm-arm/cpufeature.h |  3 ++-
 xen/include/asm-arm/smccc.h  |  6 ++
 5 files changed, 78 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 8174c0c635..0e2d027060 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -73,6 +73,16 @@ config SBSA_VUART_CONSOLE
  Allows a guest to use SBSA Generic UART as a console. The
  SBSA Generic UART implements a subset of ARM PL011 UART.
 
+config ARM_SSBD
+   bool "Speculative Store Bypass Disable" if EXPERT = "y"
+   depends on HAS_ALTERNATIVE
+   default y
+   help
+ This enables mitigation of bypassing of previous stores by speculative
+ loads.
+
+ If unsure, say Y.
+
 endmenu
 
 menu "ARM errata workaround via the alternative framework"
diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index 1baa20654b..bcea2eb6e5 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -235,6 +235,39 @@ static int enable_ic_inv_hardening(void *data)
 
 #endif
 
+#ifdef CONFIG_ARM_SSBD
+
+/*
+ * Assembly code may use the variable directly, so we need to make sure
+ * it fits in a register.
+ */
+DEFINE_PER_CPU_READ_MOSTLY(register_t, ssbd_callback_required);
+
+static bool has_ssbd_mitigation(const struct arm_cpu_capabilities *entry)
+{
+struct arm_smccc_res res;
+bool supported = true;
+
+if ( smccc_ver < SMCCC_VERSION(1, 1) )
+return false;
+
+/*
+ * The probe function return value is either negative (unsupported
+ * or mitigated), positive (unaffected), or zero (requires
+ * mitigation). We only need to do anything in the last case.
+ */
+arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID,
+  ARM_SMCCC_ARCH_WORKAROUND_2_FID, );
+if ( (int)res.a0 != 0 )
+supported = false;
+
+if ( supported )
+this_cpu(ssbd_callback_required) = 1;
+
+return supported;
+}
+#endif
+
 #define MIDR_RANGE(model, min, max) \
 .matches = is_affected_midr_range,  \
 .midr_model = model,\
@@ -336,6 +369,12 @@ static const struct arm_cpu_capabilities arm_errata[] = {
 .enable = enable_ic_inv_hardening,
 },
 #endif
+#ifdef CONFIG_ARM_SSBD
+{
+.capability = ARM_SSBD,
+.matches = has_ssbd_mitigation,
+},
+#endif
 {},
 };
 
diff --git a/xen/include/asm-arm/cpuerrata.h b/xen/include/asm-arm/cpuerrata.h
index 4e45b237c8..e628d3ff56 100644
--- a/xen/include/asm-arm/cpuerrata.h
+++ b/xen/include/asm-arm/cpuerrata.h
@@ -27,9 +27,30 @@ static inline bool check_workaround_##erratum(void)  
   \
 
 CHECK_WORKAROUND_HELPER(766422, ARM32_WORKAROUND_766422, CONFIG_ARM_32)
 CHECK_WORKAROUND_HELPER(834220, ARM64_WORKAROUND_834220, CONFIG_ARM_64)
+CHECK_WORKAROUND_HELPER(ssbd, ARM_SSBD, CONFIG_ARM_SSBD)
 
 #undef CHECK_WORKAROUND_HELPER
 
+#ifdef CONFIG_ARM_SSBD
+
+#include 
+
+DECLARE_PER_CPU(register_t, ssbd_callback_required);
+
+static inline bool cpu_require_ssbd_mitigation(void)
+{
+return this_cpu(ssbd_callback_required);
+}
+
+#else
+
+static inline bool cpu_require_ssbd_mitigation(void)
+{
+return false;
+}
+
+#endif
+
 #endif /* __ARM_CPUERRATA_H__ */
 /*
  * Local variables:
diff --git a/xen/include/asm-arm/cpufeature.h b/xen/include/asm-arm/cpufeature.h
index e557a095af..2a5c075d3b 100644
--- a/xen/include/asm-arm/cpufeature.h
+++ b/xen/include/asm-arm/cpufeature.h
@@ -43,8 +43,9 @@
 #define SKIP_SYNCHRONIZE_SERROR_ENTRY_EXIT 5
 #define SKIP_CTXT_SWITCH_SERROR_SYNC 6
 #define ARM_HARDEN_BRANCH_PREDICTOR 7
+#define ARM_SSBD 8
 
-#define ARM_NCAPS   8
+#define ARM_NCAPS   9
 
 #ifndef __ASSEMBLY__
 
diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h
index 8342cc33fe..650744d28b 100644
--- a/xen/include/asm-arm/smccc.h
+++ b/xen/include/asm-arm/smccc.h
@@ -258,6 +258,12 @@ struct arm_smccc_res {
   ARM_SMCCC_OWNER_ARCH, \
   0x8000)
 
+#define ARM_SMCCC_ARCH_WORKAROUND_2_FID \
+ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+   ARM_SMCCC_CONV_32,   \
+   ARM_SMCCC_OWNER_ARCH,\
+   0x7FFF)
+
 /* SMCCC error codes */
 #define ARM_SMCCC_ERR_UNKNOWN_FUNCTION  (-1)
 #define ARM_SMCCC_NOT_SUPPORTED (-1)
-- 
2.11.0


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

[Xen-devel] [PATCH 11/13] xen/arm: Kconfig: Move HARDEN_BRANCH_PREDICTOR under "Architecture features"

[Julien Grall]

At the moment, HARDEN_BRANCH_PREDICTOR is not in any section making
impossible for the user to unselect it.

Also, it looks like we require to use 'expert = "y"' for showing the
option in expert mode.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/Kconfig | 34 +-
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 0e2d027060..4212c58171 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -83,6 +83,23 @@ config ARM_SSBD
 
  If unsure, say Y.
 
+config HARDEN_BRANCH_PREDICTOR
+   bool "Harden the branch predictor against aliasing attacks" if EXPERT = 
"y"
+   default y
+   help
+ Speculation attacks against some high-performance processors rely on
+ being able to manipulate the branch predictor for a victim context by
+ executing aliasing branches in the attacker context.  Such attacks
+ can be partially mitigated against by clearing internal branch
+ predictor state and limiting the prediction logic in some situations.
+
+ This config option will take CPU-specific actions to harden the
+ branch predictor against aliasing attacks and may rely on specific
+ instruction sequences or control bits being set by the system
+ firmware.
+
+ If unsure, say Y.
+
 endmenu
 
 menu "ARM errata workaround via the alternative framework"
@@ -197,23 +214,6 @@ config ARM64_ERRATUM_834220
 
 endmenu
 
-config HARDEN_BRANCH_PREDICTOR
-   bool "Harden the branch predictor against aliasing attacks" if EXPERT
-   default y
-   help
- Speculation attacks against some high-performance processors rely on
- being able to manipulate the branch predictor for a victim context by
- executing aliasing branches in the attacker context.  Such attacks
- can be partially mitigated against by clearing internal branch
- predictor state and limiting the prediction logic in some situations.
-
- This config option will take CPU-specific actions to harden the
- branch predictor against aliasing attacks and may rely on specific
- instruction sequences or control bits being set by the system
- firmware.
-
- If unsure, say Y.
-
 config ARM64_HARDEN_BRANCH_PREDICTOR
 def_bool y if ARM_64 && HARDEN_BRANCH_PREDICTOR
 
-- 
2.11.0


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

[Xen-devel] [PATCH 00/13] xen/arm: SSBD (aka Spectre-v4) mitigation (XSA-263)

[Julien Grall]

Hi all,

This patch series implement the Xen hypervisor side of the "Spectre-v4"
(CVE-2018-3639) mitigation known as "Speculative Store Bypass Disable"
(SSBD).

More information can be found at:
  https://bugs.chromium.org/p/project-zero/issues/detail?id=1528
  
https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability

For all released Arm Cortex-A that are affected by this issue, then the
preferred mitigation is simply to set a chicken bit in the firmware during
CPU initialization and therefore no change to Xen is required. Other CPUs
may require the chicken bit to be toggled dynamically (for example, when
switching between kernel-mode and hypervisor-mode) and this is achieve by
calling into EL3 via an SMC which has been published as part of the latest
SMCCC specification:
  
https://developer.arm.com/cache-speculation-vulnerability-firmware-specification

as well as an ATF update for the released ARM cores affected by SSBD:
  https://github.com/ARM-software/arm-trusted-firmware/pull/1392

These patches provide the following:
  1. Safe probing of firmware to establish which CPUs in the system
 require calling into EL3 as part of the mitigation
  2. A command-line option to force SSBD mitigation to be always on,
 always off, or dynamically toggled (default) for CPUs that require
 the EL3 call.
  3. An initial implementation of the call via Xen, which exposes the
 mitigation to the guest via an HVC interface.

This patch also provides bug fix and new infrastructure require to implement
the mitigation:
  1. Zeroed each vCPU stack
  2. Provide generic assembly macros
  3. Provide alternative callback (RFC)

A branch can be found with all the patches at:
https://xenbits.xen.org/git-http/people/julieng/xen-unstable.git
branch ssbd/v1

Cheers,

Julien Grall (13):
  xen/arm: domain: Zeroed the vCPU stack
  xen/arm64: entry: Use named label in guest_sync
  xen/arm: setup: Check errata for boot CPU later on
  xen/arm: Add ARCH_WORKAROUND_2 probing
  xen/arm: Add command line option to control SSBD mitigation
  xen/arm: Add ARCH_WORKAROUND_2 support for guests
  xen/arm: Simplify alternative patching
  xen/arm: alternatives: Add dynamic patching feature
  xen/arm64: Add generic assembly macros
  xen/arm64: Implement a fast path for handling SMCCC_ARCH_WORKAROUND_2
  xen/arm: Kconfig: Move HARDEN_BRANCH_PREDICTOR under "Architecture
features"
  xen/arm: smccc: Fix indentation in ARM_SMCCC_ARCH_WORKAROUND_1_FID
  xen/arm: Avoid to use current everywhere in enter_hypervisor_head

 docs/misc/xen-command-line.markdown |  18 +
 xen/arch/arm/Kconfig|  44 +++
 xen/arch/arm/alternative.c  |  79 +++
 xen/arch/arm/arm64/asm-offsets.c|   2 +
 xen/arch/arm/arm64/entry.S  |  49 +++-
 xen/arch/arm/cpuerrata.c| 150 
 xen/arch/arm/domain.c   |  12 +++
 xen/arch/arm/setup.c|   8 +-
 xen/arch/arm/traps.c|  32 ++--
 xen/arch/arm/vsmc.c |  37 +
 xen/include/asm-arm/alternative.h   |  44 +--
 xen/include/asm-arm/arm64/macros.h  |  25 ++
 xen/include/asm-arm/cpuerrata.h |  42 ++
 xen/include/asm-arm/cpufeature.h|   3 +-
 xen/include/asm-arm/current.h   |   6 +-
 xen/include/asm-arm/macros.h|   2 +-
 xen/include/asm-arm/smccc.h |  13 +++-
 17 files changed, 495 insertions(+), 71 deletions(-)
 create mode 100644 xen/include/asm-arm/arm64/macros.h

-- 
2.11.0


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

[Xen-devel] [PATCH 12/13] xen/arm: smccc: Fix indentation in ARM_SMCCC_ARCH_WORKAROUND_1_FID

[Julien Grall]

Signed-off-by: Julien Grall 
---
 xen/include/asm-arm/smccc.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h
index a6804cec99..74c13f8419 100644
--- a/xen/include/asm-arm/smccc.h
+++ b/xen/include/asm-arm/smccc.h
@@ -254,9 +254,9 @@ struct arm_smccc_res {
 
 #define ARM_SMCCC_ARCH_WORKAROUND_1_FID \
 ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
-  ARM_SMCCC_CONV_32,\
-  ARM_SMCCC_OWNER_ARCH, \
-  0x8000)
+   ARM_SMCCC_CONV_32,   \
+   ARM_SMCCC_OWNER_ARCH,\
+   0x8000)
 
 #define ARM_SMCCC_ARCH_WORKAROUND_2_FID \
 ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
-- 
2.11.0


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

[Xen-devel] [PATCH 02/13] xen/arm64: entry: Use named label in guest_sync

[Julien Grall]

This will improve readability for future changes.

This is part of XSA-263.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/arm64/entry.S | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/arm64/entry.S b/xen/arch/arm/arm64/entry.S
index ffa9a1c492..e2344e565f 100644
--- a/xen/arch/arm/arm64/entry.S
+++ b/xen/arch/arm/arm64/entry.S
@@ -226,11 +226,11 @@ guest_sync:
 mrs x1, esr_el2
 lsr x1, x1, #HSR_EC_SHIFT   /* x1 = ESR_EL2.EC */
 cmp x1, #HSR_EC_HVC64
-b.ne1f  /* Not a HVC skip fastpath. */
+b.neguest_sync_slowpath /* Not a HVC skip fastpath. */
 
 mrs x1, esr_el2
 and x1, x1, #0x /* Check the immediate [0:16] 
*/
-cbnzx1, 1f  /* should be 0 for HVC #0 */
+cbnzx1, guest_sync_slowpath /* should be 0 for HVC #0 */
 
 /*
  * Fastest path possible for ARM_SMCCC_ARCH_WORKAROUND_1.
@@ -241,7 +241,7 @@ guest_sync:
  * be encoded as an immediate for cmp.
  */
 eor w0, w0, #ARM_SMCCC_ARCH_WORKAROUND_1_FID
-cbnzw0, 1f
+cbnzw0, guest_sync_slowpath
 
 /*
  * Clobber both x0 and x1 to prevent leakage. Note that thanks
@@ -250,7 +250,7 @@ guest_sync:
 mov x1, xzr
 eret
 
-1:
+guest_sync_slowpath:
 /*
  * x0/x1 may have been scratch by the fast path above, so avoid
  * to save them.
-- 
2.11.0


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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt-xsm 12 guest-start  fail REGR. vs. 122357
 test-amd64-i386-libvirt  12 guest-start  fail REGR. vs. 122357
 test-amd64-i386-freebsd10-i386 11 guest-startfail REGR. vs. 122357
 test-amd64-amd64-libvirt-pair 21 guest-start/debian  fail REGR. vs. 122357
 test-amd64-i386-libvirt-xsm  12 guest-start  fail REGR. vs. 122357
 test-amd64-amd64-libvirt 12 guest-start  fail REGR. vs. 122357
 test-amd64-i386-freebsd10-amd64 11 guest-start   fail REGR. vs. 122357
 test-amd64-i386-libvirt-pair 21 guest-start/debian   fail REGR. vs. 122357
 test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail REGR. vs. 122357
 test-arm64-arm64-libvirt-xsm 12 guest-start  fail REGR. vs. 122357
 test-amd64-i386-qemuu-rhel6hvm-intel 10 redhat-install   fail REGR. vs. 122357
 test-amd64-amd64-qemuu-nested-intel 10 debian-hvm-install fail REGR. vs. 122357
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. 
vs. 122357
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 
122357
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail 
REGR. vs. 122357
 test-amd64-amd64-xl-qcow210 debian-di-installfail REGR. vs. 122357
 test-amd64-amd64-qemuu-nested-amd 10 debian-hvm-install  fail REGR. vs. 122357
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail 
REGR. vs. 122357
 test-amd64-amd64-xl-qemuu-win7-amd64 10 windows-install  fail REGR. vs. 122357
 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 
122357
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail 
REGR. vs. 122357
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. 
vs. 122357
 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install   fail REGR. vs. 122357
 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 
122357
 test-armhf-armhf-libvirt 12 guest-start  fail REGR. vs. 122357
 test-armhf-armhf-libvirt-xsm 12 guest-start  fail REGR. vs. 122357
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 122357
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail 
REGR. vs. 122357
 test-amd64-amd64-libvirt-vhd 10 debian-di-installfail REGR. vs. 122357
 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install   fail REGR. vs. 122357
 test-armhf-armhf-libvirt-raw 10 debian-di-installfail REGR. vs. 122357
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install  fail REGR. vs. 122357
 test-armhf-armhf-xl-vhd  10 debian-di-installfail REGR. vs. 122357

Tests which did not succeed, but are not blocking:
 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-xl-pvshim12 guest-start  fail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-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-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass

Re: [Xen-devel] [PATCH v4 1/2] xen/PVH: Set up GS segment for stack canary

[Boris Ostrovsky]

On 05/22/2018 12:32 PM, Jan Beulich wrote:
 On 22.05.18 at 18:20,  wrote:
>> On 05/22/2018 12:10 PM, Jan Beulich wrote:
>> On 22.05.18 at 17:15,  wrote:
 On Tue, May 22, 2018 at 9:57 AM, Jan Beulich  wrote:
 On 22.05.18 at 15:45,  wrote:
>> On Mon, May 21, 2018 at 11:54 PM, Boris Ostrovsky 
>>  
>> wrote:
>>> @@ -98,6 +101,12 @@ ENTRY(pvh_start_xen)
>>> /* 64-bit entry point. */
>>> .code64
>>>  1:
>>> +   /* Set base address in stack canary descriptor. */
>>> +   mov $MSR_GS_BASE,%ecx
>>> +   mov $canary, %rax
>>> +   cdq
>>> +   wrmsr
>> CDQ only sign-extends EAX to RAX.  What you really want is to move the
>> high 32-bits to EDX (or zero EDX if we can guarantee it is loaded
>> below 4G).
> What you describe is CDQE (AT name: CLTD); CDQ (AT: CLTQ)
> sign-extends EAX to EDX:EAX.
 But that would still be wrong, as it would set EDX to 0x if
 the kernel was loaded between 2G and 4G.  Looking closer at the code,
 we just left 32-bit mode, so we must have been loaded below 4G,
 therefore EDX must be zero.
>>> Ah, yes, indeed.
>> We are loading virtual address for $canary so we will always have EDX
>> set to 0x. Isn't that what we want?
> Oh, that's rather confusing - we're still running on the low 1:1
> mapping when we're here. But yes, by the time we enter C code
> (where the GS base starts to matter) we ought to be on the high
> mappings - if only there wasn't xen_prepare_pvh().

xen_prepare_pvh() (and whatever it might call) is the only reason for
this patch to exist. It's the only C call that we are making before
jumping to startup_64, which I assume will have to set up GS itself
before calling into C.

I didn't realize we are still on identity mapping. I'll clear EDX (and
load $_pa(canary)) then.

BTW, don't we have the same issue in startup_xen()?

-boris


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

[Xen-devel] [PATCH v2 1/2] docs/process: Add RUBRIC

[Ian Jackson]

Signed-off-by: Ian Jackson 
---
 docs/process/RUBRIC | 15 +++
 1 file changed, 15 insertions(+)
 create mode 100644 docs/process/RUBRIC

diff --git a/docs/process/RUBRIC b/docs/process/RUBRIC
new file mode 100644
index 000..78aca80
--- /dev/null
+++ b/docs/process/RUBRIC
@@ -0,0 +1,15 @@
+These process documents are used by those involved in releasing Xen to
+help keep the releases high quality, our release preparation
+well-organised, and to help avoid errors.
+
+They are living documents, and no special approval is needed to modify
+them beyond the usual acks for commit.  They should be updated as and
+when it seems expediant.
+
+Also, these documents are not to be slavishly followed.  Intelligent
+application of the guidelines means understanding, and giving effect
+to, the purpose behind any imprecation.
+
+Especially, the shell runes should not be executed blindly.  They are
+prompts to think about what should be done, and in what order; but
+often, the standard runes are not appropriate.
-- 
2.1.4


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

[Xen-devel] [PATCH v2 2/2] docs/process/xen-release-management: Lesson to learn

[Ian Jackson]

The 4.10 release preparation was significantly more hairy than ideal.
(We seem to have a good overall outcome despite, rather than because
of, our approach.)

This is the second time (at least) that we have come close to failure
by committing to a release date before the exact code to be released
is known and has been made and tested.

Evidently our docs makes it insufficiently clear not to do that.

CC: Lars Kurth 
CC: Julien Grall 
Acked-by: Juergen Gross 
Signed-off-by: Ian Jackson 
---
 docs/process/xen-release-management.pandoc | 5 +
 1 file changed, 5 insertions(+)

diff --git a/docs/process/xen-release-management.pandoc 
b/docs/process/xen-release-management.pandoc
index 2ff0665..eee5dcf 100644
--- a/docs/process/xen-release-management.pandoc
+++ b/docs/process/xen-release-management.pandoc
@@ -211,6 +211,11 @@ https://wiki.xenproject.org/wiki/Category:Xen_4.9
 Ask them to dry-run their checklist and confirm everything is OK. If not,
 arrange another RC and restart this checklist.
 
+7. Do not commit to a release date until
+
+* The exact xen.git commit id to be released is known.
+* That commit id has been satisfactorily tested.
+
 7. Give PR Personnel final go-ahead, and instruct Release Technician to make
 release deliverables (tags and tarballs - will usually be in place the day
 before the release). At this point, PR collateral will be sent to reporters
-- 
2.1.4


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

Re: [Xen-devel] [PATCH v4 1/2] xen/PVH: Set up GS segment for stack canary

[Jan Beulich]

>>> On 22.05.18 at 18:20,  wrote:
> On 05/22/2018 12:10 PM, Jan Beulich wrote:
> On 22.05.18 at 17:15,  wrote:
>>> On Tue, May 22, 2018 at 9:57 AM, Jan Beulich  wrote:
>>> On 22.05.18 at 15:45,  wrote:
> On Mon, May 21, 2018 at 11:54 PM, Boris Ostrovsky 
>  
> wrote:
>> @@ -98,6 +101,12 @@ ENTRY(pvh_start_xen)
>> /* 64-bit entry point. */
>> .code64
>>  1:
>> +   /* Set base address in stack canary descriptor. */
>> +   mov $MSR_GS_BASE,%ecx
>> +   mov $canary, %rax
>> +   cdq
>> +   wrmsr
> CDQ only sign-extends EAX to RAX.  What you really want is to move the
> high 32-bits to EDX (or zero EDX if we can guarantee it is loaded
> below 4G).
 What you describe is CDQE (AT name: CLTD); CDQ (AT: CLTQ)
 sign-extends EAX to EDX:EAX.
>>> But that would still be wrong, as it would set EDX to 0x if
>>> the kernel was loaded between 2G and 4G.  Looking closer at the code,
>>> we just left 32-bit mode, so we must have been loaded below 4G,
>>> therefore EDX must be zero.
>> Ah, yes, indeed.
> 
> We are loading virtual address for $canary so we will always have EDX
> set to 0x. Isn't that what we want?

Oh, that's rather confusing - we're still running on the low 1:1
mapping when we're here. But yes, by the time we enter C code
(where the GS base starts to matter) we ought to be on the high
mappings - if only there wasn't xen_prepare_pvh().

Jan



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

Re: [Xen-devel] [PATCH v4 1/2] xen/PVH: Set up GS segment for stack canary

[Boris Ostrovsky]

On 05/22/2018 12:10 PM, Jan Beulich wrote:
 On 22.05.18 at 17:15,  wrote:
>> On Tue, May 22, 2018 at 9:57 AM, Jan Beulich  wrote:
>> On 22.05.18 at 15:45,  wrote:
 On Mon, May 21, 2018 at 11:54 PM, Boris Ostrovsky 
  wrote:
> @@ -98,6 +101,12 @@ ENTRY(pvh_start_xen)
> /* 64-bit entry point. */
> .code64
>  1:
> +   /* Set base address in stack canary descriptor. */
> +   mov $MSR_GS_BASE,%ecx
> +   mov $canary, %rax
> +   cdq
> +   wrmsr
 CDQ only sign-extends EAX to RAX.  What you really want is to move the
 high 32-bits to EDX (or zero EDX if we can guarantee it is loaded
 below 4G).
>>> What you describe is CDQE (AT name: CLTD); CDQ (AT: CLTQ)
>>> sign-extends EAX to EDX:EAX.
>> But that would still be wrong, as it would set EDX to 0x if
>> the kernel was loaded between 2G and 4G.  Looking closer at the code,
>> we just left 32-bit mode, so we must have been loaded below 4G,
>> therefore EDX must be zero.
> Ah, yes, indeed.


We are loading virtual address for $canary so we will always have EDX
set to 0x. Isn't that what we want?

-borsi


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

Re: [Xen-devel] [PATCH v2] xen: Add acpu_sleep=s3_fake command-line option for testing

[George Dunlap]

On 05/22/2018 05:05 PM, Jan Beulich wrote:
 On 22.05.18 at 17:46,  wrote:
>>> Btw, so far you've only mentioned XPTI and BTI collectively enabled or
>>> disabled. Have you tried with one of them on and the other off?
>>
>> Just tried it.  bti=off crashes.  xpti=off works.
> 
> "works" as in produces a register dump, I assume?

No, xpti=off successfully goes into real S3 and comes back. :-)

 -George

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

Re: [Xen-devel] [PATCH v4 1/2] xen/PVH: Set up GS segment for stack canary

[Jan Beulich]

>>> On 22.05.18 at 17:15,  wrote:
> On Tue, May 22, 2018 at 9:57 AM, Jan Beulich  wrote:
> On 22.05.18 at 15:45,  wrote:
>>> On Mon, May 21, 2018 at 11:54 PM, Boris Ostrovsky 
>>>  wrote:
 @@ -98,6 +101,12 @@ ENTRY(pvh_start_xen)
 /* 64-bit entry point. */
 .code64
  1:
 +   /* Set base address in stack canary descriptor. */
 +   mov $MSR_GS_BASE,%ecx
 +   mov $canary, %rax
 +   cdq
 +   wrmsr
>>>
>>> CDQ only sign-extends EAX to RAX.  What you really want is to move the
>>> high 32-bits to EDX (or zero EDX if we can guarantee it is loaded
>>> below 4G).
>>
>> What you describe is CDQE (AT name: CLTD); CDQ (AT: CLTQ)
>> sign-extends EAX to EDX:EAX.
> 
> But that would still be wrong, as it would set EDX to 0x if
> the kernel was loaded between 2G and 4G.  Looking closer at the code,
> we just left 32-bit mode, so we must have been loaded below 4G,
> therefore EDX must be zero.

Ah, yes, indeed.

Jan



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

Re: [Xen-devel] [PATCH] tools: prepend to PKG_CONFIG_PATH when configuring qemu

[Ian Jackson]

Ian Jackson writes ("Re: [PATCH] tools: prepend to PKG_CONFIG_PATH when 
configuring qemu"):
> Juergen Gross writes ("Re: [PATCH] tools: prepend to PKG_CONFIG_PATH when 
> configuring qemu"):
> > On 26/04/18 19:41, Stewart Hildebrand wrote:
> > > A user may choose to set his/her own PKG_CONFIG_PATH, which is useful in 
> > > the
> > > case of cross-compiling.  We don't want to completely override the
> > > PKG_CONFIG_PATH, just add to it.
> > > 
> > > Signed-off-by: Stewart Hildebrand 
> > 
> > Release-acked-by: Juergen Gross 
> 
> Thanks all.  Applied and queued for backport.

I have applied this to staging-4.10 and staging-4.9.  4.8 and earlier
do not mess about with PKG_CONFIG_PATH so that's as far as it needs to
go.

Thanks,
Ian.

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

Re: [Xen-devel] Xen 4.8.4 about due

[Jan Beulich]

>>> On 22.05.18 at 17:52,  wrote:
> On Fri, May 18, 2018 at 12:40 PM, Jan Beulich  wrote:
>> this should go out in a week or two. Please point out backport candidates you
>> find missing from its staging branch, but which you consider relevant.
> 
> XPTI speed-ups?

I don't have backports of them farther than to 4.9 yet, and I don't want
to hold the release for them.

Jan



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

Re: [Xen-devel] [PATCH v2] xen: Add acpu_sleep=s3_fake command-line option for testing

[Jan Beulich]

>>> On 22.05.18 at 17:46,  wrote:
>> Btw, so far you've only mentioned XPTI and BTI collectively enabled or
>> disabled. Have you tried with one of them on and the other off?
> 
> Just tried it.  bti=off crashes.  xpti=off works.

"works" as in produces a register dump, I assume?

Jan



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

Re: [Xen-devel] [PATCH v2] xen: Add acpu_sleep=s3_fake command-line option for testing

[Jan Beulich]

>>> On 22.05.18 at 17:25,  wrote:
> With your code dump patch (sorry for the wrapping):
> 
> (XEN) *** DOUBLE FAULT ***
> (XEN) [ Xen-4.11-rc  x86_64  debug=y   Not tainted ]
> (XEN) CPU:0
> (XEN) RIP:e008:[] handle_exception+0x9c/0xff
> (XEN) RFLAGS: 00010006   CONTEXT: hypervisor
> (XEN) rax: c900402040d8   rbx:    rcx: 0003
> (XEN) rdx:    rsi:    rdi: 
> (XEN) rbp: 36ffbfdfbf07   rsp: c90040204000   r8:  
> (XEN) r9:     r10:    r11: 
> (XEN) r12:    r13:    r14: c90040207fff
> (XEN) r15:    cr0: 8005003b   cr4: 2660
> (XEN) cr3: 00019200a000   cr2: c90040203ff8
> (XEN) fsb: 7f800083d700   gsb: 88003dc4   gss: 
> (XEN) ds: 002b   es: 002b   fs:    gs:    ss: e010   cs: e008
> (XEN) Xen code around  (handle_exception+0x9c/0xff):
> (XEN)  00 f3 90 0f ae e8 eb f9  07 00 00 00 f3 90 0f ae e8 eb f9 83

So that's a CALL (in the RSB stashing loop), meaning presumably the
page right below RSP is not present (ballooned out?) or r/o. I'm afraid
we may have accumulated a rather deep stack already, making it
rather cumbersome to unwind all of that and find where badness
started.

Jan



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

Re: [Xen-devel] Xen 4.8.4 about due

[George Dunlap]

On Fri, May 18, 2018 at 12:40 PM, Jan Beulich  wrote:
> All,
>
> this should go out in a week or two. Please point out backport candidates you
> find missing from its staging branch, but which you consider relevant.

XPTI speed-ups?

 -George

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

Re: [Xen-devel] [PATCH v2] xen: Add acpu_sleep=s3_fake command-line option for testing

[George Dunlap]

On 05/22/2018 04:32 PM, Jan Beulich wrote:
 On 22.05.18 at 16:50,  wrote:
>> In fact, with `s3_fake` enabled, Xen just hangs when XPTI / BTI are
>> enabled; but with it disabled, I actually get a stack trace.  Serial
>> output and xen-syms.map attached.
> 
> Interesting (not sure if I simply didn't pay attention before):
> 
> (XEN) *** DOUBLE FAULT ***
> (XEN) [ Xen-4.11-rc  x86_64  debug=y   Not tainted ]
> (XEN) CPU:0
> (XEN) RIP:e008:[] handle_exception+0x9c/0xff
> (XEN) RFLAGS: 00010006   CONTEXT: hypervisor
> (XEN) rax: c900402140b8   rbx:    rcx: 0005
> (XEN) rdx:    rsi:    rdi: 
> (XEN) rbp: 36ffbfdebf27   rsp: c90040214000   r8:  
> (XEN) r9:     r10:    r11: 
> (XEN) r12:    r13:    r14: c90040217fff
> (XEN) r15:    cr0: 8005003b   cr4: 2660
> (XEN) cr3: 00019200a000   cr2: c90040213ff8
> (XEN) fsb:    gsb: 88003dcc   gss: 
> (XEN) ds: 002b   es: 002b   fs: 8e00   gs: 87c1   ss: e010   cs: e008
> (XEN) Current stack base c9004021 differs from expected 
> 8300dfa8
> (XEN) Valid stack range: c90040216000-c90040218000, 
> sp=c90040214000, tss.rsp0=8300dfa87fa0
> 
> We're in handle_exception, but on a guest (presumably Dom0) kernel stack.
> 
> The selector values in FS and GS are also highly suspicious.
> 
> I can't explain either for the moment, as bypassing do_suspend_lowlevel()
> ought to mean that none of TR, FS, or GS get touched at all.

Actually I didn't bypass it -- this is without s3_fake.  With s3_fake it
hangs but I don't get any output at all.

> Looking at
> the flow of execution I wonder though whether your opt_fake_s3 wasn't
> better placed further down the call tree, e.g. in acpi_enter_sleep_state().
> That would cause more of the involved code path to be tested.

That sounds generally useful -- I'll take a look at that.

> Btw, so far you've only mentioned XPTI and BTI collectively enabled or
> disabled. Have you tried with one of them on and the other off?

Just tried it.  bti=off crashes.  xpti=off works.

 -George

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

[Xen-devel] [PATCH v3 1/8] mtrr: introduce mask to get VCNT from MTRRcap MSR

[Roger Pau Monne]

No functional change.

Signed-off-by: Roger Pau Monné 
Reviewed-by: Jan Beulich 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
Changes since v3:
 - Rebase on top of Jan's MTRR fixes.

Changes since v2:
 - Use unsigned int instead of uint8_t in mtrr_pat_not_equal.
---
 xen/arch/x86/cpu/mtrr/main.c| 2 +-
 xen/arch/x86/hvm/mtrr.c | 8 
 xen/include/asm-x86/msr-index.h | 2 ++
 3 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/cpu/mtrr/main.c b/xen/arch/x86/cpu/mtrr/main.c
index 56f71a6e1f..e9df53f00d 100644
--- a/xen/arch/x86/cpu/mtrr/main.c
+++ b/xen/arch/x86/cpu/mtrr/main.c
@@ -95,7 +95,7 @@ static void __init set_num_var_ranges(void)
config = 2;
else if (is_cpu(CENTAUR))
config = 8;
-   num_var_ranges = config & 0xff;
+   num_var_ranges = MASK_EXTR(config, MTRRcap_VCNT);
 }
 
 static void __init init_table(void)
diff --git a/xen/arch/x86/hvm/mtrr.c b/xen/arch/x86/hvm/mtrr.c
index a61cc1e6dc..c298369044 100644
--- a/xen/arch/x86/hvm/mtrr.c
+++ b/xen/arch/x86/hvm/mtrr.c
@@ -78,7 +78,7 @@ static uint8_t __read_mostly pat_entry_tbl[PAT_TYPE_NUMS] =
 bool_t is_var_mtrr_overlapped(const struct mtrr_state *m)
 {
 unsigned int seg, i;
-unsigned int num_var_ranges = (uint8_t)m->mtrr_cap;
+unsigned int num_var_ranges = MASK_EXTR(m->mtrr_cap, MTRRcap_VCNT);
 
 for ( i = 0; i < num_var_ranges; i++ )
 {
@@ -193,7 +193,7 @@ static int get_mtrr_type(const struct mtrr_state *m,
uint8_t overlap_mtrr = 0;
uint8_t overlap_mtrr_pos = 0;
uint64_tmask = -(uint64_t)PAGE_SIZE << order;
-   unsigned int seg, num_var_ranges = m->mtrr_cap & 0xff;
+   unsigned int seg, num_var_ranges = MASK_EXTR(m->mtrr_cap, MTRRcap_VCNT);
 
if ( unlikely(!(m->enabled & 0x2)) )
return MTRR_TYPE_UNCACHABLE;
@@ -483,7 +483,7 @@ bool mtrr_pat_not_equal(const struct vcpu *vd, const struct 
vcpu *vs)
 
 if ( md->enabled & 2 )
 {
-unsigned int num_var_ranges = (uint8_t)md->mtrr_cap;
+unsigned int num_var_ranges = MASK_EXTR(md->mtrr_cap, MTRRcap_VCNT);
 
 /* Test default type MSR. */
 if ( md->def_type != ms->def_type )
@@ -499,7 +499,7 @@ bool mtrr_pat_not_equal(const struct vcpu *vd, const struct 
vcpu *vs)
 return true;
 
 /* Test variable ranges. */
-if ( num_var_ranges != (uint8_t)ms->mtrr_cap ||
+if ( num_var_ranges != MASK_EXTR(ms->mtrr_cap, MTRRcap_VCNT) ||
  memcmp(md->var_ranges, ms->var_ranges,
 num_var_ranges * sizeof(*md->var_ranges)) )
 return true;
diff --git a/xen/include/asm-x86/msr-index.h b/xen/include/asm-x86/msr-index.h
index 8fbccc88a7..95bb66916c 100644
--- a/xen/include/asm-x86/msr-index.h
+++ b/xen/include/asm-x86/msr-index.h
@@ -60,6 +60,8 @@
 #define ATM_LNC_C6_AUTO_DEMOTE (1UL << 25)
 
 #define MSR_MTRRcap0x00fe
+#define MTRRcap_VCNT   0x00ff
+
 #define MSR_IA32_BBL_CR_CTL0x0119
 
 #define MSR_IA32_SYSENTER_CS   0x0174
-- 
2.17.0


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

[Xen-devel] [PATCH v3 7/8] libxc/pvh: set default MTRR type to write-back

[Roger Pau Monne]

And enable MTRR. This allows to provide a sane initial MTRR state for
PVH DomUs. This will have to be expanded when pci-passthrough support
is added to PVH guests, so that MMIO regions of devices are set as
UC.

Note that initial MTRR setup is done by hvmloader for HVM guests,
that's not used by PVH guests.

Signed-off-by: Roger Pau Monné 
Acked-by: Wei Liu 

Cc: Ian Jackson 
Cc: Wei Liu 
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 tools/libxc/xc_dom_x86.c | 44 
 1 file changed, 44 insertions(+)

diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index e33a28847d..d28ff4d7e9 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -53,6 +53,9 @@
 #define X86_CR0_PE 0x01
 #define X86_CR0_ET 0x10
 
+#define MTRR_TYPE_WRBACK 6
+#define MTRR_DEF_TYPE_ENABLE (1u << 11)
+
 #define SPECIALPAGE_PAGING   0
 #define SPECIALPAGE_ACCESS   1
 #define SPECIALPAGE_SHARING  2
@@ -931,6 +934,20 @@ static int vcpu_x86_64(struct xc_dom_image *dom)
 return rc;
 }
 
+const static void *hvm_get_save_record(const void *ctx, unsigned int type,
+   unsigned int instance)
+{
+const struct hvm_save_descriptor *header;
+
+for ( header = ctx;
+  header->typecode != HVM_SAVE_CODE(END);
+  ctx += sizeof(*header) + header->length, header = ctx )
+if ( header->typecode == type && header->instance == instance )
+return ctx + sizeof(*header);
+
+return NULL;
+}
+
 static int vcpu_hvm(struct xc_dom_image *dom)
 {
 struct {
@@ -938,9 +955,12 @@ static int vcpu_hvm(struct xc_dom_image *dom)
 HVM_SAVE_TYPE(HEADER) header;
 struct hvm_save_descriptor cpu_d;
 HVM_SAVE_TYPE(CPU) cpu;
+struct hvm_save_descriptor mtrr_d;
+HVM_SAVE_TYPE(MTRR) mtrr;
 struct hvm_save_descriptor end_d;
 HVM_SAVE_TYPE(END) end;
 } bsp_ctx;
+const HVM_SAVE_TYPE(MTRR) *mtrr_record;
 uint8_t *full_ctx = NULL;
 int rc;
 
@@ -1014,6 +1034,30 @@ static int vcpu_hvm(struct xc_dom_image *dom)
 if ( dom->start_info_seg.pfn )
 bsp_ctx.cpu.rbx = dom->start_info_seg.pfn << PAGE_SHIFT;
 
+/* Set the MTRR. */
+bsp_ctx.mtrr_d.typecode = HVM_SAVE_CODE(MTRR);
+bsp_ctx.mtrr_d.instance = 0;
+bsp_ctx.mtrr_d.length = HVM_SAVE_LENGTH(MTRR);
+
+mtrr_record = hvm_get_save_record(full_ctx, HVM_SAVE_CODE(MTRR), 0);
+if ( !mtrr_record )
+{
+xc_dom_panic(dom->xch, XC_INTERNAL_ERROR,
+ "%s: unable to get MTRR save record", __func__);
+goto out;
+}
+
+memcpy(_ctx.mtrr, mtrr_record, sizeof(bsp_ctx.mtrr));
+
+/* TODO: maybe this should be a firmware option instead? */
+if ( !dom->device_model )
+/*
+ * Enable MTRR, set default type to WB.
+ * TODO: add MMIO areas as UC when passthrough is supported.
+ */
+bsp_ctx.mtrr.msr_mtrr_def_type = MTRR_TYPE_WRBACK |
+ MTRR_DEF_TYPE_ENABLE;
+
 /* Set the end descriptor. */
 bsp_ctx.end_d.typecode = HVM_SAVE_CODE(END);
 bsp_ctx.end_d.instance = 0;
-- 
2.17.0


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

[Xen-devel] [PATCH v3 3/8] x86/mtrr: split "enabled" field into two boolean flags

[Roger Pau Monne]

From: Jan Beulich 

The code hopefully is more readable this way.

Also switch have_fixed to bool, seeing that it already is used as a
boolean.

Signed-off-by: Jan Beulich 
[switched to use MASK_*]
Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/cpu/mtrr/generic.c | 14 +-
 xen/arch/x86/hvm/hvm.c  |  6 --
 xen/arch/x86/hvm/mtrr.c | 23 ++-
 xen/include/asm-x86/msr-index.h |  2 ++
 xen/include/asm-x86/mtrr.h  |  5 +++--
 5 files changed, 32 insertions(+), 18 deletions(-)

diff --git a/xen/arch/x86/cpu/mtrr/generic.c b/xen/arch/x86/cpu/mtrr/generic.c
index 7ba0c3f0fe..09763654be 100644
--- a/xen/arch/x86/cpu/mtrr/generic.c
+++ b/xen/arch/x86/cpu/mtrr/generic.c
@@ -80,7 +80,8 @@ void __init get_mtrr_state(void)
 
rdmsrl(MSR_MTRRdefType, msr_content);
mtrr_state.def_type = (msr_content & 0xff);
-   mtrr_state.enabled = (msr_content & 0xc00) >> 10;
+   mtrr_state.enabled = MASK_EXTR(msr_content, MTRRdefType_E);
+   mtrr_state.fixed_enabled = MASK_EXTR(msr_content, MTRRdefType_FE);
 
/* Store mtrr_cap for HVM MTRR virtualisation. */
rdmsrl(MSR_MTRRcap, mtrr_state.mtrr_cap);
@@ -159,7 +160,7 @@ static void __init print_mtrr_state(const char *level)
unsigned int base = 0, step = 0x1;
 
printk("%sMTRR fixed ranges %sabled:\n", level,
-  mtrr_state.enabled & 1 ? "en" : "dis");
+  mtrr_state.fixed_enabled ? "en" : "dis");
for (; block->ranges; ++block, step >>= 2) {
for (i = 0; i < block->ranges; ++i, fr += 8) {
print_fixed(base, step, fr, level);
@@ -169,7 +170,7 @@ static void __init print_mtrr_state(const char *level)
print_fixed_last(level);
}
printk("%sMTRR variable ranges %sabled:\n", level,
-  mtrr_state.enabled & 2 ? "en" : "dis");
+  mtrr_state.enabled ? "en" : "dis");
width = (paddr_bits - PAGE_SHIFT + 3) / 4;
 
for (i = 0; i < num_var_ranges; ++i) {
@@ -383,8 +384,11 @@ static unsigned long set_mtrr_state(void)
/*  Set_mtrr_restore restores the old value of MTRRdefType,
   so to set it we fiddle with the saved value  */
if ((deftype & 0xff) != mtrr_state.def_type
-   || ((deftype & 0xc00) >> 10) != mtrr_state.enabled) {
-   deftype = (deftype & ~0xcff) | mtrr_state.def_type | 
(mtrr_state.enabled << 10);
+   || MASK_EXTR(deftype, MTRRdefType_E) != mtrr_state.enabled
+   || MASK_EXTR(deftype, MTRRdefType_FE) != mtrr_state.fixed_enabled) {
+   deftype = (deftype & ~0xcff) | mtrr_state.def_type |
+ MASK_INSR(mtrr_state.enabled, MTRRdefType_E) |
+ MASK_INSR(mtrr_state.fixed_enabled, MTRRdefType_FE);
change_mask |= MTRR_CHANGE_MASK_DEFTYPE;
}
 
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index c23983cdff..247b3eb1bd 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3468,8 +3468,10 @@ int hvm_msr_read_intercept(unsigned int msr, uint64_t 
*msr_content)
 case MSR_MTRRdefType:
 if ( !d->arch.cpuid->basic.mtrr )
 goto gp_fault;
-*msr_content = v->arch.hvm_vcpu.mtrr.def_type
-| (v->arch.hvm_vcpu.mtrr.enabled << 10);
+*msr_content = v->arch.hvm_vcpu.mtrr.def_type |
+   MASK_INSR(v->arch.hvm_vcpu.mtrr.enabled, MTRRdefType_E) 
|
+   MASK_INSR(v->arch.hvm_vcpu.mtrr.fixed_enabled,
+ MTRRdefType_FE);
 break;
 case MSR_MTRRfix64K_0:
 if ( !d->arch.cpuid->basic.mtrr )
diff --git a/xen/arch/x86/hvm/mtrr.c b/xen/arch/x86/hvm/mtrr.c
index 654299a198..c181a7a3d0 100644
--- a/xen/arch/x86/hvm/mtrr.c
+++ b/xen/arch/x86/hvm/mtrr.c
@@ -195,11 +195,11 @@ static int get_mtrr_type(const struct mtrr_state *m,
uint64_tmask = -(uint64_t)PAGE_SIZE << order;
unsigned int seg, num_var_ranges = MASK_EXTR(m->mtrr_cap, MTRRcap_VCNT);
 
-   if ( unlikely(!(m->enabled & 0x2)) )
+   if ( unlikely(!m->enabled) )
return MTRR_TYPE_UNCACHABLE;
 
pa &= mask;
-   if ( (pa < 0x10) && (m->enabled & 1) )
+   if ( (pa < 0x10) && m->fixed_enabled )
{
/* Fixed range MTRR takes effect. */
uint32_t addr = (uint32_t)pa, index;
@@ -391,7 +391,8 @@ bool_t mtrr_def_type_msr_set(struct domain *d, struct 
mtrr_state *m,
  uint64_t msr_content)
 {
 uint8_t def_type = msr_content & 0xff;
-uint8_t enabled = (msr_content >> 10) & 0x3;
+bool fixed_enabled = MASK_EXTR(msr_content, MTRRdefType_FE);
+bool enabled = MASK_EXTR(msr_content, MTRRdefType_E);
 
 if ( 

[Xen-devel] [PATCH v3 2/8] x86/HVM: improve MTRR load checks

[Roger Pau Monne]

From: Jan Beulich 

We should not assume that the incoming set of values contains exactly
MTRR_VCNT variable range MSRs. Permit a smaller amount and reject a
bigger one. As a result the save path then also needs to no longer use
a fixed upper bound, in turn requiring unused space in the save record
to be zeroed up front.

Also slightly refine types where appropriate.

Signed-off-by: Jan Beulich 
[switch to use MASK_EXTR to get VCNT]
Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/hvm/mtrr.c | 28 ++--
 1 file changed, 18 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/hvm/mtrr.c b/xen/arch/x86/hvm/mtrr.c
index c298369044..654299a198 100644
--- a/xen/arch/x86/hvm/mtrr.c
+++ b/xen/arch/x86/hvm/mtrr.c
@@ -673,22 +673,22 @@ int hvm_set_mem_pinned_cacheattr(struct domain *d, 
uint64_t gfn_start,
 
 static int hvm_save_mtrr_msr(struct domain *d, hvm_domain_context_t *h)
 {
-int i;
 struct vcpu *v;
-struct hvm_hw_mtrr hw_mtrr;
-struct mtrr_state *mtrr_state;
+
 /* save mtrr */
 for_each_vcpu(d, v)
 {
-mtrr_state = >arch.hvm_vcpu.mtrr;
+const struct mtrr_state *mtrr_state = >arch.hvm_vcpu.mtrr;
+struct hvm_hw_mtrr hw_mtrr = {
+.msr_mtrr_def_type = mtrr_state->def_type |
+ (mtrr_state->enabled << 10),
+.msr_mtrr_cap  = mtrr_state->mtrr_cap,
+};
+unsigned int i;
 
 hvm_get_guest_pat(v, _mtrr.msr_pat_cr);
 
-hw_mtrr.msr_mtrr_def_type = mtrr_state->def_type
-| (mtrr_state->enabled << 10);
-hw_mtrr.msr_mtrr_cap = mtrr_state->mtrr_cap;
-
-for ( i = 0; i < MTRR_VCNT; i++ )
+for ( i = 0; i < MASK_EXTR(hw_mtrr.msr_mtrr_cap, MTRRcap_VCNT); i++ )
 {
 /* save physbase */
 hw_mtrr.msr_mtrr_var[i*2] =
@@ -726,6 +726,14 @@ static int hvm_load_mtrr_msr(struct domain *d, 
hvm_domain_context_t *h)
 if ( hvm_load_entry(MTRR, h, _mtrr) != 0 )
 return -EINVAL;
 
+if ( MASK_EXTR(hw_mtrr.msr_mtrr_cap, MTRRcap_VCNT) > MTRR_VCNT )
+{
+dprintk(XENLOG_G_ERR,
+"HVM restore: %pv: too many (%lu) variable range MTRRs\n",
+v, MASK_EXTR(hw_mtrr.msr_mtrr_cap, MTRRcap_VCNT));
+return -EINVAL;
+}
+
 mtrr_state = >arch.hvm_vcpu.mtrr;
 
 hvm_set_guest_pat(v, hw_mtrr.msr_pat_cr);
@@ -735,7 +743,7 @@ static int hvm_load_mtrr_msr(struct domain *d, 
hvm_domain_context_t *h)
 for ( i = 0; i < NUM_FIXED_MSR; i++ )
 mtrr_fix_range_msr_set(d, mtrr_state, i, hw_mtrr.msr_mtrr_fixed[i]);
 
-for ( i = 0; i < MTRR_VCNT; i++ )
+for ( i = 0; i < MASK_EXTR(hw_mtrr.msr_mtrr_cap, MTRRcap_VCNT); i++ )
 {
 mtrr_var_range_msr_set(d, mtrr_state,
MSR_IA32_MTRR_PHYSBASE(i),
-- 
2.17.0


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

[Xen-devel] [PATCH v3 6/8] hvm/mtrr: copy hardware state for Dom0

[Roger Pau Monne]

Copy the state found on the hardware when creating a PVH Dom0. Since
the memory map provided to a PVH Dom0 is based on the native one using
the same set of MTRR ranges should provide Dom0 with a sane MTRR state
without having to manually build it in Xen.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
Changes since v1:
 - Introduce and use the FE shift into the deftype MTRR MSR.
---
 xen/arch/x86/hvm/mtrr.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/xen/arch/x86/hvm/mtrr.c b/xen/arch/x86/hvm/mtrr.c
index 37ac3271d6..d69670742b 100644
--- a/xen/arch/x86/hvm/mtrr.c
+++ b/xen/arch/x86/hvm/mtrr.c
@@ -185,6 +185,32 @@ int hvm_vcpu_cacheattr_init(struct vcpu *v)
 ((uint64_t)PAT_TYPE_UC_MINUS << 48) |   /* PAT6: UC- */
 ((uint64_t)PAT_TYPE_UNCACHABLE << 56);  /* PAT7: UC */
 
+if ( is_hardware_domain(v->domain) )
+{
+/* Copy values from the host. */
+struct domain *d = v->domain;
+unsigned int i;
+
+if ( mtrr_state.have_fixed )
+for ( i = 0; i < NUM_FIXED_MSR; i++ )
+mtrr_fix_range_msr_set(d, m, i,
+  ((uint64_t 
*)mtrr_state.fixed_ranges)[i]);
+
+for ( i = 0; i < num_var_ranges; i++ )
+{
+mtrr_var_range_msr_set(d, m, MSR_IA32_MTRR_PHYSBASE(i),
+   mtrr_state.var_ranges[i].base);
+mtrr_var_range_msr_set(d, m, MSR_IA32_MTRR_PHYSMASK(i),
+   mtrr_state.var_ranges[i].mask);
+}
+
+mtrr_def_type_msr_set(d, m,
+  mtrr_state.def_type |
+  MASK_INSR(mtrr_state.fixed_enabled,
+MTRRdefType_FE) |
+  MASK_INSR(mtrr_state.enabled, MTRRdefType_E));
+}
+
 return 0;
 }
 
-- 
2.17.0


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

[Xen-devel] [PATCH v3 0/8] PVH MTRR initial state

[Roger Pau Monne]

Hello,

The following patches set a sane initial MTRR state for both Dom0 and
DomU PVH guests. Note that for Dom0 the host MTRR state is used, OTOH
for DomU the default MTRR type is set to write-back.

This should avoid guests having to setup some kind of MTRR state in
order to boot.

This has been rebased on top of a couple of fixes/improvements from Jan,
which are also included in the series.

Thanks, Roger.

Jan Beulich (2):
  x86/HVM: improve MTRR load checks
  x86/mtrr: split "enabled" field into two boolean flags

Roger Pau Monne (6):
  mtrr: introduce mask to get VCNT from MTRRcap MSR
  hvm/mtrr: add emacs local variables block with formatting info
  hvm/mtrr: use the hardware number of variable ranges for Dom0
  hvm/mtrr: copy hardware state for Dom0
  libxc/pvh: set default MTRR type to write-back
  docs/pvh: document initial MTRR state

 docs/misc/pvh.markdown  |  18 +
 tools/libxc/xc_dom_x86.c|  44 
 xen/arch/x86/cpu/mtrr/generic.c |  14 ++--
 xen/arch/x86/cpu/mtrr/main.c|   2 +-
 xen/arch/x86/hvm/hvm.c  |  13 ++--
 xen/arch/x86/hvm/mtrr.c | 121 +---
 xen/include/asm-x86/msr-index.h |   4 ++
 xen/include/asm-x86/mtrr.h  |   8 ++-
 8 files changed, 188 insertions(+), 36 deletions(-)

-- 
2.17.0


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

[Xen-devel] [PATCH v3 4/8] hvm/mtrr: add emacs local variables block with formatting info

[Roger Pau Monne]

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/hvm/mtrr.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/xen/arch/x86/hvm/mtrr.c b/xen/arch/x86/hvm/mtrr.c
index c181a7a3d0..2f8f8ddd8f 100644
--- a/xen/arch/x86/hvm/mtrr.c
+++ b/xen/arch/x86/hvm/mtrr.c
@@ -871,3 +871,13 @@ int epte_get_entry_emt(struct domain *d, unsigned long 
gfn, mfn_t mfn,
 
 return MTRR_TYPE_UNCACHABLE;
 }
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.17.0


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

[Xen-devel] [PATCH v3 8/8] docs/pvh: document initial MTRR state

[Roger Pau Monne]

Provided to both Dom0 and DomUs.

Signed-off-by: Roger Pau Monné 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Julien Grall 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
Changes since v2:
 - Add 'currently' to the first sentence about the default MTRR type.

Changes since v1:
 - Add an extra paragraph to clarify the initial MTRR state.
---
 docs/misc/pvh.markdown | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/docs/misc/pvh.markdown b/docs/misc/pvh.markdown
index e85fb15374..1c9a00b48a 100644
--- a/docs/misc/pvh.markdown
+++ b/docs/misc/pvh.markdown
@@ -92,3 +92,21 @@ event channels. Delivery of those interrupts can be 
configured in the same way
 as HVM guests, check xen/include/public/hvm/params.h and
 xen/include/public/hvm/hvm\_op.h for more information about available delivery
 methods.
+
+## MTRR ##
+
+### Unprivileged guests ###
+
+PVH guests are currently booted with the default MTRR type set to write-back
+and MTRR enabled. This allows DomUs to start with a sane MTRR state. Note that
+this will have to be revisited when pci-passthrough is added to PVH in order to
+set MMIO regions as UC.
+
+Xen guarantees that RAM regions will always have the WB cache type set in the
+initial MTRR state, either set by the default MTRR type or by other means.
+
+### Hardware domain ###
+
+A PVH hardware domain is booted with the same MTRR state as the one found on
+the host. This is done because the hardware domain memory map is already a
+modified copy of the host memory map, so the same MTRR setup should work.
-- 
2.17.0


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

Re: [Xen-devel] [PATCH v2] xen: Add acpu_sleep=s3_fake command-line option for testing

[Jan Beulich]

>>> On 22.05.18 at 16:50,  wrote:
> In fact, with `s3_fake` enabled, Xen just hangs when XPTI / BTI are
> enabled; but with it disabled, I actually get a stack trace.  Serial
> output and xen-syms.map attached.

Interesting (not sure if I simply didn't pay attention before):

(XEN) *** DOUBLE FAULT ***
(XEN) [ Xen-4.11-rc  x86_64  debug=y   Not tainted ]
(XEN) CPU:0
(XEN) RIP:e008:[] handle_exception+0x9c/0xff
(XEN) RFLAGS: 00010006   CONTEXT: hypervisor
(XEN) rax: c900402140b8   rbx:    rcx: 0005
(XEN) rdx:    rsi:    rdi: 
(XEN) rbp: 36ffbfdebf27   rsp: c90040214000   r8:  
(XEN) r9:     r10:    r11: 
(XEN) r12:    r13:    r14: c90040217fff
(XEN) r15:    cr0: 8005003b   cr4: 2660
(XEN) cr3: 00019200a000   cr2: c90040213ff8
(XEN) fsb:    gsb: 88003dcc   gss: 
(XEN) ds: 002b   es: 002b   fs: 8e00   gs: 87c1   ss: e010   cs: e008
(XEN) Current stack base c9004021 differs from expected 8300dfa8
(XEN) Valid stack range: c90040216000-c90040218000, 
sp=c90040214000, tss.rsp0=8300dfa87fa0

We're in handle_exception, but on a guest (presumably Dom0) kernel stack.

The selector values in FS and GS are also highly suspicious.

I can't explain either for the moment, as bypassing do_suspend_lowlevel()
ought to mean that none of TR, FS, or GS get touched at all. Looking at
the flow of execution I wonder though whether your opt_fake_s3 wasn't
better placed further down the call tree, e.g. in acpi_enter_sleep_state().
That would cause more of the involved code path to be tested.

Btw, so far you've only mentioned XPTI and BTI collectively enabled or
disabled. Have you tried with one of them on and the other off?

> (The mail server doesn't seem to want the full xen-syms file -- let me
> know if you need it and I'll figure out how to get it to you.)

While in general I would have considered this useful (or even necessary),
in order to be able to work out at what exact insn the #DF occurred, with
the above I'm no longer certain this matters - things must have gone
wrong much earlier.

I guess what we really need is a raw dump of whatever stack we're on
currently, so we have a chance to reconstruct at least recent execution
history (like what exception has lead us into handle_exception). Once
again - for now I'm completely lost as to us having managed to switch to
a non-hypervisor stack in hypervisor context (or to run guest code with
hypervisor CS/SS).

Jan



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

Re: [Xen-devel] [PATCH v2] xen: Add acpu_sleep=s3_fake command-line option for testing

[Andrew Cooper]

On 22/05/18 16:25, George Dunlap wrote:
> On 05/22/2018 03:50 PM, George Dunlap wrote:
>> On 05/22/2018 03:43 PM, George Dunlap wrote:
>>> On 05/22/2018 03:37 PM, Andrew Cooper wrote:
 On 22/05/18 14:48, George Dunlap wrote:
> On 05/22/2018 02:40 PM, Jan Beulich wrote:
> On 22.05.18 at 15:35,  wrote:
>>> --- a/xen/arch/x86/acpi/power.c
>>> +++ b/xen/arch/x86/acpi/power.c
>>> @@ -33,6 +33,8 @@
>>>  
>>>  uint32_t system_reset_counter = 1;
>>>  
>>> +static bool __read_mostly opt_fake_s3 = false;
>> With the typo in the title (wants to be acpi_sleep) corrected 
> Oops -- I can fix this on check-in (once the development window opens).
 If this patch is necessary, or at least a useful aid to track down an S3
 bug in Xen 4.11, I vote for its inclusion.

 As far as the change itself goes, it is very simple, with a minimal
 change of any unintended side effects.

 CC'ing the RM for his decision on the subject.
>>> Using `rtcwake -s 10 -m mem`, the only difference I've seen between
>>> suspend with this patch and without is that it doesn't actually sleep
>>> for 10 seconds -- not surprising, as it was never asleep. :-)
>> In fact, with `s3_fake` enabled, Xen just hangs when XPTI / BTI are
>> enabled; but with it disabled, I actually get a stack trace.  Serial
>> output and xen-syms.map attached.
> With your code dump patch (sorry for the wrapping):
>
> (XEN) *** DOUBLE FAULT ***
>
> (XEN) [ Xen-4.11-rc  x86_64  debug=y   Not tainted ]
>
> (XEN) CPU:0
>
> (XEN) RIP:e008:[] handle_exception+0x9c/0xff
>
> (XEN) RFLAGS: 00010006   CONTEXT: hypervisor
>
> (XEN) rax: c900402040d8   rbx:    rcx: 0003
>
> (XEN) rdx:    rsi:    rdi: 
>
> (XEN) rbp: 36ffbfdfbf07   rsp: c90040204000   r8:  
>
> (XEN) r9:     r10:    r11: 
>
> (XEN) r12:    r13:    r14: c90040207fff
>
> (XEN) r15:    cr0: 8005003b   cr4: 2660
>
> (XEN) cr3: 00019200a000   cr2: c90040203ff8
>
> (XEN) fsb: 7f800083d700   gsb: 88003dc4   gss: 
>
> (XEN) ds: 002b   es: 002b   fs:    gs:    ss: e010   cs: e008
>
> (XEN) Xen code around  (handle_exception+0x9c/0xff):
>
> (XEN)  00 f3 90 0f ae e8 eb f9  07 00 00 00 f3 90 0f ae e8 eb f9 83
> e9 01 75

Ok - this is in the middle of the RSB loop...

>
> (XEN) Current stack base c9004020 differs from expected
> 8300dfa8
>
> (XEN) Valid stack range: c90040206000-c90040208000,
> sp=c90040204000, tss.rsp0=8300dfa87fa0

...and we've got a stack pointer which looks to be on the base of the
guard page, which will explain why we are seeing a double fault - #PF
trying to push the return value, and a second #PF trying to push the
exception frame.

The question is, where are we getting this dodgy stack pointer from. 
We've executed most of the RSB loop, with the value in %rax being the
original stack pointer which will be restored at the end of the loop.

~Andrew

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

Re: [Xen-devel] [PATCH v2] xen: Add acpu_sleep=s3_fake command-line option for testing

[George Dunlap]

On 05/22/2018 03:50 PM, George Dunlap wrote:
> On 05/22/2018 03:43 PM, George Dunlap wrote:
>> On 05/22/2018 03:37 PM, Andrew Cooper wrote:
>>> On 22/05/18 14:48, George Dunlap wrote:
 On 05/22/2018 02:40 PM, Jan Beulich wrote:
 On 22.05.18 at 15:35,  wrote:
>> --- a/xen/arch/x86/acpi/power.c
>> +++ b/xen/arch/x86/acpi/power.c
>> @@ -33,6 +33,8 @@
>>  
>>  uint32_t system_reset_counter = 1;
>>  
>> +static bool __read_mostly opt_fake_s3 = false;
> With the typo in the title (wants to be acpi_sleep) corrected 
 Oops -- I can fix this on check-in (once the development window opens).
>>>
>>> If this patch is necessary, or at least a useful aid to track down an S3
>>> bug in Xen 4.11, I vote for its inclusion.
>>>
>>> As far as the change itself goes, it is very simple, with a minimal
>>> change of any unintended side effects.
>>>
>>> CC'ing the RM for his decision on the subject.
>>
>> Using `rtcwake -s 10 -m mem`, the only difference I've seen between
>> suspend with this patch and without is that it doesn't actually sleep
>> for 10 seconds -- not surprising, as it was never asleep. :-)
> 
> In fact, with `s3_fake` enabled, Xen just hangs when XPTI / BTI are
> enabled; but with it disabled, I actually get a stack trace.  Serial
> output and xen-syms.map attached.

With your code dump patch (sorry for the wrapping):

(XEN) *** DOUBLE FAULT ***

(XEN) [ Xen-4.11-rc  x86_64  debug=y   Not tainted ]

(XEN) CPU:0

(XEN) RIP:e008:[] handle_exception+0x9c/0xff

(XEN) RFLAGS: 00010006   CONTEXT: hypervisor

(XEN) rax: c900402040d8   rbx:    rcx: 0003

(XEN) rdx:    rsi:    rdi: 

(XEN) rbp: 36ffbfdfbf07   rsp: c90040204000   r8:  

(XEN) r9:     r10:    r11: 

(XEN) r12:    r13:    r14: c90040207fff

(XEN) r15:    cr0: 8005003b   cr4: 2660

(XEN) cr3: 00019200a000   cr2: c90040203ff8

(XEN) fsb: 7f800083d700   gsb: 88003dc4   gss: 

(XEN) ds: 002b   es: 002b   fs:    gs:    ss: e010   cs: e008

(XEN) Xen code around  (handle_exception+0x9c/0xff):

(XEN)  00 f3 90 0f ae e8 eb f9  07 00 00 00 f3 90 0f ae e8 eb f9 83
e9 01 75

(XEN) Current stack base c9004020 differs from expected
8300dfa8

(XEN) Valid stack range: c90040206000-c90040208000,
sp=c90040204000, tss.rsp0=8300dfa87fa0

(XEN) No stack overflow detected. Skipping stack trace.

(XEN)

(XEN) 

(XEN) Panic on CPU 0:

(XEN) DOUBLE FAULT -- system shutdown

(XEN) 

(XEN)

(XEN) Reboot in five seconds...


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

Re: [Xen-devel] [PATCH v4 1/2] xen/PVH: Set up GS segment for stack canary

[Brian Gerst]

On Tue, May 22, 2018 at 9:57 AM, Jan Beulich  wrote:
 On 22.05.18 at 15:45,  wrote:
>> On Mon, May 21, 2018 at 11:54 PM, Boris Ostrovsky 
>>  wrote:
>>> @@ -98,6 +101,12 @@ ENTRY(pvh_start_xen)
>>> /* 64-bit entry point. */
>>> .code64
>>>  1:
>>> +   /* Set base address in stack canary descriptor. */
>>> +   mov $MSR_GS_BASE,%ecx
>>> +   mov $canary, %rax
>>> +   cdq
>>> +   wrmsr
>>
>> CDQ only sign-extends EAX to RAX.  What you really want is to move the
>> high 32-bits to EDX (or zero EDX if we can guarantee it is loaded
>> below 4G).
>
> What you describe is CDQE (AT name: CLTD); CDQ (AT: CLTQ)
> sign-extends EAX to EDX:EAX.

But that would still be wrong, as it would set EDX to 0x if
the kernel was loaded between 2G and 4G.  Looking closer at the code,
we just left 32-bit mode, so we must have been loaded below 4G,
therefore EDX must be zero.

--
Brian Gerst

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

Re: [Xen-devel] [RFC 1/3] xen/balloon: Allow allocating DMA buffers

[Oleksandr Andrushchenko]

On 05/22/2018 05:33 PM, Boris Ostrovsky wrote:

On 05/22/2018 01:55 AM, Oleksandr Andrushchenko wrote:

On 05/21/2018 11:36 PM, Boris Ostrovsky wrote:

On 05/21/2018 03:13 PM, Oleksandr Andrushchenko wrote:

On 05/21/2018 09:53 PM, Boris Ostrovsky wrote:

On 05/21/2018 01:32 PM, Oleksandr Andrushchenko wrote:

On 05/21/2018 07:35 PM, Boris Ostrovsky wrote:

On 05/21/2018 01:40 AM, Oleksandr Andrushchenko wrote:

On 05/19/2018 01:04 AM, Boris Ostrovsky wrote:

On 05/17/2018 04:26 AM, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko 

A commit message would be useful.

Sure, v1 will have it

Signed-off-by: Oleksandr Andrushchenko


  for (i = 0; i < nr_pages; i++) {
-    page = alloc_page(gfp);
-    if (page == NULL) {
-    nr_pages = i;
-    state = BP_EAGAIN;
-    break;
+    if (ext_pages) {
+    page = ext_pages[i];
+    } else {
+    page = alloc_page(gfp);
+    if (page == NULL) {
+    nr_pages = i;
+    state = BP_EAGAIN;
+    break;
+    }
  }
  scrub_page(page);
  list_add(>lru, );
@@ -529,7 +565,7 @@ static enum bp_state
decrease_reservation(unsigned long nr_pages, gfp_t gfp)
  i = 0;
  list_for_each_entry_safe(page, tmp, , lru) {
  /* XENMEM_decrease_reservation requires a GFN */
-    frame_list[i++] = xen_page_to_gfn(page);
+    frames[i++] = xen_page_to_gfn(page);
    #ifdef CONFIG_XEN_HAVE_PVMMU
  /*
@@ -552,18 +588,22 @@ static enum bp_state
decrease_reservation(unsigned long nr_pages, gfp_t gfp)
  #endif
  list_del(>lru);
  -    balloon_append(page);
+    if (!ext_pages)
+    balloon_append(page);

So what you are proposing is not really ballooning. You are just
piggybacking on existing interfaces, aren't you?

Sort of. Basically I need to {increase|decrease}_reservation, not
actually
allocating ballooned pages.
Do you think I can simply EXPORT_SYMBOL for
{increase|decrease}_reservation?
Any other suggestion?

I am actually wondering how much of that code you end up reusing.
You
pretty much create new code paths in both routines and common code
ends
up being essentially the hypercall.

Well, I hoped that it would be easier to maintain if I modify
existing
code
to support both use-cases, but I am also ok to create new routines if
this
seems to be reasonable - please let me know

     So the question is --- would it make
sense to do all of this separately from the balloon driver?

This can be done, but which driver will host this code then? If we
move from
the balloon driver, then this could go to either gntdev or
grant-table.
What's your preference?

A separate module?
Is there any use for this feature outside of your zero-copy DRM
driver?

Intel's hyper dma-buf (Dongwon/Matt CC'ed), V4L/GPU at least.

At the time I tried to upstream zcopy driver it was discussed and
decided that
it would be better if I remove all DRM specific code and move it to
Xen drivers.
Thus, this RFC.

But it can also be implemented as a dedicated Xen dma-buf driver which
will have all the
code from this RFC + a bit more (char/misc device handling at least).
This will also require a dedicated user-space library, just like
libxengnttab.so
for gntdev (now I have all new IOCTLs covered there).

If the idea of a dedicated Xen dma-buf driver seems to be more
attractive we
can work toward this solution. BTW, I do support this idea, but was not
sure if Xen community accepts yet another driver which duplicates
quite some code
of the existing gntdev/balloon/grant-table. And now after this RFC I
hope that all cons
and pros of both dedicated driver and gntdev/balloon/grant-table
extension are
clearly seen and we can make a decision.

IIRC the objection for a separate module was in the context of gntdev
was discussion, because (among other things) people didn't want to have
yet another file in /dev/xen/

Here we are talking about (a new) balloon-like module which doesn't
create any new user-visible interfaces. And as for duplicating code ---
as I said, I am not convinced there is much of duplication.

I might even argue that we should add a new config option for this
module.

I am not quite sure I am fully following you here: so, you suggest
that we have balloon.c unchanged, but instead create a new
module (namely a file under the same folder as balloon.c, e.g.
dma-buf-reservation.c) and move those {increase|decrease}_reservation
routines (specific to dma-buf) to that new file? And make it selectable
via Kconfig? If so, then how about the changes to grant-table and gntdev?
Those will look inconsistent then.

Inconsistent with what? The changes to grant code will also be under the
new config option.

Ah, ok.

Option 1. We will have Kconfig option which will cover dma-buf
changes in balloon, grant-table and gntdev. 

Re: [Xen-devel] 4.11.0 RC1 panic

[Jan Beulich]

>>> On 22.05.18 at 13:01,  wrote:
> On Tue, May 15, 2018 at 03:30:17AM -0600, Jan Beulich wrote:
>> - reduce the test environment (ideally to a simple [XTF?] test), or
>> - at least narrow the conditions, or
> 
> Now that I know where to find the domU number in the panic message,
> I can say that, so far, only 32bit domUs have caused this assert failure.
> 
>> - at the very least summarize the relevant actions NetBSD takes in
>>   terms of page table management, to hopefully reduce the sets of
>>   code paths potentially involved (for example, across a larger set of
>>   crashes knowing whether UNPIN is always involved would be
>>   helpful; I've been blindly assuming it would be short of having
>>   further data)
> 
> So far I've seen 2 stack traces with 4.11:
> (XEN) Xen call trace:
> (XEN)[] mm.c#dec_linear_entries+0x12/0x20
> (XEN)[] mm.c#_put_page_type+0x13e/0x350
> (XEN)[] _spin_lock+0xd/0x50
> (XEN)[] mm.c#put_page_from_l2e+0xdf/0x110
> (XEN)[] free_page_type+0x2f9/0x790
> (XEN)[] mm.c#_put_page_type+0x107/0x350
> (XEN)[] put_page_type_preemptible+0xf/0x10
> (XEN)[] domain.c#relinquish_memory+0xab/0x460
> (XEN)[] domain_relinquish_resources+0x203/0x290
> (XEN)[] domain_kill+0xbd/0x150
> (XEN)[] do_domctl+0x7d3/0x1a90
> (XEN)[] do_domctl+0/0x1a90
> (XEN)[] pv_hypercall+0x1f5/0x430
> (XEN)[] lstar_enter+0xa2/0x120
> (XEN)[] lstar_enter+0xae/0x120
> (XEN)[] lstar_enter+0xa2/0x120
> (XEN)[] lstar_enter+0xae/0x120
> (XEN)[] lstar_enter+0xa2/0x120
> (XEN)[] lstar_enter+0xae/0x120
> (XEN)[] lstar_enter+0x10c/0x120

That's interesting: So far I've been working with the assumption that
there would be a race of the put_page_from_l2e() with some other
piece of code. The issue happening out of domain_relinquish_resources()
pretty much excludes this, and instead suggests that such a race (if
there is one in the first place, but you seeing this only sporadically
highly suggests so) would sit somewhere earlier, perhaps when the
page gets established as a recursive L2 one. Unless someone else
gets to this earlier than me, I'll have to go through the related code
another time with this property in mind.

Jan



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

Re: [Xen-devel] [PATCH v2] xen: Add acpu_sleep=s3_fake command-line option for testing

[George Dunlap]

On 05/22/2018 03:37 PM, Andrew Cooper wrote:
> On 22/05/18 14:48, George Dunlap wrote:
>> On 05/22/2018 02:40 PM, Jan Beulich wrote:
>> On 22.05.18 at 15:35,  wrote:
 --- a/xen/arch/x86/acpi/power.c
 +++ b/xen/arch/x86/acpi/power.c
 @@ -33,6 +33,8 @@
  
  uint32_t system_reset_counter = 1;
  
 +static bool __read_mostly opt_fake_s3 = false;
>>> With the typo in the title (wants to be acpi_sleep) corrected 
>> Oops -- I can fix this on check-in (once the development window opens).
> 
> If this patch is necessary, or at least a useful aid to track down an S3
> bug in Xen 4.11, I vote for its inclusion.
> 
> As far as the change itself goes, it is very simple, with a minimal
> change of any unintended side effects.
> 
> CC'ing the RM for his decision on the subject.

Using `rtcwake -s 10 -m mem`, the only difference I've seen between
suspend with this patch and without is that it doesn't actually sleep
for 10 seconds -- not surprising, as it was never asleep. :-)

I agree that it's quite low risk; but it doesn't seem to me to be very
critical either, which is why I didn't CC Juergen in the first place.
But I'm fine either way.

 -George

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

Re: [Xen-devel] [PATCH v2] xen: Add acpu_sleep=s3_fake command-line option for testing

[Andrew Cooper]

On 22/05/18 14:48, George Dunlap wrote:
> On 05/22/2018 02:40 PM, Jan Beulich wrote:
> On 22.05.18 at 15:35,  wrote:
>>> --- a/xen/arch/x86/acpi/power.c
>>> +++ b/xen/arch/x86/acpi/power.c
>>> @@ -33,6 +33,8 @@
>>>  
>>>  uint32_t system_reset_counter = 1;
>>>  
>>> +static bool __read_mostly opt_fake_s3 = false;
>> With the typo in the title (wants to be acpi_sleep) corrected 
> Oops -- I can fix this on check-in (once the development window opens).

If this patch is necessary, or at least a useful aid to track down an S3
bug in Xen 4.11, I vote for its inclusion.

As far as the change itself goes, it is very simple, with a minimal
change of any unintended side effects.

CC'ing the RM for his decision on the subject.

~Andrew

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

Re: [Xen-devel] ARM: Issues while Enabling hibernation in domU(linux) on jacinto-j6

[Julien Grall]

On 22/05/18 14:17, moin anjnawala wrote:

Hi,


Hello,


I am using xen4.6 and Linux-4.4 as dom0 and domU on Jacinto j6 board.
The system is able to boot and create domains successfully. Now, I am
trying to enable hibernation in domU. The hibernation seems to be
completed successfully. After hibernating domU and recreating domU. It
is able to resume but gives following error messages for vbd in kernel
logs
Xen 4.6 has been released 3 years and is 5 releases old. You should use 
a recent Xen and Linux when doing development as bug may have been fixed 
in recent version. Please reproduce your error on recent version (Xen 
4.10 at least).


Regards,

--
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: Add acpu_sleep=s3_fake command-line option for testing

[Jan Beulich]

>>> On 22.05.18 at 15:48,  wrote:
> On 05/22/2018 02:40 PM, Jan Beulich wrote:
> On 22.05.18 at 15:35,  wrote:
>>> --- a/xen/arch/x86/acpi/power.c
>>> +++ b/xen/arch/x86/acpi/power.c
>>> @@ -33,6 +33,8 @@
>>>  
>>>  uint32_t system_reset_counter = 1;
>>>  
>>> +static bool __read_mostly opt_fake_s3 = false;
>> 
>> With the typo in the title (wants to be acpi_sleep) corrected 
> 
> Oops -- I can fix this on check-in (once the development window opens).
> 
>> and
>> preferably with the pointless initializer here dropped
> 
> Are global variables in C automatically initialized?  That's new to me
> -- under what circumstances, and since when?

Yes, they are (albeit you mean "file scope" instead of "global" here):

"A declaration of an identifier for an object that has file scope without an
 initializer, and without a storage-class specifier or with the storage-class
 specifier static, constitutes a tentative definition. If a translation unit
 contains one or more tentative definitions for an identifier, and the
 translation unit contains no external definition for that identifier, then the
 behavior is exactly as if the translation unit contains a file scope
 declaration of that identifier, with the composite type as of the end of the
 translation unit, with an initializer equal to 0."

As to since when - forever, I would say. I don't have a K book to hand
though to see whether it was that way back then already.

Jan



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

[Xen-devel] [linux-4.14 test] 122974: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 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-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-armhf-armhf-xl-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-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-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-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-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:
 linuxd88700f79448fc8f03617d4f1929c39676f8d1e4
baseline version:
 linux3f07ecbec1518b1638f8227a5e1d0154c3b4826f

Last test of basis   122902  2018-05-17 20:50:45 Z4 days
Testing same since   122974  2018-05-20 01:24:58 Z2 days1 attempts


People who touched revisions under test:
  Adi Nissim 
  Alistair Strachan 
  Andre Tomt 
  Andrey Ignatov 
  Antony Antony 
  Bjørn Mork 
  Christophe JAILLET 
  Cong Wang 
  

Re: [Xen-devel] [PATCH] x86/HVM: correct mtrr_pat_not_equal()

[Andrew Cooper]

On 22/05/18 14:50, Jan Beulich wrote:
> The two vCPU-s differing in MTRR-enabled state means MTRR settings are
> not equal. Both vCPU-s having MTRRs disabled means only PAT needs to be
> compared. Along those lines for fixed range MTRRs. Differing variable
> range counts likewise mean settings are different overall (even if
> that's not a very reasonable setup to have).
>
> Constify types and convert bool_t to bool.
>
> Signed-off-by: Jan Beulich 
> Reviewed-by: Roger Pau Monné 
> Release-acked-by: Juergen Gross 

Acked-by: Andrew Cooper 

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

[Xen-devel] [PATCH] x86/HVM: correct mtrr_pat_not_equal()

[Jan Beulich]

The two vCPU-s differing in MTRR-enabled state means MTRR settings are
not equal. Both vCPU-s having MTRRs disabled means only PAT needs to be
compared. Along those lines for fixed range MTRRs. Differing variable
range counts likewise mean settings are different overall (even if
that's not a very reasonable setup to have).

Constify types and convert bool_t to bool.

Signed-off-by: Jan Beulich 
Reviewed-by: Roger Pau Monné 
Release-acked-by: Juergen Gross 

--- a/xen/arch/x86/hvm/mtrr.c
+++ b/xen/arch/x86/hvm/mtrr.c
@@ -473,35 +473,40 @@ bool_t mtrr_var_range_msr_set(
 return 1;
 }
 
-bool_t mtrr_pat_not_equal(struct vcpu *vd, struct vcpu *vs)
+bool mtrr_pat_not_equal(const struct vcpu *vd, const struct vcpu *vs)
 {
-struct mtrr_state *md = >arch.hvm_vcpu.mtrr;
-struct mtrr_state *ms = >arch.hvm_vcpu.mtrr;
-int32_t res;
-uint8_t num_var_ranges = (uint8_t)md->mtrr_cap;
-
-/* Test fixed ranges. */
-res = memcmp(md->fixed_ranges, ms->fixed_ranges,
-NUM_FIXED_RANGES*sizeof(mtrr_type));
-if ( res )
-return 1;
-
-/* Test var ranges. */
-res = memcmp(md->var_ranges, ms->var_ranges,
-num_var_ranges*sizeof(struct mtrr_var_range));
-if ( res )
-return 1;
-
-/* Test default type MSR. */
-if ( (md->def_type != ms->def_type)
-&& (md->enabled != ms->enabled) )
-return 1;
+const struct mtrr_state *md = >arch.hvm_vcpu.mtrr;
+const struct mtrr_state *ms = >arch.hvm_vcpu.mtrr;
 
-/* Test PAT. */
-if ( vd->arch.hvm_vcpu.pat_cr != vs->arch.hvm_vcpu.pat_cr )
-return 1;
+if ( (md->enabled ^ ms->enabled) & 2 )
+return true;
+
+if ( md->enabled & 2 )
+{
+unsigned int num_var_ranges = (uint8_t)md->mtrr_cap;
+
+/* Test default type MSR. */
+if ( md->def_type != ms->def_type )
+return true;
+
+/* Test fixed ranges. */
+if ( (md->enabled ^ ms->enabled) & 1 )
+return true;
+
+if ( (md->enabled & 1) &&
+ memcmp(md->fixed_ranges, ms->fixed_ranges,
+sizeof(md->fixed_ranges)) )
+return true;
+
+/* Test variable ranges. */
+if ( num_var_ranges != (uint8_t)ms->mtrr_cap ||
+ memcmp(md->var_ranges, ms->var_ranges,
+num_var_ranges * sizeof(*md->var_ranges)) )
+return true;
+}
 
-return 0;
+/* Test PAT. */
+return vd->arch.hvm_vcpu.pat_cr != vs->arch.hvm_vcpu.pat_cr;
 }
 
 struct hvm_mem_pinned_cacheattr_range {
--- unstable.orig/xen/include/asm-x86/mtrr.h2016-02-09 14:46:55.0 
+0100
+++ unstable/xen/include/asm-x86/mtrr.h 2018-05-15 12:12:33.681639726 +0200
@@ -92,6 +92,6 @@ extern void memory_type_changed(struct d
 extern bool_t pat_msr_set(uint64_t *pat, uint64_t msr);
 
 bool_t is_var_mtrr_overlapped(const struct mtrr_state *m);
-bool_t mtrr_pat_not_equal(struct vcpu *vd, struct vcpu *vs);
+bool mtrr_pat_not_equal(const struct vcpu *vd, const struct vcpu *vs);
 
 #endif /* __ASM_X86_MTRR_H__ */




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

Re: [Xen-devel] [PATCH v2] xen: Add acpu_sleep=s3_fake command-line option for testing

[George Dunlap]

On 05/22/2018 02:40 PM, Jan Beulich wrote:
 On 22.05.18 at 15:35,  wrote:
>> --- a/xen/arch/x86/acpi/power.c
>> +++ b/xen/arch/x86/acpi/power.c
>> @@ -33,6 +33,8 @@
>>  
>>  uint32_t system_reset_counter = 1;
>>  
>> +static bool __read_mostly opt_fake_s3 = false;
> 
> With the typo in the title (wants to be acpi_sleep) corrected 

Oops -- I can fix this on check-in (once the development window opens).

> and
> preferably with the pointless initializer here dropped

Are global variables in C automatically initialized?  That's new to me
-- under what circumstances, and since when?

 -George

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

Re: [Xen-devel] [PATCH v4 1/2] xen/PVH: Set up GS segment for stack canary

[Brian Gerst]

On Mon, May 21, 2018 at 11:54 PM, Boris Ostrovsky
 wrote:
> We are making calls to C code (e.g. xen_prepare_pvh()) which may use
> stack canary (stored in GS segment).
>
> Signed-off-by: Boris Ostrovsky 
> ---
>  arch/x86/xen/xen-pvh.S | 26 +-
>  1 file changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/xen/xen-pvh.S b/arch/x86/xen/xen-pvh.S
> index e1a5fbe..0169374 100644
> --- a/arch/x86/xen/xen-pvh.S
> +++ b/arch/x86/xen/xen-pvh.S
> @@ -54,6 +54,9 @@
>   * charge of setting up it's own stack, GDT and IDT.
>   */
>
> +#define PVH_GDT_ENTRY_CANARY   4
> +#define PVH_CANARY_SEL (PVH_GDT_ENTRY_CANARY * 8)
> +
>  ENTRY(pvh_start_xen)
> cld
>
> @@ -98,6 +101,12 @@ ENTRY(pvh_start_xen)
> /* 64-bit entry point. */
> .code64
>  1:
> +   /* Set base address in stack canary descriptor. */
> +   mov $MSR_GS_BASE,%ecx
> +   mov $canary, %rax
> +   cdq
> +   wrmsr

CDQ only sign-extends EAX to RAX.  What you really want is to move the
high 32-bits to EDX (or zero EDX if we can guarantee it is loaded
below 4G).

--
Brian Gerst

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

Re: [Xen-devel] [PATCH v1 1/2] x86/mm: Add mem access rights to NPT

[Jan Beulich]

>>> On 22.05.18 at 15:35,  wrote:
> On Ma, 2018-05-22 at 03:49 -0600, Jan Beulich wrote:
>> > > > On 18.05.18 at 20:30,  wrote:
>> > On 05/18/2018 06:30 PM, Jan Beulich wrote:
>> > > > > > On 11.05.18 at 13:11,  wrote:
>> > > > This patch adds access rights for the NPT pages. The access
>> > > > rights are
>> > > > saved in bits 59:56 of pte that are manipulated through
>> > > > p2m_set_access()
>> > > > and p2m_get_access() functions.
>> > > You don't give any rationale for the choice of bits. Right now
>> > > p2m-pt.c still
>> > > assumes that CPU and IOMMU page tables might be shared, despite
>> > > amd_iommu_init() unconditionally turning this functionality off.
>> > > As long as the
>> > > option for that mode hasn't been removed from p2m-pt.c, I think
>> > > bits used
>> > > by the IOMMU (here: bit 59) should not be used for software
>> > > purposes. The
>> > > alternative therefore is for you to supply a prereq patch purging
>> > > the sharing
>> > > functionality from p2m-pt.c and preferably also from the AMD
>> > > IOMMU code.
>> > > That's of course only an option if we don't foresee any means by
>> > > which this
>> > > mode may become usable again.
>> > The choice of bits was our interpretation of Andrew's reply here:
>> >
>> > https://lists.xenproject.org/archives/html/xen-devel/2018-05/msg005 
>> > 73.html
>> >
>> > Have we misread it?
>> I don't think you have, but what Andrew has described was only the
>> CPU side
>> of considerations to make. Plus of course the patch description
>> should explain
>> whatever choice you make.
>>
>> >
>> > We've also thought about putting the information in a new field of
>> > struct page_info. Would that perhaps be preferable?
>> I don't view this as a page property, but a mapping property. As such
>> it can't validly go into struct page_info.
> 
> I will add the information in the patch description. Can you tell us
> what structure is best to use for the access rights?

I may not correctly understand the question: I think everybody agrees
on the bits to go into an _unused_ portion of the p2m entry. 

Jan



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