[Xen-devel] [PATCH v3 01/19] hw: i386: Decouple the ACPI build from the PC machine type

[Samuel Ortiz]

ACPI tables are platform and machine type and even architecture
agnostic, and as such we want to provide an internal ACPI API that
only depends on platform agnostic information.

For the x86 architecture, in order to build ACPI tables independently
from the PC or Q35 machine types, we are moving a few MachineState
structure fields into a machine type agnostic structure called
AcpiConfiguration. The structure fields we move are:

   HotplugHandler *acpi_dev
   AcpiNVDIMMState acpi_nvdimm_state;
   FWCfgState *fw_cfg
   ram_addr_t below_4g_mem_size, above_4g_mem_size
   bool apic_xrupt_override
   unsigned apic_id_limit
   uint64_t numa_nodes
   uint64_t numa_mem

Signed-off-by: Samuel Ortiz 
---
 hw/acpi/cpu_hotplug.c|   9 +-
 hw/arm/virt-acpi-build.c |  10 ---
 hw/i386/acpi-build.c | 135 ++
 hw/i386/acpi-build.h |   4 +-
 hw/i386/pc.c | 175 ---
 hw/i386/pc_piix.c|  21 ++---
 hw/i386/pc_q35.c |  21 ++---
 hw/i386/xen/xen-hvm.c|  19 +++--
 include/hw/acpi/acpi.h   |  43 ++
 include/hw/i386/pc.h |  19 ++---
 10 files changed, 254 insertions(+), 202 deletions(-)

