Re: [Xen-devel] [PATCH v3 3/3] xen/pciback: support driver_override

[Juergen Gross]

On 22/09/16 23:10, Boris Ostrovsky wrote:
> On 09/22/2016 04:45 AM, Juergen Gross wrote:
>> Support the driver_override scheme introduced with commit 782a985d7af2
>> ("PCI: Introduce new device binding path using pci_dev.driver_override")
>>
>> As pcistub_probe() is called for all devices (it has to check for a
>> match based on the slot address rather than device type) it has to
>> check for driver_override set to "pciback" itself.
>>
>> Up to now for assigning a pci device to pciback you need something like:
>>
>> echo :07:10.0 > /sys/bus/pci/devices/\:07\:10.0/driver/unbind
>> echo :07:10.0 > /sys/bus/pci/drivers/pciback/new_slot
>> echo :07:10.0 > /sys/bus/pci/drivers_probe
>>
>> while with the patch you can use the same mechanism as for similar
>> drivers like pci-stub and vfio-pci:
>>
>> echo pciback > /sys/bus/pci/devices/\:07\:10.0/driver_override
>> echo :07:10.0 > /sys/bus/pci/devices/\:07\:10.0/driver/unbind
>> echo :07:10.0 > /sys/bus/pci/drivers_probe
>>
>> So e.g. libvirt doesn't need special handling for pciback.
>>
>> Signed-off-by: Juergen Gross 
>> ---
>> V3: Move override check up in order not to miss the PCI_HEADER_TYPE
>> check.
>> Add an assigned device to the slot list.
>>
>> V2: Removed now unused label
>> ---
>>  drivers/xen/xen-pciback/pci_stub.c | 36 +---
>>  1 file changed, 29 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/xen/xen-pciback/pci_stub.c 
>> b/drivers/xen/xen-pciback/pci_stub.c
>> index 0179333..6331a95 100644
>> --- a/drivers/xen/xen-pciback/pci_stub.c
>> +++ b/drivers/xen/xen-pciback/pci_stub.c
>> @@ -25,6 +25,8 @@
>>  #include "conf_space.h"
>>  #include "conf_space_quirks.h"
>>  
>> +#define PCISTUB_DRIVER_NAME "pciback"
>> +
>>  static char *pci_devs_to_hide;
>>  wait_queue_head_t xen_pcibk_aer_wait_queue;
>>  /*Add sem for sync AER handling and xen_pcibk remove/reconfigue ops,
>> @@ -508,15 +510,18 @@ static void pcistub_device_id_add_list(struct 
>> pcistub_device_id *new,
>>  kfree(new);
>>  }
>>  
>> -static int pcistub_seize(struct pci_dev *dev)
>> +static int pcistub_seize(struct pci_dev *dev,
>> + struct pcistub_device_id *pci_dev_id)
>>  {
>>  struct pcistub_device *psdev;
>>  unsigned long flags;
>>  int err = 0;
>>  
>>  psdev = pcistub_device_alloc(dev);
>> -if (!psdev)
>> +if (!psdev) {
>> +kfree(pci_dev_id);
> 
> Here too --- I'd rather have it freed by whoever allocated it (i.e. the
> caller). In fact I think you can allocate this here and instead of
> passing pci_dev_id pointer pass a flag of some sort.

Allocating it here will become nasty: The allocation flags are
different in the two cases, so I'd have to either pass the flags
or have to use GFP_ATOMIC in both cases.

And dealing with an allocation failure at the very end of
pcistub_seize() would require quite some rollback action.


Juergen

> -boris
> 
>>  return -ENOMEM;
>> +}
>>  
>>  spin_lock_irqsave(_devices_lock, flags);
>>  
>> @@ -537,8 +542,12 @@ static int pcistub_seize(struct pci_dev *dev)
>>  
>>  spin_unlock_irqrestore(_devices_lock, flags);
>>  
>> -if (err)
>> +if (err) {
>> +kfree(pci_dev_id);
>>  pcistub_device_put(psdev);
>> +} else if (pci_dev_id)
>> +pcistub_device_id_add_list(pci_dev_id, pci_domain_nr(dev->bus),
>> +   dev->bus->number, dev->devfn);
>>  
>>  return err;
>>  }
>> @@ -547,11 +556,16 @@ static int pcistub_seize(struct pci_dev *dev)
>>   * other functions that take the sysfs lock. */
>>  static int pcistub_probe(struct pci_dev *dev, const struct pci_device_id 
>> *id)
>>  {
>> -int err = 0;
>> +int err = 0, match;
>> +struct pcistub_device_id *pci_dev_id = NULL;
>>  
>>  dev_dbg(>dev, "probing...\n");
>>  
>> -if (pcistub_match(dev)) {
>> +match = pcistub_match(dev);
>> +
>> +if ((dev->driver_override &&
>> + !strcmp(dev->driver_override, PCISTUB_DRIVER_NAME)) ||
>> +match) {
>>  
>>  if (dev->hdr_type != PCI_HEADER_TYPE_NORMAL
>>  && dev->hdr_type != PCI_HEADER_TYPE_BRIDGE) {
>> @@ -562,8 +576,16 @@ static int pcistub_probe(struct pci_dev *dev, const 
>> struct pci_device_id *id)
>>  goto out;
>>  }
>>  
>> +if (!match) {
>> +pci_dev_id = kmalloc(sizeof(*pci_dev_id), GFP_ATOMIC);
>> +if (!pci_dev_id) {
>> +err = -ENOMEM;
>> +goto out;
>> +}
>> +}
>> +
>>  dev_info(>dev, "seizing device\n");
>> -err = pcistub_seize(dev);
>> +err = pcistub_seize(dev, pci_dev_id);
>>  } else
>>  /* Didn't find the device */
>>  err = -ENODEV;
>> @@ -975,7 +997,7 @@ static const struct 

Re: [Xen-devel] [PATCH v3 2/3] xen/pciback: avoid multiple entries in slot list

[Juergen Gross]

On 22/09/16 23:02, Boris Ostrovsky wrote:
> On 09/22/2016 04:45 AM, Juergen Gross wrote:
>> The Xen pciback driver has a list of all pci devices it is ready to
>> seize. There is no check whether a to be added entry already exists.
>> While this might be no problem in the common case it might confuse
>> those which consume the list via sysfs.
>>
>> Modify the handling of this list by not adding an entry which already
>> exists. As this will be needed later split out the list handling into
>> a separate function.
>>
>> Signed-off-by: Juergen Gross 
>> ---
>>  drivers/xen/xen-pciback/pci_stub.c | 39 
>> ++
>>  1 file changed, 31 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/xen/xen-pciback/pci_stub.c 
>> b/drivers/xen/xen-pciback/pci_stub.c
>> index 79a9e4d..0179333 100644
>> --- a/drivers/xen/xen-pciback/pci_stub.c
>> +++ b/drivers/xen/xen-pciback/pci_stub.c
>> @@ -478,6 +478,36 @@ static int __init pcistub_init_devices_late(void)
>>  return 0;
>>  }
>>  
>> +static void pcistub_device_id_add_list(struct pcistub_device_id *new,
>> +   int domain, int bus, unsigned int devfn)
>> +{
>> +struct pcistub_device_id *pci_dev_id;
>> +unsigned long flags;
>> +int found = 0;
>> +
>> +spin_lock_irqsave(_ids_lock, flags);
>> +
>> +list_for_each_entry(pci_dev_id, _device_ids, slot_list) {
>> +if (pci_dev_id->domain == domain && pci_dev_id->bus == bus &&
>> +pci_dev_id->devfn == devfn) {
>> +found = 1;
>> +break;
>> +}
>> +}
>> +
>> +if (!found) {
>> +new->domain = domain;
>> +new->bus = bus;
>> +new->devfn = devfn;
>> +list_add_tail(>slot_list, _device_ids);
>> +}
>> +
>> +spin_unlock_irqrestore(_ids_lock, flags);
>> +
>> +if (found)
>> +kfree(new);
> 
> I'd rather free 'new' in the caller (who allocated it) and return
> something like -EEXIST if device is already on the list.

Hmm, I thought of this, but with two callers after the following patch
having to deal with the situation I've chosen this way to do it.

The code is smaller this way.


Juergen

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail REGR. vs. 101101

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101101
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 101101
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101101

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass

version targeted for testing:
 qemuu430da7a81d356e368ccd88dcca60f38da9aa5b9a
baseline version:
 qemuub98bbea2d94dc5902acaa3a5dd7f9057cc82cdb1

Last test of basis   101101  2016-09-22 11:51:11 Z0 days
Testing same since   101110  2016-09-22 19:15:09 Z0 days1 attempts


People who touched revisions under test:
  Alberto Garcia 
  Brian Rak 
  Colin Lord 
  Eduardo Otubo 
  Laurent Vivier 
  Marc Mari 
  Marc Marí 
  Max Reitz 
  Michael Walle 
  Peter Maydell 
  Reda Sallahi 
  Riku Voipio 
  Timothy E Baldwin 
  Timothy Edward Baldwin 
  Vladimir Sementsov-Ogievskiy 

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

[Xen-devel] [PATCH V4] xen/arm: domain_build: allocate lowmem for dom0 as much as possible

[Peng Fan]

On AArch64 SoCs, some IPs may only have the capability to access
32 bits address space. The physical memory assigned for Dom0 maybe
not in 4GB address space, then the IPs will not work properly.
So need to allocate memory under 4GB for Dom0.

There is no restriction that how much lowmem needs to be allocated for
Dom0 ,so allocate lowmem as much as possible for Dom0.

This patch does not affect 32-bit domain, because Variable "lowmem" is
set to true at the beginning. If failed to allocate bank0 under 4GB,
need to panic for 32-bit domain, because 32-bit domain requires bank0
be allocated under 4GB.

For 64-bit domain, set "lowmem" to false, and continue allocating
memory from above 4GB.

Signed-off-by: Peng Fan 
Cc: Stefano Stabellini 
Cc: Julien Grall 
---

This patch is to resolve the issue mentioned in
https://lists.xen.org/archives/html/xen-devel/2016-09/msg00235.html

 Tested results:
 (XEN) Allocating 1:1 mappings totalling 2048MB for dom0:
 (XEN) BANK[0] 0x008800-0x00f800 (1792MB)
 (XEN) BANK[1] 0x09e000-0x09f000 (256MB)
 1792M allocated in 4GB address space.

V4:
 Address comments in V3: 
https://lists.xen.org/archives/html/xen-devel/2016-09/msg02499.html
 Drop uneccessary check when failed to allocate memory under 4GB
 Refine comments according to Julien's suggestion in V3.
 Keep "bits <= (lowmem ? 32 : PADDR_BITS)", but not changed to "bits <= 32"

V3:
 Add more commit log
 Add more comments
 Add back panic if failed to allocate bank0 under 4GB for 32-bit domain.

V2:
 Remove the bootargs dom0_lowmem introduced in V1.
 Following 
"https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg01459.html;
 to allocate as much as possible lowmem.

 xen/arch/arm/domain_build.c | 33 ++---
 1 file changed, 22 insertions(+), 11 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 35ab08d..6b5ac8d 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -195,9 +195,9 @@ fail:
  *bank. Partly this is just easier for us to deal with, but also
  *the ramdisk and DTB must be placed within a certain proximity of
  *the kernel within RAM.
- * 3. For 32-bit dom0 we want to place as much of the RAM as we
- *reasonably can below 4GB, so that it can be used by non-LPAE
- *enabled kernels.
+ * 3. For dom0 we want to place as much of the RAM as we reasonably can
+ *below 4GB, so that it can be used by non-LPAE enabled kernels (32-bit)
+ *or when a device assigned to dom0 can only do 32-bit DMA access.
  * 4. For 32-bit dom0 the kernel must be located below 4GB.
  * 5. We want to have a few largers banks rather than many smaller ones.
  *
@@ -230,7 +230,8 @@ fail:
  * we give up.
  *
  * For 32-bit domain we require that the initial allocation for the
- * first bank is under 4G. Then for the subsequent allocations we
+ * first bank is under 4G. For 64-bit domain, the first bank is preferred
+ * to be allocated under 4G. Then for the subsequent allocations we
  * initially allocate memory only from below 4GB. Once that runs out
  * (as described above) we allow higher allocations and continue until
  * that runs out (or we have allocated sufficient dom0 memory).
@@ -244,7 +245,7 @@ static void allocate_memory(struct domain *d, struct 
kernel_info *kinfo)
 unsigned int order = get_11_allocation_size(kinfo->unassigned_mem);
 int i;
 
-bool_t lowmem = is_32bit_domain(d);
+bool_t lowmem = true;
 unsigned int bits;
 
 /*
@@ -269,20 +270,30 @@ static void allocate_memory(struct domain *d, struct 
kernel_info *kinfo)
 {
 pg = alloc_domheap_pages(d, order, MEMF_bits(bits));
 if ( pg != NULL )
+{
+if ( !insert_11_bank(d, kinfo, pg, order) )
+BUG(); /* Cannot fail for first bank */
+
 goto got_bank0;
+}
 }
 order--;
 }
 
-panic("Unable to allocate first memory bank");
-
- got_bank0:
+/* Failed to allocate bank0 under 4GB */
+if ( is_32bit_domain(d) )
+panic("Unable to allocate first memory bank.");
 
-if ( !insert_11_bank(d, kinfo, pg, order) )
-BUG(); /* Cannot fail for first bank */
+/* Try to allocate memory from above 4GB */
+printk(XENLOG_INFO "No bank has been allocated below 4GB.\n");
+lowmem = false;
 
-/* Now allocate more memory and fill in additional banks */
+ got_bank0:
 
+/*
+ * If we failed to allocate bank0 under 4GB, continue allocating
+ * memory from above 4GB and fill in banks.
+ */
 order = get_11_allocation_size(kinfo->unassigned_mem);
 while ( kinfo->unassigned_mem && kinfo->mem.nr_banks < NR_MEM_BANKS )
 {
-- 
2.6.6


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

Re: [Xen-devel] [RFC 0/5] xen/arm: support big.little SoC

[Peng Fan]

On Thu, Sep 22, 2016 at 12:21:00PM +0100, Julien Grall wrote:

According to George's comments,
Then, I think we could use affinity to restrict little vcpus be scheduled 
on little vcpus,
and restrict big vcpus on big vcpus. Seems no need to consider soft 
affinity, use hard
affinity is to handle this.

We may need to provide some interface to let xl can get the information 
such as
big.little or smp. if it is big.little, which is big and which is little.

For how to differentiate cpus, I am looking the linaro eas cpu topology 
code,
The code has not been upstreamed (:, but merged into google android kernel.
I only plan to take some necessary code, such as device tree parse and
cpu topology build, because we only need to know the computing capacity of 
each pcpu.

Some doc about eas piece, including dts node examples:
https://git.linaro.org/arm/eas/kernel.git/blob/refs/heads/lsk-v4.4-eas-v5.2:/Documentation/devicetree/bindings/scheduler/sched-energy-costs.txt
>>>
>>>I am reluctant to take any non-upstreamed bindings in Xen. There is a similar
>>>series going on the lklm [1].
>>
>>For how to differentiate cpu classes, how about directly use
>>compatible property of each cpu node?
>
>What do you mean by cpu classes? If it is power, then the compatible will not
>help here. You may have a platform with the same core (e.g cortex A53) but
>different silicon implementation, so the power efficiency will be different.

cpu classes, I mean cpu clusters. I checked the cpu capacity code[1] you listed,
it use dmips from dhystone. But now what I plan to implement to block vcpu
from being scheduled within big.LITTLE.

In my case, vcpu will be restricted in A53 or A72.

In the same cluster, different cores may run at different cpu freq or all the 
cores
run at the same freq. This depends on soc implementation.

This needs xen to choose which pcpu to run the vcpu, and no local migration 
scheduling vcpu on the cpus in one cluster.

Considering power for future, dmips needs to be used, but also need to 
differentiate
cpus from different clusters. So "dmips + compatible" both needs to be 
considered.

For cpus in one cluster, also need to take the dmips info for xen scheduling
vcpu between pcpu effectively.

Thanks,
Peng.

[1]https://lwn.net/Articles/699569/
>
>Regards,
>
>-- 
>Julien Grall

-- 

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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 85b88deb18857af261c655dfa833de17b19d7163
baseline version:
 ovmf 7f1bf51bdbcaf9dd46f77cf4bd5e69a294dd995e

Last test of basis   101097  2016-09-22 06:49:50 Z0 days
Testing same since   101113  2016-09-22 21:45:32 Z0 days1 attempts


People who touched revisions under test:
  Tapan Shah 

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



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=85b88deb18857af261c655dfa833de17b19d7163
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
85b88deb18857af261c655dfa833de17b19d7163
+ branch=ovmf
+ revision=85b88deb18857af261c655dfa833de17b19d7163
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' x85b88deb18857af261c655dfa833de17b19d7163 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : 

[Xen-devel] [qemu-mainline baseline-only test] 67748: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 67748 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67748/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-winxpsp3  6 xen-bootfail REGR. vs. 67746

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 67746
 test-amd64-amd64-amd64-pvgrub 10 guest-start  fail  like 67746

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail never pass

version targeted for testing:
 qemuub98bbea2d94dc5902acaa3a5dd7f9057cc82cdb1
baseline version:
 qemuua008535b9fa396226ff9cf78b8ac5f3584bda58e

Last test of basis67746  2016-09-22 07:50:19 Z0 days
Testing same since67748  2016-09-22 20:44:39 Z0 days1 attempts


People who touched revisions under test:
  Peter Maydell 
  Richard Henderson 

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

Re: [Xen-devel] [RFC 0/5] xen/arm: support big.little SoC

[Peng Fan]

On Thu, Sep 22, 2016 at 07:54:02PM +0100, Julien Grall wrote:
>Hi Stefano,
>
>On 22/09/2016 18:31, Stefano Stabellini wrote:
>>On Thu, 22 Sep 2016, Julien Grall wrote:
>>>Hello Peng,
>>>
>>>On 22/09/16 10:27, Peng Fan wrote:
On Thu, Sep 22, 2016 at 10:50:23AM +0200, Dario Faggioli wrote:
>On Thu, 2016-09-22 at 14:49 +0800, Peng Fan wrote:
>>On Wed, Sep 21, 2016 at 08:11:43PM +0100, Julien Grall wrote:
>A feature like `xl cpupool-biglittle-split' can still be interesting,

"cpupool-cluster-split" maybe a better name?
>>>
>>>You seem to assume that a cluster, from the MPIDR point of view, can only
>>>contain the same set of CPUs. I don't think this is part of the architecture,
>>>so this may not be true in the future.
>>
>>Interesting. I also understood that a cluster can only have one kind if
>>cpus. Honestly it would be a little insane for it to be otherwise :-)
>
>I don't think this is insane (or maybe I am insane :)). Cluster usually
>doesn't share all L2 cache (assuming L1 is local to each core) and L3 cache
>may not be present, so if you move a task from one cluster to another you
>will add latency because the new L2 cache has to be refilled.
>
>The use case of big.LITTLE is big cores are used for short period of burst
>and little core are used for the rest (e.g listening audio, fetching
>mail...). If you want to reduce latency when switch between big and little
>CPUs, you may want to put them within the same cluster.
>
>Also, as mentioned in another thread, you may have a platform with the same
>micro-architecture (e.g Cortex A-53) but different silicon implementation
>(e.g to have a different frequency, power efficiency). Here the concept of
>big.LITTLE is more blurred.

That is possible that in one cluster, different pcpus runs with different cpu
frequency. This depends on hardware design. Some may require all the cores in
one cluster runs at the same frequency, some may have more complicated design 
that
supports different cores runs at different frequency.

This is just like you have a smp system, but different cores can run at
different cpu frequency. I think this is not what bit.LITTLE means.

For the pcpus in one cluster, xen needs to choose which pcpu for vcpu
for power or etc.


Thanks,
Peng.

>
>That's why I am quite reluctant to name (even if it may be more handy to the
>user) "big" and "little" the different CPU set.
>
>Cheers,
>
>-- 
>Julien Grall

-- 

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

Re: [Xen-devel] [v2 0/3] Enable L2 Cache Allocation Technology

[Yi Sun]

On 16-09-22 11:18:12, Wei Liu wrote:
> Hi Yi
> 
> Thanks for submitting this series.  I see that all the actual patches
> are not chained to 0/3. It would be better if they show up as replies to
> 0/3.
> 
> The workflow for sending patch series differs from person to person, so
> we don't want to  dictate how you use your tool. But we have written a
> wiki page on how to submit patches to xen-devel. That contains some tips
> about git.
> 
> https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#Sending_the_patches_to_the_list
> 
> Feel free to ask questions here. I would be happy to share how I do it
> if you're interested.
> 
> Wei.

Hi, Wei,

Thanks a lot for your kindness! I just went through the wiki and found I
should use '--in-reply-to=', right? If you can share your steps that would
be great.

Can I send the patches again after addressing Ian's comments?

Thanks,
Yi

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

Re: [Xen-devel] [RFC 0/5] xen/arm: support big.little SoC

[Peng Fan]

On Thu, Sep 22, 2016 at 12:29:53PM +0100, Julien Grall wrote:
>Hello Peng,
>
>On 22/09/16 10:27, Peng Fan wrote:
>>On Thu, Sep 22, 2016 at 10:50:23AM +0200, Dario Faggioli wrote:
>>>On Thu, 2016-09-22 at 14:49 +0800, Peng Fan wrote:
On Wed, Sep 21, 2016 at 08:11:43PM +0100, Julien Grall wrote:
>>>A feature like `xl cpupool-biglittle-split' can still be interesting,
>>
>>"cpupool-cluster-split" maybe a better name?
>
>You seem to assume that a cluster, from the MPIDR point of view, can only
>contain the same set of CPUs. I don't think this is part of the architecture,
>so this may not be true in the future.
>
>>
>>>completely orthogonally and independently from the affinity based work,
>>>and this series looks like it can be used to implement that. :-)
>>
>>Agree. All pcpus default can be assigned into cpupool0 based on the affinity 
>>work.
>
>What do you mean by affinity? From MPIDR?

vcpu hard affinity. When allocate or initialize vcpu, the hard affinity needs
to be inititialized.

Thanks,
Peng.

>
>>We could add one like "cpupool-numa-split" to split different classes cpu
>>into different cpupools.
>
>Regards,
>
>-- 
>Julien Grall

-- 

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

Re: [Xen-devel] [PATCH V3] xen/arm: domain_build: allocate lowmem for dom0 as much as possible

[Peng Fan]

On Thu, Sep 22, 2016 at 04:23:05PM +0100, Julien Grall wrote:
>Hello Peng,
>
>On 22/09/16 10:16, Peng Fan wrote:
>>On AArch64 SoCs, some IPs may only have the capability to access
>>32 bits address space. The physical memory assigned for Dom0 maybe
>>not in 4GB address space, then the IPs will not work properly.
>>So need to allocate memory under 4GB for Dom0.
>>
>>There is no restriction that how much lowmem needs to be allocated for
>>Dom0. Dom0 now use 1:1 mapping, but DomU does not use 1:1 mapping,
>>there is no need to reserve lowmem for DomU, so allocate lowmem as much
>>as possible for Dom0.
>
>The last sentence is confusing. I would avoid to mention domU use case here.

Drop it in V4.

>
>>
>>This patch does not affect 32-bit domain, because Variable "lowmem" is
>>set to true at the beginning. If failed to allocate bank0 under 4GB,
>>need to panic for 32-bit domain, because 32-bit domain requires bank0
>>be allocated under 4GB.
>>
>>For 64-bit domain, set "lowmem" to false, and continue allocating
>>memory from higher memory space.
>>
>>Signed-off-by: Peng Fan 
>>Cc: Stefano Stabellini 
>>Cc: Julien Grall 
>>---
>>
>>This patch is to resolve the issue mentioned in
>>https://lists.xen.org/archives/html/xen-devel/2016-09/msg00235.html
>>
>>V3:
>> Add more commit log
>> Add more comments
>> Add back panic if failed to allocate bank0 under 4GB for 32-bit domain.
>>
>>V2:
>> Remove the bootargs dom0_lowmem introduced in V1.
>> Following 
>> "https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg01459.html;
>> to allocate as much as possible lowmem.
>>
>> Tested results:
>> (XEN) Allocating 1:1 mappings totalling 2048MB for dom0:
>> (XEN) BANK[0] 0x008800-0x00f800 (1792MB)
>> (XEN) BANK[1] 0x09e000-0x09f000 (256MB)
>> 1792M allocated in 4GB address space.
>>
>> xen/arch/arm/domain_build.c | 44 +++-
>> 1 file changed, 31 insertions(+), 13 deletions(-)
>>
>>diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>>index 35ab08d..a9c37c4 100644
>>--- a/xen/arch/arm/domain_build.c
>>+++ b/xen/arch/arm/domain_build.c
>>@@ -195,9 +195,10 @@ fail:
>>  *bank. Partly this is just easier for us to deal with, but also
>>  *the ramdisk and DTB must be placed within a certain proximity of
>>  *the kernel within RAM.
>>- * 3. For 32-bit dom0 we want to place as much of the RAM as we
>>- *reasonably can below 4GB, so that it can be used by non-LPAE
>>- *enabled kernels.
>>+ * 3. For dom0 we want to place as much of the RAM as we reasonably can
>>+ *below 4GB, so that the devices have the limitation to access 64 bits
>>+ *address space and work properly and it can be used by non-LPAE enabled
>>+ *kernels.
>
>I would say: "For dom0 we want to place as much of the RAM as we reasonably
>can below 4GB, so that it can be used by non-LPAE enabled kernels (32-bit) or
>when a device assigned to dom0 can only do 32-bit DMA access".

Thanks. Fix in V4.

>
>>  * 4. For 32-bit dom0 the kernel must be located below 4GB.
>>  * 5. We want to have a few largers banks rather than many smaller ones.
>>  *
>>@@ -230,7 +231,8 @@ fail:
>>  * we give up.
>>  *
>>  * For 32-bit domain we require that the initial allocation for the
>>- * first bank is under 4G. Then for the subsequent allocations we
>>+ * first bank is under 4G. For 64-bit domain, the first bank is preferred
>>+ * to be allocated under 4G. Then for the subsequent allocations we
>>  * initially allocate memory only from below 4GB. Once that runs out
>>  * (as described above) we allow higher allocations and continue until
>>  * that runs out (or we have allocated sufficient dom0 memory).
>>@@ -240,11 +242,11 @@ static void allocate_memory(struct domain *d, struct 
>>kernel_info *kinfo)
>> const unsigned int min_low_order =
>> get_order_from_bytes(min_t(paddr_t, dom0_mem, MB(128)));
>> const unsigned int min_order = get_order_from_bytes(MB(4));
>>-struct page_info *pg;
>>+struct page_info *pg = NULL;
>> unsigned int order = get_11_allocation_size(kinfo->unassigned_mem);
>> int i;
>>
>>-bool_t lowmem = is_32bit_domain(d);
>>+bool_t lowmem = true;
>> unsigned int bits;
>>
>> /*
>>@@ -265,24 +267,40 @@ static void allocate_memory(struct domain *d, struct 
>>kernel_info *kinfo)
>>  */
>> while ( order >= min_low_order )
>> {
>>-for ( bits = order ; bits <= (lowmem ? 32 : PADDR_BITS); bits++ )
>>+for ( bits = order ; bits <= 32 ; bits++ )
>
>Why this change? If we ever decide to set lowmen to false, it will not work
>anymore.

Reasonable. Fix in V4.

>
>> {
>> pg = alloc_domheap_pages(d, order, MEMF_bits(bits));
>> if ( pg != NULL )
>>+{
>>+if ( !insert_11_bank(d, kinfo, pg, order) )
>>+BUG(); /* Cannot fail for first bank */
>>+
>> 

Re: [Xen-devel] [PATCH v5 16/16] livepatch: arm[32, 64], x86: NOP test-case

[Konrad Rzeszutek Wilk]

.snip..
> > While on ARM32 there are 24 bytes:
> > 
> >   e52db004push{fp}
> >   e28db000add fp, sp, #0 <- NOP
> >   e3a8mov r0, #8 <- NOP
> >   e24bd000sub sp, fp, #0 <- NOP
> >   e49db004pop {fp}
> >   e12fff1ebx  lr
> > 
> > And we can NOP instruction 2,3, and 4.
> 
> Why don't you NOP push {fp} and pop {fp}? At first glance, I am a bit
> surprised that the compiler is generating them (maybe it is because you have
> debug enabled?) and would have expect to have:
> 
> mov r0, #8
> bx lr
> 
> NOPing all the instructions but the last one would simplify at lot the test
> case below.
> 
> [...]

..snip..
> With my suggestion above, the two ARM code could become:
> 
> #ifdef CONFIG_ARM
>   .old_addr = (void *)MINOR_VERSION_ADDR,
>   .new_size = MINOR_VERSION_SIZE - 4,
> #endif
> 
> The "- 4" is to avoid replacing the return.

Done!

From 8ade51e1866b86c7660277bb19100db337d432b4 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk 
Date: Sat, 10 Sep 2016 20:41:24 -0400
Subject: [PATCH v6] livepatch: arm[32,64],x86: NOP test-case

The test-case is quite simple - we NOP the 'xen_minor_version'.
The amount of NOPs depends on the architecture.

On x86 the function is 11 bytes long:

   55  push   %rbp  <- NOP
   48 89 e5mov%rsp,%rbp <- NOP
   b8 04 00 00 00  mov$0x4,%eax <- NOP
   5d  pop%rbp  <- NOP
   c3  retq

We can NOP everything but the last instruction (so 10 bytes).

On ARM64 its 8 bytes:

  52800100mov w0, #0x8 <- NOP
  d65f03c0ret

We can NOP the first instruction.

While on ARM32 there are 24 bytes:

  e52db004push{fp}   <- NOP
  e28db000add fp, sp, #0 <- NOP
  e3a8mov r0, #8 <- NOP
  e24bd000sub sp, fp, #0 <- NOP
  e49db004pop {fp}   <- NOP
  e12fff1ebx  lr

And we can NOP instructions 1 through 5.

Granted this code may be different per compiler!

Hence if anybody does run this test-case - they should
verify that the assumptions made here are correct.

Signed-off-by: Konrad Rzeszutek Wilk 
---
Cc: Julien Grall 
Cc: Stefano Stabellini 
Cc: Jan Beulich 
Cc: Andrew Cooper 

v3: New submission.
v4: Redo the ARM code to NOP over push/pop as well.
---
 xen/test/livepatch/Makefile  | 15 +-
 xen/test/livepatch/xen_nop.c | 48 
 2 files changed, 62 insertions(+), 1 deletion(-)
 create mode 100644 xen/test/livepatch/xen_nop.c

diff --git a/xen/test/livepatch/Makefile b/xen/test/livepatch/Makefile
index 9439f62..76a779a 100644
--- a/xen/test/livepatch/Makefile
+++ b/xen/test/livepatch/Makefile
@@ -18,6 +18,7 @@ CODE_SZ=$(shell nm --defined -S $(1) | grep $(2) | awk '{ 
print "0x"$$2}')
 LIVEPATCH := xen_hello_world.livepatch
 LIVEPATCH_BYE := xen_bye_world.livepatch
 LIVEPATCH_REPLACE := xen_replace_world.livepatch
+LIVEPATCH_NOP := xen_nop.livepatch
 
 default: livepatch
 
@@ -25,10 +26,12 @@ install: livepatch
$(INSTALL_DATA) $(LIVEPATCH) $(DESTDIR)$(DEBUG_DIR)/$(LIVEPATCH)
$(INSTALL_DATA) $(LIVEPATCH_BYE) $(DESTDIR)$(DEBUG_DIR)/$(LIVEPATCH_BYE)
$(INSTALL_DATA) $(LIVEPATCH_REPLACE) 
$(DESTDIR)$(DEBUG_DIR)/$(LIVEPATCH_REPLACE)
+   $(INSTALL_DATA) $(LIVEPATCH_NOP) $(DESTDIR)$(DEBUG_DIR)/$(LIVEPATCH_NOP)
 uninstall:
rm -f $(DESTDIR)$(DEBUG_DIR)/$(LIVEPATCH)
rm -f $(DESTDIR)$(DEBUG_DIR)/$(LIVEPATCH_BYE)
rm -f $(DESTDIR)$(DEBUG_DIR)/$(LIVEPATCH_REPLACE)
+   rm -f $(DESTDIR)$(DEBUG_DIR)/$(LIVEPATCH_NOP)
 
 .PHONY: clean
 clean::
@@ -41,9 +44,13 @@ clean::
 .PHONY: config.h
 config.h: OLD_CODE_SZ=$(call CODE_SZ,$(BASEDIR)/xen-syms,xen_extra_version)
 config.h: NEW_CODE_SZ=$(call CODE_SZ,$<,xen_hello_world)
+config.h: MINOR_VERSION_SZ=$(call 
CODE_SZ,$(BASEDIR)/xen-syms,xen_minor_version)
+config.h: MINOR_VERSION_ADDR=$(call 
CODE_ADDR,$(BASEDIR)/xen-syms,xen_minor_version)
 config.h: xen_hello_world_func.o
(set -e; \
 echo "#define NEW_CODE_SZ $(NEW_CODE_SZ)"; \
+echo "#define MINOR_VERSION_SZ $(MINOR_VERSION_SZ)"; \
+echo "#define MINOR_VERSION_ADDR $(MINOR_VERSION_ADDR)"; \
 echo "#define OLD_CODE_SZ $(OLD_CODE_SZ)") > $@
 
 xen_hello_world.o: config.h
@@ -91,5 +98,11 @@ xen_replace_world.o: config.h
 $(LIVEPATCH_REPLACE): xen_replace_world_func.o xen_replace_world.o note.o
$(LD) $(LDFLAGS) $(build_id_linker) -r -o $(LIVEPATCH_REPLACE) $^
 
+xen_nop.o: config.h
+
+.PHONY: $(LIVEPATCH_NOP)
+$(LIVEPATCH_NOP): xen_nop.o note.o
+   $(LD) $(LDFLAGS) $(build_id_linker) -r -o $(LIVEPATCH_NOP) $^
+
 .PHONY: livepatch
-livepatch: $(LIVEPATCH) $(LIVEPATCH_BYE) $(LIVEPATCH_REPLACE)
+livepatch: $(LIVEPATCH) $(LIVEPATCH_BYE) 

Re: [Xen-devel] [PATCH v5 11/16] livepatch: tests: Make them compile under ARM64

[Konrad Rzeszutek Wilk]

.snip..
> > diff --git a/xen/test/Makefile b/xen/test/Makefile
> > index 8c53040..95c1755 100644
> > --- a/xen/test/Makefile
> > +++ b/xen/test/Makefile
> > @@ -1,6 +1,6 @@
> >  .PHONY: tests
> >  tests:
> I am wondering if there is any way to use the
> > -ifeq ($(XEN_TARGET_ARCH),x86_64)
> > +ifneq $(XEN_TARGET_ARCH),arm32)
> 
> NIT: I am wondering if you could instead use CONFIG_LIVEPATCH here, so the
> tests would only be built when livepatch is enabled.

Lets leave it as is and do it in the future. Right now the tests
are not compiled by default so not much harm here. But I do agree that
somehow exposing the CONFIG_LIVEPATCH and latching it off (in say
tests/livepatch/ directory) is a good TODO item.. 
> 
> > $(MAKE) -f $(BASEDIR)/Rules.mk -C livepatch livepatch
> >  endif
> > 
> > diff --git a/xen/test/livepatch/Makefile b/xen/test/livepatch/Makefile
> > index 48ff843..5db4d9c 100644
> > --- a/xen/test/livepatch/Makefile
> > +++ b/xen/test/livepatch/Makefile
> > @@ -1,5 +1,12 @@
> >  include $(XEN_ROOT)/Config.mk
> > 
> > +ifeq ($(XEN_TARGET_ARCH),x86_64)
> > +OBJCOPY_MAGIC := -I binary -O elf64-x86-64 -B i386:x86-64
> > +endif
> > +ifeq ($(XEN_TARGET_ARCH),arm64)
> > +OBJCOPY_MAGIC := -I binary -O elf64-littleaarch64 -B aarch64
> > +endif
> > +
> >  CODE_ADDR=$(shell nm --defined $(1) | grep $(2) | awk '{print "0x"$$1}')
> >  CODE_SZ=$(shell nm --defined -S $(1) | grep $(2) | awk '{ print "0x"$$2}')
> > 
> > @@ -54,8 +61,9 @@ $(LIVEPATCH): xen_hello_world_func.o xen_hello_world.o 
> > note.o
> >  .PHONY: note.o
> >  note.o:
> > $(OBJCOPY) -O binary --only-section=.note.gnu.build-id 
> > $(BASEDIR)/xen-syms $@.bin
> > -   $(OBJCOPY) -I binary -O elf64-x86-64 -B i386:x86-64 \
> > +   $(OBJCOPY) $(OBJCOPY_MAGIC) \
> >
> > --rename-section=.data=.livepatch.depends,alloc,load,readonly,data,contents 
> > -S $@.bin $@
> > +  --rename-section=.data=.livepatch.depends -S $@.bin $@
> 
> I am not sure why you added this line. Did you intend to replace the
> previous one?

Fixed.
..snip..
> > @@ -25,6 +28,10 @@ const char *xen_hello_world(void)
> >   */
> >  rc = __get_user(tmp, non_canonical_addr);
> >  BUG_ON(rc != -EFAULT);
> > +#endif
> > +#ifdef CONFIG_ARM_64
> 
> NIT: I would use:
> 
> #if defined(CONFIG_ARM) && defined(CONFIG_HAS_ALTERNATIVE)
> 
> in order to handle alternative if we decide to add support for ARM32.

Done!

Here is the updated patch:


From c0dac442d15b5f0095b199ab4fff1fc414fb5719 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk 
Date: Mon, 19 Sep 2016 16:04:55 -0400
Subject: [PATCH v6] livepatch: tests: Make them compile under ARM64

We need to two things:
1) Wrap the platform-specific objcopy parameters in defines
   The input and output parameters for $(OBJCOPY) are different
   based on the platforms. As such provide them in the
   OBJCOPY_MAGIC define and use that.

2) The alternative is a bit different (exists only under ARM64
   and x86), while and there are no exceptions under ARM at all.
   We use the LIVEPATCH_FEATURE CPU id feature for ARM similar to
   how it is done on x86.

We are not yet attempting to build them under ARM32 so
that is still ifdefed out.

Signed-off-by: Konrad Rzeszutek Wilk 

---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 

v1: First submission
v2: Corrected description by Julien
Add #ifeq instead of #else for ARM case.
v3: Moved 'asm(alter..)' by one space to the left.
v4: Rebase on top of "livepatch/tests: Make .livepatch.depends be read-only"
Rewrote the commit description 2) a bit.
v6: Fixed the note.o --rename-section
Replaced CONFIG_ARM_64 with defined(CONFIG_ARM) &&
defined(CONFIG_HAS_ALTERNATIVE)
---
 xen/test/Makefile |  2 +-
 xen/test/livepatch/Makefile   | 11 +--
 xen/test/livepatch/xen_hello_world_func.c |  7 +++
 3 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/xen/test/Makefile b/xen/test/Makefile
