Re: [Xen-devel] [PATCH 4/5] x86/pv: Drop support for paging out the LDT

[Jan Beulich]

>>> On 12.01.18 at 19:37,  wrote:
> Windows is the only OS which pages out kernel datastructures, so chances are
> good that this is a vestigial remnant of the PV Windows XP experiment.

This is based on what? How do you know there are no other OSes
doing so, including perhaps ones which none of us has ever heard
of? The diffstat of the change here is certainly nice, but as always
with something being removed from the ABI I'm rather hesitant.

> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -1942,11 +1942,8 @@ int domain_relinquish_resources(struct domain *d)
>  {
>  for_each_vcpu ( d, v )
>  {
> -/*
> - * Relinquish GDT mappings. No need for explicit unmapping of
> - * the LDT as it automatically gets squashed with the guest
> - * mappings.
> - */
> +/* Relinquish GDT/LDT mappings. */
> +pv_destroy_ldt(v);
>  pv_destroy_gdt(v);

The domain is dead at this point, so the order doesn't matter much,
but strictly speaking you should destroy the GDT before destroying
the LDT (just like LDT _loads_ always need to come _after_ GDT
adjustments).

Everything else here looks fine, but the initial comment may need
further discussion. For example we may want to consider a
two-stage phasing out of the feature, with a couple of years in
between: Make the functionality dependent upon a default-off
command line option for the time being, and issue a bright warning
when someone actually enables it (telling them to tell us).

Jan


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

Re: [Xen-devel] [PATCH v4] kexec-tools: Perform run-time linking of libxenctrl.so

[Simon Horman]

On Wed, Jan 17, 2018 at 10:39:01AM -0600, Eric DeVolder wrote:
> When kexec is utilized in a Xen environment, it has an explicit
> run-time dependency on libxenctrl.so. This dependency occurs
> during the configure stage and when building kexec-tools.

...

Thanks for addressing this and thanks doubly for the very comprehensive
changelog.

Applied.

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

Re: [Xen-devel] Access I2C bus from guest/DomU on ARM board

[Saumya Rajesh]

On Wed, Jan 17, 2018 at 9:06 PM, Andrii Anisov 
wrote:

> Rajesh,
>
> On 17.01.18 16:03, Saumya Rajesh wrote:
>
>> Just out of curiosity, is it possible to split the Driver for the Renesas
>> RCar I2C unit [1] into frontend and backend to use the i2c bus from guest?
>> Or to do something similar to PCI passthrough? Please forgive me if I sound
>> illogical. I'm just curious.
>>
> I guess you could implement PV I2C using FE/BE scheme. With enormous
> efforts and unpredictable results.
> But I'm sure it is not what you really need.
>
> --
>
> *Andrii Anisov*
>
>
>
​Hi Andrii

Actually I am planning to set up Android as guest in Xen. In order to
enable sound in the Android guest, I need to passthrough the audio codec
device which communicates through the I2C bus. For BE/FE scheme, I think
sharing the internal DMA and clock would pose problems. So I'm going to go
ahead with the device passthrough way.

Any thoughts or inputs you can possibly give regarding this use case will
be very helpful and valuable.

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

Re: [Xen-devel] [PATCH 1/5] x86/idt: Factor out enabling and disabling of ISTs

[Jan Beulich]

>>> On 17.01.18 at 15:43,  wrote:
> On Fri, Jan 12, 2018 at 06:37:20PM +, Andrew Cooper wrote:
>> All alteration of IST settings (other than the crash path) happen in an
>> identical triple.  Introduce helpers to keep the triple in sync, and reduce
>> the risk of opencoded mistakes.
>> 
>> 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

[Xen-devel] [linux-4.9 test] 118151: trouble: broken/fail/pass

[osstest service owner]

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

Failures and problems with tests :-(

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

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds  4 host-install(4)broken REGR. vs. 117765
 test-amd64-amd64-rumprun-amd64 17 rumprun-demo-xenstorels/xenstorels.repeat 
fail REGR. vs. 117765

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

version targeted for testing:
 linuxb8cf9ff79d63a3ac5567bd7cbb9445bfed193f4d
baseline version:
 linux7bbc6ca4887794cc44b41412a35bdfbe0cbd1c50

Last test of basis   117765  2018-01-10 08:50:09 Z7 days
Testing same since   118151  2018-01-17 09:29:15 Z0 days1 attempts


People who touched revisions 

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

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 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

version targeted for testing:
 xen  e730f8e41e8537f1db9770b9464f9523c28857b9
baseline version:
 xen  e871e80c38547d9faefc6604532ba3e985e65873

Last test of basis   118105  2018-01-16 17:04:09 Z1 days
Failing since118110  2018-01-16 19:02:12 Z1 days   17 attempts
Testing same since   118194  2018-01-18 00:01:12 Z0 days3 attempts


People who touched revisions under test:
  Andrew Cooper 
  Anthony Liguori 
  Bob Moore 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Jon Ludlam 
  Jonathan Ludlam 
  Julien Grall 
  Lv Zheng 
  Rafael J. Wysocki 
  Roger Pau Monne 
  Roger Pau Monné 
  Sergey Dyasli 
  Stefano Stabellini 
  Wei Liu 

jobs:
 build-arm64-xsm  pass
 build-amd64  pass
 build-armhf  fail
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  blocked 
 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


Not pushing.

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

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

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

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 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

version targeted for testing:
 xen  e730f8e41e8537f1db9770b9464f9523c28857b9
baseline version:
 xen  e871e80c38547d9faefc6604532ba3e985e65873

Last test of basis   118105  2018-01-16 17:04:09 Z1 days
Failing since118110  2018-01-16 19:02:12 Z1 days   16 attempts
Testing same since   118194  2018-01-18 00:01:12 Z0 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Anthony Liguori 
  Bob Moore 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Jon Ludlam 
  Jonathan Ludlam 
  Julien Grall 
  Lv Zheng 
  Rafael J. Wysocki 
  Roger Pau Monne 
  Roger Pau Monné 
  Sergey Dyasli 
  Stefano Stabellini 
  Wei Liu 

jobs:
 build-arm64-xsm  pass
 build-amd64  pass
 build-armhf  fail
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  blocked 
 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


Not pushing.

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

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

[Xen-devel] [PULL 06/19] machine: Replace has_dynamic_sysbus with list of allowed devices

[Eduardo Habkost]

The existing has_dynamic_sysbus flag makes the machine accept
every user-creatable sysbus device type on the command-line.
Replace it with a list of allowed device types, so machines can
easily accept some sysbus devices while rejecting others.

To keep exactly the same behavior as before, the existing
has_dynamic_sysbus=true assignments are replaced with a
TYPE_SYS_BUS_DEVICE entry on the allowed list.  Other patches
will replace the TYPE_SYS_BUS_DEVICE entries with more specific
lists of devices.

Cc: Peter Maydell 
Cc: Marcel Apfelbaum 
Cc: "Michael S. Tsirkin" 
Cc: Alexander Graf 
Cc: David Gibson 
Cc: Stefano Stabellini 
Cc: Anthony Perard 
Cc: qemu-...@nongnu.org
Cc: qemu-...@nongnu.org
Cc: xen-devel@lists.xenproject.org
Signed-off-by: Eduardo Habkost 
Message-Id: <20171125151610.20547-2-ehabk...@redhat.com>
Reviewed-by: Greg Kurz 
Reviewed-by: David Gibson 
Reviewed-by: Marc-André Lureau 
Reviewed-by: Marcel Apfelbaum 
Signed-off-by: Eduardo Habkost 
---
 include/hw/boards.h  |  5 -
 hw/arm/virt.c|  3 ++-
 hw/core/machine.c| 43 +--
 hw/i386/pc_q35.c |  3 ++-
 hw/ppc/e500plat.c|  4 +++-
 hw/ppc/spapr.c   |  3 ++-
 hw/xen/xen_backend.c |  7 ++-
 7 files changed, 48 insertions(+), 20 deletions(-)

diff --git a/include/hw/boards.h b/include/hw/boards.h
index 156b16f7a6..041bc08971 100644
--- a/include/hw/boards.h
+++ b/include/hw/boards.h
@@ -76,6 +76,9 @@ void machine_set_cpu_numa_node(MachineState *machine,
const CpuInstanceProperties *props,
Error **errp);
 
+void machine_class_allow_dynamic_sysbus_dev(MachineClass *mc, const char 
*type);
+
+
 /**
  * CPUArchId:
  * @arch_id - architecture-dependent CPU ID of present or possible CPU
@@ -179,7 +182,6 @@ struct MachineClass {
 no_floppy:1,
 no_cdrom:1,
 no_sdcard:1,
-has_dynamic_sysbus:1,
 pci_allow_0_address:1,
 legacy_fw_cfg_order:1;
 int is_default;
@@ -197,6 +199,7 @@ struct MachineClass {
 bool ignore_memory_transaction_failures;
 int numa_mem_align_shift;
 const char **valid_cpu_types;
+strList *allowed_dynamic_sysbus_devices;
 bool auto_enable_numa_with_memhp;
 void (*numa_auto_assign_ram)(MachineClass *mc, NodeInfo *nodes,
  int nb_nodes, ram_addr_t size);
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 543f9bd6cc..7549895fd2 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -1591,7 +1591,8 @@ static void virt_machine_class_init(ObjectClass *oc, void 
*data)
  * configuration of the particular instance.
  */
 mc->max_cpus = 255;
-mc->has_dynamic_sysbus = true;
+/*TODO: allow only sysbus devices that really work with this machine */
+machine_class_allow_dynamic_sysbus_dev(mc, TYPE_SYS_BUS_DEVICE);
 mc->block_default_type = IF_VIRTIO;
 mc->no_cdrom = 1;
 mc->pci_allow_0_address = true;
diff --git a/hw/core/machine.c b/hw/core/machine.c
index c857f3f934..0320a8efa1 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -334,29 +334,44 @@ static bool machine_get_enforce_config_section(Object 
*obj, Error **errp)
 return ms->enforce_config_section;
 }
 
-static void error_on_sysbus_device(SysBusDevice *sbdev, void *opaque)
+void machine_class_allow_dynamic_sysbus_dev(MachineClass *mc, const char *type)
 {
-error_report("Option '-device %s' cannot be handled by this machine",
- object_class_get_name(object_get_class(OBJECT(sbdev;
-exit(1);
+strList *item = g_new0(strList, 1);
+
+item->value = g_strdup(type);
+item->next = mc->allowed_dynamic_sysbus_devices;
+mc->allowed_dynamic_sysbus_devices = item;
 }
 
-static void machine_init_notify(Notifier *notifier, void *data)
+static void validate_sysbus_device(SysBusDevice *sbdev, void *opaque)
 {
-Object *machine = qdev_get_machine();
-ObjectClass *oc = object_get_class(machine);
-MachineClass *mc = MACHINE_CLASS(oc);
+MachineState *machine = opaque;
+MachineClass *mc = MACHINE_GET_CLASS(machine);
+bool allowed = false;
+strList *wl;
 
-if (mc->has_dynamic_sysbus) {
-/* Our machine can handle dynamic sysbus devices, we're all good */
-return;
+for (wl = mc->allowed_dynamic_sysbus_devices;
+ !allowed && wl;
+ wl = wl->next) {
+allowed |= !!object_dynamic_cast(OBJECT(sbdev), wl->value);
 }
 
+if (!allowed) {
+error_report("Option '-device %s' cannot be handled by this machine",
+ object_class_get_name(object_get_class(OBJECT(sbdev;
+exit(1);
+}
+}
+
+static void 

[Xen-devel] [PULL 10/19] xen: Add only xen-sysdev to dynamic sysbus device list

[Eduardo Habkost]

There's no need to make the machine allow every possible sysbus
device.  We can now just add xen-sysdev to the allowed list.

Cc: Stefano Stabellini 
Cc: Anthony Perard 
Cc: xen-devel@lists.xenproject.org
Cc: Juergen Gross 
Signed-off-by: Eduardo Habkost 
Message-Id: <20171125151610.20547-6-ehabk...@redhat.com>
Reviewed-by: Marc-André Lureau 
Acked-by: Anthony PERARD 
Signed-off-by: Eduardo Habkost 
---
 hw/xen/xen_backend.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
index 82380ea9ee..7445b506ac 100644
--- a/hw/xen/xen_backend.c
+++ b/hw/xen/xen_backend.c
@@ -564,12 +564,7 @@ static void xen_set_dynamic_sysbus(void)
 ObjectClass *oc = object_get_class(machine);
 MachineClass *mc = MACHINE_CLASS(oc);
 
-/*
- * Emulate old mc->has_dynamic_sysbus=true assignment
- *
- *TODO: add only Xen devices to the list
- */
-machine_class_allow_dynamic_sysbus_dev(mc, TYPE_SYS_BUS_DEVICE);
+machine_class_allow_dynamic_sysbus_dev(mc, TYPE_XENSYSDEV);
 }
 
 int xen_be_register(const char *type, struct XenDevOps *ops)
-- 
2.14.3


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

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

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 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

version targeted for testing:
 xen  8d2983ec793362e8bcbe1a9a36d3eee61bc187f0
baseline version:
 xen  e871e80c38547d9faefc6604532ba3e985e65873

Last test of basis   118105  2018-01-16 17:04:09 Z1 days
Failing since118110  2018-01-16 19:02:12 Z1 days   14 attempts
Testing same since   118162  2018-01-17 15:01:29 Z0 days4 attempts


People who touched revisions under test:
  Andrew Cooper 
  Anthony Liguori 
  Bob Moore 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Jon Ludlam 
  Jonathan Ludlam 
  Lv Zheng 
  Rafael J. Wysocki 
  Roger Pau Monne 
  Roger Pau Monné 
  Sergey Dyasli 
  Wei Liu 

jobs:
 build-arm64-xsm  pass
 build-amd64  pass
 build-armhf  fail
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  blocked 
 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


Not pushing.

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

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

Re: [Xen-devel] [PATCH 1/5] xen/arm: Introduce enable callback to enable a capabilities on each online CPU

[Stefano Stabellini]

On Wed, 17 Jan 2018, Stefano Stabellini wrote:
> On Wed, 17 Jan 2018, Lars Kurth wrote:
> >   Regarding README.source, this is covering file and contain the same 
> > mention as in the commit message. As this is a single function. Isn't the 
> > commit message
> >   enough?
> > 
> > 
> > From a legal viewpoint it is enough.
> 
> If that is enough from a legal viewpoint, then it is enough for me.
> 
> However, from a legal viewpoint, I thought we needed to explicitly
> mention all the original signed-off-bys because Julien is not actually
> the copyright holder for that function, hence, we need to add the
> signed-off-bys of all the missing copyright holders.

Actually, reading again the Developer’s Certificate of Origin, it
states:

"The contribution is based upon previous work that, to the best of my 
knowledge, is covered under an appropriate open source license and I have the 
right under that license to submit that work with modifications, whether 
created in whole or in part by me, under the same open source license (unless I 
am permitted to submit under a different license), as indicated in the file"

so I think Lars is right. In that case, there is no need to resubmit
this series, I'll commit to staging as is. If tests go well, I'll
backport it to the stable trees.___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

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

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 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

version targeted for testing:
 xen  8d2983ec793362e8bcbe1a9a36d3eee61bc187f0
baseline version:
 xen  e871e80c38547d9faefc6604532ba3e985e65873

Last test of basis   118105  2018-01-16 17:04:09 Z1 days
Failing since118110  2018-01-16 19:02:12 Z1 days   13 attempts
Testing same since   118162  2018-01-17 15:01:29 Z0 days3 attempts


People who touched revisions under test:
  Andrew Cooper 
  Anthony Liguori 
  Bob Moore 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Jon Ludlam 
  Jonathan Ludlam 
  Lv Zheng 
  Rafael J. Wysocki 
  Roger Pau Monne 
  Roger Pau Monné 
  Sergey Dyasli 
  Wei Liu 

jobs:
 build-arm64-xsm  pass
 build-amd64  pass
 build-armhf  fail
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  blocked 
 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


Not pushing.

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

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

[Xen-devel] [linux-3.18 test] 118149: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 117702
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 117702
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 117702
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 117702
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 117702
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 117702
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 117702
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 build-arm64-pvops 6 kernel-build fail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemut-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-qemuu-win10-i386 10 windows-install fail never pass

version targeted for testing:
 linuxa5d35deca214e095bf9d1745aa6c00dd7ced0517
baseline version:
 linux788ccf7552c82179135470473d9035f7c8b0b188

Last test of basis   117702  2018-01-07 16:48:28 Z   10 days
Testing same since   118149  2018-01-17 08:52:14 Z0 days1 attempts


People who touched revisions under test:
  Aaron Brown 
  Aaron Ma 
  Abdul Lateef Attar 
  Al Viro 
  Alex Smith 
  Amit Pundir 
  Andrew 

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

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 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

version targeted for testing:
 xen  8d2983ec793362e8bcbe1a9a36d3eee61bc187f0
baseline version:
 xen  e871e80c38547d9faefc6604532ba3e985e65873

Last test of basis   118105  2018-01-16 17:04:09 Z1 days
Failing since118110  2018-01-16 19:02:12 Z0 days   12 attempts
Testing same since   118162  2018-01-17 15:01:29 Z0 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Anthony Liguori 
  Bob Moore 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Jon Ludlam 
  Jonathan Ludlam 
  Lv Zheng 
  Rafael J. Wysocki 
  Roger Pau Monne 
  Roger Pau Monné 
  Sergey Dyasli 
  Wei Liu 

jobs:
 build-arm64-xsm  pass
 build-amd64  pass
 build-armhf  fail
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  blocked 
 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


Not pushing.

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

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

Re: [Xen-devel] [PATCH 4/5] xen/arm64: Add skeleton to harden the branch predictor aliasing attacks

[Stefano Stabellini]

On Tue, 16 Jan 2018, Julien Grall wrote:
> Aliasing attacked against CPU branch predictors can allow an attacker to
> redirect speculative control flow on some CPUs and potentially divulge
> information from one context to another.
> 
> This patch adds initial skeleton code behind a new Kconfig option to
> enable implementation-specific mitigations against these attacks for
> CPUs that are affected.
> 
> Most of the mitigations will have to be applied when entering to the
> hypervisor from the guest context. For safety, it is applied at every
> exception entry. So there are potential for optimizing when receiving
> an exception at the same level.
> 
> Because the attack is against branch predictor, it is not possible to
> safely use branch instruction before the mitigation is applied.
> Therefore, this has to be done in the vector entry before jump to the
> helper handling a given exception.
> 
> On Arm64, each vector can hold 32 instructions. This leave us 31
> instructions for the mitigation. The last one is the branch instruction
> to the helper.
> 
> Because a platform may have CPUs with different micro-architectures,
> per-CPU vector table needs to be provided. Realistically, only a few
> different mitigations will be necessary. So provide a small set of
> vector tables. They will be re-used and patch with the mitigations
> on-demand.
> 
> This is based on the work done in Linux (see [1]).
> 
> This is part of XSA-254.
> 
> [1] git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
> branch ktpi

If mentioning the original commit/branch is sufficient, then OK.
Otherwise, if we need to explicitly mention all the copyright holders,
then please add all the required signed-off-bys.


> Signed-off-by: Julien Grall 
> ---
>  xen/arch/arm/Kconfig |  20 ++
>  xen/arch/arm/arm64/Makefile  |   1 +
>  xen/arch/arm/arm64/bpi.S |  64 ++
>  xen/arch/arm/cpuerrata.c | 142 
> +++
>  xen/arch/arm/traps.c |   5 +-
>  xen/include/asm-arm/cpuerrata.h  |   1 +
>  xen/include/asm-arm/cpufeature.h |   3 +-
>  xen/include/asm-arm/processor.h  |   5 +-
>  8 files changed, 237 insertions(+), 4 deletions(-)
>  create mode 100644 xen/arch/arm/arm64/bpi.S
> 
> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> index f58019d6ed..06fd85cc77 100644
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -171,6 +171,26 @@ config ARM64_ERRATUM_834220
>  
>  endmenu
>  
> +config HARDEN_BRANCH_PREDICTOR
> + bool "Harden the branch predictor against aliasing attacks" if EXPERT
> + default y
> + help
> +   Speculation attacks against some high-performance processors rely on
> +   being able to manipulate the branch predictor for a victim context by
> +   executing aliasing branches in the attacker context.  Such attacks
> +   can be partially mitigated against by clearing internal branch
> +   predictor state and limiting the prediction logic in some situations.
> +
> +   This config option will take CPU-specific actions to harden the
> +   branch predictor against aliasing attacks and may rely on specific
> +   instruction sequences or control bits being set by the system
> +   firmware.
> +
> +   If unsure, say Y.
> +
> +config ARM64_HARDEN_BRANCH_PREDICTOR
> +def_bool y if ARM_64 && HARDEN_BRANCH_PREDICTOR
> +
>  source "common/Kconfig"
>  
>  source "drivers/Kconfig"
> diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
> index 718fe44455..bb5c610b2a 100644
> --- a/xen/arch/arm/arm64/Makefile
> +++ b/xen/arch/arm/arm64/Makefile
> @@ -1,6 +1,7 @@
>  subdir-y += lib
>  
>  obj-y += cache.o
> +obj-$(CONFIG_HARDEN_BRANCH_PREDICTOR) += bpi.o
>  obj-$(EARLY_PRINTK) += debug.o
>  obj-y += domctl.o
>  obj-y += domain.o
> diff --git a/xen/arch/arm/arm64/bpi.S b/xen/arch/arm/arm64/bpi.S
> new file mode 100644
> index 00..6cc2f17529
> --- /dev/null
> +++ b/xen/arch/arm/arm64/bpi.S
> @@ -0,0 +1,64 @@
> +/*
> + * Contains CPU specific branch predictor invalidation sequences
> + *
> + * Copyright (C) 2018 ARM Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see .
> + */
> +
> +.macro ventry target
> +.rept 31
> +nop
> +.endr
> +b\target
> +.endm
> +
> +.macro vectors target
> +ventry \target + 0x000
> +ventry \target + 0x080
> +   

Re: [Xen-devel] [PATCH 6/6] firmware/shim: fix build process to use POSIX find options

[Andrew Cooper]

On 17/01/18 17:32, Roger Pau Monné wrote:
> On Wed, Jan 17, 2018 at 04:24:27PM +, Ian Jackson wrote:
>> Roger Pau Monne writes ("[PATCH 6/6] firmware/shim: fix build process to use 
>> POSIX find options"):
>>> The -printf find option is not POSIX compatible, so replace it with
>>> another rune.
>> ...
>>>   cd $(D)/$(d); \
>>> - find $(XEN_ROOT)/$(d)/ -type d -printf "./%P\n" |  xargs 
>>> mkdir -p);)
>>> + find $(XEN_ROOT)/$(d)/ -type d -exec sh -c \
>>> + "echo {} | sed 's,^$(XEN_ROOT)/$(d)/,,g' | xargs mkdir 
>>> -p" \;);)
>> This is now a pretty nasty shell construct.
>>
>> If you're going to use sed, you could just
>>find ... -print | sed ... | xargs mkdir -p
> I think I will go with this one...
>
>> Substituting {} into the middle of the shell rune is bad practice in
>> general because it might contain metacharacters or spaces.  In our
>> build system this doesn't matter because that breaks anyway, but it's
>> very poor style (and also it buries the actual data flow path into the
>> middle of a complicated manglement).
>>
>> If you wanted to use -exec and sh, you could do something like this
>>-exec sh -c 'exec mkdir "${1#$(XEN_ROOT}/$(d)/}"' x {}
>> maybe.
> ... because I cannot really make #2 work, and I'm not sure I fully
> understand it.

Probably because it needs to be 'exec mkdir "$${1  so shell sees ${1
when its passed through Make.

~Andrew

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

[Xen-devel] [seabios test] 118140: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop   fail REGR. vs. 115539

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 115539
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 115539
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 115539
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass

version targeted for testing:
 seabios  14d91c353e19b7085fdbb7b2dcc43f3355665670
baseline version:
 seabios  0ca6d6277dfafc671a5b3718cbeb5c78e2a888ea

Last test of basis   115539  2017-11-03 20:48:58 Z   74 days
Failing since115733  2017-11-10 17:19:59 Z   68 days   80 attempts
Testing same since   118140  2018-01-17 05:09:48 Z0 days1 attempts


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

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



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

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

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

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


Not pushing.


commit 14d91c353e19b7085fdbb7b2dcc43f3355665670
Author: Marcel Apfelbaum 
Date:   Thu Jan 11 22:15:12 2018 +0200

pci: fix 'io hints' capability for RedHat PCI bridges

Commit ec6cb17f (pci: enable RedHat PCI bridges to reserve additional
 resources on PCI init)
added a new vendor specific PCI capability for RedHat PCI bridges
allowing them to reserve additional buses and/or IO/MEM space.

When adding the IO hints PCI capability to the pcie-root-port
without specifying a value for bus reservation, the subordinate bus
computation is wrong and the guest kernel gets messed up.

Fix it by returning to prev code if the value for bus
reservation is not set.

Removed also a wrong debug print "PCI: invalid QEMU resource reserve
cap offset" which appears if the 'IO hints' capability is not present.

Acked-by: Michael S. Tsirkin 

Re: [Xen-devel] [PATCH 6/6] firmware/shim: fix build process to use POSIX find options

[Roger Pau Monné]

On Wed, Jan 17, 2018 at 04:24:27PM +, Ian Jackson wrote:
> Roger Pau Monne writes ("[PATCH 6/6] firmware/shim: fix build process to use 
> POSIX find options"):
> > The -printf find option is not POSIX compatible, so replace it with
> > another rune.
> ...
> >   cd $(D)/$(d); \
> > - find $(XEN_ROOT)/$(d)/ -type d -printf "./%P\n" |  xargs 
> > mkdir -p);)
> > + find $(XEN_ROOT)/$(d)/ -type d -exec sh -c \
> > + "echo {} | sed 's,^$(XEN_ROOT)/$(d)/,,g' | xargs mkdir 
> > -p" \;);)
> 
> This is now a pretty nasty shell construct.
> 
> If you're going to use sed, you could just
>find ... -print | sed ... | xargs mkdir -p

I think I will go with this one...

> Substituting {} into the middle of the shell rune is bad practice in
> general because it might contain metacharacters or spaces.  In our
> build system this doesn't matter because that breaks anyway, but it's
> very poor style (and also it buries the actual data flow path into the
> middle of a complicated manglement).
> 
> If you wanted to use -exec and sh, you could do something like this
>-exec sh -c 'exec mkdir "${1#$(XEN_ROOT}/$(d)/}"' x {}
> maybe.

... because I cannot really make #2 work, and I'm not sure I fully
understand it.

Thanks, Roger.

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

Re: [Xen-devel] [PATCH v8 15/17] x86/ctxt: Issue a speculation barrier between vcpu contexts

[David Woodhouse]

On Mon, 2018-01-15 at 22:39 +0100, David Woodhouse wrote:
> On Mon, 2018-01-15 at 14:23 +0100, David Woodhouse wrote:
> > 
> > 
> > > 
> > > > 
> > > >  
> > > > Also... if you're doing that in context_switch() does it do the right
> > > > thing with idle? If a CPU switches to the idle domain and then back
> > > > again to the same vCPU, does that do the IBPB twice?
> > >
> > > Context switches to idle will skip the IBPB because it isn't needed, but
> > > any switch to non-idle need it.  In your example, we should execute just
> > > a single IBPB.
>
> > In my example I think we should not execute IBPB at all. We come from a
> > given VMCS, sleep for a while, and go back to it. No need for any
> > flushing whatsoever.
>
> msw points out that in my example we *don't* execute IBPB at all, I
> think.
> 
> In both switching to idle, and back to the vCPU, we should hit this
> case and not the 'else' case that does the IBPB:
> 
> 1710 if ( (per_cpu(curr_vcpu, cpu) == next) ||
> 1711  (is_idle_domain(nextd) && cpu_online(cpu)) )
> 1712 {
> 1713 local_irq_enable();
> 1714 }

I tested that; it doesn't seem to be the case. We end up here with prev
being the idle thread, next being the actual vCPU, and
per_cpu(curr_vcpu, cpu) being the idle thread too. So we still do the
IBPB even when we've just switch from a given vCPU to idle and back
again.

That's not actually tested on Xen master, but the code here looks very
much the same as what I actually did test.

smime.p7s
Description: S/MIME cryptographic signature
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] Xen Security Advisory 254 (CVE-2017-5753, CVE-2017-5715, CVE-2017-5754) - Information leak via side effects of speculative execution

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

 Xen Security Advisory CVE-2017-5753,CVE-2017-5715,CVE-2017-5754 / XSA-254
 version 9

Information leak via side effects of speculative execution

UPDATES IN VERSION 9


"Stage 1" pagetable isolation (PTI) Meltdown fixes for Xen are
available.

"Comet" updates to shim code (4.10 branch):
 * Include >32vcpu workaround in shim branch so that all shim
   guests can boot without hypervisor changes.
 * Fix shim build on systems whose find(1) lacks -printf
 * Place shim trampoline at page 0x1 to avoid having 0 mapped
(4.8 "Comet" users are using the 4.10 shim and may want to update.)

ISSUE DESCRIPTION
=

Processors give the illusion of a sequence of instructions executed
one-by-one.  However, in order to most efficiently use cpu resources,
modern superscalar processors actually begin executing many
instructions in parallel.  In cases where instructions depend on the
result of previous instructions or checks which have not yet
completed, execution happens based on guesses about what the outcome
will be.  If the guess is correct, execution has been sped up.  If the
guess is incorrect, partially-executed instructions are cancelled and
architectural state changes (to registers, memory, and so on)
reverted; but the whole process is no slower than if no guess had been
made at all.  This is sometimes called "speculative execution".

Unfortunately, although architectural state is rolled back, there are
other side effects, such as changes to TLB or cache state, which are
not rolled back.  These side effects can subsequently be detected by
an attacker to determine information about what happened during the
speculative execution phase.  If an attacker can cause speculative
execution to access sensitive memory areas, they may be able to infer
what that sensitive memory contained.

Furthermore, these guesses can often be 'poisoned', such that attacker
can cause logic to reliably 'guess' the way the attacker chooses.
This advisory discusses three ways to cause speculative execution to
access sensitive memory areas (named here according to the
discoverer's naming scheme):

"Bounds-check bypass" (aka SP1, "Variant 1", Spectre CVE-2017-5753):
Poison the branch predictor, such that victim code is speculatively
executed past boundary and security checks.  This would allow an
attacker to, for instance, cause speculative code in the normal
hypercall / emulation path to execute with wild array indexes.

"Branch Target Injection" (aka SP2, "Variant 2", Spectre CVE-2017-5715):
Poison the branch predictor.  Well-abstracted code often involves
calling function pointers via indirect branches; reading these
function pointers may involve a (slow) memory access, so the CPU
attempts to guess where indirect branches will lead.  Poisoning this
enables an attacker to speculatively branch to any code that is
executable by the victim (eg, anywhere in the hypervisor).

"Rogue Data Load" (aka SP3, "Variant 3", Meltdown, CVE-2017-5754):
On some processors, certain pagetable permission checks only happen
when the instruction is retired; effectively meaning that speculative
execution is not subject to pagetable permission checks.  On such
processors, an attacker can speculatively execute arbitrary code in
userspace with, effectively, the highest privilege level.

More information is available here:
  https://meltdownattack.com/
  https://spectreattack.com/
  
https://googleprojectzero.blogspot.co.uk/2018/01/reading-privileged-memory-with-side.html

Additional Xen-specific background:

Xen hypervisors on most systems map all of physical RAM, so code
speculatively executed in a hypervisor context can read all of system
RAM.

When running PV guests, the guest and the hypervisor share the address
space; guest kernels run in a lower privilege level, and Xen runs in
the highest privilege level.  (x86 HVM and PVH guests, and ARM guests,
run in a separate address space to the hypervisor.)  However, only
64-bit PV guests can generate addresses large enough to point to
hypervisor memory.

IMPACT
==

Xen guests may be able to infer the contents of arbitrary host memory,
including memory assigned to other guests.

An attacker's choice of code to speculatively execute (and thus the
ease of extracting useful information) goes up with the numbers.  For
SP1, an attacker is limited to windows of code after bound checks of
user-supplied indexes.  For SP2, the attacker will in many cases will
be limited to executing arbitrary pre-existing code inside of Xen.
For SP3 (and other cases for SP2), an attacker can write arbitrary
code to speculatively execute.

Additionally, in general, attacks within a guest (from guest user to
guest kernel) will be the same as on real hardware.  Consult your
operating system provider for more information.

NOTE ON TIMING
==

This vulnerability was originally scheduled to be made public on 9
January.  

Re: [Xen-devel] [PATCH 5/5] xen/arm64: Implement branch predictor hardening for affected Cortex-A CPUs

[Stefano Stabellini]

On Wed, 17 Jan 2018, Julien Grall wrote:
> Hi Stefano,
> 
> On 17/01/18 00:42, Stefano Stabellini wrote:
> > On Tue, 16 Jan 2018, Julien Grall wrote:
> > >   #define MIDR_RANGE(model, min, max) \
> > > @@ -205,6 +232,28 @@ static const struct arm_cpu_capabilities arm_errata[]
> > > = {
> > >  (1 << MIDR_VARIANT_SHIFT) | 2),
> > >   },
> > >   #endif
> > > +#ifdef CONFIG_ARM64_HARDEN_BRANCH_PREDICTOR
> > > +{
> > > +.capability = ARM_HARDEN_BRANCH_PREDICTOR,
> > > +MIDR_ALL_VERSIONS(MIDR_CORTEX_A57),
> > > +.enable = enable_psci_bp_hardening,
> > > +},
> > > +{
> > > +.capability = ARM_HARDEN_BRANCH_PREDICTOR,
> > > +MIDR_ALL_VERSIONS(MIDR_CORTEX_A72),
> > > +.enable = enable_psci_bp_hardening,
> > > +},
> > > +{
> > > +.capability = ARM_HARDEN_BRANCH_PREDICTOR,
> > > +MIDR_ALL_VERSIONS(MIDR_CORTEX_A73),
> > > +.enable = enable_psci_bp_hardening,
> > > +},
> > > +{
> > > +.capability = ARM_HARDEN_BRANCH_PREDICTOR,
> > > +MIDR_ALL_VERSIONS(MIDR_CORTEX_A75),
> > > +.enable = enable_psci_bp_hardening,
> > > +},
> > 
> > We need to add a basic description in the desc field as it is printed by
> > update_cpu_capabilities.
> 
> desc field is not mandatory, and in that case I think the print would be
> confusing. At the difference of the other errata, we have more check in
> install_bp_hardening_vec that may result to skip the hardening.
> 
> The errata here is covering all variant/revision of A75 models for safety
> reason. Arm has introduced a new field ID_AA64PFR0_EL1.CSV2 to tell whether a
> branch predictor trained in one context will affect speculative execution in
> another context. This field is checked in install_bp_hardening_vec so you
> avoid to harden the vector tables and small performance hit.
> 
> IHMO, it would be better to have a per-CPU message in install_bp_hardening_vec
> announcing whether the vector tables has been harden and the kind of
> hardening.
> 
> What do you think?

I understand what you are saying and I agree with you. Maybe we should
change update_cpu_capabilities to print "detected need for workaround:
blah" but you don't have to do it in this series.

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

Re: [Xen-devel] [PATCH 6/6] firmware/shim: fix build process to use POSIX find options

[Ian Jackson]

Wei Liu writes ("Re: [PATCH 6/6] firmware/shim: fix build process to use POSIX 
find options"):
> On Wed, Jan 17, 2018 at 04:55:01PM +, Ian Jackson wrote:
> > FYI I am going to ship the patch as is to "comet" users via an XSA-254
> > update.  I'm just quibbling about this for #staging.
> 
> Yeah, we can definitely change the rune to something better once we have
> all the critical issues solved. The rune was the best I could come up
> with under a short notice. And it wasn't critical so I moved on to
> something else.

Right, thanks.

Ian.

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

Re: [Xen-devel] [PATCH] ocaml: fix arm build

[Wei Liu]

CC Ocaml experts

On Wed, Jan 17, 2018 at 04:43:54PM +, Wei Liu wrote:
> ARM doesn't have emulation_flags in the arch_domainconfig.
> 
> Signed-off-by: Wei Liu 
> ---
> Cc: Ian Jackson 
> Cc: Julien Grall 
> Cc: Andrew Cooper 
> ---
>  tools/ocaml/libs/xc/xenctrl_stubs.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/tools/ocaml/libs/xc/xenctrl_stubs.c 
> b/tools/ocaml/libs/xc/xenctrl_stubs.c
> index 0b5a2361c0..fd128778b3 100644
> --- a/tools/ocaml/libs/xc/xenctrl_stubs.c
> +++ b/tools/ocaml/libs/xc/xenctrl_stubs.c
> @@ -175,11 +175,15 @@ CAMLprim value stub_xc_domain_create(value xch, value 
> ssidref,
>   caml_failwith("Unhandled: ARM");
>   break;
>  
> +#if defined(__i386__) || defined(__x86_64__)
>   case 1: /* X86 - emulation flags in the block */
>   for (l = Field(Field(domconfig, 0), 0);
>l != Val_none;
>l = Field(l, 1))
>   config.emulation_flags |= 1u << Int_val(Field(l, 0));
> +#else
> + caml_failwith("Unhandled: x86");
> +#endif
>   break;
>  
>   default:
> @@ -320,6 +324,7 @@ static value alloc_domaininfo(xc_domaininfo_t * info)
>  
>   Store_field(result, 15, tmp);
>  
> +#if defined(__i386__) || defined(__x86_64__)
>   /* emulation_flags: x86_arch_emulation_flags list; */
>   tmp = emul_list = Val_emptylist;
>   for (i = 0; i < 10; i++) {
> @@ -341,6 +346,7 @@ static value alloc_domaininfo(xc_domaininfo_t * info)
>   Store_field(arch_config, 0, x86_arch_config);
>  
>   Store_field(result, 16, arch_config);
> +#endif
>  
>   CAMLreturn(result);
>  }
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] [PATCH 6/6] firmware/shim: fix build process to use POSIX find options

[Wei Liu]

On Wed, Jan 17, 2018 at 04:55:01PM +, Ian Jackson wrote:
> Wei Liu writes ("Re: [PATCH 6/6] firmware/shim: fix build process to use 
> POSIX find options"):
> > On Wed, Jan 17, 2018 at 04:24:27PM +, Ian Jackson wrote:
> > > And finally, I don't really understand why it is necessary to strip
> > > $(XEN_ROOT)/$(d)/ out at all.
> > 
> > We want the path without $(XEN_ROOT)/$(d) so we can construct the same
> > tree under $(d). It is better to just look at the tree structure after
> > running the linkfarm rune.
> 
> Fair enough.  But I think my other points still stand.
> 
> FYI I am going to ship the patch as is to "comet" users via an XSA-254
> update.  I'm just quibbling about this for #staging.

Yeah, we can definitely change the rune to something better once we have
all the critical issues solved. The rune was the best I could come up
with under a short notice. And it wasn't critical so I moved on to
something else.

Wei.

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

Re: [Xen-devel] [PATCH 6/6] firmware/shim: fix build process to use POSIX find options

[Ian Jackson]

Wei Liu writes ("Re: [PATCH 6/6] firmware/shim: fix build process to use POSIX 
find options"):
> On Wed, Jan 17, 2018 at 04:24:27PM +, Ian Jackson wrote:
> > And finally, I don't really understand why it is necessary to strip
> > $(XEN_ROOT)/$(d)/ out at all.
> 
> We want the path without $(XEN_ROOT)/$(d) so we can construct the same
> tree under $(d). It is better to just look at the tree structure after
> running the linkfarm rune.

Fair enough.  But I think my other points still stand.

FYI I am going to ship the patch as is to "comet" users via an XSA-254
update.  I'm just quibbling about this for #staging.

Ian.

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

Re: [Xen-devel] [PATCH] ocaml: fix arm build

[Julien Grall]

Hi Wei,

On 17/01/18 16:43, Wei Liu wrote:

ARM doesn't have emulation_flags in the arch_domainconfig.

Signed-off-by: Wei Liu 


Reviewed-by: Julien Grall 

Cheers,


---
Cc: Ian Jackson 
Cc: Julien Grall 
Cc: Andrew Cooper 
---
  tools/ocaml/libs/xc/xenctrl_stubs.c | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/tools/ocaml/libs/xc/xenctrl_stubs.c 
b/tools/ocaml/libs/xc/xenctrl_stubs.c
index 0b5a2361c0..fd128778b3 100644
--- a/tools/ocaml/libs/xc/xenctrl_stubs.c
+++ b/tools/ocaml/libs/xc/xenctrl_stubs.c
@@ -175,11 +175,15 @@ CAMLprim value stub_xc_domain_create(value xch, value 
ssidref,
caml_failwith("Unhandled: ARM");
break;
  
+#if defined(__i386__) || defined(__x86_64__)

case 1: /* X86 - emulation flags in the block */
for (l = Field(Field(domconfig, 0), 0);
 l != Val_none;
 l = Field(l, 1))
config.emulation_flags |= 1u << Int_val(Field(l, 0));
+#else
+   caml_failwith("Unhandled: x86");
+#endif
break;
  
  	default:

@@ -320,6 +324,7 @@ static value alloc_domaininfo(xc_domaininfo_t * info)
  
  	Store_field(result, 15, tmp);
  
+#if defined(__i386__) || defined(__x86_64__)

/* emulation_flags: x86_arch_emulation_flags list; */
tmp = emul_list = Val_emptylist;
for (i = 0; i < 10; i++) {
@@ -341,6 +346,7 @@ static value alloc_domaininfo(xc_domaininfo_t * info)
Store_field(arch_config, 0, x86_arch_config);
  
  	Store_field(result, 16, arch_config);

+#endif
  
  	CAMLreturn(result);

  }



--
Julien Grall

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

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

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 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

version targeted for testing:
 xen  8d2983ec793362e8bcbe1a9a36d3eee61bc187f0
baseline version:
 xen  e871e80c38547d9faefc6604532ba3e985e65873

Last test of basis   118105  2018-01-16 17:04:09 Z0 days
Failing since118110  2018-01-16 19:02:12 Z0 days   11 attempts
Testing same since   118162  2018-01-17 15:01:29 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Anthony Liguori 
  Bob Moore 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Jon Ludlam 
  Jonathan Ludlam 
  Lv Zheng 
  Rafael J. Wysocki 
  Roger Pau Monne 
  Roger Pau Monné 
  Sergey Dyasli 
  Wei Liu 

jobs:
 build-arm64-xsm  pass
 build-amd64  pass
 build-armhf  fail
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  blocked 
 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


Not pushing.

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

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

[Xen-devel] [PATCH v4] kexec-tools: Perform run-time linking of libxenctrl.so

[Eric DeVolder]

When kexec is utilized in a Xen environment, it has an explicit
run-time dependency on libxenctrl.so. This dependency occurs
during the configure stage and when building kexec-tools.

When kexec is utilized in a non-Xen environment (either bare
metal or KVM), the configure and build of kexec-tools omits
any reference to libxenctrl.so.

Thus today it is not currently possible to configure and build
a *single* kexec that will work in *both* Xen and non-Xen
environments, unless the libxenctrl.so is *always* present.

For example, a kexec configured for Xen in a Xen environment:

 # ldd build/sbin/kexec
linux-vdso.so.1 =>  (0x7ffdeba5c000)
libxenctrl.so.4.4 => /usr/lib64/libxenctrl.so.4.4 (0x0038d800)
libz.so.1 => /lib64/libz.so.1 (0x0038d6c0)
libc.so.6 => /lib64/libc.so.6 (0x0038d600)
libdl.so.2 => /lib64/libdl.so.2 (0x0038d640)
libpthread.so.0 => /lib64/libpthread.so.0 (0x0038d680)
/lib64/ld-linux-x86-64.so.2 (0x55e9f8c6c000)
 # build/sbin/kexec -v
 kexec-tools 2.0.16

However, the *same* kexec executable fails in a non-Xen environment:

 # copy xen kexec to .
 # ldd ./kexec
 linux-vdso.so.1 =>  (0x7fffa9da7000)
 libxenctrl.so.4.4 => not found
 liblzma.so.0 => /usr/lib64/liblzma.so.0 (0x003014e0)
 libz.so.1 => /lib64/libz.so.1 (0x00300ea0)
 libc.so.6 => /lib64/libc.so.6 (0x00300de0)
 libpthread.so.0 => /lib64/libpthread.so.0 (0x00300e20)
 /lib64/ld-linux-x86-64.so.2 (0x558cc786c000)
 # ./kexec -v
 ./kexec: error while loading shared libraries:
 libxenctrl.so.4.4: cannot open shared object file: No such file or directory

At Oracle we "workaround" this by having two kexec-tools packages,
one for Xen and another for non-Xen environments. At Oracle, the
desire is to offer a single kexec-tools package that works in either
environment. To achieve this, kexec-tools would either have to ship
with libxenctrl.so (which we have deemed as unacceptable), or we can
make kexec perform run-time linking against libxenctrl.so.

This patch is one possible way to alleviate the explicit run-time
dependency on libxenctrl.so. This implementation utilizes a set of
macros to wrap calls into libxenctrl.so so that the library can
instead be dlopen() and obtain the function via dlsym() and then
make the call. The advantage of this implementation is that it
requires few changes to the existing kexec-tools code. The dis-
advantage is that it uses macros to remap libxenctrl functions
and do work under the hood.

Another possible implementation worth considering is the approach
taken by libvmi. Reference the following file:

https://github.com/libvmi/libvmi/blob/master/libvmi/driver/xen/libxc_wrapper.h

The libxc_wrapper_t structure definition that starts at line ~33
has members that are function pointers into libxenctrl.so. This
structure is populated once and then later referenced/dereferenced
by the callers of libxenctrl.so members. The advantage of this
implementation is it is more explicit in managing the use of
libxenctrl.so and its versions, but the disadvantage is it would
require touching more of the kexec-tools code.

The following is a list libxenctrl members utilized by kexec:

Functions:
xc_interface_open
xc_kexec_get_range
xc_interface_close
xc_kexec_get_range
xc_interface_open
xc_get_max_cpus
xc_kexec_get_range
xc_version
xc_kexec_exec
xc_kexec_status
xc_kexec_unload
xc_hypercall_buffer_array_create
xc__hypercall_buffer_array_alloc
xc_hypercall_buffer_array_destroy
xc_kexec_load
xc_get_machine_memory_map

Data:
xc__hypercall_buffer_HYPERCALL_BUFFER_NULL

These were identified by configuring and building kexec-tools
with Xen support, but omitting the -lxenctrl from the LDFLAGS
in the Makefile for an x86_64 build.

The above libxenctrl members were referenced via these source
files.

kexec/crashdump-xen.c
kexec/kexec-xen.c
kexec/arch/i386/kexec-x86-common.c
kexec/arch/i386/crashdump-x86.c

This patch provides a wrapper around the calls to the above
functions in libxenctrl.so. Every libxenctrl call must pass a
xc_interface which it obtains from xc_interface_open().
So the existing code is already structured in a manner that
facilitates graceful dlopen()'ing of the libxenctrl.so and
the subsequent dlsym() of the required member.

The patch creates a wrapper function around xc_interface_open()
and xc_interface_close() to perform the dlopen() and dlclose().

For the remaining xc_ functions, this patch defines a macro
of the same name which performs the dlsym() and then invokes
the function. See the __xc_call() macro for details.

There was one data item in libxenctrl.so that presented a
unique problem, HYPERCALL_BUFFER_NULL. It was only utilized
once, as

set_xen_guest_handle(xen_segs[s].buf.h, HYPERCALL_BUFFER_NULL);

I tried a variety of techniques but could not find a general
macro-type solution without modifying xenctrl.h. 

Re: [Xen-devel] [PATCH v3] kexec-tools: Perform run-time linking of libxenctrl.so

[Eric DeVolder]

Responses are inlined below.
Eric

On 01/16/2018 03:39 PM, Daniel Kiper wrote:

On Fri, Jan 12, 2018 at 03:21:13PM -0600, Eric DeVolder wrote:

When kexec is utilized in a Xen environment, it has an explicit
run-time dependency on libxenctrl.so. This dependency occurs
during the configure stage and when building kexec-tools.

When kexec is utilized in a non-Xen environment (either bare
metal or KVM), the configure and build of kexec-tools omits
any reference to libxenctrl.so.


[...]

Wow! What a long story! Patch looks quite good. Just a few nitpicks.
If you fix them then you can add Reviewed-by: Daniel Kiper 
 to the next version.


Thanks, I've incorporated all these and added your RB and posted V4.




Signed-off-by: Eric DeVolder 
---
v1: 29nov2017
  - Daniel Kiper suggested Debian's libxen package of libraries,
but I did not find similar package on most other systems.

v2: 14dec2017
  - Reposted to kexec and xen-devel mailing lists

v3: 12jan2018
  - Incorporated feedback from Daniel Kiper.
Configure changes for --with-xen=dl, style problems corrected.
Extensive testing of the new mode.
---
  configure.ac   | 27 ++
  kexec/Makefile |  1 +
  kexec/arch/i386/crashdump-x86.c|  4 +--
  kexec/arch/i386/kexec-x86-common.c |  4 +--
  kexec/crashdump-xen.c  |  4 +--
  kexec/kexec-xen.c  | 41 -
  kexec/kexec-xen.h  | 73 ++
  7 files changed, 138 insertions(+), 16 deletions(-)
  create mode 100644 kexec/kexec-xen.h

diff --git a/configure.ac b/configure.ac
index 208dc0a..4dab57f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -167,12 +167,27 @@ if test "$with_xen" = yes ; then
AC_CHECK_HEADER(xenctrl.h,
[AC_CHECK_LIB(xenctrl, xc_kexec_load, ,
AC_MSG_NOTICE([Xen support disabled]))])
-   if test "$ac_cv_lib_xenctrl_xc_kexec_load" = yes ; then
-   AC_CHECK_LIB(xenctrl, xc_kexec_status,
-   AC_DEFINE(HAVE_KEXEC_CMD_STATUS, 1,
-   [The kexec_status call is available]),
-   AC_MSG_NOTICE([The kexec_status call is not 
available]))
-   fi
+fi
+
+dnl Link libxenctrl.so at run-time rather than build-time
+if test "$with_xen" = dl ; then
+   AC_CHECK_HEADER(dlfcn.h,
+   [AC_CHECK_LIB(dl, dlopen, ,
+   AC_MSG_ERROR([Dynamic library linking not available]))],
+   AC_MSG_ERROR([Dynamic library linking not available]))


I think that this error message should be like this:
   Dynamic library linking header not available


done




+   AC_DEFINE(CONFIG_LIBXENCTRL_DL, 1, [Define to 1 to link libxenctrl.so 
at run-time rather than build-time])
+   AC_CHECK_HEADER(xenctrl.h,
+   [AC_CHECK_LIB(xenctrl, xc_kexec_load,
+   AC_DEFINE(HAVE_LIBXENCTRL, 1, ), # required define, and prevent 
-lxenctrl
+   AC_MSG_NOTICE([Xen support disabled]))])
+fi
+
+dnl Check for the Xen kexec_status hypercall - reachable from --with-xen=yes|dl
+if test "$ac_cv_lib_xenctrl_xc_kexec_load" = yes ; then
+   AC_CHECK_LIB(xenctrl, xc_kexec_status,
+   AC_DEFINE(HAVE_KEXEC_CMD_STATUS, 1,
+   [The kexec_status call is available]),
+   AC_MSG_NOTICE([The kexec_status call is not available]))
  fi

  dnl ---Sanity checks
diff --git a/kexec/Makefile b/kexec/Makefile
index 2b4fb3d..8871731 100644
--- a/kexec/Makefile
+++ b/kexec/Makefile
@@ -36,6 +36,7 @@ dist += kexec/Makefile
\
kexec/kexec-elf-boot.h  \
kexec/kexec-elf.h kexec/kexec-sha256.h  \
kexec/kexec-zlib.h kexec/kexec-lzma.h   \
+   kexec/kexec-xen.h   
\


Could you fix backslash alignment? Maybe in separate patch. It can be
part of this series.


Turns out I had tabstop=4 and it should have been tabstop=8. I've 
corrected my tabstop and the backslash alignment and everything aligns 
now; no additional patch needed.





kexec/kexec-syscall.h kexec/kexec.h kexec/kexec.8

  dist  += kexec/proc_iomem.c
diff --git a/kexec/arch/i386/crashdump-x86.c b/kexec/arch/i386/crashdump-x86.c
index 69a063a..a948d9f 100644
--- a/kexec/arch/i386/crashdump-x86.c
+++ b/kexec/arch/i386/crashdump-x86.c
@@ -44,9 +44,7 @@
  #include "kexec-x86.h"
  #include "crashdump-x86.h"



Please remove this blank line...


done




-#ifdef HAVE_LIBXENCTRL
-#include 
-#endif /* HAVE_LIBXENCTRL */
+#include "../../kexec-xen.h"



...and this... Same things below... This was done to separate
conditional include from unconditional ones. So, blank lines
after your patch are no 

[Xen-devel] [PATCH] ocaml: fix arm build

[Wei Liu]

ARM doesn't have emulation_flags in the arch_domainconfig.

Signed-off-by: Wei Liu 
---
Cc: Ian Jackson 
Cc: Julien Grall 
Cc: Andrew Cooper 
---
 tools/ocaml/libs/xc/xenctrl_stubs.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/tools/ocaml/libs/xc/xenctrl_stubs.c 
b/tools/ocaml/libs/xc/xenctrl_stubs.c
index 0b5a2361c0..fd128778b3 100644
--- a/tools/ocaml/libs/xc/xenctrl_stubs.c
+++ b/tools/ocaml/libs/xc/xenctrl_stubs.c
@@ -175,11 +175,15 @@ CAMLprim value stub_xc_domain_create(value xch, value 
ssidref,
caml_failwith("Unhandled: ARM");
break;
 
+#if defined(__i386__) || defined(__x86_64__)
case 1: /* X86 - emulation flags in the block */
for (l = Field(Field(domconfig, 0), 0);
 l != Val_none;
 l = Field(l, 1))
config.emulation_flags |= 1u << Int_val(Field(l, 0));
+#else
+   caml_failwith("Unhandled: x86");
+#endif
break;
 
default:
@@ -320,6 +324,7 @@ static value alloc_domaininfo(xc_domaininfo_t * info)
 
Store_field(result, 15, tmp);
 
+#if defined(__i386__) || defined(__x86_64__)
/* emulation_flags: x86_arch_emulation_flags list; */
tmp = emul_list = Val_emptylist;
for (i = 0; i < 10; i++) {
@@ -341,6 +346,7 @@ static value alloc_domaininfo(xc_domaininfo_t * info)
Store_field(arch_config, 0, x86_arch_config);
 
Store_field(result, 16, arch_config);
+#endif
 
CAMLreturn(result);
 }
-- 
2.11.0


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

Re: [Xen-devel] [PATCH 6/6] firmware/shim: fix build process to use POSIX find options

[Wei Liu]

On Wed, Jan 17, 2018 at 04:24:27PM +, Ian Jackson wrote:
> Roger Pau Monne writes ("[PATCH 6/6] firmware/shim: fix build process to use 
> POSIX find options"):
> > The -printf find option is not POSIX compatible, so replace it with
> > another rune.
> ...
> >   cd $(D)/$(d); \
> > - find $(XEN_ROOT)/$(d)/ -type d -printf "./%P\n" |  xargs 
> > mkdir -p);)
> > + find $(XEN_ROOT)/$(d)/ -type d -exec sh -c \
> > + "echo {} | sed 's,^$(XEN_ROOT)/$(d)/,,g' | xargs mkdir 
> > -p" \;);)
> 
> This is now a pretty nasty shell construct.
> 
> If you're going to use sed, you could just
>find ... -print | sed ... | xargs mkdir -p
> 
> Substituting {} into the middle of the shell rune is bad practice in
> general because it might contain metacharacters or spaces.  In our
> build system this doesn't matter because that breaks anyway, but it's
> very poor style (and also it buries the actual data flow path into the
> middle of a complicated manglement).
> 
> If you wanted to use -exec and sh, you could do something like this
>-exec sh -c 'exec mkdir "${1#$(XEN_ROOT}/$(d)/}"' x {}
> maybe.
> 
> And finally, I don't really understand why it is necessary to strip
> $(XEN_ROOT)/$(d)/ out at all.
> 

We want the path without $(XEN_ROOT)/$(d) so we can construct the same
tree under $(d). It is better to just look at the tree structure after
running the linkfarm rune.

Wei.

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

Re: [Xen-devel] [PATCH 6/6] firmware/shim: fix build process to use POSIX find options

[Ian Jackson]

Roger Pau Monne writes ("[PATCH 6/6] firmware/shim: fix build process to use 
POSIX find options"):
> The -printf find option is not POSIX compatible, so replace it with
> another rune.
...
> cd $(D)/$(d); \
> -   find $(XEN_ROOT)/$(d)/ -type d -printf "./%P\n" |  xargs 
> mkdir -p);)
> +   find $(XEN_ROOT)/$(d)/ -type d -exec sh -c \
> +   "echo {} | sed 's,^$(XEN_ROOT)/$(d)/,,g' | xargs mkdir 
> -p" \;);)

This is now a pretty nasty shell construct.

If you're going to use sed, you could just
   find ... -print | sed ... | xargs mkdir -p

Substituting {} into the middle of the shell rune is bad practice in
general because it might contain metacharacters or spaces.  In our
build system this doesn't matter because that breaks anyway, but it's
very poor style (and also it buries the actual data flow path into the
middle of a complicated manglement).

If you wanted to use -exec and sh, you could do something like this
   -exec sh -c 'exec mkdir "${1#$(XEN_ROOT}/$(d)/}"' x {}
maybe.

And finally, I don't really understand why it is necessary to strip
$(XEN_ROOT)/$(d)/ out at all.

Ian.

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

Re: [Xen-devel] Access I2C bus from guest/DomU on ARM board

[Andrii Anisov]

Rajesh,

On 17.01.18 16:03, Saumya Rajesh wrote:
Just out of curiosity, is it possible to split the Driver for the 
Renesas RCar I2C unit [1] into frontend and backend to use the i2c bus 
from guest? Or to do something similar to PCI passthrough? Please 
forgive me if I sound illogical. I'm just curious.
I guess you could implement PV I2C using FE/BE scheme. With enormous 
efforts and unpredictable results.

But I'm sure it is not what you really need.

--

*Andrii Anisov*



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

Re: [Xen-devel] [Embedded-pv-devel] Xen on RCarH3 Starter Kit

[Andrii Anisov]

Hello Ganesh

On 17.01.18 15:33, Ganesh H wrote:

Dear Andrii,

Sorry for the confusion. I am having an RCarH3 starter kit. Is there a Xen port 
available for RCarH3 starter kit right now?

We did not run XEN on h3ulcb. But it can be done with minimal efforts IMHO.


If not what are the steps to create one?


Steps should be as easy as I've already listed :


Add a h3ulcb device tree to [3], update recipe [2].
Do not forget to PR the stuff to our meta-demo.

[2] - 
https://github.com/xen-troops/meta-demo/blob/master/meta-rcar-gen3-xen/recipes-extended/xen/xen_git.bbappend#L17

[3] - 
https://github.com/xen-troops/meta-demo/tree/master/meta-rcar-gen3-xen/recipes-kernel/linux/linux-renesas


--

*Andrii Anisov*


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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-arm64-arm64-xl-xsm  12 guest-start  fail REGR. vs. 118105
 build-armhf   6 xen-buildfail REGR. vs. 118105

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass

version targeted for testing:
 xen  db3ae8becc2b4f9f544eafa06a7c858c7cc9f029
baseline version:
 xen  e871e80c38547d9faefc6604532ba3e985e65873

Last test of basis   118105  2018-01-16 17:04:09 Z0 days
Failing since118110  2018-01-16 19:02:12 Z0 days   10 attempts
Testing same since   118160  2018-01-17 13:01:46 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Anthony Liguori 
  Bob Moore 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Jon Ludlam 
  Jonathan Ludlam 
  Lv Zheng 
  Rafael J. Wysocki 
  Roger Pau Monne 
  Roger Pau Monné 
  Sergey Dyasli 
  Wei Liu 

jobs:
 build-arm64-xsm  pass
 build-amd64  pass
 build-armhf  fail
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  fail
 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


Not pushing.

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

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

Re: [Xen-devel] [PATCH 1/5] x86/idt: Factor out enabling and disabling of ISTs

[Wei Liu]

On Fri, Jan 12, 2018 at 06:37:20PM +, Andrew Cooper wrote:
> All alteration of IST settings (other than the crash path) happen in an
> identical triple.  Introduce helpers to keep the triple in sync, and reduce
> the risk of opencoded mistakes.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Wei Liu 

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

Re: [Xen-devel] [PATCH 2/5] x86/pv: Rename invalidate_shadow_ldt() to pv_destroy_ldt()

[Wei Liu]

On Fri, Jan 12, 2018 at 06:37:21PM +, Andrew Cooper wrote:
> and move it into pv/descriptor-tables.c beside its GDT counterpart.  Reduce
> the !in_irq() check from a BUG_ON() to ASSERT().
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Wei Liu 

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

Re: [Xen-devel] [PATCH 1/5] xen/arm: Introduce enable callback to enable a capabilities on each online CPU

[Lars Kurth]

Hi Julien,

> On 17 Jan 2018, at 12:31, Julien Grall  wrote:
> 
> 
 If you took the code from Linux, you need to add the original
 Signed-off-by from the Linux commit. Aside from that:
>>> 
>>> There are multiple commits touching this function. So I followed what we 
>>> did in similar situation. By that I mean, mentioning the code was taken 
>>> from Linux and not gathered the signed-off-by.
>>> 
>>> If you really want, I can gather all the signed-off-by of the commit 
>>> touching this function.
>> If there are a lot of then, you may want to consider adding a README.source 
>> file instead. There are a few examples in tree and they are also mentioned 
>> in CONTRIBUTING files
> 
> I am not sure to understand your suggestion here. I spotted only one 
> CONTRIBUTING file and it only list the license.

I was suggesting to create a README.source in the xen arm tree seomwhere where 
you can list imports.

> Regarding README.source, this is covering file and contain the same mention 
> as in the commit message. As this is a single function. Isn't the commit 
> message enough?

From a legal viewpoint it is enough.
The reason why we created the README.source file is because it is very easy to 
miss code imports when they are mentioned in commit messages.

Normally this isn't a problem: only if we ever have to relicense the code or if 
someone does code archeology 
When we relicensed the ACPI builder, it created all sorts of problems as 
outlined in 
https://www.slideshare.net/xen_com_mgr/ossa17-mixed-license-foss-projects 


> Lastly, we do have quite a bit of code in Xen coming from Linux (or other 
> project). A lot of them are not listed in README.source/CONTRIBUTING. But 
> only mention in the commit message (not necessarily with Signed-off-by tag).

That is true: which is why I have started fixing these, whenever I found them 
and moved such information to README.source. 

> So I am quite interested to know what is the normal procedure here.

I think:
* Doing this via Signed-off-by tag is sufficient for a one-off-import
* I would prefer if people added import related info README.source files (and 
also in the commit message)

Does this make sense?

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

[Xen-devel] [PATCH] Revert "xl: Default guest mode changed from PV to PVH with PV shim"

[Ian Jackson]

This breaks ARM.  It should be protected by some x86 #if.  For now,
revert it, as it's not critical (and it isn't included in the
comet/vixen security patch branches published via XSA-254).

This reverts commit 63080b704351022cb7badb73339d47646fb465bd.

Signed-off-by: Ian Jackson 
CC: Wei Liu 
CC: Julien Grall 
---
 tools/xl/xl_parse.c | 13 +++--
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
index 2a53ac0..fdfe693 100644
--- a/tools/xl/xl_parse.c
+++ b/tools/xl/xl_parse.c
@@ -939,12 +939,8 @@ void parse_config_data(const char *config_source,
 c_info->type = builder_type;
 }
 
-static bool pvshim_default_enable = 0;
-
-if (c_info->type == LIBXL_DOMAIN_TYPE_INVALID) {
-c_info->type = LIBXL_DOMAIN_TYPE_PVH;
-pvshim_default_enable = 1;
-}
+if (c_info->type == LIBXL_DOMAIN_TYPE_INVALID)
+c_info->type = LIBXL_DOMAIN_TYPE_PV;
 
 xlu_cfg_get_defbool(config, "hap", _info->hap, 0);
 
@@ -970,10 +966,7 @@ void parse_config_data(const char *config_source,
 libxl_domain_build_info_init_type(b_info, c_info->type);
 
 if (b_info->type == LIBXL_DOMAIN_TYPE_PVH) {
-if (xlu_cfg_get_defbool(config, "pvshim", _info->u.pvh.pvshim, 0)
-&& pvshim_default_enable)
-libxl_defbool_set(_info->u.pvh.pvshim, 1);
-
+xlu_cfg_get_defbool(config, "pvshim", _info->u.pvh.pvshim, 0);
 if (!xlu_cfg_get_string(config, "pvshim_path", , 0))
 xlu_cfg_replace_string(config, "pvshim_path",
_info->u.pvh.pvshim_path, 0);
-- 
2.1.4


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

Re: [Xen-devel] Access I2C bus from guest/DomU on ARM board

[Saumya Rajesh]

On Tue, Jan 16, 2018 at 9:22 PM, Andrii Anisov 
wrote:

> Dear Rajesh,
>
>
> You can try to get an I2C bus controller in DomU in PIO mode following
> [1], keeping in mind [2].
>
> If you want it DMA capable you need Renesas IPMMU support in XEN [3], [4]
> to be incorporated.
>
>
> [1] - https://xenbits.xen.org/docs/unstable/misc/arm/passthrough.txt
>
> [2] - https://lists.xenproject.org/archives/html/xen-users/2017-10
> /msg00031.html
>
> [3] - https://lists.xenproject.org/archives/html/xen-devel/2017-07
> /msg02545.html
>
> [4] - https://lists.xenproject.org/archives/html/xen-devel/2017-07
> /msg02679.html
>
>
> --
>
> *Andrii Anisov*
>
>
>
Thank you Andrii for replying. I will try the device passthrough way of
using I2C bus from guest and post the updates.

Just out of curiosity, is it possible to split the Driver for the Renesas
RCar I2C unit [1] into frontend and backend to use the i2c bus from guest?
Or to do something similar to PCI passthrough? Please forgive me if I sound
illogical. I'm just curious.

Regards
Saumya

[1]
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/drivers/i2c/busses/i2c-rcar.c?h=v4.14.13
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] xl: Unable to boot Xen Arm guest when using latest staging

[Julien Grall]

Hi all,

Just a quick heads-up before I go into debugging.

I have built and install the latest staging (db3ae8becc) for Arm.
When I boot a guest, I get the following error message:

libxl: debug: libxl_create.c:1664:do_domain_create: Domain 0:ao 0x386e44d0: 
create: how=(nil) callback=(nil) poller=0x386e0b50
libxl: debug: libxl_arm.c:87:libxl__arch_domain_prepare_config: Configure the 
domain
libxl: debug: libxl_arm.c:90:libxl__arch_domain_prepare_config:  - Allocate 0 
SPIs
libxl: debug: libxl_create.c:1005:initiate_domain_create: Domain 1:running 
bootloader
libxl: debug: libxl_bootloader.c:335:libxl__bootloader_run: Domain 1:no 
bootloader configured, using user supplied kernel
libxl: debug: libxl_event.c:686:libxl__ev_xswatch_deregister: watch 
w=0x386e3078: deregister unregistered
(XEN) grant_table.c:1680:d0v3 Expanding d1 grant table from 0 to 1 frames
domainbuilder: detail: xc_dom_allocate: cmdline="pv-shim console=xen,pv 
sched=null", features=""
domainbuilder: detail: xc_dom_kernel_file: 
filename="/usr/local/lib/xen/boot/xen-shim"
xc: error: panic: xc_dom_core.c:208: failed to open file 
'/usr/local/lib/xen/boot/xen-shim': No such file or directory: Internal error
domainbuilder: detail: xc_dom_malloc_filemap: failed (on file 
`/usr/local/lib/xen/boot/xen-shim')
libxl: error: libxl_dom.c:1032:libxl__domain_firmware: xc_dom_kernel_file 
failed: No such file or directory
libxl: error: libxl_dom.c:1220:libxl__build_hvm: initializing domain firmware 
failed
domainbuilder: detail: xc_dom_release: called
libxl: error: libxl_create.c:1264:domcreate_rebuild_done: Domain 1:cannot 
(re-)build domain: -1
libxl: debug: libxl_domain.c:1138:devices_destroy_cb: Domain 1:Forked pid 1217 
for destroy of domain
libxl: debug: libxl_create.c:1701:do_domain_create: Domain 0:ao 0x386e44d0: 
inprogress: poller=0x386e0b50, flags=i
libxl: debug: libxl_event.c:1869:libxl__ao_complete: ao 0x386e44d0: complete, 
rc=-3
libxl: debug: libxl_event.c:1838:libxl__ao__destroy: ao 0x386e44d0: destroy
libxl: debug: libxl_domain.c:868:libxl_domain_destroy: Domain 1:ao 0x386e44d0: 
create: how=(nil) callback=(nil) poller=0x386e0b50
libxl: error: libxl_domain.c:1000:libxl__destroy_domid: Domain 1:Non-existant 
domain
libxl: error: libxl_domain.c:959:domain_destroy_callback: Domain 1:Unable to 
destroy guest
libxl: error: libxl_domain.c:886:domain_destroy_cb: Domain 1:Destruction of 
domain failed
libxl: debug: libxl_event.c:1869:libxl__ao_complete: ao 0x386e44d0: complete, 
rc=-21
libxl: debug: libxl_domain.c:877:libxl_domain_destroy: Domain 1:ao 0x386e44d0: 
inprogress: poller=0x386e0b50, flags=ic
libxl: debug: libxl_event.c:1838:libxl__ao__destroy: ao 0x386e44d0: destroy
xencall:buffer: debug: total allocations:75 total releases:75
xencall:buffer: debug: current allocations:0 maximum allocations:3
xencall:buffer: debug: cache current size:3
xencall:buffer: debug: cache hits:61 misses:3 toobig:11
xencall:buffer: debug: total allocations:0 total releases:0
xencall:buffer: debug: current allocations:0 maximum allocations:0
xencall:buffer: debug: cache current size:0
xencall:buffer: debug: cache hits:0 misses:0 toobig:0

The configuration file is:

name="guest"
memory= "256"
kernel= "/root/Image"
ramdisk= "/root/initramfs"
extra= "console=hvc0"
vcpus= 1

Cheers,

-- 
Julien Grall

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

[Xen-devel] [PATCH v2] x86/efi: fix build with linkers that support both coff-x86-64 and pe-x86-64

[Roger Pau Monne]

When using a linker that supports both formats the following error
will be triggered:

efi/buildid.o: file not recognized: File format is ambiguous
efi/buildid.o: matching formats: coff-x86-64 pe-x86-64

Solve this by specifying the efi/buildid.o format to pe-x86-64.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Doug Goldstein 
---
Changes since v1:
 - Add note_file_option in order to store the linker options plus
   object file.
 - Add a comment that the note_file_option must be the last input in
   the linker call.
---
 xen/arch/x86/Makefile | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 8a39965026..d903b7abb9 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -178,30 +178,34 @@ ifeq ($(call ld-ver-build-id,$(LD) $(filter 
-m%,$(EFI_LDFLAGS))),y)
 CFLAGS += -DBUILD_ID_EFI
 EFI_LDFLAGS += $(build_id_linker)
 note_file := efi/buildid.o
+# NB: this must be the last input in the linker call, because inputs following
+# the -b option will all be treated as being in the specified format.
+note_file_option := -b pe-x86-64 $(note_file)
 else
 note_file := note.o
 endif
 else
 note_file :=
 endif
+note_file_option ?= $(note_file)
 
 $(TARGET).efi: prelink-efi.o $(note_file) efi.lds efi/relocs-dummy.o 
$(BASEDIR)/common/symbols-dummy.o efi/mkreloc
$(foreach base, $(VIRT_BASE) $(ALT_BASE), \
  $(guard) $(LD) $(call EFI_LDFLAGS,$(base)) -T efi.lds -N $< 
efi/relocs-dummy.o \
-   $(BASEDIR)/common/symbols-dummy.o $(note_file) -o 
$(@D)/.$(@F).$(base).0 &&) :
+   $(BASEDIR)/common/symbols-dummy.o $(note_file_option) 
-o $(@D)/.$(@F).$(base).0 &&) :
$(guard) efi/mkreloc $(foreach base,$(VIRT_BASE) 
$(ALT_BASE),$(@D)/.$(@F).$(base).0) >$(@D)/.$(@F).0r.S
$(guard) $(NM) -pa --format=sysv $(@D)/.$(@F).$(VIRT_BASE).0 \
| $(guard) $(BASEDIR)/tools/symbols $(all_symbols) --sysv 
--sort >$(@D)/.$(@F).0s.S
$(guard) $(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).0r.o 
$(@D)/.$(@F).0s.o
$(foreach base, $(VIRT_BASE) $(ALT_BASE), \
  $(guard) $(LD) $(call EFI_LDFLAGS,$(base)) -T efi.lds -N $< \
-   $(@D)/.$(@F).0r.o $(@D)/.$(@F).0s.o $(note_file) -o 
$(@D)/.$(@F).$(base).1 &&) :
+   $(@D)/.$(@F).0r.o $(@D)/.$(@F).0s.o $(note_file_option) 
-o $(@D)/.$(@F).$(base).1 &&) :
$(guard) efi/mkreloc $(foreach base,$(VIRT_BASE) 
$(ALT_BASE),$(@D)/.$(@F).$(base).1) >$(@D)/.$(@F).1r.S
$(guard) $(NM) -pa --format=sysv $(@D)/.$(@F).$(VIRT_BASE).1 \
| $(guard) $(BASEDIR)/tools/symbols $(all_symbols) --sysv 
--sort >$(@D)/.$(@F).1s.S
$(guard) $(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).1r.o 
$(@D)/.$(@F).1s.o
$(guard) $(LD) $(call EFI_LDFLAGS,$(VIRT_BASE)) -T efi.lds -N $< \
-   $(@D)/.$(@F).1r.o $(@D)/.$(@F).1s.o $(note_file) -o $@
+   $(@D)/.$(@F).1r.o $(@D)/.$(@F).1s.o $(note_file_option) 
-o $@
if $(guard) false; then rm -f $@; echo 'EFI support disabled'; \
else $(NM) -pa --format=sysv $(@D)/$(@F) \
| $(BASEDIR)/tools/symbols --xensyms --sysv --sort 
>$(@D)/$(@F).map; fi
-- 
2.15.1


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

Re: [Xen-devel] [PATCH] x86/hvm: more sure APIC assist is aborted if guest EOIs APIC

[Paul Durrant]

> -Original Message-
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: 17 January 2018 12:54
> To: xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; Jan Beulich
> ; Andrew Cooper 
> Subject: [PATCH] x86/hvm: more sure APIC assist is aborted if guest EOIs
> APIC

Sorry, I typo-ed the title. If there the no objections to the patch then 
hopefully this can be fixed up on commit.

  Paul

> 
> It appears there is a case where Windows enables the APIC assist
> enlightenment (see Microsoft Hypervisor Top Level Functional Spec. 5.0b,
> section 10.3.5) but does not use it. This scenario is perfectly valid
> according to the documentation, but causes the state machine in Xen to
> become confused leading to a domain_crash() such as the following:
> 
> (XEN) d4: VIRIDIAN GUEST_OS_ID: vendor: 1 os: 4 major: 6 minor: 1 sp: 0
>   build: 1db0
> (XEN) d4: VIRIDIAN HYPERCALL: enabled: 1 pfn: 3
> (XEN) d4v0: VIRIDIAN VP_ASSIST_PAGE: enabled: 1 pfn: 3fffe
> (XEN) domain_crash called from viridian.c:452
> (XEN) Domain 4 (vcpu#0) crashed on cpu#1:
> 
> The following sequence of events is an example of how this can happen:
> 
> - On return to guest vlapic_has_pending_irq() finds a bit set in the IRR.
> - vlapic_ack_pending_irq() calls viridian_start_apic_assist() which latches
>   the vector, sets the bit in the ISR and clears it from the IRR.
> - The guest then processes the interrupt but EOIs it normally, therefore
>   clearing the bit in the ISR.
> - On next return to guest vlapic_has_pending_irq() calls
>   viridian_complete_apic_assist(), which discovers the assist bit still set
>   in the shared page and therefore leaves the latched vector in place, but
>   also finds another bit set in the IRR.
> - vlapic_ack_pending_irq() is then called but, because the ISR is was
>   cleared by the EOI, another call is made to viridian_start_apic_assist()
>   and this then calls domain_crash() because it finds the latched vector
>   has not been cleared.
> 
> This patch adds a call to viridian_abort_apic_assist() into vlapic EOI
> handler to make sure any latched vector is cleared when the ISR is cleared.
> 
> Signed-off-by: Paul Durrant 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> ---
>  xen/arch/x86/hvm/vlapic.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
> index 50f53bdaef..3184970c6e 100644
> --- a/xen/arch/x86/hvm/vlapic.c
> +++ b/xen/arch/x86/hvm/vlapic.c
> @@ -422,6 +422,13 @@ void vlapic_EOI_set(struct vlapic *vlapic)
>  if ( vector == -1 )
>  return;
> 
> +/*
> + * It is possible that APIC assist has been enabled by the guest but
> + * it has chosen not to use it, by EOIing normally. It is therefore
> + * necessary to abort any APIC assist that may have been started
> + * to avoid confusing the state machine.
> + */
> +viridian_abort_apic_assist(vlapic_vcpu(vlapic));
>  vlapic_clear_vector(vector, >regs->data[APIC_ISR]);
> 
>  if ( hvm_funcs.handle_eoi )
> --
> 2.11.0


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

Re: [Xen-devel] [PATCH for-4.10.0-shim-comet] x86/guest: use the vcpu_info area from shared_info

[Jan Beulich]

>>> On 17.01.18 at 12:04,  wrote:
> On 01/17/2018 10:57 AM, Roger Pau Monne wrote:
>> If using less than 32 vCPUs (XEN_LEGACY_MAX_VCPUS).
>> 
>> This is a workaround that should allow to boot the shim on hypervisors
>> without commit "x86/upcall: inject a spurious event after setting
>> upcall vector" as long as less than 32 vCPUs are assigned to the
>> shim.
>> 
>> Signed-off-by: Roger Pau Monné 
>> ---
>> Cc: Jan Beulich 
>> Cc: Andrew Cooper 
>> Cc: Wei Liu 
>> Cc: Ian Jackson 
>> Cc: George Dunlap 
>> ---
>> ONLY apply to the 4.10.0-shim-comet branch. Long term we don't want to
>> carry this patch since it would prevent the vcpu_info mapping code
>> from being tested unless a shim with > 32 vCPUs is created, which
>> doesn't seem very common.
> 
> Just to fill this out a bit:
> 
> Without this patch, people need to reboot their L0 hypervisor in order
> to use Comet.
> 
> With this patch, people only need to compile and update their L0 tools
> to use Comet; they can avoid rebooting their L0 hypervisor.
> 
> Roger would like to avoid checking this in to staging, because he's
> afraid it might make the >32vcpu path bitrot.
> 
> The risk of checking it into the Comet branches but not staging is that
> if people update their shim to "Rudolph" (4.11) without rebooting their
> host, things may unexpectedly not work.  I think that's something we can
> live with.

I agree. I'm not sure this patch going into that branch only needs
an x86 maintainers ack, but if so, feel free to add mine.

Jan

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-xsm   6 xen-buildfail REGR. vs. 118105
 build-armhf   6 xen-buildfail REGR. vs. 118105

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass

version targeted for testing:
 xen  36c560e7f38130f12a36e8b66b0785fb655fe893
baseline version:
 xen  e871e80c38547d9faefc6604532ba3e985e65873

Last test of basis   118105  2018-01-16 17:04:09 Z0 days
Testing same since   118110  2018-01-16 19:02:12 Z0 days9 attempts


People who touched revisions under test:
  Andrew Cooper 
  Anthony Liguori 
  Bob Moore 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Jon Ludlam 
  Jonathan Ludlam 
  Lv Zheng 
  Rafael J. Wysocki 
  Roger Pau Monne 
  Roger Pau Monné 
  Sergey Dyasli 
  Wei Liu 

jobs:
 build-arm64-xsm  fail
 build-amd64  pass
 build-armhf  fail
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  blocked 
 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


Not pushing.

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

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

Re: [Xen-devel] [PATCH 1/5] xen/arm: Introduce enable callback to enable a capabilities on each online CPU

[Julien Grall]

Hi Lars,

On 17/01/18 12:23, Lars Kurth wrote:



On 17 Jan 2018, at 10:31, Julien Grall > wrote:


Hi Stefano,

On 16/01/18 23:55, Stefano Stabellini wrote:

On Tue, 16 Jan 2018, Julien Grall wrote:

Once Xen knows what features/workarounds present on the platform, it
might be necessary to configure each online CPU.

Introduce a new callback "enable" that will be called on each online 
CPU to

configure the "capability".

The code is based on Linux v4.14 (where cpufeature.c comes from), the
explanation of why using stop_machine_run is kept as we have similar
problem in the future.

Lastly introduce enable_errata_workaround that will be called once CPUs
have booted and before the hardware domain is created.

This is part of XSA-254.

Signed-of-by: Julien Grall >

If you took the code from Linux, you need to add the original
Signed-off-by from the Linux commit. Aside from that:


There are multiple commits touching this function. So I followed what 
we did in similar situation. By that I mean, mentioning the code was 
taken from Linux and not gathered the signed-off-by.


If you really want, I can gather all the signed-off-by of the commit 
touching this function.


If there are a lot of then, you may want to consider adding 
a README.source file instead. There are a few examples in tree and they 
are also mentioned in CONTRIBUTING files


I am not sure to understand your suggestion here. I spotted only one 
CONTRIBUTING file and it only list the license.


Regarding README.source, this is covering file and contain the same 
mention as in the commit message. As this is a single function. Isn't 
the commit message enough?


Lastly, we do have quite a bit of code in Xen coming from Linux (or 
other project). A lot of them are not listed in 
README.source/CONTRIBUTING. But only mention in the commit message (not 
necessarily with Signed-off-by tag).


So I am quite interested to know what is the normal procedure here.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH] x86/efi: fix build with linkers that support both coff-x86-64 and pe-x86-64

[Jan Beulich]

>>> On 17.01.18 at 12:21,  wrote:
> On Mon, Jan 08, 2018 at 03:11:21AM -0700, Jan Beulich wrote:
>> >>> On 05.01.18 at 17:43,  wrote:
>> > --- a/xen/arch/x86/Makefile
>> > +++ b/xen/arch/x86/Makefile
>> > @@ -188,20 +188,20 @@ endif
>> >  $(TARGET).efi: prelink-efi.o $(note_file) efi.lds efi/relocs-dummy.o 
>> > $(BASEDIR)/common/symbols-dummy.o efi/mkreloc
>> >$(foreach base, $(VIRT_BASE) $(ALT_BASE), \
>> >  $(guard) $(LD) $(call EFI_LDFLAGS,$(base)) -T efi.lds -N $< 
>> > efi/relocs-dummy.o \
>> > -  $(BASEDIR)/common/symbols-dummy.o $(note_file) -o 
>> > $(@D)/.$(@F).$(base).0 &&) :
>> > +  $(BASEDIR)/common/symbols-dummy.o -b pe-x86-64 
>> > $(note_file) -o $(@D)/.$(@F).$(base).0 &&) :
>> 
>> I wonder whether introducing e.g
>> 
>> note_file_options := -b pe-x86-64 $(note_file)
>> 
>> wouldn't be better than repeating the same thing three times.
>> Of course it would need to be clearly spelled out that this
>> needs to come last (or another -b would need to follow). This
>> would additionally deal with the case where note.o instead of
>> efi/buildid.o is being linked in (you don't want -b pe-x86-64
>> with that one, I suppose), or when build ID support isn't
>> available at all (the new option would then be stray and might
>> be warned about).
> 
> What about doing something like:
> 
> ifneq ($(build_id_linker),)
> ifeq ($(call ld-ver-build-id,$(LD) $(filter -m%,$(EFI_LDFLAGS))),y)
> CFLAGS += -DBUILD_ID_EFI
> EFI_LDFLAGS += $(build_id_linker)
> # Note that this must be the last input in the ld call, because
> # inputs following the -b option will all be treated as being in the
> # specified format.
> note_file := -b pe-x86-64 efi/buildid.o

I'm afraid this will not work with the use of $(note_file) as a
dependency of xen.efi (indeed I first too had been considering
simply extending this variable).

Jan


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

Re: [Xen-devel] [PATCH 1/5] xen/arm: Introduce enable callback to enable a capabilities on each online CPU

[Lars Kurth]

> On 17 Jan 2018, at 10:31, Julien Grall  wrote:
> 
> Hi Stefano,
> 
> On 16/01/18 23:55, Stefano Stabellini wrote:
>> On Tue, 16 Jan 2018, Julien Grall wrote:
>>> Once Xen knows what features/workarounds present on the platform, it
>>> might be necessary to configure each online CPU.
>>> 
>>> Introduce a new callback "enable" that will be called on each online CPU to
>>> configure the "capability".
>>> 
>>> The code is based on Linux v4.14 (where cpufeature.c comes from), the
>>> explanation of why using stop_machine_run is kept as we have similar
>>> problem in the future.
>>> 
>>> Lastly introduce enable_errata_workaround that will be called once CPUs
>>> have booted and before the hardware domain is created.
>>> 
>>> This is part of XSA-254.
>>> 
>>> Signed-of-by: Julien Grall 
>> If you took the code from Linux, you need to add the original
>> Signed-off-by from the Linux commit. Aside from that:
> 
> There are multiple commits touching this function. So I followed what we did 
> in similar situation. By that I mean, mentioning the code was taken from 
> Linux and not gathered the signed-off-by.
> 
> If you really want, I can gather all the signed-off-by of the commit touching 
> this function.

If there are a lot of then, you may want to consider adding a README.source 
file instead. There are a few examples in tree and they are also mentioned in 
CONTRIBUTING files
Lars

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

Re: [Xen-devel] [PATCH v2 2/6] xen/pvh: place the trampoline at page 0x1

[Wei Liu]

On Wed, Jan 17, 2018 at 12:00:41PM +, Roger Pau Monne wrote:
> Since PVH guest jump straight into trampoline_setup trampoline_phys is
> not initialized, thus the trampoline is relocated to address 0.
> 
> This works, but has the undesirable effect of having VA 0 mapped to
> MFN 0, which means NULL pointed dereferences no longer trigger a page
> fault.
> 
> In order to solve this, place the trampoline at page 0x1 and reserve
> the memory used by it.
> 
> Signed-off-by: Roger Pau Monné 

Reviewed-by: Wei Liu 

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

[Xen-devel] [PATCH v2] tools: fix arm build after bdf693ee61b48

[Wei Liu]

The ramdisk fields were removed. We should use modules[0] instead.

Signed-off-by: Wei Liu 
---
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: Ian Jackson 

Verified the build with a qemu-chroot.
---
 tools/libxc/xc_dom_arm.c | 10 +-
 tools/libxl/libxl_arm.c  |  6 +++---
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
index fce151d821..5b9eca6087 100644
--- a/tools/libxc/xc_dom_arm.c
+++ b/tools/libxc/xc_dom_arm.c
@@ -390,8 +390,8 @@ static int meminit(struct xc_dom_image *dom)
 const uint64_t kernsize = kernend - kernbase;
 const uint64_t dtb_size = dom->devicetree_blob ?
 ROUNDUP(dom->devicetree_size, XC_PAGE_SHIFT) : 0;
-const uint64_t ramdisk_size = dom->ramdisk_blob ?
-ROUNDUP(dom->ramdisk_size, XC_PAGE_SHIFT) : 0;
+const uint64_t ramdisk_size = dom->modules[0].blob ?
+ROUNDUP(dom->modules[0].size, XC_PAGE_SHIFT) : 0;
 const uint64_t modsize = dtb_size + ramdisk_size;
 const uint64_t ram128mb = bankbase[0] + (128<<20);
 
@@ -483,12 +483,12 @@ static int meminit(struct xc_dom_image *dom)
  */
 if ( ramdisk_size )
 {
-dom->ramdisk_seg.vstart = modbase;
-dom->ramdisk_seg.vend = modbase + ramdisk_size;
+dom->modules[0].seg.vstart = modbase;
+dom->modules[0].seg.vend = modbase + ramdisk_size;
 
 DOMPRINTF("%s: ramdisk: 0x%" PRIx64 " -> 0x%" PRIx64 "",
   __FUNCTION__,
-  dom->ramdisk_seg.vstart, dom->ramdisk_seg.vend);
+  dom->modules[0].seg.vstart, dom->modules[0].seg.vend);
 
 modbase += ramdisk_size;
 }
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index de1840bece..3e46554301 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -923,7 +923,7 @@ next_resize:
 FDT( fdt_begin_node(fdt, "") );
 
 FDT( make_root_properties(gc, vers, fdt) );
-FDT( make_chosen_node(gc, fdt, !!dom->ramdisk_blob, state, info) );
+FDT( make_chosen_node(gc, fdt, !!dom->modules[0].blob, state, info) );
 FDT( make_cpus_node(gc, fdt, info->max_vcpus, ainfo) );
 FDT( make_psci_node(gc, fdt) );
 
@@ -1053,8 +1053,8 @@ int libxl__arch_domain_finalise_hw_description(libxl__gc 
*gc,
 int i;
 const uint64_t bankbase[] = GUEST_RAM_BANK_BASES;
 
-const struct xc_dom_seg *ramdisk = dom->ramdisk_blob ?
->ramdisk_seg : NULL;
+const struct xc_dom_seg *ramdisk = dom->modules[0].blob ?
+>modules[0].seg : NULL;
 
 if (ramdisk) {
 int chosen, res;
-- 
2.11.0


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

Re: [Xen-devel] [PATCH] x86/efi: fix build with linkers that support both coff-x86-64 and pe-x86-64

[Roger Pau Monné]

On Mon, Jan 08, 2018 at 03:11:21AM -0700, Jan Beulich wrote:
> >>> On 05.01.18 at 17:43,  wrote:
> > When using a linker that supports both formats the following error
> > will be triggered:
> > 
> > efi/buildid.o: file not recognized: File format is ambiguous
> > efi/buildid.o: matching formats: coff-x86-64 pe-x86-64
> > 
> > Solve this by specifying the buildid.o format to pe-x86-64.
> 
> Nice idea. I don't suppose this works with a linker only
> supporting coff-x86-64 though, but I assume such a linker
> wouldn't be usable for building xen.efi anyway.

I guess you could have in theory a linker that supports i386pep and
coff-x86-64 and doesn't support pe-x86-64 and try to build a Xen efi
binary with it. I'm not sure whether that would work or not, because
AFAICT no distro ships such a linker.

IMHO making sure it works fine as long as the linker has support for
pe-x86-64 is the best option, regardless of whether coff support is
enabled or not.

> > --- a/xen/arch/x86/Makefile
> > +++ b/xen/arch/x86/Makefile
> > @@ -188,20 +188,20 @@ endif
> >  $(TARGET).efi: prelink-efi.o $(note_file) efi.lds efi/relocs-dummy.o 
> > $(BASEDIR)/common/symbols-dummy.o efi/mkreloc
> > $(foreach base, $(VIRT_BASE) $(ALT_BASE), \
> >   $(guard) $(LD) $(call EFI_LDFLAGS,$(base)) -T efi.lds -N $< 
> > efi/relocs-dummy.o \
> > -   $(BASEDIR)/common/symbols-dummy.o $(note_file) -o 
> > $(@D)/.$(@F).$(base).0 &&) :
> > +   $(BASEDIR)/common/symbols-dummy.o -b pe-x86-64 
> > $(note_file) -o $(@D)/.$(@F).$(base).0 &&) :
> 
> I wonder whether introducing e.g
> 
> note_file_options := -b pe-x86-64 $(note_file)
> 
> wouldn't be better than repeating the same thing three times.
> Of course it would need to be clearly spelled out that this
> needs to come last (or another -b would need to follow). This
> would additionally deal with the case where note.o instead of
> efi/buildid.o is being linked in (you don't want -b pe-x86-64
> with that one, I suppose), or when build ID support isn't
> available at all (the new option would then be stray and might
> be warned about).

What about doing something like:

ifneq ($(build_id_linker),)
ifeq ($(call ld-ver-build-id,$(LD) $(filter -m%,$(EFI_LDFLAGS))),y)
CFLAGS += -DBUILD_ID_EFI
EFI_LDFLAGS += $(build_id_linker)
# Note that this must be the last input in the ld call, because
# inputs following the -b option will all be treated as being in the
# specified format.
note_file := -b pe-x86-64 efi/buildid.o
else
note_file := note.o
endif
else
note_file :=
endif

Thanks, Roger.

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

Re: [Xen-devel] [PATCH] libxc: fix arm build after bdf693ee61b48

[Wei Liu]

On Wed, Jan 17, 2018 at 10:43:40AM +, Wei Liu wrote:
> The ramdisk fields were removed. We should use modules[0] instead.
> 
> Signed-off-by: Wei Liu 
> ---
> Cc: Stefano Stabellini 
> Cc: Julien Grall 
> Cc: Ian Jackson 
> 
> Verified the build with a qemu-chroot.

I will send out an updated version. This seems to be missing a hunk to
libxl. Sorry about this.

Wei.

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

Re: [Xen-devel] [PATCH for-4.10.0-shim-comet] x86/guest: use the vcpu_info area from shared_info

[George Dunlap]

On 01/17/2018 11:16 AM, Ian Jackson wrote:
> George Dunlap writes ("Re: [PATCH for-4.10.0-shim-comet] x86/guest: use the 
> vcpu_info area from shared_info"):
>> Without this patch, people need to reboot their L0 hypervisor in order
>> to use Comet.
> 
> People running 4.10.  On 4.8 this presumably has no benefit.

On the contrary -- exactly the same arguments apply.  There were *no*
hypervisor patches as part of the 4.8 PVH backport; the only patches
between staging-4.8 and the 4.8 Comet tag that touch the hypervisor are
the pvshim-specific patches; so the same arguments apply both to 4.10
and 4.8.

 -George

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

Re: [Xen-devel] [PATCH for-4.10.0-shim-comet] x86/guest: use the vcpu_info area from shared_info

[Ian Jackson]

George Dunlap writes ("Re: [PATCH for-4.10.0-shim-comet] x86/guest: use the 
vcpu_info area from shared_info"):
> Without this patch, people need to reboot their L0 hypervisor in order
> to use Comet.

People running 4.10.  On 4.8 this presumably has no benefit.

> The risk of checking it into the Comet branches but not staging is that
> if people update their shim to "Rudolph" (4.11) without rebooting their
> host, things may unexpectedly not work.  I think that's something we can
> live with.

People won't expect to do that because of the way the tools and
hypervisor already have to be in lockstep.

Ian.

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

Re: [Xen-devel] [PATCH 3/6] xen/pvshim: identity pin shim vCPUs to pCPUs

[Wei Liu]

On Wed, Jan 17, 2018 at 09:48:11AM +, Roger Pau Monne wrote:
> Since VCPUOP_{up/down} already identity pins vCPU hotplug to pCPU
> hotplug also pin the vCPUs to the pCPUs in the scheduler. This prevent

The description is a bit ambiguous. I read it as "the shim hotplug code
pins vcpu to pcpu while doing VCPUOP_{up/down}" but in fact it is "the
shim hotplug code assumes identity mapping between vcpu and pcpu".

With this clarified.

Reviewed-by: Wei Liu 

> vCPU migration and should improve performance.
> 
> While there also use __cpumask_set_cpu instead of cpumask_set_cpu,
> there's no need to use the locked variant.
> 
> Signed-off-by: Roger Pau Monné 
> ---
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> Cc: Wei Liu 
> Cc: Ian Jackson 
> ---
> Should be backported to the 4.10.0-shim-comet branch.
> ---
>  xen/arch/x86/dom0_build.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
> index 17cb1272c1..555660b853 100644
> --- a/xen/arch/x86/dom0_build.c
> +++ b/xen/arch/x86/dom0_build.c
> @@ -140,9 +140,8 @@ struct vcpu *__init dom0_setup_vcpu(struct domain *d,
>  {
>  if ( pv_shim )
>  {
> -
> -cpumask_setall(v->cpu_hard_affinity);
> -cpumask_setall(v->cpu_soft_affinity);
> +__cpumask_set_cpu(vcpu_id, v->cpu_hard_affinity);
> +__cpumask_set_cpu(vcpu_id, v->cpu_soft_affinity);
>  }
>  else
>  {
> -- 
> 2.15.1
> 

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

Re: [Xen-devel] [PATCH v4] docs: note default for timer_mode in xl.cfg man

[Wei Liu]

On Tue, Jan 16, 2018 at 10:28:56AM -0600, Doug Goldstein wrote:
> There was no default documented but inspecting
> libxl__domain_build_info_setdefault() shows the default to be
> LIBXL_TIMER_MODE_NO_DELAY_FOR_MISSED_TICKS.
> 
> Signed-off-by: Doug Goldstein 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH] libxc: fix arm build after bdf693ee61b48

[Ian Jackson]

Wei Liu writes ("[PATCH] libxc: fix arm build after bdf693ee61b48"):
> The ramdisk fields were removed. We should use modules[0] instead.

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [Xen-users] DomU not starting under pvhv2

[M A Young]

On Wed, 17 Jan 2018, Roger Pau Monné wrote:

> On Mon, Jan 08, 2018 at 06:01:57PM +, George Dunlap wrote:
> > Moving to xen-devel, and cc'ing Roger and Boris (who developed PVH)
> > 
> > On Mon, Jan 8, 2018 at 5:24 AM, Peter  wrote:
> > > Hi.
> > >
> > > Running Xen 4.10.0
> > 
> > What version of Linux are you using?
> > 
> > >
> > > A VM is not starting with type = 'pvh'.  The VM starts, but exits prior to
> > > any data being read off the domU disk image.
> 
> Can you append earlyprintk=xen to your guest command line and try with
> a debug build of the hypervisor?
> 
> Is there anything relevant in the hypervisor serial console output?
> (xl dmesg if you don't have the serial console hooked up)

Also are you using qemu-xen or qemu-xen-traditional? If it is the former 
and you have the error
xen emulation not implemented (yet)
in the relevant qemu-dm log file in /var/log/xen then you presumably need 
the patch at
https://lists.xenproject.org/archives/html/xen-devel/2018-01/msg01289.html

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

[Xen-devel] [qemu-mainline test] 118117: regressions - trouble: broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-pygrub  broken
 test-amd64-amd64-xl-qcow2broken
 test-amd64-amd64-xl-pvhv2-amd broken
 test-amd64-amd64-xl-qemuu-ws16-amd64 broken
 test-amd64-i386-libvirt-pair broken
 test-amd64-amd64-pygrub   4 host-install(4)broken REGR. vs. 117930
 test-amd64-amd64-xl-pvhv2-amd  4 host-install(4)   broken REGR. vs. 117930
 test-amd64-amd64-xl-qcow2 4 host-install(4)broken REGR. vs. 117930
 test-amd64-i386-libvirt-pair 4 host-install/src_host(4) broken REGR. vs. 117930
 test-amd64-amd64-xl-qemuu-ws16-amd64 4 host-install(4) broken REGR. vs. 117930
 test-armhf-armhf-xl-vhd   7 xen-boot fail REGR. vs. 117930

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

version targeted for testing:
 qemuu8e5dc9ba49743b46d955ec7dacb04e42ae7ada7c
baseline version:
 qemuu7398166ddf7c6dbbc9cae6ac69bb2feda14b40ac

Last test of basis   117930  2018-01-12 23:48:34 Z4 days
Failing since118034  2018-01-15 10:18:58 Z2 days4 attempts
Testing same since   118117  2018-01-16 21:47:31 Z0 days1 attempts


People who touched revisions under test:
  Alex Bennée 
  Alexey Perevalov 
  

Re: [Xen-devel] [PATCH for-4.10.0-shim-comet] x86/guest: use the vcpu_info area from shared_info

[George Dunlap]

On 01/17/2018 10:57 AM, Roger Pau Monne wrote:
> If using less than 32 vCPUs (XEN_LEGACY_MAX_VCPUS).
> 
> This is a workaround that should allow to boot the shim on hypervisors
> without commit "x86/upcall: inject a spurious event after setting
> upcall vector" as long as less than 32 vCPUs are assigned to the
> shim.
> 
> Signed-off-by: Roger Pau Monné 
> ---
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> Cc: Wei Liu 
> Cc: Ian Jackson 
> Cc: George Dunlap 
> ---
> ONLY apply to the 4.10.0-shim-comet branch. Long term we don't want to
> carry this patch since it would prevent the vcpu_info mapping code
> from being tested unless a shim with > 32 vCPUs is created, which
> doesn't seem very common.

Just to fill this out a bit:

Without this patch, people need to reboot their L0 hypervisor in order
to use Comet.

With this patch, people only need to compile and update their L0 tools
to use Comet; they can avoid rebooting their L0 hypervisor.

Roger would like to avoid checking this in to staging, because he's
afraid it might make the >32vcpu path bitrot.

The risk of checking it into the Comet branches but not staging is that
if people update their shim to "Rudolph" (4.11) without rebooting their
host, things may unexpectedly not work.  I think that's something we can
live with.

 -George

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

[Xen-devel] [PATCH for-4.10.0-shim-comet] x86/guest: use the vcpu_info area from shared_info

[Roger Pau Monne]

If using less than 32 vCPUs (XEN_LEGACY_MAX_VCPUS).

This is a workaround that should allow to boot the shim on hypervisors
without commit "x86/upcall: inject a spurious event after setting
upcall vector" as long as less than 32 vCPUs are assigned to the
shim.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Wei Liu 
Cc: Ian Jackson 
Cc: George Dunlap 
---
ONLY apply to the 4.10.0-shim-comet branch. Long term we don't want to
carry this patch since it would prevent the vcpu_info mapping code
from being tested unless a shim with > 32 vCPUs is created, which
doesn't seem very common.
---
 xen/arch/x86/guest/xen.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/guest/xen.c b/xen/arch/x86/guest/xen.c
index 2a5554ab26..ed8b8c8c7b 100644
--- a/xen/arch/x86/guest/xen.c
+++ b/xen/arch/x86/guest/xen.c
@@ -257,7 +257,8 @@ void __init hypervisor_setup(void)
 map_shared_info();
 
 set_vcpu_id();
-vcpu_info = xzalloc_array(struct vcpu_info, nr_cpu_ids);
+if ( nr_cpu_ids > XEN_LEGACY_MAX_VCPUS )
+vcpu_info = xzalloc_array(struct vcpu_info, nr_cpu_ids);
 if ( map_vcpuinfo() )
 {
 xfree(vcpu_info);
-- 
2.15.1


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

Re: [Xen-devel] [PATCH 6/6] firmware/shim: fix build process to use POSIX find options

[Wei Liu]

On Wed, Jan 17, 2018 at 09:48:14AM +, Roger Pau Monne wrote:
> The -printf find option is not POSIX compatible, so replace it with
> another rune.
> 
> Signed-off-by: Roger Pau Monné 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH 2/6] xen/pvh: place the trampoline at page 0x1

[Wei Liu]

On Wed, Jan 17, 2018 at 09:48:10AM +, Roger Pau Monne wrote:
> Since PVH guest jump straight into trampoline_setup trampoline_phys is
> not initialized, thus the trampoline is relocated to address 0.
> 
> This works, but has the undesirable effect of having VA 0 mapped to
> MFN 0, which means NULL pointed dereferences no longer trigger a page
> fault.
> 
> In order to solve this, place the trampoline at page 0x1 and reserve
> the memory used by it.
> 
> Signed-off-by: Roger Pau Monné 
> ---
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> Cc: Wei Liu 
> Cc: Ian Jackson 
> ---
> Should be backported to the 4.10.0-shim-comet branch.
> ---
>  xen/arch/x86/boot/head.S | 3 +++
>  xen/arch/x86/mm.c| 8 ++--
>  2 files changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
> index 4fe5a776b1..7829e3f07c 100644
> --- a/xen/arch/x86/boot/head.S
> +++ b/xen/arch/x86/boot/head.S
> @@ -411,6 +411,9 @@ __pvh_start:
>  /* Skip bootloader setup and bios setup, go straight to trampoline */
>  movb$1, sym_esi(pvh_boot)
>  movb$1, sym_esi(skip_realmode)
> +
> +/* Set trampoline_phys to use page 1. */

Could you please add the rationale here -- to avoid having VA 0 mapped.

> +movw$0x1000, sym_esi(trampoline_phys)
>  jmp trampoline_setup
>  
>  #endif /* CONFIG_PVH_GUEST */
> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> index 1147a1afb1..586af2ba9a 100644
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -292,9 +292,13 @@ void __init arch_init_memory(void)
>  /*
>   * First 1MB of RAM is historically marked as I/O.  If we booted PVH,
>   * reclaim the space.  Irrespective, leave MFN 0 as special for the sake
> - * of 0 being a very common default value.
> + * of 0 being a very common default value. Also reserve page 0x1 which is
> + * used by the trampoline code.
>   */
> -for ( i = 0; i < (pvh_boot ? 1 : 0x100); i++ )
> +for ( i = 0;
> +  i < (pvh_boot ? (1 + PFN_UP(trampoline_end - trampoline_start))
> +: 0x100);
> +  i++ )

There is now a hardcoded assumption that the trampoline is mapped at
page 0x1. Maybe there should be a dedicated loop to share the trampoline
with dom_io?

Wei.

>  share_xen_page_with_guest(mfn_to_page(_mfn(i)),
>dom_io, XENSHARE_writable);
>  
> -- 
> 2.15.1
> 

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

Re: [Xen-devel] [PATCH 5/6] xen/pvshim: fix coding style issues

[Wei Liu]

On Wed, Jan 17, 2018 at 09:48:13AM +, Roger Pau Monne wrote:
> Fix a couple of coding style issues.
> 
> No code or functional change.
> 
> Signed-off-by: Roger Pau Monné 

Reviewed-by: Wei Liu 

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

Re: [Xen-devel] [PATCH 4/6] xen/pvshim: simplify replace_va_mapping code

[Wei Liu]

On Wed, Jan 17, 2018 at 09:48:12AM +, Roger Pau Monne wrote:
> No functional change.
> 
> Signed-off-by: Roger Pau Monné 

Reviewed-by: Wei Liu 

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

[Xen-devel] [PATCH] libxc: fix arm build after bdf693ee61b48

[Wei Liu]

The ramdisk fields were removed. We should use modules[0] instead.

Signed-off-by: Wei Liu 
---
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: Ian Jackson 

Verified the build with a qemu-chroot.
---
 tools/libxc/xc_dom_arm.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
index fce151d821..5b9eca6087 100644
--- a/tools/libxc/xc_dom_arm.c
+++ b/tools/libxc/xc_dom_arm.c
@@ -390,8 +390,8 @@ static int meminit(struct xc_dom_image *dom)
 const uint64_t kernsize = kernend - kernbase;
 const uint64_t dtb_size = dom->devicetree_blob ?
 ROUNDUP(dom->devicetree_size, XC_PAGE_SHIFT) : 0;
-const uint64_t ramdisk_size = dom->ramdisk_blob ?
-ROUNDUP(dom->ramdisk_size, XC_PAGE_SHIFT) : 0;
+const uint64_t ramdisk_size = dom->modules[0].blob ?
+ROUNDUP(dom->modules[0].size, XC_PAGE_SHIFT) : 0;
 const uint64_t modsize = dtb_size + ramdisk_size;
 const uint64_t ram128mb = bankbase[0] + (128<<20);
 
@@ -483,12 +483,12 @@ static int meminit(struct xc_dom_image *dom)
  */
 if ( ramdisk_size )
 {
-dom->ramdisk_seg.vstart = modbase;
-dom->ramdisk_seg.vend = modbase + ramdisk_size;
+dom->modules[0].seg.vstart = modbase;
+dom->modules[0].seg.vend = modbase + ramdisk_size;
 
 DOMPRINTF("%s: ramdisk: 0x%" PRIx64 " -> 0x%" PRIx64 "",
   __FUNCTION__,
-  dom->ramdisk_seg.vstart, dom->ramdisk_seg.vend);
+  dom->modules[0].seg.vstart, dom->modules[0].seg.vend);
 
 modbase += ramdisk_size;
 }
-- 
2.11.0


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

Re: [Xen-devel] [Xen-users] DomU not starting under pvhv2

[Roger Pau Monné]

On Mon, Jan 08, 2018 at 06:01:57PM +, George Dunlap wrote:
> Moving to xen-devel, and cc'ing Roger and Boris (who developed PVH)
> 
> On Mon, Jan 8, 2018 at 5:24 AM, Peter  wrote:
> > Hi.
> >
> > Running Xen 4.10.0
> 
> What version of Linux are you using?
> 
> >
> > A VM is not starting with type = 'pvh'.  The VM starts, but exits prior to
> > any data being read off the domU disk image.

Can you append earlyprintk=xen to your guest command line and try with
a debug build of the hypervisor?

Is there anything relevant in the hypervisor serial console output?
(xl dmesg if you don't have the serial console hooked up)

Thanks, Roger.

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

Re: [Xen-devel] [PATCH 1/5] xen/arm: Introduce enable callback to enable a capabilities on each online CPU

[Julien Grall]

Hi Stefano,

On 16/01/18 23:55, Stefano Stabellini wrote:

On Tue, 16 Jan 2018, Julien Grall wrote:

Once Xen knows what features/workarounds present on the platform, it
might be necessary to configure each online CPU.

Introduce a new callback "enable" that will be called on each online CPU to
configure the "capability".

The code is based on Linux v4.14 (where cpufeature.c comes from), the
explanation of why using stop_machine_run is kept as we have similar
problem in the future.

Lastly introduce enable_errata_workaround that will be called once CPUs
have booted and before the hardware domain is created.

This is part of XSA-254.

Signed-of-by: Julien Grall 


If you took the code from Linux, you need to add the original
Signed-off-by from the Linux commit. Aside from that:


There are multiple commits touching this function. So I followed what we 
did in similar situation. By that I mean, mentioning the code was taken 
from Linux and not gathered the signed-off-by.


If you really want, I can gather all the signed-off-by of the commit 
touching this function.


Cheers,



Reviewed-by: Stefano Stabellini 



---
  xen/arch/arm/cpuerrata.c |  6 ++
  xen/arch/arm/cpufeature.c| 29 +
  xen/arch/arm/setup.c |  1 +
  xen/include/asm-arm/cpuerrata.h  |  1 +
  xen/include/asm-arm/cpufeature.h |  3 +++
  5 files changed, 40 insertions(+)

diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index fe9e9facbe..772587c05a 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -64,6 +64,12 @@ void check_local_cpu_errata(void)
  {
  update_cpu_capabilities(arm_errata, "enabled workaround for");
  }
+
+void __init enable_errata_workarounds(void)
+{
+enable_cpu_capabilities(arm_errata);
+}
+
  /*
   * Local variables:
   * mode: C
diff --git a/xen/arch/arm/cpufeature.c b/xen/arch/arm/cpufeature.c
index 479c9fb011..525b45e22f 100644
--- a/xen/arch/arm/cpufeature.c
+++ b/xen/arch/arm/cpufeature.c
@@ -19,6 +19,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  
  DECLARE_BITMAP(cpu_hwcaps, ARM_NCAPS);

@@ -40,6 +41,34 @@ void update_cpu_capabilities(const struct 
arm_cpu_capabilities *caps,
  }
  
  /*

+ * Run through the enabled capabilities and enable() it on all active
+ * CPUs.
+ */
+void __init enable_cpu_capabilities(const struct arm_cpu_capabilities *caps)
+{
+for ( ; caps->matches; caps++ )
+{
+if ( !cpus_have_cap(caps->capability) )
+continue;
+
+if ( caps->enable )
+{
+int ret;
+
+/*
+ * Use stop_machine_run() as it schedules the work allowing
+ * us to modify PSTATE, instead of on_each_cpu() which uses
+ * an IPI, giving us a PSTATE that disappears when we
+ * return.
+ */
+ret = stop_machine_run(caps->enable, (void *)caps, NR_CPUS);
+/* stop_machine_run should never fail at this stage of the boot. */
+BUG_ON(ret);
+}
+}
+}
+
+/*
   * Local variables:
   * mode: C
   * c-file-style: "BSD"
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 16a3b1be8e..032a6a882d 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -849,6 +849,7 @@ void __init start_xen(unsigned long boot_phys_offset,
   * stop_machine (tasklets initialized via an initcall).
   */
  apply_alternatives_all();
+enable_errata_workarounds();
  
  /* Create initial domain 0. */

  /* The vGIC for DOM0 is exactly emulating the hardware GIC */
diff --git a/xen/include/asm-arm/cpuerrata.h b/xen/include/asm-arm/cpuerrata.h
index 8b158429c7..7de68361ff 100644
--- a/xen/include/asm-arm/cpuerrata.h
+++ b/xen/include/asm-arm/cpuerrata.h
@@ -5,6 +5,7 @@
  #include 
  
  void check_local_cpu_errata(void);

+void enable_errata_workarounds(void);
  
  #ifdef CONFIG_HAS_ALTERNATIVE
  
diff --git a/xen/include/asm-arm/cpufeature.h b/xen/include/asm-arm/cpufeature.h

index f00b6dbd39..21c65e198c 100644
--- a/xen/include/asm-arm/cpufeature.h
+++ b/xen/include/asm-arm/cpufeature.h
@@ -74,6 +74,7 @@ struct arm_cpu_capabilities {
  const char *desc;
  u16 capability;
  bool (*matches)(const struct arm_cpu_capabilities *);
+int (*enable)(void *); /* Called on every active CPUs */
  union {
  struct {/* To be used for eratum handling only */
  u32 midr_model;
@@ -85,6 +86,8 @@ struct arm_cpu_capabilities {
  void update_cpu_capabilities(const struct arm_cpu_capabilities *caps,
   const char *info);
  
+void enable_cpu_capabilities(const struct arm_cpu_capabilities *caps);

+
  #endif /* __ASSEMBLY__ */
  
  #endif

--
2.11.0



--
Julien Grall

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-xsm   6 xen-buildfail REGR. vs. 118105
 build-armhf   6 xen-buildfail REGR. vs. 118105

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass

version targeted for testing:
 xen  36c560e7f38130f12a36e8b66b0785fb655fe893
baseline version:
 xen  e871e80c38547d9faefc6604532ba3e985e65873

Last test of basis   118105  2018-01-16 17:04:09 Z0 days
Testing same since   118110  2018-01-16 19:02:12 Z0 days8 attempts


People who touched revisions under test:
  Andrew Cooper 
  Anthony Liguori 
  Bob Moore 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Jon Ludlam 
  Jonathan Ludlam 
  Lv Zheng 
  Rafael J. Wysocki 
  Roger Pau Monne 
  Roger Pau Monné 
  Sergey Dyasli 
  Wei Liu 

jobs:
 build-arm64-xsm  fail
 build-amd64  pass
 build-armhf  fail
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  blocked 
 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


Not pushing.

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

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

Re: [Xen-devel] [PATCH v4] docs: note default for timer_mode in xl.cfg man

[Roger Pau Monné]

On Tue, Jan 16, 2018 at 10:28:56AM -0600, Doug Goldstein wrote:
> There was no default documented but inspecting
> libxl__domain_build_info_setdefault() shows the default to be
> LIBXL_TIMER_MODE_NO_DELAY_FOR_MISSED_TICKS.
> 
> Signed-off-by: Doug Goldstein 

Reviewed-by: Roger Pau Monné 

Thanks, Roger.

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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xen  e871e80c38547d9faefc6604532ba3e985e65873
baseline version:
 xen  2d70b54e055635ff60526b6949156504b6194b7c

Last test of basis   117979  2018-01-14 09:18:54 Z3 days
Testing same since   118152  2018-01-17 09:31:43 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 

jobs:
 coverity-amd64   pass



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   2d70b54e05..e871e80c38  e871e80c38547d9faefc6604532ba3e985e65873 -> 
coverity-tested/smoke

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

Re: [Xen-devel] [xen-unstable test] 118078: regressions - FAIL

[Paul Durrant]

> -Original Message-
[snip]
> What I meant was that I'd expect the guest to have interrupts disabled whilst
> poking the MSR to enable APIC assist on that CPU, since enabling APIC assist
> is clearly going to modify the way in which interrupts are handled. If that's
> not the case though then I guess that is probably the cause of the issue; I
> never really considered protecting interrupt handling against APIC assist
> being enabled on the same CPU.
> 

I think I've spotted it...

If the guest is indeed setting up APIC assist but not actually using it then I 
think we get into this situation...

- On return to guest vlapic_has_pending_irq() finds a bit set in the IRR, then 
vlapic_ack_pending_irq() calls viridian_start_apic_assist() which latches the 
vector, sets the bit in the ISR and clears it from the IRR.
- The guest then processes the interrupt but EOIs it normally, therefore 
clearing the bit in the ISR.
- On next return to guest vlapic_has_pending_irq() calls 
viridian_complete_apic_assist(), which discovers the assist bit still set in 
the page and therefore leaves the latched vector in place, but finds another 
bit set in the IRR.
- vlapic_ack_pending_irq() is then called, the ISR is clear, so another call is 
made to viridian_start_apic_assist() and this then calls domain_crash() because 
it finds the previously latched vector.

I think the correct solution to this is to call viridian_abort_apic_assist() in 
vlapic_EOI_set() when the vector is cleared from the ISR.

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

[Xen-devel] [linux-linus test] 118112: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 linux41aa5e5d712ba3a5f4fac0bbd6d976d70f9aed06
baseline version:
 linuxa8750ddca918032d6349adbf9a4b6555e7db20da

Last test of basis   117996  2018-01-15 00:47:18 Z2 days
Testing same since   118112  2018-01-16 20:52:02 Z0 days1 attempts


People who touched revisions under test:
  Linus Torvalds 
  Randy Dunlap 
  Steven Rostedt (VMware) 
  Takashi Iwai 

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

[Xen-devel] [PATCH 3/6] xen/pvshim: identity pin shim vCPUs to pCPUs

[Roger Pau Monne]

Since VCPUOP_{up/down} already identity pins vCPU hotplug to pCPU
hotplug also pin the vCPUs to the pCPUs in the scheduler. This prevent
vCPU migration and should improve performance.

While there also use __cpumask_set_cpu instead of cpumask_set_cpu,
there's no need to use the locked variant.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Wei Liu 
Cc: Ian Jackson 
---
Should be backported to the 4.10.0-shim-comet branch.
---
 xen/arch/x86/dom0_build.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
index 17cb1272c1..555660b853 100644
--- a/xen/arch/x86/dom0_build.c
+++ b/xen/arch/x86/dom0_build.c
@@ -140,9 +140,8 @@ struct vcpu *__init dom0_setup_vcpu(struct domain *d,
 {
 if ( pv_shim )
 {
-
-cpumask_setall(v->cpu_hard_affinity);
-cpumask_setall(v->cpu_soft_affinity);
+__cpumask_set_cpu(vcpu_id, v->cpu_hard_affinity);
+__cpumask_set_cpu(vcpu_id, v->cpu_soft_affinity);
 }
 else
 {
-- 
2.15.1


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

[Xen-devel] [PATCH 6/6] firmware/shim: fix build process to use POSIX find options

[Roger Pau Monne]

The -printf find option is not POSIX compatible, so replace it with
another rune.

Signed-off-by: Roger Pau Monné 
---
Cc: Ian Jackson 
Cc: Wei Liu 
---
 tools/firmware/xen-dir/Makefile | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/firmware/xen-dir/Makefile b/tools/firmware/xen-dir/Makefile
index adf6c31e8d..de754c752e 100644
--- a/tools/firmware/xen-dir/Makefile
+++ b/tools/firmware/xen-dir/Makefile
@@ -21,7 +21,8 @@ linkfarm.stamp: $(DEP_DIRS) $(DEP_FILES) FORCE
$(foreach d, $(LINK_DIRS), \
 (mkdir -p $(D)/$(d); \
  cd $(D)/$(d); \
- find $(XEN_ROOT)/$(d)/ -type d -printf "./%P\n" |  xargs 
mkdir -p);)
+ find $(XEN_ROOT)/$(d)/ -type d -exec sh -c \
+ "echo {} | sed 's,^$(XEN_ROOT)/$(d)/,,g' | xargs mkdir 
-p" \;);)
$(foreach d, $(LINK_DIRS), \
(cd $(XEN_ROOT); \
 find $(d) ! -type l -type f \
-- 
2.15.1


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

[Xen-devel] [PATCH 0/6] xen/pvshim: fix for staging

[Roger Pau Monne]

Hello,

The following series contain some code and style fixes for the pvshim
(comet) code that has been merged into staging. IMHO patches 1-3 should
be backported to the stable comet branch.

A branch with the series is also available at:

git://xenbits.xen.org/people/royger/xen.git pvshim_fixes_v1

Thanks, Roger.

Roger Pau Monne (6):
  xen/pvshim: map vcpu_info earlier for APs
  xen/pvh: place the trampoline at page 0x1
  xen/pvshim: identity pin shim vCPUs to pCPUs
  xen/pvshim: simplify replace_va_mapping code
  xen/pvshim: fix coding style issues
  firmware/shim: fix build process to use POSIX find options

 tools/firmware/xen-dir/Makefile |  3 ++-
 xen/arch/x86/boot/head.S|  3 +++
 xen/arch/x86/dom0_build.c   |  5 ++---
 xen/arch/x86/mm.c   |  8 ++--
 xen/arch/x86/pv/shim.c  | 39 +++
 xen/arch/x86/smpboot.c  |  6 +++---
 6 files changed, 31 insertions(+), 33 deletions(-)

-- 
2.15.1


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

[Xen-devel] [PATCH 2/6] xen/pvh: place the trampoline at page 0x1

[Roger Pau Monne]

Since PVH guest jump straight into trampoline_setup trampoline_phys is
not initialized, thus the trampoline is relocated to address 0.

This works, but has the undesirable effect of having VA 0 mapped to
MFN 0, which means NULL pointed dereferences no longer trigger a page
fault.

In order to solve this, place the trampoline at page 0x1 and reserve
the memory used by it.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Wei Liu 
Cc: Ian Jackson 
---
Should be backported to the 4.10.0-shim-comet branch.
---
 xen/arch/x86/boot/head.S | 3 +++
 xen/arch/x86/mm.c| 8 ++--
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 4fe5a776b1..7829e3f07c 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -411,6 +411,9 @@ __pvh_start:
 /* Skip bootloader setup and bios setup, go straight to trampoline */
 movb$1, sym_esi(pvh_boot)
 movb$1, sym_esi(skip_realmode)
+
+/* Set trampoline_phys to use page 1. */
+movw$0x1000, sym_esi(trampoline_phys)
 jmp trampoline_setup
 
 #endif /* CONFIG_PVH_GUEST */
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 1147a1afb1..586af2ba9a 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -292,9 +292,13 @@ void __init arch_init_memory(void)
 /*
  * First 1MB of RAM is historically marked as I/O.  If we booted PVH,
  * reclaim the space.  Irrespective, leave MFN 0 as special for the sake
- * of 0 being a very common default value.
+ * of 0 being a very common default value. Also reserve page 0x1 which is
+ * used by the trampoline code.
  */
-for ( i = 0; i < (pvh_boot ? 1 : 0x100); i++ )
+for ( i = 0;
+  i < (pvh_boot ? (1 + PFN_UP(trampoline_end - trampoline_start))
+: 0x100);
+  i++ )
 share_xen_page_with_guest(mfn_to_page(_mfn(i)),
   dom_io, XENSHARE_writable);
 
-- 
2.15.1


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

[Xen-devel] [PATCH 5/6] xen/pvshim: fix coding style issues

[Roger Pau Monne]

Fix a couple of coding style issues.

No code or functional change.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/pv/shim.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/xen/arch/x86/pv/shim.c b/xen/arch/x86/pv/shim.c
index 4f94047695..2c6bd62ba5 100644
--- a/xen/arch/x86/pv/shim.c
+++ b/xen/arch/x86/pv/shim.c
@@ -264,14 +264,14 @@ int pv_shim_shutdown(uint8_t reason)
_console_pfn));
 
 /* Pause the other vcpus before starting the migration. */
-for_each_vcpu(d, v)
+for_each_vcpu ( d, v )
 if ( v != current )
 vcpu_pause_by_systemcontroller(v);
 
 rc = xen_hypercall_shutdown(SHUTDOWN_suspend);
 if ( rc )
 {
-for_each_vcpu(d, v)
+for_each_vcpu ( d, v )
 if ( v != current )
 vcpu_unpause_by_systemcontroller(v);
 
@@ -347,7 +347,7 @@ int pv_shim_shutdown(uint8_t reason)
  */
 write_start_info(d);
 
-for_each_vcpu(d, v)
+for_each_vcpu ( d, v )
 {
 /* Unmap guest vcpu_info pages. */
 unmap_vcpu_info(v);
@@ -428,7 +428,7 @@ static long pv_shim_event_channel_op(int cmd, 
XEN_GUEST_HANDLE_PARAM(void) arg)
  */
 rc = xen_hypercall_event_channel_op(EVTCHNOP_alloc_unbound, );
 if ( rc )
-   break;
+break;
 
 /* Force L1 to use the event channel port allocated on L0. */
 rc = evtchn_bind_virq(, alloc.port);
@@ -477,7 +477,7 @@ static long pv_shim_event_channel_op(int cmd, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 {
 rc = xen_hypercall_event_channel_op(EVTCHNOP_bind_vcpu, );
 if ( !rc )
- evtchn_assign_vcpu(d, vcpu.port, vcpu.vcpu);
+evtchn_assign_vcpu(d, vcpu.port, vcpu.vcpu);
 }
 
 break;
@@ -596,9 +596,9 @@ void pv_shim_inject_evtchn(unsigned int port)
 {
 if ( port_is_valid(guest, port) )
 {
- struct evtchn *chn = evtchn_from_port(guest, port);
+struct evtchn *chn = evtchn_from_port(guest, port);
 
- evtchn_port_set_pending(guest, chn->notify_vcpu_id, chn);
+evtchn_port_set_pending(guest, chn->notify_vcpu_id, chn);
 }
 }
 
@@ -633,7 +633,7 @@ static long pv_shim_grant_table_op(unsigned int cmd,
 }
 if ( compat )
 #define XLAT_gnttab_setup_table_HNDL_frame_list(d, s)
-XLAT_gnttab_setup_table(, );
+XLAT_gnttab_setup_table(, );
 #undef XLAT_gnttab_setup_table_HNDL_frame_list
 
 nat.status = GNTST_okay;
@@ -728,7 +728,7 @@ static long pv_shim_grant_table_op(unsigned int cmd,
 
 if ( compat )
 #define XLAT_gnttab_setup_table_HNDL_frame_list(d, s)
-XLAT_gnttab_setup_table(, );
+XLAT_gnttab_setup_table(, );
 #undef XLAT_gnttab_setup_table_HNDL_frame_list
 
 if ( unlikely(compat ? __copy_to_guest(uop, , 1)
-- 
2.15.1


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

[Xen-devel] [PATCH 1/6] xen/pvshim: map vcpu_info earlier for APs

[Roger Pau Monne]

Or else init_percpu_time is going to dereference a NULL pointer when
trying to access vcpu_info.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Ian Jackson 
Cc: Wei Liu 
---
Should be backported to the 4.10.0-shim-comet branch.
---
 xen/arch/x86/smpboot.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
index 63ca053b35..2cdd431b5f 100644
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -349,6 +349,9 @@ void start_secondary(void *unused)
 else
 microcode_resume_cpu(cpu);
 
+if ( xen_guest )
+hypervisor_ap_setup();
+
 smp_callin();
 
 init_percpu_time();
@@ -376,9 +379,6 @@ void start_secondary(void *unused)
 cpumask_set_cpu(cpu, _online_map);
 unlock_vector_lock();
 
-if ( xen_guest )
-hypervisor_ap_setup();
-
 /* We can take interrupts now: we're officially "up". */
 local_irq_enable();
 mtrr_ap_init();
-- 
2.15.1


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

[Xen-devel] [PATCH 4/6] xen/pvshim: simplify replace_va_mapping code

[Roger Pau Monne]

No functional change.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/pv/shim.c | 21 ++---
 1 file changed, 6 insertions(+), 15 deletions(-)

diff --git a/xen/arch/x86/pv/shim.c b/xen/arch/x86/pv/shim.c
index 702249719e..4f94047695 100644
--- a/xen/arch/x86/pv/shim.c
+++ b/xen/arch/x86/pv/shim.c
@@ -117,21 +117,12 @@ uint64_t pv_shim_mem(uint64_t avail)
 static void __init replace_va_mapping(struct domain *d, l4_pgentry_t *l4start,
   unsigned long va, unsigned long mfn)
 {
-struct page_info *page;
-l4_pgentry_t *pl4e;
-l3_pgentry_t *pl3e;
-l2_pgentry_t *pl2e;
-l1_pgentry_t *pl1e;
-
-pl4e = l4start + l4_table_offset(va);
-pl3e = l4e_to_l3e(*pl4e);
-pl3e += l3_table_offset(va);
-pl2e = l3e_to_l2e(*pl3e);
-pl2e += l2_table_offset(va);
-pl1e = l2e_to_l1e(*pl2e);
-pl1e += l1_table_offset(va);
-
-page = mfn_to_page(l1e_get_pfn(*pl1e));
+l4_pgentry_t *pl4e = l4start + l4_table_offset(va);
+l3_pgentry_t *pl3e = l4e_to_l3e(*pl4e) + l3_table_offset(va);
+l2_pgentry_t *pl2e = l3e_to_l2e(*pl3e) + l2_table_offset(va);
+l1_pgentry_t *pl1e = l2e_to_l1e(*pl2e) + l1_table_offset(va);
+struct page_info *page =  mfn_to_page(l1e_get_pfn(*pl1e));;
+
 put_page_and_type(page);
 
 *pl1e = l1e_from_pfn(mfn, (!is_pv_32bit_domain(d) ? L1_PROT
-- 
2.15.1


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

Re: [Xen-devel] [PATCH v8 08/17] x86/msr: Emulation of MSR_{SPEC_CTRL, PRED_CMD} for guests

[Andrew Cooper]

From: Jan Beulich [jbeul...@suse.com]
Sent: 17 January 2018 09:11
To: Andrew Cooper
Cc: David Woodhouse; Xen-devel
Subject: Re: [Xen-devel] [PATCH v8 08/17] x86/msr: Emulation of MSR_{SPEC_CTRL, 
PRED_CMD} for guests

>>> On 16.01.18 at 17:58,  wrote:
> On 16/01/18 11:10, David Woodhouse wrote:
>> On Fri, 2018-01-12 at 18:00 +, Andrew Cooper wrote:
>>> @@ -152,14 +163,38 @@ int guest_wrmsr(struct vcpu *v, uint32_t msr,
>>> uint64_t val)
>>>  {
>>>  const struct vcpu *curr = current;
>>>  struct domain *d = v->domain;
>>> +const struct cpuid_policy *cp = d->arch.cpuid;
>>>  struct msr_domain_policy *dp = d->arch.msr;
>>>  struct msr_vcpu_policy *vp = v->arch.msr;
>>>
>>>  switch ( msr )
>>>  {
>>>  case MSR_INTEL_PLATFORM_INFO:
>>> +/* Read-only */
>>>  goto gp_fault;
>>>
>>> +case MSR_SPEC_CTRL:
>>> +if ( !cp->feat.ibrsb )
>>> +goto gp_fault; /* MSR available? */
>>> +if ( val & ~(SPEC_CTRL_IBRS |
>>> + (cp->feat.stibp ? SPEC_CTRL_STIBP : 0)) )
>> Intel defines the STIBP bit as non-faulting and ignored, even when
>> STIBP isn't advertised. So you should probably just mask it out
>> if !cp->feat.stibp.
>
> Well - this published spec finally answers several several-month-old
> outstanding questions of mine.
>
> Time for some rewriting.  /sigh

In light of this, is there actually much point in me looking at the two
remaining v8 patches (13 and 14)?

Not really. They are going to change completely. 

~Andrew 

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

Re: [Xen-devel] [xen-unstable test] 118078: regressions - FAIL

[Paul Durrant]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 17 January 2018 08:52
> To: Paul Durrant 
> Cc: xen-devel ; osstest-
> ad...@xenproject.org
> Subject: RE: [Xen-devel] [xen-unstable test] 118078: regressions - FAIL
> 
> >>> On 16.01.18 at 18:30,  wrote:
> >> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On
> Behalf
> >> Of Paul Durrant
> >> Sent: 16 January 2018 09:27
> >> > From: Jan Beulich [mailto:jbeul...@suse.com]
> >> > Sent: 16 January 2018 08:58
> >> > >>> On 16.01.18 at 09:43,  wrote:
> >> > > flight 118078 xen-unstable real [real]
> >> > > http://logs.test-lab.xenproject.org/osstest/logs/118078/
> >> > >
> >> > > Regressions :-(
> >> > >
> >> > > Tests which did not succeed and are blocking,
> >> > > including tests which could not be run:
> >> > >  build-arm64-pvops 6 kernel-build fail REGR. 
> >> > > vs. 118003
> >> > >  test-amd64-amd64-xl-qemut-win7-amd64 10 windows-install  fail
> REGR.
> >> vs.
> >> > 118003
> >> >
> >> > Paul,
> >> >
> >> > is this last one something you could look into?
> >> >
> >> > (XEN) d4: VIRIDIAN GUEST_OS_ID: vendor: 1 os: 4 major: 6 minor: 1 sp: 0
> >> > build: 1db0
> >> > (XEN) d4: VIRIDIAN HYPERCALL: enabled: 1 pfn: 3
> >> > (XEN) d4v0: VIRIDIAN VP_ASSIST_PAGE: enabled: 1 pfn: 3fffe
> >> > (XEN) domain_crash called from viridian.c:452
> >> > (XEN) Domain 4 (vcpu#0) crashed on cpu#1:
> >> > (XEN) [ Xen-4.11-unstable  x86_64  debug=y   Not tainted ]
> >> > (XEN) CPU:1
> >> > (XEN) RIP:0010:[]
> >> > (XEN) RFLAGS: 0286   CONTEXT: hvm guest (d4v0)
> >> > (XEN) rax:    rbx: f800027f7e80   rcx:
> 0001
> >> > (XEN) rdx:    rsi: fa800129d040   rdi:
> f80002805c40
> >> > (XEN) rbp: 0080   rsp: f880009b0d80   r8:
> >> 
> >> > (XEN) r9:  f800027f7e80   r10: fa800129d040   r11: 
> >> > f800027f7e90
> >> > (XEN) r12: f88129a0   r13: f800028b9be0   r14:
> fa8001239b30
> >> > (XEN) r15: f8b96080   cr0: 80050031   cr4:
> >> 06b8
> >> > (XEN) cr3: 00187000   cr2: 
> >> > (XEN) fsb:    gsb: f800027f7d00   gss:
> f800027f7d00
> >> > (XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
> >> >
> >> > I.e. the domain_crash() in viridian_start_apic_assist().
> >> >
> >>
> >> Yes, I'll have a look at that.
> >
> > No real clue about this as yet. It is odd that the guest has only set up one
> > of the APIC assist pages and yet has taken an interrupt...
> >
> > Jan 16 01:46:05.691223 (XEN) Dumping guest's current state at
> key_handler...
> > Jan 16 01:46:05.691265 (XEN) Size of VMCB = 4096, paddr =
> 00020f7f7000,
> > vaddr = 83020f7f7000
> > Jan 16 01:46:05.699269 (XEN) cr_intercepts = 0xfef3fef3 dr_intercepts =
> > 0x exception_intercepts = 0x60082
> > Jan 16 01:46:05.707128 (XEN) general1_intercepts = 0xbdc4000f
> > general2_intercepts = 0x2e7f
> > Jan 16 01:46:05.715222 (XEN) iopm_base_pa = 0xdfd71000 msrpm_base_pa
> =
> > 0x20f7f4000 tsc_offset = 0xfc36684278c9
> > Jan 16 01:46:05.723116 (XEN) tlb_control = 0 vintr = 0x1020001
> > interrupt_shadow = 0
> > Jan 16 01:46:05.723153 (XEN) eventinj 802f, valid? 1, ec? 0,
> > type 0, vector 0x2f
> > Jan 16 01:46:05.731141 (XEN) exitcode = 0x64 exitintinfo = 0
> > Jan 16 01:46:05.739123 (XEN) exitinfo1 = 0 exitinfo2 = 0
> > Jan 16 01:46:05.739157 (XEN) np_enable = 0x1 guest_asid = 0x4b49
> > Jan 16 01:46:05.739187 (XEN) virtual vmload/vmsave = 0, virt_ext = 0
> >
> > I'd expect it to have interrupts disabled at this point. Seemingly doesn't
> > repro on Intel h/w (although I was testing with Win7 SP1 rather than RTM)
> so
> > I'll try to find some AMD h/w and try again.
> 
> Well, it looks to be a random problem in the first place, or else we
> would have known about the issue much earlier I think. I.e. I'm
> not sure I see what you take the "AMD only" from here.
> 

Well, I don't see any repro on Intel and the VMCB (rather than VMCS) dump 
identifies this case as using AMD h/w. I agree that it is random though, so it 
could indeed be purely coincidental.

> As to interrupt state - isn't it quite normal for an OS to bring up
> the BSP first, enable interrupts on it, and then bring up APs?
> That's how we do it in Xen.

What I meant was that I'd expect the guest to have interrupts disabled whilst 
poking the MSR to enable APIC assist on that CPU, since enabling APIC assist is 
clearly going to modify the way in which interrupts are handled. If that's not 
the case though then I guess that is probably the cause of the issue; I never 
really considered protecting interrupt handling against APIC assist being 
enabled on the same CPU.

  Paul

> 
> Jan

Re: [Xen-devel] [PATCH v8 12/17] x86/entry: Organise the use of MSR_SPEC_CTRL at each entry/exit point

[Andrew Cooper]

No, not really. Omitting it on the grounds of "we don't expect to take a double 
fault" don't beat uniformally altering all the entrypoints in a consistent 
manor. 

The only thing which can go wrong is that we forget to do it when it is needed.

~Andrew 

From: Jan Beulich [jbeul...@suse.com]
Sent: 17 January 2018 08:47
To: Andrew Cooper
Cc: Xen-devel
Subject: Re: [Xen-devel] [PATCH v8 12/17] x86/entry: Organise the use of 
MSR_SPEC_CTRL at each entry/exit point

>>> On 16.01.18 at 22:24,  wrote:
> On 15/01/18 12:09, Jan Beulich wrote:
> On 12.01.18 at 19:01,  wrote:
>>> @@ -586,6 +611,10 @@ ENTRY(double_fault)
>>>  movl  $TRAP_double_fault,4(%rsp)
>>>  /* Set AC to reduce chance of further SMAP faults */
>>>  SAVE_ALL STAC
>>> +
>>> +SPEC_CTRL_ENTRY_FROM_INTR /* Req: %rsp=regs Clob: acd */
>>> +/* WARNING! `ret`, `call *`, `jmp *` not safe before this point. */
>> Is it actually useful to do _anything_ in the double fault handler?
>
> Typically no, but then again we hope never to execute this code.
>
> OTOH, we would need to do this if we ever get around to doing espfix64.

Could I get you to omit the change to the handler until then, to keep
it as straightforward as possible?

Jan


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

Re: [Xen-devel] [PATCH v8 08/17] x86/msr: Emulation of MSR_{SPEC_CTRL, PRED_CMD} for guests

[Jan Beulich]

>>> On 16.01.18 at 17:58,  wrote:
> On 16/01/18 11:10, David Woodhouse wrote:
>> On Fri, 2018-01-12 at 18:00 +, Andrew Cooper wrote:
>>> @@ -152,14 +163,38 @@ int guest_wrmsr(struct vcpu *v, uint32_t msr,
>>> uint64_t val)
>>>  {
>>>  const struct vcpu *curr = current;
>>>  struct domain *d = v->domain;
>>> +const struct cpuid_policy *cp = d->arch.cpuid;
>>>  struct msr_domain_policy *dp = d->arch.msr;
>>>  struct msr_vcpu_policy *vp = v->arch.msr;
>>>  
>>>  switch ( msr )
>>>  {
>>>  case MSR_INTEL_PLATFORM_INFO:
>>> +/* Read-only */
>>>  goto gp_fault;
>>>  
>>> +case MSR_SPEC_CTRL:
>>> +if ( !cp->feat.ibrsb )
>>> +goto gp_fault; /* MSR available? */
>>> +if ( val & ~(SPEC_CTRL_IBRS |
>>> + (cp->feat.stibp ? SPEC_CTRL_STIBP : 0)) )
>> Intel defines the STIBP bit as non-faulting and ignored, even when
>> STIBP isn't advertised. So you should probably just mask it out
>> if !cp->feat.stibp.
> 
> Well - this published spec finally answers several several-month-old
> outstanding questions of mine.
> 
> Time for some rewriting.  /sigh

In light of this, is there actually much point in me looking at the two
remaining v8 patches (13 and 14)?

Jan


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

Re: [Xen-devel] [xen-unstable test] 118078: regressions - FAIL

[Jan Beulich]

>>> On 16.01.18 at 18:30,  wrote:
>> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
>> Of Paul Durrant
>> Sent: 16 January 2018 09:27
>> > From: Jan Beulich [mailto:jbeul...@suse.com]
>> > Sent: 16 January 2018 08:58
>> > >>> On 16.01.18 at 09:43,  wrote:
>> > > flight 118078 xen-unstable real [real]
>> > > http://logs.test-lab.xenproject.org/osstest/logs/118078/ 
>> > >
>> > > Regressions :-(
>> > >
>> > > Tests which did not succeed and are blocking,
>> > > including tests which could not be run:
>> > >  build-arm64-pvops 6 kernel-build fail REGR. vs. 
>> > > 118003
>> > >  test-amd64-amd64-xl-qemut-win7-amd64 10 windows-install  fail REGR.
>> vs.
>> > 118003
>> >
>> > Paul,
>> >
>> > is this last one something you could look into?
>> >
>> > (XEN) d4: VIRIDIAN GUEST_OS_ID: vendor: 1 os: 4 major: 6 minor: 1 sp: 0
>> > build: 1db0
>> > (XEN) d4: VIRIDIAN HYPERCALL: enabled: 1 pfn: 3
>> > (XEN) d4v0: VIRIDIAN VP_ASSIST_PAGE: enabled: 1 pfn: 3fffe
>> > (XEN) domain_crash called from viridian.c:452
>> > (XEN) Domain 4 (vcpu#0) crashed on cpu#1:
>> > (XEN) [ Xen-4.11-unstable  x86_64  debug=y   Not tainted ]
>> > (XEN) CPU:1
>> > (XEN) RIP:0010:[]
>> > (XEN) RFLAGS: 0286   CONTEXT: hvm guest (d4v0)
>> > (XEN) rax:    rbx: f800027f7e80   rcx: 0001
>> > (XEN) rdx:    rsi: fa800129d040   rdi: f80002805c40
>> > (XEN) rbp: 0080   rsp: f880009b0d80   r8:
>> 
>> > (XEN) r9:  f800027f7e80   r10: fa800129d040   r11: f800027f7e90
>> > (XEN) r12: f88129a0   r13: f800028b9be0   r14: fa8001239b30
>> > (XEN) r15: f8b96080   cr0: 80050031   cr4:
>> 06b8
>> > (XEN) cr3: 00187000   cr2: 
>> > (XEN) fsb:    gsb: f800027f7d00   gss: f800027f7d00
>> > (XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
>> >
>> > I.e. the domain_crash() in viridian_start_apic_assist().
>> >
>> 
>> Yes, I'll have a look at that.
> 
> No real clue about this as yet. It is odd that the guest has only set up one 
> of the APIC assist pages and yet has taken an interrupt...
> 
> Jan 16 01:46:05.691223 (XEN) Dumping guest's current state at key_handler...
> Jan 16 01:46:05.691265 (XEN) Size of VMCB = 4096, paddr = 00020f7f7000, 
> vaddr = 83020f7f7000
> Jan 16 01:46:05.699269 (XEN) cr_intercepts = 0xfef3fef3 dr_intercepts = 
> 0x exception_intercepts = 0x60082
> Jan 16 01:46:05.707128 (XEN) general1_intercepts = 0xbdc4000f 
> general2_intercepts = 0x2e7f
> Jan 16 01:46:05.715222 (XEN) iopm_base_pa = 0xdfd71000 msrpm_base_pa = 
> 0x20f7f4000 tsc_offset = 0xfc36684278c9
> Jan 16 01:46:05.723116 (XEN) tlb_control = 0 vintr = 0x1020001 
> interrupt_shadow = 0
> Jan 16 01:46:05.723153 (XEN) eventinj 802f, valid? 1, ec? 0, 
> type 0, vector 0x2f
> Jan 16 01:46:05.731141 (XEN) exitcode = 0x64 exitintinfo = 0
> Jan 16 01:46:05.739123 (XEN) exitinfo1 = 0 exitinfo2 = 0
> Jan 16 01:46:05.739157 (XEN) np_enable = 0x1 guest_asid = 0x4b49
> Jan 16 01:46:05.739187 (XEN) virtual vmload/vmsave = 0, virt_ext = 0
> 
> I'd expect it to have interrupts disabled at this point. Seemingly doesn't 
> repro on Intel h/w (although I was testing with Win7 SP1 rather than RTM) so 
> I'll try to find some AMD h/w and try again.

Well, it looks to be a random problem in the first place, or else we
would have known about the issue much earlier I think. I.e. I'm
not sure I see what you take the "AMD only" from here.

As to interrupt state - isn't it quite normal for an OS to bring up
the BSP first, enable interrupts on it, and then bring up APs?
That's how we do it in Xen.

Jan


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

Re: [Xen-devel] [PATCH v8 12/17] x86/entry: Organise the use of MSR_SPEC_CTRL at each entry/exit point

[Jan Beulich]

>>> On 16.01.18 at 22:24,  wrote:
> On 15/01/18 12:09, Jan Beulich wrote:
> On 12.01.18 at 19:01,  wrote:
>>> @@ -586,6 +611,10 @@ ENTRY(double_fault)
>>>  movl  $TRAP_double_fault,4(%rsp)
>>>  /* Set AC to reduce chance of further SMAP faults */
>>>  SAVE_ALL STAC
>>> +
>>> +SPEC_CTRL_ENTRY_FROM_INTR /* Req: %rsp=regs Clob: acd */
>>> +/* WARNING! `ret`, `call *`, `jmp *` not safe before this point. */
>> Is it actually useful to do _anything_ in the double fault handler?
> 
> Typically no, but then again we hope never to execute this code.
> 
> OTOH, we would need to do this if we ever get around to doing espfix64.

Could I get you to omit the change to the handler until then, to keep
it as straightforward as possible?

Jan


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

Re: [Xen-devel] [PATCH v8 11/17] x86: Protect unaware domains from meddling hyperthreads

[Andrew Cooper]

On 17/01/2018 08:40, Jan Beulich wrote:
 On 16.01.18 at 22:11,  wrote:
>> An alternative to the current levelling logic would be to treat STIBP as
>> a Special Bit (in CPUID terms, like OSXSAVE/etc) and unconditionally set
>> it equal to IBRS, irrespective of the toolstack setting.  That way,
>> migration between HT and non-HT hardware is safe and a VM which chooses
>> to use STIBP will work even on non-HT hardware which simply ignores the
>> request.
> Wouldn't that overall result in simpler code anyway?

Much, except its only become an option since yesterday.

~Andrew

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

Re: [Xen-devel] [PATCH v8 11/17] x86: Protect unaware domains from meddling hyperthreads

[Jan Beulich]

>>> On 16.01.18 at 22:11,  wrote:
> An alternative to the current levelling logic would be to treat STIBP as
> a Special Bit (in CPUID terms, like OSXSAVE/etc) and unconditionally set
> it equal to IBRS, irrespective of the toolstack setting.  That way,
> migration between HT and non-HT hardware is safe and a VM which chooses
> to use STIBP will work even on non-HT hardware which simply ignores the
> request.

Wouldn't that overall result in simpler code anyway?

Jan


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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-xsm   6 xen-buildfail REGR. vs. 118105
 build-armhf   6 xen-buildfail REGR. vs. 118105

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass

version targeted for testing:
 xen  36c560e7f38130f12a36e8b66b0785fb655fe893
baseline version:
 xen  e871e80c38547d9faefc6604532ba3e985e65873

Last test of basis   118105  2018-01-16 17:04:09 Z0 days
Testing same since   118110  2018-01-16 19:02:12 Z0 days7 attempts


People who touched revisions under test:
  Andrew Cooper 
  Anthony Liguori 
  Bob Moore 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Jon Ludlam 
  Jonathan Ludlam 
  Lv Zheng 
  Rafael J. Wysocki 
  Roger Pau Monne 
  Roger Pau Monné 
  Sergey Dyasli 
  Wei Liu 

jobs:
 build-arm64-xsm  fail
 build-amd64  pass
 build-armhf  fail
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  blocked 
 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


Not pushing.

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

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

Re: [Xen-devel] [PATCH] xen/efi: Avoid EFI stub using absolute symbols

[Jan Beulich]

>>> On 16.01.18 at 18:43,  wrote:
> On 12/01/18 13:13, Jan Beulich wrote:
> On 09.01.18 at 20:43,  wrote:
>>> When I compiled the snippet on x86 and Arm, no relocation is available
>>> for the pointers to string in the array in the final binary. Yet they
>>> are available in the object.
>> 
>> I can see them there in the binary I look at. I use my own tool
>> for dumping, so the output may look unfamiliar to you, but here
>> are the relevant pieces:
> 
> I am a bit confused. Which binary are you looking at? Is it xen.efi?
> I don't seem to find them in xen-syms.

Of course it is xen.efi. xen-syms can't possibly have any PE relocations,
as it's an ELF image on x86.

>> Well, without having seen the binary I don't think I can conclude
>> in the direction of compiler bug. Please don't forget that ld itself
>> does indeed not (yet) create any relocations in PE executables
>> (which an EFI application is). They're being added in a post-
>> processing step (hence the need to link the binary twice at
>> different base addresses, for the helper tool [mkreloc] to figure
>> out where relocations are needed).
> 
> If the code compiled is position independent, then you should not need
> relocation. Right? So what are you trying to achieve with mkreloc?

If _all_ of the code, even assembly, was position independent,
then yes, there shouldn't be relocations. But that's not the case
right now.

> Also, it does not explain why the compiler is issuing absolute address 
> when building with -fpie.

To be honest I'm not certain what guarantees -fpie makes on the
compiled code. It looks to me as if it only tries to minimize the
relocations needed, not eliminate all of them (after all the binary
will work fine that way, it is just required that the relocations not
be removed while linking the final binary). Indeed both 32-bit and
64-bit for both x86 and ARM produce relocations for tables like
the one we talk about (so called absolute ones on ARM), yet I
don't think this is a compiler bug.

>>> So I am wondering how this work on x86? Note that this code is only used
>>> in error path.
>> 
>> Sure, but an error path is being taken every now and then, and
>> I personally have seen errors coming back (mostly after having
>> made mistakes elsewhere).
> 
> And I guess the binary will never be loaded at the same as virtual 
> address as Xen would be meant to run?

Indeed - it can't be loaded at that address, as the 1:1 mapping the
EFI environment requires can't ever have any present mappings in
the upper half of the virtual address space.

Jan


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