diff --git a/hw/acpi/cpu_hotplug.c b/hw/acpi/cpu_hotplug.c
index 5243918125..634dc3b846 100644
--- a/hw/acpi/cpu_hotplug.c
+++ b/hw/acpi/cpu_hotplug.c
@@ -237,9 +237,9 @@ void build_legacy_cpu_hotplug_aml(Aml *ctx, MachineState 
*machine,
 /* The current AML generator can cover the APIC ID range [0..255],
  * inclusive, for VCPU hotplug. */
 QEMU_BUILD_BUG_ON(ACPI_CPU_HOTPLUG_ID_LIMIT > 256);
-if (pcms->apic_id_limit > ACPI_CPU_HOTPLUG_ID_LIMIT) {
+if (pcms->acpi_configuration.apic_id_limit > ACPI_CPU_HOTPLUG_ID_LIMIT) {
 error_report("max_cpus is too large. APIC ID of last CPU is %u",
- pcms->apic_id_limit - 1);
+ pcms->acpi_configuration.apic_id_limit - 1);
 exit(1);
 }
 
@@ -316,8 +316,9 @@ void build_legacy_cpu_hotplug_aml(Aml *ctx, MachineState 
*machine,
  * ith up to 255 elements. Windows guests up to win2k8 fail when
  * VarPackageOp is used.
  */
-pkg = pcms->apic_id_limit <= 255 ? aml_package(pcms->apic_id_limit) :
-   aml_varpackage(pcms->apic_id_limit);
+pkg = pcms->acpi_configuration.apic_id_limit <= 255 ?
+aml_package(pcms->acpi_configuration.apic_id_limit) :
+aml_varpackage(pcms->acpi_configuration.apic_id_limit);
 
 for (i = 0, apic_idx = 0; i < apic_ids->len; i++) {
 int apic_id = apic_ids->cpus[i].arch_id;
diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
index 5785fb697c..f28a2faa53 100644
--- a/hw/arm/virt-acpi-build.c
+++ b/hw/arm/virt-acpi-build.c
@@ -790,16 +790,6 @@ build_dsdt(GArray *table_data, BIOSLinker *linker, 
VirtMachineState *vms)
 free_aml_allocator();
 }
 
-typedef
-struct AcpiBuildState {
-/* Copy of table in RAM (for patching). */
-MemoryRegion *table_mr;
-MemoryRegion *rsdp_mr;
-MemoryRegion *linker_mr;
-/* Is table patched? */
-bool patched;
-} AcpiBuildState;
-
 static
 void virt_acpi_build(VirtMachineState *vms, AcpiBuildTables *tables)
 {
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 1599caa7c5..c8545238c4 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -338,13 +338,14 @@ void pc_madt_cpu_entry(AcpiDeviceIf *adev, int uid,
 }
 
 static void
-build_madt(GArray *table_data, BIOSLinker *linker, PCMachineState *pcms)
+build_madt(GArray *table_data, BIOSLinker *linker,
+   MachineState *ms, AcpiConfiguration *conf)
 {
-MachineClass *mc = MACHINE_GET_CLASS(pcms);
-const CPUArchIdList *apic_ids = mc->possible_cpu_arch_ids(MACHINE(pcms));
+MachineClass *mc = MACHINE_GET_CLASS(ms);
+const CPUArchIdList *apic_ids = mc->possible_cpu_arch_ids(ms);
 int madt_start = table_data->len;
-AcpiDeviceIfClass *adevc = ACPI_DEVICE_IF_GET_CLASS(pcms->acpi_dev);
-AcpiDeviceIf *adev = ACPI_DEVICE_IF(pcms->acpi_dev);
+AcpiDeviceIfClass *adevc = ACPI_DEVICE_IF_GET_CLASS(conf->acpi_dev);
+AcpiDeviceIf *adev = ACPI_DEVICE_IF(conf->acpi_dev);
 bool x2apic_mode = false;
 
 AcpiMultipleApicTable *madt;
@@ -370,7 +371,7 @@ build_madt(GArray *table_data, BIOSLinker *linker, 
PCMachineState *pcms)
 io_apic->address = cpu_to_le32(IO_APIC_DEFAULT_ADDRESS);
 io_apic->interrupt = cpu_to_le32(0);
 
-if (pcms->apic_xrupt_override) {
+if (conf->apic_xrupt_override) {
 intsrcovr = acpi_data_push(table_data, sizeof *intsrcovr);
 intsrcovr->type   = ACPI_APIC_XRUPT_OVERRIDE;
 intsrcovr->length = sizeof(*intsrcovr);
@@ -1786,13 +1787,12 @@ static Aml *build_q35_osc_method(void)
 static void
 build_dsdt(GArray *table_data, BIOSLinker *linker,
AcpiPmInfo *pm, AcpiMiscInfo *misc,
-   Range *pci_hole, Range *pci_hole64, MachineState *machine)
+   Range *pci_hole, Range *pci_hole64,
+ 

[Xen-devel] [linux-linus bisection] complete test-amd64-amd64-amd64-pvgrub

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-amd64-pvgrub
testid xen-boot

Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  linux 
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
  Bug introduced:  69d5b97c597307773fe6c59775a5d5a88bb7e6b3
  Bug not present: 10dc890d4228cd17ddfd09ba9aaa9221627e29b2
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/129169/


  (Revision log too long, omitted.)


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-linus/test-amd64-amd64-amd64-pvgrub.xen-boot.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/linux-linus/test-amd64-amd64-amd64-pvgrub.xen-boot
 --summary-out=tmp/129169.bisection-summary --basis-template=125898 
--blessings=real,real-bisect linux-linus test-amd64-amd64-amd64-pvgrub xen-boot
Searching for failure / basis pass:
 129072 fail [host=huxelrebe1] / 128945 [host=godello0] 128920 [host=fiano1] 
128885 [host=elbling1] 128861 [host=fiano0] 128835 [host=debina1] 128727 
[host=debina0] 128663 [host=huxelrebe0] 128599 [host=baroque1] 128520 
[host=pinot1] 128493 [host=godello0] 128476 [host=godello1] 128461 
[host=albana1] 128438 [host=elbling0] 128407 [host=baroque0] 128369 
[host=fiano0] 128334 [host=albana0] 128312 [host=joubertin0] 128278 
[host=debina1] 128264 [host=fiano1] 128236 [host=debina0] 128170 
[host=elbling1] 128114 [host=italia0] 128059 [host=pinot0] 128022 
[host=baroque1] 128002 [host=pinot1] 127991 [host=godello0] 127976 
[host=godello1] 127962 ok.
Failure / basis pass flights: 129072 / 127962
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 69d5b97c597307773fe6c59775a5d5a88bb7e6b3 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149 
de5b678ca4dcdfa83e322491d478d66df56c1986 
92666fdd6e0afab989b2d89759d9b43f2c645ae7
Basis pass 10dc890d4228cd17ddfd09ba9aaa9221627e29b2 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149 
de5b678ca4dcdfa83e322491d478d66df56c1986 
1dfb8e6e0948912d1fd96d6ed9034527c5c74f31
Generating revisions with ./adhoc-revtuple-generator  
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#10dc890d4228cd17ddfd09ba9aaa9221627e29b2-69d5b97c597307773fe6c59775a5d5a88bb7e6b3
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/qemu-xen-traditional.git#9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149-9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149
 
git://xenbits.xen.org/qemu-xen.git#de5b678ca4dcdfa83e322491d478d66df56c1986-de5b678ca4dcdfa83e322491d478d66df56c1986
 
git://xenbits.xen.org/xen.git#1dfb8e6e0948912d1fd96d6ed9034527c5c74f31-92666fdd6e0afab989b2d89759d9b43f2c645ae7
adhoc-revtuple-generator: tree discontiguous: linux-2.6
Loaded 1002 nodes in revision graph
Searching for test results:
 127516 [host=albana0]
 127535 [host=albana0]
 127551 [host=albana0]
 127569 [host=albana0]
 127617 [host=albana0]
 127732 [host=rimava1]
 127793 [host=fiano0]
 127907 [host=albana1]
 127976 [host=godello1]
 127962 pass 10dc890d4228cd17ddfd09ba9aaa9221627e29b2 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149 
de5b678ca4dcdfa83e322491d478d66df56c1986 
1dfb8e6e0948912d1fd96d6ed9034527c5c74f31
 127991 [host=godello0]
 128002 [host=pinot1]
 128022 [host=baroque1]
 128059 [host=pinot0]
 128114 [host=italia0]
 128170 [host=elbling1]
 128264 [host=fiano1]
 128236 [host=debina0]
 128278 [host=debina1]
 128334 [host=albana0]
 128312 [host=joubertin0]
 128369 [host=fiano0]
 128407 [host=baroque0]
 128438 [host=elbling0]
 128476 [host=godello1]
 128461 [host=albana1]
 128493 [host=godello0]
 128520 [host=pinot1]
 128599 [host=baroque1]
 128663 [host=huxelrebe0]
 128727 [host=debina0]
 128861 [host=fiano0]
 128835 [host=debina1]
 128885 [host=elbling1]
 128920 [host=fiano1]
 128945 [host=godello0]
 128970 fail irrelevant
 129005 fail irrelevant
 129072 fail 69d5b97c597307773fe6c59775a5d5a88bb7e6b3 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149 
de5b678ca4dcdfa83e322491d478d66df56c1986 
92666fdd6e0afab989b2d89759d9b43f2c645ae7
 129146 

[Xen-devel] [ovmf test] 129162: all pass - PUSHED

[osstest service owner]

flight 129162 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129162/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf c87ac38cf280fa969f1033de3c5b7a157aac8cbc
baseline version:
 ovmf c09b254bdc6050cc8b580a26558f692f958645d6

Last test of basis   129125  2018-10-29 07:40:48 Z0 days
Testing same since   129162  2018-10-30 01:40:57 Z0 days1 attempts


People who touched revisions under test:
  Ruiyu Ni 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   c09b254bdc..c87ac38cf2  c87ac38cf280fa969f1033de3c5b7a157aac8cbc -> 
xen-tested-master

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

[Xen-devel] [ovmf baseline-only test] 75537: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 75537 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75537/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   6 libvirt-build   fail baseline untested
 build-i386-libvirt6 libvirt-build   fail baseline untested
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail baseline 
untested
 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail baseline 
untested

version targeted for testing:
 ovmf c09b254bdc6050cc8b580a26558f692f958645d6
baseline version:
 ovmf 2f6693c283b54666def65e5e0d0b84e48b21cfef

Last test of basis75532  2018-10-29 03:20:35 Z1 days
Testing same since75537  2018-10-29 10:52:10 Z0 days1 attempts


People who touched revisions under test:
  Chasel Chiu 
  Chasel, Chiu 
  Ruiyu Ni 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  fail
 build-i386-libvirt   fail
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail



sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xensource.com/osstest/logs

Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.


commit c09b254bdc6050cc8b580a26558f692f958645d6
Author: Chasel, Chiu 
Date:   Fri Oct 26 15:12:33 2018 +0800

IntelFsp2Pkg: Fixed potentially NULL pointer accessing

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1280

When copying IDT table in SecMain, the pointer might be
NULL so added the check to fix it.

Test: Verified on internal platform and boots successfully.

Cc: Jiewen Yao 
Cc: Desimone Nathaniel L 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Chasel Chiu 

commit 70425456dae16fca23540936c8fb0d2b86776b97
Author: Ruiyu Ni 
Date:   Thu Oct 25 18:09:46 2018 +0800

MdeModulePkg/UsbBusPei: Reject descriptor whose length is bad

Today's implementation doesn't check whether the length of
descriptor is valid before using it.

The patch fixes this issue by syncing the similar fix to UsbBusDxe.
70c3c2370a2aefe71cf0f6c1a1e063f7d74e1d79
*MdeModulePkg/UsbBus: Reject descriptor whose length is bad

Additionally the patch also rejects the data when length is
larger than sizeof (PeiUsbDevice->ConfigurationData).

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Reviewed-by: Star Zeng 
Cc: Jiewen Yao 

commit c96de1dbaedce11489974c3e977f1de4ec5cfb84
Author: Ruiyu Ni 
Date:   Thu Oct 25 17:07:12 2018 +0800

MdeModulePkg/UsbBusPei: Fix out-of-bound read access to descriptors

Today's implementation reads the Type/Length field in the USB
descriptors data without checking whether the offset to read is
beyond the data boundary.

The patch fixes this issue by syncing the fix in commit
4c034bf62cbc1f3c5f4b5df25de97f0f528132b2
*MdeModulePkg/UsbBus: Fix out-of-bound read access to descriptors

ParsedBytes in UsbBusPei.GetExpectedDescriptor() is different from
Consumed in UsbBusDxe.UsbCreateDesc().
ParsedBytes is the offset of found descriptor while Consumed is
offset of next descriptor of found one.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Reviewed-by: Star Zeng 
Cc: Jiewen Yao 

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

[Xen-devel] [XEN][ARM] WiFi bridge creation

[Vikram K]

Hello,

We are using Hikey960 with Debian as Dom0 and DomU. This board has only
WiFi interface. We want to create bridge between Dom0 and DomU so that DomU
has internet access. We tried to create bridge using brtcl command, but it
is not working. Please provide pointers.

-- 






This
message contains confidential information and is intended only 
for the
individual(s) named. If you are not the intended
recipient, you are 
notified that disclosing, copying, distributing or taking any
action in 
reliance on the contents of this mail and attached file/s is strictly

prohibited. Please notify the
sender immediately and delete this e-mail 
from your system. E-mail transmission
cannot be guaranteed to be secured or 
error-free as information could be
intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain
viruses. The sender therefore does 
not accept liability for any errors or
omissions in the contents of this 
message, which arise as a result of e-mail
transmission.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [xen-4.9-testing baseline-only test] 75535: trouble: blocked/broken/fail/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 75535 xen-4.9-testing real [real]
http://osstest.xensource.com/osstest/logs/75535/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf  broken

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-midway1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 build-armhf   4 host-install(4)   broken baseline untested
 test-amd64-i386-xl-raw   10 debian-di-install   fail baseline untested
 test-amd64-i386-xl-qemut-ws16-amd64 10 windows-install  fail baseline untested
 test-amd64-amd64-i386-pvgrub 19 guest-start/debian.repeat fail baseline 
untested
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail baseline 
untested
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop   fail baseline untested
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop  fail baseline untested
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop   fail baseline untested
 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail baseline 
untested
 test-amd64-i386-xl-qemut-win10-i386 17 guest-stop   fail baseline untested
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-install fail baseline untested
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass

version targeted for testing:
 xen  f294d80e8e43d4cdcc6d4d94b1e9c9b1aadf67d8
baseline version:
 xen  782ca9b94f77026875dd98d6288fc1f8dcc7ce19

Last test of basis75474  2018-10-22 03:18:08 Z8 days
Testing same since75535  2018-10-29 09:18:10 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64-xtf  pass
 build-amd64  pass
 build-armhf  broken  
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  blocked 
 build-i386-libvirt   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumprun  pass
 build-i386-rumprun   pass
 test-xtf-amd64-amd64-1   pass
 test-xtf-amd64-amd64-2   pass
 test-xtf-amd64-amd64-3   pass
 test-xtf-amd64-amd64-4   pass
 test-xtf-amd64-amd64-5   pass
 test-amd64-amd64-xl 

[Xen-devel] [linux-linus test] 129105: regressions - trouble: broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl  broken
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR. vs. 
125898
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 xen-boot fail REGR. vs. 125898
 test-amd64-i386-xl-pvshim 7 xen-boot fail REGR. vs. 125898
 test-amd64-i386-freebsd10-i386  7 xen-boot   fail REGR. vs. 125898
 test-amd64-amd64-xl-xsm   7 xen-boot fail REGR. vs. 125898
 test-amd64-amd64-xl-qemut-debianhvm-amd64  7 xen-bootfail REGR. vs. 125898
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
125898
 test-amd64-amd64-amd64-pvgrub  7 xen-bootfail REGR. vs. 125898
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  7 xen-boot fail REGR. vs. 125898
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
125898
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  7 xen-boot fail REGR. vs. 125898
 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 125898
 test-amd64-i386-xl-qemuu-win10-i386  7 xen-boot  fail REGR. vs. 125898
 test-amd64-amd64-qemuu-nested-intel  7 xen-boot  fail REGR. vs. 125898
 test-amd64-amd64-xl-qemut-win7-amd64  7 xen-boot fail REGR. vs. 125898
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
125898
 test-amd64-amd64-xl-qemut-win10-i386  7 xen-boot fail REGR. vs. 125898
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 125898
 test-amd64-amd64-xl-shadow7 xen-boot fail REGR. vs. 125898
 test-amd64-i386-xl-qemut-win7-amd64  7 xen-boot  fail REGR. vs. 125898
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  7 xen-bootfail REGR. vs. 125898
 test-amd64-i386-freebsd10-amd64  7 xen-boot  fail REGR. vs. 125898
 test-amd64-amd64-xl-credit2   7 xen-boot fail REGR. vs. 125898
 test-amd64-i386-libvirt-xsm   7 xen-boot fail REGR. vs. 125898
 test-amd64-i386-qemuu-rhel6hvm-intel  7 xen-boot fail REGR. vs. 125898
 test-amd64-amd64-xl   7 xen-boot fail REGR. vs. 125898
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs. 
125898
 test-amd64-amd64-i386-pvgrub  7 xen-boot fail REGR. vs. 125898
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. 
vs. 125898
 test-amd64-amd64-qemuu-nested-amd  7 xen-bootfail REGR. vs. 125898
 test-amd64-amd64-xl-qemuu-win10-i386  7 xen-boot fail REGR. vs. 125898
 test-amd64-i386-qemut-rhel6hvm-amd  7 xen-boot   fail REGR. vs. 125898
 test-amd64-amd64-xl-pvhv2-amd  7 xen-bootfail REGR. vs. 125898
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR. 
vs. 125898
 test-amd64-amd64-xl-qemut-ws16-amd64  7 xen-boot fail REGR. vs. 125898
 test-amd64-amd64-xl-qcow2 7 xen-boot fail REGR. vs. 125898
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 125898
 test-amd64-amd64-libvirt-vhd  7 xen-boot fail REGR. vs. 125898
 test-amd64-amd64-libvirt-pair 10 xen-boot/src_host   fail REGR. vs. 125898
 test-amd64-amd64-libvirt-pair 11 xen-boot/dst_host   fail REGR. vs. 125898
 test-amd64-amd64-xl-multivcpu  7 xen-bootfail REGR. vs. 125898
 test-amd64-amd64-pygrub   7 xen-boot fail REGR. vs. 125898
 test-amd64-amd64-xl-qemuu-win7-amd64  7 xen-boot fail REGR. vs. 125898
 test-amd64-amd64-rumprun-amd64  7 xen-boot   fail REGR. vs. 125898
 test-amd64-amd64-pair10 xen-boot/src_hostfail REGR. vs. 125898
 test-amd64-amd64-pair11 xen-boot/dst_hostfail REGR. vs. 125898
 test-amd64-amd64-libvirt-xsm  7 xen-boot fail REGR. vs. 125898
 test-amd64-i386-examine   8 reboot   fail REGR. vs. 125898
 test-amd64-i386-xl-qemuu-ws16-amd64  7 xen-boot  fail REGR. vs. 125898
 test-amd64-i386-xl-qemut-ws16-amd64  7 xen-boot  fail REGR. vs. 125898
 test-amd64-i386-rumprun-i386  7 xen-boot fail REGR. vs. 125898
 test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 125898
 test-amd64-i386-libvirt   7 xen-boot fail REGR. vs. 125898
 test-amd64-i386-xl-shadow 7 xen-boot fail REGR. vs. 125898
 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 125898
 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 125898
 test-amd64-i386-xl7 xen-boot fail REGR. vs. 125898
 test-amd64-i386-qemut-rhel6hvm-intel  7 xen-boot fail REGR. vs. 125898
 test-amd64-amd64-xl-qemuu-ws16-amd64  7 xen-boot  

Re: [Xen-devel] [PATCH] xen-swiotlb: exchange memory with Xen only when pages are contiguous

[Joe Jin]

On 10/25/18 11:56 AM, Joe Jin wrote:
> I just discussed this patch with Boris in private, his opinions(Boris,
> please correct me if any misunderstood) are:
> 
> 1. With/without the check, both are incorrect, he thought we need to
>prevented unalloc'd free at here. 
> 2. On freeing, if upper layer already checked the memory was DMA-able,
>the checking at here does not make sense, we can remove all checks.
> 3. xen_create_contiguous_region() and xen_destroy_contiguous_region()
>to come in pairs.
I tried to added radix_tree to track allocating/freeing and I found some
memory only allocated but was not freed, I guess it caused by driver used
dma_pool, that means if lots of such requests, the list will consume lot
of memory for it. Will continue to work on it, if anyone have good idea
for it please let me know, I'd like to try it.

Thanks,
Joe

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

Re: [Xen-devel] [RFC 08/16] xen/arm: p2m: Handle translation fault in get_page_from_gva

[Stefano Stabellini]

On Mon, 8 Oct 2018, Julien Grall wrote:
> A follow-up patch will re-purpose the valid bit of LPAE entries to
> generate fault even on entry containing valid information.
> 
> This means that when translation a guest VA to guest PA (e.g IPA) will
> fail if the Stage-2 entries used have the valid bit unset. Because of
> that, we need to fallback to walk the page-table in software to check
> whether the fault was expected.
> 
> This patch adds the software page-table walk on all the translation
> fault. It would be possible in the future to avoid pointless walk when
> the fault in PAR_EL1 is not a translation fault.
> 
> Signed-off-by: Julien Grall 
> 
> ---
> 
> There are a couple of TODO in the code. They are clean-up and performance
> improvement (e.g when the fault cannot be handled) that could be delayed after
> the series has been merged.
> ---
>  xen/arch/arm/p2m.c | 65 
> --
>  1 file changed, 58 insertions(+), 7 deletions(-)
> 
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index 2a1e7e9be2..ec956bc151 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -13,6 +13,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -1438,6 +1439,8 @@ struct page_info *get_page_from_gva(struct vcpu *v, 
> vaddr_t va,
>  struct page_info *page = NULL;
>  paddr_t maddr = 0;
>  uint64_t par;
> +mfn_t mfn;
> +p2m_type_t t;
>  
>  /*
>   * XXX: To support a different vCPU, we would need to load the
> @@ -1454,8 +1457,30 @@ struct page_info *get_page_from_gva(struct vcpu *v, 
> vaddr_t va,
>  par = gvirt_to_maddr(va, , flags);
>  p2m_read_unlock(p2m);
>  
> +/*
> + * gvirt_to_maddr may fail if the entry does not have the valid bit
> + * set. Fallback
> + * to the second method:

pointless newline

> + *  1) Translate the VA to IPA using software lookup -> Stage-1 
> page-table
> + *  may not be accessible because the stage-2 entries may have valid
> + *  bit unset.
> + *  2) Software lookup of the MFN
> + *
> + * Note that when memaccess is enabled, we instead all directly
> + * p2m_mem_access_check_and_get_page(...). Because the function is a
> + * a variant of the methods described above, it will be able to
> + * handle entry with valid bit unset.
 ^ entries

> + * TODO: Integrate more nicely memaccess with the rest of the
> + * function.
> + * TODO: Use the fault error in PAR_EL1 to avoid pointless
> + *  translation.
> + */
>  if ( par )
>  {
> +paddr_t ipa;
> +unsigned int perms;
> +
>  /*
>   * When memaccess is enabled, the translation GVA to MADDR may
>   * have failed because of a permission fault.
> @@ -1463,20 +1488,46 @@ struct page_info *get_page_from_gva(struct vcpu *v, 
> vaddr_t va,
>  if ( p2m->mem_access_enabled )
>  return p2m_mem_access_check_and_get_page(va, flags, v);
>  
> -dprintk(XENLOG_G_DEBUG,
> -"%pv: gvirt_to_maddr failed va=%#"PRIvaddr" flags=0x%lx 
> par=%#"PRIx64"\n",
> -v, va, flags, par);
> -return NULL;
> +/*
> + * The software stage-1 table walk can still fail, e.g, if the
> + * GVA is not mapped.
> + */
> +if ( !guest_walk_tables(v, va, , ) )
> +{
> +dprintk(XENLOG_G_DEBUG, "%pv: Failed to walk page-table va 
> %#"PRIvaddr"\n", v, va);

Greater than 80 chars line.


> +return NULL;
> +}
> +
> +/*
> + * Check permission that are assumed by the caller. For instance
> + * in case of guestcopy, the caller assumes that the translated
> + * page can be accessed with the requested permissions. If this
> + * is not the case, we should fail.
> + *
> + * Please note that we do not check for the GV2M_EXEC
> + * permission. This is fine because the hardware-based translation
> + * instruction does not test for execute permissions.
> + */
> +if ( (flags & GV2M_WRITE) && !(perms & GV2M_WRITE) )
> +return NULL;
> +
> +mfn = p2m_lookup(d, gaddr_to_gfn(ipa), );
> +if ( mfn_eq(INVALID_MFN, mfn) )
> +return NULL;
> +
> +/* We consider that RAM is always mapped read-write */

Is the RW assumption required? I can think of a case where RAM is mapped
RO at stage2.


>  }
> +else
> +mfn = maddr_to_mfn(maddr);
>  
> -if ( !mfn_valid(maddr_to_mfn(maddr)) )
> +if ( !mfn_valid(mfn) )
>  {
>  dprintk(XENLOG_G_DEBUG, "%pv: Invalid MFN %#"PRI_mfn"\n",
> -v, mfn_x(maddr_to_mfn(maddr)));
> +v, mfn_x(mfn));
>  return NULL;
>  }
>  
> -page = mfn_to_page(maddr_to_mfn(maddr));
> +page = mfn_to_page(mfn);
>  ASSERT(page);
>  
>  if ( unlikely(!get_page(page, d)) )
> -- 

[Xen-devel] [linux-4.4 test] 129123: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-libvirt6 libvirt-buildfail REGR. vs. 129086
 test-amd64-amd64-libvirt-vhd 11 guest-start  fail REGR. vs. 129086
 build-i386-pvops  6 kernel-build fail REGR. vs. 129086

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-pvshim 1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win10-i386  1 build-check(1)  blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-shadow 1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemut-win10-i386  1 build-check(1)  blocked n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-examine   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-arm64-arm64-examine  8 reboot   fail   never pass
 test-arm64-arm64-xl-xsm   7 xen-boot fail   never pass
 test-arm64-arm64-xl   7 xen-boot fail   never pass
 test-arm64-arm64-xl-credit2   7 xen-boot fail   never pass
 test-arm64-arm64-libvirt-xsm  7 xen-boot fail   never pass
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-arm64-arm64-xl-credit1   7 xen-boot fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-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-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-xl-qemuu-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-credit1  13 

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  ce75973a273f6cacce2b2b8ace1d3ab4b304c361
baseline version:
 xen  dafd936dddbd7978d4131275ad1112f64457bf64

Last test of basis   129141  2018-10-29 15:00:41 Z0 days
Testing same since   129151  2018-10-29 22:00:24 Z0 days1 attempts


People who touched revisions under test:
  Julien Grall 
  Stefano Stabellini 

jobs:
 build-arm64-xsm  pass
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   dafd936ddd..ce75973a27  ce75973a273f6cacce2b2b8ace1d3ab4b304c361 -> smoke

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

Re: [Xen-devel] [RFC 07/16] xen/arm: p2m: Introduce p2m_is_valid and use it

[Stefano Stabellini]

On Mon, 8 Oct 2018, Julien Grall wrote:
> The LPAE format allows to store information in an entry even with the
> valid bit unset. In a follow-up patch, we will take advantage of this
> feature to re-purpose the valid bit for generating a translation fault
> even if an entry contains valid information.
> 
> So we need a different way to know whether an entry contains valid
> information. It is possible to use the information hold in the p2m_type
> to know for that purpose. Indeed all entries containing valid
> information will have a valid p2m type (i.e p2m_type != p2m_invalid).
> 
> This patch introduces a new helper p2m_is_valid, which implements that
> idea, and replace most of lpae_is_valid call with the new helper. The ones
> remaining are for TLBs handling and entries accounting.
> 
> With the renaming there are 2 others changes required:
> - Generate table entry with a valid p2m type
> - Detect new mapping for proper stats accounting
> 
> Signed-off-by: Julien Grall 
> ---
>  xen/arch/arm/p2m.c | 34 +++---
>  1 file changed, 23 insertions(+), 11 deletions(-)
> 
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index 6c76298ebc..2a1e7e9be2 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -220,17 +220,26 @@ static p2m_access_t p2m_mem_access_radix_get(struct 
> p2m_domain *p2m, gfn_t gfn)
>  }
>  
>  /*
> + * In the case of the P2M, the valid bit is used for other purpose. Use
> + * the type to check whether an entry is valid.
> + */
> +static inline bool p2m_is_valid(lpae_t pte)
> +{
> +return pte.p2m.type != p2m_invalid;
> +}
> +
> +/*
>   * lpae_is_* helpers don't check whether the valid bit is set in the
>   * PTE. Provide our own overlay to check the valid bit.
>   */
>  static inline bool p2m_is_mapping(lpae_t pte, unsigned int level)
>  {
> -return lpae_is_valid(pte) && lpae_is_mapping(pte, level);
> +return p2m_is_valid(pte) && lpae_is_mapping(pte, level);
>  }
>  
>  static inline bool p2m_is_superpage(lpae_t pte, unsigned int level)
>  {
> -return lpae_is_valid(pte) && lpae_is_superpage(pte, level);
> +return p2m_is_valid(pte) && lpae_is_superpage(pte, level);
>  }
>  
>  #define GUEST_TABLE_MAP_FAILED 0
> @@ -264,7 +273,7 @@ static int p2m_next_level(struct p2m_domain *p2m, bool 
> read_only,
>  
>  entry = *table + offset;
>  
> -if ( !lpae_is_valid(*entry) )
> +if ( !p2m_is_valid(*entry) )
>  {
>  if ( read_only )
>  return GUEST_TABLE_MAP_FAILED;
> @@ -356,7 +365,7 @@ mfn_t p2m_get_entry(struct p2m_domain *p2m, gfn_t gfn,
>  
>  entry = table[offsets[level]];
>  
> -if ( lpae_is_valid(entry) )
> +if ( p2m_is_valid(entry) )
>  {
>  *t = entry.p2m.type;
>  
> @@ -544,8 +553,11 @@ static lpae_t page_to_p2m_table(struct page_info *page)
>  /*
>   * The access value does not matter because the hardware will ignore
>   * the permission fields for table entry.
> + *
> + * We use p2m_ram_rw so the entry has a valid type. This is important
> + * for p2m_is_valid() to return valid on table entries.
>   */
> -return mfn_to_p2m_entry(page_to_mfn(page), p2m_invalid, p2m_access_rwx);
> +return mfn_to_p2m_entry(page_to_mfn(page), p2m_ram_rw, p2m_access_rwx);
>  }
>  
>  static inline void p2m_write_pte(lpae_t *p, lpae_t pte, bool clean_pte)
> @@ -569,7 +581,7 @@ static int p2m_create_table(struct p2m_domain *p2m, 
> lpae_t *entry)
>  struct page_info *page;
>  lpae_t *p;
>  
> -ASSERT(!lpae_is_valid(*entry));
> +ASSERT(!p2m_is_valid(*entry));
>  
>  page = alloc_domheap_page(NULL, 0);
>  if ( page == NULL )
> @@ -626,7 +638,7 @@ static int p2m_mem_access_radix_set(struct p2m_domain 
> *p2m, gfn_t gfn,
>   */
>  static void p2m_put_l3_page(const lpae_t pte)
>  {
> -ASSERT(lpae_is_valid(pte));
> +ASSERT(p2m_is_valid(pte));
>  
>  /*
>   * TODO: Handle other p2m types
> @@ -654,11 +666,11 @@ static void p2m_free_entry(struct p2m_domain *p2m,
>  struct page_info *pg;
>  
>  /* Nothing to do if the entry is invalid. */
> -if ( !lpae_is_valid(entry) )
> +if ( !p2m_is_valid(entry) )
>  return;
>  
>  /* Nothing to do but updating the stats if the entry is a super-page. */
> -if ( p2m_is_superpage(entry, level) )
> +if ( level == 3 && entry.p2m.table )

Why?


>  {
>  p2m->stats.mappings[level]--;
>  return;
> @@ -951,7 +963,7 @@ static int __p2m_set_entry(struct p2m_domain *p2m,
>  else
>  p2m->need_flush = true;
>  }
> -else /* new mapping */
> +else if ( !p2m_is_valid(orig_pte) ) /* new mapping */

There are a couple of lpae_is_valid checks just above this line that you
missed, why haven't you changed them?

If you have a good reason, please explain in a comment and/or commit
message.

>  p2m->stats.mappings[level]++;
>  
>  p2m_write_pte(entry, pte, p2m->clean_pte);
> 

Re: [Xen-devel] [RFC 06/16] xen/arm: p2m: Introduce a helper to generate P2M table entry from a page

[Stefano Stabellini]

On Mon, 8 Oct 2018, Julien Grall wrote:
> Generate P2M table entry requires to set some default values which are
> worth to explain in a comment. At the moment, there are 2 places where
> such entry are created but only one as proper comment.
> 
> Some move the code to generate P2M table entry in a separate helper.
> This will be helpful in a follow-up patch to make modification on the
> defaults.
> 
> At the same time, switch the default access from p2m->default_access to
> p2m_access_rwx. This should not matter as permission are ignored for
> table by the hardware.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 

> ---
>  xen/arch/arm/p2m.c | 25 -
>  1 file changed, 12 insertions(+), 13 deletions(-)
> 
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index 8fffb42889..6c76298ebc 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -538,6 +538,16 @@ static lpae_t mfn_to_p2m_entry(mfn_t mfn, p2m_type_t t, 
> p2m_access_t a)
>  return e;
>  }
>  
> +/* Generate table entry with correct attributes. */
> +static lpae_t page_to_p2m_table(struct page_info *page)
> +{
> +/*
> + * The access value does not matter because the hardware will ignore
> + * the permission fields for table entry.
> + */
> +return mfn_to_p2m_entry(page_to_mfn(page), p2m_invalid, p2m_access_rwx);
> +}
> +
>  static inline void p2m_write_pte(lpae_t *p, lpae_t pte, bool clean_pte)
>  {
>  write_pte(p, pte);
> @@ -558,7 +568,6 @@ static int p2m_create_table(struct p2m_domain *p2m, 
> lpae_t *entry)
>  {
>  struct page_info *page;
>  lpae_t *p;
> -lpae_t pte;
>  
>  ASSERT(!lpae_is_valid(*entry));
>  
> @@ -576,14 +585,7 @@ static int p2m_create_table(struct p2m_domain *p2m, 
> lpae_t *entry)
>  
>  unmap_domain_page(p);
>  
> -/*
> - * The access value does not matter because the hardware will ignore
> - * the permission fields for table entry.
> - */
> -pte = mfn_to_p2m_entry(page_to_mfn(page), p2m_invalid,
> -   p2m->default_access);
> -
> -p2m_write_pte(entry, pte, p2m->clean_pte);
> +p2m_write_pte(entry, page_to_p2m_table(page), p2m->clean_pte);
>  
>  return 0;
>  }
> @@ -764,14 +766,11 @@ static bool p2m_split_superpage(struct p2m_domain *p2m, 
> lpae_t *entry,
>  
>  unmap_domain_page(table);
>  
> -pte = mfn_to_p2m_entry(page_to_mfn(page), p2m_invalid,
> -   p2m->default_access);
> -
>  /*
>   * Even if we failed, we should install the newly allocated LPAE
>   * entry. The caller will be in charge to free the sub-tree.
>   */
> -p2m_write_pte(entry, pte, p2m->clean_pte);
> +p2m_write_pte(entry, page_to_p2m_table(page), p2m->clean_pte);
>  
>  return rv;
>  }
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] [RFC 05/16] xen/arm: traps: Move the implementation of GUEST_BUG_ON in traps.h

[Stefano Stabellini]

On Mon, 8 Oct 2018, Julien Grall wrote:
> GUEST_BUG_ON may be used in other files doing guest emulation.
> 
> Signed-off-by: Julien Grall 

Acked-by: Stefano Stabellini 


> ---
> 
> The patch was previously sent separately.
> ---
>  xen/arch/arm/traps.c| 24 
>  xen/include/asm-arm/traps.h | 24 
>  2 files changed, 24 insertions(+), 24 deletions(-)
> 
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 9251ae50b8..b40798084d 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -68,30 +68,6 @@ static inline void check_stack_alignment_constraints(void) 
> {
>  #endif
>  }
>  
> -/*
> - * GUEST_BUG_ON is intended for checking that the guest state has not been
> - * corrupted in hardware and/or that the hardware behaves as we
> - * believe it should (i.e. that certain traps can only occur when the
> - * guest is in a particular mode).
> - *
> - * The intention is to limit the damage such h/w bugs (or spec
> - * misunderstandings) can do by turning them into Denial of Service
> - * attacks instead of e.g. information leaks or privilege escalations.
> - *
> - * GUEST_BUG_ON *MUST* *NOT* be used to check for guest controllable state!
> - *
> - * Compared with regular BUG_ON it dumps the guest vcpu state instead
> - * of Xen's state.
> - */
> -#define guest_bug_on_failed(p)  \
> -do {\
> -show_execution_state(guest_cpu_user_regs());\
> -panic("Guest Bug: %pv: '%s', line %d, file %s\n",   \
> -  current, p, __LINE__, __FILE__);  \
> -} while (0)
> -#define GUEST_BUG_ON(p) \
> -do { if ( unlikely(p) ) guest_bug_on_failed(#p); } while (0)
> -
>  #ifdef CONFIG_ARM_32
>  static int debug_stack_lines = 20;
>  #define stack_words_per_line 8
> diff --git a/xen/include/asm-arm/traps.h b/xen/include/asm-arm/traps.h
> index 70b52d1d16..0acf7de67d 100644
> --- a/xen/include/asm-arm/traps.h
> +++ b/xen/include/asm-arm/traps.h
> @@ -9,6 +9,30 @@
>  # include 
>  #endif
>  
> +/*
> + * GUEST_BUG_ON is intended for checking that the guest state has not been
> + * corrupted in hardware and/or that the hardware behaves as we
> + * believe it should (i.e. that certain traps can only occur when the
> + * guest is in a particular mode).
> + *
> + * The intention is to limit the damage such h/w bugs (or spec
> + * misunderstandings) can do by turning them into Denial of Service
> + * attacks instead of e.g. information leaks or privilege escalations.
> + *
> + * GUEST_BUG_ON *MUST* *NOT* be used to check for guest controllable state!
> + *
> + * Compared with regular BUG_ON it dumps the guest vcpu state instead
> + * of Xen's state.
> + */
> +#define guest_bug_on_failed(p)  \
> +do {\
> +show_execution_state(guest_cpu_user_regs());\
> +panic("Guest Bug: %pv: '%s', line %d, file %s\n",   \
> +  current, p, __LINE__, __FILE__);  \
> +} while (0)
> +#define GUEST_BUG_ON(p) \
> +do { if ( unlikely(p) ) guest_bug_on_failed(#p); } while (0)
> +
>  int check_conditional_instr(struct cpu_user_regs *regs, const union hsr hsr);
>  
>  void advance_pc(struct cpu_user_regs *regs, const union hsr hsr);
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] [RFC 03/16] xen/arm: Allow lpae_is_{table, mapping} helpers to work on invalid entry

[Stefano Stabellini]

On Mon, 8 Oct 2018, Julien Grall wrote:
> Currently, lpae_is_{table, mapping} helpers will always return false on
> entries with the valid bit unset. However, it would be useful to have them
> operating on any entry. For instance to store information in advance but
> still request a fault.
> 
> With that change, the p2m is now providing an overlay for *_is_{table,
> mapping} that will check the valid bit of the entry.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 

> ---
> 
> The patch was previously sent separately.
> ---
>  xen/arch/arm/guest_walk.c  |  2 +-
>  xen/arch/arm/mm.c  |  2 +-
>  xen/arch/arm/p2m.c | 22 ++
>  xen/include/asm-arm/lpae.h | 11 +++
>  4 files changed, 27 insertions(+), 10 deletions(-)
> 
> diff --git a/xen/arch/arm/guest_walk.c b/xen/arch/arm/guest_walk.c
> index e3e21bdad3..4a1b4cf2c8 100644
> --- a/xen/arch/arm/guest_walk.c
> +++ b/xen/arch/arm/guest_walk.c
> @@ -566,7 +566,7 @@ static int guest_walk_ld(const struct vcpu *v,
>   * PTE is invalid or holds a reserved entry (PTE<1:0> == x0)) or if the 
> PTE
>   * maps a memory block at level 3 (PTE<1:0> == 01).
>   */
> -if ( !lpae_is_mapping(pte, level) )
> +if ( !lpae_is_valid(pte) || !lpae_is_mapping(pte, level) )
>  return -EFAULT;
>  
>  /* Make sure that the lower bits of the PTE's base address are zero. */
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index 0bc31b1d9b..987fcb9162 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -996,7 +996,7 @@ static int create_xen_entries(enum xenmap_operation op,
>  for(; addr < addr_end; addr += PAGE_SIZE, mfn = mfn_add(mfn, 1))
>  {
>  entry = _second[second_linear_offset(addr)];
> -if ( !lpae_is_table(*entry, 2) )
> +if ( !lpae_is_valid(*entry) || !lpae_is_table(*entry, 2) )
>  {
>  rc = create_xen_table(entry);
>  if ( rc < 0 ) {
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index f8a2f6459e..8fffb42889 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -219,6 +219,20 @@ static p2m_access_t p2m_mem_access_radix_get(struct 
> p2m_domain *p2m, gfn_t gfn)
>  return radix_tree_ptr_to_int(ptr);
>  }
>  
> +/*
> + * lpae_is_* helpers don't check whether the valid bit is set in the
> + * PTE. Provide our own overlay to check the valid bit.
> + */
> +static inline bool p2m_is_mapping(lpae_t pte, unsigned int level)
> +{
> +return lpae_is_valid(pte) && lpae_is_mapping(pte, level);
> +}
> +
> +static inline bool p2m_is_superpage(lpae_t pte, unsigned int level)
> +{
> +return lpae_is_valid(pte) && lpae_is_superpage(pte, level);
> +}
> +
>  #define GUEST_TABLE_MAP_FAILED 0
>  #define GUEST_TABLE_SUPER_PAGE 1
>  #define GUEST_TABLE_NORMAL_PAGE 2
> @@ -262,7 +276,7 @@ static int p2m_next_level(struct p2m_domain *p2m, bool 
> read_only,
>  
>  /* The function p2m_next_level is never called at the 3rd level */
>  ASSERT(level < 3);
> -if ( lpae_is_mapping(*entry, level) )
> +if ( p2m_is_mapping(*entry, level) )
>  return GUEST_TABLE_SUPER_PAGE;
>  
>  mfn = lpae_get_mfn(*entry);
> @@ -642,7 +656,7 @@ static void p2m_free_entry(struct p2m_domain *p2m,
>  return;
>  
>  /* Nothing to do but updating the stats if the entry is a super-page. */
> -if ( lpae_is_superpage(entry, level) )
> +if ( p2m_is_superpage(entry, level) )
>  {
>  p2m->stats.mappings[level]--;
>  return;
> @@ -697,7 +711,7 @@ static bool p2m_split_superpage(struct p2m_domain *p2m, 
> lpae_t *entry,
>   * a superpage.
>   */
>  ASSERT(level < target);
> -ASSERT(lpae_is_superpage(*entry, level));
> +ASSERT(p2m_is_superpage(*entry, level));
>  
>  page = alloc_domheap_page(NULL, 0);
>  if ( !page )
> @@ -836,7 +850,7 @@ static int __p2m_set_entry(struct p2m_domain *p2m,
>  /* We need to split the original page. */
>  lpae_t split_pte = *entry;
>  
> -ASSERT(lpae_is_superpage(*entry, level));
> +ASSERT(p2m_is_superpage(*entry, level));
>  
>  if ( !p2m_split_superpage(p2m, _pte, level, target, offsets) )
>  {
> diff --git a/xen/include/asm-arm/lpae.h b/xen/include/asm-arm/lpae.h
> index 17fdc6074f..545b0c8f24 100644
> --- a/xen/include/asm-arm/lpae.h
> +++ b/xen/include/asm-arm/lpae.h
> @@ -133,16 +133,19 @@ static inline bool lpae_is_valid(lpae_t pte)
>  return pte.walk.valid;
>  }
>  
> +/*
> + * lpae_is_* don't check the valid bit. This gives an opportunity for the
> + * callers to operate on the entry even if they are not valid. For
> + * instance to store information in advance.
> + */
>  static inline bool lpae_is_table(lpae_t pte, unsigned int level)
>  {
> -return (level < 3) && lpae_is_valid(pte) && pte.walk.table;
> +return (level < 3) && pte.walk.table;
>  }
>  
>  static inline bool lpae_is_mapping(lpae_t pte, unsigned int level)
>  {
> -if ( 

Re: [Xen-devel] [RFC 02/16] xen/arm: Introduce helpers to get/set an MFN from/to an LPAE entry

[Stefano Stabellini]

On Mon, 8 Oct 2018, Julien Grall wrote:
> The new helpers make it easier to read the code by abstracting the way to
> set/get an MFN from/to an LPAE entry. The helpers are using "walk" as the
> bits are common across different LPAE stages.
> 
> At the same time, use the new helpers to replace the various open-coding
> place.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


> ---
> This patch was originally sent separately.
> ---
>  xen/arch/arm/mm.c  | 10 +-
>  xen/arch/arm/p2m.c | 19 ++-
>  xen/include/asm-arm/lpae.h |  3 +++
>  3 files changed, 18 insertions(+), 14 deletions(-)
> 
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index 7a06a33e21..0bc31b1d9b 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -238,7 +238,7 @@ void dump_pt_walk(paddr_t ttbr, paddr_t addr,
>  
>  /* For next iteration */
>  unmap_domain_page(mapping);
> -mapping = map_domain_page(_mfn(pte.walk.base));
> +mapping = map_domain_page(lpae_get_mfn(pte));
>  }
>  
>  unmap_domain_page(mapping);
> @@ -323,7 +323,7 @@ static inline lpae_t mfn_to_xen_entry(mfn_t mfn, unsigned 
> attr)
>  
>  ASSERT(!(mfn_to_maddr(mfn) & ~PADDR_MASK));
>  
> -e.pt.base = mfn_x(mfn);
> +lpae_set_mfn(e, mfn);
>  
>  return e;
>  }
> @@ -490,7 +490,7 @@ mfn_t domain_page_map_to_mfn(const void *ptr)
>  ASSERT(slot >= 0 && slot < DOMHEAP_ENTRIES);
>  ASSERT(map[slot].pt.avail != 0);
>  
> -return _mfn(map[slot].pt.base + offset);
> +return mfn_add(lpae_get_mfn(map[slot]), offset);
>  }
>  #endif
>  
> @@ -851,7 +851,7 @@ void __init setup_xenheap_mappings(unsigned long base_mfn,
>  /* mfn_to_virt is not valid on the 1st 1st mfn, since it
>   * is not within the xenheap. */
>  first = slot == xenheap_first_first_slot ?
> -xenheap_first_first : __mfn_to_virt(p->pt.base);
> +xenheap_first_first : mfn_to_virt(lpae_get_mfn(*p));
>  }
>  else if ( xenheap_first_first_slot == -1)
>  {
> @@ -1007,7 +1007,7 @@ static int create_xen_entries(enum xenmap_operation op,
>  
>  BUG_ON(!lpae_is_valid(*entry));
>  
> -third = __mfn_to_virt(entry->pt.base);
> +third = mfn_to_virt(lpae_get_mfn(*entry));
>  entry = [third_table_offset(addr)];
>  
>  switch ( op ) {
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index 30cfb01498..f8a2f6459e 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -265,7 +265,7 @@ static int p2m_next_level(struct p2m_domain *p2m, bool 
> read_only,
>  if ( lpae_is_mapping(*entry, level) )
>  return GUEST_TABLE_SUPER_PAGE;
>  
> -mfn = _mfn(entry->p2m.base);
> +mfn = lpae_get_mfn(*entry);
>  
>  unmap_domain_page(*table);
>  *table = map_domain_page(mfn);
> @@ -349,7 +349,7 @@ mfn_t p2m_get_entry(struct p2m_domain *p2m, gfn_t gfn,
>  if ( a )
>  *a = p2m_mem_access_radix_get(p2m, gfn);
>  
> -mfn = _mfn(entry.p2m.base);
> +mfn = lpae_get_mfn(entry);
>  /*
>   * The entry may point to a superpage. Find the MFN associated
>   * to the GFN.
> @@ -519,7 +519,7 @@ static lpae_t mfn_to_p2m_entry(mfn_t mfn, p2m_type_t t, 
> p2m_access_t a)
>  
>  ASSERT(!(mfn_to_maddr(mfn) & ~PADDR_MASK));
>  
> -e.p2m.base = mfn_x(mfn);
> +lpae_set_mfn(e, mfn);
>  
>  return e;
>  }
> @@ -621,7 +621,7 @@ static void p2m_put_l3_page(const lpae_t pte)
>   */
>  if ( p2m_is_foreign(pte.p2m.type) )
>  {
> -mfn_t mfn = _mfn(pte.p2m.base);
> +mfn_t mfn = lpae_get_mfn(pte);
>  
>  ASSERT(mfn_valid(mfn));
>  put_page(mfn_to_page(mfn));
> @@ -655,7 +655,7 @@ static void p2m_free_entry(struct p2m_domain *p2m,
>  return;
>  }
>  
> -table = map_domain_page(_mfn(entry.p2m.base));
> +table = map_domain_page(lpae_get_mfn(entry));
>  for ( i = 0; i < LPAE_ENTRIES; i++ )
>  p2m_free_entry(p2m, *(table + i), level + 1);
>  
> @@ -669,7 +669,7 @@ static void p2m_free_entry(struct p2m_domain *p2m,
>   */
>  p2m_tlb_flush_sync(p2m);
>  
> -mfn = _mfn(entry.p2m.base);
> +mfn = lpae_get_mfn(entry);
>  ASSERT(mfn_valid(mfn));
>  
>  pg = mfn_to_page(mfn);
> @@ -688,7 +688,7 @@ static bool p2m_split_superpage(struct p2m_domain *p2m, 
> lpae_t *entry,
>  bool rv = true;
>  
>  /* Convenience aliases */
> -mfn_t mfn = _mfn(entry->p2m.base);
> +mfn_t mfn = lpae_get_mfn(*entry);
>  unsigned int next_level = level + 1;
>  unsigned int level_order = level_orders[next_level];
>  
> @@ -719,7 +719,7 @@ static bool p2m_split_superpage(struct p2m_domain *p2m, 
> lpae_t *entry,
>   * the necessary fields. So the correct permission are kept.
>   */
>  pte = *entry;
> -pte.p2m.base = mfn_x(mfn_add(mfn, i << level_order));
> +

Re: [Xen-devel] [PATCH v2] CONFIG_XEN_PV breaks xen_create_contiguous_region on ARM

[Stefano Stabellini]

On Fri, 26 Oct 2018, Julien Grall wrote:
> Hi Stefano,
> 
> On 10/26/18 7:04 PM, Stefano Stabellini wrote:
> > From: Stefano Stabellini 
> > 
> > xen_create_contiguous_region has now only an implementation if
> > CONFIG_XEN_PV is defined. However, on ARM we never set CONFIG_XEN_PV but
> > we do have an implementation of xen_create_contiguous_region which is
> > required for swiotlb-xen to work correctly (although it just sets
> > *dma_handle).
> > 
> > Add a stub implementation of xen_remap_pfn: it should never be called on
> > ARM but it is necessary for linking.
> > 
> > This fixes a bug introduced by 16624390816c4c40df3d777b34665d3fd01e693d.
> 
> Again, this should contain a tag "Fixes: sha1 ("commit title")" so it can be
> picked for backporting automatically.

Yeah, I forgot about it, it should be definitely added.


> > Signed-off-by: Stefano Stabellini 
> > CC: jeff.kubas...@dornerworks.com
> > CC: jarvis.ro...@dornerworks.com
> > CC: nathan.stu...@dornerworks.com
> > CC: vkuzn...@redhat.com
> > CC: boris.ostrov...@oracle.com
> > CC: jgr...@suse.com
> > ---
> >   arch/arm/xen/mm.c | 8 
> >   include/xen/xen-ops.h | 2 +-
> >   2 files changed, 9 insertions(+), 1 deletion(-)
> > ---
> > Changes in v2:
> > - improve commit message
> > - add xen_remap_pfn stub implementation
> > - use if defined()
> > diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
> > index 785d2a5..7230e22 100644
> > --- a/arch/arm/xen/mm.c
> > +++ b/arch/arm/xen/mm.c
> > @@ -182,6 +182,14 @@ void xen_destroy_contiguous_region(phys_addr_t pstart,
> > unsigned int order)
> >   }
> >   EXPORT_SYMBOL_GPL(xen_destroy_contiguous_region);
> >   +int xen_remap_pfn(struct vm_area_struct *vma, unsigned long addr,
> > + xen_pfn_t *pfn, int nr, int *err_ptr, pgprot_t prot,
> > + unsigned int domid, bool no_translate, struct page **pages)
> > +{
> > +   return -EOPNOTSUPP;
> > +}
> > +EXPORT_SYMBOL_GPL(xen_remap_pfn);
> 
> This does not match the "unimplemented" version in xen-ops.h.
> 
> But I find this solution quite ugly. Why don't you split the #ifdef in two
> below?

I am happy to follow the maintainers' opinion on this. I would keep
those those definition together but I don't mind either way.


Juergen, Boris,

What do you prefer?


> > +
> >   const struct dma_map_ops *xen_dma_ops;
> >   EXPORT_SYMBOL(xen_dma_ops);
> >   diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
> > index 18803ff..765dd05 100644
> > --- a/include/xen/xen-ops.h
> > +++ b/include/xen/xen-ops.h
> > @@ -42,7 +42,7 @@ int xen_setup_shutdown_event(void);
> > extern unsigned long *xen_contiguous_bitmap;
> >   -#ifdef CONFIG_XEN_PV
> > +#if defined(CONFIG_XEN_PV) || defined(CONFIG_ARM) || defined(CONFIG_ARM64)
> >   int xen_create_contiguous_region(phys_addr_t pstart, unsigned int order,
> > unsigned int address_bits,
> > dma_addr_t *dma_handle);
> > 
> 
> Cheers,
> 
> -- 
> Julien Grall
> 

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

Re: [Xen-devel] [PATCH v2] arm, smmu: backport "Disable stalling faults for all endpoints"

[Julien Grall]

On 10/29/18 9:14 PM, Stefano Stabellini wrote:

From: Stefano Stabellini 

Backport commit 3714ce1d6655098ee69ede632883e5874d67e4ab
"iommu/arm-smmu: Disable stalling faults for all endpoints" from the
Linux kernel. This works-around Erratum #842869.

Original commit message:

   Enabling stalling faults can result in hardware deadlock on poorly
   designed systems, particularly those with a PCI root complex upstream of
   the SMMU.

   Although it's not really Linux's job to save hardware integrators from
   their own misfortune, it *is* our job to stop userspace (e.g. VFIO
   clients) from hosing the system for everybody else, even if they might
   already be required to have elevated privileges.

   Given that the fault handling code currently executes entirely in IRQ
   context, there is nothing that can sensibly be done to recover from
   things like page faults anyway, so let's rip this code out for now and
   avoid the potential for deadlock.

   Cc: 
   Fixes: 48ec83bcbcf5 ("iommu/arm-smmu: Add initial driver support for ARM SMMUv3 
devices")
   Reported-by: Matt Evans 
   Signed-off-by: Will Deacon 

Signed-off-by: Stefano Stabellini 


Acked-by: Julien Grall 

Cheers,



---
Changes in v2:
- add Erratum to docs/misc/arm/silicon-errata.txt
- add in-code comment about Erratum
---
  docs/misc/arm/silicon-errata.txt   |  1 +
  xen/drivers/passthrough/arm/smmu.c | 40 --
  2 files changed, 13 insertions(+), 28 deletions(-)

diff --git a/docs/misc/arm/silicon-errata.txt b/docs/misc/arm/silicon-errata.txt
index c9854c3..906bf5f 100644
--- a/docs/misc/arm/silicon-errata.txt
+++ b/docs/misc/arm/silicon-errata.txt
@@ -48,3 +48,4 @@ stable hypervisors.
  | ARM| Cortex-A57  | #852523 | N/A
 |
  | ARM| Cortex-A57  | #832075 | ARM64_ERRATUM_832075   
 |
  | ARM| Cortex-A57  | #834220 | ARM64_ERRATUM_834220   
 |
+| ARM| MMU-500 | #842869 | N/A 
|
diff --git a/xen/drivers/passthrough/arm/smmu.c 
b/xen/drivers/passthrough/arm/smmu.c
index b510399..9612c0f 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -898,8 +898,7 @@ static void arm_smmu_tlb_inv_context(struct arm_smmu_domain 
*smmu_domain)
  
  static irqreturn_t arm_smmu_context_fault(int irq, void *dev)

  {
-   int flags, ret;
-   u32 fsr, far, fsynr, resume;
+   u32 fsr, far, fsynr;
unsigned long iova;
struct iommu_domain *domain = dev;
struct arm_smmu_domain *smmu_domain = domain->priv;
@@ -913,13 +912,7 @@ static irqreturn_t arm_smmu_context_fault(int irq, void 
*dev)
if (!(fsr & FSR_FAULT))
return IRQ_NONE;
  
-	if (fsr & FSR_IGN)

-   dev_err_ratelimited(smmu->dev,
-   "Unexpected context fault (fsr 0x%x)\n",
-   fsr);
-
fsynr = readl_relaxed(cb_base + ARM_SMMU_CB_FSYNR0);
-   flags = fsynr & FSYNR0_WNR ? IOMMU_FAULT_WRITE : IOMMU_FAULT_READ;
  
  	far = readl_relaxed(cb_base + ARM_SMMU_CB_FAR_LO);

iova = far;
@@ -928,25 +921,12 @@ static irqreturn_t arm_smmu_context_fault(int irq, void 
*dev)
iova |= ((unsigned long)far << 32);
  #endif
  
-	if (!report_iommu_fault(domain, smmu->dev, iova, flags)) {

-   ret = IRQ_HANDLED;
-   resume = RESUME_RETRY;
-   } else {
-   dev_err_ratelimited(smmu->dev,
-   "Unhandled context fault: iova=0x%08lx, fsynr=0x%x, 
cb=%d\n",
-   iova, fsynr, cfg->cbndx);
-   ret = IRQ_NONE;
-   resume = RESUME_TERMINATE;
-   }
-
-   /* Clear the faulting FSR */
+   dev_err_ratelimited(smmu->dev,
+   "Unhandled context fault: fsr=0x%x, iova=0x%08lx, fsynr=0x%x, cb=%d\n",
+   fsr, iova, fsynr, cfg->cbndx);
+
writel(fsr, cb_base + ARM_SMMU_CB_FSR);
-
-   /* Retry or terminate any stalled transactions */
-   if (fsr & FSR_SS)
-   writel_relaxed(resume, cb_base + ARM_SMMU_CB_RESUME);
-
-   return ret;
+   return IRQ_HANDLED;
  }
  
  static irqreturn_t arm_smmu_global_fault(int irq, void *dev)

@@ -1180,8 +1160,12 @@ static void arm_smmu_init_context_bank(struct 
arm_smmu_domain *smmu_domain)
writel_relaxed(reg, cb_base + ARM_SMMU_CB_S1_MAIR0);
}
  
-	/* SCTLR */

-   reg = SCTLR_CFCFG | SCTLR_CFIE | SCTLR_CFRE | SCTLR_M | SCTLR_EAE_SBOP;
+   /*
+* SCTLR
+*
+* Do not set SCTLR_CFCFG, because of Erratum #842869
+*/
+   reg = SCTLR_CFIE | SCTLR_CFRE | SCTLR_M | SCTLR_EAE_SBOP;
if (stage1)
reg |= SCTLR_S1_ASIDPNE;
  #ifdef __BIG_ENDIAN



--
Julien Grall

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

[Xen-devel] [PATCH v2] arm, smmu: backport "Disable stalling faults for all endpoints"

[Stefano Stabellini]

From: Stefano Stabellini 

Backport commit 3714ce1d6655098ee69ede632883e5874d67e4ab
"iommu/arm-smmu: Disable stalling faults for all endpoints" from the
Linux kernel. This works-around Erratum #842869.

Original commit message:

  Enabling stalling faults can result in hardware deadlock on poorly
  designed systems, particularly those with a PCI root complex upstream of
  the SMMU.

  Although it's not really Linux's job to save hardware integrators from
  their own misfortune, it *is* our job to stop userspace (e.g. VFIO
  clients) from hosing the system for everybody else, even if they might
  already be required to have elevated privileges.

  Given that the fault handling code currently executes entirely in IRQ
  context, there is nothing that can sensibly be done to recover from
  things like page faults anyway, so let's rip this code out for now and
  avoid the potential for deadlock.

  Cc: 
  Fixes: 48ec83bcbcf5 ("iommu/arm-smmu: Add initial driver support for ARM 
SMMUv3 devices")
  Reported-by: Matt Evans 
  Signed-off-by: Will Deacon 

Signed-off-by: Stefano Stabellini 

---
Changes in v2:
- add Erratum to docs/misc/arm/silicon-errata.txt
- add in-code comment about Erratum
---
 docs/misc/arm/silicon-errata.txt   |  1 +
 xen/drivers/passthrough/arm/smmu.c | 40 --
 2 files changed, 13 insertions(+), 28 deletions(-)

diff --git a/docs/misc/arm/silicon-errata.txt b/docs/misc/arm/silicon-errata.txt
index c9854c3..906bf5f 100644
--- a/docs/misc/arm/silicon-errata.txt
+++ b/docs/misc/arm/silicon-errata.txt
@@ -48,3 +48,4 @@ stable hypervisors.
 | ARM| Cortex-A57  | #852523 | N/A 
|
 | ARM| Cortex-A57  | #832075 | ARM64_ERRATUM_832075
|
 | ARM| Cortex-A57  | #834220 | ARM64_ERRATUM_834220
|
+| ARM| MMU-500 | #842869 | N/A 
|
diff --git a/xen/drivers/passthrough/arm/smmu.c 
b/xen/drivers/passthrough/arm/smmu.c
index b510399..9612c0f 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -898,8 +898,7 @@ static void arm_smmu_tlb_inv_context(struct arm_smmu_domain 
*smmu_domain)
 
 static irqreturn_t arm_smmu_context_fault(int irq, void *dev)
 {
-   int flags, ret;
-   u32 fsr, far, fsynr, resume;
+   u32 fsr, far, fsynr;
unsigned long iova;
struct iommu_domain *domain = dev;
struct arm_smmu_domain *smmu_domain = domain->priv;
@@ -913,13 +912,7 @@ static irqreturn_t arm_smmu_context_fault(int irq, void 
*dev)
if (!(fsr & FSR_FAULT))
return IRQ_NONE;
 
-   if (fsr & FSR_IGN)
-   dev_err_ratelimited(smmu->dev,
-   "Unexpected context fault (fsr 0x%x)\n",
-   fsr);
-
fsynr = readl_relaxed(cb_base + ARM_SMMU_CB_FSYNR0);
-   flags = fsynr & FSYNR0_WNR ? IOMMU_FAULT_WRITE : IOMMU_FAULT_READ;
 
far = readl_relaxed(cb_base + ARM_SMMU_CB_FAR_LO);
iova = far;
@@ -928,25 +921,12 @@ static irqreturn_t arm_smmu_context_fault(int irq, void 
*dev)
iova |= ((unsigned long)far << 32);
 #endif
 
-   if (!report_iommu_fault(domain, smmu->dev, iova, flags)) {
-   ret = IRQ_HANDLED;
-   resume = RESUME_RETRY;
-   } else {
-   dev_err_ratelimited(smmu->dev,
-   "Unhandled context fault: iova=0x%08lx, fsynr=0x%x, 
cb=%d\n",
-   iova, fsynr, cfg->cbndx);
-   ret = IRQ_NONE;
-   resume = RESUME_TERMINATE;
-   }
-
-   /* Clear the faulting FSR */
+   dev_err_ratelimited(smmu->dev,
+   "Unhandled context fault: fsr=0x%x, iova=0x%08lx, fsynr=0x%x, cb=%d\n",
+   fsr, iova, fsynr, cfg->cbndx);
+ 
writel(fsr, cb_base + ARM_SMMU_CB_FSR);
-
-   /* Retry or terminate any stalled transactions */
-   if (fsr & FSR_SS)
-   writel_relaxed(resume, cb_base + ARM_SMMU_CB_RESUME);
-
-   return ret;
+   return IRQ_HANDLED;
 }
 
 static irqreturn_t arm_smmu_global_fault(int irq, void *dev)
@@ -1180,8 +1160,12 @@ static void arm_smmu_init_context_bank(struct 
arm_smmu_domain *smmu_domain)
writel_relaxed(reg, cb_base + ARM_SMMU_CB_S1_MAIR0);
}
 
-   /* SCTLR */
-   reg = SCTLR_CFCFG | SCTLR_CFIE | SCTLR_CFRE | SCTLR_M | SCTLR_EAE_SBOP;
+   /*
+* SCTLR
+*
+* Do not set SCTLR_CFCFG, because of Erratum #842869
+*/
+   reg = SCTLR_CFIE | SCTLR_CFRE | SCTLR_M | SCTLR_EAE_SBOP;
if (stage1)
reg |= SCTLR_S1_ASIDPNE;
 #ifdef __BIG_ENDIAN
-- 
1.9.1


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

Re: [Xen-devel] [PATCH] arm, smmu: backport "Disable stalling faults for all endpoints"

[Stefano Stabellini]

On Fri, 26 Oct 2018, Julien Grall wrote:
> Hi Stefano,
> 
> On 10/15/18 12:03 AM, Stefano Stabellini wrote:
> > Backport commit 3714ce1d6655098ee69ede632883e5874d67e4ab
> > "iommu/arm-smmu: Disable stalling faults for all endpoints" from the
> > Linux kernel.
> > 
> > Original commit message:
> > 
> >Enabling stalling faults can result in hardware deadlock on poorly
> >designed systems, particularly those with a PCI root complex upstream of
> >the SMMU.
> > 
> >Although it's not really Linux's job to save hardware integrators from
> >their own misfortune, it *is* our job to stop userspace (e.g. VFIO
> >clients) from hosing the system for everybody else, even if they might
> >already be required to have elevated privileges.
> > 
> >Given that the fault handling code currently executes entirely in IRQ
> >context, there is nothing that can sensibly be done to recover from
> >things like page faults anyway, so let's rip this code out for now and
> >avoid the potential for deadlock.
> > 
> >Cc: 
> >Fixes: 48ec83bcbcf5 ("iommu/arm-smmu: Add initial driver support for ARM
> > SMMUv3 devices")
> >Reported-by: Matt Evans 
> >Signed-off-by: Will Deacon 
> > 
> > Signed-off-by: Stefano Stabellini 
> 
> This is actually an errata on some SMMUv2 implementation. Can you update
> docs/misc/arm/silicon-errata.txt accordingly?

OK


> > 
> > diff --git a/xen/drivers/passthrough/arm/smmu.c
> > b/xen/drivers/passthrough/arm/smmu.c
> > index b510399..8de5d16 100644
> > --- a/xen/drivers/passthrough/arm/smmu.c
> > +++ b/xen/drivers/passthrough/arm/smmu.c
> > @@ -898,8 +898,7 @@ static void arm_smmu_tlb_inv_context(struct
> > arm_smmu_domain *smmu_domain)
> > static irqreturn_t arm_smmu_context_fault(int irq, void *dev)
> >   {
> > -   int flags, ret;
> > -   u32 fsr, far, fsynr, resume;
> > +   u32 fsr, far, fsynr;
> > unsigned long iova;
> > struct iommu_domain *domain = dev;
> > struct arm_smmu_domain *smmu_domain = domain->priv;
> > @@ -913,13 +912,7 @@ static irqreturn_t arm_smmu_context_fault(int irq, void
> > *dev)
> > if (!(fsr & FSR_FAULT))
> > return IRQ_NONE;
> >   - if (fsr & FSR_IGN)
> > -   dev_err_ratelimited(smmu->dev,
> > -   "Unexpected context fault (fsr 0x%x)\n",
> > -   fsr);
> > -
> > fsynr = readl_relaxed(cb_base + ARM_SMMU_CB_FSYNR0);
> > -   flags = fsynr & FSYNR0_WNR ? IOMMU_FAULT_WRITE : IOMMU_FAULT_READ;
> > far = readl_relaxed(cb_base + ARM_SMMU_CB_FAR_LO);
> > iova = far;
> > @@ -928,25 +921,12 @@ static irqreturn_t arm_smmu_context_fault(int irq,
> > void *dev)
> > iova |= ((unsigned long)far << 32);
> >   #endif
> >   - if (!report_iommu_fault(domain, smmu->dev, iova, flags)) {
> > -   ret = IRQ_HANDLED;
> > -   resume = RESUME_RETRY;
> > -   } else {
> > -   dev_err_ratelimited(smmu->dev,
> > -   "Unhandled context fault: iova=0x%08lx, fsynr=0x%x,
> > cb=%d\n",
> > -   iova, fsynr, cfg->cbndx);
> > -   ret = IRQ_NONE;
> > -   resume = RESUME_TERMINATE;
> > -   }
> > -
> > -   /* Clear the faulting FSR */
> > +   dev_err_ratelimited(smmu->dev,
> > +   "Unhandled context fault: fsr=0x%x, iova=0x%08lx, fsynr=0x%x,
> > cb=%d\n",
> > +   fsr, iova, fsynr, cfg->cbndx);
> > +
> > writel(fsr, cb_base + ARM_SMMU_CB_FSR);
> > -
> > -   /* Retry or terminate any stalled transactions */
> > -   if (fsr & FSR_SS)
> > -   writel_relaxed(resume, cb_base + ARM_SMMU_CB_RESUME);
> > -
> > -   return ret;
> > +   return IRQ_HANDLED;
> >   }
> > static irqreturn_t arm_smmu_global_fault(int irq, void *dev)
> > @@ -1181,7 +1161,7 @@ static void arm_smmu_init_context_bank(struct
> > arm_smmu_domain *smmu_domain)
> > }
> > /* SCTLR */
> > -   reg = SCTLR_CFCFG | SCTLR_CFIE | SCTLR_CFRE | SCTLR_M |
> > SCTLR_EAE_SBOP;
> > +   reg = SCTLR_CFIE | SCTLR_CFRE | SCTLR_M | SCTLR_EAE_SBOP;
> 
> It would also document here SCTLR_CFIE is not set because of erratum #... This
> would avoid us to turn it on again by mistake.

OK


> > if (stage1)
> > reg |= SCTLR_S1_ASIDPNE;
> >   #ifdef __BIG_ENDIAN
> > 
> 
> -- 
> Julien Grall
> 

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

Re: [Xen-devel] [PATCH RESEND qemu-xen-traditional] xen/pt: allow QEMU to request MSI unmasking at bind time

[Paraschiv, Andra-Irina]

On Mon, Oct 29, 2018 at 04:58:22PM +0200, Pasi Kärkkäinen wrote:
> Hi,
>
> On Wed, Oct 24, 2018 at 04:20:35PM +0100, Ian Jackson wrote:
> > Andra Paraschiv writes ("[PATCH RESEND qemu-xen-traditional] xen/pt: allow 
> > QEMU to request MSI unmasking at bind time"):
> > > When a MSI interrupt is bound to a guest using
> > > xc_domain_update_msi_irq (XEN_DOMCTL_bind_pt_irq) the interrupt is
> > > left masked by default.
> >
> > Applied, and pushed the corresponding update to QEMU_TAG in
> > qemu-xen-unstable.
> >
> > Does this patch need to be backported to earlier Xen releases ?  It
> > wasn't clear to me whether there is new Xen code in this area without
> > which the problem (which the patch solves) does not arise; or whether,
> > conversely, simply running a new guest is sufficient.
> >
> 
> Good question. In the earlier thread about this patch it was mentioned
> the bug happens with latest stable version of Xen, which sounds like
> this patch should be backported to stable Xen versions. Is that correct?

Replied later than expected, but I'm back now.

Ian, Pasi,

Right. We have this mail thread where the issue was originally reported:
https://lists.xenproject.org/archives/html/xen-devel/2017-07/msg00915.html

And the follow-up with the patches for Xen and QEMU (not traditional):
https://lists.xenproject.org/archives/html/xen-devel/2018-05/msg01238.html

"Hm, I think I might have fixed this issue, see:

https://git.qemu.org/?p=qemu.git;a=commit;h=a8036336609d2e184fc3543a4c439c0ba7d7f3a2

And the Xen side:

http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=69d99d1b223fc5082400374698ddd7486e5ea953;

The Xen patch above is present in the tree from 4.10.0-rc1 tag forward.

Thanks for feedback. Anything I can help further, we can discuss about it.

Andra

> Thanks,
> 
> -- Pasi
>
> > Regards,
> > Ian.
> >

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



Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar 
Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in 
Romania. Registration number J22/2621/2005.


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

Re: [Xen-devel] [PATCH v5 23/25] xen/vpl011: buffer out chars when the backend is xen

[Stefano Stabellini]

On Wed, 24 Oct 2018, Oleksandr Andrushchenko wrote:
> On 10/23/2018 05:03 AM, Stefano Stabellini wrote:
> > To avoid mixing the output of different domains on the console, buffer
> > the output chars and print line by line. Unless the domain has input
> > from the serial, in which case we want to print char by char for a
> > smooth user experience.
> > 
> > The size of SBSA_UART_OUT_BUF_SIZE is arbitrary, choose the same size
> > as VUART_BUT_SIZE used in vuart.c.
> s/VUART_BUT_SIZE/VUART_BUF_SIZE

Ops, I'll fix


> > Export a function named console_input_domain() to allow others to know
> > which domains has input at a given time.
> > 
> > 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: konrad.w...@oracle.com
> > CC: t...@xen.org
> > CC: wei.l...@citrix.com
> > ---
> > XXX: merge this patch with "xen/arm: Allow vpl011 to be used by DomU" on
> >   commit
> > 
> > Changes in v5:
> > - use rcu_lock in console_input_domain
> > - rcu_unlock at the end of vpl011_write_data_xen
> > - add a comment on top of console_input_domain as a reminder that the
> >caller needs to rcu_unlock
> > 
> > Changes in v4:
> > - make SBSA_UART_OUT_BUF_SIZE the same size of VUART_BUT_SIZE
> > - rearrange the code to be clearer input and != input cases
> > - code style
> > - add \n when printing the out buffer because is full
> > - don't print prefix for input domain
> > ---
> >   xen/arch/arm/vpl011.c| 36 +---
> >   xen/drivers/char/console.c   |  8 
> >   xen/include/asm-arm/vpl011.h |  4 
> >   xen/include/xen/console.h|  2 ++
> >   4 files changed, 47 insertions(+), 3 deletions(-)
> > 
> > diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
> > index 131507e..f7db18b 100644
> > --- a/xen/arch/arm/vpl011.c
> > +++ b/xen/arch/arm/vpl011.c
> > @@ -28,6 +28,7 @@
> >   #include 
> >   #include 
> >   #include 
> > +#include 
> >   #include 
> >   #include 
> >   #include 
> > @@ -85,18 +86,47 @@ static void vpl011_write_data_xen(struct domain *d,
> > uint8_t data)
> >   {
> >   unsigned long flags;
> >   struct vpl011 *vpl011 = >arch.vpl011;
> > +struct vpl011_xen_backend *intf = vpl011->backend.xen;
> > +struct domain *input = console_input_domain();
> > VPL011_LOCK(d, flags);
> >   -printk("%c", data);
> > -if (data == '\n')
> > -printk("DOM%u: ", d->domain_id);
> > +intf->out[intf->out_prod++] = data;
> > +if ( d == input )
> > +{
> > +if ( intf->out_prod == 1 )
> > +{
> > +printk("%c", data);
> > +intf->out_prod = 0;
> > +}
> > +else
> > +{
> > +if ( data != '\n' )
> > +intf->out[intf->out_prod++] = '\n';
> > +intf->out[intf->out_prod++] = '\0';
> > +printk("%s", intf->out);
> > +intf->out_prod = 0;
> > +}
> > +}
> > +else
> > +{
> > +if ( intf->out_prod == SBSA_UART_OUT_BUF_SIZE - 2 ||
> > + data == '\n' )
> > +{
> > +if ( data != '\n' )
> > +intf->out[intf->out_prod++] = '\n';
> > +intf->out[intf->out_prod++] = '\0';
> > +printk("DOM%u: %s", d->domain_id, intf->out);
> > +intf->out_prod = 0;
> > +}
> > +}
> > vpl011->uartris |= TXI;
> >   vpl011->uartfr &= ~TXFE;
> >   vpl011_update_interrupt_status(d);
> > VPL011_UNLOCK(d, flags);
> > +rcu_unlock_domain(input);
> input can be NULL. Although it won't hurt with the existing
> code base things could change any time soon...

No, you are right, I'll add an explicit check for it at the beginning of
the function.


> >   }
> > /*
> > diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> > index 990c51c..eb1cc1b 100644
> > --- a/xen/drivers/char/console.c
> > +++ b/xen/drivers/char/console.c
> > @@ -406,6 +406,14 @@ static void dump_console_ring_key(unsigned char key)
> >*/
> >   static unsigned int __read_mostly console_rx = 0;
> >   +/* Make sure to rcu_unlock_domain after use */
> > +struct domain *console_input_domain(void)
> > +{
> > +if ( console_rx == 0 )
> > +return NULL;
> > +return rcu_lock_domain_by_id(console_rx - 1);
> > +}
> > +
> >   static void switch_serial_input(void)
> >   {
> >   if ( console_rx++ == max_init_domid + 1 )
> > diff --git a/xen/include/asm-arm/vpl011.h b/xen/include/asm-arm/vpl011.h
> > index 5eb6d25..ab6fd79 100644
> > --- a/xen/include/asm-arm/vpl011.h
> > +++ b/xen/include/asm-arm/vpl011.h
> > @@ -30,9 +30,13 @@
> >   #define VPL011_UNLOCK(d,flags)
> > spin_unlock_irqrestore(&(d)->arch.vpl011.lock, flags)
> > #define SBSA_UART_FIFO_SIZE 32
> > +/* Same size as VUART_BUT_SIZE, used in vuart.c */
> > +#define SBSA_UART_OUT_BUF_SIZE 128
> >   struct vpl011_xen_backend {
> >   

Re: [Xen-devel] [PATCH v5 22/25] xen/arm: Allow vpl011 to be used by DomU

[Stefano Stabellini]

On Wed, 24 Oct 2018, Oleksandr Tyshchenko wrote:
> Hi, Stefano
> 
> On Tue, Oct 23, 2018 at 5:04 AM Stefano Stabellini
>  wrote:
> >
> > Make vpl011 being able to be used without a userspace component in Dom0.
> > In that case, output is printed to the Xen serial and input is received
> > from the Xen serial one character at a time.
> >
> > Call domain_vpl011_init during construct_domU if vpl011 is enabled.
> >
> > Introduce a new ring struct with only the ring array to avoid a waste of
> > memory. Introduce separate read_data and write_data functions for
> > initial domains: vpl011_write_data_xen is very simple and just writes
> > to the console, while vpl011_read_data_xen is a duplicate of
> > vpl011_read_data. Although textually almost identical, we are forced to
> > duplicate the functions because the struct layout is different.
> >
> > Output characters are printed one by one, potentially leading to
> > intermixed output of different domains on the console. A follow-up patch
> > will solve the issue by introducing buffering.
> >
> > Signed-off-by: Stefano Stabellini 
> > Acked-by: Julien Grall 
> > ---
> > Changes in v5:
> > - renable call to vpl011_rx_char_xen from console.c
> >
> > Changes in v4:
> > - code style
> >
> > Changes in v3:
> > - add in-code comments
> > - improve existing comments
> > - remove ifdef around domain_vpl011_init in construct_domU
> > - add ASSERT
> > - use SBSA_UART_FIFO_SIZE for in buffer size
> > - rename ring_enable to backend_in_domain
> > - rename struct xencons_in to struct vpl011_xen_backend
> > - rename inring field to xen
> > - rename helper functions accordingly
> > - remove unnecessary stub implementation of vpl011_rx_char
> > - move vpl011_rx_char_xen within the file to avoid the need of a forward
> >   declaration of vpl011_data_avail
> > - fix small bug in vpl011_rx_char_xen: increment in_prod before using it
> >   to check xencons_queued.
> >
> > Changes in v2:
> > - only init if vpl011
> > - rename vpl011_read_char to vpl011_rx_char
> > - remove spurious change
> > - fix coding style
> > - use different ring struct
> > - move the write_data changes to their own function
> >   (vpl011_write_data_noring)
> > - duplicate vpl011_read_data
> > ---
> >  xen/arch/arm/domain_build.c  |   9 +-
> >  xen/arch/arm/vpl011.c| 200 
> > +--
> >  xen/drivers/char/console.c   |   2 +-
> >  xen/include/asm-arm/vpl011.h |   8 ++
> >  4 files changed, 193 insertions(+), 26 deletions(-)
> >
> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > index 6026b77..9ffd919 100644
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -2629,7 +2629,14 @@ static int __init construct_domU(struct domain *d,
> >  if ( rc < 0 )
> >  return rc;
> >
> > -return construct_domain(d, );
> > +rc = construct_domain(d, );
> > +if ( rc < 0 )
> > +return rc;
> > +
> > +if ( kinfo.vpl011 )
> > +rc = domain_vpl011_init(d, NULL);
> > +
> > +return rc;
> >  }
> >
> >  void __init create_domUs(void)
> > diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
> > index 68452a8..131507e 100644
> > --- a/xen/arch/arm/vpl011.c
> > +++ b/xen/arch/arm/vpl011.c
> > @@ -77,6 +77,91 @@ static void vpl011_update_interrupt_status(struct domain 
> > *d)
> >  #endif
> >  }
> >
> > +/*
> > + * vpl011_write_data_xen writes chars from the vpl011 out buffer to the
> > + * console. Only to be used when the backend is Xen.
> > + */
> > +static void vpl011_write_data_xen(struct domain *d, uint8_t data)
> > +{
> > +unsigned long flags;
> > +struct vpl011 *vpl011 = >arch.vpl011;
> > +
> > +VPL011_LOCK(d, flags);
> > +
> > +printk("%c", data);
> > +if (data == '\n')
> > +printk("DOM%u: ", d->domain_id);
> > +
> > +vpl011->uartris |= TXI;
> > +vpl011->uartfr &= ~TXFE;
> > +vpl011_update_interrupt_status(d);
> > +
> > +VPL011_UNLOCK(d, flags);
> > +}
> > +
> > +/*
> > + * vpl011_read_data_xen reads data when the backend is xen. Characters
> > + * are added to the vpl011 receive buffer by vpl011_rx_char_xen.
> > + */
> > +static uint8_t vpl011_read_data_xen(struct domain *d)
> > +{
> > +unsigned long flags;
> > +uint8_t data = 0;
> > +struct vpl011 *vpl011 = >arch.vpl011;
> > +struct vpl011_xen_backend *intf = vpl011->backend.xen;
> > +XENCONS_RING_IDX in_cons, in_prod;
> > +
> > +VPL011_LOCK(d, flags);
> > +
> > +in_cons = intf->in_cons;
> > +in_prod = intf->in_prod;
> > +
> > +smp_rmb();
> > +
> > +/*
> > + * It is expected that there will be data in the ring buffer when this
> > + * function is called since the guest is expected to read the data 
> > register
> > + * only if the TXFE flag is not set.
> > + * If the guest still does read when TXFE bit is set then 0 will be 
> > returned.
> > + */
> > +if ( xencons_queued(in_prod, in_cons, sizeof(intf->in)) > 0 )
> > +{
> 

Re: [Xen-devel] [PATCH v5 21/25] xen: support console_switching between Dom0 and DomUs on ARM

[Julien Grall]

On 10/29/18 8:00 PM, Stefano Stabellini wrote:

On Wed, 24 Oct 2018, Oleksandr Andrushchenko wrote:

On 10/23/2018 05:03 AM, Stefano Stabellini wrote:
+ * console_rx=0 => input to xen
+ * console_rx=1 => input to dom0
+ * console_rx=N => input to dom(N-1)
So, why do you only handle case 0/1?

+#if 0

Do you need this #if 0?


To make the series fully bisectable: the code below requires
functionalities introduced by later patches.


That's a hint to update the commit message ;).

Cheers,

--
Julien Grall

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

[Xen-devel] [linux-linus bisection] complete test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
testid xen-boot

Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  linux 
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
  Bug introduced:  69d5b97c597307773fe6c59775a5d5a88bb7e6b3
  Bug not present: 091a1eaa0e309b0e8dcbf3f2da12c7f3d03ed182
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/129145/


  (Revision log too long, omitted.)


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-linus/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm.xen-boot.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/linux-linus/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm.xen-boot
 --summary-out=tmp/129145.bisection-summary --basis-template=125898 
--blessings=real,real-bisect linux-linus 
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm xen-boot
Searching for failure / basis pass:
 129072 fail [host=huxelrebe0] / 128945 [host=baroque1] 128920 
[host=joubertin0] 128885 [host=fiano0] 128861 [host=albana0] 128835 
[host=pinot1] 128727 [host=huxelrebe1] 128663 [host=baroque0] 128599 
[host=elbling1] 128520 [host=debina0] 128493 [host=italia0] 128476 
[host=fiano1] 128461 [host=rimava1] 128438 ok.
Failure / basis pass flights: 129072 / 128438
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 69d5b97c597307773fe6c59775a5d5a88bb7e6b3 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149 
de5b678ca4dcdfa83e322491d478d66df56c1986 
92666fdd6e0afab989b2d89759d9b43f2c645ae7
Basis pass 091a1eaa0e309b0e8dcbf3f2da12c7f3d03ed182 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149 
de5b678ca4dcdfa83e322491d478d66df56c1986 
359970fd8b781fac2ddcbc84dd5b890075fa08ef
Generating revisions with ./adhoc-revtuple-generator  
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#091a1eaa0e309b0e8dcbf3f2da12c7f3d03ed182-69d5b97c597307773fe6c59775a5d5a88bb7e6b3
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/qemu-xen-traditional.git#9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149-9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149
 
git://xenbits.xen.org/qemu-xen.git#de5b678ca4dcdfa83e322491d478d66df56c1986-de5b678ca4dcdfa83e322491d478d66df56c1986
 
git://xenbits.xen.org/xen.git#359970fd8b781fac2ddcbc84dd5b890075fa08ef-92666fdd6e0afab989b2d89759d9b43f2c645ae7
From 
git://cache:9419/git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
   5bd4af34a09a..044ee8902861  master -> origin/master
adhoc-revtuple-generator: tree discontiguous: linux-2.6
Loaded 1002 nodes in revision graph
Searching for test results:
 128369 [host=albana0]
 128407 [host=fiano0]
 128438 pass 091a1eaa0e309b0e8dcbf3f2da12c7f3d03ed182 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149 
de5b678ca4dcdfa83e322491d478d66df56c1986 
359970fd8b781fac2ddcbc84dd5b890075fa08ef
 128476 [host=fiano1]
 128461 [host=rimava1]
 128493 [host=italia0]
 128520 [host=debina0]
 128599 [host=elbling1]
 128663 [host=baroque0]
 128727 [host=huxelrebe1]
 128861 [host=albana0]
 128835 [host=pinot1]
 128885 [host=fiano0]
 128920 [host=joubertin0]
 128945 [host=baroque1]
 128970 fail irrelevant
 129005 fail irrelevant
 129122 fail 69d5b97c597307773fe6c59775a5d5a88bb7e6b3 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149 
de5b678ca4dcdfa83e322491d478d66df56c1986 
92666fdd6e0afab989b2d89759d9b43f2c645ae7
 129072 fail 69d5b97c597307773fe6c59775a5d5a88bb7e6b3 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149 
de5b678ca4dcdfa83e322491d478d66df56c1986 
92666fdd6e0afab989b2d89759d9b43f2c645ae7
 129119 pass 091a1eaa0e309b0e8dcbf3f2da12c7f3d03ed182 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149 
de5b678ca4dcdfa83e322491d478d66df56c1986 
359970fd8b781fac2ddcbc84dd5b890075fa08ef
 129134 pass 091a1eaa0e309b0e8dcbf3f2da12c7f3d03ed182 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149 

[Xen-devel] [PATCH] xen-blkfront: fix kernel panic with negotiate_mq error path

[Manjunath Patil]

info->nr_rings isn't adjusted in case of ENOMEM error from
negotiate_mq(). This leads to kernel panic in error path.

Typical call stack involving panic -
 #8 page_fault at 8175936f
[exception RIP: blkif_free_ring+33]
RIP: a0149491  RSP: 8804f7673c08  RFLAGS: 00010292
 ...
 #9 blkif_free at a0149aaa [xen_blkfront]
 #10 talk_to_blkback at a014c8cd [xen_blkfront]
 #11 blkback_changed at a014ea8b [xen_blkfront]
 #12 xenbus_otherend_changed at 81424670
 #13 backend_changed at 81426dc3
 #14 xenwatch_thread at 81422f29
 #15 kthread at 810abe6a
 #16 ret_from_fork at 81754078

Though either of my changes avoid the panic, I included both the
changes. This issue got introduced with "7ed8ce1 xen-blkfront: move
negotiate_mq to cover all cases of new VBDs"

Signed-off-by: Manjunath Patil 
---
 drivers/block/xen-blkfront.c |7 +--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 429d201..dc8fe25 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -1350,8 +1350,10 @@ static void blkif_free(struct blkfront_info *info, int 
suspend)
if (info->rq)
blk_mq_stop_hw_queues(info->rq);
 
-   for (i = 0; i < info->nr_rings; i++)
-   blkif_free_ring(>rinfo[i]);
+   if (info->rinfo) {
+   for (i = 0; i < info->nr_rings; i++)
+   blkif_free_ring(>rinfo[i]);
+   }
 
kfree(info->rinfo);
info->rinfo = NULL;
@@ -1919,6 +1921,7 @@ static int negotiate_mq(struct blkfront_info *info)
  GFP_KERNEL);
if (!info->rinfo) {
xenbus_dev_fatal(info->xbdev, -ENOMEM, "allocating ring_info 
structure");
+   info->nr_rings = 0;
return -ENOMEM;
}
 
-- 
1.7.1


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

[Xen-devel] [PATCH 8/8] viridian: introduce struct viridian_page

[Paul Durrant]

The 'vp_assist' page is currently an example of a guest page which needs to
be kept mapped throughout the life-time of a guest, but there are other
such examples in the specifiction [1]. This patch therefore introduces a
generic 'viridian_page' type and converts the current vp_assist/apic_assist
related code to use it. Subsequent patches implementing other enlightments
can then also make use of it.

This patch also renames the 'vp_assist_pending' field in struct
hvm_viridian_vcpu_context to 'apic_assist_pending' to more accurately
reflect its meaning. The term 'vp_assist' applies to the whole page rather
than just the EOI-avoidance enlightenment. New versons of the specification
have defined data structures for other enlightenments within the same page.

No functional change.

[1] 
https://github.com/MicrosoftDocs/Virtualization-Documentation/raw/live/tlfs/Hypervisor%20Top%20Level%20Functional%20Specification%20v5.0C.pdf

Signed-off-by: Paul Durrant 
---
Cc: Ian Jackson 
Cc: Wei Liu 
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 tools/misc/xen-hvmctx.c|  4 +--
 xen/arch/x86/hvm/viridian/synic.c  | 47 --
 xen/include/asm-x86/hvm/viridian.h | 13 ++
 xen/include/public/arch-x86/hvm/save.h |  2 +-
 4 files changed, 33 insertions(+), 33 deletions(-)

diff --git a/tools/misc/xen-hvmctx.c b/tools/misc/xen-hvmctx.c
index 40e77851be..a4efadf307 100644
--- a/tools/misc/xen-hvmctx.c
+++ b/tools/misc/xen-hvmctx.c
@@ -370,9 +370,9 @@ static void dump_viridian_vcpu(void)
 {
 HVM_SAVE_TYPE(VIRIDIAN_VCPU) p;
 READ(p);
-printf("VIRIDIAN_VCPU: vp_assist_msr 0x%llx, vp_assist_pending %s\n",
+printf("VIRIDIAN_VCPU: vp_assist_msr 0x%llx, apic_assist_pending %s\n",
   (unsigned long long) p.vp_assist_msr,
-  p.vp_assist_pending ? "true" : "false");
+  p.apic_assist_pending ? "true" : "false");
 }
 
 static void dump_vmce_vcpu(void)
diff --git a/xen/arch/x86/hvm/viridian/synic.c 
b/xen/arch/x86/hvm/viridian/synic.c
index 735c4c897c..f9aa8fd898 100644
--- a/xen/arch/x86/hvm/viridian/synic.c
+++ b/xen/arch/x86/hvm/viridian/synic.c
@@ -36,14 +36,13 @@ static void dump_vp_assist(const struct vcpu *v)
v, (unsigned long)va->fields.pfn);
 }
 
-static void initialize_vp_assist(struct vcpu *v)
+static void initialize_guest_page(struct vcpu *v, struct viridian_page *vp)
 {
 struct domain *d = v->domain;
-unsigned long gmfn = v->arch.hvm.viridian.vp_assist.msr.fields.pfn;
+unsigned long gmfn = vp->msr.fields.pfn;
 struct page_info *page = get_page_from_gfn(d, gmfn, NULL, P2M_ALLOC);
-HV_VP_ASSIST_PAGE *ptr;
 
-ASSERT(!v->arch.hvm.viridian.vp_assist.ptr);
+ASSERT(!vp->ptr);
 
 if ( !page )
 goto fail;
@@ -54,16 +53,14 @@ static void initialize_vp_assist(struct vcpu *v)
 goto fail;
 }
 
-ptr = __map_domain_page_global(page);
-if ( !ptr )
+vp->ptr = __map_domain_page_global(page);
+if ( !vp->ptr )
 {
 put_page_and_type(page);
 goto fail;
 }
 
-clear_page(ptr);
-
-v->arch.hvm.viridian.vp_assist.ptr = ptr;
+clear_page(vp->ptr);
 return;
 
  fail:
@@ -71,19 +68,18 @@ static void initialize_vp_assist(struct vcpu *v)
  gmfn, mfn_x(page ? page_to_mfn(page) : INVALID_MFN));
 }
 
-static void teardown_vp_assist(struct vcpu *v)
+static void teardown_guest_page(struct viridian_page *vp)
 {
-HV_VP_ASSIST_PAGE *ptr = v->arch.hvm.viridian.vp_assist.ptr;
 struct page_info *page;
 
-if ( !ptr )
+if ( !vp->ptr )
 return;
 
-v->arch.hvm.viridian.vp_assist.ptr = NULL;
+page = mfn_to_page(domain_page_map_to_mfn(vp->ptr));
 
-page = mfn_to_page(domain_page_map_to_mfn(ptr));
+unmap_domain_page_global(vp->ptr);
+vp->ptr = NULL;
 
-unmap_domain_page_global(ptr);
 put_page_and_type(page);
 }
 
@@ -99,10 +95,10 @@ void viridian_apic_assist_set(struct vcpu *v)
  * wrong and the VM will most likely hang so force a crash now
  * to make the problem clear.
  */
-if ( v->arch.hvm.viridian.vp_assist.pending )
+if ( v->arch.hvm.viridian.apic_assist_pending )
 domain_crash(v->domain);
 
-v->arch.hvm.viridian.vp_assist.pending = true;
+v->arch.hvm.viridian.apic_assist_pending = true;
 ptr->ApicAssist.no_eoi = 1;
 }
 
@@ -113,11 +109,11 @@ bool viridian_apic_assist_completed(struct vcpu *v)
 if ( !ptr )
 return false;
 
-if ( v->arch.hvm.viridian.vp_assist.pending &&
+if ( v->arch.hvm.viridian.apic_assist_pending &&
  !ptr->ApicAssist.no_eoi )
 {
 /* An EOI has been avoided */
-v->arch.hvm.viridian.vp_assist.pending = false;
+v->arch.hvm.viridian.apic_assist_pending = false;
 return true;
 }
 
@@ -132,7 +128,7 @@ void viridian_apic_assist_clear(struct vcpu *v)
 return;
 
 ptr->ApicAssist.no_eoi = 0;
-v->arch.hvm.viridian.vp_assist.pending = false;
+

Re: [Xen-devel] [PATCH 2/2] iommu / p2m: add a page_order parameter to iommu_map/unmap_page()

[Paul Durrant]

Apologies. Ignore this as it is just a re-post of a stale patch.

  Paul

> -Original Message-
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: 29 October 2018 18:02
> To: xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; Jan Beulich
> ; Andrew Cooper ; Wei Liu
> ; George Dunlap ; Ian
> Jackson ; Julien Grall ;
> Konrad Rzeszutek Wilk ; Stefano Stabellini
> ; Tim (Xen.org) ; Jun Nakajima
> ; Kevin Tian 
> Subject: [PATCH 2/2] iommu / p2m: add a page_order parameter to
> iommu_map/unmap_page()
> 
> The P2M code currently contains many loops to deal with the fact that,
> while it may be require to handle page orders greater than 4k, the
> IOMMU map and unmap functions do not.
> This patch adds a page_order parameter to those functions and implements
> the necessary loops within. This allows the P2M code to be sunstantially
> simplified.
> 
> NOTE: This patch does not modify the underlying vendor IOMMU
>   implementations to deal with page orders of more than 4k.
> 
> Signed-off-by: Paul Durrant 
> ---
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> Cc: Wei Liu 
> Cc: George Dunlap 
> Cc: Ian Jackson 
> Cc: Julien Grall 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Stefano Stabellini 
> Cc: Tim Deegan 
> Cc: Jun Nakajima 
> Cc: Kevin Tian 
> ---
>  xen/arch/x86/mm.c   |  4 ++-
>  xen/arch/x86/mm/p2m-ept.c   | 30 ++---
>  xen/arch/x86/mm/p2m-pt.c| 47 ++-
>  xen/arch/x86/mm/p2m.c   | 49 
>  xen/arch/x86/x86_64/mm.c|  4 ++-
>  xen/common/grant_table.c|  7 ++--
>  xen/drivers/passthrough/iommu.c | 65 
> -
>  xen/drivers/passthrough/x86/iommu.c |  2 +-
>  xen/include/xen/iommu.h |  8 +++--
>  9 files changed, 80 insertions(+), 136 deletions(-)
> 
> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> index c53bc86a68..f0ae016e7a 100644
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -2794,9 +2794,11 @@ static int _get_page_type(struct page_info *page,
> unsigned long type,
>  mfn_t mfn = page_to_mfn(page);
> 
>  if ( (x & PGT_type_mask) == PGT_writable_page )
> -iommu_ret = iommu_unmap_page(d, _dfn(mfn_x(mfn)));
> +iommu_ret = iommu_unmap_page(d, _dfn(mfn_x(mfn)),
> + PAGE_ORDER_4K);
>  else if ( type == PGT_writable_page )
>  iommu_ret = iommu_map_page(d, _dfn(mfn_x(mfn)), mfn,
> +   PAGE_ORDER_4K,
> IOMMUF_readable |
> IOMMUF_writable);
>  }
> diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
> index 407e299e50..656c8dd3ac 100644
> --- a/xen/arch/x86/mm/p2m-ept.c
> +++ b/xen/arch/x86/mm/p2m-ept.c
> @@ -880,33 +880,9 @@ out:
>  if ( iommu_use_hap_pt(d) )
>  rc = iommu_pte_flush(d, gfn, _entry->epte, order,
> vtd_pte_present);
>  else if ( need_iommu_pt_sync(d) )
> -{
> -dfn_t dfn = _dfn(gfn);
> -
> -if ( iommu_flags )
> -for ( i = 0; i < (1 << order); i++ )
> -{
> -rc = iommu_map_page(d, dfn_add(dfn, i),
> -mfn_add(mfn, i), iommu_flags);
> -if ( unlikely(rc) )
> -{
> -while ( i-- )
> -/* If statement to satisfy __must_check. */
> -if ( iommu_unmap_page(p2m->domain,
> -  dfn_add(dfn, i)) )
> -continue;
> -
> -break;
> -}
> -}
> -else
> -for ( i = 0; i < (1 << order); i++ )
> -{
> -ret = iommu_unmap_page(d, dfn_add(dfn, i));
> -if ( !rc )
> -rc = ret;
> -}
> -}
> +rc = iommu_flags ?
> +iommu_map_page(d, _dfn(gfn), mfn, order, iommu_flags) :
> +iommu_unmap_page(d, _dfn(gfn), order);
>  }
> 
>  unmap_domain_page(table);
> diff --git a/xen/arch/x86/mm/p2m-pt.c b/xen/arch/x86/mm/p2m-pt.c
> index 55df18501e..b264a97bd8 100644
> --- a/xen/arch/x86/mm/p2m-pt.c
> +++ b/xen/arch/x86/mm/p2m-pt.c
> @@ -477,10 +477,11 @@ p2m_pt_set_entry(struct p2m_domain *p2m, gfn_t gfn_,
> mfn_t mfn,
>   unsigned int page_order, p2m_type_t p2mt, p2m_access_t
> p2ma,
>   int sve)
>  {
> +struct domain *d = p2m->domain;
>  /* XXX -- this might be able to be faster iff current->domain == d */
>  void *table;
>  unsigned long gfn = gfn_x(gfn_);
> -unsigned long i, gfn_remainder = gfn;
> +unsigned long gfn_remainder = gfn;
>   

Re: [Xen-devel] [PATCH 1/2] x86/mm/p2m: don't needlessly limit MMIO mapping order to 4k

[Paul Durrant]

Apologies. Ignore this as it is just a re-post of a stale patch.

  Paul

> -Original Message-
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: 29 October 2018 18:02
> To: xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; Jan Beulich
> ; Andrew Cooper ; Wei Liu
> 
> Subject: [PATCH 1/2] x86/mm/p2m: don't needlessly limit MMIO mapping order
> to 4k
> 
> The P2M common code currently restricts the MMIO mapping order of any
> domain with IOMMU mappings, but that is not using shared tables, to 4k.
> This has been shown to have a huge performance cost when passing through
> a PCI device with a very large BAR (e.g. NVIDIA P40), increasing the guest
> boot time from ~20s to several minutes when iommu=no-sharept is specified
> on the Xen command line.
> 
> The limitation was added by commit c3c756bd "x86/p2m: use large pages
> for MMIO mappings" however the underlying implementations of p2m-
> >set_entry
> for Intel and AMD are coded to cope with mapping orders higher than 4k,
> even though the IOMMU mapping function is itself currently limited to 4k,
> so there is no real need to limit the order passed into the method, other
> than to avoid a potential DoS caused by a long running hypercall.
> 
> In practice, mmio_order() already strictly disallows 1G mappings since the
> if clause in question starts with:
> 
> if ( 0 /*
> * Don't use 1Gb pages, to limit the iteration count in
> * set_typed_p2m_entry() when it needs to zap M2P entries
> * for a RAM range.
> */ &&
> 
> With this patch applied (and hence 2M mappings in use) the VM boot time is
> restored to something reasonable. Not as fast as without iommu=no-sharept,
> but within a few seconds of it.
> 
> NOTE: This patch takes the opportunity to shorten a couple of > 80
>   character lines in the code.
> 
> Signed-off-by: Paul Durrant 
> Acked-by: George Dunlap 
> ---
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> Cc: Wei Liu 
> 
> v2:
>  - Add an extra to the if clause disallowing 1G mappings to make sure
>they are not used if need_iommu_pt_sync() is true, even though the
>check is currently moot (see main comment).
> ---
>  xen/arch/x86/mm/p2m.c | 19 ++-
>  1 file changed, 10 insertions(+), 9 deletions(-)
> 
> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> index a00a3c1bff..f972b4819d 100644
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -2081,14 +2081,11 @@ static unsigned int mmio_order(const struct domain
> *d,
> unsigned long start_fn, unsigned long nr)
>  {
>  /*
> - * Note that the !iommu_use_hap_pt() here has three effects:
> - * - cover iommu_{,un}map_page() not having an "order" input yet,
> - * - exclude shadow mode (which doesn't support large MMIO mappings),
> - * - exclude PV guests, should execution reach this code for such.
> - * So be careful when altering this.
> + * PV guests or shadow-mode HVM guests must be restricted to 4k
> + * mappings.
>   */
> -if ( !iommu_use_hap_pt(d) ||
> - (start_fn & ((1UL << PAGE_ORDER_2M) - 1)) || !(nr >>
> PAGE_ORDER_2M) )
> +if ( !hap_enabled(d) || (start_fn & ((1UL << PAGE_ORDER_2M) - 1)) ||
> + !(nr >> PAGE_ORDER_2M) )
>  return PAGE_ORDER_4K;
> 
>  if ( 0 /*
> @@ -2096,8 +2093,12 @@ static unsigned int mmio_order(const struct domain
> *d,
>  * set_typed_p2m_entry() when it needs to zap M2P entries
>  * for a RAM range.
>  */ &&
> - !(start_fn & ((1UL << PAGE_ORDER_1G) - 1)) && (nr >>
> PAGE_ORDER_1G) &&
> - hap_has_1gb )
> + !(start_fn & ((1UL << PAGE_ORDER_1G) - 1)) &&
> + (nr >> PAGE_ORDER_1G) &&
> + hap_has_1gb &&
> + /* disable 1G mappings if we need to keep the IOMMU in sync */
> + !need_iommu_pt_sync(d)
> +)
>  return PAGE_ORDER_1G;
> 
>  if ( hap_has_2mb )
> --
> 2.11.0


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

[Xen-devel] [PATCH 0/8] viridian cleanup

[Paul Durrant]

I plan to add implementations for more viridian enlightenments in the near
future. This series is just some cleanup I've been doing in preparation.

Paul Durrant (8):
  viridian: move the code into its own sub-directory
  viridian: remove MSR perf counters
  viridian: remove comments referencing section number in the spec.
  viridian: remove duplicate union types
  viridian: separate interrupt related enlightenment implementations...
  viridian: separate time related enlightenment implementations...
  viridian: define type for the 'virtual VP assist page'
  viridian: introduce struct viridian_page

 tools/misc/xen-hvmctx.c|   4 +-
 xen/arch/x86/hvm/Makefile  |   2 +-
 xen/arch/x86/hvm/viridian/Makefile |   3 +
 xen/arch/x86/hvm/viridian/synic.c  | 233 ++
 xen/arch/x86/hvm/viridian/time.c   | 244 +++
 xen/arch/x86/hvm/{ => viridian}/viridian.c | 480 +++--
 xen/include/asm-x86/hvm/viridian.h | 144 ++---
 xen/include/asm-x86/perfc_defn.h   |  26 --
 xen/include/public/arch-x86/hvm/save.h |   2 +-
 9 files changed, 623 insertions(+), 515 deletions(-)
 create mode 100644 xen/arch/x86/hvm/viridian/Makefile
 create mode 100644 xen/arch/x86/hvm/viridian/synic.c
 create mode 100644 xen/arch/x86/hvm/viridian/time.c
 rename xen/arch/x86/hvm/{ => viridian}/viridian.c (54%)

-- 
2.11.0


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

[Xen-devel] [PATCH 2/2] iommu / p2m: add a page_order parameter to iommu_map/unmap_page()

[Paul Durrant]

The P2M code currently contains many loops to deal with the fact that,
while it may be require to handle page orders greater than 4k, the
IOMMU map and unmap functions do not.
This patch adds a page_order parameter to those functions and implements
the necessary loops within. This allows the P2M code to be sunstantially
simplified.

NOTE: This patch does not modify the underlying vendor IOMMU
  implementations to deal with page orders of more than 4k.

Signed-off-by: Paul Durrant 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Wei Liu 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Julien Grall 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Jun Nakajima 
Cc: Kevin Tian 
---
 xen/arch/x86/mm.c   |  4 ++-
 xen/arch/x86/mm/p2m-ept.c   | 30 ++---
 xen/arch/x86/mm/p2m-pt.c| 47 ++-
 xen/arch/x86/mm/p2m.c   | 49 
 xen/arch/x86/x86_64/mm.c|  4 ++-
 xen/common/grant_table.c|  7 ++--
 xen/drivers/passthrough/iommu.c | 65 -
 xen/drivers/passthrough/x86/iommu.c |  2 +-
 xen/include/xen/iommu.h |  8 +++--
 9 files changed, 80 insertions(+), 136 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index c53bc86a68..f0ae016e7a 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -2794,9 +2794,11 @@ static int _get_page_type(struct page_info *page, 
unsigned long type,
 mfn_t mfn = page_to_mfn(page);
 
 if ( (x & PGT_type_mask) == PGT_writable_page )
-iommu_ret = iommu_unmap_page(d, _dfn(mfn_x(mfn)));
+iommu_ret = iommu_unmap_page(d, _dfn(mfn_x(mfn)),
+ PAGE_ORDER_4K);
 else if ( type == PGT_writable_page )
 iommu_ret = iommu_map_page(d, _dfn(mfn_x(mfn)), mfn,
+   PAGE_ORDER_4K,
IOMMUF_readable |
IOMMUF_writable);
 }
diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index 407e299e50..656c8dd3ac 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -880,33 +880,9 @@ out:
 if ( iommu_use_hap_pt(d) )
 rc = iommu_pte_flush(d, gfn, _entry->epte, order, 
vtd_pte_present);
 else if ( need_iommu_pt_sync(d) )
-{
-dfn_t dfn = _dfn(gfn);
-
-if ( iommu_flags )
-for ( i = 0; i < (1 << order); i++ )
-{
-rc = iommu_map_page(d, dfn_add(dfn, i),
-mfn_add(mfn, i), iommu_flags);
-if ( unlikely(rc) )
-{
-while ( i-- )
-/* If statement to satisfy __must_check. */
-if ( iommu_unmap_page(p2m->domain,
-  dfn_add(dfn, i)) )
-continue;
-
-break;
-}
-}
-else
-for ( i = 0; i < (1 << order); i++ )
-{
-ret = iommu_unmap_page(d, dfn_add(dfn, i));
-if ( !rc )
-rc = ret;
-}
-}
+rc = iommu_flags ?
+iommu_map_page(d, _dfn(gfn), mfn, order, iommu_flags) :
+iommu_unmap_page(d, _dfn(gfn), order);
 }
 
 unmap_domain_page(table);
diff --git a/xen/arch/x86/mm/p2m-pt.c b/xen/arch/x86/mm/p2m-pt.c
index 55df18501e..b264a97bd8 100644
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -477,10 +477,11 @@ p2m_pt_set_entry(struct p2m_domain *p2m, gfn_t gfn_, 
mfn_t mfn,
  unsigned int page_order, p2m_type_t p2mt, p2m_access_t p2ma,
  int sve)
 {
+struct domain *d = p2m->domain;
 /* XXX -- this might be able to be faster iff current->domain == d */
 void *table;
 unsigned long gfn = gfn_x(gfn_);
-unsigned long i, gfn_remainder = gfn;
+unsigned long gfn_remainder = gfn;
 l1_pgentry_t *p2m_entry, entry_content;
 /* Intermediate table to free if we're replacing it with a superpage. */
 l1_pgentry_t intermediate_entry = l1e_empty();
@@ -515,7 +516,7 @@ p2m_pt_set_entry(struct p2m_domain *p2m, gfn_t gfn_, mfn_t 
mfn,
 t.gfn = gfn;
 t.mfn = mfn_x(mfn);
 t.p2mt = p2mt;
-t.d = p2m->domain->domain_id;
+t.d = d->domain_id;
 t.order = page_order;
 
 __trace_var(TRC_MEM_SET_P2M_ENTRY, 0, sizeof(t), );
@@ -683,41 +684,13 @@ p2m_pt_set_entry(struct p2m_domain *p2m, gfn_t gfn_, 
mfn_t mfn,
 {
 ASSERT(rc == 0);
 
-if ( iommu_use_hap_pt(p2m->domain) )
-{
-if ( iommu_old_flags )
-

[Xen-devel] [PATCH 5/8] viridian: separate interrupt related enlightenment implementations...

[Paul Durrant]

...into new 'synic' module.

The SynIC (synthetic interrupt controller) is specified [1] to be a super-
set of a virtualized LAPIC, and its definition encompasses all
enlightenments related to virtual interrupt control.

This patch reduces the size of the main viridian source module by giving
these enlightenments their own module. This is done in anticipation of
implementation of more such enlightenments and a desire not to further
lengthen then main source module when this work is done.

Whilst moving the code:

- Fix various style issues.
- Move the MSR definitions into the header (since they are now needed in
  more than one source module).

[1] 
https://github.com/MicrosoftDocs/Virtualization-Documentation/raw/live/tlfs/Hypervisor%20Top%20Level%20Functional%20Specification%20v5.0C.pdf

Signed-off-by: Paul Durrant 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Wei Liu 
---
 xen/arch/x86/hvm/viridian/Makefile   |   1 +
 xen/arch/x86/hvm/viridian/synic.c| 224 ++
 xen/arch/x86/hvm/viridian/viridian.c | 229 ++-
 xen/include/asm-x86/hvm/viridian.h   |  76 
 4 files changed, 311 insertions(+), 219 deletions(-)
 create mode 100644 xen/arch/x86/hvm/viridian/synic.c

diff --git a/xen/arch/x86/hvm/viridian/Makefile 
b/xen/arch/x86/hvm/viridian/Makefile
index 09fd0a5f3c..fca8e16e20 100644
--- a/xen/arch/x86/hvm/viridian/Makefile
+++ b/xen/arch/x86/hvm/viridian/Makefile
@@ -1 +1,2 @@
+obj-y += synic.o
 obj-y += viridian.o
diff --git a/xen/arch/x86/hvm/viridian/synic.c 
b/xen/arch/x86/hvm/viridian/synic.c
new file mode 100644
index 00..3f043f34ee
--- /dev/null
+++ b/xen/arch/x86/hvm/viridian/synic.c
@@ -0,0 +1,224 @@
+/***
+ * synic.c
+ *
+ * An implementation of some interrupt related Viridian enlightenments.
+ * See Microsoft's Hypervisor Top Level Functional Specification.
+ * for more information.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static void dump_vp_assist(const struct vcpu *v)
+{
+const union viridian_page_msr *va = >arch.hvm.viridian.vp_assist.msr;
+
+if ( !va->fields.enabled )
+return;
+
+printk(XENLOG_G_INFO "%pv: VIRIDIAN VP_ASSIST_PAGE: pfn: %lx\n",
+   v, (unsigned long)va->fields.pfn);
+}
+
+static void initialize_vp_assist(struct vcpu *v)
+{
+struct domain *d = v->domain;
+unsigned long gmfn = v->arch.hvm.viridian.vp_assist.msr.fields.pfn;
+struct page_info *page = get_page_from_gfn(d, gmfn, NULL, P2M_ALLOC);
+void *va;
+
+ASSERT(!v->arch.hvm.viridian.vp_assist.va);
+
+if ( !page )
+goto fail;
+
+if ( !get_page_type(page, PGT_writable_page) )
+{
+put_page(page);
+goto fail;
+}
+
+va = __map_domain_page_global(page);
+if ( !va )
+{
+put_page_and_type(page);
+goto fail;
+}
+
+clear_page(va);
+
+v->arch.hvm.viridian.vp_assist.va = va;
+return;
+
+ fail:
+gdprintk(XENLOG_WARNING, "Bad GMFN %#"PRI_gfn" (MFN %#"PRI_mfn")\n",
+ gmfn, mfn_x(page ? page_to_mfn(page) : INVALID_MFN));
+}
+
+static void teardown_vp_assist(struct vcpu *v)
+{
+void *va = v->arch.hvm.viridian.vp_assist.va;
+struct page_info *page;
+
+if ( !va )
+return;
+
+v->arch.hvm.viridian.vp_assist.va = NULL;
+
+page = mfn_to_page(domain_page_map_to_mfn(va));
+
+unmap_domain_page_global(va);
+put_page_and_type(page);
+}
+
+void viridian_apic_assist_set(struct vcpu *v)
+{
+uint32_t *va = v->arch.hvm.viridian.vp_assist.va;
+
+if ( !va )
+return;
+
+/*
+ * If there is already an assist pending then something has gone
+ * wrong and the VM will most likely hang so force a crash now
+ * to make the problem clear.
+ */
+if ( v->arch.hvm.viridian.vp_assist.pending )
+domain_crash(v->domain);
+
+v->arch.hvm.viridian.vp_assist.pending = true;
+*va |= 1u;
+}
+
+bool viridian_apic_assist_completed(struct vcpu *v)
+{
+uint32_t *va = v->arch.hvm.viridian.vp_assist.va;
+
+if ( !va )
+return false;
+
+if ( v->arch.hvm.viridian.vp_assist.pending &&
+ !(*va & 1u) )
+{
+/* An EOI has been avoided */
+v->arch.hvm.viridian.vp_assist.pending = false;
+return true;
+}
+
+return false;
+}
+
+void viridian_apic_assist_clear(struct vcpu *v)
+{
+uint32_t *va = v->arch.hvm.viridian.vp_assist.va;
+
+if ( !va )
+return;
+
+*va &= ~1u;
+v->arch.hvm.viridian.vp_assist.pending = false;
+}
+
+int viridian_synic_wrmsr(struct vcpu *v, uint32_t idx, uint64_t val)
+{
+switch ( idx )
+{
+case HV_X64_MSR_EOI:
+vlapic_EOI_set(vcpu_vlapic(v));
+break;
+
+case HV_X64_MSR_ICR: {
+u32 eax = (u32)val, edx = (u32)(val >> 32);
+struct vlapic *vlapic = vcpu_vlapic(v);
+eax &= ~(1 << 12);
+edx &= 0xff00;
+

[Xen-devel] [PATCH 1/8] viridian: move the code into its own sub-directory

[Paul Durrant]

Subsequent patches will introduce support for more viridian enlightenments
which will make a single source module quite lengthy.

This patch therefore creates a new arch/x86/hvm/viridian sub-directory and
moves viridian.c into that.

The patch also fixes some bad whitespace whilst moving the code.

Signed-off-by: Paul Durrant 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Wei Liu 
---
 xen/arch/x86/hvm/Makefile  | 2 +-
 xen/arch/x86/hvm/viridian/Makefile | 1 +
 xen/arch/x86/hvm/{ => viridian}/viridian.c | 4 ++--
 3 files changed, 4 insertions(+), 3 deletions(-)
 create mode 100644 xen/arch/x86/hvm/viridian/Makefile
 rename xen/arch/x86/hvm/{ => viridian}/viridian.c (99%)

diff --git a/xen/arch/x86/hvm/Makefile b/xen/arch/x86/hvm/Makefile
index 5e04bc1429..86b106f8e7 100644
--- a/xen/arch/x86/hvm/Makefile
+++ b/xen/arch/x86/hvm/Makefile
@@ -1,5 +1,6 @@
 subdir-y += svm
 subdir-y += vmx
+subdir-y += viridian
 
 obj-y += asid.o
 obj-y += dm.o
@@ -23,7 +24,6 @@ obj-y += rtc.o
 obj-y += save.o
 obj-y += stdvga.o
 obj-y += vioapic.o
-obj-y += viridian.o
 obj-y += vlapic.o
 obj-y += vm_event.o
 obj-y += vmsi.o
diff --git a/xen/arch/x86/hvm/viridian/Makefile 
b/xen/arch/x86/hvm/viridian/Makefile
new file mode 100644
index 00..09fd0a5f3c
--- /dev/null
+++ b/xen/arch/x86/hvm/viridian/Makefile
@@ -0,0 +1 @@
+obj-y += viridian.o
diff --git a/xen/arch/x86/hvm/viridian.c b/xen/arch/x86/hvm/viridian/viridian.c
similarity index 99%
rename from xen/arch/x86/hvm/viridian.c
rename to xen/arch/x86/hvm/viridian/viridian.c
index f42b1f063e..3e9beda831 100644
--- a/xen/arch/x86/hvm/viridian.c
+++ b/xen/arch/x86/hvm/viridian/viridian.c
@@ -4,7 +4,7 @@
  * An implementation of some Viridian enlightenments. See Microsoft's
  * Hypervisor Top Level Functional Specification (v5.0a) at:
  *
- * 
https://github.com/Microsoft/Virtualization-Documentation/raw/master/tlfs/Hypervisor%20Top%20Level%20Functional%20Specification%20v5.0.pdf
 
+ * 
https://github.com/Microsoft/Virtualization-Documentation/raw/master/tlfs/Hypervisor%20Top%20Level%20Functional%20Specification%20v5.0.pdf
  *
  * for more information.
  */
@@ -334,7 +334,7 @@ static void dump_reference_tsc(const struct domain *d)
 const union viridian_reference_tsc *rt;
 
 rt = >arch.hvm.viridian.reference_tsc;
-
+
 printk(XENLOG_G_INFO "d%d: VIRIDIAN REFERENCE_TSC: enabled: %x pfn: %lx\n",
d->domain_id,
rt->fields.enabled, (unsigned long)rt->fields.pfn);
-- 
2.11.0


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

[Xen-devel] [PATCH 4/8] viridian: remove duplicate union types

[Paul Durrant]

The 'viridian_vp_assist', 'viridian_hypercall_gpa' and
'viridian_reference_tsc' union types are identical in layout. The layout
is also common throughout the specification [1].

This patch declares a common 'viridian_page_msr' type and converts the rest
of the code to use that type for both the hypercall and VP assist pages.

Also, rename 'viridian_guest_os_id' to 'viridian_guest_os_id_msr' since it
also is a union representing an MSR value.

No functional change.

[1] 
https://github.com/MicrosoftDocs/Virtualization-Documentation/raw/live/tlfs/Hypervisor%20Top%20Level%20Functional%20Specification%20v5.0C.pdf

Signed-off-by: Paul Durrant 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Wei Liu 
---
 xen/arch/x86/hvm/viridian/viridian.c |  8 
 xen/include/asm-x86/hvm/viridian.h   | 36 
 2 files changed, 12 insertions(+), 32 deletions(-)

diff --git a/xen/arch/x86/hvm/viridian/viridian.c 
b/xen/arch/x86/hvm/viridian/viridian.c
index db166d41c5..55b9071c32 100644
--- a/xen/arch/x86/hvm/viridian/viridian.c
+++ b/xen/arch/x86/hvm/viridian/viridian.c
@@ -288,7 +288,7 @@ void cpuid_viridian_leaves(const struct vcpu *v, uint32_t 
leaf,
 
 static void dump_guest_os_id(const struct domain *d)
 {
-const union viridian_guest_os_id *goi;
+const union viridian_guest_os_id_msr *goi;
 
 goi = >arch.hvm.viridian.guest_os_id;
 
@@ -302,7 +302,7 @@ static void dump_guest_os_id(const struct domain *d)
 
 static void dump_hypercall(const struct domain *d)
 {
-const union viridian_hypercall_gpa *hg;
+const union viridian_page_msr *hg;
 
 hg = >arch.hvm.viridian.hypercall_gpa;
 
@@ -313,7 +313,7 @@ static void dump_hypercall(const struct domain *d)
 
 static void dump_vp_assist(const struct vcpu *v)
 {
-const union viridian_vp_assist *va;
+const union viridian_page_msr *va;
 
 va = >arch.hvm.viridian.vp_assist.msr;
 
@@ -323,7 +323,7 @@ static void dump_vp_assist(const struct vcpu *v)
 
 static void dump_reference_tsc(const struct domain *d)
 {
-const union viridian_reference_tsc *rt;
+const union viridian_page_msr *rt;
 
 rt = >arch.hvm.viridian.reference_tsc;
 
diff --git a/xen/include/asm-x86/hvm/viridian.h 
b/xen/include/asm-x86/hvm/viridian.h
index f6008f9bdb..359fdf5a83 100644
--- a/xen/include/asm-x86/hvm/viridian.h
+++ b/xen/include/asm-x86/hvm/viridian.h
@@ -9,8 +9,9 @@
 #ifndef __ASM_X86_HVM_VIRIDIAN_H__
 #define __ASM_X86_HVM_VIRIDIAN_H__
 
-union viridian_vp_assist
-{   uint64_t raw;
+union viridian_page_msr
+{
+uint64_t raw;
 struct
 {
 uint64_t enabled:1;
@@ -22,14 +23,14 @@ union viridian_vp_assist
 struct viridian_vcpu
 {
 struct {
-union viridian_vp_assist msr;
+union viridian_page_msr msr;
 void *va;
 bool pending;
 } vp_assist;
 uint64_t crash_param[5];
 };
 
-union viridian_guest_os_id
+union viridian_guest_os_id_msr
 {
 uint64_t raw;
 struct
@@ -43,16 +44,6 @@ union viridian_guest_os_id
 } fields;
 };
 
-union viridian_hypercall_gpa
-{   uint64_t raw;
-struct
-{
-uint64_t enabled:1;
-uint64_t reserved_preserved:11;
-uint64_t pfn:48;
-} fields;
-};
-
 struct viridian_time_ref_count
 {
 unsigned long flags;
@@ -66,17 +57,6 @@ struct viridian_time_ref_count
 int64_t off;
 };
 
-union viridian_reference_tsc
-{
-uint64_t raw;
-struct
-{
-uint64_t enabled:1;
-uint64_t reserved_preserved:11;
-uint64_t pfn:48;
-} fields;
-};
-
 typedef struct _HV_REFERENCE_TSC_PAGE
 {
 uint32_t TscSequence;
@@ -88,10 +68,10 @@ typedef struct _HV_REFERENCE_TSC_PAGE
 
 struct viridian_domain
 {
-union viridian_guest_os_id guest_os_id;
-union viridian_hypercall_gpa hypercall_gpa;
+union viridian_guest_os_id_msr guest_os_id;
+union viridian_page_msr hypercall_gpa;
 struct viridian_time_ref_count time_ref_count;
-union viridian_reference_tsc reference_tsc;
+union viridian_page_msr reference_tsc;
 };
 
 void cpuid_viridian_leaves(const struct vcpu *v, uint32_t leaf,
-- 
2.11.0


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

[Xen-devel] [PATCH 3/8] viridian: remove comments referencing section number in the spec.

[Paul Durrant]

Microsoft has a habit of re-numbering sections in the spec. so avoid
referring to section numbers in comments. Also remove the URL for the
spec. from the boilerplate... Again, Microsoft has a habit of changing
these too.

This patch also cleans up some > 80 character lines.

Purely cosmetic. No functional change.

Signed-off-by: Paul Durrant 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Wei Liu 
---
 xen/arch/x86/hvm/viridian/viridian.c | 82 
 xen/include/asm-x86/hvm/viridian.h   |  4 --
 2 files changed, 36 insertions(+), 50 deletions(-)

diff --git a/xen/arch/x86/hvm/viridian/viridian.c 
b/xen/arch/x86/hvm/viridian/viridian.c
index c5722d6992..db166d41c5 100644
--- a/xen/arch/x86/hvm/viridian/viridian.c
+++ b/xen/arch/x86/hvm/viridian/viridian.c
@@ -1,12 +1,8 @@
-/**
+/**
  * viridian.c
  *
  * An implementation of some Viridian enlightenments. See Microsoft's
- * Hypervisor Top Level Functional Specification (v5.0a) at:
- *
- * 
https://github.com/Microsoft/Virtualization-Documentation/raw/master/tlfs/Hypervisor%20Top%20Level%20Functional%20Specification%20v5.0.pdf
- *
- * for more information.
+ * Hypervisor Top Level Functional Specification for more information.
  */
 
 #include 
@@ -103,10 +99,7 @@
 #define HV_FLUSH_ALL_PROCESSORS 1
 
 /*
- * Viridian Partition Privilege Flags.
- *
- * This is taken from section 4.2.2 of the specification, and fixed for
- * style and correctness.
+ * Viridian Partition Privilege Flags
  */
 typedef struct {
 /* Access to virtual MSRs */
@@ -168,7 +161,7 @@ typedef union _HV_CRASH_CTL_REG_CONTENTS
 #define CPUID4A_MSR_BASED_APIC (1 << 3)
 #define CPUID4A_RELAX_TIMER_INT(1 << 5)
 
-/* Viridian CPUID leaf 6: Implementation HW features detected and in use. */
+/* Viridian CPUID leaf 6: Implementation HW features detected and in use */
 #define CPUID6A_APIC_OVERLAY(1 << 0)
 #define CPUID6A_MSR_BITMAPS (1 << 1)
 #define CPUID6A_NESTED_PAGING   (1 << 3)
@@ -204,7 +197,6 @@ void cpuid_viridian_leaves(const struct vcpu *v, uint32_t 
leaf,
 switch ( leaf )
 {
 case 0:
-/* See section 2.4.1 of the specification */
 res->a = 0x4006; /* Maximum leaf */
 memcpy(>b, "Micr", 4);
 memcpy(>c, "osof", 4);
@@ -212,13 +204,14 @@ void cpuid_viridian_leaves(const struct vcpu *v, uint32_t 
leaf,
 break;
 
 case 1:
-/* See section 2.4.2 of the specification */
 memcpy(>a, "Hv#1", 4);
 break;
 
 case 2:
-/* Hypervisor information, but only if the guest has set its
-   own version number. */
+/*
+ * Hypervisor information, but only if the guest has set its
+ * own version number.
+ */
 if ( d->arch.hvm.viridian.guest_os_id.raw == 0 )
 break;
 res->a = viridian_build;
@@ -230,9 +223,9 @@ void cpuid_viridian_leaves(const struct vcpu *v, uint32_t 
leaf,
 case 3:
 {
 /*
- * Section 2.4.4 details this leaf and states that EAX and EBX
- * are defined to be the low and high parts of the partition
- * privilege mask respectively.
+ * The specification states that EAX and EBX are defined to be
+ * the low and high parts of the partition privilege mask
+ * respectively.
  */
 HV_PARTITION_PRIVILEGE_MASK mask = {
 .AccessIntrCtrlRegs = 1,
@@ -382,11 +375,6 @@ static void initialize_vp_assist(struct vcpu *v)
 
 ASSERT(!v->arch.hvm.viridian.vp_assist.va);
 
-/*
- * See section 7.8.7 of the specification for details of this
- * enlightenment.
- */
-
 if ( !page )
 goto fail;
 
@@ -409,8 +397,8 @@ static void initialize_vp_assist(struct vcpu *v)
 return;
 
  fail:
-gdprintk(XENLOG_WARNING, "Bad GMFN %#"PRI_gfn" (MFN %#"PRI_mfn")\n", gmfn,
- mfn_x(page ? page_to_mfn(page) : INVALID_MFN));
+gdprintk(XENLOG_WARNING, "Bad GMFN %#"PRI_gfn" (MFN %#"PRI_mfn")\n",
+ gmfn, mfn_x(page ? page_to_mfn(page) : INVALID_MFN));
 }
 
 static void teardown_vp_assist(struct vcpu *v)
@@ -498,14 +486,15 @@ static void update_reference_tsc(struct domain *d, bool_t 
initialize)
 clear_page(p);
 
 /*
- * This enlightenment must be disabled is the host TSC is not invariant.
- * However it is also disabled if vtsc is true (which means rdtsc is being
- * emulated). This generally happens when guest TSC freq and host TSC freq
- * don't match. The TscScale value could be adjusted to cope with this,
- * allowing vtsc to be turned off, but support for this is not yet present
- * in the hypervisor. Thus is it is possible that migrating a Windows VM
- * between hosts of differing TSC frequencies may result in large
- * differences in guest performance.
+ * This 

[Xen-devel] [PATCH 1/2] x86/mm/p2m: don't needlessly limit MMIO mapping order to 4k

[Paul Durrant]

The P2M common code currently restricts the MMIO mapping order of any
domain with IOMMU mappings, but that is not using shared tables, to 4k.
This has been shown to have a huge performance cost when passing through
a PCI device with a very large BAR (e.g. NVIDIA P40), increasing the guest
boot time from ~20s to several minutes when iommu=no-sharept is specified
on the Xen command line.

The limitation was added by commit c3c756bd "x86/p2m: use large pages
for MMIO mappings" however the underlying implementations of p2m->set_entry
for Intel and AMD are coded to cope with mapping orders higher than 4k,
even though the IOMMU mapping function is itself currently limited to 4k,
so there is no real need to limit the order passed into the method, other
than to avoid a potential DoS caused by a long running hypercall.

In practice, mmio_order() already strictly disallows 1G mappings since the
if clause in question starts with:

if ( 0 /*
* Don't use 1Gb pages, to limit the iteration count in
* set_typed_p2m_entry() when it needs to zap M2P entries
* for a RAM range.
*/ &&

With this patch applied (and hence 2M mappings in use) the VM boot time is
restored to something reasonable. Not as fast as without iommu=no-sharept,
but within a few seconds of it.

NOTE: This patch takes the opportunity to shorten a couple of > 80
  character lines in the code.

Signed-off-by: Paul Durrant 
Acked-by: George Dunlap 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Wei Liu 

v2:
 - Add an extra to the if clause disallowing 1G mappings to make sure
   they are not used if need_iommu_pt_sync() is true, even though the
   check is currently moot (see main comment).
---
 xen/arch/x86/mm/p2m.c | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index a00a3c1bff..f972b4819d 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -2081,14 +2081,11 @@ static unsigned int mmio_order(const struct domain *d,
unsigned long start_fn, unsigned long nr)
 {
 /*
- * Note that the !iommu_use_hap_pt() here has three effects:
- * - cover iommu_{,un}map_page() not having an "order" input yet,
- * - exclude shadow mode (which doesn't support large MMIO mappings),
- * - exclude PV guests, should execution reach this code for such.
- * So be careful when altering this.
+ * PV guests or shadow-mode HVM guests must be restricted to 4k
+ * mappings.
  */
-if ( !iommu_use_hap_pt(d) ||
- (start_fn & ((1UL << PAGE_ORDER_2M) - 1)) || !(nr >> PAGE_ORDER_2M) )
+if ( !hap_enabled(d) || (start_fn & ((1UL << PAGE_ORDER_2M) - 1)) ||
+ !(nr >> PAGE_ORDER_2M) )
 return PAGE_ORDER_4K;
 
 if ( 0 /*
@@ -2096,8 +2093,12 @@ static unsigned int mmio_order(const struct domain *d,
 * set_typed_p2m_entry() when it needs to zap M2P entries
 * for a RAM range.
 */ &&
- !(start_fn & ((1UL << PAGE_ORDER_1G) - 1)) && (nr >> PAGE_ORDER_1G) &&
- hap_has_1gb )
+ !(start_fn & ((1UL << PAGE_ORDER_1G) - 1)) &&
+ (nr >> PAGE_ORDER_1G) &&
+ hap_has_1gb &&
+ /* disable 1G mappings if we need to keep the IOMMU in sync */
+ !need_iommu_pt_sync(d)
+)
 return PAGE_ORDER_1G;
 
 if ( hap_has_2mb )
-- 
2.11.0


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

Re: [Xen-devel] [PATCH v5 03/15] libxl_qmp: Implement fd callback and read data [and 1 more messages]

[Ian Jackson]

Anthony PERARD writes ("Re: [PATCH v5 03/15] libxl_qmp: Implement fd callback 
and read data [and 1 more messages]"):
> On Mon, Oct 15, 2018 at 05:35:36PM +0100, Ian Jackson wrote:
> > What are LIBXL__QMP_ERROR_CLASSes and why are they even different from
> > ERROR_* values ?  Maybe one of them is the QMP integer values and one
> > of them is the corresponding libxl integer values ?
> 
> The issue here is that, in QMP, the error is a string and in camel case,
> e.g. "GenericError".  I've use the idl to generate an enum from the
> different error strings.

You're using the idl generator to generate a table mapping
"GenericError" to LIBXL__QMP_ERROR_CLASS_GENERICERROR (by a series of
string lookups done in the libxl string to enum value function) and
then a handwritten function to convert that to
ERROR_QMP_GENERIC_ERROR, which is in turn defined in the ERROR
enum in the idl ?

I don't think the first use of the idl generator (for
LIBXL__QMP_ERROR_CLASS) is really helping very much here.

How about this: introduce in the IDL only ERROR_QMP_* values like
ERROR_QMP_GENERIC_ERROR.  The idl compiler will make a table mapping
"QMP_GENERIC_ERROR" to ERROR_QMP_GENERIC_ERROR.

You can then write a custom lookup function
  int libxl_qmp_error_class_to_libxl_error_code
  (libxl_gc *gc, const char *eclass)
which:
 * Iterates over that table, looking for strings in the table
   which start QMP_.  So it finds at "QMP_GENERIC_ERROR".
 * If an entry does start with QMP_, it uses a custom string
   comparison routine which ignores case, and skips underscores
   in the libxl error code string.  So it matches like this:
   QMP_GENERIC_ERROR
   Generic Error
 * If no matching entry is found it logs the real QMP
   error string and returns ERROR_UNKNOWN_QMP_ERROR
   (which must not be called LIBXL_QMP_UNKNOWN_ERROR in
   case QMP has or grows an "UnknownError" error code).

This is not the fastest approach imaginable but it's no worse than the
existing O(n) error string lookup and I hope this isn't a hot path.


> > > +/* return 1 when a user callback as been called */
> > > +static int qmp_ev_handle_response(libxl__egc *egc,
> > > +  libxl__ev_qmp *ev,
> > > +  const libxl__json_object *resp,
> > > +  libxl__qmp_message_type type)
> > > +{
> > > +EGC_GC;
> > > +const libxl__json_object *response;
> > > +const libxl__json_object *o;
> > > +int rc;
> > > +int id;
> > > +
> > > +o = libxl__json_map_get("id", resp, JSON_INTEGER);
> > > +if (!o) {
> > > +const char *error_desc;
> > > +
> > > +/* unexpected message, attempt to find an error description */
> > > +o = libxl__json_map_get("error", resp, JSON_MAP);
> > > +o = libxl__json_map_get("desc", o, JSON_STRING);
> > 
> > What is the dead store from "error" doing ?
> 
> It's not dead, I reuse "o", as I get "desc" from "o".
> I could just create new variables here instead of reusing the same one
> (o) over and over again, e.g. obj_id, obj_error, obj_desc.

Oh.  Sorry.  Yes.  The idiom with the reuse of `o' is fine, I think,
but:

> Should I add here that we are parsing: {"error":{"desc": X }} ?

That would be lovely.  In general that would make these functions much
easier to read.

> > > +case LIBXL__QMP_MESSAGE_TYPE_ERROR: {
> > > +const char *s;
> > > +const libxl__json_object *err;
> > > +libxl__qmp_error_class error_class;
> > > +
> > > +rc = ERROR_FAIL;
> > > +response = NULL;
> > > +
> > > +err = libxl__json_map_get("error", resp, JSON_MAP);
> > > +o = libxl__json_map_get("class", err, JSON_STRING);
> > > +s = libxl__json_object_get_string(o);
> > > +if (s && !libxl__qmp_error_class_from_string(s, _class))
> > > +rc = qmp_error_class_to_libxl_error_code(error_class);
> > > +
> > > +o = libxl__json_map_get("desc", err, JSON_STRING);
> > > +s = libxl__json_object_get_string(o);
> > > +if (s)
> > > +LOGD(ERROR, ev->domid, "%s", s);
> > > +
> > > +break;
> > 
> > Surely this should print more debugging (or maybe even error log
> > messages) if the error json document was not in the expected form ?
> 
> Do you mean that if the QMP server doesn't respect the QMP protocol, I
> should print more debug here?
> 
> If we are at this point in the programme, we know that the server sent:
> {"error": X }
> 
> I'm tempted to say that if "class" or "desc" isn't present, we could say
> so and declare the server broken (and disconnect).

Yes.  Precisely.  But I think what happens with your current code is
that it falls through to the bottom with little in the way of
diagnostics.

One approach would be to add an error logging string parameter to
libxl__json_*_get, which (if non-null, and the input object is
non-null) logs an appropriate complaint including the logging string
parameter and the 

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  dafd936dddbd7978d4131275ad1112f64457bf64
baseline version:
 xen  1ecb1ee4d8475475c3ccf72f6654644b242ce856

Last test of basis   129136  2018-10-29 13:00:37 Z0 days
Testing same since   129141  2018-10-29 15:00:41 Z0 days1 attempts


People who touched revisions under test:
  Dario Faggioli 
  George Dunlap 

jobs:
 build-arm64-xsm  pass
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   1ecb1ee4d8..dafd936ddd  dafd936dddbd7978d4131275ad1112f64457bf64 -> smoke

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

Re: [Xen-devel] Interrupt injection with ISR set on Intel hardware

[Andrew Cooper]

On 29/10/18 16:58, Jan Beulich wrote:
 On 29.10.18 at 17:44,  wrote:
>> On 29/10/18 16:33, Jan Beulich wrote:
>> On 15.10.18 at 12:30,  wrote:
 (XEN)   [22641] PUSH {sp  0, irq  30, vec 0x21}
>>> This is the last push or pop.
>>>
 (XEN)   [22650] WAKE PPR 0x0020
 (XEN)IRR 
>> 0200
 (XEN)ISR 
>> 0200
>>> For one I'm having trouble understanding why IRR here is different
>>> from ...
>>>
 (XEN) All LAPIC state:
 (XEN)   [vector]  ISR  TMR  IRR
 (XEN)   [1f:00]    
 (XEN)   [3f:20]  0002  
 (XEN)   [5f:40]    
 (XEN)   [7f:60]    
 (XEN)   [9f:80]    
 (XEN)   [bf:a0]    
 (XEN)   [df:c0]    
 (XEN)   [ff:e0]    0400
>>> ... IRR here.
>> You shouldn't expect them to be the same.
>>
>> The WAKE line is sampled before we enable interrupts, and the "All LAPIC
>> state" is after we enable interrupts and (erroneously) accept vector
>> 0x21 a second time.
> Oh, right - I had overlooked that the debugging patch was actually
> attached to Roger's mail.
>
>> In the meantime, a TLB flush has become pending, but interrupts are
>> currently disabled so it has yet to be accepted.  Remember that bits
>> accumulate in IRR entirely asynchronously.
> Well, bits newly set are of course to be expected at any time. My
> issue was just with bit 0x21 having got cleared.

What is unexpected about that?

Accepting a vector clears it out of IRR and sets it in ISR.  A second
interrupt can then be queued in IRR while the first is being serviced.

>  (FTR I think it's an
> LAPIC timer interrupt which has become pending, not a TLB flush
> IPI, but I don't think the difference matters here at all.)

Hmm possibly.  I thought I traced it once before, but the vector layout
here is slightly dynamic based on boot conditions.  I agree that the
difference is immaterial.

~Andrew

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

Re: [Xen-devel] [PATCH v2 3/7] x86/pvh: allow PVH Dom0 to use the debug IO port console

[Jan Beulich]

>>> On 29.10.18 at 17:53,  wrote:
> On 19/10/18 16:20, Roger Pau Monne wrote:
>> Add an option to allow trapping accesses to IO port 0xe9 for a PVH
>> Dom0, so it can print to the HVM debug console. Note this is not
>> enabled by default in order to prevent clashes with hardware on the
>> system using 0xe9.
>>
>> Signed-off-by: Roger Pau Monné 
>> ---
>> Cc: Jan Beulich 
>> Cc: Andrew Cooper 
>> Cc: Wei Liu 
>> ---
>> Changes since v1:
>>  - Use a define for 0xe9.
>>  - Expand 'List of' in the Xen command doc.
> 
> As said during v1, make this unconditional and do away the command line
> option.
> 
> Noone with a PVH dom0 is going to have a real CoZet Info PC radio on an
> ISA bus.

Oh, I'm sorry - I had forgotten about that request of yours, and
should hence not have given my R-b.

Jan


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

[Xen-devel] FOSDEM Devrooms (CfP deadlines for relevant DevRooms from Dec 1-10) and Xen Project Stand

[Lars Kurth]

Hi all,

I just submitted a Xen Project stand submission and if everything goes ok, we 
will be having a booth again like the last 5 years
Accepted stands should be announced by November 11

If you already know you are going, please add yourself to 
https://docs.google.com/spreadsheets/d/1uk79a_iEeSosTWG7OgZvhW2nZMO-cJHiDz0BNb0dN60/edit?usp=sharing
 and let me know if you are willing to help out. Also, if you want to give swag 
out, give demos, etc. please let me know by adding what you want to in the last 
column

Also, a number of CfP’s may be relevant: see table below

Devroom

CfP Deadline

CfP

BSD @ Sat, Feb 2nd

2018-12-10

https://lists.fosdem.org/pipermail/fosdem/2018q4/002741.html

Virtualization and IaaS @ Sat, Feb 2nd

2018-12-01

https://lists.fosdem.org/pipermail/fosdem/2018q4/002757.html

Containers @ Sun, Feb 3rd

TBA

TBA

Microkernels and Component-based OS @ Sun, Feb 3rd

2018-12-01

https://lists.fosdem.org/pipermail/fosdem/2018q4/002742.html


The complete list of accepted DevRooms is at 
https://www.fosdem.org/2019/news/2018-10-14-accepted-developer-rooms/
Some will have earlier CfP’s

Note that I am not volunteering for the Virtualization and IaaS DevRoom this 
year: if anyone wants to volunteer, please contact

Brian Proffitt (bproffit at redhat)

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

Re: [Xen-devel] Interrupt injection with ISR set on Intel hardware

[Jan Beulich]

>>> On 29.10.18 at 17:44,  wrote:
> On 29/10/18 16:33, Jan Beulich wrote:
> On 15.10.18 at 12:30,  wrote:
>>> (XEN)   [22641] PUSH {sp  0, irq  30, vec 0x21}
>> This is the last push or pop.
>>
>>> (XEN)   [22650] WAKE PPR 0x0020
>>> (XEN)IRR 
> 0200
>>> (XEN)ISR 
> 0200
>> For one I'm having trouble understanding why IRR here is different
>> from ...
>>
>>> (XEN) All LAPIC state:
>>> (XEN)   [vector]  ISR  TMR  IRR
>>> (XEN)   [1f:00]    
>>> (XEN)   [3f:20]  0002  
>>> (XEN)   [5f:40]    
>>> (XEN)   [7f:60]    
>>> (XEN)   [9f:80]    
>>> (XEN)   [bf:a0]    
>>> (XEN)   [df:c0]    
>>> (XEN)   [ff:e0]    0400
>> ... IRR here.
> 
> You shouldn't expect them to be the same.
> 
> The WAKE line is sampled before we enable interrupts, and the "All LAPIC
> state" is after we enable interrupts and (erroneously) accept vector
> 0x21 a second time.

Oh, right - I had overlooked that the debugging patch was actually
attached to Roger's mail.

> In the meantime, a TLB flush has become pending, but interrupts are
> currently disabled so it has yet to be accepted.  Remember that bits
> accumulate in IRR entirely asynchronously.

Well, bits newly set are of course to be expected at any time. My
issue was just with bit 0x21 having got cleared. (FTR I think it's an
LAPIC timer interrupt which has become pending, not a TLB flush
IPI, but I don't think the difference matters here at all.)

Jan



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

Re: [Xen-devel] [PATCH v2 2/7] x86/hvm: introduce a define for the debug output IO port

[Jan Beulich]

>>> On 19.10.18 at 17:20,  wrote:
> No functional change intended.
> 
> Signed-off-by: Roger Pau Monné 

Reviewed-by: Jan Beulich 
with one remark:

> --- a/xen/include/public/arch-x86/xen.h
> +++ b/xen/include/public/arch-x86/xen.h
> @@ -346,6 +346,12 @@ struct xen_arch_domainconfig {
>  #define XEN_CPUID  XEN_EMULATE_PREFIX "cpuid"
>  #endif
>  
> +/*
> + * Debug console IO port, also called "port E9 hack". Each character written
> + * to this IO port will be printed on the hypervisor console.
> + */
> +#define XEN_HVM_DEBUGCONS_IOPORT 0xe9

Perhaps amend the comment with "..., subject to log level
restrictions"? Easily done while committing.

FTR I'm a little uneasy about adding this to the public
interface, but otoh external components already use it as
if it was part of it.

Jan


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

Re: [Xen-devel] [PATCH 1/4] xen/arm: gic: Ensure we have an ISB between ack and do_IRQ()

[Andrii Anisov]

Hello Julien

On 29.10.18 15:36, Julien Grall wrote:0
I wrote down an answer yesterday (sent it today) to your previous
answer. You may use the LRs information from the previous guest trap as
interrupts are re-enabled before storing the LRs.

Yes, it is the case. I've overlooked that for some exceptions interrupts are 
enabled before enter_hypervisor_head().


Can you try the patch below?

I tried it, and it works like a charm for the issue.

The only notice here is that I suppose it coul



commit 11e360b93be81a58a41832d714f33f797ad312a9
Author: Julien Grall 
Date:   Mon Oct 29 13:32:56 2018 +

xen/arm: Re-enable interrupt later in the trap path

Signed-off-by: Julien Grall 


diff --git a/xen/arch/arm/arm64/entry.S b/xen/arch/arm/arm64/entry.S
index 97b05f53ea..8f287891b6 100644
--- a/xen/arch/arm/arm64/entry.S
+++ b/xen/arch/arm/arm64/entry.S
@@ -195,7 +195,6 @@ hyp_error_invalid:

 hyp_error:
 entry   hyp=1
-msr daifclr, #2
 mov x0, sp
 bl  do_trap_hyp_serror
 exithyp=1
@@ -203,7 +202,7 @@ hyp_error:
 /* Traps taken in Current EL with SP_ELx */
 hyp_sync:
 entry   hyp=1
-msr daifclr, #6
+msr daifclr, #4
 mov x0, sp
 bl  do_trap_hyp_sync
 exithyp=1
@@ -304,7 +303,7 @@ guest_sync_slowpath:
 ALTERNATIVE("bl check_pending_vserror; cbnz x0, 1f",
 "nop; nop",
 SKIP_SYNCHRONIZE_SERROR_ENTRY_EXIT)
-msr daifclr, #6
+msr daifclr, #4
 mov x0, sp
 bl  do_trap_guest_sync
 1:
@@ -332,7 +331,7 @@ guest_fiq_invalid:

 guest_error:
 entry   hyp=0, compat=0
-msr daifclr, #6
+msr daifclr, #4
 mov x0, sp
 bl  do_trap_guest_serror
 exithyp=0, compat=0
@@ -347,7 +346,7 @@ guest_sync_compat:
 ALTERNATIVE("bl check_pending_vserror; cbnz x0, 1f",
 "nop; nop",
 SKIP_SYNCHRONIZE_SERROR_ENTRY_EXIT)
-msr daifclr, #6
+msr daifclr, #4
 mov x0, sp
 bl  do_trap_guest_sync
 1:
@@ -375,7 +374,7 @@ guest_fiq_invalid_compat:

 guest_error_compat:
 entry   hyp=0, compat=1
-msr daifclr, #6
+msr daifclr, #4
 mov x0, sp
 bl  do_trap_guest_serror
 exithyp=0, compat=1
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 51d2e42c77..c18f89b41f 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2039,6 +2039,8 @@ static void enter_hypervisor_head(struct cpu_user_regs 
*regs)
 {
 struct vcpu *v = current;

+ASSERT(!local_irq_is_enabled());
+
 /* If the guest has disabled the workaround, bring it back on. */
 if ( needs_ssbd_flip(v) )
 arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 1, NULL);
@@ -2073,6 +2075,7 @@ void do_trap_guest_sync(struct cpu_user_regs *regs)
 const union hsr hsr = { .bits = regs->hsr };

 enter_hypervisor_head(regs);
+local_irq_enable();

 switch ( hsr.ec )
 {
@@ -2208,6 +2211,7 @@ void do_trap_hyp_sync(struct cpu_user_regs *regs)
 const union hsr hsr = { .bits = regs->hsr };

 enter_hypervisor_head(regs);
+local_irq_enable();

 switch ( hsr.ec )
 {
@@ -2246,6 +2250,7 @@ void do_trap_hyp_sync(struct cpu_user_regs *regs)
 void do_trap_hyp_serror(struct cpu_user_regs *regs)
 {
 enter_hypervisor_head(regs);
+local_irq_enable();

 __do_trap_serror(regs, VABORT_GEN_BY_GUEST(regs));
 }
@@ -2253,6 +2258,7 @@ void do_trap_hyp_serror(struct cpu_user_regs *regs)
 void do_trap_guest_serror(struct cpu_user_regs *regs)
 {
 enter_hypervisor_head(regs);
+local_irq_enable();

 __do_trap_serror(regs, true);
 }

--

Andrii Anisov

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

Re: [Xen-devel] [PATCH v2 1/7] x86/pvh: fix TSC mode setup for PVH Dom0

[Jan Beulich]

>>> On 19.10.18 at 17:20,  wrote:
> A PVH Dom0 might use TSC scaling or other HVM specific TSC
> adjustments, so only short-circuit the TSC setup for a classic PV
> Dom0.
> 
> Signed-off-by: Roger Pau Monné 

Acked-by: Jan Beulich 


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

Re: [Xen-devel] Interrupt injection with ISR set on Intel hardware

[Andrew Cooper]

On 29/10/18 16:33, Jan Beulich wrote:
 On 15.10.18 at 12:30,  wrote:
>> (XEN)   [22641] PUSH {sp  0, irq  30, vec 0x21}
> This is the last push or pop.
>
>> (XEN)   [22650] WAKE PPR 0x0020
>> (XEN)IRR 
>> 0200
>> (XEN)ISR 
>> 0200
> For one I'm having trouble understanding why IRR here is different
> from ...
>
>> (XEN) All LAPIC state:
>> (XEN)   [vector]  ISR  TMR  IRR
>> (XEN)   [1f:00]    
>> (XEN)   [3f:20]  0002  
>> (XEN)   [5f:40]    
>> (XEN)   [7f:60]    
>> (XEN)   [9f:80]    
>> (XEN)   [bf:a0]    
>> (XEN)   [df:c0]    
>> (XEN)   [ff:e0]    0400
> ... IRR here.

You shouldn't expect them to be the same.

The WAKE line is sampled before we enable interrupts, and the "All LAPIC
state" is after we enable interrupts and (erroneously) accept vector
0x21 a second time.

In the meantime, a TLB flush has become pending, but interrupts are
currently disabled so it has yet to be accepted.  Remember that bits
accumulate in IRR entirely asynchronously.

~Andrew

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

Re: [Xen-devel] [PATCH v4] arch/x86: Add registers to vm_event

[Jan Beulich]

>>> On 26.10.18 at 11:11,  wrote:
> @@ -157,6 +157,21 @@
>  #define VM_EVENT_X86_CR42
>  #define VM_EVENT_X86_XCR0   3
>  
> +/*
> + * The limit field is right-shifted by 12 bits if .ar.g is set.
> + */

This is supposed to be a single line comment.

> @@ -191,9 +206,19 @@ struct vm_event_regs_x86 {
>  uint64_t msr_efer;
>  uint64_t msr_star;
>  uint64_t msr_lstar;
> -uint64_t fs_base;
> -uint64_t gs_base;
> -uint32_t cs_arbytes;
> +struct x86_selector_reg_32 cs;
> +struct x86_selector_reg_32 ss;
> +struct x86_selector_reg_32 ds;
> +struct x86_selector_reg_32 es;
> +struct x86_selector_reg_64 fs;

Since you say space is scarce on the ring, you may want to consider
filling the (I think) 4-byte gaps here and ...

> +struct x86_selector_reg_64 gs;

... here, e.g. by putting two selector values there. But of course
this requires either splitting struct x86_selector_reg_{32,64} or
somehow (in a gcc extension free way) reducing the alignment of
the latter. My recommendation would be to pack only limit and
access rights into a structure, and provided bases as standalone
fields just like you already do for selectors. With that you'd then
also not need to put some of the selector values in the middle (to
fill padding holes).

But this is just a suggestion - I'm not the maintainer of any of the
code you change.

Jan



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

Re: [Xen-devel] Interrupt injection with ISR set on Intel hardware

[Jan Beulich]

>>> On 15.10.18 at 12:30,  wrote:
> (XEN)   [22641] PUSH {sp  0, irq  30, vec 0x21}

This is the last push or pop.

> (XEN)   [22650] WAKE PPR 0x0020
> (XEN)IRR 
> 0200
> (XEN)ISR 
> 0200

For one I'm having trouble understanding why IRR here is different
from ...

> (XEN) All LAPIC state:
> (XEN)   [vector]  ISR  TMR  IRR
> (XEN)   [1f:00]    
> (XEN)   [3f:20]  0002  
> (XEN)   [5f:40]    
> (XEN)   [7f:60]    
> (XEN)   [9f:80]    
> (XEN)   [bf:a0]    
> (XEN)   [df:c0]    
> (XEN)   [ff:e0]    0400

... IRR here.

> (XEN) Assertion '(sp == 0) || (peoi[sp-1].vector < vector)' failed at 
> irq.c:1340
> (XEN) [ Xen-4.12-unstable  x86_64  debug=y   Tainted:  C   ]
> (XEN) CPU:1
> (XEN) RIP:e008:[] do_IRQ+0x8df/0xacb
> (XEN) RFLAGS: 00010002   CONTEXT: hypervisor
> (XEN) rax: 83086c67202c   rbx: 0180   rcx: 
> (XEN) rdx: 83086c68   rsi: 000a   rdi: 83086c601e24
> (XEN) rbp: 83086c68fd98   rsp: 83086c68fd38   r8:  83086c69
> (XEN) r9:  0030   r10: 0400   r11: 0007
> (XEN) r12: 011f   r13:    r14: 83086c601e00
> (XEN) r15: 82cfb100   cr0: 80050033   cr4: 003526e0

And then I'm having trouble guessing which register holds
"vector" here: r9 is the only one where I could sort of guess
it might be a vector, but then the assertion would not have
triggered. There's in particular no register with the low byte
being 0x21, nor is there any with it being 0xfa (to match the
bit that became set in IRR).

Could you please check or provide the disassembly?

Jan



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

Re: [Xen-devel] [PATCH 1/4] xen/arm: gic: Ensure we have an ISB between ack and do_IRQ()

[Julien Grall]

On 29/10/2018 16:16, Andrii Anisov wrote:

Hello Julien


Hi,

On 29.10.18 15:36, Julien Grall wrote:0

I wrote down an answer yesterday (sent it today) to your previous
answer. You may use the LRs information from the previous guest trap as
interrupts are re-enabled before storing the LRs.


Yes, it is the case. I've overlooked that for some exceptions interrupts
are enabled before enter_hypervisor_head().



Can you try the patch below?


I tried it, and it works like a charm for the issue.


What is the issue? Is it just your print or there a latent bug in current vGIC?



The only notice here is that, I suppose, changes are needed for
exceptions taken from a guest mode. For the exceptions taken from hyp,
we do not massage gic in enter_hypervisor_head.


I actually prefer if we re-enable interrupts after entry_hypervisor_head(). This 
makes the code working the same way everywhere so less trouble to figure out 
problem.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 1/4] xen/arm: gic: Ensure we have an ISB between ack and do_IRQ()

[Andrii Anisov]

Hello Julien

On 29.10.18 15:36, Julien Grall wrote:0
> I wrote down an answer yesterday (sent it today) to your previous
> answer. You may use the LRs information from the previous guest trap as
> interrupts are re-enabled before storing the LRs.

Yes, it is the case. I've overlooked that for some exceptions interrupts 
are enabled before enter_hypervisor_head().


> Can you try the patch below?

I tried it, and it works like a charm for the issue.

The only notice here is that, I suppose, changes are needed for 
exceptions taken from a guest mode. For the exceptions taken from hyp, 
we do not massage gic in enter_hypervisor_head.


-- 

*Andrii Anisov*



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

[Xen-devel] [PATCH v2] x86/hvm: Clean up the rest of bool_t from vm_event

[Alexandru Stefan ISAILA]

Signed-off-by: Alexandru Isaila 
Acked-by: Tamas K Lengyel 
Acked-by: Jan Beulich 

---
Changes since V1:
- Made style corrections suggested by Jan.
---
 xen/arch/x86/hvm/hvm.c| 3 ++-
 xen/arch/x86/mm/mem_sharing.c | 2 +-
 xen/arch/x86/mm/p2m.c | 5 ++---
 xen/common/memory.c   | 2 +-
 xen/common/vm_event.c | 4 ++--
 xen/include/asm-x86/mem_sharing.h | 2 +-
 xen/include/xen/vm_event.h| 8 
 7 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index a140e60c9c..a8566fb87c 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1905,7 +1905,8 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned long 
gla,
 if ( sharing_enomem )
 {
 int rv;
-if ( (rv = mem_sharing_notify_enomem(currd, gfn, 1)) < 0 )
+
+if ( (rv = mem_sharing_notify_enomem(currd, gfn, true)) < 0 )
 {
 gdprintk(XENLOG_ERR, "Domain %hu attempt to unshare "
  "gfn %lx, ENOMEM and no helper (rc %d)\n",
diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index 1dab2c8cc3..be09c8871a 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -546,7 +546,7 @@ static int audit(void)
 }
 
 int mem_sharing_notify_enomem(struct domain *d, unsigned long gfn,
-bool_t allow_sleep) 
+  bool allow_sleep)
 {
 struct vcpu *v = current;
 int rc;
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index a00a3c1bff..4bdc5e34e0 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -448,7 +448,7 @@ mfn_t __get_gfn_type_access(struct p2m_domain *p2m, 
unsigned long gfn_l,
 /* Try to unshare. If we fail, communicate ENOMEM without
  * sleeping. */
 if ( mem_sharing_unshare_page(p2m->domain, gfn_l, 0) < 0 )
-(void)mem_sharing_notify_enomem(p2m->domain, gfn_l, 0);
+mem_sharing_notify_enomem(p2m->domain, gfn_l, false);
 mfn = p2m->get_entry(p2m, gfn, t, a, q, page_order, NULL);
 }
 
@@ -839,8 +839,7 @@ guest_physmap_add_entry(struct domain *d, gfn_t gfn, mfn_t 
mfn,
  * Foreign domains are okay to place an event as they 
  * won't go to sleep. */
 (void)mem_sharing_notify_enomem(p2m->domain,
-gfn_x(gfn_add(gfn, i)),
-0);
+gfn_x(gfn_add(gfn, i)), false);
 return rc;
 }
 omfn = p2m->get_entry(p2m, gfn_add(gfn, i),
diff --git a/xen/common/memory.c b/xen/common/memory.c
index 987395fbb3..b68efd4d9f 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -356,7 +356,7 @@ int guest_remove_page(struct domain *d, unsigned long gmfn)
 rc = mem_sharing_unshare_page(d, gmfn, 0);
 if ( rc )
 {
-(void)mem_sharing_notify_enomem(d, gmfn, 0);
+mem_sharing_notify_enomem(d, gmfn, false);
 goto out_put_gfn;
 }
 /* Maybe the mfn changed */
diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
index 6ffd18a448..26cfa2c605 100644
--- a/xen/common/vm_event.c
+++ b/xen/common/vm_event.c
@@ -496,7 +496,7 @@ static int vm_event_wait_slot(struct vm_event_domain *ved)
 return rc;
 }
 
-bool_t vm_event_check_ring(struct vm_event_domain *ved)
+bool vm_event_check_ring(struct vm_event_domain *ved)
 {
 return (ved && ved->ring_page);
 }
@@ -514,7 +514,7 @@ bool_t vm_event_check_ring(struct vm_event_domain *ved)
  *
  */
 int __vm_event_claim_slot(struct domain *d, struct vm_event_domain *ved,
-  bool_t allow_sleep)
+  bool allow_sleep)
 {
 if ( !vm_event_check_ring(ved) )
 return -EOPNOTSUPP;
diff --git a/xen/include/asm-x86/mem_sharing.h 
b/xen/include/asm-x86/mem_sharing.h
index 91908924df..0e77b7d935 100644
--- a/xen/include/asm-x86/mem_sharing.h
+++ b/xen/include/asm-x86/mem_sharing.h
@@ -84,7 +84,7 @@ static inline int mem_sharing_unshare_page(struct domain *d,
  * then it's the same as a foreign domain.
  */
 int mem_sharing_notify_enomem(struct domain *d, unsigned long gfn,
-bool_t allow_sleep);
+  bool allow_sleep);
 int mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg);
 int mem_sharing_domctl(struct domain *d, 
struct xen_domctl_mem_sharing_op *mec);
diff --git a/xen/include/xen/vm_event.h b/xen/include/xen/vm_event.h
index 2ff6e1c333..5302ee55c1 100644
--- a/xen/include/xen/vm_event.h
+++ b/xen/include/xen/vm_event.h
@@ -30,7 +30,7 @@
 void vm_event_cleanup(struct domain *d);
 
 /* Returns whether a ring has been set up */
-bool_t vm_event_check_ring(struct vm_event_domain *ved);
+bool 

Re: [Xen-devel] [PATCH v5 03/15] libxl_qmp: Implement fd callback and read data [and 1 more messages]

[Anthony PERARD]

On Mon, Oct 15, 2018 at 05:35:36PM +0100, Ian Jackson wrote:
> > +static int qmp_error_class_to_libxl_error_code(const 
> > libxl__qmp_error_class c)
> > +{
> > +switch (c) {
> > +case LIBXL__QMP_ERROR_CLASS_GENERICERROR:
> > +return ERROR_QMP_GENERIC_ERROR;
> > +case LIBXL__QMP_ERROR_CLASS_COMMANDNOTFOUND:
> > +return ERROR_QMP_COMMAND_NOT_FOUND;
> > +case LIBXL__QMP_ERROR_CLASS_DEVICENOTFOUND:
> > +return ERROR_QMP_DEVICE_NOT_FOUND;
> 
> Urgh.  The slightly different names means that this can't be
> macro-ified.  Without that, it would be really easy for someone in the
> future to accidentally write something like this:
>
> > +case LIBXL__QMP_ERROR_CLASS_GENERICERROR:
> > +return ERROR_QMP_GENERIC_ERROR;
> > +case LIBXL__QMP_ERROR_CLASS_COMMANDNOTFOUND:
> > +return ERROR_QMP_GENERIC_ERROR;
> > +case LIBXL__QMP_ERROR_CLASS_DEVICENOTFOUND:
> > +return ERROR_QMP_DEVICE_NOT_FOUND;
> 
> and it's hard to spot.
> 
> What are LIBXL__QMP_ERROR_CLASSes and why are they even different from
> ERROR_* values ?  Maybe one of them is the QMP integer values and one
> of them is the corresponding libxl integer values ?

The issue here is that, in QMP, the error is a string and in camel case,
e.g. "GenericError".  I've use the idl to generate an enum from the
different error strings.

> Anyway, can we not make this less open-coded somehow.

I could remove some underscores '_' from the libxl ERROR_* integer
values, e.g. ERROR_QMP_GENERICERROR. But if you have a better suggestion
on how to transform "CommandNotFound" into a ERROR_QMP_*, I'll take it.

> > +default:
> > +abort();
> 
> But what happens if qemu invents a new error code ?  I don't think
> aborting is likely to be right.

If qemu invent a new error code, libxl should not call
qmp_error_class_to_libxl_error_code(), because libxl would not have been
able to generate a libxl__qmp_error_class from the new error code.

But I could add an assert(false) and return ERROR_FAIL instead of the
abort.

> > +/* return 1 when a user callback as been called */
> > +static int qmp_ev_handle_response(libxl__egc *egc,
> > +  libxl__ev_qmp *ev,
> > +  const libxl__json_object *resp,
> > +  libxl__qmp_message_type type)
> > +{
> > +EGC_GC;
> > +const libxl__json_object *response;
> > +const libxl__json_object *o;
> > +int rc;
> > +int id;
> > +
> > +o = libxl__json_map_get("id", resp, JSON_INTEGER);
> > +if (!o) {
> > +const char *error_desc;
> > +
> > +/* unexpected message, attempt to find an error description */
> > +o = libxl__json_map_get("error", resp, JSON_MAP);
> > +o = libxl__json_map_get("desc", o, JSON_STRING);
> 
> What is the dead store from "error" doing ?

It's not dead, I reuse "o", as I get "desc" from "o".
I could just create new variables here instead of reusing the same one
(o) over and over again, e.g. obj_id, obj_error, obj_desc.

Should I add here that we are parsing: {"error":{"desc": X }} ?

> > +switch (type) {
> > +case LIBXL__QMP_MESSAGE_TYPE_RETURN: {
> > +response = libxl__json_map_get("return", resp, JSON_ANY);
> > +rc = 0;
> > +break;
> > +}
> > +case LIBXL__QMP_MESSAGE_TYPE_ERROR: {
> > +const char *s;
> > +const libxl__json_object *err;
> > +libxl__qmp_error_class error_class;
> > +
> > +rc = ERROR_FAIL;
> > +response = NULL;
> > +
> > +err = libxl__json_map_get("error", resp, JSON_MAP);
> > +o = libxl__json_map_get("class", err, JSON_STRING);
> > +s = libxl__json_object_get_string(o);
> > +if (s && !libxl__qmp_error_class_from_string(s, _class))
> > +rc = qmp_error_class_to_libxl_error_code(error_class);
> > +
> > +o = libxl__json_map_get("desc", err, JSON_STRING);
> > +s = libxl__json_object_get_string(o);
> > +if (s)
> > +LOGD(ERROR, ev->domid, "%s", s);
> > +
> > +break;
> 
> Surely this should print more debugging (or maybe even error log
> messages) if the error json document was not in the expected form ?

Do you mean that if the QMP server doesn't respect the QMP protocol, I
should print more debug here?

If we are at this point in the programme, we know that the server sent:
{"error": X }

I'm tempted to say that if "class" or "desc" isn't present, we could say
so and declare the server broken (and disconnect).

> > +/* Findout how much can be parsed */
> > +size_t len = end - s;
> > +
> > +LOG_QMP("parsing %luB: '%.*s'", len, (int)len, s);
> > +
> > +/* Replace \n by \0 so that libxl__json_parse can use strlen */
> > +s[len - 1] = '\0';
> 
> Doesn't this feed the \r to libxl__json_parse ?
> 
> Also, why does this have to be a loop ?  Does qemu really send
> multiple json documents end to end, 

Re: [Xen-devel] [PATCH V3 1/3] x86/altp2m: propagate ept.ad changes to all active altp2ms

[Tamas K Lengyel]

On Mon, Oct 29, 2018 at 6:42 AM Razvan Cojocaru
 wrote:
>
> This patch is a pre-requisite for fixing the logdirty VGA issue
> (display freezes when switching to a new altp2m view early in a
> domain's lifetime), but sent separately for easier review.
> The new ept_set_ad_sync() function has been added to update all
> active altp2ms' ept.ad. New altp2ms will inherit the hostp2m's
> ept.ad value.
>
> Signed-off-by: Razvan Cojocaru 
> Suggested-by: George Dunlap 

Tested-by: Tamas K Lengyel 

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

Re: [Xen-devel] [PATCH V3 2/3] x86/mm: allocate logdirty_ranges for altp2ms

[Tamas K Lengyel]

On Mon, Oct 29, 2018 at 6:41 AM Razvan Cojocaru
 wrote:
>
> This patch is a pre-requisite for the one fixing VGA logdirty
> freezes when using altp2m. It only concerns itself with the
> ranges allocation / deallocation / initialization part. While
> touching the code, I've switched global_logdirty from bool_t
> to bool.
>
> Signed-off-by: Razvan Cojocaru 

Tested-by: Tamas K Lengyel 

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

Re: [Xen-devel] [PATCH V3 3/3] x86/altp2m: fix display frozen when switching to a new view early

[Tamas K Lengyel]

On Mon, Oct 29, 2018 at 6:41 AM Razvan Cojocaru
 wrote:
>
> When an new altp2m view is created very early on guest boot, the
> display will freeze (although the guest will run normally). This
> may also happen on resizing the display. The reason is the way
> Xen currently (mis)handles logdirty VGA: it intentionally
> misconfigures VGA pages so that they will fault.
>
> The problem is that it only does this in the host p2m. Once we
> switch to a new altp2m, the misconfigured entries will no longer
> fault, so the display will not be updated.
>
> This patch:
> * updates ept_handle_misconfig() to use the active altp2m instead
>   of the hostp2m;
> * modifies p2m_change_entry_type_global(), p2m_memory_type_changed
>   and p2m_change_type_range() to propagate their changes to all
>   valid altp2ms.
>
> Signed-off-by: Razvan Cojocaru 
> Suggested-by: George Dunlap 

Tested-by: Tamas K Lengyel 

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

Re: [Xen-devel] [PATCH V3 2/2] Xen/PCIback: Implement PCI flr/slot/bus reset with 'reset' SysFS attribute

[Pasi Kärkkäinen]

Hi,

On Tue, Oct 23, 2018 at 08:40:29PM +0200, Håkon Alstadheim wrote:
> 
> 
> Den 08. okt. 2018 16:32, skrev Boris Ostrovsky:
> >
> > Are these two patches still needed? ISTR they were  written originally
> > to deal with guest trying to use device that was previously assigned to
> > another guest. But pcistub_put_pci_dev() calls
> > __pci_reset_function_locked() which first tries FLR, and it looks like
> > it was added relatively recently.
> >
> >
> Sorry for the late reply, but I just now booted xen staging-4.11
> (94fba9f438a2c36ad9bf3a481a6013ddc7cf8cd9), with gentoo-sources-4.19.0
> as dom0. Shut down and started again a VM that has a secondary GPU
> passed through, and the whole  machine hung. I haven't had time to look
> more closely into this, other than that my old "do_flr" patch no longer
> applies to gentoo-sources (i.e. the linux kernel sources) . "do_flr"
> worked for me on linux-4.18.? , with appropriate patch to the linux kernel.
> 
> So, something is definitely needed. No "reset" , or "do_flr" is present
> in linux-4.19.0, viz:
> 
> $ cd /usr/src/linux/drivers/xen/xen-pciback
> $ grep DRIVER *
> pci_stub.c:#define PCISTUB_DRIVER_NAME "pciback"
> pci_stub.c:  !strcmp(dev->driver_override, PCISTUB_DRIVER_NAME)) ||
> pci_stub.c: .name = PCISTUB_DRIVER_NAME,
> pci_stub.c:static DRIVER_ATTR_WO(new_slot);
> pci_stub.c:static DRIVER_ATTR_WO(remove_slot);
> pci_stub.c:static DRIVER_ATTR_RO(slots);
> pci_stub.c:static DRIVER_ATTR_RO(irq_handlers);
> pci_stub.c:static DRIVER_ATTR_WO(irq_handler_state);
> pci_stub.c:static DRIVER_ATTR_RW(quirks);
> pci_stub.c:static DRIVER_ATTR_RW(permissive);
> pci_stub.c: if (action != BUS_NOTIFY_UNBIND_DRIVER)
> $
> 
> 
> I'd be happy to test patches. Seems I only got one corrupt file from my
> test this morning :-D .
> 

Håkon: Please do test the patches and report how it works for you!
Here are the links:

Linux kernel xen-pciback 'reset' patches:

"[PATCH V3 0/2] Xen/PCIback: PCI reset using 'reset' SysFS attribute":
https://lists.xen.org/archives/html/xen-devel/2017-12/msg00659.html

(Patch 1/2 is not needed anymore in upstream Linux kernel, as 
pcie_has_flr() is already exported meanwhile)

"[PATCH V3 2/2] Xen/PCIback: Implement PCI flr/slot/bus reset with 
'reset' SysFS attribute":
https://lists.xen.org/archives/html/xen-devel/2017-12/msg00661.html

Xen libxl 'reset' patches:

"[PATCH V1 0/1] Xen/Tools: PCI reset using 'reset' SysFS attribute":
https://lists.xen.org/archives/html/xen-devel/2017-12/msg00664.html

"[PATCH V1 1/1] Xen/libxl: Perform PCI reset using 'reset' SysFS 
attribute":
https://lists.xen.org/archives/html/xen-devel/2017-12/msg00663.html



Thanks,

-- Pasi


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

Re: [Xen-devel] [PATCH 2/4] x86/vvmx: Drop the now-obsolete vmx_inst_check_privilege()

[Jan Beulich]

>>> On 25.10.18 at 17:38,  wrote:
> Now that nvmx_handle_vmx_insn() performs all VT-x instruction checks, there is
> no need for redundant checking in vmx_inst_check_privilege().  Remove it, and
> take out the vmxon_check boolean which was plumbed through 
> decode_vmx_inst().
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 



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

Re: [Xen-devel] [PATCH 1/4] x86/vvmx: Unconditionally initialise vmxon_region_pa during vcpu construction

[Jan Beulich]

>>> On 25.10.18 at 17:36,  wrote:
> This is a stopgap solution until the toolstack side of initialisation can be
> sorted out, but it does result in the nvmx_vcpu_in_vmx() predicate working
> correctly even when nested virt hasn't been enabled for the domain.
> 
> Update nvmx_handle_vmx_insn() to include the in-vmx mode check (for all
> instructions other than VMXON) to complete the set of #UD checks.
> 
> In addition, sanity check that the nested vmexit handler has worked correctly,
> and that we are only providing emulation of the VT-x instructions to L1
> guests.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 



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

[Xen-devel] [PATCH] x86/paravirt: pv_ops isn't GPL only

[Juergen Gross]

Commit 5c83511bdb9832 ("x86/paravirt: Use a single ops structure")
introduced a regression for out-of-tree modules using spinlocks, as
pv_lock_ops was exported via EXPORT_SYMBOL(), while the new pv_ops
structure now containing the pv lock operations is exported via
EXPORT_SYMBOL_GPL().

Change that by using EXPORT_SYMBOL(pv_ops).

Fixes: 5c83511bdb9832 ("x86/paravirt: Use a single ops structure")
Signed-off-by: Juergen Gross 
---
 arch/x86/kernel/paravirt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index e4d4df37922a..45123b116c05 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -483,5 +483,5 @@ NOKPROBE_SYMBOL(native_set_debugreg);
 NOKPROBE_SYMBOL(native_load_idt);
 #endif
 
-EXPORT_SYMBOL_GPL(pv_ops);
+EXPORT_SYMBOL(pv_ops);
 EXPORT_SYMBOL_GPL(pv_info);
-- 
2.16.4


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

Re: [Xen-devel] [PATCH RESEND qemu-xen-traditional] xen/pt: allow QEMU to request MSI unmasking at bind time

[Pasi Kärkkäinen]

Hi,

On Wed, Oct 24, 2018 at 04:20:35PM +0100, Ian Jackson wrote:
> Andra Paraschiv writes ("[PATCH RESEND qemu-xen-traditional] xen/pt: allow 
> QEMU to request MSI unmasking at bind time"):
> > When a MSI interrupt is bound to a guest using
> > xc_domain_update_msi_irq (XEN_DOMCTL_bind_pt_irq) the interrupt is
> > left masked by default.
> 
> Applied, and pushed the corresponding update to QEMU_TAG in
> qemu-xen-unstable.
> 
> Does this patch need to be backported to earlier Xen releases ?  It
> wasn't clear to me whether there is new Xen code in this area without
> which the problem (which the patch solves) does not arise; or whether,
> conversely, simply running a new guest is sufficient.
> 

Good question. In the earlier thread about this patch it was mentioned
the bug happens with latest stable version of Xen, which sounds like 
this patch should be backported to stable Xen versions. Is that correct?


Thanks,

-- Pasi

> Regards,
> Ian.
> 

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

Re: [Xen-devel] [PATCH v2 13/16] x86: rearrange x86_64/entry.S

[Jan Beulich]

>>> On 19.10.18 at 16:28,  wrote:
> @@ -845,19 +865,7 @@ handle_ist_exception:
>  /* We want to get straight to the IRET on the NMI exit path. */
>  testb $3,UREGS_cs(%rsp)
>  jzrestore_all_xen
> -GET_CURRENT(bx)
> -/* Send an IPI to ourselves to cover for the lack of event checking. 
> */
> -movl  VCPU_processor(%rbx),%eax
> -shll  $IRQSTAT_shift,%eax
> -leaq  irq_stat+IRQSTAT_softirq_pending(%rip),%rcx
> -cmpl  $0,(%rcx,%rax,1)
> -je1f
> -movl  $EVENT_CHECK_VECTOR,%edi
> -call  send_IPI_self
> -1:  movq  VCPU_domain(%rbx),%rax
> -cmpb  $0,DOMAIN_is_32bit_pv(%rax)
> -jerestore_all_guest
> -jmp   compat_restore_all_guest
> +jmp   self_ipi_restore_all_guest

I'm having some trouble understanding why you move this code:
Without CONFIG_PV it is unreachable. I'd prefer if it stayed in
place and simply got an #ifdef around it. The one alternative
option I could see is to move the restore_all_xen code block
right here, so the JMP you put in could become JNZ.

Jan



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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  1ecb1ee4d8475475c3ccf72f6654644b242ce856
baseline version:
 xen  079df73c0a5b4b09b71044091d65a986452d829c

Last test of basis   129116  2018-10-29 01:01:58 Z0 days
Testing same since   129136  2018-10-29 13:00:37 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Brian Woods 
  Jan Beulich 
  Paul Durrant 

jobs:
 build-arm64-xsm  pass
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   079df73c0a..1ecb1ee4d8  1ecb1ee4d8475475c3ccf72f6654644b242ce856 -> smoke

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

Re: [Xen-devel] [PATCH v2 09/16] x86: don't setup PV hypercall stubs and entries when !CONFIG_PV

[Jan Beulich]

>>> On 19.10.18 at 17:59,  wrote:
> On 19/10/18 15:28, Wei Liu wrote:
>> @@ -347,6 +352,7 @@ void subarch_percpu_traps_init(void)
>>  /* Common SYSCALL parameters. */
>>  wrmsrl(MSR_STAR, XEN_MSR_STAR);
>>  wrmsrl(MSR_SYSCALL_MASK, XEN_SYSCALL_MASK);
>> +#endif
> 
> It would be a wise precaution to initialise these MSRs to 0 in the !PV
> case, so we don't retain stale values.

If anything, EFER.SCE needs to be kept clear, as that's what
controls whether SYSCALL would raise #GP(0). But without a
PV domain around, nothing can access the host values of
these MSRs in the first place, so instead we could simplify
some context switching by never restoring host values, and
only ever loading guest ones. Except that, of course, VMLOAD
is an all-or-nothing insn, and we need to use to get TR loaded.

Jan



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

Re: [Xen-devel] [PATCH v2 09/16] x86: don't setup PV hypercall stubs and entries when !CONFIG_PV

[Jan Beulich]

>>> On 19.10.18 at 16:28,  wrote:
> @@ -303,14 +305,17 @@ void cstar_enter(void);
>  
>  void subarch_percpu_traps_init(void)
>  {
> +#ifdef CONFIG_PV
>  unsigned long stack_bottom = get_stack_bottom();
>  unsigned long stub_va = this_cpu(stubs.addr);
>  unsigned char *stub_page;
>  unsigned int offset;
> +#endif
>  
>  /* IST_MAX IST pages + at least 1 guard page + primary stack. */
>  BUILD_BUG_ON((IST_MAX + 1) * PAGE_SIZE + PRIMARY_STACK_SIZE > 
> STACK_SIZE);

By moving this to the end of the function, one less #if/#endif
pair would be needed.

Jan



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

Re: [Xen-devel] [PATCH v2 07/16] x86: put XEN_DOMCTL_{set, get}_address_size under CONFIG_PV

[Jan Beulich]

>>> On 19.10.18 at 16:28,  wrote:
> They are useful to PV only.

Considering there was no is_{hvm,pv}_...() check so far, I think
you need to extend this a little plus ...

> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -608,6 +608,7 @@ long arch_do_domctl(
>  copyback = true;
>  break;
>  
> +#ifdef CONFIG_PV
>  case XEN_DOMCTL_set_address_size:
>  if ( ((domctl->u.address_size.size == 64) && !d->arch.is_32bit_pv) ||
>   ((domctl->u.address_size.size == 32) && d->arch.is_32bit_pv) )
> @@ -623,6 +624,7 @@ long arch_do_domctl(
>
> BITS_PER_LONG;
>  copyback = true;
>  break;
> +#endif

... add such a check so that similar behavior will result with PV
enabled and disabled (error codes may differ, but success vs
error ought to match).

Jan



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

Re: [Xen-devel] [PATCH v1] x86/hvm: Clean up the rest of bool_t from vm_event

[Tamas K Lengyel]

On Mon, Oct 29, 2018 at 4:54 AM Alexandru Stefan ISAILA
 wrote:
>
> Signed-off-by: Alexandru Isaila 

Acked-by: Tamas K Lengyel 

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

Re: [Xen-devel] [PATCH v2 7/7] amd/pvh: enable ACPI C1E disable quirk on PVH Dom0

[Jan Beulich]

>>> On 19.10.18 at 17:20,  wrote:
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -1272,6 +1272,24 @@ void svm_host_osvw_init()
>  spin_unlock(_lock);
>  }
>  
> +static int acpi_c1e_quirk(int dir, unsigned int port, unsigned int bytes,
> +  uint32_t *val)
> +{
> +ASSERT(bytes == 1 && port == acpi_smi_cmd);
> +
> +if ( dir == IOREQ_READ )
> +{
> +*val = inb(port);
> +return X86EMUL_OKAY;
> +}
> +
> +outb(*val, port);
> +if ( *val == acpi_enable_value )
> +   on_each_cpu(amd_disable_c1e, NULL, 1);
> +
> +return X86EMUL_OKAY;
> +}

Nothing in here nor ...

> @@ -1284,6 +1302,9 @@ static int svm_domain_initialise(struct domain *d)
>  
>  svm_guest_osvw_init(d);
>  
> +if ( amd_acpi_c1e_quirk )
> +register_portio_handler(d, acpi_smi_cmd, 1, acpi_c1e_quirk);

... the registration here restricts this to Dom0.

Jan



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

[Xen-devel] [xen-unstable test] 129104: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-arm64-arm64-libvirt-xsm 12 guest-start  fail REGR. vs. 128775
 test-armhf-armhf-libvirt 12 guest-start  fail REGR. vs. 128775
 test-armhf-armhf-libvirt-raw 10 debian-di-installfail REGR. vs. 128775

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 128775
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 128775
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 128775
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 128775
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 128775
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 128775
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 128775
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  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-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   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-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-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-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 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

version targeted for testing:
 xen  5d91b689dde48522a591ad3cac7c0520b4dec30c
baseline version:
 xen  92666fdd6e0afab989b2d89759d9b43f2c645ae7

Last test of basis   128775  2018-10-14 16:42:23 Z   14 days
Failing since128839  2018-10-16 15:38:26 Z   12 days9 attempts
Testing same since   129074  2018-10-27 22:00:31 Z1 days2 attempts


People who touched revisions under test:
  
  Adrian Pop 
  Alexander Schulz 
  Alexandru Isaila 
  Andrew Cooper 
  Daniel De Graaf 
  Elena Ufimtseva 
  George Dunlap 
  Ian Jackson 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Paul Durrant 
  Razvan Cojocaru 
  Roger Pau Monne 
  Roger Pau Monné 
  Sergey Dyasli 
  Tamas K Lengyel 
  Tim Deegan 
  Wei Liu 
  Xin Li 
  Xin Li 

jobs:
 build-amd64-xsm   

Re: [Xen-devel] [PATCH 1/4] xen/arm: gic: Ensure we have an ISB between ack and do_IRQ()

[Julien Grall]

On 29/10/2018 10:06, Andrii Anisov wrote:

Hello Julien,


Hi,



Sorry for the previous email sent as html.


Don't worry. I didn't notice it :).




On 27.10.18 15:14, Andrii Anisov wrote:

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c index
f6f6de3..985192b 100644 --- a/xen/arch/arm/traps.c +++
b/xen/arch/arm/traps.c @@ -2095,6 +2095,7 @@ static void
enter_hypervisor_head(struct cpu_user_regs *regs) if (
current->arch.hcr_el2 & HCR_VA ) current->arch.hcr_el2 =
READ_SYSREG(HCR_EL2);

+gic_store_lrs();


gic_clear_lrs(...) may rewrite the LRs. To confirm this stall LRs
are not due by this function, can you move that after
gic_clear_lrs()?

Right you are, gic_clear_lrs(), in 4.10 codebase, rewrites LRs. But
it does not change PENDING to INVALID under no circumstances from
one hand. From another hand, all changes to LRs are made through
gic specific operations gic_hw_ops->... which are tracked by me.
You can see, in the code above, that I copy all updates to the
physical LR issued by hypervisor into the stored LRs. So it not the
case. But I'll check on Monday.


In 4.12-unstable code base I moved gic_store_lrs() after
vgic_sync_from_lrs()  and see significant changes.  Now stale lines
are printed at very high rate, and it is the proper behavior. Because
the correspondent check (performed when vgic_sync_from_lrs() reads
LRs) detects that VM processes interrupts and LR values are changed
comparing to those set by hypervisor lately.

So now it is the question, why could I detect spurious changes in LRs
without exiting to VM?


I wrote down an answer yesterday (sent it today) to your previous
answer. You may use the LRs information from the previous guest trap as
interrupts are re-enabled before storing the LRs.

Can you try the patch below?

commit 11e360b93be81a58a41832d714f33f797ad312a9
Author: Julien Grall 
Date:   Mon Oct 29 13:32:56 2018 +

xen/arm: Re-enable interrupt later in the trap path

Signed-off-by: Julien Grall 

diff --git a/xen/arch/arm/arm64/entry.S b/xen/arch/arm/arm64/entry.S
index 97b05f53ea..8f287891b6 100644
--- a/xen/arch/arm/arm64/entry.S
+++ b/xen/arch/arm/arm64/entry.S
@@ -195,7 +195,6 @@ hyp_error_invalid:

 hyp_error:
 entry   hyp=1
-msr daifclr, #2
 mov x0, sp
 bl  do_trap_hyp_serror
 exithyp=1
@@ -203,7 +202,7 @@ hyp_error:
 /* Traps taken in Current EL with SP_ELx */
 hyp_sync:
 entry   hyp=1
-msr daifclr, #6
+msr daifclr, #4
 mov x0, sp
 bl  do_trap_hyp_sync
 exithyp=1
@@ -304,7 +303,7 @@ guest_sync_slowpath:
 ALTERNATIVE("bl check_pending_vserror; cbnz x0, 1f",
 "nop; nop",
 SKIP_SYNCHRONIZE_SERROR_ENTRY_EXIT)
-msr daifclr, #6
+msr daifclr, #4
 mov x0, sp
 bl  do_trap_guest_sync
 1:
@@ -332,7 +331,7 @@ guest_fiq_invalid:

 guest_error:
 entry   hyp=0, compat=0
-msr daifclr, #6
+msr daifclr, #4
 mov x0, sp
 bl  do_trap_guest_serror
 exithyp=0, compat=0
@@ -347,7 +346,7 @@ guest_sync_compat:
 ALTERNATIVE("bl check_pending_vserror; cbnz x0, 1f",
 "nop; nop",
 SKIP_SYNCHRONIZE_SERROR_ENTRY_EXIT)
-msr daifclr, #6
+msr daifclr, #4
 mov x0, sp
 bl  do_trap_guest_sync
 1:
@@ -375,7 +374,7 @@ guest_fiq_invalid_compat:

 guest_error_compat:
 entry   hyp=0, compat=1
-msr daifclr, #6
+msr daifclr, #4
 mov x0, sp
 bl  do_trap_guest_serror
 exithyp=0, compat=1
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 51d2e42c77..c18f89b41f 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2039,6 +2039,8 @@ static void enter_hypervisor_head(struct cpu_user_regs 
*regs)
 {
 struct vcpu *v = current;

+ASSERT(!local_irq_is_enabled());
+
 /* If the guest has disabled the workaround, bring it back on. */
 if ( needs_ssbd_flip(v) )
 arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 1, NULL);
@@ -2073,6 +2075,7 @@ void do_trap_guest_sync(struct cpu_user_regs *regs)
 const union hsr hsr = { .bits = regs->hsr };

 enter_hypervisor_head(regs);
+local_irq_enable();

 switch ( hsr.ec )
 {
@@ -2208,6 +2211,7 @@ void do_trap_hyp_sync(struct cpu_user_regs *regs)
 const union hsr hsr = { .bits = regs->hsr };

 enter_hypervisor_head(regs);
+local_irq_enable();

 switch ( hsr.ec )
 {
@@ -2246,6 +2250,7 @@ void do_trap_hyp_sync(struct cpu_user_regs *regs)
 void do_trap_hyp_serror(struct cpu_user_regs *regs)
 {
 enter_hypervisor_head(regs);
+local_irq_enable();

 __do_trap_serror(regs, VABORT_GEN_BY_GUEST(regs));
 }
@@ -2253,6 +2258,7 @@ void do_trap_hyp_serror(struct cpu_user_regs *regs)
 void 

[Xen-devel] [PATCH v2] iommu / p2m: add a page_order parameter to iommu_map/unmap_page()

[Paul Durrant]

The P2M code currently contains many loops to deal with the fact that,
while it may be require to handle page orders greater than 4k, the
IOMMU map and unmap functions do not.
This patch adds a page_order parameter to those functions and implements
the necessary loops within. This allows the P2M code to be substantially
simplified.

NOTE: This patch does not modify the underlying vendor IOMMU
  implementations to deal with page orders of more than 4k.

Signed-off-by: Paul Durrant 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Wei Liu 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Julien Grall 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Jun Nakajima 
Cc: Kevin Tian 

v2:
 - Add alignment ASSERTs and tweak code structure to avoid to much nesting.
 - Don't bail from an unmap in the case of the hardware domain.
---
 xen/arch/x86/mm.c   |  4 ++-
 xen/arch/x86/mm/p2m-ept.c   | 30 +++---
 xen/arch/x86/mm/p2m-pt.c| 47 --
 xen/arch/x86/mm/p2m.c   | 49 +--
 xen/arch/x86/x86_64/mm.c|  4 ++-
 xen/common/grant_table.c|  7 +++--
 xen/drivers/passthrough/iommu.c | 51 +
 xen/drivers/passthrough/x86/iommu.c |  2 +-
 xen/include/xen/iommu.h |  8 +++---
 9 files changed, 77 insertions(+), 125 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index c53bc86a68..f0ae016e7a 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -2794,9 +2794,11 @@ static int _get_page_type(struct page_info *page, 
unsigned long type,
 mfn_t mfn = page_to_mfn(page);
 
 if ( (x & PGT_type_mask) == PGT_writable_page )
-iommu_ret = iommu_unmap_page(d, _dfn(mfn_x(mfn)));
+iommu_ret = iommu_unmap_page(d, _dfn(mfn_x(mfn)),
+ PAGE_ORDER_4K);
 else if ( type == PGT_writable_page )
 iommu_ret = iommu_map_page(d, _dfn(mfn_x(mfn)), mfn,
+   PAGE_ORDER_4K,
IOMMUF_readable |
IOMMUF_writable);
 }
diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index 407e299e50..656c8dd3ac 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -880,33 +880,9 @@ out:
 if ( iommu_use_hap_pt(d) )
 rc = iommu_pte_flush(d, gfn, _entry->epte, order, 
vtd_pte_present);
 else if ( need_iommu_pt_sync(d) )
-{
-dfn_t dfn = _dfn(gfn);
-
-if ( iommu_flags )
-for ( i = 0; i < (1 << order); i++ )
-{
-rc = iommu_map_page(d, dfn_add(dfn, i),
-mfn_add(mfn, i), iommu_flags);
-if ( unlikely(rc) )
-{
-while ( i-- )
-/* If statement to satisfy __must_check. */
-if ( iommu_unmap_page(p2m->domain,
-  dfn_add(dfn, i)) )
-continue;
-
-break;
-}
-}
-else
-for ( i = 0; i < (1 << order); i++ )
-{
-ret = iommu_unmap_page(d, dfn_add(dfn, i));
-if ( !rc )
-rc = ret;
-}
-}
+rc = iommu_flags ?
+iommu_map_page(d, _dfn(gfn), mfn, order, iommu_flags) :
+iommu_unmap_page(d, _dfn(gfn), order);
 }
 
 unmap_domain_page(table);
diff --git a/xen/arch/x86/mm/p2m-pt.c b/xen/arch/x86/mm/p2m-pt.c
index 55df18501e..b264a97bd8 100644
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -477,10 +477,11 @@ p2m_pt_set_entry(struct p2m_domain *p2m, gfn_t gfn_, 
mfn_t mfn,
  unsigned int page_order, p2m_type_t p2mt, p2m_access_t p2ma,
  int sve)
 {
+struct domain *d = p2m->domain;
 /* XXX -- this might be able to be faster iff current->domain == d */
 void *table;
 unsigned long gfn = gfn_x(gfn_);
-unsigned long i, gfn_remainder = gfn;
+unsigned long gfn_remainder = gfn;
 l1_pgentry_t *p2m_entry, entry_content;
 /* Intermediate table to free if we're replacing it with a superpage. */
 l1_pgentry_t intermediate_entry = l1e_empty();
@@ -515,7 +516,7 @@ p2m_pt_set_entry(struct p2m_domain *p2m, gfn_t gfn_, mfn_t 
mfn,
 t.gfn = gfn;
 t.mfn = mfn_x(mfn);
 t.p2mt = p2mt;
-t.d = p2m->domain->domain_id;
+t.d = d->domain_id;
 t.order = page_order;
 
 __trace_var(TRC_MEM_SET_P2M_ENTRY, 0, sizeof(t), );
@@ -683,41 +684,13 @@ p2m_pt_set_entry(struct p2m_domain *p2m, gfn_t gfn_, 
mfn_t 

Re: [Xen-devel] [PATCH v2 12/18] xen: setup Xen specific data for PVH

[Roger Pau Monné]

On Fri, Oct 19, 2018 at 06:39:50PM +0200, Juergen Gross wrote:
> On 19/10/2018 18:10, Roger Pau Monné wrote:
> > On Tue, Oct 09, 2018 at 01:03:11PM +0200, Juergen Gross wrote:
> >> Initialize the needed Xen specific data. This is:
> >>
> >> - the Xen start of day page containing the console and Xenstore ring
> >>   page PFN and event channel
> >> - the grant table
> >> - the shared info page
> >>
> >> Set the RSDP address for the guest from the start_info page passed
> >> as boot parameter.
> >>
> >> Signed-off-by: Juergen Gross 
> >> ---
> >>  grub-core/kern/i386/xen/pvh.c | 107 
> >> ++
> >>  1 file changed, 107 insertions(+)
> >>
> >> diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/xen/pvh.c
> >> index b4933b454..93ed68245 100644
> >> --- a/grub-core/kern/i386/xen/pvh.c
> >> +++ b/grub-core/kern/i386/xen/pvh.c
> >> @@ -24,6 +24,7 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >> +#include 
> >>  #include 
> >>  
> >>  struct xen_machine_mmap_entry
> >> @@ -39,6 +40,7 @@ static struct { char _entry[32]; } hypercall_page[128]
> >>__attribute__ ((aligned (GRUB_XEN_PAGE_SIZE)));
> >>  
> >>  static grub_uint32_t xen_cpuid_base;
> >> +static struct start_info grub_xen_start_page;
> >>  static struct xen_machine_mmap_entry map[128];
> >>  static unsigned int nr_map_entries;
> >>  
> >> @@ -104,6 +106,36 @@ grub_xen_hypercall (grub_uint32_t callno, 
> >> grub_uint32_t a0,
> >>return __res;
> >>  }
> >>  
> >> +static grub_uint32_t
> >> +grub_xen_get_param (int idx)
> >> +{
> >> +  struct xen_hvm_param xhv;
> >> +  int r;
> >> +
> >> +  xhv.domid = DOMID_SELF;
> >> +  xhv.index = idx;
> >> +  r = grub_xen_hypercall (__HYPERVISOR_hvm_op, HVMOP_get_param,
> >> +(grub_uint32_t) (), 0, 0, 0, 0);
> >> +  if (r < 0)
> >> +grub_xen_early_halt ();
> >> +  return xhv.value;
> >> +}
> >> +
> >> +static void *
> >> +grub_xen_add_physmap (unsigned int space, void *addr)
> >> +{
> >> +  struct xen_add_to_physmap xatp;
> >> +
> >> +  xatp.domid = DOMID_SELF;
> >> +  xatp.idx = 0;
> >> +  xatp.space = space;
> >> +  xatp.gpfn = (grub_addr_t) addr >> GRUB_XEN_LOG_PAGE_SIZE;
> >> +  if (grub_xen_hypercall (__HYPERVISOR_memory_op, XENMEM_add_to_physmap,
> >> +(grub_uint32_t) (), 0, 0, 0, 0))
> >> +grub_xen_early_halt ();
> >> +  return addr;
> >> +}
> >> +
> >>  static void
> >>  grub_xen_sort_mmap (void)
> >>  {
> >> @@ -190,12 +222,87 @@ grub_xen_get_mmap (void)
> >>grub_xen_sort_mmap ();
> >>  }
> >>  
> >> +static grub_uint64_t
> >> +grub_xen_find_page (grub_uint64_t start)
> >> +{
> >> +  unsigned int i, j;
> >> +  grub_uint64_t last = start;
> >> +
> >> +  /* Try to find a e820 map hole below 4G. */
> > 
> > Doing this is kind of dangerous, what if you end up placing something
> > on top of an MMIO region (either emulated or from a real passthrough
> > device)?
> 
> Shouldn't those be marked as "Reserved" in the memory map?

I don't think BARs are guaranteed to be in areas marked as reserved in
the memory map. Unless you also scan for PCI devices and make sure
there's no device with a BAR in the area you are attempting to
populate I think the above is not safe.

Thanks, Roger.

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

[Xen-devel] [PATCH V3 2/3] x86/mm: allocate logdirty_ranges for altp2ms

[Razvan Cojocaru]

This patch is a pre-requisite for the one fixing VGA logdirty
freezes when using altp2m. It only concerns itself with the
ranges allocation / deallocation / initialization part. While
touching the code, I've switched global_logdirty from bool_t
to bool.

Signed-off-by: Razvan Cojocaru 

---
CC: George Dunlap 
CC: Jan Beulich 
CC: Andrew Cooper 
CC: Wei Liu 

---
Changes since V2:
 - Moved the logdirty_ranges allocation / deallocation logic from
   p2m-ept.c to p2m.c on Jan's suggestion.
 - Added a comment clarifyin that the rangeset_merge() call is
   really just a copy in our context.
---
 xen/arch/x86/mm/p2m.c | 80 +--
 xen/include/asm-x86/p2m.h |  2 +-
 2 files changed, 64 insertions(+), 18 deletions(-)

diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 42b9ef4..c6b17e6 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -59,6 +59,28 @@ static void p2m_nestedp2m_init(struct p2m_domain *p2m)
 #endif
 }
 
+static int p2m_init_logdirty(struct p2m_domain *p2m)
+{
+if ( p2m->logdirty_ranges )
+return 0;
+
+p2m->logdirty_ranges = rangeset_new(p2m->domain, "log-dirty",
+RANGESETF_prettyprint_hex);
+if ( !p2m->logdirty_ranges )
+return -ENOMEM;
+
+return 0;
+}
+
+static void p2m_free_logdirty(struct p2m_domain *p2m)
+{
+if ( !p2m->logdirty_ranges )
+return;
+
+rangeset_destroy(p2m->logdirty_ranges);
+p2m->logdirty_ranges = NULL;
+}
+
 /* Init the datastructures for later use by the p2m code */
 static int p2m_initialise(struct domain *d, struct p2m_domain *p2m)
 {
@@ -108,7 +130,10 @@ free_p2m:
 static void p2m_free_one(struct p2m_domain *p2m)
 {
 if ( hap_enabled(p2m->domain) && cpu_has_vmx )
+{
+p2m_free_logdirty(p2m);
 ept_p2m_uninit(p2m);
+}
 free_cpumask_var(p2m->dirty_cpumask);
 xfree(p2m);
 }
@@ -116,19 +141,19 @@ static void p2m_free_one(struct p2m_domain *p2m)
 static int p2m_init_hostp2m(struct domain *d)
 {
 struct p2m_domain *p2m = p2m_init_one(d);
+int rc;
 
-if ( p2m )
-{
-p2m->logdirty_ranges = rangeset_new(d, "log-dirty",
-RANGESETF_prettyprint_hex);
-if ( p2m->logdirty_ranges )
-{
-d->arch.p2m = p2m;
-return 0;
-}
+if ( !p2m )
+return -ENOMEM;
+
+rc = p2m_init_logdirty(p2m);
+
+if ( !rc )
+d->arch.p2m = p2m;
+else
 p2m_free_one(p2m);
-}
-return -ENOMEM;
+
+return rc;
 }
 
 static void p2m_teardown_hostp2m(struct domain *d)
@@ -138,7 +163,7 @@ static void p2m_teardown_hostp2m(struct domain *d)
 
 if ( p2m )
 {
-rangeset_destroy(p2m->logdirty_ranges);
+p2m_free_logdirty(p2m);
 p2m_free_one(p2m);
 d->arch.p2m = NULL;
 }
@@ -194,6 +219,7 @@ static void p2m_teardown_altp2m(struct domain *d)
 continue;
 p2m = d->arch.altp2m_p2m[i];
 d->arch.altp2m_p2m[i] = NULL;
+p2m_free_logdirty(p2m);
 p2m_free_one(p2m);
 }
 }
@@ -2271,6 +2297,7 @@ void p2m_flush_altp2m(struct domain *d)
 {
 p2m_flush_table(d->arch.altp2m_p2m[i]);
 /* Uninit and reinit ept to force TLB shootdown */
+p2m_free_logdirty(d->arch.altp2m_p2m[i]);
 ept_p2m_uninit(d->arch.altp2m_p2m[i]);
 ept_p2m_init(d->arch.altp2m_p2m[i]);
 d->arch.altp2m_eptp[i] = mfn_x(INVALID_MFN);
@@ -2279,6 +2306,18 @@ void p2m_flush_altp2m(struct domain *d)
 altp2m_list_unlock(d);
 }
 
+static int p2m_init_altp2m_logdirty(struct p2m_domain *p2m)
+{
+struct p2m_domain *hostp2m = p2m_get_hostp2m(p2m->domain);
+int rc = p2m_init_logdirty(p2m);
+
+if ( rc )
+return rc;
+
+/* The following is really just a rangeset copy. */
+return rangeset_merge(p2m->logdirty_ranges, hostp2m->logdirty_ranges);
+}
+
 int p2m_init_altp2m_by_id(struct domain *d, unsigned int idx)
 {
 int rc = -EINVAL;
@@ -2290,8 +2329,9 @@ int p2m_init_altp2m_by_id(struct domain *d, unsigned int 
idx)
 
 if ( d->arch.altp2m_eptp[idx] == mfn_x(INVALID_MFN) )
 {
-p2m_init_altp2m_ept(d, idx);
-rc = 0;
+rc = p2m_init_altp2m_logdirty(d->arch.altp2m_p2m[idx]);
+if ( !rc )
+p2m_init_altp2m_ept(d, idx);
 }
 
 altp2m_list_unlock(d);
@@ -2310,9 +2350,13 @@ int p2m_init_next_altp2m(struct domain *d, uint16_t *idx)
 if ( d->arch.altp2m_eptp[i] != mfn_x(INVALID_MFN) )
 continue;
 
-p2m_init_altp2m_ept(d, i);
-*idx = i;
-rc = 0;
+rc = p2m_init_altp2m_logdirty(d->arch.altp2m_p2m[i]);
+
+if ( !rc )
+{
+p2m_init_altp2m_ept(d, i);
+*idx = i;
+}
 
 break;
 }
@@ -2341,6 +2385,7 @@ int p2m_destroy_altp2m_by_id(struct domain *d, unsigned 
int idx)
 {
 p2m_flush_table(d->arch.altp2m_p2m[idx]);
   

[Xen-devel] [PATCH V3 3/3] x86/altp2m: fix display frozen when switching to a new view early

[Razvan Cojocaru]

When an new altp2m view is created very early on guest boot, the
display will freeze (although the guest will run normally). This
may also happen on resizing the display. The reason is the way
Xen currently (mis)handles logdirty VGA: it intentionally
misconfigures VGA pages so that they will fault.

The problem is that it only does this in the host p2m. Once we
switch to a new altp2m, the misconfigured entries will no longer
fault, so the display will not be updated.

This patch:
* updates ept_handle_misconfig() to use the active altp2m instead
  of the hostp2m;
* modifies p2m_change_entry_type_global(), p2m_memory_type_changed
  and p2m_change_type_range() to propagate their changes to all
  valid altp2ms.

Signed-off-by: Razvan Cojocaru 
Suggested-by: George Dunlap 

---
CC: Jun Nakajima 
CC: Kevin Tian 
CC: George Dunlap 
CC: Jan Beulich 
CC: Andrew Cooper 
CC: Wei Liu 

---
Changes since V2:
 - RFC: We need George's opinion on Jan's suggestion to update
   p2m-pt.c as well.
 - Dropped the p2m_ prefix from the static helpers instead of
   adding a leading underscore (except for _memory_type_changed(),
   as there's a memory_type_changed() in asm/mtrr.h, which would
   break the build.
 - Used hostp2m in p2m_change_entry_type_global() where previously
   I had missed doing so for
   _p2m_change_entry_type_global(p2m_get_hostp2m(d), ot, nt);
   (although it had been already latched).
 - Now consistenly using the "update the hostp2m first, then the
   altp2ms" pattern.
---
 xen/arch/x86/mm/p2m-ept.c |  8 +
 xen/arch/x86/mm/p2m.c | 83 +++
 2 files changed, 78 insertions(+), 13 deletions(-)

diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index fabcd06..e6fa85f 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -657,6 +657,9 @@ bool_t ept_handle_misconfig(uint64_t gpa)
 bool_t spurious;
 int rc;
 
+if ( altp2m_active(curr->domain) )
+p2m = p2m_get_altp2m(curr);
+
 p2m_lock(p2m);
 
 spurious = curr->arch.hvm.vmx.ept_spurious_misconfig;
@@ -1440,6 +1443,11 @@ void p2m_init_altp2m_ept(struct domain *d, unsigned int 
i)
 struct p2m_domain *hostp2m = p2m_get_hostp2m(d);
 struct ept_data *ept;
 
+p2m->max_mapped_pfn = hostp2m->max_mapped_pfn;
+p2m->default_access = hostp2m->default_access;
+p2m->domain = hostp2m->domain;
+
+p2m->global_logdirty = hostp2m->global_logdirty;
 p2m->ept.ad = hostp2m->ept.ad;
 p2m->min_remapped_gfn = gfn_x(INVALID_GFN);
 p2m->max_remapped_gfn = 0;
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index c6b17e6..5fbee82 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -281,7 +281,6 @@ int p2m_init(struct domain *d)
 int p2m_is_logdirty_range(struct p2m_domain *p2m, unsigned long start,
   unsigned long end)
 {
-ASSERT(p2m_is_hostp2m(p2m));
 if ( p2m->global_logdirty ||
  rangeset_contains_range(p2m->logdirty_ranges, start, end) )
 return 1;
@@ -290,24 +289,48 @@ int p2m_is_logdirty_range(struct p2m_domain *p2m, 
unsigned long start,
 return 0;
 }
 
+static void change_entry_type_global(struct p2m_domain *p2m,
+  p2m_type_t ot, p2m_type_t nt)
+{
+p2m->change_entry_type_global(p2m, ot, nt);
+p2m->global_logdirty = (nt == p2m_ram_logdirty);
+}
+
 void p2m_change_entry_type_global(struct domain *d,
   p2m_type_t ot, p2m_type_t nt)
 {
-struct p2m_domain *p2m = p2m_get_hostp2m(d);
+struct p2m_domain *hostp2m = p2m_get_hostp2m(d);
 
 ASSERT(ot != nt);
 ASSERT(p2m_is_changeable(ot) && p2m_is_changeable(nt));
 
-p2m_lock(p2m);
-p2m->change_entry_type_global(p2m, ot, nt);
-p2m->global_logdirty = (nt == p2m_ram_logdirty);
-p2m_unlock(p2m);
+p2m_lock(hostp2m);
+
+change_entry_type_global(hostp2m, ot, nt);
+
+#ifdef CONFIG_HVM
+if ( unlikely(altp2m_active(d)) )
+{
+unsigned int i;
+
+for ( i = 0; i < MAX_ALTP2M; i++ )
+if ( d->arch.altp2m_eptp[i] != mfn_x(INVALID_MFN) )
+{
+struct p2m_domain *p2m = d->arch.altp2m_p2m[i];
+
+p2m_lock(p2m);
+change_entry_type_global(p2m, ot, nt);
+p2m_unlock(p2m);
+}
+}
+#endif
+
+p2m_unlock(hostp2m);
 }
 
-void p2m_memory_type_changed(struct domain *d)
+/* There's already a memory_type_changed() in asm/mtrr.h. */
+static void _memory_type_changed(struct p2m_domain *p2m)
 {
-struct p2m_domain *p2m = p2m_get_hostp2m(d);
-
 if ( p2m->memory_type_changed )
 {
 p2m_lock(p2m);
@@ -316,6 +339,22 @@ void p2m_memory_type_changed(struct domain *d)
 }
 }
 
+void p2m_memory_type_changed(struct domain *d)
+{
+_memory_type_changed(p2m_get_hostp2m(d));
+
+#ifdef CONFIG_HVM
+if ( unlikely(altp2m_active(d)) )
+{
+unsigned int i;
+
+for ( i = 0; i < 

[Xen-devel] [PATCH V3 0/3] Fix VGA logdirty related display freezes with altp2m

[Razvan Cojocaru]

Hello,

This series aims to prevent the display from freezing when
enabling altp2m and switching to a new view (and assorted problems
when resizing the display). Since the last version of the series,
what was previously the second (and last) patch has been split in
two patches, the first of which only concerns itself with rangeset
allocation / deallocation / initialization.

The first patch propagates ept.ad changes to all active altp2ms,
the second one allocates and initializes a new logdirty rangeset for
each new altp2m, and the third propagates (under lock) changes to all
p2ms.

[PATCH V3 1/3] x86/altp2m: propagate ept.ad changes to all active altp2ms
[PATCH V3 2/3] x86/mm: allocate logdirty_ranges for altp2ms
[PATCH V3 3/3] x86/altp2m: fix display frozen when switching to a new view early


Thanks,
Razvan

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

[Xen-devel] [PATCH V3 1/3] x86/altp2m: propagate ept.ad changes to all active altp2ms

[Razvan Cojocaru]

This patch is a pre-requisite for fixing the logdirty VGA issue
(display freezes when switching to a new altp2m view early in a
domain's lifetime), but sent separately for easier review.
The new ept_set_ad_sync() function has been added to update all
active altp2ms' ept.ad. New altp2ms will inherit the hostp2m's
ept.ad value.

Signed-off-by: Razvan Cojocaru 
Suggested-by: George Dunlap 

---
CC: Jun Nakajima 
CC: Kevin Tian 
CC: George Dunlap 
CC: Jan Beulich 
CC: Andrew Cooper 
CC: Wei Liu 
---
 xen/arch/x86/mm/p2m-ept.c | 57 +++
 xen/arch/x86/mm/p2m.c |  8 ---
 2 files changed, 53 insertions(+), 12 deletions(-)

diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index 407e299..fabcd06 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -17,6 +17,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1222,6 +1223,34 @@ static void ept_tlb_flush(struct p2m_domain *p2m)
 ept_sync_domain_mask(p2m, p2m->domain->dirty_cpumask);
 }
 
+static void ept_set_ad_sync(struct domain *d, bool value)
+{
+struct p2m_domain *hostp2m = p2m_get_hostp2m(d);
+
+ASSERT(p2m_locked_by_me(hostp2m));
+
+hostp2m->ept.ad = value;
+
+if ( unlikely(altp2m_active(d)) )
+{
+unsigned int i;
+
+for ( i = 0; i < MAX_ALTP2M; i++ )
+{
+struct p2m_domain *p2m;
+
+if ( d->arch.altp2m_eptp[i] == mfn_x(INVALID_MFN) )
+continue;
+
+p2m = d->arch.altp2m_p2m[i];
+
+p2m_lock(p2m);
+p2m->ept.ad = value;
+p2m_unlock(p2m);
+}
+}
+}
+
 static void ept_enable_pml(struct p2m_domain *p2m)
 {
 /* Domain must have been paused */
@@ -1236,7 +1265,7 @@ static void ept_enable_pml(struct p2m_domain *p2m)
 return;
 
 /* Enable EPT A/D bit for PML */
-p2m->ept.ad = 1;
+ept_set_ad_sync(p2m->domain, true);
 vmx_domain_update_eptp(p2m->domain);
 }
 
@@ -1248,10 +1277,28 @@ static void ept_disable_pml(struct p2m_domain *p2m)
 vmx_domain_disable_pml(p2m->domain);
 
 /* Disable EPT A/D bit */
-p2m->ept.ad = 0;
+ept_set_ad_sync(p2m->domain, false);
 vmx_domain_update_eptp(p2m->domain);
 }
 
+static void ept_enable_hardware_log_dirty(struct p2m_domain *p2m)
+{
+struct p2m_domain *hostp2m = p2m_get_hostp2m(p2m->domain);
+
+p2m_lock(hostp2m);
+ept_enable_pml(hostp2m);
+p2m_unlock(hostp2m);
+}
+
+static void ept_disable_hardware_log_dirty(struct p2m_domain *p2m)
+{
+struct p2m_domain *hostp2m = p2m_get_hostp2m(p2m->domain);
+
+p2m_lock(hostp2m);
+ept_disable_pml(hostp2m);
+p2m_unlock(hostp2m);
+}
+
 static void ept_flush_pml_buffers(struct p2m_domain *p2m)
 {
 /* Domain must have been paused */
@@ -1281,8 +1328,8 @@ int ept_p2m_init(struct p2m_domain *p2m)
 
 if ( cpu_has_vmx_pml )
 {
-p2m->enable_hardware_log_dirty = ept_enable_pml;
-p2m->disable_hardware_log_dirty = ept_disable_pml;
+p2m->enable_hardware_log_dirty = ept_enable_hardware_log_dirty;
+p2m->disable_hardware_log_dirty = ept_disable_hardware_log_dirty;
 p2m->flush_hardware_cached_dirty = ept_flush_pml_buffers;
 }
 
@@ -1390,8 +1437,10 @@ void setup_ept_dump(void)
 void p2m_init_altp2m_ept(struct domain *d, unsigned int i)
 {
 struct p2m_domain *p2m = d->arch.altp2m_p2m[i];
+struct p2m_domain *hostp2m = p2m_get_hostp2m(d);
 struct ept_data *ept;
 
+p2m->ept.ad = hostp2m->ept.ad;
 p2m->min_remapped_gfn = gfn_x(INVALID_GFN);
 p2m->max_remapped_gfn = 0;
 ept = >ept;
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index a00a3c1..42b9ef4 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -360,11 +360,7 @@ void p2m_enable_hardware_log_dirty(struct domain *d)
 struct p2m_domain *p2m = p2m_get_hostp2m(d);
 
 if ( p2m->enable_hardware_log_dirty )
-{
-p2m_lock(p2m);
 p2m->enable_hardware_log_dirty(p2m);
-p2m_unlock(p2m);
-}
 }
 
 void p2m_disable_hardware_log_dirty(struct domain *d)
@@ -372,11 +368,7 @@ void p2m_disable_hardware_log_dirty(struct domain *d)
 struct p2m_domain *p2m = p2m_get_hostp2m(d);
 
 if ( p2m->disable_hardware_log_dirty )
-{
-p2m_lock(p2m);
 p2m->disable_hardware_log_dirty(p2m);
-p2m_unlock(p2m);
-}
 }
 
 void p2m_flush_hardware_cached_dirty(struct domain *d)
-- 
2.7.4


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

Re: [Xen-devel] Xen optimization

[Milan Boberic]

Sorry for late reply,

> I am afraid no. .config is generated during building time. So can you
> paste here please.


".config" file is in attachment.

I also tried Xen 4.9 and I got almost same numbers, jitter is smaller
by 150ns which isn't significant change at all.

Milan
#
# Automatically generated file; DO NOT EDIT.
# Xen/arm 4.11.1-pre Configuration
#
CONFIG_64BIT=y
CONFIG_ARM_64=y
CONFIG_ARM=y
CONFIG_ARCH_DEFCONFIG="arch/arm/configs/arm64_defconfig"

#
# Architecture Features
#
CONFIG_NR_CPUS=128
# CONFIG_ACPI is not set
CONFIG_GICV3=y
# CONFIG_HAS_ITS is not set
# CONFIG_NEW_VGIC is not set
CONFIG_SBSA_VUART_CONSOLE=y

#
# ARM errata workaround via the alternative framework
#
CONFIG_ARM64_ERRATUM_827319=y
CONFIG_ARM64_ERRATUM_824069=y
CONFIG_ARM64_ERRATUM_819472=y
CONFIG_ARM64_ERRATUM_832075=y
CONFIG_ARM64_ERRATUM_834220=y
CONFIG_HARDEN_BRANCH_PREDICTOR=y
CONFIG_ARM64_HARDEN_BRANCH_PREDICTOR=y
CONFIG_ALL_PLAT=y
# CONFIG_QEMU is not set
# CONFIG_RCAR3 is not set
# CONFIG_MPSOC is not set
CONFIG_ALL64_PLAT=y
# CONFIG_ALL32_PLAT is not set
CONFIG_MPSOC_PLATFORM=y

#
# Common Features
#
CONFIG_HAS_ALTERNATIVE=y
CONFIG_HAS_DEVICE_TREE=y
# CONFIG_MEM_ACCESS is not set
CONFIG_HAS_PDX=y
CONFIG_TMEM=y
# CONFIG_XSM is not set

#
# Schedulers
#
CONFIG_SCHED_CREDIT=y
CONFIG_SCHED_CREDIT2=y
CONFIG_SCHED_RTDS=y
# CONFIG_SCHED_ARINC653 is not set
CONFIG_SCHED_NULL=y
CONFIG_SCHED_CREDIT_DEFAULT=y
# CONFIG_SCHED_CREDIT2_DEFAULT is not set
# CONFIG_SCHED_RTDS_DEFAULT is not set
# CONFIG_SCHED_NULL_DEFAULT is not set
CONFIG_SCHED_DEFAULT="credit"
# CONFIG_LIVEPATCH is not set
CONFIG_SUPPRESS_DUPLICATE_SYMBOL_WARNINGS=y
CONFIG_CMDLINE=""

#
# Device Drivers
#
CONFIG_HAS_NS16550=y
CONFIG_HAS_CADENCE_UART=y
CONFIG_HAS_MVEBU=y
CONFIG_HAS_PL011=y
CONFIG_HAS_SCIF=y
CONFIG_HAS_PASSTHROUGH=y
CONFIG_ARM_SMMU=y
CONFIG_VIDEO=y
CONFIG_HAS_ARM_HDLCD=y
CONFIG_DEFCONFIG_LIST="$ARCH_DEFCONFIG"

#
# Debugging Options
#
# CONFIG_DEBUG is not set
# CONFIG_FRAME_POINTER is not set
# CONFIG_COVERAGE is not set
# CONFIG_LOCK_PROFILE is not set
# CONFIG_PERF_COUNTERS is not set
# CONFIG_VERBOSE_DEBUG is not set
# CONFIG_DEVICE_TREE_DEBUG is not set
# CONFIG_SCRUB_DEBUG is not set___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] x86/domain: Fix build with GCC 4.3.x

[Jan Beulich]

>>> On 29.10.18 at 12:53,  wrote:
> On Mon, Oct 29, 2018 at 11:52:08AM +, Andrew Cooper wrote:
>> GCC 4.3.x can't initialise the user_regs structure like this.
>> 
>> Reported-by: Jan Beulich 
>> Signed-off-by: Andrew Cooper 
> 
> Reviewed-by: Wei Liu 

Acked-by: Jan Beulich 




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

Re: [Xen-devel] [PATCH v5 05/25] xen/arm: check for multiboot nodes only under /chosen

[Julien Grall]

Hi Stefano,

On 10/27/18 1:42 AM, Stefano Stabellini wrote:

On Fri, 26 Oct 2018, Julien Grall wrote:

On 10/26/18 10:27 PM, Julien Grall wrote:

Hi,

On 10/26/18 10:12 PM, Stefano Stabellini wrote:

On Fri, 26 Oct 2018, Julien Grall wrote:

Hi Stefano,

On 10/23/18 3:02 AM, Stefano Stabellini wrote:

Make sure to only look for multiboot compatible nodes only under
/chosen, not under any other paths (depth <= 3).

Signed-off-by: Stefano Stabellini 

---

Changes in v5:
- add patch
- add check on return value of fdt_get_path
---
    xen/arch/arm/bootfdt.c | 13 ++---
    1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index 8eba42c..a314aca 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -173,7 +173,14 @@ static void __init process_multiboot_node(const
void
*fdt, int node,
    bootmodule_kind kind;
    paddr_t start, size;
    const char *cmdline;
-    int len;
+    int len = sizeof("/chosen");


NIT, I am not convince you win anything with that trick. strlen could be
optimized by the compiler (we use __builtin_strlen on Arm64).


I could use strlen if you prefer, but given that the string is known at
compile time, it should hopefully be resolved to "8" at compile time
using sizeof. What's wrong with it?


__builtin_strlen should get optimized at compile-time. Although, I don't
seem to be the case when I tried. Not sure why.

Never mind then.


Actually I just tried to use __builtin_stlren rather than strlen. And
GCC is computing the size at compiler time.

Somehow, I thought arm64 was using __builtin_strlen but it seems to implement
there own. Most likely we would want to use __builtin_strlen wor constant
string. But that's another story.

In that case, I would prefer if you use __builtin_strlen. This is easier to
understand over sizeof.


sizeof should be easier than __builtin_strlen for most: sizeof is part
of the C language, and it is taught in C classes. I expect everybody
should know what it is. While __builtin_strlen is a compiler construct,
which is certainly not for beginners. I think it is strange you find it
easier, probably a side of effect of years of Xen/kernel programming :-)


I think it is pretty much the invert :). When I see "strlen" in the name 
I can imagine what you are trying to achieve. I.e computing the length 
of the string. If it has __builtin, my,... in front it just tells you 
that it is a different implementation.


Sizeof takes a bit more time because you have to wonder why strlen is 
not "suitable" here.


To be honest, this is a micro-optimization. It is very likely not going 
to make Xen booting much faster as that function might just get called 
~30 times at most.




I would rather keep it as is.


Then please stay consistent. You hardcode the value in one place, and 
the other you use sizeof("/chosen"). Either way works for me.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 1/4] xen/arm: gic: Ensure we have an ISB between ack and do_IRQ()

[Julien Grall]

On 10/27/18 1:14 PM, Andrii Anisov wrote:

Hello Julien,


On 10/27/2018 12:55 AM, Julien Grall wrote:
The functions below does not exist in latest Xen. So are you sure this 
based on mainline?


Yep, I've put a wrong diff into the email, it is for XEN 4.10.
Please find the patch for XEN 4.12-unstable on my github [1].


How many domain do you have run at that time?

Only one domain. In my setup I'm running a BSP release under XEN as Dom0.


Under which condition this is hapenning?
Under no specific conditions. During the system boot, during console 
operations, during glmark2 [2] running.


So the glmark2 is running in Dom0, am I correct?




Also, what is your Xen command line?
`dom0_mem=1G console=dtuart dtuart=serial0 dom0_max_vcpus=4 bootscrub=0 
loglvl=all cpufreq=none`


I assume you didn't disable serrors, right? So we should have plenty 
of dsb(sy) and isb() in the path to there.

I didn't disable serrors.


So I would rule out a missing barrier here.








Those prints I treat as LR content change (state PENDING->INVALID)
without exiting from hyp to guest. Unfortunately, I did not find a kind
of explanation to this effect in ARM IHI 0048B.b document.
I have GICv2 on the die.

I appreciate you find some time to look at this and express your 
opinion.



---

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 511c8d7..0b9aa2d 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -171,6 +171,14 @@ static unsigned int gicv2_cpu_mask(const cpumask_t
*cpumask)
   return mask;
   }

+static void gicv2_store_lrs(void)
+{
+    int i;
+
+    for ( i = 0; i < gicv2_info.nr_lrs; i++ )
+    current->arch.gic.v2.lr[i] = readl_gich(GICH_LR + i * 4);
+}
+
   static void gicv2_save_state(struct vcpu *v)
   {
   int i;
@@ -446,11 +454,13 @@ static void gicv2_update_lr(int lr, const struct
pending_irq *p,
      << GICH_V2_LR_PHYSICAL_SHIFT);

   writel_gich(lr_reg, GICH_LR + lr * 4);
+    current->arch.gic.v2.lr[lr] = lr_reg;
   }

   static void gicv2_clear_lr(int lr)
   {
   writel_gich(0, GICH_LR + lr * 4);
+    current->arch.gic.v2.lr[lr] = 0;
   }

   static void gicv2_read_lr(int lr, struct gic_lr *lr_reg)
@@ -458,6 +468,9 @@ static void gicv2_read_lr(int lr, struct gic_lr 
*lr_reg)

   uint32_t lrv;

   lrv  = readl_gich(GICH_LR + lr * 4);
+    if ( lrv != current->arch.gic.v2.lr[lr])
+    printk("Stored LR is stale: stored 0x%"PRIX32" read 
0x%"PRIX32"\n",

+   current->arch.gic.v2.lr[lr], lrv);
   lr_reg->pirq = (lrv >> GICH_V2_LR_PHYSICAL_SHIFT) &
GICH_V2_LR_PHYSICAL_MASK;
   lr_reg->virq = (lrv >> GICH_V2_LR_VIRTUAL_SHIFT) &
GICH_V2_LR_VIRTUAL_MASK;
   lr_reg->priority = (lrv >> GICH_V2_LR_PRIORITY_SHIFT) &
GICH_V2_LR_PRIORITY_MASK;
@@ -481,6 +494,7 @@ static void gicv2_write_lr(int lr, const struct
gic_lr *lr_reg)
     ((uint32_t)(lr_reg->grp & GICH_V2_LR_GRP_MASK) <<
GICH_V2_LR_GRP_SHIFT) );

   writel_gich(lrv, GICH_LR + lr * 4);
+    current->arch.gic.v2.lr[lr] = lrv;
   }

   static void gicv2_hcr_status(uint32_t flag, bool status)
@@ -1232,6 +1246,7 @@ const static struct gic_hw_operations gicv2_ops 
= {

   .info    = _info,
   .init    = gicv2_init,
   .secondary_init  = gicv2_secondary_cpu_init,
+    .store_lrs   = gicv2_store_lrs,
   .save_state  = gicv2_save_state,
   .restore_state   = gicv2_restore_state,
   .dump_state  = gicv2_dump_state,
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index ed363f6..a05c518 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -594,6 +594,12 @@ static void gic_update_one_lr(struct vcpu *v, 
int i)

   }
   }

+void gic_store_lrs(void)
+{
+    if(gic_hw_ops->store_lrs)
+    gic_hw_ops->store_lrs();
+}
+
   void gic_clear_lrs(struct vcpu *v)
   {
   int i = 0;
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index f6f6de3..985192b 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2095,6 +2095,7 @@ static void enter_hypervisor_head(struct
cpu_user_regs *regs)
   if ( current->arch.hcr_el2 & HCR_VA )
   current->arch.hcr_el2 = READ_SYSREG(HCR_EL2);

+    gic_store_lrs();


gic_clear_lrs(...) may rewrite the LRs. To confirm this stall LRs are 
not due by this function, can you move that after gic_clear_lrs()?
Right you are, gic_clear_lrs(), in 4.10 codebase, rewrites LRs. But it 
does not change PENDING to INVALID under no circumstances from one hand. 
From another hand, all changes to LRs are made through gic specific 
operations gic_hw_ops->... which are tracked by me. You can see, in the 
code above, that I copy all updates to the physical LR issued by 
hypervisor into the stored LRs. So it not the case. But I'll check on 
Monday.


Ah, I missed the part where you updated the LRs.

While the interrupt exception path does not re-enable interrupts early. 
Other traps may do 

Re: [Xen-devel] [PULL 00/20] Trivial patches patches

[Peter Maydell]

On 26 October 2018 at 16:31, Laurent Vivier  wrote:
> The following changes since commit 808ebd66e467f77c0d1f8c6346235f81e9c99cf2:
>
>   Merge remote-tracking branch 'remotes/riscv/tags/riscv-for-master-3.1-sf0' 
> into staging (2018-10-25 17:41:03 +0100)
>
> are available in the Git repository at:
>
>   git://github.com/vivier/qemu.git tags/trivial-patches-pull-request
>
> for you to fetch changes up to 4b03da6e87c34793137a231b558231fd406c05e8:
>
>   ppc: move at24c to its own CONFIG_ symbol (2018-10-26 17:17:32 +0200)
>
> 
> QEMU trivial patches collected between June and October 2018
> (Thank you to Thomas Huth)
>
> 

Hi; I get a compile error due to a format string issue:

In file included from
/home/petmay01/qemu-for-merges/hw/net/milkymist-minimac2.c:33:0:
/home/petmay01/qemu-for-merges/hw/net/milkymist-minimac2.c: In
function 'minimac2_write':
/home/petmay01/qemu-for-merges/hw/net/milkymist-minimac2.c:420:23:
error: format '%lx' expects
 argument of type 'long unsigned int', but argument 4 has type
'uint64_t {aka long long unsign
ed int}' [-Werror=format=]
   "milkymist_minimac2_wr%d: 0x%" HWADDR_PRIx " = 0x%lx\n",
   ^
/home/petmay01/qemu-for-merges/include/qemu/log.h:85:22: note: in
definition of macro 'qemu_lo
g_mask'
 qemu_log(FMT, ## __VA_ARGS__);  \
  ^
cc1: all warnings being treated as errors

(affects windows crossbuilds, OSX and 32-bit hosts).

thanks
-- PMM

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

Re: [Xen-devel] [PATCH] x86/domain: Fix build with GCC 4.3.x

[Wei Liu]

On Mon, Oct 29, 2018 at 11:52:08AM +, Andrew Cooper wrote:
> GCC 4.3.x can't initialise the user_regs structure like this.
> 
> Reported-by: Jan Beulich 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Wei Liu 

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

[Xen-devel] [PATCH] x86/domain: Fix build with GCC 4.3.x

[Andrew Cooper]

GCC 4.3.x can't initialise the user_regs structure like this.

Reported-by: Jan Beulich 
Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
---
 xen/arch/x86/domain.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index d63b71c..19692e2 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -326,9 +326,8 @@ void free_vcpu_struct(struct vcpu *v)
 /* Initialise various registers to their architectural INIT/RESET state. */
 void arch_vcpu_regs_init(struct vcpu *v)
 {
-v->arch.user_regs = (typeof(v->arch.user_regs)){
-.rflags = X86_EFLAGS_MBS,
-};
+memset(>arch.user_regs, 0, sizeof(v->arch.user_regs));
+v->arch.user_regs.eflags = X86_EFLAGS_MBS;
 
 memset(v->arch.debugreg, 0, sizeof(v->arch.debugreg));
 v->arch.debugreg[6] = X86_DR6_DEFAULT;
-- 
2.1.4


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

Re: [Xen-devel] Interrupt injection with ISR set on Intel hardware

[Roger Pau Monné]

On Mon, Oct 22, 2018 at 03:33:07PM +0800, Chao Gao wrote:
> Hi, Roger, Andrew and Wei,
> 
> Jan's patch
> (https://lists.xen.org/archives/html/xen-devel/2018-10/msg01031.html)
> fixs an issue in handling SVI. Currently, when dealing with EOI from guest, 
> the
> SVI was cleared. But the correct way is clearing the corresponding bit in VISR
> and then setting SVI to the highest index of bit set in VISR (please refer to
> SDM 29.1.4). If SVI is set to a value lower than the vector of the highest
> priority interrupt that is in service, the PPR virtualization (29.1.3) might
> set the VPPR to a lower value on VMEntry too. Thus an interrupt with same or
> lower priority, which should be blocked by VPPR, slips in.

AFAICT the patch is for the emulated lapic, and the issue we are
seeing here is with the hardware lapic.

> Could you apply Jan's patch and try to reproduce it again?

I've applied Jan's patch and I'm still able to reproduce the issue.

Thanks, Roger.

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

Re: [Xen-devel] [PATCH v4 01/12] x86: infrastructure to allow converting certain indirect calls to direct ones

[Jan Beulich]

>>> On 03.10.18 at 20:38,  wrote:
> Reviewing just the code generation at this point.

Thanks for having found the time.

> See the Linux source code for ASM_CALL_CONSTRAINT.  There is a potential
> code generation issue if you've got a call instruction inside an asm
> block if you don't list the stack pointer as a clobbered output.

I'll look into this, but to be honest I don't always trust the Linux
folks in such regards. Plus doesn't this consideration come a little
late, seeing that we already have inline asm()-s inserting CALLs
(see e.g. asm-x86/guest/hypercall.h)?

> Next, with Clang, there seems to be some a bug causing the function
> pointer to be spilled onto the stack
> 
> 82d08026e990 :
> 82d08026e990:   50  push   %rax
> 82d08026e991:   48 8b 05 40 bc 20 00mov0x20bc40(%rip),%rax   
>  # 82d08047a5d8 
> 82d08026e998:   48 89 04 24 mov%rax,(%rsp)
> 82d08026e99c:   ff 15 36 bc 20 00   callq  *0x20bc36(%rip)   
>  # 82d08047a5d8 
> 82d08026e9a2:   31 c0   xor%eax,%eax
> 82d08026e9a4:   59  pop%rcx
> 82d08026e9a5:   c3  retq   
> 82d08026e9a6:   66 2e 0f 1f 84 00 00nopw   %cs:0x0(%rax,%rax,1)
> 82d08026e9ad:   00 00 00 
> 
> 
> I'm not quite sure what is going on here, and the binary does boot, but
> the code gen is definitely not correct.

What's not correct here? There's just some pointless extra code
the compiler produces.

>  Given this and the GCC bugs
> you've found leading to the NO_ARG infrastructure, how about dropping
> all the compatibility hacks, and making the infrastructure fall back to
> a regular compiler-inserted function pointer call?

Well, if there were multiple issues left, I'd view this as an option.
But there's just one ugly workaround in this version, in
"x86/genapic: patch indirect calls to direct ones", and that even affects
gcc 8. So on the whole I'd rather not go this route.

> Next, the ASM'd calls aren't SYSV-ABI compliant.
> 
> extern void bar(void);
> 
> int foo1(void)
> {
> hvm_funcs.wbinvd_intercept();
> return 0;
> }
> 
> int foo2(void)
> {
> alternative_vcall(hvm_funcs.wbinvd_intercept);
> return 0;
> }
> 
> int bar1(void)
> {
> bar();
> return 0;
> }
> 
> 82d08026e1e0 :
> 82d08026e1e0:   48 83 ec 08 sub$0x8,%rsp
> 82d08026e1e4:   48 8b 05 c5 49 1d 00mov0x1d49c5(%rip),%rax   
>  # 82d080442bb0 
> 82d08026e1eb:   e8 30 2d 0f 00  callq  82d080360f20 
> <__x86_indirect_thunk_rax>
> 82d08026e1f0:   31 c0   xor%eax,%eax
> 82d08026e1f2:   48 83 c4 08 add$0x8,%rsp
> 82d08026e1f6:   c3  retq   
> 82d08026e1f7:   66 0f 1f 84 00 00 00nopw   0x0(%rax,%rax,1)
> 82d08026e1fe:   00 00 
> 
> 82d08026e200 :
> 82d08026e200:   ff 15 aa 49 1d 00   callq  *0x1d49aa(%rip)   
>  # 82d080442bb0 
> 82d08026e206:   31 c0   xor%eax,%eax
> 82d08026e208:   c3  retq   
> 82d08026e209:   0f 1f 80 00 00 00 00nopl   0x0(%rax)
> 
> 82d08026e210 :
> 82d08026e210:   48 83 ec 08 sub$0x8,%rsp
> 82d08026e214:   e8 17 18 01 00  callq  82d08027fa30 
> 82d08026e219:   31 c0   xor%eax,%eax
> 82d08026e21b:   48 83 c4 08 add$0x8,%rsp
> 82d08026e21f:   c3  retq   
> 
> foo2 which uses alternative_vcall() should be subtracting 8 from the
> stack pointer before the emitted call instruction.  I can't find any set
> of constraints which causes the stack to be set up correctly.

I think I have an idea how to arrange for this (adding an artificial
extra constraint referencing a local variable requiring 16-byte
alignment; ideally the variable would itself be zero size), but I've
yet to try it out. The question though is if we really need this
ABI compliance here. Recall that for years we've been running
with mis-aligned stacks, and only EFI runtime call issues required
us to address this. There are no EFI runtime calls behind any of
the (to be) patched calls.

I was in fact considering the opposite thing: Use (on new enough
gcc) the command line option to reduce stack alignment to 8 bytes
in general, enforcing 16-byte alignment only where we really need
it.

Jan


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

[Xen-devel] [PATCH v1] x86/hvm: Clean up the rest of bool_t from vm_event

[Alexandru Stefan ISAILA]

Signed-off-by: Alexandru Isaila 
---
 xen/arch/x86/hvm/hvm.c| 2 +-
 xen/arch/x86/mm/mem_sharing.c | 2 +-
 xen/arch/x86/mm/p2m.c | 4 ++--
 xen/common/memory.c   | 2 +-
 xen/common/vm_event.c | 4 ++--
 xen/include/asm-x86/mem_sharing.h | 2 +-
 xen/include/xen/vm_event.h| 8 
 7 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index a140e60c9c..3a1d8ce279 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1905,7 +1905,7 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned long 
gla,
 if ( sharing_enomem )
 {
 int rv;
-if ( (rv = mem_sharing_notify_enomem(currd, gfn, 1)) < 0 )
+if ( (rv = mem_sharing_notify_enomem(currd, gfn, true)) < 0 )
 {
 gdprintk(XENLOG_ERR, "Domain %hu attempt to unshare "
  "gfn %lx, ENOMEM and no helper (rc %d)\n",
diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index 1dab2c8cc3..be09c8871a 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -546,7 +546,7 @@ static int audit(void)
 }
 
 int mem_sharing_notify_enomem(struct domain *d, unsigned long gfn,
-bool_t allow_sleep) 
+  bool allow_sleep)
 {
 struct vcpu *v = current;
 int rc;
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index a00a3c1bff..cbd9bac6a1 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -448,7 +448,7 @@ mfn_t __get_gfn_type_access(struct p2m_domain *p2m, 
unsigned long gfn_l,
 /* Try to unshare. If we fail, communicate ENOMEM without
  * sleeping. */
 if ( mem_sharing_unshare_page(p2m->domain, gfn_l, 0) < 0 )
-(void)mem_sharing_notify_enomem(p2m->domain, gfn_l, 0);
+(void)mem_sharing_notify_enomem(p2m->domain, gfn_l, false);
 mfn = p2m->get_entry(p2m, gfn, t, a, q, page_order, NULL);
 }
 
@@ -840,7 +840,7 @@ guest_physmap_add_entry(struct domain *d, gfn_t gfn, mfn_t 
mfn,
  * won't go to sleep. */
 (void)mem_sharing_notify_enomem(p2m->domain,
 gfn_x(gfn_add(gfn, i)),
-0);
+false);
 return rc;
 }
 omfn = p2m->get_entry(p2m, gfn_add(gfn, i),
diff --git a/xen/common/memory.c b/xen/common/memory.c
index 987395fbb3..5676740973 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -356,7 +356,7 @@ int guest_remove_page(struct domain *d, unsigned long gmfn)
 rc = mem_sharing_unshare_page(d, gmfn, 0);
 if ( rc )
 {
-(void)mem_sharing_notify_enomem(d, gmfn, 0);
+(void)mem_sharing_notify_enomem(d, gmfn, false);
 goto out_put_gfn;
 }
 /* Maybe the mfn changed */
diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
index 6ffd18a448..26cfa2c605 100644
--- a/xen/common/vm_event.c
+++ b/xen/common/vm_event.c
@@ -496,7 +496,7 @@ static int vm_event_wait_slot(struct vm_event_domain *ved)
 return rc;
 }
 
-bool_t vm_event_check_ring(struct vm_event_domain *ved)
+bool vm_event_check_ring(struct vm_event_domain *ved)
 {
 return (ved && ved->ring_page);
 }
@@ -514,7 +514,7 @@ bool_t vm_event_check_ring(struct vm_event_domain *ved)
  *
  */
 int __vm_event_claim_slot(struct domain *d, struct vm_event_domain *ved,
-  bool_t allow_sleep)
+  bool allow_sleep)
 {
 if ( !vm_event_check_ring(ved) )
 return -EOPNOTSUPP;
diff --git a/xen/include/asm-x86/mem_sharing.h 
b/xen/include/asm-x86/mem_sharing.h
index 91908924df..0e77b7d935 100644
--- a/xen/include/asm-x86/mem_sharing.h
+++ b/xen/include/asm-x86/mem_sharing.h
@@ -84,7 +84,7 @@ static inline int mem_sharing_unshare_page(struct domain *d,
  * then it's the same as a foreign domain.
  */
 int mem_sharing_notify_enomem(struct domain *d, unsigned long gfn,
-bool_t allow_sleep);
+  bool allow_sleep);
 int mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg);
 int mem_sharing_domctl(struct domain *d, 
struct xen_domctl_mem_sharing_op *mec);
diff --git a/xen/include/xen/vm_event.h b/xen/include/xen/vm_event.h
index 2ff6e1c333..5302ee55c1 100644
--- a/xen/include/xen/vm_event.h
+++ b/xen/include/xen/vm_event.h
@@ -30,7 +30,7 @@
 void vm_event_cleanup(struct domain *d);
 
 /* Returns whether a ring has been set up */
-bool_t vm_event_check_ring(struct vm_event_domain *ved);
+bool vm_event_check_ring(struct vm_event_domain *ved);
 
 /* Returns 0 on success, -ENOSYS if there is no ring, -EBUSY if there is no
  * available space and the caller is a foreign domain. If the guest itself
@@ -46,17 +46,17 @@ bool_t 

[Xen-devel] [ovmf test] 129125: all pass - PUSHED

[osstest service owner]

flight 129125 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129125/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf c09b254bdc6050cc8b580a26558f692f958645d6
baseline version:
 ovmf 2f6693c283b54666def65e5e0d0b84e48b21cfef

Last test of basis   129113  2018-10-29 00:40:55 Z0 days
Testing same since   129121  2018-10-29 03:41:45 Z0 days2 attempts


People who touched revisions under test:
  Chasel Chiu 
  Chasel, Chiu 
  Ruiyu Ni 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   2f6693c283..c09b254bdc  c09b254bdc6050cc8b580a26558f692f958645d6 -> 
xen-tested-master

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

Re: [Xen-devel] Ping: Re: Flask default policy mismatch vs dummy

[Jan Beulich]

>>> On 26.10.18 at 23:41,  wrote:
>>  -Original Message-
>> From: Jan Beulich 
>> Sent: Friday, October 26, 2018 7:16 AM
>> To: Daniel de Graaf 
>> Cc: Andrew Cooper ; xen-de...@lists.xen.org 
>> Subject: [Non-DoD Source] Ping: Re: Flask default policy mismatch vs dummy
>> 
>> >>> On 11.10.18 at 13:40,  wrote:
>>  On 11.10.18 at 10:05,  wrote:
>> >> Found while looking at some OSSTest logs.
>> >>
>> >> Oct  9 14:03:09.579037 (XEN) avc:  denied  { setup } for domid=0
>> >> scontext=system_u:system_r:dom0_t tcontext=system_u:system_r:xen_t
>> >> tclass=resource
>> >> Oct  9 14:03:09.590863 [0.522193] Failed to report MMCONFIG 
>> >> reservation
>> >> state for PCI MMCONFIG  [bus 00-7f] to hypervisor (-13)
>> >>
>> >> If someone has some tuits, please feel free.  If not, I'll see what I
>> >> can do when I've got some time.
>> >
>> > How about this?
>> >
>> > Jan
>> 
>> Daniel, do you have any thoughts here?
>> 
>> Thanks, Jan
> 
> This looks like a missing allow rule in the policy for dom0; something like:
> 
> allow dom0_t xen_t: resource setup;
> 
> in dom0.te at the end near the admin_device() statements.  I'm not at my 
> Linux system at the moment, otherwise I'd make a patch.

Okay, if the adjustment is to be in the rules, then I'll leave it
to you (or anyone else who wants to pick it up).

Jan



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

Re: [Xen-devel] [PATCH v2 2/5] x86/domain: Initialise vcpu debug registers correctly

[Jan Beulich]

>>> On 26.10.18 at 17:58,  wrote:
> On 26/10/2018 16:01, Jan Beulich wrote:
> On 26.10.18 at 16:51,  wrote:
>>> On 26/10/2018 15:37, Jan Beulich wrote:
>>> On 26.10.18 at 16:22,  wrote:
> On 26/10/2018 14:31, Jan Beulich wrote:
> On 15.10.18 at 12:36,  wrote:
>>> --- a/xen/arch/x86/domain.c
>>> +++ b/xen/arch/x86/domain.c
>>> @@ -323,6 +323,18 @@ void free_vcpu_struct(struct vcpu *v)
>>>  free_xenheap_page(v);
>>>  }
>>>  
>>> +/* Initialise various registers to their architectural INIT/RESET 
>>> state. */
>>> +void arch_vcpu_regs_init(struct vcpu *v)
>>> +{
>>> +v->arch.user_regs = (typeof(v->arch.user_regs)){
>>> +.rflags = X86_EFLAGS_MBS,
>>> +};
>> Sadly this initializer broke the build once again for gcc 4.3.x.
> Oh - that's unfortunate.  I guess it will need a memset instead.
 Or we finally need to bump the minimum version we're happy with.

>> (As a side note, using .eflags instead of .rflags would have a
>> fair chance of an omitted REX prefix.)
> You specifically requested rflags over eflags in your previous review.
 Did I? I haven't been able to find v1 of this patch at all in the archives
 (going back to May), or in my inbox (using just part of the title for
 searching). Was that posted in private, or under a different title? I'm
 trying to figure why I would have asked for that...
>>> <5b17e80a0278001c8...@prv1-mh.provo.novell.com>
>> Hmm, yes, except that my mail client doesn't allow me to search for
>> mail IDs, or at least I don't know how I would do that. You don't
>> happen to have title, time stamp, or mail archive ref?
> 
> "Re: [PATCH 03/11] x86: Initialise debug registers correctly", sent
> 06/06/2018, 14:56

Ah, thanks, now I see. In that earlier patch the context did not
have (in hvm_vcpu_reset_state()) both lines

memset(>arch.user_regs, 0, sizeof(v->arch.user_regs));
v->arch.user_regs.rflags = X86_EFLAGS_MBS;

and hence I was assuming that the clearing of the high half here
was necessary. (I should have looked at the source instead of
just going from patch context, I admit.) With the memset(), the
use or .rflags was clearly not necessary (and isn't in this new
version of the patch). Anyway - I'd prefer if you used .eflags,
but I'm not going to make this a requirement.

Jan



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

Re: [Xen-devel] [PATCH 5/5] RFC: test/depriv: Add a tool to check process-level depriv

[Ian Jackson]

George Dunlap writes ("Re: [PATCH 5/5] RFC: test/depriv: Add a tool to check 
process-level depriv"):
> Oh, actually, 65534 is "nogroup", which is the default when you don't
> add a specific group.
> 
> Should we recommend creating a separate group for the Xen qemus in our
> feature doc?  Or should we just mention the possibility, but leave the
> actual example to the default (which will normally end up with the
> `nogroup` group)?

`nogroup' isn't as big a problem in general as `nobody'.  (No
processes may ever run as nobody because to avoid unintendedly
permitting access, such a non-id must either have no principals or no
objects, and a process running with a particular uid is both; whereas
running as a particular group does not turn a process into an object
accessible via that group.)

But it's still probably best avoided in case of mistakes.  Also
assigning a group to all the qemus may make some kinds of
configuration applicable to all of them easier.

So I think we should recommend creating one group for this.

Ian.

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

Re: [Xen-devel] [PATCH 1/4] xen/arm: gic: Ensure we have an ISB between ack and do_IRQ()

[Andrii Anisov]

Hello Julien,


Sorry for the previous email sent as html.


On 27.10.18 15:14, Andrii Anisov wrote:
>>> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
>>> index f6f6de3..985192b 100644
>>> --- a/xen/arch/arm/traps.c
>>> +++ b/xen/arch/arm/traps.c
>>> @@ -2095,6 +2095,7 @@ static void enter_hypervisor_head(struct
>>> cpu_user_regs *regs)
>>>    if ( current->arch.hcr_el2 & HCR_VA )
>>>    current->arch.hcr_el2 = READ_SYSREG(HCR_EL2);
>>>
>>> +    gic_store_lrs();
>>
>> gic_clear_lrs(...) may rewrite the LRs. To confirm this stall LRs are 
>> not due by this function, can you move that after gic_clear_lrs()?
> Right you are, gic_clear_lrs(), in 4.10 codebase, rewrites LRs. But it 
> does not change PENDING to INVALID under no circumstances from one 
> hand. From another hand, all changes to LRs are made through gic 
> specific operations gic_hw_ops->... which are tracked by me. You can 
> see, in the code above, that I copy all updates to the physical LR 
> issued by hypervisor into the stored LRs. So it not the case. But I'll 
> check on Monday.

In 4.12-unstable code base I moved gic_store_lrs() after vgic_sync_from_lrs()  
and see significant changes.  Now stale lines are printed at very high rate, 
and it is the proper behavior. Because the correspondent check (performed when 
vgic_sync_from_lrs() reads LRs) detects that VM processes interrupts and LR 
values are changed comparing to those set by hypervisor lately.

So now it is the question, why could I detect spurious changes in LRs without 
exiting to VM?


-- 

*Andrii Anisov*



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

[Xen-devel] [freebsd-master test] 129128: regressions - trouble: blocked/broken

[osstest service owner]

flight 129128 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129128/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-freebsd  broken
 build-amd64-freebsd   6 host-build-prep  fail REGR. vs. 128497

Tests which did not succeed, but are not blocking:
 build-amd64-xen-freebsd   1 build-check(1)   blocked  n/a
 build-amd64-freebsd-again 1 build-check(1)   blocked  n/a

version targeted for testing:
 freebsd  d59b5479f9c99e4417907cf706bf3e98b116d113
baseline version:
 freebsd  c0b412ce93b9d3ee750e5f262b50e64c52d300cc

Last test of basis   128497  2018-10-08 09:19:52 Z   21 days
Failing since128582  2018-10-10 09:19:25 Z   19 days9 attempts
Testing same since   129128  2018-10-29 09:19:07 Z0 days1 attempts


People who touched revisions under test:
  0mp <0...@freebsd.org>
  ae 
  alc 
  allanjude 
  andrew 
  arichardson 
  avg 
  bapt 
  bcr 
  bcran 
  br 
  brooks 
  bwidawsk 
  bz 
  Cassiano Peixoto and others
  cem 
  cy 
  davidcs 
  delphij 
  des 
  dteske 
  eadler 
  egypcio 
  emaste 
  erj 
  eugen 
  Fyodor Ustinov 
  gjb 
  glebius 
  gonzo 
  hselasky 
  imp 
  jamie 
  jchandra 
  jhb 
  jhibbits 
  jilles 
  jkim 
  jtl 
  kevans 
  kib 
  kp 
  luporl 
  markj 
  mav 
  mckusick 
  mjg 
  mm 
  mw 
  np 
  nwhitehorn 
  oshogbo 
  peter 
  philip 
  phk 
  rgrimes 
  rigoletto 
  rmacklem 
  shurd 
  skozlov 
  slavash 
  takawata 
  tijl 
  tmunro 
  tobik 
  trasz 
  tsoome 
  tuexen 
  vmaffione 
  whu 
  wulf 
  yuripv 

jobs:
 build-amd64-freebsd-againblocked 
 build-amd64-freebsd  broken  
 build-amd64-xen-freebsd  blocked 



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary

broken-job build-amd64-freebsd broken

Not pushing.

(No revision log; it would be 6921 lines long.)

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

[Xen-devel] [xen-4.9-testing test] 129090: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail like 128844
 test-amd64-i386-xl-qemuu-ws16-amd64 15 guest-saverestore.2fail like 128868
 test-amd64-amd64-xl-qemut-ws16-amd64 14 guest-localmigratefail like 128900
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 128900
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 128900
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 128900
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 128900
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 128900
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 128900
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-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-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 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-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-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:
 xen  f294d80e8e43d4cdcc6d4d94b1e9c9b1aadf67d8
baseline version:
 xen  782ca9b94f77026875dd98d6288fc1f8dcc7ce19

Last test of basis   128900  2018-10-20 14:23:36 Z8 days
Testing same since   128966  2018-10-24 21:36:22 Z4 days4 attempts


People who touched revisions under test:
  Andrew Cooper 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-i386-xsm   pass
 build-amd64-xtf

[Xen-devel] [ovmf baseline-only test] 75532: trouble: blocked/broken

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 75532 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75532/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm  broken
 build-i386   broken
 build-amd64-pvopsbroken
 build-i386-xsm   broken
 build-amd64  broken
 build-i386-pvops broken

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 build-i3864 host-install(4)   broken baseline untested
 build-i386-pvops  4 host-install(4)   broken baseline untested
 build-amd64   4 host-install(4)   broken baseline untested
 build-amd64-pvops 4 host-install(4)   broken baseline untested
 build-i386-xsm4 host-install(4)   broken baseline untested
 build-amd64-xsm   4 host-install(4)   broken baseline untested

version targeted for testing:
 ovmf 2f6693c283b54666def65e5e0d0b84e48b21cfef
baseline version:
 ovmf 0cd645250306b244a5d6e0e293ed1786ec101641

Last test of basis75528  2018-10-28 15:50:33 Z0 days
Testing same since75532  2018-10-29 03:20:35 Z0 days1 attempts


People who touched revisions under test:
  Jiaxin Wu 
  Wu Jiaxin 

jobs:
 build-amd64-xsm  broken  
 build-i386-xsm   broken  
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 



sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xensource.com/osstest/logs

Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-job build-amd64-xsm broken
broken-job build-i386 broken
broken-job build-amd64-pvops broken
broken-job build-i386-xsm broken
broken-job build-amd64 broken
broken-job build-i386-pvops broken
broken-step build-i386 host-install(4)
broken-step build-i386-pvops host-install(4)
broken-step build-amd64 host-install(4)
broken-step build-amd64-pvops host-install(4)
broken-step build-i386-xsm host-install(4)
broken-step build-amd64-xsm host-install(4)

Push not applicable.


commit 2f6693c283b54666def65e5e0d0b84e48b21cfef
Author: Jiaxin Wu 
Date:   Thu Oct 25 15:16:13 2018 +0800

NetworkPkg/Mtftp6Dxe: Correct the total received and saved block number.

The block returned from Mtftp6RemoveBlockNum is not the total received and
saved block number if it works in passive (Slave) mode.

The issue was exposed by the EMS test.

Cc: Ye Ting 
Cc: Fu Siyuan 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Wu Jiaxin 
Reviewed-by: Ye Ting 

commit 9202304c180e811ab7b64ccf01fe11187969fe9b
Author: Jiaxin Wu 
Date:   Thu Oct 25 15:31:10 2018 +0800

MdeModulePke/Mtftp4Dxe: Correct the total received and saved block number.

The block returned from Mtftp4RemoveBlockNum is not the total received and
saved block number if it works in passive (Slave) mode.

The issue was exposed by the EMS test.

Cc: Ye Ting 
Cc: Fu Siyuan 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Wu Jiaxin 
Reviewed-by: Ye Ting 

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

[Xen-devel] [ovmf test] 129121: regressions - FAIL

[osstest service owner]

flight 129121 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129121/

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a

version targeted for testing:
 ovmf c09b254bdc6050cc8b580a26558f692f958645d6
baseline version:
 ovmf 2f6693c283b54666def65e5e0d0b84e48b21cfef

Last test of basis   129113  2018-10-29 00:40:55 Z0 days
Testing same since   129121  2018-10-29 03:41:45 Z0 days1 attempts


People who touched revisions under test:
  Chasel Chiu 
  Chasel, Chiu 
  Ruiyu Ni 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   fail
 build-amd64-pvopspass
 build-i386-pvops fail
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.


commit c09b254bdc6050cc8b580a26558f692f958645d6
Author: Chasel, Chiu 
Date:   Fri Oct 26 15:12:33 2018 +0800

IntelFsp2Pkg: Fixed potentially NULL pointer accessing

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1280

When copying IDT table in SecMain, the pointer might be
NULL so added the check to fix it.

Test: Verified on internal platform and boots successfully.

Cc: Jiewen Yao 
Cc: Desimone Nathaniel L 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Chasel Chiu 

commit 70425456dae16fca23540936c8fb0d2b86776b97
Author: Ruiyu Ni 
Date:   Thu Oct 25 18:09:46 2018 +0800

MdeModulePkg/UsbBusPei: Reject descriptor whose length is bad

Today's implementation doesn't check whether the length of
descriptor is valid before using it.

The patch fixes this issue by syncing the similar fix to UsbBusDxe.
70c3c2370a2aefe71cf0f6c1a1e063f7d74e1d79
*MdeModulePkg/UsbBus: Reject descriptor whose length is bad

Additionally the patch also rejects the data when length is
larger than sizeof (PeiUsbDevice->ConfigurationData).

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Reviewed-by: Star Zeng 
Cc: Jiewen Yao 

commit c96de1dbaedce11489974c3e977f1de4ec5cfb84
Author: Ruiyu Ni 
Date:   Thu Oct 25 17:07:12 2018 +0800

MdeModulePkg/UsbBusPei: Fix out-of-bound read access to descriptors

Today's implementation reads the Type/Length field in the USB
descriptors data without checking whether the offset to read is
beyond the data boundary.

The patch fixes this issue by syncing the fix in commit
4c034bf62cbc1f3c5f4b5df25de97f0f528132b2
*MdeModulePkg/UsbBus: Fix out-of-bound read access to descriptors

ParsedBytes in UsbBusPei.GetExpectedDescriptor() is different from
Consumed in UsbBusDxe.UsbCreateDesc().
ParsedBytes is the offset of found descriptor while Consumed is
offset of next descriptor of found one.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Reviewed-by: Star Zeng 
Cc: Jiewen Yao 

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