index 8c53040..95c1755 100644
--- a/xen/test/Makefile
+++ b/xen/test/Makefile
@@ -1,6 +1,6 @@
 .PHONY: tests
 tests:
-ifeq ($(XEN_TARGET_ARCH),x86_64)
+ifneq $(XEN_TARGET_ARCH),arm32)
$(MAKE) -f $(BASEDIR)/Rules.mk -C livepatch livepatch
 endif
 
diff --git a/xen/test/livepatch/Makefile b/xen/test/livepatch/Makefile
index 48ff843..d844ad4 100644
--- a/xen/test/livepatch/Makefile
+++ b/xen/test/livepatch/Makefile
@@ -1,5 +1,12 @@
 include $(XEN_ROOT)/Config.mk
 
+ifeq ($(XEN_TARGET_ARCH),x86_64)
+OBJCOPY_MAGIC := -I binary -O elf64-x86-64 -B i386:x86-64
+endif
+ifeq ($(XEN_TARGET_ARCH),arm64)
+OBJCOPY_MAGIC := -I binary -O elf64-littleaarch64 -B aarch64
+endif
+
 

Re: [Xen-devel] [PATCH v6 4/4] x86/ioreq server: Reset outstanding p2m_ioreq_server entries when an ioreq server unmaps.

[Yu Zhang]

On 9/23/2016 2:06 AM, George Dunlap wrote:

On Tue, Sep 20, 2016 at 3:57 AM, Yu Zhang  wrote:

Well, for the logic of p2m type recalculation, similarities between
p2m_ioreq_server
and other changeable types exceeds their differences. As to the special
cases, how
about we use a macro, i.e. p2m_is_ioreq?

That'd be better than the open coded check, but would still result
in (taking the above example)

p2m_is_changeable(ept_entry->sa_p2mt) &&
!p2m_is_ioreq(ept_entry->sa_p2mt) )

? What I'd prefer is a predicate that can be applied here on its own,
without involving && or ||.


OK. I can think of 2 scenarios that p2m_ioreq_server needs special
handling:

1> In ept_get_entry()/recal_type(), the p2m types are supposed to return
as it is, instead of
changing to p2m_log_dirty. So we can use a macro or a inline function
like p2m_check_changeable(),
which combines the

p2m_is_changeable(ept_entry->sa_p2mt) &&
!p2m_is_ioreq(ept_entry->sa_p2mt) )

together.

2> In resolve_misconfig()/do_recalc(), the entry_count gets decremented.
We
do not need this new inline function, because they are in a separate
if() statement.

Is this OK? :)

Sounds reasonable. But please give George and others a chance to
voice their opinions before you go that route.

Jan


Hi George,

   Any comments on this series? :)

Well regarding the question you and Jan have been discussing, of what
to call / how to do the checks for changeable-but-not-ioreq, I don't
really care very much. :-)

I'm sorry it's taking so long to look at this series -- the code
you're trying to modify is already a bit of a tangled mess, and I
think this patch has a ways to go before it's ready.  I do think this
series is important, so I'll be coming back to it first thing Monday.

Regarding the pausing added in this patch -- you listed two reasons in
the first patch for the domain pausing.  The first was detecting
read-modify-write and acting appropriately; I think that can be done
with the patch that I sent you.

The second was the deadlock due to grabbing locks in a different
order.  I'm afraid having such a thing lying around, even if you've
avoided it for now by pausing the domain, is another major trap that
we should try to avoid laying for future developers if we can at all
help it.  The normal thing to do here is to simply have a locking
discipline -- in this case, I don't think it would be too difficult to
work out a locking order that would avoid the deadlock in a more
robust way than pausing and unpausing the domain.

With those two handled, we shouldn't need to pause the domain any more.


Thank you, George. Hope we can find a more elegant approach. :-)
B.R.
Yu


Thanks for your work on this -- I'll get back to patch 4/4 next week.

Peace,
  -George




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

Re: [Xen-devel] [PATCH v5 08/16] livepatch/arm/x86: Check payload for for unwelcomed symbols.

[Konrad Rzeszutek Wilk]

> > +bool arch_livepatch_symbol_deny(const struct livepatch_elf *elf,
> > +const struct livepatch_elf_sym *sym)
> > +{
> > +#ifdef CONFIG_ARM_32
> 
> Out of interest, is there any particular reason to use #ifdef rather than
> adding the function in {arm32/arm64}/livepatch.c?

I updated it be like that:

From 5fc79e4fc3c0770ee4f6e7e0ed666e593deced65 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk 
Date: Tue, 13 Sep 2016 13:15:07 -0400
Subject: [PATCH v6] livepatch/arm/x86: Check payload for for unwelcomed
 symbols.

Certain platforms, such as ARM [32|64] add extra mapping symbols
such as $x (for ARM64 instructions), or more interesting to
this patch: $t (for Thumb instructions). These symbols are supposed
to help the final linker to make any adjustments (such as
add an veneer). But more importantly - we do not compile Xen
with any Thumb instructions (which are variable length) - and
if we find these mapping symbols we should disallow such payload.

Reviewed-by: Julien Grall 
Signed-off-by: Konrad Rzeszutek Wilk 
---
Cc: Konrad Rzeszutek Wilk 
Cc: Ross Lagerwall 
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: Andrew Cooper 

v3: New submission.
Use [i] instead of sym (as that will always be NULL).
v4: Use bool instead of int for return
Update comment in common code about ARM odd symbols.
s/_check/_deny/ to make it more clear.
v5: Also check for $t.* wildcard.
Use Julien's variant where we roll the [2] check in the return.
v6: s/suppose/supposed/ in commit description.
Move arch_livepatch_symbol_deny in arm[32|64]/livepatch.c
Added Julien's Reviewed-by.
---
 xen/arch/arm/arm32/livepatch.c | 13 +
 xen/arch/arm/arm64/livepatch.c |  7 +++
 xen/arch/x86/livepatch.c   |  7 +++
 xen/common/livepatch_elf.c |  7 +++
 xen/include/xen/livepatch.h|  2 ++
 5 files changed, 36 insertions(+)

diff --git a/xen/arch/arm/arm32/livepatch.c b/xen/arch/arm/arm32/livepatch.c
index 80f9646..5fc2e63 100644
--- a/xen/arch/arm/arm32/livepatch.c
+++ b/xen/arch/arm/arm32/livepatch.c
@@ -20,6 +20,19 @@ int arch_livepatch_verify_elf(const struct livepatch_elf 
*elf)
 return -EOPNOTSUPP;
 }
 
+bool arch_livepatch_symbol_deny(const struct livepatch_elf *elf,
+const struct livepatch_elf_sym *sym)
+{
+/*
+ * Xen does not use Thumb instructions - and we should not see any of
+ * them. If we do, abort.
+ */
+if ( sym->name && sym->name[0] == '$' && sym->name[1] == 't' )
+return ( !sym->name[2] || sym->name[2] == '.' );
+
+return false;
+}
+
 int arch_livepatch_perform_rela(struct livepatch_elf *elf,
 const struct livepatch_elf_sec *base,
 const struct livepatch_elf_sec *rela)
diff --git a/xen/arch/arm/arm64/livepatch.c b/xen/arch/arm/arm64/livepatch.c
index 0fe73d9..0f25e1e 100644
--- a/xen/arch/arm/arm64/livepatch.c
+++ b/xen/arch/arm/arm64/livepatch.c
@@ -95,6 +95,13 @@ int arch_livepatch_verify_elf(const struct livepatch_elf 
*elf)
 return 0;
 }
 
+bool arch_livepatch_symbol_deny(const struct livepatch_elf *elf,
+const struct livepatch_elf_sym *sym)
+{
+/* No special checks on ARM 64. */
+return false;
+}
+
 enum aarch64_reloc_op {
 RELOC_OP_NONE,
 RELOC_OP_ABS,
diff --git a/xen/arch/x86/livepatch.c b/xen/arch/x86/livepatch.c
index 7a369a0..9663ef6 100644
--- a/xen/arch/x86/livepatch.c
+++ b/xen/arch/x86/livepatch.c
@@ -131,6 +131,13 @@ bool arch_livepatch_symbol_ok(const struct livepatch_elf 
*elf,
 return true;
 }
 
+bool arch_livepatch_symbol_deny(const struct livepatch_elf *elf,
+const struct livepatch_elf_sym *sym)
+{
+/* No special checks on x86. */
+return false;
+}
+
 int arch_livepatch_perform_rel(struct livepatch_elf *elf,
const struct livepatch_elf_sec *base,
const struct livepatch_elf_sec *rela)
diff --git a/xen/common/livepatch_elf.c b/xen/common/livepatch_elf.c
index dec904a..53b3fba 100644
--- a/xen/common/livepatch_elf.c
+++ b/xen/common/livepatch_elf.c
@@ -251,6 +251,13 @@ static int elf_get_sym(struct livepatch_elf *elf, const 
void *data)
 
 sym[i].sym = s;
 sym[i].name = strtab_sec->data + delta;
+/* e.g. On ARM we should NEVER see $t* symbols. */
+if ( arch_livepatch_symbol_deny(elf, [i]) )
+{
+dprintk(XENLOG_ERR, LIVEPATCH "%s: Symbol '%s' should not be in 
payload!\n",
+elf->name, sym[i].name);
+return -EINVAL;
+}
 }
 elf->nsym = nsym;
 
diff --git a/xen/include/xen/livepatch.h b/xen/include/xen/livepatch.h
index 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  9 redhat-install fail REGR. vs. 101069

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail REGR. vs. 101069
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101069
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101069
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 101069
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 101069
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101069

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 build-amd64-rumprun   5 rumprun-buildfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 build-i386-rumprun5 rumprun-buildfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass

version targeted for testing:
 xen  b106f15efbfc99f52ccb94ab8ca7fdb21fcf
baseline version:
 xen  a9c9600bb5b2f79058ce24f0ef51f22c78e89ba1

Last test of basis   101069  2016-09-21 01:49:11 Z1 days
Failing since101086  2016-09-21 20:36:20 Z1 days2 attempts
Testing same since   101102  2016-09-22 12:16:01 Z0 days1 attempts


People who touched revisions under test:
  Dario Faggioli 
  George Dunlap 
  Jan Beulich 
  Julien Grall 
  Konrad Rzeszutek Wilk 
  Razvan Cojocaru 
  Stefano Stabellini 

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

[Xen-devel] [xen-4.5-testing test] 101106: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail in 101070 pass 
in 101106
 test-amd64-amd64-libvirt-vhd 13 guest-saverestore fail in 101070 pass in 101106
 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail in 101070 
pass in 101106
 test-amd64-amd64-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail in 101088 
pass in 101106
 test-amd64-i386-libvirt 14 guest-saverestore fail in 101088 pass in 101106
 test-amd64-i386-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail in 101088 
pass in 101106
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail pass in 
101070
 test-armhf-armhf-xl-multivcpu  6 xen-boot  fail pass in 101088
 test-amd64-i386-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail pass in 
101088

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop  fail in 101070 like 101045
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 101088 blocked 
in 101045
 test-amd64-amd64-xl-rtds  6 xen-boot fail  like 101045
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 101045
 test-armhf-armhf-xl-rtds 11 guest-start  fail  like 101045
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101045
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101045

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu 12 migrate-support-check fail in 101088 never 
pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-check fail in 101088 
never pass
 test-armhf-armhf-xl-rtds12 migrate-support-check fail in 101088 never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-check fail in 101088 never pass
 build-amd64-rumprun   5 rumprun-buildfail   never pass
 build-i386-rumprun5 rumprun-buildfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-qcow2 10 guest-start  fail never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 10 guest-start  fail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-vhd  10 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass

version targeted for testing:
 xen  84e4e56aa643444f13686362535d8ca8a06839c6
baseline version:
 xen  e4ae4b03d35babc9624b7286f1ea4c6749bad84b

Last test of basis   101045  2016-09-20 12:58:05 Z2 days
Testing same since   101070  2016-09-21 02:03:18 Z1 days3 attempts


People who touched revisions under test:
  Ian Jackson 

jobs:
 build-amd64-xtf  pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 

Re: [Xen-devel] [PATCH v7 1/5] livepatch: Disallow applying after an revert

[Konrad Rzeszutek Wilk]

On Thu, Sep 22, 2016 at 03:21:00AM -0600, Jan Beulich wrote:
> >>> On 21.09.16 at 18:57,  wrote:
> > @@ -325,8 +327,13 @@ static int move_payload(struct payload *payload, 
> > struct livepatch_elf *elf)
> >   * and .shstrtab. For the non-relocate we allocate and copy these
> >   * via other means - and the .rel we can ignore as we only use it
> >   * once during loading.
> > + *
> > + * Also ignore sections with zero size. Those can be .data, or 
> > .bss.
> 
> Or any others. Please make this apparent by adding "e.g." or some
> such.
> 
> > + *
> > + * This logic must MATCH what is done in 
> > livepatch_elf_resolve_symbols.
> 
> Instead of such a comment, is it perhaps worth making an inline
> function or macro to cover the three instances where these
> checks need to match up?
> 
> > @@ -374,14 +381,18 @@ static int move_payload(struct payload *payload, 
> > struct livepatch_elf *elf)
> >  
> >  for ( i = 1; i < elf->hdr->e_shnum; i++ )
> >  {
> > -if ( elf->sec[i].sec->sh_flags & SHF_ALLOC )
> > +if ( elf->sec[i].sec->sh_flags & SHF_ALLOC && 
> > elf->sec[i].sec->sh_size )
> 
> Please parenthesize the & in cases like this.


Thanks!

Please see the updated patch:
From 829aa410c06231906b5ee786b10ede343ac39884 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk 
Date: Tue, 13 Sep 2016 12:02:20 -0400
Subject: [PATCH v8] livepatch: Disallow applying after an revert

On general this is unhealthy - as the payload's .bss (definitly)
or .data (maybe) will be modified once the payload is running.

Doing an revert and then re-applying the payload with a non-pristine
.bss or .data can lead to unforseen consequences (.bss are assumed
to always contain zero value but now they may have a different value).

There is one exception - if the payload contains only one .data section
- the .livepatch.funcs, then it is OK to re-apply an revert.
We detect this rather simply (if there is one RW section and its name
is .livepatch.funcs) - but the payload may have many other RW sections
that are not used at all (such as .bss or .data sections with zero
length). To not account those we also ignore sections with sh_size
being zero.

Suggested-by: Jan Beulich 
Signed-off-by: Konrad Rzeszutek Wilk 

---
Cc: Andrew Cooper 
Cc: Jan Beulich 

v6: New submission.
v7: Use 'bool' instead of 'bool_t'
  - Ignore sh_size==0 sections as a way to make the exception check work.
  - Also add the sh_size==0 check in livepatch_elf_resolve_symbols.
  - Update comment in load move_payload to mention
"livepatch_elf_resolve_symbols"
v8: Expand the comment
  - Parenthesize the &
  - Introduce livepatch_elf_ignore_section which does the sh_size and
SHF_ALLOC check
---
 docs/misc/livepatch.markdown|  7 +++
 xen/common/livepatch.c  | 34 +++---
 xen/common/livepatch_elf.c  |  3 +--
 xen/include/xen/livepatch_elf.h |  4 
 4 files changed, 43 insertions(+), 5 deletions(-)

diff --git a/docs/misc/livepatch.markdown b/docs/misc/livepatch.markdown
index 89c1050..a674037 100644
--- a/docs/misc/livepatch.markdown
+++ b/docs/misc/livepatch.markdown
@@ -1061,6 +1061,13 @@ depending on the current state of data. As such it 
should not be attempted.
 That said we should provide hook functions so that the existing data
 can be changed during payload application.
 
+To guarantee safety we disallow re-applying an payload after it has been
+reverted. This is because we cannot guarantee that the state of .bss
+and .data to be exactly as it was during loading. Hence the administrator
+MUST unload the payload and upload it again to apply it.
+
+There is an exception to this: if the payload only has .livepatch.funcs;
+and the .data or .bss sections are of zero length.
 
 ### Inline patching
 
diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
index 23e4d51..912729e 100644
--- a/xen/common/livepatch.c
+++ b/xen/common/livepatch.c
@@ -52,6 +52,8 @@ struct livepatch_build_id {
 struct payload {
 uint32_t state;  /* One of the LIVEPATCH_STATE_*. */
 int32_t rc;  /* 0 or -XEN_EXX. */
+bool reverted;   /* Whether it was reverted. */
+bool safe_to_reapply;/* Can apply safely after revert. */
 struct list_head list;   /* Linked to 'payload_list'. */
 const void *text_addr;   /* Virtual address of .text. */
 size_t text_size;/* .. and its size. */
@@ -308,7 +310,7 @@ static void calc_section(const struct livepatch_elf_sec 
*sec, size_t *size,
 static int move_payload(struct payload *payload, struct livepatch_elf *elf)
 {
 void *text_buf, *ro_buf, *rw_buf;
-unsigned int i;
+unsigned int i, rw_buf_sec, rw_buf_cnt = 0;
 size_t size = 0;
  

Re: [Xen-devel] [PATCH v3 3/3] xen/pciback: support driver_override

[Boris Ostrovsky]

On 09/22/2016 04:45 AM, Juergen Gross wrote:
> Support the driver_override scheme introduced with commit 782a985d7af2
> ("PCI: Introduce new device binding path using pci_dev.driver_override")
>
> As pcistub_probe() is called for all devices (it has to check for a
> match based on the slot address rather than device type) it has to
> check for driver_override set to "pciback" itself.
>
> Up to now for assigning a pci device to pciback you need something like:
>
> echo :07:10.0 > /sys/bus/pci/devices/\:07\:10.0/driver/unbind
> echo :07:10.0 > /sys/bus/pci/drivers/pciback/new_slot
> echo :07:10.0 > /sys/bus/pci/drivers_probe
>
> while with the patch you can use the same mechanism as for similar
> drivers like pci-stub and vfio-pci:
>
> echo pciback > /sys/bus/pci/devices/\:07\:10.0/driver_override
> echo :07:10.0 > /sys/bus/pci/devices/\:07\:10.0/driver/unbind
> echo :07:10.0 > /sys/bus/pci/drivers_probe
>
> So e.g. libvirt doesn't need special handling for pciback.
>
> Signed-off-by: Juergen Gross 
> ---
> V3: Move override check up in order not to miss the PCI_HEADER_TYPE
> check.
> Add an assigned device to the slot list.
>
> V2: Removed now unused label
> ---
>  drivers/xen/xen-pciback/pci_stub.c | 36 +---
>  1 file changed, 29 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/xen/xen-pciback/pci_stub.c 
> b/drivers/xen/xen-pciback/pci_stub.c
> index 0179333..6331a95 100644
> --- a/drivers/xen/xen-pciback/pci_stub.c
> +++ b/drivers/xen/xen-pciback/pci_stub.c
> @@ -25,6 +25,8 @@
>  #include "conf_space.h"
>  #include "conf_space_quirks.h"
>  
> +#define PCISTUB_DRIVER_NAME "pciback"
> +
>  static char *pci_devs_to_hide;
>  wait_queue_head_t xen_pcibk_aer_wait_queue;
>  /*Add sem for sync AER handling and xen_pcibk remove/reconfigue ops,
> @@ -508,15 +510,18 @@ static void pcistub_device_id_add_list(struct 
> pcistub_device_id *new,
>   kfree(new);
>  }
>  
> -static int pcistub_seize(struct pci_dev *dev)
> +static int pcistub_seize(struct pci_dev *dev,
> +  struct pcistub_device_id *pci_dev_id)
>  {
>   struct pcistub_device *psdev;
>   unsigned long flags;
>   int err = 0;
>  
>   psdev = pcistub_device_alloc(dev);
> - if (!psdev)
> + if (!psdev) {
> + kfree(pci_dev_id);

Here too --- I'd rather have it freed by whoever allocated it (i.e. the
caller). In fact I think you can allocate this here and instead of
passing pci_dev_id pointer pass a flag of some sort.


-boris

>   return -ENOMEM;
> + }
>  
>   spin_lock_irqsave(_devices_lock, flags);
>  
> @@ -537,8 +542,12 @@ static int pcistub_seize(struct pci_dev *dev)
>  
>   spin_unlock_irqrestore(_devices_lock, flags);
>  
> - if (err)
> + if (err) {
> + kfree(pci_dev_id);
>   pcistub_device_put(psdev);
> + } else if (pci_dev_id)
> + pcistub_device_id_add_list(pci_dev_id, pci_domain_nr(dev->bus),
> +dev->bus->number, dev->devfn);
>  
>   return err;
>  }
> @@ -547,11 +556,16 @@ static int pcistub_seize(struct pci_dev *dev)
>   * other functions that take the sysfs lock. */
>  static int pcistub_probe(struct pci_dev *dev, const struct pci_device_id *id)
>  {
> - int err = 0;
> + int err = 0, match;
> + struct pcistub_device_id *pci_dev_id = NULL;
>  
>   dev_dbg(>dev, "probing...\n");
>  
> - if (pcistub_match(dev)) {
> + match = pcistub_match(dev);
> +
> + if ((dev->driver_override &&
> +  !strcmp(dev->driver_override, PCISTUB_DRIVER_NAME)) ||
> + match) {
>  
>   if (dev->hdr_type != PCI_HEADER_TYPE_NORMAL
>   && dev->hdr_type != PCI_HEADER_TYPE_BRIDGE) {
> @@ -562,8 +576,16 @@ static int pcistub_probe(struct pci_dev *dev, const 
> struct pci_device_id *id)
>   goto out;
>   }
>  
> + if (!match) {
> + pci_dev_id = kmalloc(sizeof(*pci_dev_id), GFP_ATOMIC);
> + if (!pci_dev_id) {
> + err = -ENOMEM;
> + goto out;
> + }
> + }
> +
>   dev_info(>dev, "seizing device\n");
> - err = pcistub_seize(dev);
> + err = pcistub_seize(dev, pci_dev_id);
>   } else
>   /* Didn't find the device */
>   err = -ENODEV;
> @@ -975,7 +997,7 @@ static const struct pci_error_handlers 
> xen_pcibk_error_handler = {
>  static struct pci_driver xen_pcibk_pci_driver = {
>   /* The name should be xen_pciback, but until the tools are updated
>* we will keep it as pciback. */
> - .name = "pciback",
> + .name = PCISTUB_DRIVER_NAME,
>   .id_table = pcistub_ids,
>   .probe = pcistub_probe,
>   .remove = pcistub_remove,



___
Xen-devel 

Re: [Xen-devel] [PATCH v3 2/3] xen/pciback: avoid multiple entries in slot list

[Boris Ostrovsky]

On 09/22/2016 04:45 AM, Juergen Gross wrote:
> The Xen pciback driver has a list of all pci devices it is ready to
> seize. There is no check whether a to be added entry already exists.
> While this might be no problem in the common case it might confuse
> those which consume the list via sysfs.
>
> Modify the handling of this list by not adding an entry which already
> exists. As this will be needed later split out the list handling into
> a separate function.
>
> Signed-off-by: Juergen Gross 
> ---
>  drivers/xen/xen-pciback/pci_stub.c | 39 
> ++
>  1 file changed, 31 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/xen/xen-pciback/pci_stub.c 
> b/drivers/xen/xen-pciback/pci_stub.c
> index 79a9e4d..0179333 100644
> --- a/drivers/xen/xen-pciback/pci_stub.c
> +++ b/drivers/xen/xen-pciback/pci_stub.c
> @@ -478,6 +478,36 @@ static int __init pcistub_init_devices_late(void)
>   return 0;
>  }
>  
> +static void pcistub_device_id_add_list(struct pcistub_device_id *new,
> +int domain, int bus, unsigned int devfn)
> +{
> + struct pcistub_device_id *pci_dev_id;
> + unsigned long flags;
> + int found = 0;
> +
> + spin_lock_irqsave(_ids_lock, flags);
> +
> + list_for_each_entry(pci_dev_id, _device_ids, slot_list) {
> + if (pci_dev_id->domain == domain && pci_dev_id->bus == bus &&
> + pci_dev_id->devfn == devfn) {
> + found = 1;
> + break;
> + }
> + }
> +
> + if (!found) {
> + new->domain = domain;
> + new->bus = bus;
> + new->devfn = devfn;
> + list_add_tail(>slot_list, _device_ids);
> + }
> +
> + spin_unlock_irqrestore(_ids_lock, flags);
> +
> + if (found)
> + kfree(new);

I'd rather free 'new' in the caller (who allocated it) and return
something like -EEXIST if device is already on the list.

-boris

> +}
> +
>  static int pcistub_seize(struct pci_dev *dev)
>  {
>   struct pcistub_device *psdev;
> @@ -1012,7 +1042,6 @@ static inline int str_to_quirk(const char *buf, int 
> *domain, int *bus, int
>  static int pcistub_device_id_add(int domain, int bus, int slot, int func)
>  {
>   struct pcistub_device_id *pci_dev_id;
> - unsigned long flags;
>   int rc = 0, devfn = PCI_DEVFN(slot, func);
>  
>   if (slot < 0) {
> @@ -1042,16 +1071,10 @@ static int pcistub_device_id_add(int domain, int bus, 
> int slot, int func)
>   if (!pci_dev_id)
>   return -ENOMEM;
>  
> - pci_dev_id->domain = domain;
> - pci_dev_id->bus = bus;
> - pci_dev_id->devfn = devfn;
> -
>   pr_debug("wants to seize %04x:%02x:%02x.%d\n",
>domain, bus, slot, func);
>  
> - spin_lock_irqsave(_ids_lock, flags);
> - list_add_tail(_dev_id->slot_list, _device_ids);
> - spin_unlock_irqrestore(_ids_lock, flags);
> + pcistub_device_id_add_list(pci_dev_id, domain, bus, devfn);
>  
>   return 0;
>  }


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

Re: [Xen-devel] [PATCH v3 1/3] xen/pciback: simplify pcistub device handling

[Boris Ostrovsky]

On 09/22/2016 04:45 AM, Juergen Gross wrote:
> The Xen pciback driver maintains a list of all its seized devices.
> There are two functions searching the list for a specific device with
> basically the same semantics just returning different structures in
> case of a match.
>
> Split out the search function.
>
> Signed-off-by: Juergen Gross 

Reviewed-by: Boris Ostrovsky 



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

[Xen-devel] [qemu-mainline baseline-only test] 67746: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 67746 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67746/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds   15 guest-start/debian.repeat fail baseline untested
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail baseline 
untested
 test-amd64-amd64-amd64-pvgrub 10 guest-startfail baseline untested

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail never pass

version targeted for testing:
 qemuua008535b9fa396226ff9cf78b8ac5f3584bda58e
baseline version:
 qemuu3d47a1390bd80b7b974185827a340012d21ad1e3

Last test of basis67731  2016-09-20 06:13:55 Z2 days
Testing same since67746  2016-09-22 07:50:19 Z0 days1 attempts


People who touched revisions under test:
  Eduardo Habkost 
  Marc-André Lureau 
  Markus Armbruster 
  Michael S. Tsirkin 
  Peter Maydell 
  Richard Henderson 
  Riku Voipio 

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

[Xen-devel] [ovmf baseline-only test] 67747: all pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 67747 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67747/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 7f1bf51bdbcaf9dd46f77cf4bd5e69a294dd995e
baseline version:
 ovmf 5919a9600e07b4700b54a5b47ae3991aad0e883c

Last test of basis67744  2016-09-22 06:47:21 Z0 days
Testing same since67747  2016-09-22 16:49:38 Z0 days1 attempts


People who touched revisions under test:
  Dandan Bi 
  Laszlo Ersek 

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



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

Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs

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


Push not applicable.


commit 7f1bf51bdbcaf9dd46f77cf4bd5e69a294dd995e
Author: Dandan Bi 
Date:   Thu Sep 22 09:21:38 2016 +0800

OvmfPkg/VirtioGpuDxe: Fix VS toolchain build failure

V2: add the assert codes.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
Reviewed-by: Laszlo Ersek 
[ler...@redhat.com: fix up subject line]
Signed-off-by: Laszlo Ersek 

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

Re: [Xen-devel] [PATCH v5 11/16] livepatch: tests: Make them compile under ARM64

[Konrad Rzeszutek Wilk]

On Thu, Sep 22, 2016 at 02:10:26PM +0100, Julien Grall wrote:
> Hi Konrad,
> 
> On 21/09/16 18:32, Konrad Rzeszutek Wilk wrote:
> > We need to two things:
> > 1) Wrap the platform-specific objcopy parameters in defines
> >The input and output parameters for $(OBJCOPY) are different
> >based on the platforms. As such provide them in the
> >OBJCOPY_MAGIC define and use that.
> > 
> > 2) The alternative is a bit different (exists only under ARM64
> >and x86), while and there are no exceptions under ARM at all.
> >We use the LIVEPATCH_FEATURE CPU id feature for ARM similar to
> >how it is done on x86.
> > 
> > We are not yet attempting to build them under ARM32 so
> > that is still ifdefed out.
> > 
> > Signed-off-by: Konrad Rzeszutek Wilk 
> > 
> > ---
> > Cc: Andrew Cooper 
> > Cc: George Dunlap 
> > Cc: Ian Jackson 
> > Cc: Jan Beulich 
> > Cc: Konrad Rzeszutek Wilk 
> > Cc: Stefano Stabellini 
> > Cc: Tim Deegan 
> > Cc: Wei Liu 
> > 
> > v1: First submission
> > v2: Corrected description by Julien
> > Add #ifeq instead of #else for ARM case.
> > v3: Moved 'asm(alter..)' by one space to the left.
> > v4: Rebase on top of "livepatch/tests: Make .livepatch.depends be read-only"
> > Rewrote the commit description 2) a bit.
> > ---
> >  xen/test/Makefile |  2 +-
> >  xen/test/livepatch/Makefile   | 12 ++--
> >  xen/test/livepatch/xen_hello_world_func.c |  7 +++
> >  3 files changed, 18 insertions(+), 3 deletions(-)
> > 
> > diff --git a/xen/test/Makefile b/xen/test/Makefile
> > index 8c53040..95c1755 100644
> > --- a/xen/test/Makefile
> > +++ b/xen/test/Makefile
> > @@ -1,6 +1,6 @@
> >  .PHONY: tests
> >  tests:
> I am wondering if there is any way to use the
> > -ifeq ($(XEN_TARGET_ARCH),x86_64)
> > +ifneq $(XEN_TARGET_ARCH),arm32)

Sure.
> 
> NIT: I am wondering if you could instead use CONFIG_LIVEPATCH here, so the
> tests would only be built when livepatch is enabled.

The tests are not built by default. But perhaps that can be done
in a future patch? (and have the check in test/livepatch instead).
> 
> > $(MAKE) -f $(BASEDIR)/Rules.mk -C livepatch livepatch
> >  endif
> > 
> > diff --git a/xen/test/livepatch/Makefile b/xen/test/livepatch/Makefile
> > index 48ff843..5db4d9c 100644
> > --- a/xen/test/livepatch/Makefile
> > +++ b/xen/test/livepatch/Makefile
> > @@ -1,5 +1,12 @@
> >  include $(XEN_ROOT)/Config.mk
> > 
> > +ifeq ($(XEN_TARGET_ARCH),x86_64)
> > +OBJCOPY_MAGIC := -I binary -O elf64-x86-64 -B i386:x86-64
> > +endif
> > +ifeq ($(XEN_TARGET_ARCH),arm64)
> > +OBJCOPY_MAGIC := -I binary -O elf64-littleaarch64 -B aarch64
> > +endif
> > +
> >  CODE_ADDR=$(shell nm --defined $(1) | grep $(2) | awk '{print "0x"$$1}')
> >  CODE_SZ=$(shell nm --defined -S $(1) | grep $(2) | awk '{ print "0x"$$2}')
> > 
> > @@ -54,8 +61,9 @@ $(LIVEPATCH): xen_hello_world_func.o xen_hello_world.o 
> > note.o
> >  .PHONY: note.o
> >  note.o:
> > $(OBJCOPY) -O binary --only-section=.note.gnu.build-id 
> > $(BASEDIR)/xen-syms $@.bin
> > -   $(OBJCOPY) -I binary -O elf64-x86-64 -B i386:x86-64 \
> > +   $(OBJCOPY) $(OBJCOPY_MAGIC) \
> >
> > --rename-section=.data=.livepatch.depends,alloc,load,readonly,data,contents 
> > -S $@.bin $@
> > +  --rename-section=.data=.livepatch.depends -S $@.bin $@
> 
> I am not sure why you added this line. Did you intend to replace the
> previous one?

Oh crud! No - thank you for spotting that!
> 
> > rm -f $@.bin
> > 
> >  #
> > @@ -65,7 +73,7 @@ note.o:
> >  .PHONY: hello_world_note.o
> >  hello_world_note.o: $(LIVEPATCH)
> > $(OBJCOPY) -O binary --only-section=.note.gnu.build-id $(LIVEPATCH) 
> > $@.bin
> > -   $(OBJCOPY)  -I binary -O elf64-x86-64 -B i386:x86-64 \
> > +   $(OBJCOPY) $(OBJCOPY_MAGIC) \
> >
> > --rename-section=.data=.livepatch.depends,alloc,load,readonly,data,contents 
> > -S $@.bin $@
> > rm -f $@.bin
> > 
> > diff --git a/xen/test/livepatch/xen_hello_world_func.c 
> > b/xen/test/livepatch/xen_hello_world_func.c
> > index 0321f3e..c5c0da1 100644
> > --- a/xen/test/livepatch/xen_hello_world_func.c
> > +++ b/xen/test/livepatch/xen_hello_world_func.c
> > @@ -7,14 +7,17 @@
> > 
> >  #include 
> >  #include 
> > +#ifdef CONFIG_X86
> >  #include 
> >  #include 
> > 
> >  static unsigned long *non_canonical_addr = (unsigned long 
> > *)0xdeadULL;
> > +#endif
> > 
> >  /* Our replacement function for xen_extra_version. */
> >  const char *xen_hello_world(void)
> >  {
> > +#ifdef CONFIG_X86
> >  unsigned long tmp;
> >  int rc;
> > 
> > @@ -25,6 +28,10 @@ const char *xen_hello_world(void)
> >   */
> >  rc = __get_user(tmp, non_canonical_addr);
> >  BUG_ON(rc != -EFAULT);
> > +#endif
> > +#ifdef CONFIG_ARM_64
> 

Re: [Xen-devel] [PATCH v5 20/21] libxl/acpi: Build ACPI tables for HVMlite guests

[Wei Liu]

On Thu, Sep 22, 2016 at 03:13:45PM -0400, Boris Ostrovsky wrote:
> Signed-off-by: Boris Ostrovsky 
> Acked-by: Jan Beulich 

Acked-by: Wei Liu 

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

[Xen-devel] [PATCH v5 10/21] acpi/hvmloader: Translate all addresses when assigning addresses in ACPI tables

[Boris Ostrovsky]

Non-hvmloader users may be building tables in virtual address space
and therefore we need to make sure that values that end up in tables
are physical addresses.

Signed-off-by: Boris Ostrovsky 
Reviewed-by: Jan Beulich 
---
 tools/firmware/hvmloader/acpi/build.c | 47 ++-
 1 file changed, 24 insertions(+), 23 deletions(-)

diff --git a/tools/firmware/hvmloader/acpi/build.c 
b/tools/firmware/hvmloader/acpi/build.c
index 1dd9987..b295ef0 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -145,7 +145,7 @@ static struct acpi_20_madt *construct_madt(struct acpi_ctxt 
*ctxt,
 lapic = (struct acpi_20_madt_lapic *)(madt + 1);
 
 info->nr_cpus = hvminfo->nr_vcpus;
-info->madt_lapic0_addr = (uint32_t)lapic;
+info->madt_lapic0_addr = ctxt->mem_ops.v2p(ctxt, lapic);
 for ( i = 0; i < hvminfo->nr_vcpus; i++ )
 {
 memset(lapic, 0, sizeof(*lapic));
@@ -162,7 +162,8 @@ static struct acpi_20_madt *construct_madt(struct acpi_ctxt 
*ctxt,
 madt->header.length = (unsigned char *)lapic - (unsigned char *)madt;
 set_checksum(madt, offsetof(struct acpi_header, checksum),
  madt->header.length);
-info->madt_csum_addr = (uint32_t)>header.checksum;
+info->madt_csum_addr =
+ctxt->mem_ops.v2p(ctxt, >header.checksum);
 
 return madt;
 }
@@ -328,7 +329,7 @@ static int construct_passthrough_tables(struct acpi_ctxt 
*ctxt,
 break;
 memcpy(buffer, header, header->length);
 
-table_ptrs[nr_tables++] = (unsigned long)buffer;
+table_ptrs[nr_tables++] = ctxt->mem_ops.v2p(ctxt, buffer);
 total += header->length;
 pt_addr += header->length;
 }
@@ -355,7 +356,7 @@ static int construct_secondary_tables(struct acpi_ctxt 
*ctxt,
 {
 madt = construct_madt(ctxt, config, info);
 if (!madt) return -1;
-table_ptrs[nr_tables++] = (unsigned long)madt;
+table_ptrs[nr_tables++] = ctxt->mem_ops.v2p(ctxt, madt);
 }
 
 /* HPET. */
@@ -363,7 +364,7 @@ static int construct_secondary_tables(struct acpi_ctxt 
*ctxt,
 {
 hpet = construct_hpet(ctxt, config);
 if (!hpet) return -1;
-table_ptrs[nr_tables++] = (unsigned long)hpet;
+table_ptrs[nr_tables++] = ctxt->mem_ops.v2p(ctxt, hpet);
 }
 
 /* WAET. */
@@ -372,7 +373,7 @@ static int construct_secondary_tables(struct acpi_ctxt 
*ctxt,
 waet = construct_waet(ctxt, config);
 if ( !waet )
 return -1;
-table_ptrs[nr_tables++] = (unsigned long)waet;
+table_ptrs[nr_tables++] = ctxt->mem_ops.v2p(ctxt, waet);
 }
 
 if ( config->table_flags & ACPI_HAS_SSDT_PM )
@@ -380,7 +381,7 @@ static int construct_secondary_tables(struct acpi_ctxt 
*ctxt,
 ssdt = ctxt->mem_ops.alloc(ctxt, sizeof(ssdt_pm), 16);
 if (!ssdt) return -1;
 memcpy(ssdt, ssdt_pm, sizeof(ssdt_pm));
-table_ptrs[nr_tables++] = (unsigned long)ssdt;
+table_ptrs[nr_tables++] = ctxt->mem_ops.v2p(ctxt, ssdt);
 }
 
 if ( config->table_flags & ACPI_HAS_SSDT_S3 )
@@ -388,7 +389,7 @@ static int construct_secondary_tables(struct acpi_ctxt 
*ctxt,
 ssdt = ctxt->mem_ops.alloc(ctxt, sizeof(ssdt_s3), 16);
 if (!ssdt) return -1;
 memcpy(ssdt, ssdt_s3, sizeof(ssdt_s3));
-table_ptrs[nr_tables++] = (unsigned long)ssdt;
+table_ptrs[nr_tables++] = ctxt->mem_ops.v2p(ctxt, ssdt);
 } else {
 printf("S3 disabled\n");
 }
@@ -398,7 +399,7 @@ static int construct_secondary_tables(struct acpi_ctxt 
*ctxt,
 ssdt = ctxt->mem_ops.alloc(ctxt, sizeof(ssdt_s4), 16);
 if (!ssdt) return -1;
 memcpy(ssdt, ssdt_s4, sizeof(ssdt_s4));
-table_ptrs[nr_tables++] = (unsigned long)ssdt;
+table_ptrs[nr_tables++] = ctxt->mem_ops.v2p(ctxt, ssdt);
 } else {
 printf("S4 disabled\n");
 }
@@ -412,12 +413,12 @@ static int construct_secondary_tables(struct acpi_ctxt 
*ctxt,
 ssdt = ctxt->mem_ops.alloc(ctxt, sizeof(ssdt_tpm), 16);
 if (!ssdt) return -1;
 memcpy(ssdt, ssdt_tpm, sizeof(ssdt_tpm));
-table_ptrs[nr_tables++] = (unsigned long)ssdt;
+table_ptrs[nr_tables++] = ctxt->mem_ops.v2p(ctxt, ssdt);
 
 tcpa = ctxt->mem_ops.alloc(ctxt, sizeof(struct acpi_20_tcpa), 16);
 if (!tcpa) return -1;
 memset(tcpa, 0, sizeof(*tcpa));
-table_ptrs[nr_tables++] = (unsigned long)tcpa;
+table_ptrs[nr_tables++] = ctxt->mem_ops.v2p(ctxt, tcpa);
 
 tcpa->header.signature = ACPI_2_0_TCPA_SIGNATURE;
 tcpa->header.length= sizeof(*tcpa);
@@ -445,11 +446,11 @@ static int construct_secondary_tables(struct acpi_ctxt 
*ctxt,
 struct acpi_20_slit *slit = construct_slit(ctxt, config);
 
 if ( srat )
-table_ptrs[nr_tables++] = (unsigned long)srat;
+

[Xen-devel] [PATCH v5 07/21] acpi/hvmloader: Make providing IOAPIC in MADT optional

[Boris Ostrovsky]

Signed-off-by: Boris Ostrovsky 
Reviewed-by: Jan Beulich 
---
 tools/firmware/hvmloader/acpi/build.c   | 70 ++---
 tools/firmware/hvmloader/acpi/libacpi.h |  1 +
 tools/firmware/hvmloader/util.c |  2 +-
 3 files changed, 40 insertions(+), 33 deletions(-)

diff --git a/tools/firmware/hvmloader/acpi/build.c 
b/tools/firmware/hvmloader/acpi/build.c
index c984e5a..dc489bb 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -100,43 +100,49 @@ static struct acpi_20_madt *construct_madt(const struct 
acpi_config *config,
 madt->lapic_addr = LAPIC_BASE_ADDRESS;
 madt->flags  = ACPI_PCAT_COMPAT;
 
-intsrcovr = (struct acpi_20_madt_intsrcovr *)(madt + 1);
-for ( i = 0; i < 16; i++ )
-{
-memset(intsrcovr, 0, sizeof(*intsrcovr));
-intsrcovr->type   = ACPI_INTERRUPT_SOURCE_OVERRIDE;
-intsrcovr->length = sizeof(*intsrcovr);
-intsrcovr->source = i;
-
-if ( i == 0 )
-{
-/* ISA IRQ0 routed to IOAPIC GSI 2. */
-intsrcovr->gsi= 2;
-intsrcovr->flags  = 0x0;
-}
-else if ( PCI_ISA_IRQ_MASK & (1U << i) )
-{
-/* PCI: active-low level-triggered. */
-intsrcovr->gsi= i;
-intsrcovr->flags  = 0xf;
-}
-else
+if ( config->table_flags & ACPI_HAS_IOAPIC )
+{ 
+intsrcovr = (struct acpi_20_madt_intsrcovr *)(madt + 1);
+for ( i = 0; i < 16; i++ )
 {
-/* No need for a INT source override structure. */
-continue;
+memset(intsrcovr, 0, sizeof(*intsrcovr));
+intsrcovr->type   = ACPI_INTERRUPT_SOURCE_OVERRIDE;
+intsrcovr->length = sizeof(*intsrcovr);
+intsrcovr->source = i;
+
+if ( i == 0 )
+{
+/* ISA IRQ0 routed to IOAPIC GSI 2. */
+intsrcovr->gsi= 2;
+intsrcovr->flags  = 0x0;
+}
+else if ( PCI_ISA_IRQ_MASK & (1U << i) )
+{
+/* PCI: active-low level-triggered. */
+intsrcovr->gsi= i;
+intsrcovr->flags  = 0xf;
+}
+else
+{
+/* No need for a INT source override structure. */
+continue;
+}
+
+intsrcovr++;
 }
 
-intsrcovr++;
-}
+io_apic = (struct acpi_20_madt_ioapic *)intsrcovr;
+memset(io_apic, 0, sizeof(*io_apic));
+io_apic->type= ACPI_IO_APIC;
+io_apic->length  = sizeof(*io_apic);
+io_apic->ioapic_id   = IOAPIC_ID;
+io_apic->ioapic_addr = ioapic_base_address;
 
-io_apic = (struct acpi_20_madt_ioapic *)intsrcovr;
-memset(io_apic, 0, sizeof(*io_apic));
-io_apic->type= ACPI_IO_APIC;
-io_apic->length  = sizeof(*io_apic);
-io_apic->ioapic_id   = IOAPIC_ID;
-io_apic->ioapic_addr = ioapic_base_address;
+lapic = (struct acpi_20_madt_lapic *)(io_apic + 1);
+}
+else
+lapic = (struct acpi_20_madt_lapic *)(madt + 1);
 
-lapic = (struct acpi_20_madt_lapic *)(io_apic + 1);
 info->nr_cpus = hvminfo->nr_vcpus;
 info->madt_lapic0_addr = (uint32_t)lapic;
 for ( i = 0; i < hvminfo->nr_vcpus; i++ )
diff --git a/tools/firmware/hvmloader/acpi/libacpi.h 
b/tools/firmware/hvmloader/acpi/libacpi.h
index 70cf26b..b8f28a3 100644
--- a/tools/firmware/hvmloader/acpi/libacpi.h
+++ b/tools/firmware/hvmloader/acpi/libacpi.h
@@ -28,6 +28,7 @@
 #define ACPI_HAS_SSDT_S3 (1<<5)
 #define ACPI_HAS_SSDT_S4 (1<<6)
 #define ACPI_HAS_TCPA(1<<7)
+#define ACPI_HAS_IOAPIC  (1<<8)
 
 struct xen_vmemrange;
 struct acpi_numa {
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index 8875675..aa5fc20 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -919,7 +919,7 @@ void hvmloader_acpi_build_tables(struct acpi_config *config,
 if ( !strncmp(xenstore_read("platform/acpi_s4", "1"), "1", 1)  )
 config->table_flags |= ACPI_HAS_SSDT_S4;
 
-config->table_flags |= ACPI_HAS_TCPA;
+config->table_flags |= (ACPI_HAS_TCPA | ACPI_HAS_IOAPIC);
 
 config->tis_hdr = (uint16_t *)ACPI_TIS_HDR_ADDRESS;
 
-- 
1.8.3.1


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

[Xen-devel] [PATCH v5 05/21] acpi/hvmloader: Collect processor and NUMA info in hvmloader

[Boris Ostrovsky]

No need for ACPI code to rely on hvm_info variable.

Signed-off-by: Boris Ostrovsky 
Reviewed-by: Jan Beulich 
---
Changes in v5:
* Constified pointer in test_bit()

 tools/firmware/hvmloader/acpi/build.c   | 52 ++---
 tools/firmware/hvmloader/acpi/libacpi.h | 11 +++
 tools/firmware/hvmloader/util.c |  9 ++
 tools/firmware/hvmloader/util.h |  4 +--
 4 files changed, 50 insertions(+), 26 deletions(-)

diff --git a/tools/firmware/hvmloader/acpi/build.c 
b/tools/firmware/hvmloader/acpi/build.c
index de56f1f..68eb7c4 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -24,6 +24,7 @@
 #include "../vnuma.h"
 #include 
 #include 
+#include 
 
 #define ACPI_MAX_SECONDARY_TABLES 16
 
@@ -70,18 +71,20 @@ static void set_checksum(
 p[checksum_offset] = -sum;
 }
 
-static struct acpi_20_madt *construct_madt(struct acpi_info *info)
+static struct acpi_20_madt *construct_madt(const struct acpi_config *config,
+   struct acpi_info *info)
 {
 struct acpi_20_madt   *madt;
 struct acpi_20_madt_intsrcovr *intsrcovr;
 struct acpi_20_madt_ioapic*io_apic;
 struct acpi_20_madt_lapic *lapic;
+const struct hvm_info_table   *hvminfo = config->hvminfo;
 int i, sz;
 
 sz  = sizeof(struct acpi_20_madt);
 sz += sizeof(struct acpi_20_madt_intsrcovr) * 16;
 sz += sizeof(struct acpi_20_madt_ioapic);
-sz += sizeof(struct acpi_20_madt_lapic) * hvm_info->nr_vcpus;
+sz += sizeof(struct acpi_20_madt_lapic) * hvminfo->nr_vcpus;
 
 madt = mem_alloc(sz, 16);
 if (!madt) return NULL;
@@ -134,9 +137,9 @@ static struct acpi_20_madt *construct_madt(struct acpi_info 
*info)
 io_apic->ioapic_addr = ioapic_base_address;
 
 lapic = (struct acpi_20_madt_lapic *)(io_apic + 1);
-info->nr_cpus = hvm_info->nr_vcpus;
+info->nr_cpus = hvminfo->nr_vcpus;
 info->madt_lapic0_addr = (uint32_t)lapic;
-for ( i = 0; i < hvm_info->nr_vcpus; i++ )
+for ( i = 0; i < hvminfo->nr_vcpus; i++ )
 {
 memset(lapic, 0, sizeof(*lapic));
 lapic->type= ACPI_PROCESSOR_LOCAL_APIC;
@@ -144,7 +147,7 @@ static struct acpi_20_madt *construct_madt(struct acpi_info 
*info)
 /* Processor ID must match processor-object IDs in the DSDT. */
 lapic->acpi_processor_id = i;
 lapic->apic_id = LAPIC_ID(i);
-lapic->flags = (test_bit(i, hvm_info->vcpu_online)
+lapic->flags = (test_bit(i, hvminfo->vcpu_online)
 ? ACPI_LOCAL_APIC_ENABLED : 0);
 lapic++;
 }
@@ -195,7 +198,7 @@ static struct acpi_20_waet *construct_waet(void)
 return waet;
 }
 
-static struct acpi_20_srat *construct_srat(void)
+static struct acpi_20_srat *construct_srat(const struct acpi_config *config)
 {
 struct acpi_20_srat *srat;
 struct acpi_20_srat_processor *processor;
@@ -204,8 +207,8 @@ static struct acpi_20_srat *construct_srat(void)
 void *p;
 unsigned int i;
 
-size = sizeof(*srat) + sizeof(*processor) * hvm_info->nr_vcpus +
-   sizeof(*memory) * nr_vmemranges;
+size = sizeof(*srat) + sizeof(*processor) * config->hvminfo->nr_vcpus +
+   sizeof(*memory) * config->numa.nr_vmemranges;
 
 p = mem_alloc(size, 16);
 if ( !p )
@@ -222,25 +225,26 @@ static struct acpi_20_srat *construct_srat(void)
 srat->table_revision  = ACPI_SRAT_TABLE_REVISION;
 
 processor = (struct acpi_20_srat_processor *)(srat + 1);
-for ( i = 0; i < hvm_info->nr_vcpus; i++ )
+for ( i = 0; i < config->hvminfo->nr_vcpus; i++ )
 {
 processor->type = ACPI_PROCESSOR_AFFINITY;
 processor->length   = sizeof(*processor);
-processor->domain   = vcpu_to_vnode[i];
+processor->domain   = config->numa.vcpu_to_vnode[i];
 processor->apic_id  = LAPIC_ID(i);
 processor->flags= ACPI_LOCAL_APIC_AFFIN_ENABLED;
 processor++;
 }
 
 memory = (struct acpi_20_srat_memory *)processor;
-for ( i = 0; i < nr_vmemranges; i++ )
+for ( i = 0; i < config->numa.nr_vmemranges; i++ )
 {
 memory->type  = ACPI_MEMORY_AFFINITY;
 memory->length= sizeof(*memory);
-memory->domain= vmemrange[i].nid;
+memory->domain= config->numa.vmemrange[i].nid;
 memory->flags = ACPI_MEM_AFFIN_ENABLED;
-memory->base_address  = vmemrange[i].start;
-memory->mem_length= vmemrange[i].end - vmemrange[i].start;
+memory->base_address  = config->numa.vmemrange[i].start;
+memory->mem_length= config->numa.vmemrange[i].end -
+config->numa.vmemrange[i].start;
 memory++;
 }
 
@@ -252,12 +256,12 @@ static struct acpi_20_srat *construct_srat(void)
 return srat;
 }
 
-static struct acpi_20_slit *construct_slit(void)
+static struct 

[Xen-devel] [PATCH v5 09/21] acpi/hvmloader: Replace mem_alloc() and virt_to_phys() with memory ops

[Boris Ostrovsky]

Components that wish to use ACPI builder will need to provide their own
mem_alloc() and virt_to_phys() routines. Pointers to these routines will
be passed to the builder as memory ops.

Signed-off-by: Boris Ostrovsky 
Acked-by: Jan Beulich 
---
 tools/firmware/hvmloader/acpi/build.c   | 95 ++---
 tools/firmware/hvmloader/acpi/libacpi.h | 10 +++-
 tools/firmware/hvmloader/util.c | 24 -
 3 files changed, 84 insertions(+), 45 deletions(-)

diff --git a/tools/firmware/hvmloader/acpi/build.c 
b/tools/firmware/hvmloader/acpi/build.c
index 537933b..1dd9987 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -71,7 +71,8 @@ static void set_checksum(
 p[checksum_offset] = -sum;
 }
 
-static struct acpi_20_madt *construct_madt(const struct acpi_config *config,
+static struct acpi_20_madt *construct_madt(struct acpi_ctxt *ctxt,
+   const struct acpi_config *config,
struct acpi_info *info)
 {
 struct acpi_20_madt   *madt;
@@ -86,7 +87,7 @@ static struct acpi_20_madt *construct_madt(const struct 
acpi_config *config,
 sz += sizeof(struct acpi_20_madt_ioapic);
 sz += sizeof(struct acpi_20_madt_lapic) * hvminfo->nr_vcpus;
 
-madt = mem_alloc(sz, 16);
+madt = ctxt->mem_ops.alloc(ctxt, sz, 16);
 if (!madt) return NULL;
 
 memset(madt, 0, sizeof(*madt));
@@ -166,11 +167,12 @@ static struct acpi_20_madt *construct_madt(const struct 
acpi_config *config,
 return madt;
 }
 
-static struct acpi_20_hpet *construct_hpet(void)
+static struct acpi_20_hpet *construct_hpet(struct acpi_ctxt *ctxt,
+   const struct acpi_config *config)
 {
 struct acpi_20_hpet *hpet;
 
-hpet = mem_alloc(sizeof(*hpet), 16);
+hpet = ctxt->mem_ops.alloc(ctxt, sizeof(*hpet), 16);
 if (!hpet) return NULL;
 
 memset(hpet, 0, sizeof(*hpet));
@@ -189,11 +191,12 @@ static struct acpi_20_hpet *construct_hpet(void)
 return hpet;
 }
 
-static struct acpi_20_waet *construct_waet(void)
+static struct acpi_20_waet *construct_waet(struct acpi_ctxt *ctxt,
+   const struct acpi_config *config)
 {
 struct acpi_20_waet *waet;
 
-waet = mem_alloc(sizeof(*waet), 16);
+waet = ctxt->mem_ops.alloc(ctxt, sizeof(*waet), 16);
 if (!waet) return NULL;
 
 memcpy(waet, , sizeof(*waet));
@@ -204,7 +207,8 @@ static struct acpi_20_waet *construct_waet(void)
 return waet;
 }
 
-static struct acpi_20_srat *construct_srat(const struct acpi_config *config)
+static struct acpi_20_srat *construct_srat(struct acpi_ctxt *ctxt,
+   const struct acpi_config *config)
 {
 struct acpi_20_srat *srat;
 struct acpi_20_srat_processor *processor;
@@ -216,7 +220,7 @@ static struct acpi_20_srat *construct_srat(const struct 
acpi_config *config)
 size = sizeof(*srat) + sizeof(*processor) * config->hvminfo->nr_vcpus +
sizeof(*memory) * config->numa.nr_vmemranges;
 
-p = mem_alloc(size, 16);
+p = ctxt->mem_ops.alloc(ctxt, size, 16);
 if ( !p )
 return NULL;
 
@@ -262,7 +266,8 @@ static struct acpi_20_srat *construct_srat(const struct 
acpi_config *config)
 return srat;
 }
 
-static struct acpi_20_slit *construct_slit(const struct acpi_config *config)
+static struct acpi_20_slit *construct_slit(struct acpi_ctxt *ctxt,
+   const struct acpi_config *config)
 {
 struct acpi_20_slit *slit;
 unsigned int i, num, size;
@@ -270,7 +275,7 @@ static struct acpi_20_slit *construct_slit(const struct 
acpi_config *config)
 num = config->numa.nr_vnodes * config->numa.nr_vnodes;
 size = sizeof(*slit) + num * sizeof(uint8_t);
 
-slit = mem_alloc(size, 16);
+slit = ctxt->mem_ops.alloc(ctxt, size, 16);
 if ( !slit )
 return NULL;
 
@@ -294,7 +299,8 @@ static struct acpi_20_slit *construct_slit(const struct 
acpi_config *config)
 return slit;
 }
 
-static int construct_passthrough_tables(unsigned long *table_ptrs,
+static int construct_passthrough_tables(struct acpi_ctxt *ctxt,
+unsigned long *table_ptrs,
 int nr_tables,
 struct acpi_config *config)
 {
@@ -317,7 +323,7 @@ static int construct_passthrough_tables(unsigned long 
*table_ptrs,
 
 header = (struct acpi_header*)pt_addr;
 
-buffer = mem_alloc(header->length, 16);
+buffer = ctxt->mem_ops.alloc(ctxt, header->length, 16);
 if ( buffer == NULL )
 break;
 memcpy(buffer, header, header->length);
@@ -330,7 +336,8 @@ static int construct_passthrough_tables(unsigned long 
*table_ptrs,
 return nr_added;
 }
 
-static int construct_secondary_tables(unsigned 

[Xen-devel] [PATCH v5 21/21] libxc/xc_dom_core: Copy ACPI tables to guest space

[Boris Ostrovsky]

Load ACPI modules into guest space

Signed-off-by: Boris Ostrovsky 
Acked-by: Wei Liu 
---
Changes ni v5:
* Style adjustments

 tools/libxc/xc_dom_core.c | 95 +++
 1 file changed, 95 insertions(+)

diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
index ebada89..87b450c 100644
--- a/tools/libxc/xc_dom_core.c
+++ b/tools/libxc/xc_dom_core.c
@@ -1040,6 +1040,97 @@ static int xc_dom_build_ramdisk(struct xc_dom_image *dom)
 return -1;
 }
 
+static int populate_acpi_pages(struct xc_dom_image *dom,
+   xen_pfn_t *extents,
+   unsigned int num_pages)
+{
+int rc;
+xc_interface *xch = dom->xch;
+uint32_t domid = dom->guest_domid;
+unsigned long idx;
+unsigned int first_high_idx = (4 << 30) >> PAGE_SHIFT; /* 4GB */
+
+for ( ; num_pages; num_pages--, extents++ )
+{
+
+if ( xc_domain_populate_physmap(xch, domid, 1, 0, 0, extents) == 1 )
+continue;
+
+if ( dom->highmem_end )
+{
+idx = --dom->highmem_end;
+if ( idx == first_high_idx )
+dom->highmem_end = 0;
+}
+else
+{
+idx = --dom->lowmem_end;
+}
+
+rc = xc_domain_add_to_physmap(xch, domid,
+  XENMAPSPACE_gmfn,
+  idx, *extents);
+if ( rc )
+return rc;
+}
+
+return 0;
+}
+
+static int xc_dom_load_acpi(struct xc_dom_image *dom)
+{
+int j, i = 0;
+unsigned num_pages;
+xen_pfn_t *extents, base;
+void *ptr;
+
+while ( (i < MAX_ACPI_MODULES) && dom->acpi_modules[i].length )
+{
+DOMPRINTF("%s: %d bytes at address %" PRIx64 "\n", __FUNCTION__,
+  dom->acpi_modules[i].length,
+  dom->acpi_modules[i].guest_addr_out);
+
+num_pages = (dom->acpi_modules[i].length + (XC_PAGE_SIZE - 1)) >>
+   XC_PAGE_SHIFT;
+extents = malloc(num_pages * sizeof(*extents));
+if ( !extents )
+{
+DOMPRINTF("%s: Out of memory", __FUNCTION__);
+goto err;
+}
+
+base = dom->acpi_modules[i].guest_addr_out >> XC_PAGE_SHIFT;
+for ( j = 0; j < num_pages; j++ )
+extents[j] = base + j;
+if ( populate_acpi_pages(dom, extents, num_pages) )
+{
+DOMPRINTF("%s: Can populate ACPI pages", __FUNCTION__);
+goto err;
+}
+
+ptr = xc_map_foreign_range(dom->xch, dom->guest_domid,
+   XC_PAGE_SIZE * num_pages,
+   PROT_READ | PROT_WRITE, base);
+if ( !ptr )
+{
+DOMPRINTF("%s: Can't map %d pages at 0x%lx",
+  __FUNCTION__, num_pages, base);
+goto err;
+}
+
+memcpy(ptr, dom->acpi_modules[i].data, dom->acpi_modules[i].length);
+
+free(extents);
+i++;
+}
+
+return 0;
+
+err:
+free(extents);
+return -1;
+}
+
 int xc_dom_build_image(struct xc_dom_image *dom)
 {
 unsigned int page_size;
@@ -1097,6 +1188,10 @@ int xc_dom_build_image(struct xc_dom_image *dom)
 memcpy(devicetreemap, dom->devicetree_blob, dom->devicetree_size);
 }
 
+/* load ACPI tables */
+if ( xc_dom_load_acpi(dom) != 0 )
+goto err;
+
 /* allocate other pages */
 if ( !dom->arch_hooks->p2m_base_supported ||
  dom->parms.p2m_base >= dom->parms.virt_base ||
-- 
1.8.3.1


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

[Xen-devel] [PATCH v5 04/21] acpi: Re-license ACPI builder files from GPLv2 to LGPLv2.1

[Boris Ostrovsky]

ACPI builder is currently distributed under GPLv2 license.

We plan to make the builder available to components other than the
hvmloader (which is also GPLv2). Some of these components (such as
libxl) may be distributed under LGPL-2.1 so that they can be used by
non-GPLv2 callers.  But this will not be possible if we incorporate
the ACPI builder in those other components.

To avoid this problem we are relicensing sources in ACPI bulder
directory to the Lesser GNU Public License (LGPL) version 2.1

gpl/mk_dsdt_asl.sh file will remain GPL-only pending permission to
relicense from Lenovo due to commit 801d469ad ("[HVM] ACPI support
patch 3 of 4: ACPI _PRT table."))

Signed-off-by: Boris Ostrovsky 
Acked-by: Daniel Kiper 
Acked-by: Stefan Berger 
Acked-by: Kouya Shimura 
Acked-by: Jan Beulich 
Acked-by: Kevin Tian 
Acked-by: Keir Fraser 
Acked-by: Simon Horman 
Acked-by: Lars Kurth 
Acked-by: Konrad Rzeszutek Wilk  [for Oracle, 
VirtualIron and Sun contributions]
---
CC: Daniel Kiper 
CC: Stefan Berger 
CC: Kouya Shimura 
CC: Jan Beulich 
CC: Kevin Tian 
CC: Keir Fraser 
CC: Simon Horman 
CC: Lars Kurth 
CC: Konrad Rzeszutek Wilk 
---
Changes in v5:
* dsdt.asl is also relicensed

 tools/firmware/hvmloader/acpi/COPYING | 480 ++
 tools/firmware/hvmloader/acpi/Makefile|  18 +-
 tools/firmware/hvmloader/acpi/acpi2_0.h   |  19 +-
 tools/firmware/hvmloader/acpi/build.c |  18 +-
 tools/firmware/hvmloader/acpi/dsdt.asl|  18 +-
 tools/firmware/hvmloader/acpi/gpl/COPYING |  22 ++
 tools/firmware/hvmloader/acpi/mk_dsdt.c   |  12 +
 tools/firmware/hvmloader/acpi/ssdt_pm.asl |  11 +-
 tools/firmware/hvmloader/acpi/ssdt_s3.asl |  11 +-
 tools/firmware/hvmloader/acpi/ssdt_s4.asl |  11 +-
 tools/firmware/hvmloader/acpi/ssdt_tpm.asl|  18 +-
 tools/firmware/hvmloader/acpi/static_tables.c |  18 +-
 12 files changed, 574 insertions(+), 82 deletions(-)
 create mode 100644 tools/firmware/hvmloader/acpi/COPYING
 create mode 100644 tools/firmware/hvmloader/acpi/gpl/COPYING

diff --git a/tools/firmware/hvmloader/acpi/COPYING 
b/tools/firmware/hvmloader/acpi/COPYING
new file mode 100644
index 000..5f2f87e
--- /dev/null
+++ b/tools/firmware/hvmloader/acpi/COPYING
@@ -0,0 +1,480 @@
+This library is licensed under LGPL v2.1 to allow its usage in LGPL-2.1
+libraries such as libxl. Note that the only valid version of the LGPL as
+far as the files in this directory (and its subdirectories) are concerned
+is _this_ particular version of the license (i.e., *only* v2.1, not v2.2
+or v3.x, unless explicitly otherwise stated.
+
+Where clause 3 is invoked in order to relicense under the GPL then
+this shall be considered to be GPL v2 only for files which have
+specified LGPL v2.1 only.
+
+gpl sub-directory
+=
+This directory contains a gpl sub-directory which contains code
+licensed under the GPL v2, because we have not yet been able to get
+the permission to relicense the relevant code to LGPL v2.1. See
+gpl/COPYING for more information.
+
+The makefile in this component allows to build a GPL and LGPL only
+variant of this library, the latter omits all GPL source code.
+
+
+
+  GNU LESSER GENERAL PUBLIC LICENSE
+   Version 2.1, February 1999
+
+ Copyright (C) 1991, 1999 Free Software Foundation, Inc.
+ 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ Everyone is permitted to copy and distribute verbatim copies
+ of this license document, but changing it is not allowed.
+
+[This is the first released version of the Lesser GPL.  It also counts
+ as the successor of the GNU Library Public License, version 2, hence
+ the version number 2.1.]
+
+Preamble
+
+  The licenses for most software are designed to take away your
+freedom to share and change it.  By contrast, the GNU General Public
+Licenses are intended to guarantee your freedom to share and change
+free software--to make sure the software is free for all its users.
+
+  This license, the Lesser General Public License, applies to some
+specially designated software packages--typically libraries--of the
+Free Software Foundation and other authors who decide to use it.  You
+can use it too, but we suggest you first think carefully about whether
+this license or the ordinary General Public License is the better
+strategy to use in any particular case, based on the explanations below.
+
+  When we speak of free software, we are referring to freedom of use,
+not price.  Our General Public Licenses are designed to make sure that

[Xen-devel] [PATCH v5 20/21] libxl/acpi: Build ACPI tables for HVMlite guests

[Boris Ostrovsky]

Signed-off-by: Boris Ostrovsky 
Acked-by: Jan Beulich 
---
Changes in v5:
* Dropped include from Makefile
* .gitignore drops all libxl/ssdt* and libxl/ssdt* files from tracking
* Various style adjustments

 .gitignore   |  11 +-
 tools/libacpi/build.c|   6 +-
 tools/libacpi/libacpi.h  |   6 +-
 tools/libxl/Makefile |  17 ++-
 tools/libxl/libxl_arch.h |   3 +
 tools/libxl/libxl_x86.c  |  28 +++--
 tools/libxl/libxl_x86_acpi.c | 240 +++
 tools/libxl/libxl_x86_acpi.h |  35 +++
 8 files changed, 328 insertions(+), 18 deletions(-)
 create mode 100644 tools/libxl/libxl_x86_acpi.c
 create mode 100644 tools/libxl/libxl_x86_acpi.h

diff --git a/.gitignore b/.gitignore
index 8e30a5d..06bad34 100644
--- a/.gitignore
+++ b/.gitignore
@@ -172,15 +172,18 @@ tools/include/xen/*
 tools/include/xen-xsm/*
 tools/include/xen-foreign/*.(c|h|size)
 tools/include/xen-foreign/checker
-tools/libxl/libxlu_cfg_y.output
+tools/libxl/_libxl.api-for-check
+tools/libxl/*.api-ok
 tools/libxl/*.pc
 tools/libxl/*.pc.in
-tools/libxl/xl
+tools/libxl/dsdt*
+tools/libxl/libxlu_cfg_y.output
+tools/libxl/mk_dsdt
+tools/libxl/ssdt*
 tools/libxl/testenum
 tools/libxl/testenum.c
 tools/libxl/tmp.*
-tools/libxl/_libxl.api-for-check
-tools/libxl/*.api-ok
+tools/libxl/xl
 tools/misc/cpuperf/cpuperf-perfcntr
 tools/misc/cpuperf/cpuperf-xen
 tools/misc/xc_shadow
diff --git a/tools/libacpi/build.c b/tools/libacpi/build.c
index 6749c9b..47dae01 100644
--- a/tools/libacpi/build.c
+++ b/tools/libacpi/build.c
@@ -497,7 +497,7 @@ static int new_vm_gid(struct acpi_ctxt *ctxt,
 return 1;
 }
 
-void acpi_build_tables(struct acpi_ctxt *ctxt, struct acpi_config *config)
+int acpi_build_tables(struct acpi_ctxt *ctxt, struct acpi_config *config)
 {
 struct acpi_info *acpi_info;
 struct acpi_20_rsdp *rsdp;
@@ -632,11 +632,11 @@ void acpi_build_tables(struct acpi_ctxt *ctxt, struct 
acpi_config *config)
 if ( !new_vm_gid(ctxt, config, acpi_info) )
 goto oom;
 
-return;
+return 0;
 
 oom:
 printf("unable to build ACPI tables: out of memory\n");
-
+return -1;
 }
 
 /*
diff --git a/tools/libacpi/libacpi.h b/tools/libacpi/libacpi.h
index e386362..1d388f9 100644
--- a/tools/libacpi/libacpi.h
+++ b/tools/libacpi/libacpi.h
@@ -78,10 +78,10 @@ struct acpi_config {
  * This must match the OperationRegion(BIOS, SystemMemory, )
  * definition in the DSDT
  */
-unsigned int infop;
+unsigned long infop;
 
 /* RSDP address */
-unsigned int rsdp;
+unsigned long rsdp;
 
 /* x86-specific parameters */
 uint8_t (*lapic_id)(unsigned cpu);
@@ -91,7 +91,7 @@ struct acpi_config {
 uint8_t ioapic_id;
 };
 
-void acpi_build_tables(struct acpi_ctxt *ctxt, struct acpi_config *config);
+int acpi_build_tables(struct acpi_ctxt *ctxt, struct acpi_config *config);
 
 #endif /* __LIBACPI_H__ */
 
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 90427ff..3c63bf9 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -75,7 +75,20 @@ else
 LIBXL_OBJS-y += libxl_no_colo.o
 endif
 
-LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o libxl_psr.o
+ACPI_PATH  = $(XEN_ROOT)/tools/libacpi
+ACPI_FILES = dsdt_pvh.c
+ACPI_OBJS  = $(patsubst %.c,%.o,$(ACPI_FILES)) build.o static_tables.o
+$(ACPI_FILES): acpi
+$(ACPI_OBJS): CFLAGS += -I. -DLIBACPI_STDUTILS=\"$(CURDIR)/libxl_x86_acpi.h\"
+vpath build.c $(ACPI_PATH)/
+vpath static_tables.c $(ACPI_PATH)/
+LIBXL_OBJS-$(CONFIG_X86) += $(ACPI_OBJS)
+
+.PHONY: acpi
+acpi:
+   $(MAKE) -C $(ACPI_PATH) ACPI_BUILD_DIR=$(CURDIR)
+
+LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o libxl_psr.o 
libxl_x86_acpi.o
 LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o libxl_arm.o libxl_libfdt_compat.o
 
 ifeq ($(CONFIG_NetBSD),y)
@@ -167,6 +180,7 @@ $(XL_OBJS): CFLAGS += $(CFLAGS_XL)
 $(XL_OBJS): CFLAGS += -include $(XEN_ROOT)/tools/config.h # libxl_json.h needs 
it.
 
 libxl_dom.o: CFLAGS += -I$(XEN_ROOT)/tools  # include libacpi/x86.h
+libxl_x86_acpi.o: CFLAGS += -I$(XEN_ROOT)/tools
 
 SAVE_HELPER_OBJS = libxl_save_helper.o _libxl_save_msgs_helper.o
 $(SAVE_HELPER_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenevtchn)
@@ -309,6 +323,7 @@ clean:
$(RM) -f testidl.c.new testidl.c *.api-ok
$(RM) -f xenlight.pc
$(RM) -f xlutil.pc
+   $(MAKE) -C $(ACPI_PATH) ACPI_BUILD_DIR=$(CURDIR) clean
 
 distclean: clean
$(RM) -f xenlight.pc.in xlutil.pc.in
diff --git a/tools/libxl/libxl_arch.h b/tools/libxl/libxl_arch.h
index 253a037..b35f7b6 100644
--- a/tools/libxl/libxl_arch.h
+++ b/tools/libxl/libxl_arch.h
@@ -66,6 +66,9 @@ int libxl__arch_domain_construct_memmap(libxl__gc *gc,
 
 #define LAPIC_BASE_ADDRESS  0xfee0
 
+int libxl__dom_load_acpi(libxl__gc *gc,
+ const libxl_domain_build_info *b_info,
+ struct xc_dom_image *dom);
 #endif
 
 #endif
diff --git 

[Xen-devel] [PATCH v5 15/21] libacpi: Build DSDT for PVH guests

[Boris Ostrovsky]

PVH guests require DSDT with only ACPI INFO (Xen-specific) and Processor
objects. We separate ASL's ACPI INFO definition into dsdt_acpi_info.asl so
that it can be included in ASLs for both HVM and PVH2.

Signed-off-by: Boris Ostrovsky 
Acked-by: Jan Beulich 
---
 tools/libacpi/Makefile  | 7 ++-
 tools/libacpi/mk_dsdt.c | 8 
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/tools/libacpi/Makefile b/tools/libacpi/Makefile
index aecac04..470b898 100644
--- a/tools/libacpi/Makefile
+++ b/tools/libacpi/Makefile
@@ -18,7 +18,7 @@ include $(XEN_ROOT)/tools/firmware/Rules.mk
 MK_DSDT = $(ACPI_BUILD_DIR)/mk_dsdt
 
 C_SRC-$(GPL)   = dsdt_anycpu.c dsdt_15cpu.c dsdt_anycpu_qemu_xen.c
-C_SRC  = $(addprefix $(ACPI_BUILD_DIR)/, $(C_SRC-y))
+C_SRC  = $(addprefix $(ACPI_BUILD_DIR)/, dsdt_pvh.c $(C_SRC-y))
 H_SRC = $(addprefix $(ACPI_BUILD_DIR)/, ssdt_s3.h ssdt_s4.h ssdt_pm.h 
ssdt_tpm.h)
 
 # Suffix for temporary files.
@@ -60,6 +60,11 @@ $(ACPI_BUILD_DIR)/dsdt_%cpu.asl: dsdt.asl dsdt_acpi_info.asl 
gpl/mk_dsdt_gpl.sh
mv -f $@.$(TMP_SUFFIX) $@
 endif
 
+$(ACPI_BUILD_DIR)/dsdt_pvh.asl: dsdt_acpi_info.asl $(MK_DSDT)
+   printf "DefinitionBlock (\"DSDT.aml\", \"DSDT\", 5, \"Xen\", \"HVM\", 
0)\n{" > $@
+   cat dsdt_acpi_info.asl >> $@
+   $(MK_DSDT) --debug=$(debug) --maxcpu any --dm-version none >> $@
+
 $(C_SRC): $(ACPI_BUILD_DIR)/%.c: iasl $(ACPI_BUILD_DIR)/%.asl
iasl -vs -p $(ACPI_BUILD_DIR)/$*.$(TMP_SUFFIX) -tc 
$(ACPI_BUILD_DIR)/$*.asl
sed -e 's/AmlCode/$*/g' $(ACPI_BUILD_DIR)/$*.hex > $@.$(TMP_SUFFIX)
diff --git a/tools/libacpi/mk_dsdt.c b/tools/libacpi/mk_dsdt.c
index e750820..8130cbd 100644
--- a/tools/libacpi/mk_dsdt.c
+++ b/tools/libacpi/mk_dsdt.c
@@ -23,6 +23,7 @@ static unsigned int indent_level;
 static bool debug = false;
 
 typedef enum dm_version {
+QEMU_NONE,
 QEMU_XEN_TRADITIONAL,
 QEMU_XEN,
 } dm_version;
@@ -135,6 +136,8 @@ int main(int argc, char **argv)
 dm_version = QEMU_XEN;
 } else if (strcmp(optarg, "qemu-xen-traditional") == 0) {
 dm_version = QEMU_XEN_TRADITIONAL;
+} else if (strcmp(optarg, "none") == 0) {
+dm_version = QEMU_NONE;
 } else {
 fprintf(stderr, "Unknown device model version `%s'.\n", 
optarg);
 return -1;
@@ -252,6 +255,11 @@ int main(int argc, char **argv)
 
 pop_block();
 
+if (dm_version == QEMU_NONE) {
+pop_block();
+return 0;
+}
+
 /* Define GPE control method. */
 push_block("Scope", "\\_GPE");
 push_block("Method",
-- 
1.8.3.1


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

[Xen-devel] [PATCH v5 13/21] acpi: Move ACPI code to tools/libacpi

[Boris Ostrovsky]

Signed-off-by: Boris Ostrovsky 
Acked-by: Jan Beulich 
---
 MAINTAINERS|  1 +
 tools/firmware/hvmloader/Makefile  | 14 --
 tools/firmware/hvmloader/ovmf.c|  2 +-
 tools/firmware/rombios/32bit/Makefile  |  2 +-
 tools/firmware/rombios/32bit/tcgbios/Makefile  |  2 +-
 tools/{firmware/hvmloader/acpi => libacpi}/COPYING |  0
 tools/{firmware/hvmloader/acpi => libacpi}/Makefile|  2 +-
 tools/{firmware/hvmloader/acpi => libacpi}/README  |  0
 tools/{firmware/hvmloader/acpi => libacpi}/acpi2_0.h   |  0
 tools/{firmware/hvmloader/acpi => libacpi}/build.c |  0
 tools/{firmware/hvmloader/acpi => libacpi}/dsdt.asl|  0
 .../hvmloader/acpi => libacpi}/dsdt_acpi_info.asl  |  0
 tools/{firmware/hvmloader/acpi => libacpi}/gpl/COPYING |  0
 .../hvmloader/acpi => libacpi}/gpl/mk_dsdt_gpl.sh  |  0
 tools/{firmware/hvmloader/acpi => libacpi}/libacpi.h   |  0
 tools/{firmware/hvmloader/acpi => libacpi}/mk_dsdt.c   |  0
 tools/{firmware/hvmloader/acpi => libacpi}/ssdt_pm.asl |  0
 tools/{firmware/hvmloader/acpi => libacpi}/ssdt_s3.asl |  0
 tools/{firmware/hvmloader/acpi => libacpi}/ssdt_s4.asl |  0
 tools/{firmware/hvmloader/acpi => libacpi}/ssdt_tpm.asl|  0
 tools/{firmware/hvmloader/acpi => libacpi}/static_tables.c |  0
 21 files changed, 13 insertions(+), 10 deletions(-)
 rename tools/{firmware/hvmloader/acpi => libacpi}/COPYING (100%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/Makefile (98%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/README (100%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/acpi2_0.h (100%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/build.c (100%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/dsdt.asl (100%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/dsdt_acpi_info.asl (100%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/gpl/COPYING (100%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/gpl/mk_dsdt_gpl.sh (100%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/libacpi.h (100%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/mk_dsdt.c (100%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/ssdt_pm.asl (100%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/ssdt_s3.asl (100%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/ssdt_s4.asl (100%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/ssdt_tpm.asl (100%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/static_tables.c (100%)

diff --git a/MAINTAINERS b/MAINTAINERS
index 97720a8..07545f3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -138,6 +138,7 @@ S:  Supported
 F: xen/arch/x86/acpi/
 F: xen/drivers/acpi/
 F: xen/include/acpi/
+F: tools/libacpi/
 
 AMD IOMMU
 M: Suravee Suthikulpanit 
diff --git a/tools/firmware/hvmloader/Makefile 
b/tools/firmware/hvmloader/Makefile
index 7b3641c..c19986a 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -20,10 +20,7 @@
 XEN_ROOT = $(CURDIR)/../../..
 include $(XEN_ROOT)/tools/firmware/Rules.mk
 
-export ACPI_BUILD_DIR=$(CURDIR)
-SUBDIRS := acpi
 
-# The HVM loader is started in 32-bit mode at the address below:
 LOADADDR = 0x10
 
 # SMBIOS spec requires format mm/dd/
@@ -71,16 +68,20 @@ GPL = y
 export GPL
 
 .PHONY: all
-all: subdirs-all
+all: acpi subdirs-all
$(MAKE) hvmloader
 
+.PHONY: acpi
+acpi:
+   $(MAKE) -C $(ACPI_PATH)  ACPI_BUILD_DIR=$(CURDIR)
+
 rombios.o: roms.inc
 smbios.o: CFLAGS += -D__SMBIOS_DATE__="\"$(SMBIOS_REL_DATE)\""
 
-ACPI_PATH = acpi
+ACPI_PATH = ../../libacpi
 ACPI_FILES = dsdt_anycpu.c dsdt_15cpu.c dsdt_anycpu_qemu_xen.c
 ACPI_OBJS = $(patsubst %.c,%.o,$(ACPI_FILES)) build.o static_tables.o
-$(ACPI_OBJS): CFLAGS += -I. -DLIBACPI_STDUTILS=\"../util.h\"
+$(ACPI_OBJS): CFLAGS += -I. -DLIBACPI_STDUTILS=\"$(CURDIR)/util.h\"
 CFLAGS += -I$(ACPI_PATH)
 vpath build.c $(ACPI_PATH)
 vpath static_tables.c $(ACPI_PATH)
@@ -122,6 +123,7 @@ endif
 clean: subdirs-clean
rm -f roms.inc roms.inc.new acpi.h
rm -f hvmloader hvmloader.tmp *.o $(DEPS)
+   $(MAKE) -C $(ACPI_PATH)  ACPI_BUILD_DIR=$(CURDIR) clean
 
 .PHONY: distclean
 distclean: clean
diff --git a/tools/firmware/hvmloader/ovmf.c b/tools/firmware/hvmloader/ovmf.c
index 0ac3416..4ff7f1d 100644
--- a/tools/firmware/hvmloader/ovmf.c
+++ b/tools/firmware/hvmloader/ovmf.c
@@ -23,7 +23,7 @@
 
 #include "config.h"
 #include "smbios_types.h"
-#include "acpi/libacpi.h"
+#include "libacpi.h"
 #include "apic_regs.h"
 #include "../rombios/config.h"
 #include "util.h"
diff --git a/tools/firmware/rombios/32bit/Makefile 
b/tools/firmware/rombios/32bit/Makefile
index 71399d2..b0583c9 100644
--- a/tools/firmware/rombios/32bit/Makefile
+++ b/tools/firmware/rombios/32bit/Makefile
@@ -3,7 +3,7 @@ 

[Xen-devel] [PATCH v5 14/21] x86: Allow LAPIC-only emulation_flags for HVM guests

[Boris Ostrovsky]

PVHv2 guests may request LAPIC emulation (and nothing else)

Signed-off-by: Boris Ostrovsky 
Reviewed-by: Jan Beulich 
---
 xen/arch/x86/domain.c | 26 --
 1 file changed, 16 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 3c4b094..1bd5eb6 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -545,25 +545,31 @@ int arch_domain_create(struct domain *d, unsigned int 
domcr_flags,
 }
 else
 {
-if ( (config->emulation_flags & ~XEN_X86_EMU_ALL) != 0 )
+uint32_t emflags;
+
+if ( is_hardware_domain(d) )
+config->emulation_flags |= XEN_X86_EMU_PIT;
+
+emflags = config->emulation_flags;
+if ( emflags & ~XEN_X86_EMU_ALL )
 {
 printk(XENLOG_G_ERR "d%d: Invalid emulation bitmap: %#x\n",
-   d->domain_id, config->emulation_flags);
+   d->domain_id, emflags);
 return -EINVAL;
 }
-if ( is_hardware_domain(d) )
-config->emulation_flags |= XEN_X86_EMU_PIT;
-if ( config->emulation_flags != 0 &&
- (config->emulation_flags !=
-  (is_hvm_domain(d) ? XEN_X86_EMU_ALL : XEN_X86_EMU_PIT)) )
+
+/* PVHv2 guests can request emulated APIC. */
+if ( emflags &&
+(is_hvm_domain(d) ? ((emflags != XEN_X86_EMU_ALL) &&
+ (emflags != XEN_X86_EMU_LAPIC)) :
+(emflags != XEN_X86_EMU_PIT)) )
 {
 printk(XENLOG_G_ERR "d%d: Xen does not allow %s domain creation "
"with the current selection of emulators: %#x\n",
-   d->domain_id, is_hvm_domain(d) ? "HVM" : "PV",
-   config->emulation_flags);
+   d->domain_id, is_hvm_domain(d) ? "HVM" : "PV", emflags);
 return -EOPNOTSUPP;
 }
-d->arch.emulation_flags = config->emulation_flags;
+d->arch.emulation_flags = emflags;
 }
 
 if ( has_hvm_container_domain(d) )
-- 
1.8.3.1


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

[Xen-devel] [PATCH v5 08/21] acpi/hvmloader: Build WAET optionally

[Boris Ostrovsky]

Signed-off-by: Boris Ostrovsky 
Reviewed-by: Jan Beulich 
---
 tools/firmware/hvmloader/acpi/build.c   | 10 +++---
 tools/firmware/hvmloader/acpi/libacpi.h |  1 +
 tools/firmware/hvmloader/util.c |  2 +-
 3 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/tools/firmware/hvmloader/acpi/build.c 
b/tools/firmware/hvmloader/acpi/build.c
index dc489bb..537933b 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -360,9 +360,13 @@ static int construct_secondary_tables(unsigned long 
*table_ptrs,
 }
 
 /* WAET. */
-waet = construct_waet();
-if (!waet) return -1;
-table_ptrs[nr_tables++] = (unsigned long)waet;
+if ( config->table_flags & ACPI_HAS_WAET )
+{
+waet = construct_waet();
+if ( !waet )
+return -1;
+table_ptrs[nr_tables++] = (unsigned long)waet;
+}
 
 if ( config->table_flags & ACPI_HAS_SSDT_PM )
 {
diff --git a/tools/firmware/hvmloader/acpi/libacpi.h 
b/tools/firmware/hvmloader/acpi/libacpi.h
index b8f28a3..b411a6e 100644
--- a/tools/firmware/hvmloader/acpi/libacpi.h
+++ b/tools/firmware/hvmloader/acpi/libacpi.h
@@ -29,6 +29,7 @@
 #define ACPI_HAS_SSDT_S4 (1<<6)
 #define ACPI_HAS_TCPA(1<<7)
 #define ACPI_HAS_IOAPIC  (1<<8)
+#define ACPI_HAS_WAET(1<<9)
 
 struct xen_vmemrange;
 struct acpi_numa {
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index aa5fc20..b345576 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -919,7 +919,7 @@ void hvmloader_acpi_build_tables(struct acpi_config *config,
 if ( !strncmp(xenstore_read("platform/acpi_s4", "1"), "1", 1)  )
 config->table_flags |= ACPI_HAS_SSDT_S4;
 
-config->table_flags |= (ACPI_HAS_TCPA | ACPI_HAS_IOAPIC);
+config->table_flags |= (ACPI_HAS_TCPA | ACPI_HAS_IOAPIC | ACPI_HAS_WAET);
 
 config->tis_hdr = (uint16_t *)ACPI_TIS_HDR_ADDRESS;
 
-- 
1.8.3.1


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

[Xen-devel] [PATCH v5 02/21] acpi: Extract acpi info description into a separate ASL file

[Boris Ostrovsky]

This code will be needed by PVH guests who don't want to use full DSDT.

Signed-off-by: Boris Ostrovsky 
---
 .gitignore   |  2 +-
 tools/firmware/hvmloader/acpi/Makefile   |  8 +---
 tools/firmware/hvmloader/acpi/dsdt.asl   | 19 -
 tools/firmware/hvmloader/acpi/dsdt_acpi_info.asl | 26 
 4 files changed, 32 insertions(+), 23 deletions(-)
 create mode 100644 tools/firmware/hvmloader/acpi/dsdt_acpi_info.asl

diff --git a/.gitignore b/.gitignore
index cc64fc9..6dee857 100644
--- a/.gitignore
+++ b/.gitignore
@@ -129,7 +129,7 @@ tools/firmware/extboot/extboot.img
 tools/firmware/extboot/signrom
 tools/firmware/hvmloader/acpi/mk_dsdt
 tools/firmware/hvmloader/acpi/dsdt*.c
-tools/firmware/hvmloader/acpi/dsdt_*.asl
+tools/firmware/hvmloader/acpi/dsdt_*cpu*.asl
 tools/firmware/hvmloader/acpi/ssdt_*.h
 tools/firmware/hvmloader/hvmloader
 tools/firmware/hvmloader/roms.h
diff --git a/tools/firmware/hvmloader/acpi/Makefile 
b/tools/firmware/hvmloader/acpi/Makefile
index 45de14a..f63e734 100644
--- a/tools/firmware/hvmloader/acpi/Makefile
+++ b/tools/firmware/hvmloader/acpi/Makefile
@@ -36,14 +36,16 @@ ssdt_s3.h ssdt_s4.h ssdt_pm.h ssdt_tpm.h: %.h: %.asl iasl
 mk_dsdt: mk_dsdt.c
$(HOSTCC) $(HOSTCFLAGS) $(CFLAGS_xeninclude) -o $@ mk_dsdt.c
 
-dsdt_anycpu_qemu_xen.asl: dsdt.asl mk_dsdt
+dsdt_anycpu_qemu_xen.asl: dsdt.asl dsdt_acpi_info.asl mk_dsdt
awk 'NR > 1 {print s} {s=$$0}' $< > $@.$(TMP_SUFFIX)
+   cat dsdt_acpi_info.asl >> $@.$(TMP_SUFFIX)
./mk_dsdt --debug=$(debug) --dm-version qemu-xen >> $@.$(TMP_SUFFIX)
mv -f $@.$(TMP_SUFFIX) $@
 
 # NB. awk invocation is a portable alternative to 'head -n -1'
-dsdt_%cpu.asl: dsdt.asl mk_dsdt
+dsdt_%cpu.asl: dsdt.asl dsdt_acpi_info.asl mk_dsdt
awk 'NR > 1 {print s} {s=$$0}' $< > $@.$(TMP_SUFFIX)
+   cat dsdt_acpi_info.asl >> $@.$(TMP_SUFFIX)
./mk_dsdt --debug=$(debug) --maxcpu $*  >> $@.$(TMP_SUFFIX)
mv -f $@.$(TMP_SUFFIX) $@
 
@@ -69,7 +71,7 @@ acpi.a: $(OBJS)
 
 clean:
rm -rf *.a *.o $(IASL_VER) $(IASL_VER).tar.gz $(DEPS)
-   rm -rf ssdt_*.h dsdt*.c *~ *.aml *.hex mk_dsdt dsdt_*.asl 
*.$(TMP_SUFFIX)
+   rm -rf ssdt_*.h dsdt*.c *~ *.aml *.hex mk_dsdt dsdt_*cpu*.asl 
*.$(TMP_SUFFIX)
 
 distclean: clean
 
diff --git a/tools/firmware/hvmloader/acpi/dsdt.asl 
b/tools/firmware/hvmloader/acpi/dsdt.asl
index bd65823..4f6db79 100644
--- a/tools/firmware/hvmloader/acpi/dsdt.asl
+++ b/tools/firmware/hvmloader/acpi/dsdt.asl
@@ -43,25 +43,6 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2, "Xen", "HVM", 0)
 
 Scope (\_SB)
 {
-   /* ACPI_INFO_PHYSICAL_ADDRESS == 0xFC00 */
-   OperationRegion(BIOS, SystemMemory, 0xFC00, 40)
-   Field(BIOS, ByteAcc, NoLock, Preserve) {
-   UAR1, 1,
-   UAR2, 1,
-   LTP1, 1,
-   HPET, 1,
-   Offset(2),
-   NCPU, 16,
-   PMIN, 32,
-   PLEN, 32,
-   MSUA, 32, /* MADT checksum address */
-   MAPA, 32, /* MADT LAPIC0 address */
-   VGIA, 32, /* VM generation id address */
-   LMIN, 32,
-   HMIN, 32,
-   LLEN, 32,
-   HLEN, 32
-   }
 
 /* Fix HCT test for 0x400 pci memory:
  * - need to report low 640 MB mem as motherboard resource
diff --git a/tools/firmware/hvmloader/acpi/dsdt_acpi_info.asl 
b/tools/firmware/hvmloader/acpi/dsdt_acpi_info.asl
new file mode 100644
index 000..0136dce
--- /dev/null
+++ b/tools/firmware/hvmloader/acpi/dsdt_acpi_info.asl
@@ -0,0 +1,26 @@
+
+Scope (\_SB)
+{
+   /*
+* BIOS region must match struct acpi_info in build.c and
+* be located at ACPI_INFO_PHYSICAL_ADDRESS = 0xFC00
+*/
+   OperationRegion(BIOS, SystemMemory, 0xFC00, 40)
+   Field(BIOS, ByteAcc, NoLock, Preserve) {
+   UAR1, 1,
+   UAR2, 1,
+   LTP1, 1,
+   HPET, 1,
+   Offset(2),
+   NCPU, 16,
+   PMIN, 32,
+   PLEN, 32,
+   MSUA, 32, /* MADT checksum address */
+   MAPA, 32, /* MADT LAPIC0 address */
+   VGIA, 32, /* VM generation id address */
+   LMIN, 32,
+   HMIN, 32,
+   LLEN, 32,
+   HLEN, 32
+   }
+}
-- 
1.8.3.1


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

[Xen-devel] [PATCH v5 01/21] acpi: Makefile should better tolerate interrupts

[Boris Ostrovsky]

Intermediate stages of building a target should be made with
temporary files that are copied to final target in the end.

Signed-off-by: Boris Ostrovsky 
---
Changes in v5:
* Now is first patch in the series
* Renamed TMP_SUFFIX to "tmp" (from "tmp__")

 tools/firmware/hvmloader/acpi/Makefile | 20 +---
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/tools/firmware/hvmloader/acpi/Makefile 
b/tools/firmware/hvmloader/acpi/Makefile
index d3e882a..45de14a 100644
--- a/tools/firmware/hvmloader/acpi/Makefile
+++ b/tools/firmware/hvmloader/acpi/Makefile
@@ -22,6 +22,9 @@ OBJS  = $(patsubst %.c,%.o,$(C_SRC))
 
 CFLAGS += $(CFLAGS_xeninclude)
 
+# Suffix for temporary files.
+TMP_SUFFIX = tmp
+
 vpath iasl $(PATH)
 all: acpi.a
 
@@ -34,18 +37,21 @@ mk_dsdt: mk_dsdt.c
$(HOSTCC) $(HOSTCFLAGS) $(CFLAGS_xeninclude) -o $@ mk_dsdt.c
 
 dsdt_anycpu_qemu_xen.asl: dsdt.asl mk_dsdt
-   awk 'NR > 1 {print s} {s=$$0}' $< > $@
-   ./mk_dsdt --debug=$(debug) --dm-version qemu-xen >> $@
+   awk 'NR > 1 {print s} {s=$$0}' $< > $@.$(TMP_SUFFIX)
+   ./mk_dsdt --debug=$(debug) --dm-version qemu-xen >> $@.$(TMP_SUFFIX)
+   mv -f $@.$(TMP_SUFFIX) $@
 
 # NB. awk invocation is a portable alternative to 'head -n -1'
 dsdt_%cpu.asl: dsdt.asl mk_dsdt
-   awk 'NR > 1 {print s} {s=$$0}' $< > $@
-   ./mk_dsdt --debug=$(debug) --maxcpu $*  >> $@
+   awk 'NR > 1 {print s} {s=$$0}' $< > $@.$(TMP_SUFFIX)
+   ./mk_dsdt --debug=$(debug) --maxcpu $*  >> $@.$(TMP_SUFFIX)
+   mv -f $@.$(TMP_SUFFIX) $@
 
 $(filter dsdt_%.c,$(C_SRC)): %.c: iasl %.asl
iasl -vs -p $* -tc $*.asl
-   sed -e 's/AmlCode/$*/g' $*.hex >$@
-   echo "int $*_len=sizeof($*);" >>$@
+   sed -e 's/AmlCode/$*/g' $*.hex >$@.$(TMP_SUFFIX)
+   echo "int $*_len=sizeof($*);" >>$@.$(TMP_SUFFIX)
+   mv -f $@.$(TMP_SUFFIX) $@
rm -f $*.aml $*.hex
 
 iasl:
@@ -63,7 +69,7 @@ acpi.a: $(OBJS)
 
 clean:
rm -rf *.a *.o $(IASL_VER) $(IASL_VER).tar.gz $(DEPS)
-   rm -rf ssdt_*.h dsdt*.c *~ *.aml *.hex mk_dsdt dsdt_*.asl
+   rm -rf ssdt_*.h dsdt*.c *~ *.aml *.hex mk_dsdt dsdt_*.asl 
*.$(TMP_SUFFIX)
 
 distclean: clean
 
-- 
1.8.3.1


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

[Xen-devel] [PATCH v5 18/21] libxl/pvhv2: Include APIC page in MMIO hole for PVHv2 guests

[Boris Ostrovsky]

Signed-off-by: Boris Ostrovsky 
Acked-by: Wei Liu 
---
 tools/libxl/Makefile |  2 ++
 tools/libxl/libxl_arch.h |  6 ++
 tools/libxl/libxl_dom.c  | 19 +++
 3 files changed, 23 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index a3c0af8..90427ff 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -166,6 +166,8 @@ $(XL_OBJS) $(TEST_PROG_OBJS) _libxl.api-for-check: \
 $(XL_OBJS): CFLAGS += $(CFLAGS_XL)
 $(XL_OBJS): CFLAGS += -include $(XEN_ROOT)/tools/config.h # libxl_json.h needs 
it.
 
+libxl_dom.o: CFLAGS += -I$(XEN_ROOT)/tools  # include libacpi/x86.h
+
 SAVE_HELPER_OBJS = libxl_save_helper.o _libxl_save_msgs_helper.o
 $(SAVE_HELPER_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenevtchn)
 
diff --git a/tools/libxl/libxl_arch.h b/tools/libxl/libxl_arch.h
index 34a853c..253a037 100644
--- a/tools/libxl/libxl_arch.h
+++ b/tools/libxl/libxl_arch.h
@@ -62,4 +62,10 @@ int libxl__arch_domain_construct_memmap(libxl__gc *gc,
 uint32_t domid,
 struct xc_dom_image *dom);
 
+#if defined(__i386__) || defined(__x86_64__)
+
+#define LAPIC_BASE_ADDRESS  0xfee0
+
+#endif
+
 #endif
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 7974302..2924629 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -1077,10 +1077,21 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
 dom->target_pages = mem_size >> XC_PAGE_SHIFT;
 if (dom->mmio_size == 0 && device_model)
 dom->mmio_size = HVM_BELOW_4G_MMIO_LENGTH;
-else if (dom->mmio_size == 0 && !device_model)
-dom->mmio_size = GB(4) -
-((X86_HVM_END_SPECIAL_REGION - X86_HVM_NR_SPECIAL_PAGES)
-<< XC_PAGE_SHIFT);
+else if (dom->mmio_size == 0 && !device_model) {
+#if defined(__i386__) || defined(__x86_64__)
+if (libxl_defbool_val(info->u.hvm.apic)) {
+/* Make sure LAPIC_BASE_ADDRESS is below special pages */
+assert(X86_HVM_END_SPECIAL_REGION - X86_HVM_NR_SPECIAL_PAGES)
+  << XC_PAGE_SHIFT) - LAPIC_BASE_ADDRESS)) >= 
XC_PAGE_SIZE);
+dom->mmio_size = GB(4) - LAPIC_BASE_ADDRESS;
+} else
+dom->mmio_size = GB(4) -
+((X86_HVM_END_SPECIAL_REGION - X86_HVM_NR_SPECIAL_PAGES)
+ << XC_PAGE_SHIFT);
+#else
+assert(1);
+#endif
+}
 lowmem_end = mem_size;
 highmem_end = 0;
 mmio_start = (1ull << 32) - dom->mmio_size;
-- 
1.8.3.1


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

[Xen-devel] [PATCH v5 19/21] libxl: Initialize domain build info before calling libxl__domain_make

[Boris Ostrovsky]

libxl__domain_make() may want to use b_info so we should set defaults
a little earlier.

Signed-off-by: Boris Ostrovsky 
Acked-by: Wei Liu 
---
 tools/libxl/libxl_create.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 04f8ae9..07b2b4b 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -899,17 +899,6 @@ static void initiate_domain_create(libxl__egc *egc,
 goto error_out;
 }
 
-ret = libxl__domain_make(gc, d_config, , >config);
-if (ret) {
-LOG(ERROR, "cannot make domain: %d", ret);
-dcs->guest_domid = domid;
-ret = ERROR_FAIL;
-goto error_out;
-}
-
-dcs->guest_domid = domid;
-dcs->sdss.dm.guest_domid = 0; /* means we haven't spawned */
-
 ret = libxl__domain_build_info_setdefault(gc, _config->b_info);
 if (ret) {
 LOG(ERROR, "Unable to set domain build info defaults");
@@ -923,6 +912,17 @@ static void initiate_domain_create(libxl__egc *egc,
 goto error_out;
 }
 
+ret = libxl__domain_make(gc, d_config, , >config);
+if (ret) {
+LOG(ERROR, "cannot make domain: %d", ret);
+dcs->guest_domid = domid;
+ret = ERROR_FAIL;
+goto error_out;
+}
+
+dcs->guest_domid = domid;
+dcs->sdss.dm.guest_domid = 0; /* means we haven't spawned */
+
 /*
  * Set the dm version quite early so that libxl doesn't have to pass the
  * build info around just to know if the domain has a device model or not.
-- 
1.8.3.1


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

[Xen-devel] [PATCH v5 00/21] Make ACPI builder available to components other than hvmloader

[Boris Ostrovsky]

The goal here is to build ACPI tables for PVHv2/HVMlite guests while reusing 
existing
hvmloader's ACPI builder code. The builder is provided as a library in 
tools/libacpi.

This is verion 5 of the series, see individual patches for changes. It can
be fetched from git://oss.oracle.com/git/bostrovs/xen.git:acpi_v5

Major changes:
* Generate GPL-licensed portion of DSDT (patch 3)


Boris Ostrovsky (21):
  acpi: Makefile should better tolerate interrupts
  acpi: Extract acpi info description into a separate ASL file
  acpi: Prevent GPL-only code from seeping into non-GPL binaries
  acpi: Re-license ACPI builder files from GPLv2 to LGPLv2.1
  acpi/hvmloader: Collect processor and NUMA info in hvmloader
  acpi/hvmloader: Set TIS header address in hvmloader
  acpi/hvmloader: Make providing IOAPIC in MADT optional
  acpi/hvmloader: Build WAET optionally
  acpi/hvmloader: Replace mem_alloc() and virt_to_phys() with memory ops
  acpi/hvmloader: Translate all addresses when assigning addresses in
ACPI tables
  acpi/hvmloader: Link ACPI object files directly
  acpi/hvmloader: Include file/paths adjustments
  acpi: Move ACPI code to tools/libacpi
  x86: Allow LAPIC-only emulation_flags for HVM guests
  libacpi: Build DSDT for PVH guests
  libxc/libxl: Allow multiple ACPI modules
  libxl/acpi: Add ACPI e820 entry
  libxl/pvhv2: Include APIC page in MMIO hole for PVHv2 guests
  libxl: Initialize domain build info before calling libxl__domain_make
  libxl/acpi: Build ACPI tables for HVMlite guests
  libxc/xc_dom_core: Copy ACPI tables to guest space

 .gitignore |  18 +-
 MAINTAINERS|   1 +
 tools/firmware/hvmloader/Makefile  |  24 +-
 tools/firmware/hvmloader/acpi/Makefile |  72 
 tools/firmware/hvmloader/acpi/ssdt_tpm.asl |  30 --
 tools/firmware/hvmloader/config.h  |   2 +
 tools/firmware/hvmloader/hvmloader.c   |   2 +-
 tools/firmware/hvmloader/ovmf.c|   2 +-
 tools/firmware/hvmloader/rombios.c |   2 +-
 tools/firmware/hvmloader/seabios.c |   5 +-
 tools/firmware/hvmloader/util.c|  52 ++-
 tools/firmware/hvmloader/util.h|   4 +-
 tools/firmware/rombios/32bit/Makefile  |   2 +-
 tools/firmware/rombios/32bit/tcgbios/Makefile  |   2 +-
 tools/firmware/rombios/32bit/util.h|   2 +-
 tools/libacpi/COPYING  | 480 +
 tools/libacpi/Makefile |  96 +
 tools/{firmware/hvmloader/acpi => libacpi}/README  |  16 +-
 .../{firmware/hvmloader/acpi => libacpi}/acpi2_0.h |  19 +-
 tools/{firmware/hvmloader/acpi => libacpi}/build.c | 303 +++--
 .../{firmware/hvmloader/acpi => libacpi}/dsdt.asl  |  51 +--
 tools/libacpi/dsdt_acpi_info.asl   |  26 ++
 tools/libacpi/gpl/COPYING  |  22 +
 tools/libacpi/gpl/mk_dsdt_gpl.sh   | 110 +
 .../{firmware/hvmloader/acpi => libacpi}/libacpi.h |  37 +-
 .../{firmware/hvmloader/acpi => libacpi}/mk_dsdt.c |  88 +---
 .../hvmloader/acpi => libacpi}/ssdt_pm.asl |  11 +-
 .../hvmloader/acpi => libacpi}/ssdt_s3.asl |  11 +-
 .../hvmloader/acpi => libacpi}/ssdt_s4.asl |  11 +-
 tools/libacpi/ssdt_tpm.asl |  28 ++
 .../hvmloader/acpi => libacpi}/static_tables.c |  18 +-
 tools/libxc/include/xc_dom.h   |   5 +-
 tools/libxc/xc_dom_core.c  |  95 
 tools/libxc/xc_dom_hvmloader.c |   3 +-
 tools/libxl/Makefile   |  19 +-
 tools/libxl/libxl_arch.h   |   9 +
 tools/libxl/libxl_create.c |  22 +-
 tools/libxl/libxl_dom.c|  53 ++-
 tools/libxl/libxl_x86.c|  43 +-
 tools/libxl/libxl_x86_acpi.c   | 240 +++
 tools/libxl/libxl_x86_acpi.h   |  35 ++
 xen/arch/x86/domain.c  |  26 +-
 42 files changed, 1623 insertions(+), 474 deletions(-)
 delete mode 100644 tools/firmware/hvmloader/acpi/Makefile
 delete mode 100644 tools/firmware/hvmloader/acpi/ssdt_tpm.asl
 create mode 100644 tools/libacpi/COPYING
 create mode 100644 tools/libacpi/Makefile
 rename tools/{firmware/hvmloader/acpi => libacpi}/README (60%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/acpi2_0.h (95%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/build.c (63%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/dsdt.asl (91%)
 create mode 100644 tools/libacpi/dsdt_acpi_info.asl
 create mode 100644 tools/libacpi/gpl/COPYING
 create mode 100755 tools/libacpi/gpl/mk_dsdt_gpl.sh
 rename tools/{firmware/hvmloader/acpi => libacpi}/libacpi.h (64%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/mk_dsdt.c (82%)
 rename 

[Xen-devel] [PATCH v5 17/21] libxl/acpi: Add ACPI e820 entry

[Boris Ostrovsky]

Add entry for ACPI tables created for PVHv2 guests to e820 map.

Signed-off-by: Boris Ostrovsky 
Acked-by: Wei Liu 
---
 tools/libxl/libxl_dom.c |  8 
 tools/libxl/libxl_x86.c | 15 +++
 2 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index c4be916..7974302 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -1134,16 +1134,16 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
 dom->vnode_to_pnode[i] = info->vnuma_nodes[i].pnode;
 }
 
+rc = libxl__build_dom(gc, domid, info, state, dom);
+if (rc != 0)
+goto out;
+
 rc = libxl__arch_domain_construct_memmap(gc, d_config, domid, dom);
 if (rc != 0) {
 LOG(ERROR, "setting domain memory map failed");
 goto out;
 }
 
-rc = libxl__build_dom(gc, domid, info, state, dom);
-if (rc != 0)
-goto out;
-
 rc = hvm_build_set_params(ctx->xch, domid, info, state->store_port,
>store_mfn, state->console_port,
>console_mfn, state->store_domid,
diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
index 46cfafb..2b221aa 100644
--- a/tools/libxl/libxl_x86.c
+++ b/tools/libxl/libxl_x86.c
@@ -492,6 +492,7 @@ int libxl__arch_domain_construct_memmap(libxl__gc *gc,
 uint64_t highmem_size =
 dom->highmem_end ? dom->highmem_end - (1ull << 32) : 0;
 uint32_t lowmem_start = dom->device_model ? GUEST_LOW_MEM_START_DEFAULT : 
0;
+unsigned page_size = XC_DOM_PAGE_SIZE(dom);
 
 /* Add all rdm entries. */
 for (i = 0; i < d_config->num_rdms; i++)
@@ -503,6 +504,10 @@ int libxl__arch_domain_construct_memmap(libxl__gc *gc,
 if (highmem_size)
 e820_entries++;
 
+for (i = 0; i < MAX_ACPI_MODULES; i++)
+if (dom->acpi_modules[i].length)
+e820_entries++;
+
 if (e820_entries >= E820MAX) {
 LOG(ERROR, "Ooops! Too many entries in the memory map!");
 rc = ERROR_INVAL;
@@ -528,6 +533,16 @@ int libxl__arch_domain_construct_memmap(libxl__gc *gc,
 nr++;
 }
 
+for (i = 0; i < MAX_ACPI_MODULES; i++) {
+if (dom->acpi_modules[i].length) {
+e820[nr].addr = dom->acpi_modules[i].guest_addr_out & ~(page_size 
- 1);
+e820[nr].size = dom->acpi_modules[i].length +
+(dom->acpi_modules[i].guest_addr_out & (page_size - 1));
+e820[nr].type = E820_ACPI;
+nr++;
+}
+}
+
 /* High memory */
 if (highmem_size) {
 e820[nr].addr = ((uint64_t)1 << 32);
-- 
1.8.3.1


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

[Xen-devel] [PATCH v5 03/21] acpi: Prevent GPL-only code from seeping into non-GPL binaries

[Boris Ostrovsky]

Some code (specifically, introduced by commit 801d469ad ("[HVM] ACPI
support patch 3 of 4: ACPI _PRT table.")) has only been licensed under
GPLv2. We want to prevent this code from showing up in non-GPL
binaries which might become possible after we make ACPI builder code
available to users other than hvmloader.

There are two pieces that we need to be careful about:
(1) A small chunk of code in dsdt.asl that implements _PIC method
(2) A chunk of ASL generator in mk_dsdt.c that describes with PCI
interrupt routing.

This code will now be generated by a GPL-only script which will be
invoked only when ACPI builder's Makefile is called with GPL variable
set.

We also strip license header from generated ASL files to prevent
inadverent use of those files with incorrect license.

Signed-off-by: Boris Ostrovsky 
---
Changes in v5:
* Generate GPL-only ASL with mk_dsdt_gpl.sh script
* Strip license header from generated DSDT ASL

 tools/firmware/hvmloader/Makefile|   4 +
 tools/firmware/hvmloader/acpi/Makefile   |  14 ++-
 tools/firmware/hvmloader/acpi/dsdt.asl   |  14 ---
 tools/firmware/hvmloader/acpi/gpl/mk_dsdt_gpl.sh | 110 +++
 tools/firmware/hvmloader/acpi/mk_dsdt.c  |  68 +-
 5 files changed, 126 insertions(+), 84 deletions(-)
 create mode 100755 tools/firmware/hvmloader/acpi/gpl/mk_dsdt_gpl.sh

diff --git a/tools/firmware/hvmloader/Makefile 
b/tools/firmware/hvmloader/Makefile
index 9f7357f..23b0a58 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -65,6 +65,10 @@ ROMBIOS_ROM := $(ROMBIOS_DIR)/BIOS-bochs-latest
 ROMS += $(ROMBIOS_ROM) $(STDVGA_ROM) $(CIRRUSVGA_ROM) $(ETHERBOOT_ROMS)
 endif
 
+# Certain parts of ACPI builder are GPL-only
+GPL = y
+export GPL
+
 .PHONY: all
 all: subdirs-all
$(MAKE) hvmloader
diff --git a/tools/firmware/hvmloader/acpi/Makefile 
b/tools/firmware/hvmloader/acpi/Makefile
index f63e734..820b8a7 100644
--- a/tools/firmware/hvmloader/acpi/Makefile
+++ b/tools/firmware/hvmloader/acpi/Makefile
@@ -17,7 +17,8 @@
 XEN_ROOT = $(CURDIR)/../../../..
 include $(XEN_ROOT)/tools/firmware/Rules.mk
 
-C_SRC = build.c dsdt_anycpu.c dsdt_15cpu.c static_tables.c 
dsdt_anycpu_qemu_xen.c
+C_SRC-$(GPL)   = build.c dsdt_anycpu.c dsdt_15cpu.c dsdt_anycpu_qemu_xen.c
+C_SRC  = build.c static_tables.c $(C_SRC-y)
 OBJS  = $(patsubst %.c,%.o,$(C_SRC))
 
 CFLAGS += $(CFLAGS_xeninclude)
@@ -36,18 +37,25 @@ ssdt_s3.h ssdt_s4.h ssdt_pm.h ssdt_tpm.h: %.h: %.asl iasl
 mk_dsdt: mk_dsdt.c
$(HOSTCC) $(HOSTCFLAGS) $(CFLAGS_xeninclude) -o $@ mk_dsdt.c
 
-dsdt_anycpu_qemu_xen.asl: dsdt.asl dsdt_acpi_info.asl mk_dsdt
+ifeq ($(GPL),y)
+dsdt_anycpu_qemu_xen.asl: dsdt.asl dsdt_acpi_info.asl gpl/mk_dsdt_gpl.sh 
mk_dsdt
awk 'NR > 1 {print s} {s=$$0}' $< > $@.$(TMP_SUFFIX)
+   # Strip license comment
+   sed -i '1,/\*\//{/\/\*/,/\*\//d}' $@.$(TMP_SUFFIX)
+   ./gpl/mk_dsdt_gpl.sh >> $@.$(TMP_SUFFIX)
cat dsdt_acpi_info.asl >> $@.$(TMP_SUFFIX)
./mk_dsdt --debug=$(debug) --dm-version qemu-xen >> $@.$(TMP_SUFFIX)
mv -f $@.$(TMP_SUFFIX) $@
 
 # NB. awk invocation is a portable alternative to 'head -n -1'
-dsdt_%cpu.asl: dsdt.asl dsdt_acpi_info.asl mk_dsdt
+dsdt_%cpu.asl: dsdt.asl dsdt_acpi_info.asl gpl/mk_dsdt_gpl.sh mk_dsdt
awk 'NR > 1 {print s} {s=$$0}' $< > $@.$(TMP_SUFFIX)
+   sed -i '1,/\*\//{/\/\*/,/\*\//d}' $@.$(TMP_SUFFIX)
+   ./gpl/mk_dsdt_gpl.sh >> $@.$(TMP_SUFFIX)
cat dsdt_acpi_info.asl >> $@.$(TMP_SUFFIX)
./mk_dsdt --debug=$(debug) --maxcpu $*  >> $@.$(TMP_SUFFIX)
mv -f $@.$(TMP_SUFFIX) $@
+endif
 
 $(filter dsdt_%.c,$(C_SRC)): %.c: iasl %.asl
iasl -vs -p $* -tc $*.asl
diff --git a/tools/firmware/hvmloader/acpi/dsdt.asl 
b/tools/firmware/hvmloader/acpi/dsdt.asl
index 4f6db79..13811cf 100644
--- a/tools/firmware/hvmloader/acpi/dsdt.asl
+++ b/tools/firmware/hvmloader/acpi/dsdt.asl
@@ -26,20 +26,6 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2, "Xen", "HVM", 0)
 Name (\APCL, 0x0001)
 Name (\PUID, 0x00)
 
-/* _S3 and _S4 are in separate SSDTs */
-Name (\_S5, Package (0x04)
-{
-0x00,  /* PM1a_CNT.SLP_TYP */
-0x00,  /* PM1b_CNT.SLP_TYP */
-0x00,  /* reserved */
-0x00   /* reserved */
-})
-
-Name(PICD, 0)
-Method(_PIC, 1)
-{
-Store(Arg0, PICD) 
-}
 
 Scope (\_SB)
 {
diff --git a/tools/firmware/hvmloader/acpi/gpl/mk_dsdt_gpl.sh 
b/tools/firmware/hvmloader/acpi/gpl/mk_dsdt_gpl.sh
new file mode 100755
index 000..4158b99
--- /dev/null
+++ b/tools/firmware/hvmloader/acpi/gpl/mk_dsdt_gpl.sh
@@ -0,0 +1,110 @@
+# This program is free software; you can redistribute it and/or modify it
+# under the terms and conditions of the GNU General Public License,
+# version 2, as published by the Free Software Foundation.
+#
+# This program is distributed in the hope it will be useful, but WITHOUT
+# 

[Xen-devel] [PATCH v5 11/21] acpi/hvmloader: Link ACPI object files directly

[Boris Ostrovsky]

ACPI sources will be available to various component which will build
them according to their own rules. ACPI's Makefile will only generate
necessary source files.

Signed-off-by: Boris Ostrovsky 
Acked-by: Jan Beulich 
---
Changes in v5:
* .gitignore lists all dsdt* / ssdt* files as not tracked.
* Clarified use of TMP_SUFFIX afor iasl bug workaround

 .gitignore |  7 +++--
 tools/firmware/hvmloader/Makefile  | 11 +++-
 tools/firmware/hvmloader/acpi/Makefile | 47 +++---
 3 files changed, 39 insertions(+), 26 deletions(-)

diff --git a/.gitignore b/.gitignore
index 6dee857..8e30a5d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -127,13 +127,12 @@ tools/firmware/*bios/*bios*.txt
 tools/firmware/etherboot/gpxe/*
 tools/firmware/extboot/extboot.img
 tools/firmware/extboot/signrom
-tools/firmware/hvmloader/acpi/mk_dsdt
-tools/firmware/hvmloader/acpi/dsdt*.c
-tools/firmware/hvmloader/acpi/dsdt_*cpu*.asl
-tools/firmware/hvmloader/acpi/ssdt_*.h
+tools/firmware/hvmloader/dsdt*
 tools/firmware/hvmloader/hvmloader
+tools/firmware/hvmloader/mk_dsdt
 tools/firmware/hvmloader/roms.h
 tools/firmware/hvmloader/roms.inc
+tools/firmware/hvmloader/ssdt*
 tools/firmware/rombios/BIOS-bochs-[^/]*
 tools/firmware/rombios/_rombios[^/]*_.c
 tools/firmware/rombios/rombios[^/]*.s
diff --git a/tools/firmware/hvmloader/Makefile 
b/tools/firmware/hvmloader/Makefile
index 23b0a58..2565832 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -20,6 +20,7 @@
 XEN_ROOT = $(CURDIR)/../../..
 include $(XEN_ROOT)/tools/firmware/Rules.mk
 
+export ACPI_BUILD_DIR=$(CURDIR)
 SUBDIRS := acpi
 
 # The HVM loader is started in 32-bit mode at the address below:
@@ -76,7 +77,15 @@ all: subdirs-all
 rombios.o: roms.inc
 smbios.o: CFLAGS += -D__SMBIOS_DATE__="\"$(SMBIOS_REL_DATE)\""
 
-hvmloader: $(OBJS) acpi/acpi.a
+ACPI_PATH = acpi
+ACPI_FILES = dsdt_anycpu.c dsdt_15cpu.c dsdt_anycpu_qemu_xen.c
+ACPI_OBJS = $(patsubst %.c,%.o,$(ACPI_FILES)) build.o static_tables.o
+$(ACPI_OBJS): CFLAGS += -I$(ACPI_PATH) -I.
+vpath build.c $(ACPI_PATH)
+vpath static_tables.c $(ACPI_PATH)
+OBJS += $(ACPI_OBJS)
+
+hvmloader: $(OBJS)
$(LD) $(LDFLAGS_DIRECT) -N -Ttext $(LOADADDR) -o hvmloader.tmp $^
$(OBJCOPY) hvmloader.tmp hvmloader
rm -f hvmloader.tmp
diff --git a/tools/firmware/hvmloader/acpi/Makefile 
b/tools/firmware/hvmloader/acpi/Makefile
index b14b3ea..3550a84 100644
--- a/tools/firmware/hvmloader/acpi/Makefile
+++ b/tools/firmware/hvmloader/acpi/Makefile
@@ -15,52 +15,57 @@
 XEN_ROOT = $(CURDIR)/../../../..
 include $(XEN_ROOT)/tools/firmware/Rules.mk
 
-C_SRC-$(GPL)   = build.c dsdt_anycpu.c dsdt_15cpu.c dsdt_anycpu_qemu_xen.c
-C_SRC  = build.c static_tables.c $(C_SRC-y)
-OBJS  = $(patsubst %.c,%.o,$(C_SRC))
+MK_DSDT = $(ACPI_BUILD_DIR)/mk_dsdt
 
-CFLAGS += $(CFLAGS_xeninclude)
+C_SRC-$(GPL)   = dsdt_anycpu.c dsdt_15cpu.c dsdt_anycpu_qemu_xen.c
+C_SRC  = $(addprefix $(ACPI_BUILD_DIR)/, $(C_SRC-y))
+H_SRC = $(addprefix $(ACPI_BUILD_DIR)/, ssdt_s3.h ssdt_s4.h ssdt_pm.h 
ssdt_tpm.h)
 
 # Suffix for temporary files.
+#
+# We will also use this suffix to workaround a bug in older iasl
+# versions where the tool will ignore everything after last '.' in the
+# path ('-p' argument). By adding "." we force iasl to use
+# complete $(ACPI_BUILD_DIR) as path, even if it has '.' symbols.
 TMP_SUFFIX = tmp
 
 vpath iasl $(PATH)
-all: acpi.a
+all: $(C_SRC) $(H_SRC)
 
-ssdt_s3.h ssdt_s4.h ssdt_pm.h ssdt_tpm.h: %.h: %.asl iasl
-   iasl -vs -p $* -tc $<
-   sed -e 's/AmlCode/$*/g' $*.hex >$@
-   rm -f $*.hex $*.aml
+$(H_SRC): $(ACPI_BUILD_DIR)/%.h: %.asl iasl
+   iasl -vs -p $(ACPI_BUILD_DIR)/$*.$(TMP_SUFFIX) -tc $<
+   sed -e 's/AmlCode/$*/g' $(ACPI_BUILD_DIR)/$*.hex >$@
+   rm -f $(addprefix $(ACPI_BUILD_DIR)/, $*.aml $*.hex)
 
-mk_dsdt: mk_dsdt.c
+$(MK_DSDT): mk_dsdt.c
$(HOSTCC) $(HOSTCFLAGS) $(CFLAGS_xeninclude) -o $@ mk_dsdt.c
 
 ifeq ($(GPL),y)
-dsdt_anycpu_qemu_xen.asl: dsdt.asl dsdt_acpi_info.asl gpl/mk_dsdt_gpl.sh 
mk_dsdt
+$(ACPI_BUILD_DIR)/dsdt_anycpu_qemu_xen.asl: dsdt.asl dsdt_acpi_info.asl 
gpl/mk_dsdt_gpl.sh $(MK_DSDT)
awk 'NR > 1 {print s} {s=$$0}' $< > $@.$(TMP_SUFFIX)
# Strip license comment
sed -i '1,/\*\//{/\/\*/,/\*\//d}' $@.$(TMP_SUFFIX)
./gpl/mk_dsdt_gpl.sh >> $@.$(TMP_SUFFIX)
cat dsdt_acpi_info.asl >> $@.$(TMP_SUFFIX)
-   ./mk_dsdt --debug=$(debug) --dm-version qemu-xen >> $@.$(TMP_SUFFIX)
+   $(MK_DSDT) --debug=$(debug) --dm-version qemu-xen >> $@.$(TMP_SUFFIX)
mv -f $@.$(TMP_SUFFIX) $@
 
 # NB. awk invocation is a portable alternative to 'head -n -1'
-dsdt_%cpu.asl: dsdt.asl dsdt_acpi_info.asl gpl/mk_dsdt_gpl.sh mk_dsdt
+$(ACPI_BUILD_DIR)/dsdt_%cpu.asl: dsdt.asl dsdt_acpi_info.asl 
gpl/mk_dsdt_gpl.sh $(MK_DSDT)
awk 'NR > 1 {print s} {s=$$0}' $< > $@.$(TMP_SUFFIX)
sed 

[Xen-devel] [PATCH v5 12/21] acpi/hvmloader: Include file/paths adjustments

[Boris Ostrovsky]

In prepearation to moving acpi sources into generally available
libacpi:

1. Pass IOAPIC/LAPIC/PCI mask values via struct acpi_config
2. Modify include files search paths to point to acpi directory
3. Macro-ise include file for build.c that defines various
   utilities used by that file. Users of libacpi will be expected
   to define this macro when compiling build.c

Signed-off-by: Boris Ostrovsky 
Acked-by: Jan Beulich 
---
Changes in v5:
* Include  in build.c

 tools/firmware/hvmloader/Makefile |  3 ++-
 tools/firmware/hvmloader/acpi/README  | 16 
 tools/firmware/hvmloader/acpi/build.c | 20 +++-
 tools/firmware/hvmloader/acpi/libacpi.h   |  7 +++
 tools/firmware/hvmloader/hvmloader.c  |  2 +-
 tools/firmware/hvmloader/rombios.c|  2 +-
 tools/firmware/hvmloader/seabios.c|  5 +++--
 tools/firmware/hvmloader/util.c   | 15 +--
 tools/firmware/rombios/32bit/Makefile |  2 +-
 tools/firmware/rombios/32bit/tcgbios/Makefile |  2 +-
 tools/firmware/rombios/32bit/util.h   |  2 +-
 11 files changed, 53 insertions(+), 23 deletions(-)

diff --git a/tools/firmware/hvmloader/Makefile 
b/tools/firmware/hvmloader/Makefile
index 2565832..7b3641c 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -80,7 +80,8 @@ smbios.o: CFLAGS += -D__SMBIOS_DATE__="\"$(SMBIOS_REL_DATE)\""
 ACPI_PATH = acpi
 ACPI_FILES = dsdt_anycpu.c dsdt_15cpu.c dsdt_anycpu_qemu_xen.c
 ACPI_OBJS = $(patsubst %.c,%.o,$(ACPI_FILES)) build.o static_tables.o
-$(ACPI_OBJS): CFLAGS += -I$(ACPI_PATH) -I.
+$(ACPI_OBJS): CFLAGS += -I. -DLIBACPI_STDUTILS=\"../util.h\"
+CFLAGS += -I$(ACPI_PATH)
 vpath build.c $(ACPI_PATH)
 vpath static_tables.c $(ACPI_PATH)
 OBJS += $(ACPI_OBJS)
diff --git a/tools/firmware/hvmloader/acpi/README 
b/tools/firmware/hvmloader/acpi/README
index 210d5ba..2b9d6e1 100644
--- a/tools/firmware/hvmloader/acpi/README
+++ b/tools/firmware/hvmloader/acpi/README
@@ -1,11 +1,19 @@
-ACPI Table for domain firmware
+ACPI builder for domain firmware
 
 
-INSTALL
+BUILDING ACPI
 -
-Simply make is OK.
-# make 
+Users of ACPI builder are expected to provide an include file that makes 
available
+the following:
+* strncpy
+* printf
+* NULL
+* test_bit
+* offsetof
 
+When compiling build.c, the name of this include file should be given to
+compiler as -DLIBACPI_STDUTILS=\"\". See 
tools/firmware/hvmloader/Makefile
+for an example.
 
 Note on DSDT Table
 --
diff --git a/tools/firmware/hvmloader/acpi/build.c 
b/tools/firmware/hvmloader/acpi/build.c
index b295ef0..6749c9b 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -13,15 +13,14 @@
  * GNU Lesser General Public License for more details.
  */
 
+#include LIBACPI_STDUTILS
 #include "acpi2_0.h"
 #include "libacpi.h"
 #include "ssdt_s3.h"
 #include "ssdt_s4.h"
 #include "ssdt_tpm.h"
 #include "ssdt_pm.h"
-#include "../config.h"
-#include "../util.h"
-#include "../vnuma.h"
+#include 
 #include 
 #include 
 #include 
@@ -82,6 +81,9 @@ static struct acpi_20_madt *construct_madt(struct acpi_ctxt 
*ctxt,
 const struct hvm_info_table   *hvminfo = config->hvminfo;
 int i, sz;
 
+if ( config->lapic_id == NULL )
+return NULL;
+
 sz  = sizeof(struct acpi_20_madt);
 sz += sizeof(struct acpi_20_madt_intsrcovr) * 16;
 sz += sizeof(struct acpi_20_madt_ioapic);
@@ -98,7 +100,7 @@ static struct acpi_20_madt *construct_madt(struct acpi_ctxt 
*ctxt,
 madt->header.oem_revision = ACPI_OEM_REVISION;
 madt->header.creator_id   = ACPI_CREATOR_ID;
 madt->header.creator_revision = ACPI_CREATOR_REVISION;
-madt->lapic_addr = LAPIC_BASE_ADDRESS;
+madt->lapic_addr = config->lapic_base_address;
 madt->flags  = ACPI_PCAT_COMPAT;
 
 if ( config->table_flags & ACPI_HAS_IOAPIC )
@@ -117,7 +119,7 @@ static struct acpi_20_madt *construct_madt(struct acpi_ctxt 
*ctxt,
 intsrcovr->gsi= 2;
 intsrcovr->flags  = 0x0;
 }
-else if ( PCI_ISA_IRQ_MASK & (1U << i) )
+else if ( config->pci_isa_irq_mask & (1U << i) )
 {
 /* PCI: active-low level-triggered. */
 intsrcovr->gsi= i;
@@ -136,8 +138,8 @@ static struct acpi_20_madt *construct_madt(struct acpi_ctxt 
*ctxt,
 memset(io_apic, 0, sizeof(*io_apic));
 io_apic->type= ACPI_IO_APIC;
 io_apic->length  = sizeof(*io_apic);
-io_apic->ioapic_id   = IOAPIC_ID;
-io_apic->ioapic_addr = ioapic_base_address;
+io_apic->ioapic_id   = config->ioapic_id;
+io_apic->ioapic_addr = config->ioapic_base_address;
 
 lapic = (struct acpi_20_madt_lapic *)(io_apic + 1);
 }
@@ -153,7 +155,7 @@ static struct acpi_20_madt *construct_madt(struct acpi_ctxt 
*ctxt,
 

[Xen-devel] [PATCH v5 06/21] acpi/hvmloader: Set TIS header address in hvmloader

[Boris Ostrovsky]

Users other than hvmloader may provide TIS address as virtual.

Signed-off-by: Boris Ostrovsky 
Reviewed-by: Jan Beulich 
---
 tools/firmware/hvmloader/acpi/build.c   | 9 -
 tools/firmware/hvmloader/acpi/libacpi.h | 3 +++
 tools/firmware/hvmloader/config.h   | 2 ++
 tools/firmware/hvmloader/util.c | 4 
 4 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/tools/firmware/hvmloader/acpi/build.c 
b/tools/firmware/hvmloader/acpi/build.c
index 68eb7c4..c984e5a 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -335,7 +335,6 @@ static int construct_secondary_tables(unsigned long 
*table_ptrs,
 struct acpi_20_tcpa *tcpa;
 unsigned char *ssdt;
 static const uint16_t tis_signature[] = {0x0001, 0x0001, 0x0001};
-uint16_t *tis_hdr;
 void *lasa;
 
 /* MADT. */
@@ -388,10 +387,10 @@ static int construct_secondary_tables(unsigned long 
*table_ptrs,
 }
 
 /* TPM TCPA and SSDT. */
-tis_hdr = (uint16_t *)0xFED40F00;
-if ( (tis_hdr[0] == tis_signature[0]) &&
- (tis_hdr[1] == tis_signature[1]) &&
- (tis_hdr[2] == tis_signature[2]) )
+if ( (config->table_flags & ACPI_HAS_TCPA) &&
+ (config->tis_hdr[0] == tis_signature[0]) &&
+ (config->tis_hdr[1] == tis_signature[1]) &&
+ (config->tis_hdr[2] == tis_signature[2]) )
 {
 ssdt = mem_alloc(sizeof(ssdt_tpm), 16);
 if (!ssdt) return -1;
diff --git a/tools/firmware/hvmloader/acpi/libacpi.h 
b/tools/firmware/hvmloader/acpi/libacpi.h
index d1e7042..70cf26b 100644
--- a/tools/firmware/hvmloader/acpi/libacpi.h
+++ b/tools/firmware/hvmloader/acpi/libacpi.h
@@ -27,6 +27,7 @@
 #define ACPI_HAS_SSDT_PM (1<<4)
 #define ACPI_HAS_SSDT_S3 (1<<5)
 #define ACPI_HAS_SSDT_S4 (1<<6)
+#define ACPI_HAS_TCPA(1<<7)
 
 struct xen_vmemrange;
 struct acpi_numa {
@@ -60,6 +61,8 @@ struct acpi_config {
 struct acpi_numa numa;
 const struct hvm_info_table *hvminfo;
 
+const uint16_t *tis_hdr;
+
 /*
  * Address where acpi_info should be placed.
  * This must match the OperationRegion(BIOS, SystemMemory, )
diff --git a/tools/firmware/hvmloader/config.h 
b/tools/firmware/hvmloader/config.h
index a4429f4..6e00413 100644
--- a/tools/firmware/hvmloader/config.h
+++ b/tools/firmware/hvmloader/config.h
@@ -56,6 +56,8 @@ extern uint8_t ioapic_version;
 /* MMIO hole: Hardcoded defaults, which can be dynamically expanded. */
 #define PCI_MEM_END 0xfc00
 
+#define ACPI_TIS_HDR_ADDRESS 0xFED40F00UL
+
 extern unsigned long pci_mem_start, pci_mem_end;
 extern uint64_t pci_hi_mem_start, pci_hi_mem_end;
 
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index f37b16e..8875675 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -919,6 +919,10 @@ void hvmloader_acpi_build_tables(struct acpi_config 
*config,
 if ( !strncmp(xenstore_read("platform/acpi_s4", "1"), "1", 1)  )
 config->table_flags |= ACPI_HAS_SSDT_S4;
 
+config->table_flags |= ACPI_HAS_TCPA;
+
+config->tis_hdr = (uint16_t *)ACPI_TIS_HDR_ADDRESS;
+
 config->numa.nr_vmemranges = nr_vmemranges;
 config->numa.nr_vnodes = nr_vnodes;
 config->numa.vcpu_to_vnode = vcpu_to_vnode;
-- 
1.8.3.1


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

[Xen-devel] [PATCH v5 16/21] libxc/libxl: Allow multiple ACPI modules

[Boris Ostrovsky]

Provide ability to load multiple ACPI modules. Thie feature is needed
by PVHv2 guests and will be used in subsequent patches.

We assume that PVHv2 guests do not load their ACPI modules specified
in the configuration file. We can extend support for that in the future
if desired.

Signed-off-by: Boris Ostrovsky 
Acked-by: Wei Liu 
---
 tools/libxc/include/xc_dom.h   |  5 +++--
 tools/libxc/xc_dom_hvmloader.c |  3 ++-
 tools/libxl/libxl_dom.c| 26 ++
 3 files changed, 23 insertions(+), 11 deletions(-)

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index de7dca9..608cbc2 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -212,8 +212,9 @@ struct xc_dom_image {
 /* BIOS/Firmware passed to HVMLOADER */
 struct xc_hvm_firmware_module system_firmware_module;
 
-/* Extra ACPI tables passed to HVMLOADER */
-struct xc_hvm_firmware_module acpi_module;
+/* Extra ACPI tables */
+#define MAX_ACPI_MODULES4
+struct xc_hvm_firmware_module acpi_modules[MAX_ACPI_MODULES];
 
 /* Extra SMBIOS structures passed to HVMLOADER */
 struct xc_hvm_firmware_module smbios_module;
diff --git a/tools/libxc/xc_dom_hvmloader.c b/tools/libxc/xc_dom_hvmloader.c
index 6eb8516..59f94e5 100644
--- a/tools/libxc/xc_dom_hvmloader.c
+++ b/tools/libxc/xc_dom_hvmloader.c
@@ -172,7 +172,8 @@ static int modules_init(struct xc_dom_image *dom)
 rc = module_init_one(dom, >system_firmware_module,
  "System Firmware module");
 if ( rc ) goto err;
-rc = module_init_one(dom, >acpi_module, "ACPI module");
+/* Only one module can be added */
+rc = module_init_one(dom, >acpi_modules[0], "ACPI module");
 if ( rc ) goto err;
 rc = module_init_one(dom, >smbios_module, "SMBIOS module");
 if ( rc ) goto err;
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index c895649..c4be916 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -818,7 +818,8 @@ static int hvm_build_set_params(xc_interface *handle, 
uint32_t domid,
 
 static int hvm_build_set_xs_values(libxl__gc *gc,
uint32_t domid,
-   struct xc_dom_image *dom)
+   struct xc_dom_image *dom,
+   const libxl_domain_build_info *info)
 {
 char *path = NULL;
 int ret = 0;
@@ -839,18 +840,20 @@ static int hvm_build_set_xs_values(libxl__gc *gc,
 goto err;
 }
 
-if (dom->acpi_module.guest_addr_out) {
+/* Only one module can be passed. PVHv2 guests do not support this. */
+if (dom->acpi_modules[0].guest_addr_out && 
+info->device_model_version !=LIBXL_DEVICE_MODEL_VERSION_NONE) {
 path = GCSPRINTF("/local/domain/%d/"HVM_XS_ACPI_PT_ADDRESS, domid);
 
 ret = libxl__xs_printf(gc, XBT_NULL, path, "0x%"PRIx64,
-   dom->acpi_module.guest_addr_out);
+   dom->acpi_modules[0].guest_addr_out);
 if (ret)
 goto err;
 
 path = GCSPRINTF("/local/domain/%d/"HVM_XS_ACPI_PT_LENGTH, domid);
 
 ret = libxl__xs_printf(gc, XBT_NULL, path, "0x%x",
-   dom->acpi_module.length);
+   dom->acpi_modules[0].length);
 if (ret)
 goto err;
 }
@@ -994,6 +997,13 @@ static int libxl__domain_firmware(libxl__gc *gc,
 }
 
 if (info->u.hvm.acpi_firmware) {
+
+if (info->device_model_version == LIBXL_DEVICE_MODEL_VERSION_NONE) {
+LOGE(ERROR, "PVH guests do not allow loading ACPI modules");
+rc = ERROR_FAIL;
+goto out;
+}
+
 data = NULL;
 e = libxl_read_file_contents(ctx, info->u.hvm.acpi_firmware,
  , );
@@ -1005,9 +1015,9 @@ static int libxl__domain_firmware(libxl__gc *gc,
 }
 libxl__ptr_add(gc, data);
 if (datalen) {
-/* Only accept non-empty files */
-dom->acpi_module.data = data;
-dom->acpi_module.length = (uint32_t)datalen;
+/* Only accept a non-empty file */
+dom->acpi_modules[0].data = data;
+dom->acpi_modules[0].length = (uint32_t)datalen;
 }
 }
 
@@ -1143,7 +1153,7 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
 goto out;
 }
 
-rc = hvm_build_set_xs_values(gc, domid, dom);
+rc = hvm_build_set_xs_values(gc, domid, dom, info);
 if (rc != 0) {
 LOG(ERROR, "hvm build set xenstore values failed");
 goto out;
-- 
1.8.3.1


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

[Xen-devel] [PATCH v4] x86/vm_event: Allow overwriting Xen's i-cache used for emulation

[Tamas K Lengyel]

When emulating instructions Xen's emulator maintains a small i-cache fetched
from the guest memory. This patch extends the vm_event interface to allow
overwriting this i-cache via a buffer returned in the vm_event response.

When responding to a SOFTWARE_BREAKPOINT event (INT3) the monitor subscriber
normally has to remove the INT3 from memory - singlestep - place back INT3
to allow the guest to continue execution. This routine however is susceptible
to a race-condition on multi-vCPU guests. By allowing the subscriber to return
the i-cache to be used for emulation it can side-step the problem by returning
a clean buffer without the INT3 present.

As part of this patch we rename hvm_mem_access_emulate_one to
hvm_emulate_one_vm_event to better reflect that it is used in various vm_event
scenarios now, not just in response to mem_access events.

Signed-off-by: Tamas K Lengyel 
Acked-by: Razvan Cojocaru 
---
Cc: Paul Durrant 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Jun Nakajima 
Cc: Kevin Tian 
Cc: George Dunlap 
Cc: Stefano Stabellini 
Cc: Julien Grall 

v4: Copy insn buffer into mmio buffer to avoid more login in hvm_emulate_one
Add comment in hvm_do_resume to preserve order as described in vm_event.h
---
 xen/arch/x86/hvm/emulate.c| 27 +--
 xen/arch/x86/hvm/hvm.c| 13 ++---
 xen/arch/x86/vm_event.c   | 11 ++-
 xen/include/asm-x86/hvm/emulate.h |  5 +++--
 xen/include/asm-x86/vm_event.h|  5 -
 xen/include/public/vm_event.h | 17 -
 6 files changed, 64 insertions(+), 14 deletions(-)

diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index cc25676..17f7f0d 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -76,9 +76,9 @@ static int set_context_data(void *buffer, unsigned int size)
 if ( curr->arch.vm_event )
 {
 unsigned int safe_size =
-min(size, curr->arch.vm_event->emul_read_data.size);
+min(size, curr->arch.vm_event->emul.read.size);
 
-memcpy(buffer, curr->arch.vm_event->emul_read_data.data, safe_size);
+memcpy(buffer, curr->arch.vm_event->emul.read.data, safe_size);
 memset(buffer + safe_size, 0, size - safe_size);
 return X86EMUL_OKAY;
 }
@@ -1931,7 +1931,7 @@ int hvm_emulate_one_mmio(unsigned long mfn, unsigned long 
gla)
 return rc;
 }
 
-void hvm_mem_access_emulate_one(enum emul_kind kind, unsigned int trapnr,
+void hvm_emulate_one_vm_event(enum emul_kind kind, unsigned int trapnr,
 unsigned int errcode)
 {
 struct hvm_emulate_ctxt ctx = {{ 0 }};
@@ -1944,10 +1944,25 @@ void hvm_mem_access_emulate_one(enum emul_kind kind, 
unsigned int trapnr,
 case EMUL_KIND_NOWRITE:
 rc = hvm_emulate_one_no_write();
 break;
-case EMUL_KIND_SET_CONTEXT:
-ctx.set_context = 1;
-/* Intentional fall-through. */
+case EMUL_KIND_SET_CONTEXT_INSN: {
+struct vcpu *curr = current;
+struct hvm_vcpu_io *vio = >arch.hvm_vcpu.hvm_io;
+
+BUILD_BUG_ON(sizeof(vio->mmio_insn) !=
+ sizeof(curr->arch.vm_event->emul.insn.data));
+ASSERT(!vio->mmio_insn_bytes);
+
+/*
+ * Stash insn buffer into mmio buffer here instead of ctx
+ * to avoid having to add more logic to hvm_emulate_one.
+ */
+vio->mmio_insn_bytes = sizeof(vio->mmio_insn);
+memcpy(vio->mmio_insn, curr->arch.vm_event->emul.insn.data,
+   vio->mmio_insn_bytes);
+}
+/* Fall-through */
 default:
+ctx.set_context = (kind == EMUL_KIND_SET_CONTEXT_DATA);
 rc = hvm_emulate_one();
 }
 
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 7bad845..b06e4d5 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -487,15 +487,22 @@ void hvm_do_resume(struct vcpu *v)
 {
 enum emul_kind kind = EMUL_KIND_NORMAL;
 
+/*
+ * Please observ the order here to match the flag descriptions
+ * provided in public/vm_event.h
+ */
 if ( v->arch.vm_event->emulate_flags &
  VM_EVENT_FLAG_SET_EMUL_READ_DATA )
-kind = EMUL_KIND_SET_CONTEXT;
+kind = EMUL_KIND_SET_CONTEXT_DATA;
 else if ( v->arch.vm_event->emulate_flags &
   VM_EVENT_FLAG_EMULATE_NOWRITE )
 kind = EMUL_KIND_NOWRITE;
+else if ( v->arch.vm_event->emulate_flags &
+  VM_EVENT_FLAG_SET_EMUL_INSN_DATA )
+kind = EMUL_KIND_SET_CONTEXT_INSN;
 
-hvm_mem_access_emulate_one(kind, TRAP_invalid_op,
-   

Re: [Xen-devel] [RFC 0/5] xen/arm: support big.little SoC

[Julien Grall]

Hi Stefano,

On 22/09/2016 18:31, Stefano Stabellini wrote:

On Thu, 22 Sep 2016, Julien Grall wrote:

Hello Peng,

On 22/09/16 10:27, Peng Fan wrote:

On Thu, Sep 22, 2016 at 10:50:23AM +0200, Dario Faggioli wrote:

On Thu, 2016-09-22 at 14:49 +0800, Peng Fan wrote:

On Wed, Sep 21, 2016 at 08:11:43PM +0100, Julien Grall wrote:

A feature like `xl cpupool-biglittle-split' can still be interesting,


"cpupool-cluster-split" maybe a better name?


You seem to assume that a cluster, from the MPIDR point of view, can only
contain the same set of CPUs. I don't think this is part of the architecture,
so this may not be true in the future.


Interesting. I also understood that a cluster can only have one kind if
cpus. Honestly it would be a little insane for it to be otherwise :-)


I don't think this is insane (or maybe I am insane :)). Cluster usually 
doesn't share all L2 cache (assuming L1 is local to each core) and L3 
cache may not be present, so if you move a task from one cluster to 
another you will add latency because the new L2 cache has to be refilled.


The use case of big.LITTLE is big cores are used for short period of 
burst and little core are used for the rest (e.g listening audio, 
fetching mail...). If you want to reduce latency when switch between big 
and little CPUs, you may want to put them within the same cluster.


Also, as mentioned in another thread, you may have a platform with the 
same micro-architecture (e.g Cortex A-53) but different silicon 
implementation (e.g to have a different frequency, power efficiency). 
Here the concept of big.LITTLE is more blurred.


That's why I am quite reluctant to name (even if it may be more handy to 
the user) "big" and "little" the different CPU set.


Cheers,

--
Julien Grall

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

[Xen-devel] [qemu-mainline test] 101101: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101081
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 101081
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101081

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass

version targeted for testing:
 qemuub98bbea2d94dc5902acaa3a5dd7f9057cc82cdb1
baseline version:
 qemuua008535b9fa396226ff9cf78b8ac5f3584bda58e

Last test of basis   101081  2016-09-21 14:11:11 Z1 days
Testing same since   101101  2016-09-22 11:51:11 Z0 days1 attempts


People who touched revisions under test:
  Peter Maydell 
  Richard Henderson 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   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-xsm   

Re: [Xen-devel] [PATCH v6 4/4] x86/ioreq server: Reset outstanding p2m_ioreq_server entries when an ioreq server unmaps.

[George Dunlap]

On Tue, Sep 20, 2016 at 3:57 AM, Yu Zhang  wrote:
> Well, for the logic of p2m type recalculation, similarities between
> p2m_ioreq_server
> and other changeable types exceeds their differences. As to the special
> cases, how
> about we use a macro, i.e. p2m_is_ioreq?

 That'd be better than the open coded check, but would still result
 in (taking the above example)

p2m_is_changeable(ept_entry->sa_p2mt) &&
!p2m_is_ioreq(ept_entry->sa_p2mt) )

 ? What I'd prefer is a predicate that can be applied here on its own,
 without involving && or ||.

>>> OK. I can think of 2 scenarios that p2m_ioreq_server needs special
>>> handling:
>>>
>>> 1> In ept_get_entry()/recal_type(), the p2m types are supposed to return
>>> as it is, instead of
>>> changing to p2m_log_dirty. So we can use a macro or a inline function
>>> like p2m_check_changeable(),
>>> which combines the
>>>
>>>p2m_is_changeable(ept_entry->sa_p2mt) &&
>>>!p2m_is_ioreq(ept_entry->sa_p2mt) )
>>>
>>> together.
>>>
>>> 2> In resolve_misconfig()/do_recalc(), the entry_count gets decremented.
>>> We
>>> do not need this new inline function, because they are in a separate
>>> if() statement.
>>>
>>> Is this OK? :)
>>
>> Sounds reasonable. But please give George and others a chance to
>> voice their opinions before you go that route.
>>
>> Jan
>
>
> Hi George,
>
>   Any comments on this series? :)

Well regarding the question you and Jan have been discussing, of what
to call / how to do the checks for changeable-but-not-ioreq, I don't
really care very much. :-)

I'm sorry it's taking so long to look at this series -- the code
you're trying to modify is already a bit of a tangled mess, and I
think this patch has a ways to go before it's ready.  I do think this
series is important, so I'll be coming back to it first thing Monday.

Regarding the pausing added in this patch -- you listed two reasons in
the first patch for the domain pausing.  The first was detecting
read-modify-write and acting appropriately; I think that can be done
with the patch that I sent you.

The second was the deadlock due to grabbing locks in a different
order.  I'm afraid having such a thing lying around, even if you've
avoided it for now by pausing the domain, is another major trap that
we should try to avoid laying for future developers if we can at all
help it.  The normal thing to do here is to simply have a locking
discipline -- in this case, I don't think it would be too difficult to
work out a locking order that would avoid the deadlock in a more
robust way than pausing and unpausing the domain.

With those two handled, we shouldn't need to pause the domain any more.

Thanks for your work on this -- I'll get back to patch 4/4 next week.

Peace,
 -George

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

Re: [Xen-devel] [RFC 0/5] xen/arm: support big.little SoC

[Stefano Stabellini]

On Thu, 22 Sep 2016, Dario Faggioli wrote:
> On Thu, 2016-09-22 at 18:05 +0800, Peng Fan wrote:
> > On Thu, Sep 22, 2016 at 10:50:23AM +0200, Dario Faggioli wrote:
> > > Yes (or I should say, "whatever", as I know nothing about all
> > > this! :-P)
> > 
> > One more thing I'd like to ask, do you prefer cpu classes to be ARM
> > specific or ARM/X86
> > common?
> > 
> I'm not sure. I'd say that it depends on where we are. I mean, in Xen,
> names can be rather specific, like some codename of the
> chip/core/family/etc.
> 
> I'm not sure what this means for you, on ARM, but I guess it would
> depend on what you, Julien and Stefano will come up and agree on.

Actually it depends on what the x86 maintainers think. For us (ARM
maintainers) it makes little difference whether the concept of cpu
classes is ARM specific or common.

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

Re: [Xen-devel] [RFC 0/5] xen/arm: support big.little SoC

[Stefano Stabellini]

On Thu, 22 Sep 2016, Julien Grall wrote:
> Hello Peng,
> 
> On 22/09/16 10:27, Peng Fan wrote:
> > On Thu, Sep 22, 2016 at 10:50:23AM +0200, Dario Faggioli wrote:
> > > On Thu, 2016-09-22 at 14:49 +0800, Peng Fan wrote:
> > > > On Wed, Sep 21, 2016 at 08:11:43PM +0100, Julien Grall wrote:
> > > A feature like `xl cpupool-biglittle-split' can still be interesting,
> > 
> > "cpupool-cluster-split" maybe a better name?
> 
> You seem to assume that a cluster, from the MPIDR point of view, can only
> contain the same set of CPUs. I don't think this is part of the architecture,
> so this may not be true in the future.

Interesting. I also understood that a cluster can only have one kind if
cpus. Honestly it would be a little insane for it to be otherwise :-)

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

Re: [Xen-devel] Question about VPID during MOV-TO-CR3

[Tamas K Lengyel]

On Thu, Sep 22, 2016 at 5:37 AM, Tamas K Lengyel
 wrote:
> On Sep 22, 2016 05:27, "Jan Beulich"  wrote:
>>
>> >>> On 22.09.16 at 12:35,  wrote:
>> > On Sep 22, 2016 02:56, "Jan Beulich"  wrote:
>> >>
>> >> >>> On 21.09.16 at 17:30,  wrote:
>> >> > What I'm saying is that the guest OS should be in charge of managing
>> >> > its own TLB when VPID is in use. Whether it does flush the TLB or not
>> >> > is not of our concern. If it's a sane OS it will likely flush when it
>> >> > needs to, but we should not be jumping in and doing it as we do right
>> >> > now. We are actually breaking the architectural behavior by forcing a
>> >> > flush, MOV-TO-CR3 doesn't by itself flush the TLB on real hardware.
>> >>
>> >> I continue to not understand where you take this from. Writes to
>> >> CR3 have always been doing TLB flushes - full ones prior to the
>> >> introduction of global pages, and flushes of only non-global entries
>> >> nowadays. In fact prior to the introduction of INVLPG and CR4
>> >> there was no other way to flush TLBs.
>> >
>> > Yes, I meant it doesn't completely flush the TLB as we do right now when
>> > invalidating the whole VPID.
>>
>> But then what architectural behavior do you see broken? Flushing
>> more than is required is always permitted. (And again - I'm all for
>> improvements here, we just need to be careful to not remove
>> flushing that is architecturally required.)
>>
>
> Global pages and PCID both are effectively disabled by this flush. And yes
> flushing more then the minimum necessary is permitted, but this seems rather
> excessive. It won't break (sane) applications but would slow things down for
> ones that optimize TLB usage. I'll do an experiment to check your hypothesis
> about no TLB flush being performed by the CPU if cpu-based load exiting is
> enabled. Should be rather easy to break applications that use the same
> virtual address if this is the case and we don't flush in Xen. Will report
> back on the results.
>

So I verified that when CPU-based load exiting is enabled, the TLB
flush here is critical. Without it the guest kernel crashes at random
points during boot. OTOH why does Xen trap every guest CR3 update
unconditionally? While we have features such as the vm_event/monitor
that may choose to subscribe to that event, Xen traps it even when
that is not in use. Is that trapping necessary for something else?

Tamas

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

Re: [Xen-devel] [PATCH v6 08/15] x86/efi: create new early memory allocator

[Julien Grall]

Hi Daniel,

On 22/09/16 13:07, Daniel Kiper wrote:

On Thu, Sep 22, 2016 at 05:25:46AM -0600, Jan Beulich wrote:

On 22.09.16 at 12:52,  wrote:

On Wed, Sep 21, 2016 at 03:42:09AM -0600, Jan Beulich wrote:

On 20.09.16 at 20:45,  wrote:

On Tue, Sep 20, 2016 at 07:46:56AM -0600, Jan Beulich wrote:

On 20.09.16 at 12:52,  wrote:


[...]


Do you suggest that I should move out of #ifndef CONFIG_ARM all ebmalloc

stuff

except free_ebmalloc_unused_mem(). Even if it is not used on ARM right

now?


That's not the static function, is it? The function you name should
actually be called on ARM too (as I did point out elsewhere already),
just to not leave a trap open for someone to fall into when (s)he
adds a first use of the allocator on ARM.


Well, I think that sane person doing that would analyze how ebmalloc works
on x86 and then move (align to ARM needs if required) all its machinery
(including free_ebmalloc_unused_mem()) to run on ARM. At least I would do
that. This way he/she would avoid issues mentioned by you. However, if you
still prefer your way I can do that. Though I am not sure about the rest of
ebmalloc stuff. Should I move it out of #ifndef CONFIG_ARM? Looking at your
earlier replies I see that yes. Am I correct?


Yes.


This does not work because if I build Xen for ARM then I got:
boot.c:589:21: error: 'ebmalloc' defined but not used
[-Werror=unused-function]
 static void __init *ebmalloc(size_t size)


Quote from an earlier reply of mine:

  Arguably the one static function may better be, as other
  workarounds to avoid the "unused" compiler warning wouldn't
  be any better.

and then later

  You misunderstood - I said that for this one (unused) static
  function such an #ifdef is probably okay, as the presumably
  smallest possible workaround.

I really have no idea what else to say.


Sorry, however, sometimes it is very difficult to understand what are
you referring to. If you could be more specific then I will be happy.

Anyway, now it looks that you wish something like that:

#ifndef CONFIG_ARM
/* Whole x86 ebmalloc stuff. */
...
#else
void __init free_ebmalloc_unused_mem(void)
{
}
#endif

and then call free_ebmalloc_unused_mem() from e.g.
xen/arch/arm/setup.c:init_done(). Am I right?


Bear in mind that the EFI loader on ARM is standalone. It cannot 
interact with Xen.


The main goal of the EFI stub is to load the different images on the 
memory and then will jump at the same starting point as when Xen is 
loaded without EFI. So anything in bss will be zeroed.


Regards,

--
Julien Grall

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

Re: [Xen-devel] [RFC 0/5] xen/arm: support big.little SoC

[Dario Faggioli]

On Thu, 2016-09-22 at 12:24 +0100, Julien Grall wrote:
> On 22/09/16 09:43, Dario Faggioli wrote:
> > Local migration basically --from the vcpu perspective-- means
> > create a
> > new vcpu, stop the original vcpu, copy the state from original to
> > new,
> > destroy the original vcpu and start the new one. My point is that
> > this
> > is not something that can be done within nor initiated by the
> > scheduler, e.g., during a context switch or a vcpu wakeup!
> 
> By local migration, I meant from the perspective of the hypervisor.
> In 
> the hypervisor you have to trap feature registers and other 
> implementation defined registers to show the same value across all
> the 
> physical CPUs.
> 
You mean we trap feature registers during the (normal) execution of a
vcpu, because we want Xen to vet what's returned to the guest itself.
And that migration support, and hence the possibility that the guest
have been migrated to a cpu different than the one where it was
created, is already one of the reasons why this is necessary... right?

If yes, and if that's "all" we need, I think it should be fine.

> You don't need to recreate the vCPU every time you move from one set
> of 
> CPUs to another one. Sorry for the confusion.
> 
No, I am sorry... it's not you that you're making confusion, it's
probably me knowing to few about ARM, and did not think at the above
when you said "migration". :-)

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)

signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [ovmf baseline-only test] 67744: all pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 67744 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67744/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 5919a9600e07b4700b54a5b47ae3991aad0e883c
baseline version:
 ovmf 7419aedd93132f2dfc91e7bf3634fba7e0842c7b

Last test of basis67741  2016-09-21 20:18:01 Z0 days
Testing same since67744  2016-09-22 06:47:21 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Feng Tian 
  Jeff Fan 
  Jiewen Yao 
  Qin Long 
  Star Zeng 

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



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

Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs

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


Push not applicable.


commit 5919a9600e07b4700b54a5b47ae3991aad0e883c
Author: Jiewen Yao 
Date:   Wed Sep 14 16:54:50 2016 +0800

SecurityPkg/TPM2: Sync PcrAllocations and PcrMask

Current TCG2 implementation will set Tpm2HashMask PCD value according to 
TPM2
PCR bank. However, there might be misconfiguration in BIOS build phase.
The enhanced logic makes sure that the current PCR allocations, the TPM
supported PCRs, and the PcdTpm2HashMask are all in agreement.

Cc: Chao B Zhang 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao 
Reviewed-by: Star Zeng 
Reviewed-by: Chao Zhang 

commit 07cdba18cd974d818556d752facfbf35a8d0f012
Author: Jiewen Yao 
Date:   Wed Sep 14 16:28:12 2016 +0800

SecurityPkg/TPM2: Extract GetSupportedAndActivePcrs to Tpm2CommandLib

This patch extracts function Tpm2GetCapabilitySupportedAndActivePcrs()
from drivers and also update Tcg2ExecutePhysicalPresence() to call
Tpm2GetCapabilitySupportedAndActivePcrs() instead of
Tcg2Protocol->GetCapability to query the TPM to determine which
hashing algorithms are supported.

Cc: Chao B Zhang 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao 
Signed-off-by: Star Zeng 
Reviewed-by: Chao Zhang 

commit f5e34e37e018034bc8ce7a2fb9ecb176d948b143
Author: Jiewen Yao 
Date:   Wed Sep 14 10:45:19 2016 +0800

SecurityPkg/TPM2: Move CopyDigestListToBuffer() to Tpm2CommandLib

This patch just moves function CopyDigestListToBuffer() from
drivers to library with HashAlgorithmMask parameter added to
make the interface more applicable.

The related function IsHashAlgSupportedInHashAlgorithmMask()
is also moved from drivers to library as internal function.

Cc: Chao B Zhang 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao 
Signed-off-by: Star Zeng 
Reviewed-by: Chao Zhang 

commit 77e55cf4e283942766d6178eca375aeec055bff2
Author: Jiewen Yao 
Date:   Wed Sep 14 10:07:45 2016 +0800

SecurityPkg/TPM2: Move GetDigestListSize() to Tpm2CommandLib

This patch just moves function GetDigestListSize() from
drivers to library and no functionality change.

Cc: Chao B Zhang 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao 
Signed-off-by: Star Zeng 
Reviewed-by: Chao Zhang 

commit f28ab8494664411ac9b3ec22b82d714d8a3ca4c1
Author: Star Zeng 
Date:   Tue Sep 13 

Re: [Xen-devel] [RFC 0/5] xen/arm: support big.little SoC

[Dario Faggioli]

On Thu, 2016-09-22 at 18:05 +0800, Peng Fan wrote:
> On Thu, Sep 22, 2016 at 10:50:23AM +0200, Dario Faggioli wrote:
> > Yes (or I should say, "whatever", as I know nothing about all
> > this! :-P)
> 
> One more thing I'd like to ask, do you prefer cpu classes to be ARM
> specific or ARM/X86
> common?
> 
I'm not sure. I'd say that it depends on where we are. I mean, in Xen,
names can be rather specific, like some codename of the
chip/core/family/etc.

I'm not sure what this means for you, on ARM, but I guess it would
depend on what you, Julien and Stefano will come up and agree on.

Then, at the toolstack level (xl and libxl) we can have aliases for the
various classes, and/or names for specific group of classes, arranged
according whatever criteria.

I also like George's idea of allowing to pick a class by its order in
the hypervisor hierarchy, if/as soon as we'll put classes in a
hierarchy withing the hypervisor.

But I'd like to hear others... In the meanwhile, if I were you, I'd
start with either "class 0", "class 1", etc., or just use the codename
of the chip ("A17, "A15", etc.)

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)

signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v6 1/4] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server.

[Yu Zhang]

On 9/22/2016 7:32 PM, George Dunlap wrote:

On Thu, Sep 22, 2016 at 10:12 AM, Yu Zhang  wrote:


On 9/21/2016 9:04 PM, George Dunlap wrote:

On Fri, Sep 9, 2016 at 6:51 AM, Yu Zhang 
wrote:

On 9/2/2016 6:47 PM, Yu Zhang wrote:

A new HVMOP - HVMOP_map_mem_type_to_ioreq_server, is added to
let one ioreq server claim/disclaim its responsibility for the
handling of guest pages with p2m type p2m_ioreq_server. Users
of this HVMOP can specify which kind of operation is supposed
to be emulated in a parameter named flags. Currently, this HVMOP
only support the emulation of write operations. And it can be
further extended to support the emulation of read ones if an
ioreq server has such requirement in the future.

For now, we only support one ioreq server for this p2m type, so
once an ioreq server has claimed its ownership, subsequent calls
of the HVMOP_map_mem_type_to_ioreq_server will fail. Users can also
disclaim the ownership of guest ram pages with p2m_ioreq_server, by
triggering this new HVMOP, with ioreq server id set to the current
owner's and flags parameter set to 0.

Note both HVMOP_map_mem_type_to_ioreq_server and p2m_ioreq_server
are only supported for HVMs with HAP enabled.

Also note that only after one ioreq server claims its ownership
of p2m_ioreq_server, will the p2m type change to p2m_ioreq_server
be allowed.

Signed-off-by: Paul Durrant 
Signed-off-by: Yu Zhang 
Acked-by: Tim Deegan 
---
Cc: Paul Durrant 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Jun Nakajima 
Cc: Kevin Tian 
Cc: Tim Deegan 

changes in v6:
 - Clarify logic in hvmemul_do_io().
 - Use recursive lock for ioreq server lock.
 - Remove debug print when mapping ioreq server.
 - Clarify code in ept_p2m_type_to_flags() for consistency.
 - Remove definition of P2M_IOREQ_HANDLE_WRITE_ACCESS.
 - Add comments for HVMMEM_ioreq_server to note only changes
   to/from HVMMEM_ram_rw are permitted.
 - Add domain_pause/unpause() in hvm_map_mem_type_to_ioreq_server()
   to avoid the race condition when a vm exit happens on a write-
   protected page, just to find the ioreq server has been unmapped
   already.
 - Introduce a seperate patch to delay the release of p2m
   lock to avoid the race condition.
 - Introduce a seperate patch to handle the read-modify-write
   operations on a write protected page.


Why do we need to do this?  Won't the default case just DTRT if it finds
that the ioreq server has been unmapped?


Well, patch 4 will either mark the remaining p2m_ioreq_server entries as
"recal" or
reset to p2m_ram_rw directly. So my understanding is that we do not wish
to
see a ept violation due to a p2m_ioreq_server access after the ioreq
server
is unmapped.
Yet without this domain_pause/unpause() pair, VM accesses may trigger an
ept
violation
during the hvmop hypercall(hvm_map_mem_type_to_ioreq_server), just to
find
the ioreq
server is NULL. Then we would have to provide handlers which just do the
copy to/from
actions for the VM. This seems awkward to me.

So the race you're worried about is this:

1. Guest fault happens
2. ioreq server calls map_mem_type_to_ioreq_server, unhooking
3. guest  finds no ioreq server present

I think in that case the easiest thing to do would be to simply assume
there was a race and re-execute the instruction.  Is that not possible
for some reason?

   -George


Thanks for your reply, George. :)
Two reasons I'd like to use the domain_pause/unpause() to avoid the race
condition:

1>  Like my previous explanation, in the read-modify-write scenario, the
ioreq server will
be NULL for the read emulation. But in such case, hypervisor will not
discard this trap, instead
it is supposed to do the copy work for the read access. So it would be
difficult for hypervisor
to decide if the ioreq server was detached due to a race condition, or if
the ioreq server should
be a NULL because we are emulating a read operation first for a
read-modify-write instruction.

Wouldn't a patch like the attached work (applied on top of the whole series)?


Thanks for your patch, George. I think it should work for 1>. But we 
still have the dead lock

problem.  :)

BTW, do you think a domain_pause will cause any new problem?

B.R.
Yu


  -George


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



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

Re: [Xen-devel] [PATCH v4 20/21] libxl/acpi: Build ACPI tables for HVMlite guests

[Wei Liu]

On Thu, Sep 22, 2016 at 11:57:18AM -0400, Boris Ostrovsky wrote:
> On 09/22/2016 06:53 AM, Wei Liu wrote:
> >
> >> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> >> index 90427ff..336358c 100644
> >> --- a/tools/libxl/Makefile
> >> +++ b/tools/libxl/Makefile
> >> @@ -75,7 +75,21 @@ else
> >>  LIBXL_OBJS-y += libxl_no_colo.o
> >>  endif
> >>  
> >> -LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o libxl_psr.o
> >> +ACPI_PATH  = $(XEN_ROOT)/tools/libacpi
> >> +ACPI_FILES = dsdt_pvh.c
> >> +ACPI_OBJS  = $(patsubst %.c,%.o,$(ACPI_FILES)) build.o static_tables.o
> >> +$(ACPI_FILES): acpi
> >> +$(ACPI_OBJS): CFLAGS += -I. 
> >> -DLIBACPI_STDUTILS=\"$(CURDIR)/libxl_x86_acpi.h\"
> >> +vpath build.c $(ACPI_PATH)/
> >> +vpath static_tables.c $(ACPI_PATH)/
> >> +LIBXL_OBJS-$(CONFIG_X86) += $(ACPI_OBJS)
> >> +
> >> +.PHONY: acpi
> >> +acpi:
> >> +  $(MAKE) -C $(ACPI_PATH) ACPI_BUILD_DIR=$(CURDIR)
> >> +-include acpi
> > Useless include?
> 
> Hmm... I thought there was a reason I put this here but I can't remember
> now.
> 
> >
> >> +
> >> +static uint8_t acpi_lapic_id(unsigned cpu)
> >> +{
> >> +return cpu * 2;
> > Is this in accordance with hardware spec?
> 
> That's how we (Xen) encode APIC IDs for guests.  For example, see
> vlapic_reset().
> 

OK.

> >> +
> >> +int libxl__dom_load_acpi(libxl__gc *gc,
> >> + const libxl_domain_build_info *b_info,
> >> + struct xc_dom_image *dom)
> >> +{
> >> +struct acpi_config config = {0};
> >> +struct libxl_acpi_ctxt libxl_ctxt;
> >> +int rc, acpi_pages_num;
> >> +void *acpi_pages;
> >> +unsigned long page_mask;
> >> +
> >> +if ((b_info->type != LIBXL_DOMAIN_TYPE_HVM) ||
> >> +(b_info->device_model_version != LIBXL_DEVICE_MODEL_VERSION_NONE))
> >> +return 0;
> > Please don't use mixed-style error handling.
> 
> Not sure I understand what you are asking for. You want 'return rc'? Or
> 'goto out'?
> 

goto out please.

> -boris
> 

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

Re: [Xen-devel] [PATCH v4 20/21] libxl/acpi: Build ACPI tables for HVMlite guests

[Boris Ostrovsky]

On 09/22/2016 06:53 AM, Wei Liu wrote:
>
>> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
>> index 90427ff..336358c 100644
>> --- a/tools/libxl/Makefile
>> +++ b/tools/libxl/Makefile
>> @@ -75,7 +75,21 @@ else
>>  LIBXL_OBJS-y += libxl_no_colo.o
>>  endif
>>  
>> -LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o libxl_psr.o
>> +ACPI_PATH  = $(XEN_ROOT)/tools/libacpi
>> +ACPI_FILES = dsdt_pvh.c
>> +ACPI_OBJS  = $(patsubst %.c,%.o,$(ACPI_FILES)) build.o static_tables.o
>> +$(ACPI_FILES): acpi
>> +$(ACPI_OBJS): CFLAGS += -I. 
>> -DLIBACPI_STDUTILS=\"$(CURDIR)/libxl_x86_acpi.h\"
>> +vpath build.c $(ACPI_PATH)/
>> +vpath static_tables.c $(ACPI_PATH)/
>> +LIBXL_OBJS-$(CONFIG_X86) += $(ACPI_OBJS)
>> +
>> +.PHONY: acpi
>> +acpi:
>> +$(MAKE) -C $(ACPI_PATH) ACPI_BUILD_DIR=$(CURDIR)
>> +-include acpi
> Useless include?

Hmm... I thought there was a reason I put this here but I can't remember
now.

>
>> +
>> +static uint8_t acpi_lapic_id(unsigned cpu)
>> +{
>> +return cpu * 2;
> Is this in accordance with hardware spec?

That's how we (Xen) encode APIC IDs for guests.  For example, see
vlapic_reset().

>> +
>> +int libxl__dom_load_acpi(libxl__gc *gc,
>> + const libxl_domain_build_info *b_info,
>> + struct xc_dom_image *dom)
>> +{
>> +struct acpi_config config = {0};
>> +struct libxl_acpi_ctxt libxl_ctxt;
>> +int rc, acpi_pages_num;
>> +void *acpi_pages;
>> +unsigned long page_mask;
>> +
>> +if ((b_info->type != LIBXL_DOMAIN_TYPE_HVM) ||
>> +(b_info->device_model_version != LIBXL_DEVICE_MODEL_VERSION_NONE))
>> +return 0;
> Please don't use mixed-style error handling.

Not sure I understand what you are asking for. You want 'return rc'? Or
'goto out'?

-boris


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

[Xen-devel] [distros-debian-wheezy test] 67745: all pass

[Platform Team regression test user]

flight 67745 distros-debian-wheezy real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67745/

Perfect :-)
All tests in this flight passed as required
baseline version:
 flight   67716

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-wheezy-netboot-pvgrub pass
 test-amd64-i386-i386-wheezy-netboot-pvgrub   pass
 test-amd64-i386-amd64-wheezy-netboot-pygrub  pass
 test-amd64-amd64-i386-wheezy-netboot-pygrub  pass



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

Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs

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


Push not applicable.


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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 7f1bf51bdbcaf9dd46f77cf4bd5e69a294dd995e
baseline version:
 ovmf 5919a9600e07b4700b54a5b47ae3991aad0e883c

Last test of basis   101085  2016-09-21 20:29:57 Z0 days
Testing same since   101097  2016-09-22 06:49:50 Z0 days1 attempts


People who touched revisions under test:
  Dandan Bi 
  Laszlo Ersek 

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



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=7f1bf51bdbcaf9dd46f77cf4bd5e69a294dd995e
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
7f1bf51bdbcaf9dd46f77cf4bd5e69a294dd995e
+ branch=ovmf
+ revision=7f1bf51bdbcaf9dd46f77cf4bd5e69a294dd995e
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' x7f1bf51bdbcaf9dd46f77cf4bd5e69a294dd995e = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git

Re: [Xen-devel] [PATCH] Xen/timer: Disable watchdog during dumping timer queues

[Jan Beulich]

>>> On 22.09.16 at 17:04,  wrote:
> On 9/22/2016 10:26 PM, Jan Beulich wrote:
 But please also answer the earlier question, which you did strip
 >> from your reply:
 >>
> >>> Which btw raises another question: Why are you in polling mode in
> >>> the first place? Do you have a UART without working interrupt?
>>> >
>>> > I found there was no interrupt with Xen ns16550 dirver while
>>> > linux kernel's serial driver can receive interrupt.
>> And do you know the reason? Is it perhaps a PCI plug in card, and
>> you don't specify the IRQ on the command line? Or the kernel
>> doesn't provide the necessary information (from ACPI) for Xen to
>> set up that IRQ?
> 
> No, I am not familiar serial device. But it's a ACPI device from linux
> sysfs node and serial drivers use irq 4 for their interrupt both on
> linux and Xen.

Hmm - I do not see why IRQ4 would not work, especially if it does
under Linux.

Jan


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

Re: [Xen-devel] [PATCH v5 02/16] arm/x86/common: Add HAS_[ALTERNATIVE|EX_TABLE]

[Ross Lagerwall]

On 09/21/2016 06:32 PM, Konrad Rzeszutek Wilk wrote:

x86 implements all of them by default - and we just
add two extra HAS_ variables to be declared in autoconf.h.

ARM 64 only has alternative while ARM 32 has none of them.

And while at it change the livepatch common code that
would benefit from this.

Acked-by: Jan Beulich  [relevant parts]
Suggested-by: Julien Grall 
Signed-off-by: Konrad Rzeszutek Wilk 



Reviewed-by: Ross Lagerwall 

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

Re: [Xen-devel] [PATCH V3] xen/arm: domain_build: allocate lowmem for dom0 as much as possible

[Julien Grall]

Hello Peng,

On 22/09/16 10:16, Peng Fan wrote:

On AArch64 SoCs, some IPs may only have the capability to access
32 bits address space. The physical memory assigned for Dom0 maybe
not in 4GB address space, then the IPs will not work properly.
So need to allocate memory under 4GB for Dom0.

There is no restriction that how much lowmem needs to be allocated for
Dom0. Dom0 now use 1:1 mapping, but DomU does not use 1:1 mapping,
there is no need to reserve lowmem for DomU, so allocate lowmem as much
as possible for Dom0.


The last sentence is confusing. I would avoid to mention domU use case here.



This patch does not affect 32-bit domain, because Variable "lowmem" is
set to true at the beginning. If failed to allocate bank0 under 4GB,
need to panic for 32-bit domain, because 32-bit domain requires bank0
be allocated under 4GB.

For 64-bit domain, set "lowmem" to false, and continue allocating
memory from higher memory space.

Signed-off-by: Peng Fan 
Cc: Stefano Stabellini 
Cc: Julien Grall 
---

This patch is to resolve the issue mentioned in
https://lists.xen.org/archives/html/xen-devel/2016-09/msg00235.html

V3:
 Add more commit log
 Add more comments
 Add back panic if failed to allocate bank0 under 4GB for 32-bit domain.

V2:
 Remove the bootargs dom0_lowmem introduced in V1.
 Following 
"https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg01459.html;
 to allocate as much as possible lowmem.

 Tested results:
 (XEN) Allocating 1:1 mappings totalling 2048MB for dom0:
 (XEN) BANK[0] 0x008800-0x00f800 (1792MB)
 (XEN) BANK[1] 0x09e000-0x09f000 (256MB)
 1792M allocated in 4GB address space.

 xen/arch/arm/domain_build.c | 44 +++-
 1 file changed, 31 insertions(+), 13 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 35ab08d..a9c37c4 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -195,9 +195,10 @@ fail:
  *bank. Partly this is just easier for us to deal with, but also
  *the ramdisk and DTB must be placed within a certain proximity of
  *the kernel within RAM.
- * 3. For 32-bit dom0 we want to place as much of the RAM as we
- *reasonably can below 4GB, so that it can be used by non-LPAE
- *enabled kernels.
+ * 3. For dom0 we want to place as much of the RAM as we reasonably can
+ *below 4GB, so that the devices have the limitation to access 64 bits
+ *address space and work properly and it can be used by non-LPAE enabled
+ *kernels.


I would say: "For dom0 we want to place as much of the RAM as we 
reasonably can below 4GB, so that it can be used by non-LPAE enabled 
kernels (32-bit) or when a device assigned to dom0 can only do 32-bit 
DMA access".



  * 4. For 32-bit dom0 the kernel must be located below 4GB.
  * 5. We want to have a few largers banks rather than many smaller ones.
  *
@@ -230,7 +231,8 @@ fail:
  * we give up.
  *
  * For 32-bit domain we require that the initial allocation for the
- * first bank is under 4G. Then for the subsequent allocations we
+ * first bank is under 4G. For 64-bit domain, the first bank is preferred
+ * to be allocated under 4G. Then for the subsequent allocations we
  * initially allocate memory only from below 4GB. Once that runs out
  * (as described above) we allow higher allocations and continue until
  * that runs out (or we have allocated sufficient dom0 memory).
@@ -240,11 +242,11 @@ static void allocate_memory(struct domain *d, struct 
kernel_info *kinfo)
 const unsigned int min_low_order =
 get_order_from_bytes(min_t(paddr_t, dom0_mem, MB(128)));
 const unsigned int min_order = get_order_from_bytes(MB(4));
-struct page_info *pg;
+struct page_info *pg = NULL;
 unsigned int order = get_11_allocation_size(kinfo->unassigned_mem);
 int i;

-bool_t lowmem = is_32bit_domain(d);
+bool_t lowmem = true;
 unsigned int bits;

 /*
@@ -265,24 +267,40 @@ static void allocate_memory(struct domain *d, struct 
kernel_info *kinfo)
  */
 while ( order >= min_low_order )
 {
-for ( bits = order ; bits <= (lowmem ? 32 : PADDR_BITS); bits++ )
+for ( bits = order ; bits <= 32 ; bits++ )


Why this change? If we ever decide to set lowmen to false, it will not 
work anymore.



 {
 pg = alloc_domheap_pages(d, order, MEMF_bits(bits));
 if ( pg != NULL )
+{
+if ( !insert_11_bank(d, kinfo, pg, order) )
+BUG(); /* Cannot fail for first bank */
+
 goto got_bank0;
+   }


The indentation looks wrong here.


 }
 order--;
 }

-panic("Unable to allocate first memory bank");
-
- got_bank0:
+/* Failed to allocate bank0 under 4GB */
+if ( pg == NULL )


This check is not necessary because you can only be here when (pg == NULL).


+

[Xen-devel] [xen-4.6-testing baseline-only test] 67743: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 67743 xen-4.6-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67743/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-i386-pvgrub 10 guest-start  fail   like 67734
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 67734
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 67734
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 67734
 test-amd64-amd64-xl-qemut-winxpsp3  9 windows-install  fail like 67734
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 67734

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-3   19 xtf/test-hvm32-invlpg~shadow fail   never pass
 test-xtf-amd64-amd64-3  26 xtf/test-hvm32pae-invlpg~shadow fail never pass
 test-xtf-amd64-amd64-3   34 xtf/test-hvm64-invlpg~shadow fail   never pass
 build-amd64-rumprun   5 rumprun-buildfail   never pass
 build-i386-rumprun5 rumprun-buildfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-xtf-amd64-amd64-1   19 xtf/test-hvm32-invlpg~shadow fail   never pass
 test-xtf-amd64-amd64-1  26 xtf/test-hvm32pae-invlpg~shadow fail never pass
 test-xtf-amd64-amd64-1   34 xtf/test-hvm64-invlpg~shadow fail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass

version targeted for testing:
 xen  245fa11021f8f123a82aa7e894d044d8f0ae6923
baseline version:
 xen  57dbc55cd3e239ab0ce5bdd62cf309e27fe52a1a

Last test of basis67734  2016-09-20 15:45:31 Z1 days
Testing same since67743  2016-09-22 02:17:23 Z0 days1 attempts


People who touched revisions under test:
  Ian Jackson 

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

Re: [Xen-devel] [PATCH] Xen/timer: Disable watchdog during dumping timer queues

[Lan, Tianyu]

On 9/22/2016 10:26 PM, Jan Beulich wrote:

But please also answer the earlier question, which you did strip
>> from your reply:
>>

>>> Which btw raises another question: Why are you in polling mode in
>>> the first place? Do you have a UART without working interrupt?

>
> I found there was no interrupt with Xen ns16550 dirver while
> linux kernel's serial driver can receive interrupt.

And do you know the reason? Is it perhaps a PCI plug in card, and
you don't specify the IRQ on the command line? Or the kernel
doesn't provide the necessary information (from ACPI) for Xen to
set up that IRQ?


No, I am not familiar serial device. But it's a ACPI device from linux
sysfs node and serial drivers use irq 4 for their interrupt both on
linux and Xen.

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

Re: [Xen-devel] [PATCH v6 14/16] public/hvm/params.h: Add macros for HVM_PARAM_CALLBACK_TYPE_PPI

[Jan Beulich]

>>> On 22.09.16 at 14:52,  wrote:
> From: Shannon Zhao 
> 
> Add macros for HVM_PARAM_CALLBACK_TYPE_PPI operation values and update
> them in evtchn_fixup().
> 
> Also use HVM_PARAM_CALLBACK_IRQ_TYPE_MASK in hvm_set_callback_via().
> 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> Signed-off-by: Shannon Zhao 
> ---
>  xen/arch/arm/domain_build.c | 9 ++---
>  xen/arch/x86/hvm/irq.c  | 2 +-
>  xen/include/public/hvm/params.h | 3 +++
>  3 files changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 35ab08d..0cf7dc3 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -2016,9 +2016,12 @@ static void evtchn_fixup(struct domain *d, struct 
> kernel_info *kinfo)
> d->arch.evtchn_irq);
>  
>  /* Set the value of domain param HVM_PARAM_CALLBACK_IRQ */
> -val = (u64)HVM_PARAM_CALLBACK_TYPE_PPI << 56;
> -val |= (2 << 8); /* Active-low level-sensitive  */
> -val |= d->arch.evtchn_irq & 0xff;
> +val = MASK_INSR(HVM_PARAM_CALLBACK_TYPE_PPI,
> +HVM_PARAM_CALLBACK_IRQ_TYPE_MASK);
> +/* Active-low level-sensitive  */
> +val |= MASK_INSR(HVM_PARAM_CALLBACK_TYPE_PPI_FLAG_LOW_LEVEL,
> + HVM_PARAM_CALLBACK_TYPE_PPI_FLAG_MASK);
> +val |= d->arch.evtchn_irq;
>  d->arch.hvm_domain.params[HVM_PARAM_CALLBACK_IRQ] = val;
>  
>  /*
> diff --git a/xen/arch/x86/hvm/irq.c b/xen/arch/x86/hvm/irq.c
> index 5323d7c..e597114 100644
> --- a/xen/arch/x86/hvm/irq.c
> +++ b/xen/arch/x86/hvm/irq.c
> @@ -325,7 +325,7 @@ void hvm_set_callback_via(struct domain *d, uint64_t via)
>  unsigned int gsi=0, pdev=0, pintx=0;
>  uint8_t via_type;
>  
> -via_type = (uint8_t)(via >> 56) + 1;
> +via_type = (uint8_t)MASK_EXTR(via, HVM_PARAM_CALLBACK_IRQ_TYPE_MASK) + 
> 1;
>  if ( ((via_type == HVMIRQ_callback_gsi) && (via == 0)) ||
>   (via_type > HVMIRQ_callback_vector) )
>  via_type = HVMIRQ_callback_none;
> diff --git a/xen/include/public/hvm/params.h b/xen/include/public/hvm/params.h
> index f7338a3..5c50e2e 100644
> --- a/xen/include/public/hvm/params.h
> +++ b/xen/include/public/hvm/params.h
> @@ -30,6 +30,7 @@
>   */
>  
>  #define HVM_PARAM_CALLBACK_IRQ 0
> +#define HVM_PARAM_CALLBACK_IRQ_TYPE_MASK 0xFF00

I'd be surprised if this goes through on all compiler versions: This
is a constant which needs at least a UL suffix (and if intended to
be usable on 32-bit even a ULL one, which would then get us into
complications with there not being supposed to be any non-C89
constructs in the public headers).

Jan


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

Re: [Xen-devel] [PATCH v6 14/16] public/hvm/params.h: Add macros for HVM_PARAM_CALLBACK_TYPE_PPI

[Julien Grall]

Hi Shannon,

On 22/09/16 13:52, z00226004 wrote:

From: Shannon Zhao 

Add macros for HVM_PARAM_CALLBACK_TYPE_PPI operation values and update
them in evtchn_fixup().

Also use HVM_PARAM_CALLBACK_IRQ_TYPE_MASK in hvm_set_callback_via().

Cc: Jan Beulich 
Cc: Andrew Cooper 
Signed-off-by: Shannon Zhao 


Providing Jan's comments have been addressed (I will let Jan confirm):

Acked-by: Julien Grall 

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v6 16/16] libxl/arm: Add the size of ACPI tables to maxmem

[Wei Liu]

On Thu, Sep 22, 2016 at 03:10:46PM +0100, Wei Liu wrote:
> On Thu, Sep 22, 2016 at 08:52:33PM +0800, z00226004 wrote:
> > From: Shannon Zhao 
> > 
> > Here it adds the ACPI tables size to set the target maxmem to avoid
> > providing less available memory for guest.
> > 
> > Signed-off-by: Shannon Zhao 
> > ---
> >  tools/libxl/libxl_arch.h|  4 
> >  tools/libxl/libxl_arm.c | 16 
> >  tools/libxl/libxl_arm.h |  4 
> >  tools/libxl/libxl_arm_acpi.c| 20 
> >  tools/libxl/libxl_arm_no_acpi.c |  6 ++
> >  tools/libxl/libxl_dom.c |  9 -
> >  tools/libxl/libxl_internal.h|  2 ++
> >  tools/libxl/libxl_x86.c |  6 ++
> >  8 files changed, 66 insertions(+), 1 deletion(-)
> > 
> > diff --git a/tools/libxl/libxl_arch.h b/tools/libxl/libxl_arch.h
> > index 8cb9ba7..a066bbd 100644
> > --- a/tools/libxl/libxl_arch.h
> > +++ b/tools/libxl/libxl_arch.h
> > @@ -66,6 +66,10 @@ _hidden
> >  void libxl__arch_domain_build_info_acpi_setdefault(
> >  libxl_domain_build_info *b_info);
> >  
> > +_hidden
> > +int libxl__arch_memory_constant(libxl__gc *gc, libxl_domain_build_info 
> > *info,
> > +libxl__domain_build_state *state);
> 
> I think the prototype should change a bit.
> 
> _hidden
> int libxl__arch_extra_memory(libxl__gc, *gc,
>  const libxl_domain_build_info *info,
>  const libxl__domain_build_state *state,
>  uint64_t *out);
> 
> The important bit is to not overload the return value to carry the
> output value.
> 
> > +
> >  #if defined(__i386__) || defined(__x86_64__)
> >  
> >  #define LAPIC_BASE_ADDRESS  0xfee0
> > diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
> > index 913f401..932e674 100644
> > --- a/tools/libxl/libxl_arm.c
> > +++ b/tools/libxl/libxl_arm.c
> > @@ -106,6 +106,22 @@ int libxl__arch_domain_create(libxl__gc *gc, 
> > libxl_domain_config *d_config,
> >  return 0;
> >  }
> >  
> > +int libxl__arch_memory_constant(libxl__gc *gc, libxl_domain_build_info 
> > *info,
> > +libxl__domain_build_state *state)
> > +{
> > +int size;
> > +
> > +if (libxl_defbool_val(info->acpi)) {
> > +size = libxl__get_acpi_size(gc, info, state);
> > +if (size < 0)
> > +return ERROR_FAIL;
> > +
> > +return DIV_ROUNDUP(size, 1024);
> > +}
> > +
> > +return 0;
> > +}
> > +
> >  static struct arch_info {
> >  const char *guest_type;
> >  const char *timer_compat;
> > diff --git a/tools/libxl/libxl_arm.h b/tools/libxl/libxl_arm.h
> > index a91ff93..37b1f15 100644
> > --- a/tools/libxl/libxl_arm.h
> > +++ b/tools/libxl/libxl_arm.h
> > @@ -24,6 +24,10 @@ int libxl__prepare_acpi(libxl__gc *gc, 
> > libxl_domain_build_info *info,
> >  libxl__domain_build_state *state,
> >  struct xc_dom_image *dom);
> >  
> > +_hidden
> > +int libxl__get_acpi_size(libxl__gc *gc, libxl_domain_build_info *info,
> > + libxl__domain_build_state *state);
> > +
> 
> Same here, don't overload the return value for output.
> 
> >  static inline uint64_t libxl__compute_mpdir(unsigned int cpuid)
> >  {
> >  /*
> > diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
> > index 9c4005f..0d4092d 100644
> > --- a/tools/libxl/libxl_arm_acpi.c
> > +++ b/tools/libxl/libxl_arm_acpi.c
> > @@ -94,6 +94,26 @@ static int libxl__estimate_madt_size(libxl__gc *gc,
> >  return rc;
> >  }
> >  
> > +int libxl__get_acpi_size(libxl__gc *gc, libxl_domain_build_info *info,
> > + libxl__domain_build_state *state)
> > +{
> > +int size;
> > +
> > +size = libxl__estimate_madt_size(gc, info, >config);
> > +if (size < 0)
> > +goto out;
> > +
> > +size = ROUNDUP(size, 3) +
> > +   ROUNDUP(sizeof(struct acpi_table_rsdp), 3) +
> > +   ROUNDUP(sizeof(struct acpi_table_xsdt), 3) +
> > +   ROUNDUP(sizeof(struct acpi_table_gtdt), 3) +
> > +   ROUNDUP(sizeof(struct acpi_table_fadt), 3) +
> > +   ROUNDUP(sizeof(dsdt_anycpu_arm_len), 3);
> > +
> > +out:
> > +return size;
> > +}
> > +
> >  static int libxl__estimate_acpi_size(libxl__gc *gc,
> >   libxl_domain_build_info *info,
> >   struct xc_dom_image *dom,
> > diff --git a/tools/libxl/libxl_arm_no_acpi.c 
> > b/tools/libxl/libxl_arm_no_acpi.c
> > index e7f7411..5eeb825 100644
> > --- a/tools/libxl/libxl_arm_no_acpi.c
> > +++ b/tools/libxl/libxl_arm_no_acpi.c
> > @@ -25,6 +25,12 @@ int libxl__prepare_acpi(libxl__gc *gc, 
> > libxl_domain_build_info *info,
> >  return ERROR_FAIL;
> >  }
> >  
> > +int libxl__get_acpi_size(libxl__gc *gc, libxl_domain_build_info *info,

Re: [Xen-devel] Fwd: Openindiana, using -machine pc, accel=xen in qemu

[jim burns]

Pls cc me with any replies.

On Thursday, 22 September 2016, 12:22:02 EDT, Anthony PERARD wrote:
> On Wed, Sep 21, 2016 at 06:20:16PM -0400, jim burns wrote:
> > I didn't get any responses in xen-users, so I'm posting here. My use case
> > is as below, but the jist of it is is the qemu option -machine
> > pc,accel=xen meant to be usable in standalone qemu, or is it only
> > available from a guest launched by xl, or libvirtd via libxl? If the
> > latter, are there any plans to make it available as a standalone qemu
> > option?
> 
> Hi,
> 
> -machine pc,accel=xen is to be used by libxl (used by xl or libvirt).
> libxl takes care of creating a guest and launch QEMU when needed.

That was quick. Thank you for your response. So there is no way to hook libxl 
from a standalone qemu option?

> There are some QEMU options to start a xen guest with standalone qemu,
> but I don't know if they works. Look for -xen-create. But I don't think
> that is what you would need.

Tried that, and -xen-attach - no effect.

> What is your xen config file for OI ?

name = "osol134"
uuid = "f80856df-3180-acc5-931d-32190cfe4062"
memory=2048
vcpus=4
localtime=1
on_poweroff = "destroy"
on_reboot = "destroy"
on_crash = "preserve"
#
boot="dc"
builder="hvm"
xen_platform_pci=0  # forces -machine pc,accel=xen
device_model_args=[ '-cpu','Haswell-noTSX' ]
#device_model_override='/usr/bin/qemu-system-x86_64'
#pvh=1
#viridian=1
#hdtype='ahci'
#device_model_stubdomain_override = 1 # using soundhw causes failure, can't 
use qxl
#kernel="/usr/lib/xen/boot/pv-grub-x86_32.gz" # upstream legacy grub doesn't 
understand zfs

## live cd installer

Disk = [ "file:/home/jimb/Documents/rpms/OI-hipster-
gui-20160421.iso,xvdc:cdrom,r", "phy:/dev/dm-2,xvda,w" ]
#bootloader="pygrub"
#bootloader_args=[ "--kernel=/home/jimb/hipster/unix","--ramdisk=/home/jimb/
hipster/boot_archive","--args='-B 
install_media=cdrom,console=ttya,livemode=text" ] #runtime
#kernel = "/home/jimb/hipster/unix" # the kernel and ramdisk are extracted 
from the install dvd, and are intended for a pv domain, which doesn't work
#ramdisk = "/home/jimb/hipster/boot_archive"
#extra = "/platform/i86pc/kernel/amd64/unix -B 
install_media=cdrom,console=ttya,livemode=vesa" #live cd istaller

# runtime

#disk = [ "phy:/dev/dm-2,xvda,w", "file:/home/jimb/Documents/rpms/OI-hipster-
gui-20160421.iso,xvdc:cdrom,r" ]
#disk = [ "format=raw,vdev=xvda,access=rw,target=/dev/dm-2", 
"format=raw,vdev=xvdc,access=ro,devtype=cdrom,target=/home/jimb/Documents/
rpms/OI-hipster-gui-20160421.iso" ]
#kernel = "/home/jimb/hipster/unix.install"
#ramdisk = "/home/jimb/hipster/boot_archive.install"
#extra = "/platform/i86pc/kernel/amd64/unix -B zfs-bootfs=rpool/ROOT/
openindiana-16,console=graphics" #runtime
##
vif = [ "mac=00:16:3e:72:da:33,bridge=virbr0,script=vif-bridge,model=e1000" ]
#vfb = [ "type=vnc,vncunused=1,vnclisten=0.0.0.0,keymap=en-us" ]
#vga="stdvga"
vga="qxl"
videoram=128
#soundhw='all' #causes hvm domain start failure
soundhw='sb16,es1370,ac97,adlib,gus,cs4231a'
monitor=1
#
sdl=0
vnc=1
#vncconsole=1
#vncviewer=1
vncpasswd=''
vncdisplay=3 # means use :0
vnclisten="0.0.0.0"
vncunused=0
keymap='en-us'
serial='pty'
usbdevice='mouse'
#
#spice
#vga='qxl' # can't use qemu-xen-traditional, supports (doesn't conflict with) 
ovmf bios
spice=1
spiceport=6080 
spicehost='0.0.0.0'
spicedisable_ticketing = 1 # default is 0 
spicedisable_copy_paste = 0
#spicepasswd = 'test'
spicevdagent=1
spice_clipboard_sharing=1
#spiceusbredirection=4
##soundhw="hda" #for spice, no stubdom, see below for other options


> Also, how do you start OI with KVM/tcg? (qemu command line)

This script has a number of options. I invoke it as 'bin/osol151' to boot 
normally from the hard disk. I can also boot from the dvd WHILE osol151 is 
running, by changing the connection ports, and invoking as 'bin/osol134'. This 
is to test various options with out disturbing my guest.

sock=spice.sock
vncport=0
spiceport=6070
if [ "`basename $0`" = "osol134" ]; then
  sock=spice.sock134
  vncport=3
  spiceport=6080
fi
#if libvirtd isn't working (after an update), I use xenbr0, else virbr0
netdev="tap,br=xenbr0,id=net0,script=no,downscript=no" #requires root
netdev="bridge,id=net0,br=virbr0"
#experimenting with sockets
Spice_opts="-device virtio-vga,virgl=on -spice unix,gl=on,addr=/run/user/1000/
$sock"
spice_opts="-device qxl-vga,vram_size_mb=64,ram_size_mb=64 -spice port=
$spiceport,tls-port=0,addr=127.0.0.1"
set -x
/usr/bin/qemu-system-x86_64 -nodefaults -name `basename $0` -localtime -vnc 
0.0.0.0:0,to=99 -display none $spice_opts,disable-ticketing,agent-mouse=on -
device virtio-serial -chardev spicevmc,id=vdagent,name=vdagent -device 
virtserialport,chardev=vdagent,name=com.redhat.spice.0 -k en-us -serial pty -
cpu Haswell-noTSX -machine pc,accel=xen:kvm:tcg,kernel_irqchip=on -m 3000 -
boot order=dc -usb -usbdevice mouse -soundhw 
sb16,es1370,ac97,adlib,gus,cs4231a -smp 4,maxcpus=4 -device 
e1000,id=nic0,netdev=net0,mac=00:16:3e:72:da:33 

[Xen-devel] [xen-4.5-testing test] 101088: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail REGR. vs. 
101045

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail in 101070 pass 
in 101088
 test-amd64-amd64-libvirt-vhd 13 guest-saverestore fail in 101070 pass in 101088
 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail in 101070 
pass in 101088
 test-amd64-i386-libvirt  14 guest-saverestore  fail pass in 101070
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail pass in 
101070
 test-amd64-i386-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail pass in 101070

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds   15 guest-start/debian.repeat fail blocked in 101045
 test-armhf-armhf-xl-rtds 11 guest-start fail in 101070 like 101045
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop  fail in 101070 like 101045
 test-amd64-amd64-xl-rtds  6 xen-boot fail  like 101045
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 101045
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101045
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101045

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 build-i386-rumprun5 rumprun-buildfail   never pass
 build-amd64-rumprun   5 rumprun-buildfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-qcow2 10 guest-start  fail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 10 guest-start  fail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-vhd  10 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass

version targeted for testing:
 xen  84e4e56aa643444f13686362535d8ca8a06839c6
baseline version:
 xen  e4ae4b03d35babc9624b7286f1ea4c6749bad84b

Last test of basis   101045  2016-09-20 12:58:05 Z2 days
Testing same since   101070  2016-09-21 02:03:18 Z1 days2 attempts


People who touched revisions under test:
  Ian Jackson 

jobs:
 build-amd64-xtf  pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 

Re: [Xen-devel] [PATCH] Xen/timer: Disable watchdog during dumping timer queues

[Jan Beulich]

>>> On 22.09.16 at 16:18,  wrote:
> On 9/21/2016 5:25 PM, Jan Beulich wrote:
> On 21.09.16 at 03:54,  wrote:
>>> On 2016年09月20日 23:36, Jan Beulich wrote:
> The precondition of process_pending_softirq() working in the debug key
>> handler is that timer interrupt arrives on time and nmi_timer_fn() can
>> run to update nmi_timer_ticks before watchdog timeout.
 Precondition?
>>>
>>> Process_pending_softirq() in debug key handler is mainly to deal with
>>> timer softirq to update nmi_timer_ticks in order to avoid NMI watchdog.
>>> If there is no timer interrupt arriving for long time,
>>> process_pending_softirq() here is meaningless and NMI watchdog still
>>> will be timeout.
>>
>> Oh, right. Still I continue to be unconvinced that disabling the
>> watchdog is the right answer (not running timers for a long time
>> has other undesirable consequence), or if it is, then it being
>> needed in only this one key handler. So perhaps you should
>> really consider submitting your generic key handler adjustment
>> as an alternative.
> 
> Disable watchdog is common solution for such kind of issues in current
> codes and so I chose it. I also proposed another solution in previous
> mail that run keyhandler always in a tasklet and insert
> process_pending_softirq() in the keyhandler.

Yes, that's the patch I've been referring to in my previous answer.

>> But please also answer the earlier question, which you did strip
>> from your reply:
>>
>>> Which btw raises another question: Why are you in polling mode in
>>> the first place? Do you have a UART without working interrupt?
> 
> I found there was no interrupt with Xen ns16550 dirver while
> linux kernel's serial driver can receive interrupt.

And do you know the reason? Is it perhaps a PCI plug in card, and
you don't specify the IRQ on the command line? Or the kernel
doesn't provide the necessary information (from ACPI) for Xen to
set up that IRQ?

Jan

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

Re: [Xen-devel] [PATCH v6 00/16] Xen ARM DomU ACPI support

[Julien Grall]

Hi Shannon,

On 22/09/16 13:52, z00226004 wrote:

From: Shannon Zhao 

The design of this feature is described as below.
Firstly, the toolstack (libxl) generates the ACPI tables according the
number of vcpus and gic controller.

Then, it copies these ACPI tables to DomU non-RAM memory map space and
passes them to UEFI firmware through the "ARM multiboot" protocol.

At last, UEFI gets the ACPI tables through the "ARM multiboot" protocol
and installs these tables like the usual way and passes both ACPI and DT
information to the Xen DomU.

Currently libxl only generates RSDP, XSDT, GTDT, MADT, FADT, DSDT tables
since it's enough now.

This has been tested using guest kernel with the Dom0 ACPI support
patches which could be fetched from linux master or:
https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/log/?h=efi/arm-xen

The UEFI binary could be fetched from or built from edk2 master branch:
http://people.linaro.org/~shannon.zhao/DomU_ACPI/XEN_EFI.fd

This series can be fetched from:
https://git.linaro.org/people/shannon.zhao/xen.git  domu_acpi_v6


I have tested this series with the latest kernel and UEFI and everything 
works for me:


Tested-by: Julien Grall 

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v6 13/16] libxl/arm: Add ACPI module

[Wei Liu]

On Thu, Sep 22, 2016 at 08:52:30PM +0800, z00226004 wrote:
> From: Shannon Zhao 
> 
> Add the ARM Multiboot module for ACPI, so UEFI or DomU can get the base
> address of ACPI tables from it.
> 
> Signed-off-by: Shannon Zhao 
> Acked-by: Julien Grall 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v6 04/16] libxl/arm: Estimate the size of ACPI tables

[Wei Liu]

On Thu, Sep 22, 2016 at 08:52:21PM +0800, z00226004 wrote:
> From: Shannon Zhao 
> 
> Estimate the size of ACPI tables and reserve a memory map space for ACPI
> tables.
> 
> Signed-off-by: Shannon Zhao 
> ---
>  tools/libxl/libxl_arm_acpi.c | 98 
> 
>  xen/include/acpi/actbl1.h|  2 +
>  2 files changed, 100 insertions(+)
> 
> diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
> index 0851411..1dbd7e5 100644
> --- a/tools/libxl/libxl_arm_acpi.c
> +++ b/tools/libxl/libxl_arm_acpi.c
> @@ -34,12 +34,108 @@ extern const unsigned char dsdt_anycpu_arm[];
>  _hidden
>  extern const int dsdt_anycpu_arm_len;
>  
> +enum {
> +RSDP,
> +XSDT,
> +GTDT,
> +MADT,
> +FADT,
> +DSDT,
> +NUMS,

NUMS is not a very good name. Maybe MAX_TABLE_NUMS or something?

Unfortunately I'm bad at naming things...

> +};
> +
> +struct acpitable {
> +uint64_t addr;
> +size_t size;
> +};
> +
> +static int libxl__estimate_madt_size(libxl__gc *gc,
> + libxl_domain_build_info *info,
> + xc_domain_configuration_t *xc_config)

Please try not to overload the return value for output. Use a dedicated
output parameter. And maybe constify things that you don't intend to
change in the function.

The rest looks reasonable to me.

Wei.

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

Re: [Xen-devel] [PATCH v6 05/16] libxl/arm: Construct ACPI RSDP table

[Wei Liu]

On Thu, Sep 22, 2016 at 08:52:22PM +0800, z00226004 wrote:
> From: Shannon Zhao 
> 
> Construct ACPI RSDP table and add a helper to calculate the ACPI table
> checksum.
> 
> Signed-off-by: Shannon Zhao 
> Acked-by: Julien Grall 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v6 09/16] libxl/arm: Construct ACPI MADT table

[Wei Liu]

On Thu, Sep 22, 2016 at 08:52:26PM +0800, z00226004 wrote:
> From: Shannon Zhao 
> 
> According to the GIC version, construct the MADT table.
> 
> Signed-off-by: Shannon Zhao 
> Acked-by: Julien Grall 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH] Xen/timer: Disable watchdog during dumping timer queues

[Lan Tianyu]

On 9/21/2016 5:25 PM, Jan Beulich wrote:

On 21.09.16 at 03:54,  wrote:

On 2016年09月20日 23:36, Jan Beulich wrote:

The precondition of process_pending_softirq() working in the debug key

handler is that timer interrupt arrives on time and nmi_timer_fn() can
run to update nmi_timer_ticks before watchdog timeout.

Precondition?


Process_pending_softirq() in debug key handler is mainly to deal with
timer softirq to update nmi_timer_ticks in order to avoid NMI watchdog.
If there is no timer interrupt arriving for long time,
process_pending_softirq() here is meaningless and NMI watchdog still
will be timeout.


Oh, right. Still I continue to be unconvinced that disabling the
watchdog is the right answer (not running timers for a long time
has other undesirable consequence), or if it is, then it being
needed in only this one key handler. So perhaps you should
really consider submitting your generic key handler adjustment
as an alternative.



Disable watchdog is common solution for such kind of issues in current
codes and so I chose it. I also proposed another solution in previous
mail that run keyhandler always in a tasklet and insert
process_pending_softirq() in the keyhandler.


But please also answer the earlier question, which you did strip
from your reply:


Which btw raises another question: Why are you in polling mode in
the first place? Do you have a UART without working interrupt?




I found there was no interrupt with Xen ns16550 dirver while
linux kernel's serial driver can receive interrupt.



Jan





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

Re: [Xen-devel] [PATCH v6 15/16] libxl/arm: Initialize domain param HVM_PARAM_CALLBACK_IRQ

[Wei Liu]

On Thu, Sep 22, 2016 at 08:52:32PM +0800, z00226004 wrote:
> From: Shannon Zhao 
> 
> The guest kernel will get the event channel interrupt information via
> domain param HVM_PARAM_CALLBACK_IRQ. Initialize it here.
> 
> Signed-off-by: Shannon Zhao 
> Acked-by: Julien Grall 

Acked-by: Wei Liu 

> ---
>  tools/libxl/libxl_arm.c  | 14 ++
>  tools/libxl/libxl_internal.h |  3 +++
>  2 files changed, 17 insertions(+)
> 
> diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
> index 6f0bc70..913f401 100644
> --- a/tools/libxl/libxl_arm.c
> +++ b/tools/libxl/libxl_arm.c
> @@ -900,8 +900,22 @@ int libxl__arch_domain_init_hw_description(libxl__gc *gc,
> struct xc_dom_image *dom)
>  {
>  int rc;
> +uint64_t val;
>  
>  assert(info->type == LIBXL_DOMAIN_TYPE_PV);
> +
> +/* Set the value of domain param HVM_PARAM_CALLBACK_IRQ. */
> +val = MASK_INSR(HVM_PARAM_CALLBACK_TYPE_PPI,
> +HVM_PARAM_CALLBACK_IRQ_TYPE_MASK);
> +/* Active-low level-sensitive  */
> +val |= MASK_INSR(HVM_PARAM_CALLBACK_TYPE_PPI_FLAG_LOW_LEVEL,
> + HVM_PARAM_CALLBACK_TYPE_PPI_FLAG_MASK);
> +val |= GUEST_EVTCHN_PPI;
> +rc = xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_CALLBACK_IRQ,
> +  val);
> +if (rc)
> +return rc;
> +
>  rc = libxl__prepare_dtb(gc, info, state, dom);
>  if (rc) goto out;
>  
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index f1ba473..cb6d9e0 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -128,6 +128,9 @@
>  #define ROUNDUP(_val, _order)   \
>  (((unsigned long)(_val)+(1UL<<(_order))-1) & ~((1UL<<(_order))-1))
>  
> +#define MASK_EXTR(v, m) (((v) & (m)) / ((m) & -(m)))
> +#define MASK_INSR(v, m) (((v) * ((m) & -(m))) & (m))
> +

Though I would have moved this to libxl_arm.c because the only user is
there, or at least give them less cryptic names.

>  #define min(X, Y) ({ \
>  const typeof (X) _x = (X);   \
>  const typeof (Y) _y = (Y);   \
> -- 
> 2.0.4
> 
> 

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

Re: [Xen-devel] [PATCH v6 12/16] libxl/arm: Factor finalise_one_memory_node as a gerneric function

[Wei Liu]

On Thu, Sep 22, 2016 at 08:52:29PM +0800, z00226004 wrote:
> From: Shannon Zhao 
> 
> Rename finalise_one_memory_node to finalise_one_node and pass the node
> name via function parameter.
> 
> This is useful for adding ACPI module which will be added by a later
> patch.
> 
> Signed-off-by: Shannon Zhao 
> Acked-by: Julien Grall 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v6 11/16] libxl/arm: Construct ACPI DSDT table

[Wei Liu]

On Thu, Sep 22, 2016 at 08:52:28PM +0800, z00226004 wrote:
> From: Shannon Zhao 
> 
> Copy the static DSDT table into ACPI blob.
> 
> Signed-off-by: Shannon Zhao 
> Acked-by: Julien Grall 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v6 10/16] libxl/arm: Construct ACPI FADT table

[Wei Liu]

On Thu, Sep 22, 2016 at 08:52:27PM +0800, z00226004 wrote:
> From: Shannon Zhao 
> 
> Signed-off-by: Shannon Zhao 
> Acked-by: Julien Grall 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v6 08/16] libxl/arm: Factor MPIDR computing codes out as a helper

[Wei Liu]

On Thu, Sep 22, 2016 at 08:52:25PM +0800, z00226004 wrote:
> From: Shannon Zhao 
> 
> Factor MPIDR computing codes out as a helper, so it could be shared
> between DT and ACPI.
> 
> Signed-off-by: Shannon Zhao 
> Acked-by: Julien Grall 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v6 07/16] libxl/arm: Construct ACPI GTDT table

[Wei Liu]

On Thu, Sep 22, 2016 at 08:52:24PM +0800, z00226004 wrote:
> From: Shannon Zhao 
> 
> Construct GTDT table with the interrupt information of timers.
> 
> Signed-off-by: Shannon Zhao 
> Acked-by: Julien Grall 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v6 06/16] libxl/arm: Construct ACPI XSDT table

[Wei Liu]

On Thu, Sep 22, 2016 at 08:52:23PM +0800, z00226004 wrote:
> From: Shannon Zhao 
> 
> Signed-off-by: Shannon Zhao 
> Acked-by: Julien Grall 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v6 16/16] libxl/arm: Add the size of ACPI tables to maxmem

[Wei Liu]

On Thu, Sep 22, 2016 at 08:52:33PM +0800, z00226004 wrote:
> From: Shannon Zhao 
> 
> Here it adds the ACPI tables size to set the target maxmem to avoid
> providing less available memory for guest.
> 
> Signed-off-by: Shannon Zhao 
> ---
>  tools/libxl/libxl_arch.h|  4 
>  tools/libxl/libxl_arm.c | 16 
>  tools/libxl/libxl_arm.h |  4 
>  tools/libxl/libxl_arm_acpi.c| 20 
>  tools/libxl/libxl_arm_no_acpi.c |  6 ++
>  tools/libxl/libxl_dom.c |  9 -
>  tools/libxl/libxl_internal.h|  2 ++
>  tools/libxl/libxl_x86.c |  6 ++
>  8 files changed, 66 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/libxl/libxl_arch.h b/tools/libxl/libxl_arch.h
> index 8cb9ba7..a066bbd 100644
> --- a/tools/libxl/libxl_arch.h
> +++ b/tools/libxl/libxl_arch.h
> @@ -66,6 +66,10 @@ _hidden
>  void libxl__arch_domain_build_info_acpi_setdefault(
>  libxl_domain_build_info *b_info);
>  
> +_hidden
> +int libxl__arch_memory_constant(libxl__gc *gc, libxl_domain_build_info *info,
> +libxl__domain_build_state *state);

I think the prototype should change a bit.

_hidden
int libxl__arch_extra_memory(libxl__gc, *gc,
 const libxl_domain_build_info *info,
 const libxl__domain_build_state *state,
 uint64_t *out);

The important bit is to not overload the return value to carry the
output value.

> +
>  #if defined(__i386__) || defined(__x86_64__)
>  
>  #define LAPIC_BASE_ADDRESS  0xfee0
> diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
> index 913f401..932e674 100644
> --- a/tools/libxl/libxl_arm.c
> +++ b/tools/libxl/libxl_arm.c
> @@ -106,6 +106,22 @@ int libxl__arch_domain_create(libxl__gc *gc, 
> libxl_domain_config *d_config,
>  return 0;
>  }
>  
> +int libxl__arch_memory_constant(libxl__gc *gc, libxl_domain_build_info *info,
> +libxl__domain_build_state *state)
> +{
> +int size;
> +
> +if (libxl_defbool_val(info->acpi)) {
> +size = libxl__get_acpi_size(gc, info, state);
> +if (size < 0)
> +return ERROR_FAIL;
> +
> +return DIV_ROUNDUP(size, 1024);
> +}
> +
> +return 0;
> +}
> +
>  static struct arch_info {
>  const char *guest_type;
>  const char *timer_compat;
> diff --git a/tools/libxl/libxl_arm.h b/tools/libxl/libxl_arm.h
> index a91ff93..37b1f15 100644
> --- a/tools/libxl/libxl_arm.h
> +++ b/tools/libxl/libxl_arm.h
> @@ -24,6 +24,10 @@ int libxl__prepare_acpi(libxl__gc *gc, 
> libxl_domain_build_info *info,
>  libxl__domain_build_state *state,
>  struct xc_dom_image *dom);
>  
> +_hidden
> +int libxl__get_acpi_size(libxl__gc *gc, libxl_domain_build_info *info,
> + libxl__domain_build_state *state);
> +

Same here, don't overload the return value for output.

>  static inline uint64_t libxl__compute_mpdir(unsigned int cpuid)
>  {
>  /*
> diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
> index 9c4005f..0d4092d 100644
> --- a/tools/libxl/libxl_arm_acpi.c
> +++ b/tools/libxl/libxl_arm_acpi.c
> @@ -94,6 +94,26 @@ static int libxl__estimate_madt_size(libxl__gc *gc,
>  return rc;
>  }
>  
> +int libxl__get_acpi_size(libxl__gc *gc, libxl_domain_build_info *info,
> + libxl__domain_build_state *state)
> +{
> +int size;
> +
> +size = libxl__estimate_madt_size(gc, info, >config);
> +if (size < 0)
> +goto out;
> +
> +size = ROUNDUP(size, 3) +
> +   ROUNDUP(sizeof(struct acpi_table_rsdp), 3) +
> +   ROUNDUP(sizeof(struct acpi_table_xsdt), 3) +
> +   ROUNDUP(sizeof(struct acpi_table_gtdt), 3) +
> +   ROUNDUP(sizeof(struct acpi_table_fadt), 3) +
> +   ROUNDUP(sizeof(dsdt_anycpu_arm_len), 3);
> +
> +out:
> +return size;
> +}
> +
>  static int libxl__estimate_acpi_size(libxl__gc *gc,
>   libxl_domain_build_info *info,
>   struct xc_dom_image *dom,
> diff --git a/tools/libxl/libxl_arm_no_acpi.c b/tools/libxl/libxl_arm_no_acpi.c
> index e7f7411..5eeb825 100644
> --- a/tools/libxl/libxl_arm_no_acpi.c
> +++ b/tools/libxl/libxl_arm_no_acpi.c
> @@ -25,6 +25,12 @@ int libxl__prepare_acpi(libxl__gc *gc, 
> libxl_domain_build_info *info,
>  return ERROR_FAIL;
>  }
>  
> +int libxl__get_acpi_size(libxl__gc *gc, libxl_domain_build_info *info,
> + libxl__domain_build_state *state)
> +{
> +return ERROR_FAIL;
> +}
> +
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index 2924629..118beab 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -408,8 +408,15 @@ int 

[Xen-devel] [libvirt test] 101094: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-qcow2  9 debian-di-install  fail REGR. vs. 101072

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass

version targeted for testing:
 libvirt  1fc90ae934b8b05e02ffc47cb79f181d9e5ece69
baseline version:
 libvirt  e5568193f4d663f6a9edebcf9044d527f90a031f

Last test of basis   101072  2016-09-21 04:22:22 Z1 days
Testing same since   101094  2016-09-22 04:22:55 Z0 days1 attempts


People who touched revisions under test:
  Chen Hanxiao 
  Jim Fehlig 
  Jiri Denemark 
  Michal Privoznik 
  Nikolay Shirokovskiy 
  Nitesh Konkar 
  Nitesh Konkar 
  Pavel Hrdina 
  Peter Krempa 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm fail
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-armhf-armhf-libvirt fail
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-armhf-armhf-libvirt-qcow2   fail
 test-armhf-armhf-libvirt-raw fail
 test-amd64-amd64-libvirt-vhd pass



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

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

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;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 314 lines long.)

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

Re: [Xen-devel] [PATCH v6 00/16] Xen ARM DomU ACPI support

[Shannon Zhao]

On 2016/9/22 21:37, Julien Grall wrote:
> 
> 
> On 22/09/16 14:32, Shannon Zhao wrote:
>>
>>
>> On 2016/9/22 21:27, Julien Grall wrote:
>>> Hi Shannon,
>>>
>>> I am not sure why, but your name on this patch series become: z00226004.
>>> You may want to give a look to your mail sender.
>>>
>> Oops, I just modified the user.name before and forgot to change back. I
>> will resend soon.
> 
> No need to resend just for that. The "From:" field is correct so we
> could apply your series if everything is ok. :)
> 
Ok, I just realized this. Thanks :)

-- 
Shannon


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

Re: [Xen-devel] [PATCH v6 00/16] Xen ARM DomU ACPI support

[Julien Grall]

On 22/09/16 14:32, Shannon Zhao wrote:



On 2016/9/22 21:27, Julien Grall wrote:

Hi Shannon,

I am not sure why, but your name on this patch series become: z00226004.
You may want to give a look to your mail sender.


Oops, I just modified the user.name before and forgot to change back. I
will resend soon.


No need to resend just for that. The "From:" field is correct so we 
could apply your series if everything is ok. :)


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v6 00/16] Xen ARM DomU ACPI support

[Shannon Zhao]

On 2016/9/22 21:27, Julien Grall wrote:
> Hi Shannon,
> 
> I am not sure why, but your name on this patch series become: z00226004.
> You may want to give a look to your mail sender.
> 
Oops, I just modified the user.name before and forgot to change back. I
will resend soon.

Thanks,
-- 
Shannon


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

Re: [Xen-devel] [PATCH v6 00/16] Xen ARM DomU ACPI support

[Julien Grall]

Hi Shannon,

I am not sure why, but your name on this patch series become: z00226004.
You may want to give a look to your mail sender.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v5 08/16] livepatch/arm/x86: Check payload for for unwelcomed symbols.

[Julien Grall]

Hi Konrad,

On 21/09/16 18:32, Konrad Rzeszutek Wilk wrote:

Certain platforms, such as ARM [32|64] add extra mapping symbols
such as $x (for ARM64 instructions), or more interesting to
this patch: $t (for Thumb instructions). These symbols are suppose


nit: s/are suppose to/are supposed to/


to help the final linker to make any adjustments (such as
add an veneer). But more importantly - we do not compile Xen
with any Thumb instructions (which are variable length) - and
if we find these mapping symbols we should disallow such payload.

Signed-off-by: Konrad Rzeszutek Wilk 
---
Cc: Konrad Rzeszutek Wilk 
Cc: Ross Lagerwall 
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: Andrew Cooper 

v3: New submission.
Use [i] instead of sym (as that will always be NULL).
v4: Use bool instead of int for return
Update comment in common code about ARM odd symbols.
s/_check/_deny/ to make it more clear.
v5: Also check for $t.* wildcard.
Use Julien's variant where we roll the [2] check in the return.
---
 xen/arch/arm/livepatch.c| 16 
 xen/arch/x86/livepatch.c|  7 +++
 xen/common/livepatch_elf.c  |  7 +++
 xen/include/xen/livepatch.h |  2 ++
 4 files changed, 32 insertions(+)

diff --git a/xen/arch/arm/livepatch.c b/xen/arch/arm/livepatch.c
index 9959315..5a99ab5 100644
--- a/xen/arch/arm/livepatch.c
+++ b/xen/arch/arm/livepatch.c
@@ -117,6 +117,22 @@ bool arch_livepatch_symbol_ok(const struct livepatch_elf 
*elf,
 return true;
 }

+bool arch_livepatch_symbol_deny(const struct livepatch_elf *elf,
+const struct livepatch_elf_sym *sym)
+{
+#ifdef CONFIG_ARM_32


Out of interest, is there any particular reason to use #ifdef rather 
than adding the function in {arm32/arm64}/livepatch.c?



+/*
+ * Xen does not use Thumb instructions - and we should not see any of
+ * them. If we do, abort.
+ */
+if ( sym->name && sym->name[0] == '$' && sym->name[1] == 't' )
+{
+return ( !sym->name[2] || sym->name[2] == '.' );
+}


NIT: You could drop { } here.


+#endif
+return false;
+}


Regardless the answer to my question:

Reviewed-by: Julien Grall 

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v5 09/16] livepatch: Move test-cases to their own sub-directory in test.

[Julien Grall]

Hi Konrad,

On 21/09/16 18:32, Konrad Rzeszutek Wilk wrote:

So they can be shared with ARM64 (but not yet, so they
are only built on x86).

No functional change.

We also need to tweak the MAINTAINERS and .gitignore file.

Also we need to update SUBDIRS to include the new 'test'
directory so 'cscope' can show the example livepatches.

Acked-by: Jan Beulich  [for directory]
Signed-off-by: Konrad Rzeszutek Wilk 

---
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: Jan Beulich 
Cc: Andrew Cooper 

v1: First submission
v2: Move to test/livepatch per Jan's recommendation
v3: Sort MAINTAINERS for livepatch.
Add Jan's Acked-by.
Added on the SUBDIRS the 'test' directory
Change title of patch (common-> own sub-directory)
---
 .gitignore | 8 
 MAINTAINERS| 1 +
 xen/Makefile   | 5 +++--
 xen/arch/arm/Makefile  | 3 ---


I am not sure if you want an ack for this small ARM change. So FWIW:

Acked-by: Julien Grall 

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v5 16/16] livepatch: arm[32, 64], x86: NOP test-case

[Julien Grall]

Hi Konrad,

On 21/09/16 18:32, Konrad Rzeszutek Wilk wrote:

The test-case is quite simple - we NOP the 'xen_minor_version'.
The amount of NOPs depends on the architecture.

On x86 the function is 11 bytes long:

   55  push   %rbp  <- NOP
   48 89 e5mov%rsp,%rbp <- NOP
   b8 04 00 00 00  mov$0x4,%eax <- NOP
   5d  pop%rbp  <- NOP
   c3  retq

We can NOP everything but the last instruction (so 10 bytes).

On ARM64 its 8 bytes:

  52800100mov w0, #0x8 <- NOP
  d65f03c0ret

We can NOP the first instruction.

While on ARM32 there are 24 bytes:

  e52db004push{fp}
  e28db000add fp, sp, #0 <- NOP
  e3a8mov r0, #8 <- NOP
  e24bd000sub sp, fp, #0 <- NOP
  e49db004pop {fp}
  e12fff1ebx  lr

And we can NOP instruction 2,3, and 4.


Why don't you NOP push {fp} and pop {fp}? At first glance, I am a bit 
surprised that the compiler is generating them (maybe it is because you 
have debug enabled?) and would have expect to have:


mov r0, #8
bx lr

NOPing all the instructions but the last one would simplify at lot the 
test case below.


[...]


--- /dev/null
+++ b/xen/test/livepatch/xen_nop.c
@@ -0,0 +1,49 @@
+/*
+ * Copyright (c) 2016 Oracle and/or its affiliates. All rights reserved.
+ *
+ */
+
+#include "config.h"
+#include 
+
+#include 
+
+/*
+ * All of the .new_size and .old_addr are based on assumptions that the
+ * code for 'xen_minor_version' is compiled in specific way. Before
+ * running this test-case you MUST verify that the assumptions are
+ * correct (Hint: make debug and look in xen.s).
+ */
+struct livepatch_func __section(".livepatch.funcs") livepatch_nop = {
+.version = LIVEPATCH_PAYLOAD_VERSION,
+.old_size = MINOR_VERSION_SZ,
+
+#ifdef CONFIG_X86
+.old_addr = (void *)MINOR_VERSION_ADDR,
+/* Everything but the last instruction: "req". */
+.new_size = MINOR_VERSION_SZ-1,
+#endif
+
+#ifdef CONFIG_ARM_64
+.old_addr = (void *)MINOR_VERSION_ADDR,
+/* Replace the first one: "mov w0, #0x8".  */
+.new_size = 4,
+#endif
+
+#ifdef CONFIG_ARM_32
+/* Skip the first instruction: "push {fp}". */
+.old_addr = (void *)(MINOR_VERSION_ADDR + 4),
+/* And replace the next three instructions. */
+.new_size = 3 * 4,
+#endif
+};


With my suggestion above, the two ARM code could become:

#ifdef CONFIG_ARM
.old_addr = (void *)MINOR_VERSION_ADDR,
.new_size = MINOR_VERSION_SIZE - 4,
#endif

The "- 4" is to avoid replacing the return.

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v5 10/16] livepatch: x86, ARM, alternative: Expose FEATURE_LIVEPATCH

[Julien Grall]

Hi Konrad,

On 21/09/16 18:32, Konrad Rzeszutek Wilk wrote:

To use as a common way of testing alternative patching for
livepatches. Both architectures have this FEATURE and the
test-cases can piggyback on that.

Suggested-by: Julien Grall 
Signed-off-by: Konrad Rzeszutek Wilk 


For the ARM part:

Acked-by: Julien Grall 

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v5 11/16] livepatch: tests: Make them compile under ARM64

[Julien Grall]

Hi Konrad,

On 21/09/16 18:32, Konrad Rzeszutek Wilk wrote:

We need to two things:
1) Wrap the platform-specific objcopy parameters in defines
   The input and output parameters for $(OBJCOPY) are different
   based on the platforms. As such provide them in the
   OBJCOPY_MAGIC define and use that.

2) The alternative is a bit different (exists only under ARM64
   and x86), while and there are no exceptions under ARM at all.
   We use the LIVEPATCH_FEATURE CPU id feature for ARM similar to
   how it is done on x86.

We are not yet attempting to build them under ARM32 so
that is still ifdefed out.

Signed-off-by: Konrad Rzeszutek Wilk 

---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 

v1: First submission
v2: Corrected description by Julien
Add #ifeq instead of #else for ARM case.
v3: Moved 'asm(alter..)' by one space to the left.
v4: Rebase on top of "livepatch/tests: Make .livepatch.depends be read-only"
Rewrote the commit description 2) a bit.
---
 xen/test/Makefile |  2 +-
 xen/test/livepatch/Makefile   | 12 ++--
 xen/test/livepatch/xen_hello_world_func.c |  7 +++
 3 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/xen/test/Makefile b/xen/test/Makefile
index 8c53040..95c1755 100644
--- a/xen/test/Makefile
+++ b/xen/test/Makefile
@@ -1,6 +1,6 @@
 .PHONY: tests
 tests:

I am wondering if there is any way to use the

-ifeq ($(XEN_TARGET_ARCH),x86_64)
+ifneq $(XEN_TARGET_ARCH),arm32)


NIT: I am wondering if you could instead use CONFIG_LIVEPATCH here, so 
the tests would only be built when livepatch is enabled.



$(MAKE) -f $(BASEDIR)/Rules.mk -C livepatch livepatch
 endif

diff --git a/xen/test/livepatch/Makefile b/xen/test/livepatch/Makefile
index 48ff843..5db4d9c 100644
--- a/xen/test/livepatch/Makefile
+++ b/xen/test/livepatch/Makefile
@@ -1,5 +1,12 @@
 include $(XEN_ROOT)/Config.mk

+ifeq ($(XEN_TARGET_ARCH),x86_64)
+OBJCOPY_MAGIC := -I binary -O elf64-x86-64 -B i386:x86-64
+endif
+ifeq ($(XEN_TARGET_ARCH),arm64)
+OBJCOPY_MAGIC := -I binary -O elf64-littleaarch64 -B aarch64
+endif
+
 CODE_ADDR=$(shell nm --defined $(1) | grep $(2) | awk '{print "0x"$$1}')
 CODE_SZ=$(shell nm --defined -S $(1) | grep $(2) | awk '{ print "0x"$$2}')

@@ -54,8 +61,9 @@ $(LIVEPATCH): xen_hello_world_func.o xen_hello_world.o note.o
 .PHONY: note.o
 note.o:
$(OBJCOPY) -O binary --only-section=.note.gnu.build-id 
$(BASEDIR)/xen-syms $@.bin
-   $(OBJCOPY) -I binary -O elf64-x86-64 -B i386:x86-64 \
+   $(OBJCOPY) $(OBJCOPY_MAGIC) \
   
--rename-section=.data=.livepatch.depends,alloc,load,readonly,data,contents -S 
$@.bin $@
+  --rename-section=.data=.livepatch.depends -S $@.bin $@


I am not sure why you added this line. Did you intend to replace the 
previous one?



rm -f $@.bin

 #
@@ -65,7 +73,7 @@ note.o:
 .PHONY: hello_world_note.o
 hello_world_note.o: $(LIVEPATCH)
$(OBJCOPY) -O binary --only-section=.note.gnu.build-id $(LIVEPATCH) 
$@.bin
-   $(OBJCOPY)  -I binary -O elf64-x86-64 -B i386:x86-64 \
+   $(OBJCOPY) $(OBJCOPY_MAGIC) \
   
--rename-section=.data=.livepatch.depends,alloc,load,readonly,data,contents -S 
$@.bin $@
rm -f $@.bin

diff --git a/xen/test/livepatch/xen_hello_world_func.c 
b/xen/test/livepatch/xen_hello_world_func.c
index 0321f3e..c5c0da1 100644
--- a/xen/test/livepatch/xen_hello_world_func.c
+++ b/xen/test/livepatch/xen_hello_world_func.c
@@ -7,14 +7,17 @@

 #include 
 #include 
+#ifdef CONFIG_X86
 #include 
 #include 

 static unsigned long *non_canonical_addr = (unsigned long 
*)0xdeadULL;
+#endif

 /* Our replacement function for xen_extra_version. */
 const char *xen_hello_world(void)
 {
+#ifdef CONFIG_X86
 unsigned long tmp;
 int rc;

@@ -25,6 +28,10 @@ const char *xen_hello_world(void)
  */
 rc = __get_user(tmp, non_canonical_addr);
 BUG_ON(rc != -EFAULT);
+#endif
+#ifdef CONFIG_ARM_64


NIT: I would use:

#if defined(CONFIG_ARM) && defined(CONFIG_HAS_ALTERNATIVE)

in order to handle alternative if we decide to add support for ARM32.


+asm(ALTERNATIVE("nop", "nop", LIVEPATCH_FEATURE));
+#endif

 return "Hello World";
 }



Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v6 08/15] x86/efi: create new early memory allocator

[Jan Beulich]

>>> On 22.09.16 at 14:07,  wrote:
> On Thu, Sep 22, 2016 at 05:25:46AM -0600, Jan Beulich wrote:
>> >>> On 22.09.16 at 12:52,  wrote:
>> > On Wed, Sep 21, 2016 at 03:42:09AM -0600, Jan Beulich wrote:
>> >> >>> On 20.09.16 at 20:45,  wrote:
>> >> > On Tue, Sep 20, 2016 at 07:46:56AM -0600, Jan Beulich wrote:
>> >> >> >>> On 20.09.16 at 12:52,  wrote:
>> >
>> > [...]
>> >
>> >> >> > Do you suggest that I should move out of #ifndef CONFIG_ARM all 
>> >> >> > ebmalloc
>> > stuff
>> >> >> > except free_ebmalloc_unused_mem(). Even if it is not used on ARM 
>> >> >> > right
>> > now?
>> >> >>
>> >> >> That's not the static function, is it? The function you name should
>> >> >> actually be called on ARM too (as I did point out elsewhere already),
>> >> >> just to not leave a trap open for someone to fall into when (s)he
>> >> >> adds a first use of the allocator on ARM.
>> >> >
>> >> > Well, I think that sane person doing that would analyze how ebmalloc 
>> >> > works
>> >> > on x86 and then move (align to ARM needs if required) all its machinery
>> >> > (including free_ebmalloc_unused_mem()) to run on ARM. At least I would 
>> >> > do
>> >> > that. This way he/she would avoid issues mentioned by you. However, if 
>> >> > you
>> >> > still prefer your way I can do that. Though I am not sure about the 
>> >> > rest 
> of
>> >> > ebmalloc stuff. Should I move it out of #ifndef CONFIG_ARM? Looking at 
> your
>> >> > earlier replies I see that yes. Am I correct?
>> >>
>> >> Yes.
>> >
>> > This does not work because if I build Xen for ARM then I got:
>> > boot.c:589:21: error: 'ebmalloc' defined but not used
>> > [-Werror=unused-function]
>> >  static void __init *ebmalloc(size_t size)
>>
>> Quote from an earlier reply of mine:
>>
>>   Arguably the one static function may better be, as other
>>   workarounds to avoid the "unused" compiler warning wouldn't
>>   be any better.
>>
>> and then later
>>
>>   You misunderstood - I said that for this one (unused) static
>>   function such an #ifdef is probably okay, as the presumably
>>   smallest possible workaround.
>>
>> I really have no idea what else to say.
> 
> Sorry, however, sometimes it is very difficult to understand what are
> you referring to. If you could be more specific then I will be happy.
> 
> Anyway, now it looks that you wish something like that:
> 
> #ifndef CONFIG_ARM
> /* Whole x86 ebmalloc stuff. */
> ...
> #else
> void __init free_ebmalloc_unused_mem(void)
> {
> }
> #endif
> 
> and then call free_ebmalloc_unused_mem() from e.g.
> xen/arch/arm/setup.c:init_done(). Am I right?

No. I want the #ifdef to _only_ cover the unused static function.

Jan


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

Re: [Xen-devel] [PATCH v5 12/16] xen/arm32: Add an helper to invalidate all instruction caches

[Julien Grall]

Hi Konrad,

On 21/09/16 18:32, Konrad Rzeszutek Wilk wrote:

This is similar to commit fb9d877a9c0f3d4d15db8f6e0c5506ea641862c6
"xen/arm64: Add an helper to invalidate all instruction caches"
except it is on ARM32 side.

When we are flushing the cache we are most likley also want


s/likley/likely/


to flush the branch predictor too. Hence we add this.

And we also need to follow this with dsb()/isb() which are
memory barriers().

Signed-off-by: Konrad Rzeszutek Wilk 


Reviewed-by: Julien Grall 

Regards,

--
Julien Grall

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