Re: [Xen-devel] [RFC Design Doc] Add vNVDIMM support for Xen

[Haozhong Zhang]

On 02/16/16 05:55, Jan Beulich wrote:
> >>> On 16.02.16 at 12:14,  wrote:
> > On Mon, 15 Feb 2016, Zhang, Haozhong wrote:
> >> On 02/04/16 20:24, Stefano Stabellini wrote:
> >> > On Thu, 4 Feb 2016, Haozhong Zhang wrote:
> >> > > On 02/03/16 15:22, Stefano Stabellini wrote:
> >> > > > On Wed, 3 Feb 2016, George Dunlap wrote:
> >> > > > > On 03/02/16 12:02, Stefano Stabellini wrote:
> >> > > > > > On Wed, 3 Feb 2016, Haozhong Zhang wrote:
> >> > > > > >> Or, we can make a file system on /dev/pmem0, create files on 
> >> > > > > >> it, set
> >> > > > > >> the owner of those files to xen-qemuuser-domid$domid, and then 
> >> > > > > >> pass
> >> > > > > >> those files to QEMU. In this way, non-root QEMU should be able 
> >> > > > > >> to
> >> > > > > >> mmap those files.
> >> > > > > >
> >> > > > > > Maybe that would work. Worth adding it to the design, I would 
> >> > > > > > like to
> >> > > > > > read more details on it.
> >> > > > > >
> >> > > > > > Also note that QEMU initially runs as root but drops privileges 
> >> > > > > > to
> >> > > > > > xen-qemuuser-domid$domid before the guest is started. Initially 
> >> > > > > > QEMU
> >> > > > > > *could* mmap /dev/pmem0 while is still running as root, but then 
> >> > > > > > it
> >> > > > > > wouldn't work for any devices that need to be mmap'ed at run time
> >> > > > > > (hotplug scenario).
> >> > > > >
> >> > > > > This is basically the same problem we have for a bunch of other 
> >> > > > > things,
> >> > > > > right?  Having xl open a file and then pass it via qmp to qemu 
> >> > > > > should
> >> > > > > work in theory, right?
> >> > > >
> >> > > > Is there one /dev/pmem? per assignable region?
> >> > > 
> >> > > Yes.
> >> > > 
> >> > > BTW, I'm wondering whether and how non-root qemu works with xl disk
> >> > > configuration that is going to access a host block device, e.g.
> >> > >  disk = [ '/dev/sdb,,hda' ]
> >> > > If that works with non-root qemu, I may take the similar solution for
> >> > > pmem.
> >> >  
> >> > Today the user is required to give the correct ownership and access mode
> >> > to the block device, so that non-root QEMU can open it. However in the
> >> > case of PCI passthrough, QEMU needs to mmap /dev/mem, as a consequence
> >> > the feature doesn't work at all with non-root QEMU
> >> > (http://marc.info/?l=xen-devel=145261763600528).
> >> > 
> >> > If there is one /dev/pmem device per assignable region, then it would be
> >> > conceivable to change its ownership so that non-root QEMU can open it.
> >> > Or, better, the file descriptor could be passed by the toolstack via
> >> > qmp.
> >> 
> >> Passing file descriptor via qmp is not enough.
> >> 
> >> Let me clarify where the requirement for root/privileged permissions
> >> comes from. The primary workflow in my design that maps a host pmem
> >> region or files in host pmem region to guest is shown as below:
> >>  (1) QEMU in Dom0 mmap the host pmem (the host /dev/pmem0 or files on
> >>  /dev/pmem0) to its virtual address space, i.e. the guest virtual
> >>  address space.
> >>  (2) QEMU asks Xen hypervisor to map the host physical address, i.e. SPA
> >>  occupied by the host pmem to a DomU. This step requires the
> >>  translation from the guest virtual address (where the host pmem is
> >>  mmaped in (1)) to the host physical address. The translation can be
> >>  done by either
> >> (a) QEMU that parses its own /proc/self/pagemap,
> >>  or
> >> (b) Xen hypervisor that does the translation by itself [1] (though
> >> this choice is not quite doable from Konrad's comments [2]).
> >> 
> >> [1] 
> >> http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg00434.html 
> >> [2] 
> >> http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg00606.html 
> >> 
> >> For 2-a, reading /proc/self/pagemap requires CAP_SYS_ADMIN capability
> >> since linux kernel 4.0. Furthermore, if we don't mlock the mapped host
> >> pmem (by adding MAP_LOCKED flag to mmap or calling mlock after mmap),
> >> pagemap will not contain all mappings. However, mlock may require
> >> privileged permission to lock memory larger than RLIMIT_MEMLOCK. Because
> >> mlock operates on memory, the permission to open(2) the host pmem files
> >> does not solve the problem and therefore passing file descriptor via qmp
> >> does not help.
> >> 
> >> For 2-b, from Konrad's comments [2], mlock is also required and
> >> privileged permission may be required consequently.
> >> 
> >> Note that the mapping and the address translation are done before QEMU
> >> dropping privileged permissions, so non-root QEMU should be able to work
> >> with above design until we start considering vNVDIMM hotplug (which has
> >> not been supported by the current vNVDIMM implementation in QEMU). In
> >> the hotplug case, we may let Xen pass explicit flags to QEMU to keep it
> >> running with root permissions.
> > 
> > Are we all good with the fact that vNVDIMM 

[Xen-devel] [libvirt test] 85151: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail 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-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-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-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  0b36b0e9ce83e8f96de27dffa90a0cb28cb229c9
baseline version:
 libvirt  95aa1017951e410b6e1ebbc685034ac4cc49c6fb

Last test of basis85019  2016-03-02 04:25:57 Z2 days
Testing same since85151  2016-03-03 04:22:50 Z1 days1 attempts


People who touched revisions under test:
  John Ferlan 
  Michal Privoznik 

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


Pushing revision :

+ branch=libvirt
+ revision=0b36b0e9ce83e8f96de27dffa90a0cb28cb229c9
+ . ./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 libvirt 
0b36b0e9ce83e8f96de27dffa90a0cb28cb229c9
+ 

[Xen-devel] [linux-3.16 baseline-only test] 44215: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 44215 linux-3.16 real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44215/

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 build-i386-rumpuserxen6 xen-buildfail   like 38735
 build-amd64-rumpuserxen   6 xen-buildfail   like 38735
 test-amd64-amd64-xl  19 guest-start/debian.repeatfail   like 38735
 test-amd64-amd64-xl-xsm  19 guest-start/debian.repeatfail   like 38735
 test-amd64-amd64-xl-credit2  17 guest-localmigrate/x10   fail   like 38735
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail like 38735

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-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  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-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-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-midway   12 migrate-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-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-multivcpu 17 guest-localmigrate/x10   fail  never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-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-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-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-xl-qemuu-win7-amd64 16 guest-stop  fail never pass
 test-amd64-amd64-xl-rtds 17 guest-localmigrate/x10   fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass

version targeted for testing:
 linux7f2a8840d127c8d5c59a5d79235e1205aba2e102
baseline version:
 linux752289d006578baafcbf6dc5b2a0b0fc38c8b1c7

Last test of basis38735  2016-02-10 21:21:20 Z   22 days
Testing same since44215  2016-03-03 15:35:17 Z0 days1 attempts


People who touched revisions under test:
  "Eric W. Biederman" 
  Akinobu Mita 
  Al Viro 
  Alan Stern 
  Alexandra Yates 
  Alexey Khoroshilov 
  Andrew Morton 
  Andrey Konovalov 
  Ard Biesheuvel 
  Arnaldo Carvalho de Melo 

Re: [Xen-devel] [GRUB2 PATCH v3 4/4] multiboot2: Add support for relocatable images

[Juergen Gross]

On 02/03/16 17:51, Daniel Kiper wrote:
> Currently multiboot2 protocol loads image exactly at address specified in
> ELF or multiboot2 header. This solution works quite well on legacy BIOS
> platforms. It is possible because memory regions are placed at predictable
> addresses (though I was not able to find any spec which says that it is
> strong requirement, so, it looks that it is just a goodwill of hardware
> designers). However, EFI platforms are more volatile. Even if required
> memory regions live at specific addresses then they are sometimes simply
> not free (e.g. used by boot/runtime services on Dell PowerEdge R820 and
> OVMF). This means that you are not able to simply set up final image
> destination on build time. You have to provide method to relocate image
> contents to real load address which is usually different than load address
> specified in ELF and multiboot2 headers.
> 
> This patch provides all needed machinery to do self relocation in image code.
> First of all GRUB2 reads min_addr (min. load addr), max_addr (max. load addr),
> align (required image alignment), preference (it says which memory regions are
> preferred by image, e.g. none, low, high) from 
> multiboot_header_tag_relocatable
> header tag contained in binary. Later loader tries to fulfill request (not 
> only
> that one) and if it succeeds then it informs image about real load address via
> multiboot_tag_base_addr tag. At this stage GRUB2 role is finished. Starting
> from now executable must cope with relocations itself using whole static
> and dynamic knowledge provided by boot loader.
> 
> This patch does not provide functionality which could do relocations using
> ELF relocation data. However, I was asked by Konrad Rzeszutek Wilk and 
> Vladimir
> 'phcoder' Serbinenko to investigate that thing. It looks that relevant 
> machinery
> could be added to existing code (including this patch) without huge effort.
> Additionally, ELF relocation could live in parallel with self relocation 
> provided
> by this patch. However, during research I realized that first of all we should
> establish the details how ELF relocatable image should look like and how it 
> should
> be build. At least to build proper test/example files.
> 
> As I saw multiboot2 protocol is able to consume ET_EXEC and ET_DYN ELF files.
> Potentially we can use ET_DYN file type. It can be build with gcc/ld -pie 
> option.
> However, it contains a lot of unneeded stuff (e.g. INTERP, DYNAMIC, 
> GNU_EH_FRAME
> program headers) and it could be quite difficult to drop them (Hmmm... Is it
> possible to build it properly with custom ld script?). So, I have checked 
> ET_EXEC
> file type. Sadly in this case linker by default resolves all local symbol 
> relocations
> and removes relocation related sections. Fortunately it is possible to leave 
> them
> as is with simple -q/--emit-relocs ld option. However, output file is quite 
> fragile
> and any operation on it should be done with great care (e.g. strip should be 
> called
> with --strip-unneeded option). So, this solution is not perfect too. It means 
> that
> maybe we should look for better solution. However, I think that we should not 
> use
> any custom tools and focus on functionalities provided by compiler and 
> binutils.
> In this context ld scripts looks quite promising but maybe you have better 
> solutions.
> So, what do you think about that?
> 
> This patch was tested with Xen image which uses that functionality. However, 
> this Xen
> feature is still under development and new patchset will be released in about 
> 3-4 weeks.
> 
> Signed-off-by: Daniel Kiper 
> ---
> v3 - suggestions/fixes:
>- reduce number of casts
>  (suggested by Konrad Rzeszutek Wilk),
>- remove unneeded space at the end of line
>  (suggested by Konrad Rzeszutek Wilk),
>- improve commit message
>  (suggested by Konrad Rzeszutek Wilk).
> ---
>  grub-core/loader/i386/multiboot_mbi.c |6 ++-
>  grub-core/loader/multiboot.c  |   12 --
>  grub-core/loader/multiboot_elfxx.c|   28 ++
>  grub-core/loader/multiboot_mbi2.c |   65 
> ++---
>  include/grub/multiboot.h  |4 +-
>  include/multiboot2.h  |   24 
>  6 files changed, 120 insertions(+), 19 deletions(-)
> 
> diff --git a/grub-core/loader/i386/multiboot_mbi.c 
> b/grub-core/loader/i386/multiboot_mbi.c
> index f60b702..4fc83ed 100644
> --- a/grub-core/loader/i386/multiboot_mbi.c
> +++ b/grub-core/loader/i386/multiboot_mbi.c
> @@ -72,7 +72,8 @@ load_kernel (grub_file_t file, const char *filename,
>grub_err_t err;
>if (grub_multiboot_quirks & GRUB_MULTIBOOT_QUIRK_BAD_KLUDGE)
>  {
> -  err = grub_multiboot_load_elf (file, filename, buffer);
> +  err = grub_multiboot_load_elf (file, filename, buffer, 0, 0, 0, 0,
> +  GRUB_RELOCATOR_PREFERENCE_NONE, NULL, 0);

Uuh, really? You are adding 

[Xen-devel] [PATCH v5 17/17] Xen: EFI: Parse DT parameters for Xen specific UEFI

[Shannon Zhao]

From: Shannon Zhao 

Add a new function to parse DT parameters for Xen specific UEFI just
like the way for normal UEFI. Then it could reuse the existing codes.

If Xen supports EFI, initialize runtime services.

Signed-off-by: Shannon Zhao 
Reviewed-by: Matt Fleming 
Reviewed-by: Stefano Stabellini 
---
CC: Matt Fleming 
---
 arch/arm/xen/enlighten.c   |  6 +
 drivers/firmware/efi/arm-runtime.c | 17 +-
 drivers/firmware/efi/efi.c | 45 --
 3 files changed, 56 insertions(+), 12 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 0e542b8..026b5a7 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -261,6 +261,12 @@ static int __init fdt_find_hyper_node(unsigned long node, 
const char *uname,
!strncmp(hyper_node.prefix, s, strlen(hyper_node.prefix)))
hyper_node.version = s + strlen(hyper_node.prefix);
 
+   if (IS_ENABLED(CONFIG_XEN_EFI)) {
+   /* Check if Xen supports EFI */
+   if (of_get_flat_dt_subnode_by_name(node, "uefi") > 0)
+   set_bit(EFI_PARAVIRT, );
+   }
+
return 0;
 }
 
diff --git a/drivers/firmware/efi/arm-runtime.c 
b/drivers/firmware/efi/arm-runtime.c
index 6ae21e4..ac609b9 100644
--- a/drivers/firmware/efi/arm-runtime.c
+++ b/drivers/firmware/efi/arm-runtime.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 
 extern u64 efi_system_table;
 
@@ -107,13 +108,19 @@ static int __init arm_enable_runtime_services(void)
}
set_bit(EFI_SYSTEM_TABLES, );
 
-   if (!efi_virtmap_init()) {
-   pr_err("No UEFI virtual mapping was installed -- runtime 
services will not be available\n");
-   return -ENOMEM;
+   if (IS_ENABLED(CONFIG_XEN_EFI) && efi_enabled(EFI_PARAVIRT)) {
+   /* Set up runtime services function pointers for Xen Dom0 */
+   xen_efi_runtime_setup();
+   } else {
+   if (!efi_virtmap_init()) {
+   pr_err("No UEFI virtual mapping was installed -- 
runtime services will not be available\n");
+   return -ENOMEM;
+   }
+
+   /* Set up runtime services function pointers */
+   efi_native_runtime_setup();
}
 
-   /* Set up runtime services function pointers */
-   efi_native_runtime_setup();
set_bit(EFI_RUNTIME_SERVICES, );
 
efi.runtime_version = efi.systab->hdr.revision;
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 2cd37da..1328cb7 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -500,12 +500,14 @@ device_initcall(efi_load_efivars);
FIELD_SIZEOF(struct efi_fdt_params, field) \
}
 
-static __initdata struct {
+struct params {
const char name[32];
const char propname[32];
int offset;
int size;
-} dt_params[] = {
+};
+
+static struct params fdt_params[] __initdata = {
UEFI_PARAM("System Table", "linux,uefi-system-table", system_table),
UEFI_PARAM("MemMap Address", "linux,uefi-mmap-start", mmap),
UEFI_PARAM("MemMap Size", "linux,uefi-mmap-size", mmap_size),
@@ -513,24 +515,45 @@ static __initdata struct {
UEFI_PARAM("MemMap Desc. Version", "linux,uefi-mmap-desc-ver", desc_ver)
 };
 
+static struct params xen_fdt_params[] __initdata = {
+   UEFI_PARAM("System Table", "xen,uefi-system-table", system_table),
+   UEFI_PARAM("MemMap Address", "xen,uefi-mmap-start", mmap),
+   UEFI_PARAM("MemMap Size", "xen,uefi-mmap-size", mmap_size),
+   UEFI_PARAM("MemMap Desc. Size", "xen,uefi-mmap-desc-size", desc_size),
+   UEFI_PARAM("MemMap Desc. Version", "xen,uefi-mmap-desc-ver", desc_ver)
+};
+
 struct param_info {
int found;
void *params;
+   struct params *dt_params;
+   int size;
 };
 
 static int __init fdt_find_uefi_params(unsigned long node, const char *uname,
   int depth, void *data)
 {
struct param_info *info = data;
+   struct params *dt_params = info->dt_params;
const void *prop;
void *dest;
u64 val;
-   int i, len;
+   int i, len, offset;
 
-   if (depth != 1 || strcmp(uname, "chosen") != 0)
-   return 0;
+   if (efi_enabled(EFI_PARAVIRT)) {
+   if (depth != 1 || strcmp(uname, "hypervisor") != 0)
+   return 0;
 
-   for (i = 0; i < ARRAY_SIZE(dt_params); i++) {
+   offset = of_get_flat_dt_subnode_by_name(node, "uefi");
+   if (offset < 0)
+   return 0;
+   node = offset;
+   } else {
+   if (depth != 1 || strcmp(uname, "chosen") != 0)
+   return 

[Xen-devel] [PATCH v5 16/17] FDT: Add a helper to get the subnode by given name

[Shannon Zhao]

From: Shannon Zhao 

Sometimes it needs to check if there is a subnode of given node in FDT
by given name. Introduce this helper to get the subnode if it exists.

CC: Rob Herring 
Signed-off-by: Shannon Zhao 
---
 drivers/of/fdt.c   | 13 +
 include/linux/of_fdt.h |  2 ++
 2 files changed, 15 insertions(+)

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 655f79d..09001db 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -645,6 +645,19 @@ int __init of_scan_flat_dt(int (*it)(unsigned long node,
 }
 
 /**
+ * of_get_flat_dt_subnode_by_name - get the subnode by given name
+ *
+ * @node: the parent node
+ * @uname: the name of subnode
+ * @return offset of the subnode, or -FDT_ERR_NOTFOUND if there is none
+ */
+
+int of_get_flat_dt_subnode_by_name(unsigned long node, const char *uname)
+{
+   return fdt_subnode_offset(initial_boot_params, node, uname);
+}
+
+/**
  * of_get_flat_dt_root - find the root node in the flat blob
  */
 unsigned long __init of_get_flat_dt_root(void)
diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
index df9ef38..fc28162 100644
--- a/include/linux/of_fdt.h
+++ b/include/linux/of_fdt.h
@@ -52,6 +52,8 @@ extern char __dtb_end[];
 extern int of_scan_flat_dt(int (*it)(unsigned long node, const char *uname,
 int depth, void *data),
   void *data);
+extern int of_get_flat_dt_subnode_by_name(unsigned long node,
+ const char *uname);
 extern const void *of_get_flat_dt_prop(unsigned long node, const char *name,
   int *size);
 extern int of_flat_dt_is_compatible(unsigned long node, const char *name);
-- 
2.0.4



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

[Xen-devel] [PATCH v5 13/17] ARM: Xen: Document UEFI support on Xen ARM virtual platforms

[Shannon Zhao]

From: Shannon Zhao 

Add a "uefi" node under /hypervisor node in FDT, then Linux kernel could
scan this to get the UEFI information.

Signed-off-by: Shannon Zhao 
Acked-by: Rob Herring 
Reviewed-by: Stefano Stabellini 
---
CC: Rob Herring 
---
 Documentation/devicetree/bindings/arm/xen.txt | 33 +++
 1 file changed, 33 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/xen.txt 
b/Documentation/devicetree/bindings/arm/xen.txt
index 0f7b9c2..6f83f76 100644
--- a/Documentation/devicetree/bindings/arm/xen.txt
+++ b/Documentation/devicetree/bindings/arm/xen.txt
@@ -15,6 +15,26 @@ the following properties:
 - interrupts: the interrupt used by Xen to inject event notifications.
   A GIC node is also required.
 
+To support UEFI on Xen ARM virtual platforms, Xen populates the FDT "uefi" node
+under /hypervisor with following parameters:
+
+
+Name  | Size   | Description
+
+xen,uefi-system-table | 64-bit | Guest physical address of the UEFI System
+ || Table.
+
+xen,uefi-mmap-start   | 64-bit | Guest physical address of the UEFI memory
+ || map.
+
+xen,uefi-mmap-size| 32-bit | Size in bytes of the UEFI memory map
+  || pointed to in previous entry.
+
+xen,uefi-mmap-desc-size   | 32-bit | Size in bytes of each entry in the UEFI
+  || memory map.
+
+xen,uefi-mmap-desc-ver| 32-bit | Version of the mmap descriptor format.
+
 
 Example (assuming #address-cells = <2> and #size-cells = <2>):
 
@@ -22,4 +42,17 @@ hypervisor {
compatible = "xen,xen-4.3", "xen,xen";
reg = <0 0xb000 0 0x2>;
interrupts = <1 15 0xf08>;
+   uefi {
+   xen,uefi-system-table = <0x>;
+   xen,uefi-mmap-start = <0x>;
+   xen,uefi-mmap-size = <0x>;
+   xen,uefi-mmap-desc-size = <0x>;
+   xen,uefi-mmap-desc-ver = <0x>;
+};
 };
+
+The format and meaning of the "xen,uefi-*" parameters are similar to those in
+Documentation/arm/uefi.txt, which are provided by the regular UEFI stub. 
However
+they differ because they are provided by the Xen hypervisor, together with a 
set
+of UEFI runtime services implemented via hypercalls, see
+http://xenbits.xen.org/docs/unstable/hypercall/x86_64/include,public,platform.h.html.
-- 
2.0.4



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

[Xen-devel] [PATCH v5 01/17] Xen: ACPI: Hide UART used by Xen

[Shannon Zhao]

From: Shannon Zhao 

ACPI 6.0 introduces a new table STAO to list the devices which are used
by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
UART is used by Xen. So here it hides UART from Dom0.

Signed-off-by: Shannon Zhao 
---
CC: "Rafael J. Wysocki"  (supporter:ACPI)
CC: Len Brown  (supporter:ACPI)
CC: linux-a...@vger.kernel.org (open list:ACPI)
---
 drivers/acpi/scan.c | 68 +
 1 file changed, 68 insertions(+)

diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 407a376..31d794c 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -45,6 +45,7 @@ static LIST_HEAD(acpi_scan_handlers_list);
 DEFINE_MUTEX(acpi_device_lock);
 LIST_HEAD(acpi_wakeup_device_list);
 static DEFINE_MUTEX(acpi_hp_context_lock);
+static u64 spcr_uart_addr;
 
 struct acpi_dep_data {
struct list_head node;
@@ -1453,6 +1454,47 @@ static int acpi_add_single_object(struct acpi_device 
**child,
return 0;
 }
 
+static acpi_status acpi_get_resource_fixed_memory32(struct acpi_resource *res,
+   void *context)
+{
+   struct acpi_resource_fixed_memory32 *fixed_memory32;
+
+   if (res->type != ACPI_RESOURCE_TYPE_FIXED_MEMORY32)
+   return AE_OK;
+
+   fixed_memory32 = >data.fixed_memory32;
+   if (!fixed_memory32)
+   return AE_OK;
+
+   *((u32 *)context) = fixed_memory32->address;
+   return AE_CTRL_TERMINATE;
+}
+
+static bool acpi_device_should_be_hidden(acpi_handle handle)
+{
+   acpi_status status;
+   u32 addr = 0;
+
+   /* Check if it should ignore the UART device */
+   if (spcr_uart_addr != 0) {
+   if (!acpi_has_method(handle, METHOD_NAME__CRS))
+   return false;
+
+   status = acpi_walk_resources(handle, METHOD_NAME__CRS,
+acpi_get_resource_fixed_memory32,
+);
+   if (ACPI_FAILURE(status))
+   return false;
+
+   if (addr == spcr_uart_addr) {
+   printk(KERN_INFO PREFIX "The UART device in SPCR table 
will be hidden\n");
+   return true;
+   }
+   }
+
+   return false;
+}
+
 static int acpi_bus_type_and_status(acpi_handle handle, int *type,
unsigned long long *sta)
 {
@@ -1466,6 +1508,9 @@ static int acpi_bus_type_and_status(acpi_handle handle, 
int *type,
switch (acpi_type) {
case ACPI_TYPE_ANY: /* for ACPI_ROOT_OBJECT */
case ACPI_TYPE_DEVICE:
+   if (acpi_device_should_be_hidden(handle))
+   return -ENODEV;
+
*type = ACPI_BUS_TYPE_DEVICE;
status = acpi_bus_get_status_handle(handle, sta);
if (ACPI_FAILURE(status))
@@ -1919,6 +1964,8 @@ static int acpi_bus_scan_fixed(void)
 int __init acpi_scan_init(void)
 {
int result;
+   acpi_status status;
+   struct acpi_table_stao *stao_ptr;
 
acpi_pci_root_init();
acpi_pci_link_init();
@@ -1933,6 +1980,27 @@ int __init acpi_scan_init(void)
 
acpi_scan_add_handler(_device_handler);
 
+   /* If there is STAO table, check whether it needs to ignore the UART
+* device in SPCR table.
+*/
+   status = acpi_get_table(ACPI_SIG_STAO, 0,
+   (struct acpi_table_header **)_ptr);
+   if (ACPI_SUCCESS(status)) {
+   if (stao_ptr->header.length > sizeof(struct acpi_table_stao))
+   printk(KERN_INFO PREFIX "STAO Name List not yet 
supported.");
+
+   if (stao_ptr->ignore_uart) {
+   struct acpi_table_spcr *spcr_ptr;
+
+   status = acpi_get_table(ACPI_SIG_SPCR, 0,
+   (struct acpi_table_header **)_ptr);
+   if (ACPI_SUCCESS(status))
+   spcr_uart_addr = spcr_ptr->serial_port.address;
+   else
+   printk(KERN_WARNING PREFIX "STAO table present, 
but SPCR is missing\n");
+   }
+   }
+
mutex_lock(_scan_lock);
/*
 * Enumerate devices in the ACPI namespace.
-- 
2.0.4



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

[Xen-devel] [PATCH v5 14/17] XEN: EFI: Move x86 specific codes to architecture directory

[Shannon Zhao]

From: Shannon Zhao 

Move x86 specific codes to architecture directory and export those EFI
runtime service functions. This will be useful for initializing runtime
service on ARM later.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
 arch/x86/xen/efi.c| 112 
 drivers/xen/efi.c | 174 ++
 include/xen/xen-ops.h |  30 ++---
 3 files changed, 168 insertions(+), 148 deletions(-)

diff --git a/arch/x86/xen/efi.c b/arch/x86/xen/efi.c
index be14cc3..86527f1 100644
--- a/arch/x86/xen/efi.c
+++ b/arch/x86/xen/efi.c
@@ -20,10 +20,122 @@
 #include 
 #include 
 
+#include 
 #include 
+#include 
 
 #include 
 #include 
+#include 
+
+static efi_char16_t vendor[100] __initdata;
+
+static efi_system_table_t efi_systab_xen __initdata = {
+   .hdr = {
+   .signature  = EFI_SYSTEM_TABLE_SIGNATURE,
+   .revision   = 0, /* Initialized later. */
+   .headersize = 0, /* Ignored by Linux Kernel. */
+   .crc32  = 0, /* Ignored by Linux Kernel. */
+   .reserved   = 0
+   },
+   .fw_vendor  = EFI_INVALID_TABLE_ADDR, /* Initialized later. */
+   .fw_revision= 0,  /* Initialized later. */
+   .con_in_handle  = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
+   .con_in = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
+   .con_out_handle = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
+   .con_out= EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
+   .stderr_handle  = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
+   .stderr = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
+   .runtime= (efi_runtime_services_t *)EFI_INVALID_TABLE_ADDR,
+ /* Not used under Xen. */
+   .boottime   = (efi_boot_services_t *)EFI_INVALID_TABLE_ADDR,
+ /* Not used under Xen. */
+   .nr_tables  = 0,  /* Initialized later. */
+   .tables = EFI_INVALID_TABLE_ADDR  /* Initialized later. */
+};
+
+static const struct efi efi_xen __initconst = {
+   .systab   = NULL, /* Initialized later. */
+   .runtime_version  = 0,/* Initialized later. */
+   .mps  = EFI_INVALID_TABLE_ADDR,
+   .acpi = EFI_INVALID_TABLE_ADDR,
+   .acpi20   = EFI_INVALID_TABLE_ADDR,
+   .smbios   = EFI_INVALID_TABLE_ADDR,
+   .smbios3  = EFI_INVALID_TABLE_ADDR,
+   .sal_systab   = EFI_INVALID_TABLE_ADDR,
+   .boot_info= EFI_INVALID_TABLE_ADDR,
+   .hcdp = EFI_INVALID_TABLE_ADDR,
+   .uga  = EFI_INVALID_TABLE_ADDR,
+   .uv_systab= EFI_INVALID_TABLE_ADDR,
+   .fw_vendor= EFI_INVALID_TABLE_ADDR,
+   .runtime  = EFI_INVALID_TABLE_ADDR,
+   .config_table = EFI_INVALID_TABLE_ADDR,
+   .get_time = xen_efi_get_time,
+   .set_time = xen_efi_set_time,
+   .get_wakeup_time  = xen_efi_get_wakeup_time,
+   .set_wakeup_time  = xen_efi_set_wakeup_time,
+   .get_variable = xen_efi_get_variable,
+   .get_next_variable= xen_efi_get_next_variable,
+   .set_variable = xen_efi_set_variable,
+   .query_variable_info  = xen_efi_query_variable_info,
+   .update_capsule   = xen_efi_update_capsule,
+   .query_capsule_caps   = xen_efi_query_capsule_caps,
+   .get_next_high_mono_count = xen_efi_get_next_high_mono_count,
+   .reset_system = NULL, /* Functionality provided by Xen. */
+   .set_virtual_address_map  = NULL, /* Not used under Xen. */
+   .memmap   = NULL, /* Not used under Xen. */
+   .flags= 0 /* Initialized later. */
+};
+
+static efi_system_table_t __init *xen_efi_probe(void)
+{
+   struct xen_platform_op op = {
+   .cmd = XENPF_firmware_info,
+   .u.firmware_info = {
+   .type = XEN_FW_EFI_INFO,
+   .index = XEN_FW_EFI_CONFIG_TABLE
+   }
+   };
+   union xenpf_efi_info *info = _info.u.efi_info;
+
+   if (!xen_initial_domain() || HYPERVISOR_platform_op() < 0)
+   return NULL;
+
+   /* Here we know that Xen runs on EFI platform. */
+
+   efi = efi_xen;
+
+   efi_systab_xen.tables = info->cfg.addr;
+   efi_systab_xen.nr_tables = info->cfg.nent;
+
+   op.cmd = XENPF_firmware_info;
+   op.u.firmware_info.type = XEN_FW_EFI_INFO;
+   

[Xen-devel] [PATCH v5 15/17] ARM64: XEN: Add a function to initialize Xen specific UEFI runtime services

[Shannon Zhao]

From: Shannon Zhao 

When running on Xen hypervisor, runtime services are supported through
hypercall. Add a Xen specific function to initialize runtime services.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
 arch/arm/include/asm/xen/xen-ops.h   |  6 ++
 arch/arm/xen/Makefile|  1 +
 arch/arm/xen/efi.c   | 40 
 arch/arm64/include/asm/xen/xen-ops.h |  6 ++
 arch/arm64/xen/Makefile  |  1 +
 drivers/xen/Kconfig  |  2 +-
 6 files changed, 55 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/include/asm/xen/xen-ops.h
 create mode 100644 arch/arm/xen/efi.c
 create mode 100644 arch/arm64/include/asm/xen/xen-ops.h

diff --git a/arch/arm/include/asm/xen/xen-ops.h 
b/arch/arm/include/asm/xen/xen-ops.h
new file mode 100644
index 000..ec154e7
--- /dev/null
+++ b/arch/arm/include/asm/xen/xen-ops.h
@@ -0,0 +1,6 @@
+#ifndef _ASM_XEN_OPS_H
+#define _ASM_XEN_OPS_H
+
+void xen_efi_runtime_setup(void);
+
+#endif /* _ASM_XEN_OPS_H */
diff --git a/arch/arm/xen/Makefile b/arch/arm/xen/Makefile
index 1296952..2279521 100644
--- a/arch/arm/xen/Makefile
+++ b/arch/arm/xen/Makefile
@@ -1 +1,2 @@
 obj-y  := enlighten.o hypercall.o grant-table.o p2m.o mm.o
+obj-$(CONFIG_XEN_EFI) += efi.o
diff --git a/arch/arm/xen/efi.c b/arch/arm/xen/efi.c
new file mode 100644
index 000..16db419
--- /dev/null
+++ b/arch/arm/xen/efi.c
@@ -0,0 +1,40 @@
+/*
+ * Copyright (c) 2015, Linaro Limited, Shannon Zhao
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+
+/* Set XEN EFI runtime services function pointers. Other fields of struct efi,
+ * e.g. efi.systab, will be set like normal EFI.
+ */
+void __init xen_efi_runtime_setup(void)
+{
+   efi.get_time = xen_efi_get_time;
+   efi.set_time = xen_efi_set_time;
+   efi.get_wakeup_time  = xen_efi_get_wakeup_time;
+   efi.set_wakeup_time  = xen_efi_set_wakeup_time;
+   efi.get_variable = xen_efi_get_variable;
+   efi.get_next_variable= xen_efi_get_next_variable;
+   efi.set_variable = xen_efi_set_variable;
+   efi.query_variable_info  = xen_efi_query_variable_info;
+   efi.update_capsule   = xen_efi_update_capsule;
+   efi.query_capsule_caps   = xen_efi_query_capsule_caps;
+   efi.get_next_high_mono_count = xen_efi_get_next_high_mono_count;
+   efi.reset_system = NULL; /* Functionality provided by Xen. 
*/
+}
+EXPORT_SYMBOL_GPL(xen_efi_runtime_setup);
diff --git a/arch/arm64/include/asm/xen/xen-ops.h 
b/arch/arm64/include/asm/xen/xen-ops.h
new file mode 100644
index 000..ec154e7
--- /dev/null
+++ b/arch/arm64/include/asm/xen/xen-ops.h
@@ -0,0 +1,6 @@
+#ifndef _ASM_XEN_OPS_H
+#define _ASM_XEN_OPS_H
+
+void xen_efi_runtime_setup(void);
+
+#endif /* _ASM_XEN_OPS_H */
diff --git a/arch/arm64/xen/Makefile b/arch/arm64/xen/Makefile
index 74a8d87..8ff8aa9 100644
--- a/arch/arm64/xen/Makefile
+++ b/arch/arm64/xen/Makefile
@@ -1,2 +1,3 @@
 xen-arm-y  += $(addprefix ../../arm/xen/, enlighten.o grant-table.o p2m.o 
mm.o)
 obj-y  := xen-arm.o hypercall.o
+obj-$(CONFIG_XEN_EFI) += $(addprefix ../../arm/xen/, efi.o)
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 73708ac..d50571c 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -268,7 +268,7 @@ config XEN_HAVE_PVMMU
 
 config XEN_EFI
def_bool y
-   depends on X86_64 && EFI
+   depends on (ARM || ARM64 || X86_64) && EFI
 
 config XEN_AUTO_XLATE
def_bool y
-- 
2.0.4



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

[Xen-devel] [PATCH v5 11/17] ARM: XEN: Move xen_early_init() before efi_init()

[Shannon Zhao]

From: Shannon Zhao 

Move xen_early_init() before efi_init(), then when calling efi_init()
could initialize Xen specific UEFI.

Check if it runs on Xen hypervisor through the flat dts.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
 arch/arm/xen/enlighten.c  | 56 ++-
 arch/arm64/kernel/setup.c |  2 +-
 2 files changed, 42 insertions(+), 16 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 807a93e..0e542b8 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -53,8 +54,6 @@ struct xen_memory_region 
xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] __initdata;
 
 static __read_mostly unsigned int xen_events_irq;
 
-static __initdata struct device_node *xen_node;
-
 int xen_remap_domain_gfn_array(struct vm_area_struct *vma,
   unsigned long addr,
   xen_pfn_t *gfn, int nr,
@@ -238,6 +237,33 @@ static irqreturn_t xen_arm_callback(int irq, void *arg)
return IRQ_HANDLED;
 }
 
+static __initdata struct {
+   const char *compat;
+   const char *prefix;
+   const char *version;
+   bool found;
+} hyper_node = {"xen,xen", "xen,xen-", NULL, false};
+
+static int __init fdt_find_hyper_node(unsigned long node, const char *uname,
+ int depth, void *data)
+{
+   const void *s = NULL;
+   int len;
+
+   if (depth != 1 || strcmp(uname, "hypervisor") != 0)
+   return 0;
+
+   if (of_flat_dt_is_compatible(node, hyper_node.compat))
+   hyper_node.found = true;
+
+   s = of_get_flat_dt_prop(node, "compatible", );
+   if (strlen(hyper_node.prefix) + 3  < len &&
+   !strncmp(hyper_node.prefix, s, strlen(hyper_node.prefix)))
+   hyper_node.version = s + strlen(hyper_node.prefix);
+
+   return 0;
+}
+
 /*
  * see Documentation/devicetree/bindings/arm/xen.txt for the
  * documentation of the Xen Device Tree format.
@@ -245,26 +271,18 @@ static irqreturn_t xen_arm_callback(int irq, void *arg)
 #define GRANT_TABLE_PHYSADDR 0
 void __init xen_early_init(void)
 {
-   int len;
-   const char *s = NULL;
-   const char *version = NULL;
-   const char *xen_prefix = "xen,xen-";
-
-   xen_node = of_find_compatible_node(NULL, NULL, "xen,xen");
-   if (!xen_node) {
+   of_scan_flat_dt(fdt_find_hyper_node, NULL);
+   if (!hyper_node.found) {
pr_debug("No Xen support\n");
return;
}
-   s = of_get_property(xen_node, "compatible", );
-   if (strlen(xen_prefix) + 3  < len &&
-   !strncmp(xen_prefix, s, strlen(xen_prefix)))
-   version = s + strlen(xen_prefix);
-   if (version == NULL) {
+
+   if (hyper_node.version == NULL) {
pr_debug("Xen version not found\n");
return;
}
 
-   pr_info("Xen %s support found\n", version);
+   pr_info("Xen %s support found\n", hyper_node.version);
 
xen_domain_type = XEN_HVM_DOMAIN;
 
@@ -305,6 +323,14 @@ static void __init xen_acpi_guest_init(void)
 
 static void __init xen_dt_guest_init(void)
 {
+   struct device_node *xen_node;
+
+   xen_node = of_find_compatible_node(NULL, NULL, "xen,xen");
+   if (!xen_node) {
+   pr_err("Xen support was detected before, but it has 
disappeared\n");
+   return;
+   }
+
xen_events_irq = irq_of_parse_and_map(xen_node, 0);
 }
 
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 8119479..a4a2878 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -313,6 +313,7 @@ void __init setup_arch(char **cmdline_p)
 */
local_async_enable();
 
+   xen_early_init();
efi_init();
arm64_memblock_init();
 
@@ -334,7 +335,6 @@ void __init setup_arch(char **cmdline_p)
} else {
psci_acpi_init();
}
-   xen_early_init();
 
cpu_read_bootcpu_ops();
smp_init_cpus();
-- 
2.0.4



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

[Xen-devel] [PATCH v5 10/17] arm/xen: Get event-channel irq through HVM_PARAM when booting with ACPI

[Shannon Zhao]

From: Shannon Zhao 

When booting with ACPI, it could get the event-channel irq through
HVM_PARAM_CALLBACK_IRQ.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
 arch/arm/xen/enlighten.c | 36 +++-
 1 file changed, 35 insertions(+), 1 deletion(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index d94f726..807a93e 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -278,6 +279,35 @@ void __init xen_early_init(void)
add_preferred_console("hvc", 0, NULL);
 }
 
+static void __init xen_acpi_guest_init(void)
+{
+#ifdef CONFIG_ACPI
+   struct xen_hvm_param a;
+   int interrupt, trigger, polarity;
+
+   a.domid = DOMID_SELF;
+   a.index = HVM_PARAM_CALLBACK_IRQ;
+   xen_events_irq = 0;
+
+   if (!HYPERVISOR_hvm_op(HVMOP_get_param, )) {
+   if ((a.value >> 56) == HVM_PARAM_CALLBACK_TYPE_EVENT) {
+   interrupt = a.value & 0xff;
+   trigger = ((a.value >> 8) & 0x1) ? ACPI_EDGE_SENSITIVE
+: ACPI_LEVEL_SENSITIVE;
+   polarity = ((a.value >> 8) & 0x2) ? ACPI_ACTIVE_LOW
+ : ACPI_ACTIVE_HIGH;
+   xen_events_irq = acpi_register_gsi(NULL, interrupt,
+  trigger, polarity);
+   }
+   }
+#endif
+}
+
+static void __init xen_dt_guest_init(void)
+{
+   xen_events_irq = irq_of_parse_and_map(xen_node, 0);
+}
+
 static int __init xen_guest_init(void)
 {
struct xen_add_to_physmap xatp;
@@ -286,7 +316,11 @@ static int __init xen_guest_init(void)
if (!xen_domain())
return 0;
 
-   xen_events_irq = irq_of_parse_and_map(xen_node, 0);
+   if (!acpi_disabled)
+   xen_acpi_guest_init();
+   else
+   xen_dt_guest_init();
+
if (!xen_events_irq) {
pr_err("Xen event channel interrupt not found\n");
return -ENODEV;
-- 
2.0.4



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

[Xen-devel] [PATCH v5 03/17] Xen: xlate: Use page_to_xen_pfn instead of page_to_pfn

[Shannon Zhao]

From: Shannon Zhao 

Make xen_xlate_map_ballooned_pages work with 64K pages. In that case
Kernel pages are 64K in size but Xen pages remain 4K in size. Xen pfns
refer to 4K pages.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
 drivers/xen/xlate_mmu.c | 26 --
 1 file changed, 16 insertions(+), 10 deletions(-)

diff --git a/drivers/xen/xlate_mmu.c b/drivers/xen/xlate_mmu.c
index 9692656..28f728b 100644
--- a/drivers/xen/xlate_mmu.c
+++ b/drivers/xen/xlate_mmu.c
@@ -207,9 +207,12 @@ int __init xen_xlate_map_ballooned_pages(xen_pfn_t **gfns, 
void **virt,
void *vaddr;
int rc;
unsigned int i;
+   unsigned long nr_pages;
+   xen_pfn_t xen_pfn = 0;
 
BUG_ON(nr_grant_frames == 0);
-   pages = kcalloc(nr_grant_frames, sizeof(pages[0]), GFP_KERNEL);
+   nr_pages = DIV_ROUND_UP(nr_grant_frames, XEN_PFN_PER_PAGE);
+   pages = kcalloc(nr_pages, sizeof(pages[0]), GFP_KERNEL);
if (!pages)
return -ENOMEM;
 
@@ -218,22 +221,25 @@ int __init xen_xlate_map_ballooned_pages(xen_pfn_t 
**gfns, void **virt,
kfree(pages);
return -ENOMEM;
}
-   rc = alloc_xenballooned_pages(nr_grant_frames, pages);
+   rc = alloc_xenballooned_pages(nr_pages, pages);
if (rc) {
-   pr_warn("%s Couldn't balloon alloc %ld pfns rc:%d\n", __func__,
-   nr_grant_frames, rc);
+   pr_warn("%s Couldn't balloon alloc %ld pages rc:%d\n", __func__,
+   nr_pages, rc);
kfree(pages);
kfree(pfns);
return rc;
}
-   for (i = 0; i < nr_grant_frames; i++)
-   pfns[i] = page_to_pfn(pages[i]);
+   for (i = 0; i < nr_grant_frames; i++) {
+   if ((i % XEN_PFN_PER_PAGE) == 0)
+   xen_pfn = page_to_xen_pfn(pages[i / XEN_PFN_PER_PAGE]);
+   pfns[i] = pfn_to_gfn(xen_pfn++);
+   }
 
-   vaddr = vmap(pages, nr_grant_frames, 0, PAGE_KERNEL);
+   vaddr = vmap(pages, nr_pages, 0, PAGE_KERNEL);
if (!vaddr) {
-   pr_warn("%s Couldn't map %ld pfns rc:%d\n", __func__,
-   nr_grant_frames, rc);
-   free_xenballooned_pages(nr_grant_frames, pages);
+   pr_warn("%s Couldn't map %ld pages rc:%d\n", __func__,
+   nr_pages, rc);
+   free_xenballooned_pages(nr_pages, pages);
kfree(pages);
kfree(pfns);
return -ENOMEM;
-- 
2.0.4



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

[Xen-devel] [PATCH v5 08/17] Xen: public/hvm: sync changes of HVM_PARAM_CALLBACK_VIA ABI from Xen

[Shannon Zhao]

From: Shannon Zhao 

Sync the changes of HVM_PARAM_CALLBACK_VIA ABI introduced by
Xen commit  (public/hvm: export the HVM_PARAM_CALLBACK_VIA
ABI in the API).

Signed-off-by: Shannon Zhao 
Acked-by: Stefano Stabellini 
---
 include/xen/interface/hvm/params.h | 27 +--
 1 file changed, 21 insertions(+), 6 deletions(-)

diff --git a/include/xen/interface/hvm/params.h 
b/include/xen/interface/hvm/params.h
index a6c7991..70ad208 100644
--- a/include/xen/interface/hvm/params.h
+++ b/include/xen/interface/hvm/params.h
@@ -27,16 +27,31 @@
  * Parameter space for HVMOP_{set,get}_param.
  */
 
+#define HVM_PARAM_CALLBACK_IRQ 0
 /*
  * How should CPU0 event-channel notifications be delivered?
- * val[63:56] == 0: val[55:0] is a delivery GSI (Global System Interrupt).
- * val[63:56] == 1: val[55:0] is a delivery PCI INTx line, as follows:
- *  Domain = val[47:32], Bus  = val[31:16],
- *  DevFn  = val[15: 8], IntX = val[ 1: 0]
- * val[63:56] == 2: val[7:0] is a vector number.
+ *
  * If val == 0 then CPU0 event-channel notifications are not delivered.
+ * If val != 0, val[63:56] encodes the type, as follows:
+ */
+
+#define HVM_PARAM_CALLBACK_TYPE_GSI  0
+/*
+ * val[55:0] is a delivery GSI.  GSI 0 cannot be used, as it aliases val == 0,
+ * and disables all notifications.
+ */
+
+#define HVM_PARAM_CALLBACK_TYPE_PCI_INTX 1
+/*
+ * val[55:0] is a delivery PCI INTx line:
+ * Domain = val[47:32], Bus = val[31:16] DevFn = val[15:8], IntX = val[1:0]
+ */
+
+#define HVM_PARAM_CALLBACK_TYPE_VECTOR   2
+/*
+ * val[7:0] is a vector number.  Check for XENFEAT_hvm_callback_vector to know
+ * if this delivery method is available.
  */
-#define HVM_PARAM_CALLBACK_IRQ 0
 
 #define HVM_PARAM_STORE_PFN1
 #define HVM_PARAM_STORE_EVTCHN 2
-- 
2.0.4



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

[Xen-devel] [PATCH v5 05/17] xen: memory : Add new XENMAPSPACE type XENMAPSPACE_dev_mmio

[Shannon Zhao]

From: Shannon Zhao 

Add a new type of Xen map space for Dom0 to map device's MMIO region.

Signed-off-by: Shannon Zhao 
---
 include/xen/interface/memory.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
index 2ecfe4f..9aa8988 100644
--- a/include/xen/interface/memory.h
+++ b/include/xen/interface/memory.h
@@ -160,6 +160,7 @@ DEFINE_GUEST_HANDLE_STRUCT(xen_machphys_mapping_t);
 #define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another dom,
* XENMEM_add_to_physmap_range only.
*/
+#define XENMAPSPACE_dev_mmio 5 /* device mmio region */
 
 /*
  * Sets the GPFN at which a particular page appears in the specified guest's
-- 
2.0.4



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

[Xen-devel] [PATCH v5 12/17] ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI

[Shannon Zhao]

From: Shannon Zhao 

When it's a Xen domain0 booting with ACPI, it will supply a /chosen and
a /hypervisor node in DT. So check if it needs to enable ACPI.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
Acked-by: Hanjun Guo 
---
 arch/arm64/kernel/acpi.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index d1ce8e2..4e92be0 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -67,10 +67,13 @@ static int __init dt_scan_depth1_nodes(unsigned long node,
 {
/*
 * Return 1 as soon as we encounter a node at depth 1 that is
-* not the /chosen node.
+* not the /chosen node, or /hypervisor node when running on Xen.
 */
-   if (depth == 1 && (strcmp(uname, "chosen") != 0))
-   return 1;
+   if (depth == 1 && (strcmp(uname, "chosen") != 0)) {
+   if (!xen_initial_domain() || (strcmp(uname, "hypervisor") != 0))
+   return 1;
+   }
+
return 0;
 }
 
@@ -184,7 +187,8 @@ void __init acpi_boot_table_init(void)
/*
 * Enable ACPI instead of device tree unless
 * - ACPI has been disabled explicitly (acpi=off), or
-* - the device tree is not empty (it has more than just a /chosen node)
+* - the device tree is not empty (it has more than just a /chosen node,
+*   and a /hypervisor node when running on Xen)
 *   and ACPI has not been force enabled (acpi=force)
 */
if (param_acpi_off ||
-- 
2.0.4



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

[Xen-devel] [PATCH v5 06/17] Xen: ARM: Add support for mapping platform device mmio

[Shannon Zhao]

From: Shannon Zhao 

Add a bus_notifier for platform bus device in order to map the device
mmio regions when DOM0 booting with ACPI.

Signed-off-by: Shannon Zhao 
Acked-by: Stefano Stabellini 
---
 drivers/xen/Makefile |   1 +
 drivers/xen/arm-device.c | 141 +++
 2 files changed, 142 insertions(+)
 create mode 100644 drivers/xen/arm-device.c

diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 9b7a35c..415f286 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -9,6 +9,7 @@ CFLAGS_features.o   := $(nostackp)
 
 CFLAGS_efi.o   += -fshort-wchar
 
+dom0-$(CONFIG_ARM64) += arm-device.o
 dom0-$(CONFIG_PCI) += pci.o
 dom0-$(CONFIG_USB_SUPPORT) += dbgp.o
 dom0-$(CONFIG_XEN_ACPI) += acpi.o $(xen-pad-y)
diff --git a/drivers/xen/arm-device.c b/drivers/xen/arm-device.c
new file mode 100644
index 000..76e26e5
--- /dev/null
+++ b/drivers/xen/arm-device.c
@@ -0,0 +1,141 @@
+/*
+ * Copyright (c) 2015, Linaro Limited, Shannon Zhao
+ *
+ * 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
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int xen_unmap_device_mmio(struct resource *resource, unsigned int count)
+{
+   unsigned int i, j, nr;
+   int rc = 0;
+   struct resource *r;
+   struct xen_remove_from_physmap xrp;
+
+   for (i = 0; i < count; i++) {
+   r = [i];
+   nr = DIV_ROUND_UP(resource_size(r), XEN_PAGE_SIZE);
+   if ((resource_type(r) != IORESOURCE_MEM) || (nr == 0))
+   continue;
+
+   for (j = 0; j < nr; j++) {
+   xrp.domid = DOMID_SELF;
+   xrp.gpfn = XEN_PFN_DOWN(r->start) + j;
+   rc = HYPERVISOR_memory_op(XENMEM_remove_from_physmap,
+ );
+   if (rc)
+   return rc;
+   }
+   }
+
+   return rc;
+}
+
+static int xen_map_device_mmio(struct resource *resource, unsigned int count)
+{
+   unsigned int i, j, nr;
+   int rc = 0;
+   struct resource *r;
+   xen_pfn_t *gpfns;
+   xen_ulong_t *idxs;
+   int *errs;
+   struct xen_add_to_physmap_range xatp;
+
+   for (i = 0; i < count; i++) {
+   r = [i];
+   nr = DIV_ROUND_UP(resource_size(r), XEN_PAGE_SIZE);
+   if ((resource_type(r) != IORESOURCE_MEM) || (nr == 0))
+   continue;
+
+   gpfns = kzalloc(sizeof(xen_pfn_t) * nr, GFP_KERNEL);
+   idxs = kzalloc(sizeof(xen_ulong_t) * nr, GFP_KERNEL);
+   errs = kzalloc(sizeof(int) * nr, GFP_KERNEL);
+   if (!gpfns || !idxs || !errs) {
+   kfree(gpfns);
+   kfree(idxs);
+   kfree(errs);
+   return -ENOMEM;
+   }
+
+   for (j = 0; j < nr; j++) {
+   gpfns[j] = XEN_PFN_DOWN(r->start) + j;
+   idxs[j] = XEN_PFN_DOWN(r->start) + j;
+   }
+
+   xatp.domid = DOMID_SELF;
+   xatp.size = nr;
+   xatp.space = XENMAPSPACE_dev_mmio;
+
+   set_xen_guest_handle(xatp.gpfns, gpfns);
+   set_xen_guest_handle(xatp.idxs, idxs);
+   set_xen_guest_handle(xatp.errs, errs);
+
+   rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap_range, );
+   kfree(gpfns);
+   kfree(idxs);
+   kfree(errs);
+   if (rc)
+   return rc;
+   }
+
+   return rc;
+}
+
+static int xen_platform_notifier(struct notifier_block *nb,
+unsigned long action, void *data)
+{
+   struct platform_device *pdev = to_platform_device(data);
+   int r = 0;
+
+   if (pdev->num_resources == 0 || pdev->resource == NULL)
+   return NOTIFY_OK;
+
+   switch (action) {
+   case BUS_NOTIFY_ADD_DEVICE:
+   r = xen_map_device_mmio(pdev->resource, pdev->num_resources);
+   break;
+   case BUS_NOTIFY_DEL_DEVICE:
+   r = xen_unmap_device_mmio(pdev->resource, pdev->num_resources);
+   break;
+   

[Xen-devel] [PATCH v5 07/17] Xen: ARM: Add support for mapping AMBA device mmio

[Shannon Zhao]

From: Shannon Zhao 

Add a bus_notifier for AMBA bus device in order to map the device
mmio regions when DOM0 booting with ACPI.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
 drivers/xen/arm-device.c | 43 +++
 1 file changed, 43 insertions(+)

diff --git a/drivers/xen/arm-device.c b/drivers/xen/arm-device.c
index 76e26e5..3854043 100644
--- a/drivers/xen/arm-device.c
+++ b/drivers/xen/arm-device.c
@@ -139,3 +139,46 @@ static int __init register_xen_platform_notifier(void)
 }
 
 arch_initcall(register_xen_platform_notifier);
+
+#ifdef CONFIG_ARM_AMBA
+#include 
+
+static int xen_amba_notifier(struct notifier_block *nb,
+unsigned long action, void *data)
+{
+   struct amba_device *adev = to_amba_device(data);
+   int r = 0;
+
+   switch (action) {
+   case BUS_NOTIFY_ADD_DEVICE:
+   r = xen_map_device_mmio(>res, 1);
+   break;
+   case BUS_NOTIFY_DEL_DEVICE:
+   r = xen_unmap_device_mmio(>res, 1);
+   break;
+   default:
+   return NOTIFY_DONE;
+   }
+   if (r)
+   dev_err(>dev, "AMBA: Failed to %s device %s MMIO!\n",
+   action == BUS_NOTIFY_ADD_DEVICE ? "map" :
+   (action == BUS_NOTIFY_DEL_DEVICE ? "unmap" : "?"),
+   adev->dev.init_name);
+
+   return NOTIFY_OK;
+}
+
+static struct notifier_block amba_device_nb = {
+   .notifier_call = xen_amba_notifier,
+};
+
+static int __init register_xen_amba_notifier(void)
+{
+   if (!xen_initial_domain() || acpi_disabled)
+   return 0;
+
+   return bus_register_notifier(_bustype, _device_nb);
+}
+
+arch_initcall(register_xen_amba_notifier);
+#endif
-- 
2.0.4



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

[Xen-devel] [PATCH v5 09/17] xen/hvm/params: Add a new delivery type for event-channel in HVM_PARAM_CALLBACK_IRQ

[Shannon Zhao]

From: Shannon Zhao 

Add a new delivery type:
val[63:56] == 3: val[15:8] is flag: val[7:0] is a PPI.
To the flag, bit 0 stands the interrupt mode is edge(1) or level(0) and
bit 1 stands the interrupt polarity is active low(1) or high(0).

Signed-off-by: Shannon Zhao 
Acked-by: Stefano Stabellini 
---
 include/xen/interface/hvm/params.h | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/include/xen/interface/hvm/params.h 
b/include/xen/interface/hvm/params.h
index 70ad208..d32b02b 100644
--- a/include/xen/interface/hvm/params.h
+++ b/include/xen/interface/hvm/params.h
@@ -53,6 +53,16 @@
  * if this delivery method is available.
  */
 
+#define HVM_PARAM_CALLBACK_TYPE_EVENT3
+/*
+ * val[55:16] need to be zero.
+ * val[15:8] is flag of event-channel interrupt:
+ *  bit 8: interrupt is edge(1) or level(0) triggered
+ *  bit 9: interrupt is active low(1) or high(0)
+ * val[7:0] is PPI number used by event-channel.
+ * This is only used by ARM/ARM64.
+ */
+
 #define HVM_PARAM_STORE_PFN1
 #define HVM_PARAM_STORE_EVTCHN 2
 
-- 
2.0.4



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

[Xen-devel] [PATCH v5 00/17] Add ACPI support for Xen Dom0 on ARM64

[Shannon Zhao]

From: Shannon Zhao 

This patch set adds ACPI support for Xen Dom0 on ARM64. The relevant Xen
ACPI on ARM64 design document could be found from [1].

This patch set adds a new FDT node "uefi" under /hypervisor to pass UEFI
information. Introduce a bus notifier of AMBA and Platform bus to map
the new added device's MMIO space. Make Xen domain use
xlated_setup_gnttab_pages to setup grant table and a new hypercall to
get event-channel irq.

Regarding the initialization flow of Linux kernel, it needs to move
xen_early_init() before efi_init(). Then xen_early_init() will check
whether it runs on Xen through the /hypervisor node and efi_init() will
call a new function fdt_find_xen_uefi_params(), to parse those
xen,uefi-* parameters just like the existing efi_get_fdt_params().

And in arm64_enable_runtime_services() it will check whether it runs on
Xen and call another new function xen_efi_runtime_setup() to setup
runtime service instead of efi_native_runtime_setup(). The
xen_efi_runtime_setup() will assign the runtime function pointers with
the functions of driver/xen/efi.c.

And since we pass a /hypervisor node and a /chosen node to Dom0, it
needs to check whether the DTS only contains a /hypervisor node and a
/chosen node in acpi_boot_table_init().

Patches are tested on FVP base model.

Thanks,
Shannon

[1] http://lists.xen.org/archives/html/xen-devel/2015-11/msg00488.html

Changes since v4:
* rebase on linux master
* move the check acpi_device_should_be_hidden into
  acpi_bus_type_and_status (patch 1)
* use existing function fdt_subnode_offset (patch 16)

Changes since v3:
* rebase on linux master
* print a warning when there is no SPCR table
* rephase the commit message of PATCH 3
* rephase the words of PATCH 13
* use strcmp and factor the function in PATCH 16
* Add several ACKs and RBs, thanks a lot


Changes since v2:
* Use 0 to check if it should ignore the UART
* Fix the use of page_to_xen_pfn
* Factor ACPI and DT parts in xen_guest_init
* Check "uefi" node by full path
* Fix the statement of Documentation/devicetree/bindings/arm/xen.txt

Changes since v1:
* Rebase on linux mainline and wallclock patch from Stefano
* Refactor AMBA and platform device MMIO map to one file
* Use EFI_PARAVIRT to check if it supports XEN EFI
* Refactor Xen EFI codes
* Address other comments

Shannon Zhao (17):
  Xen: ACPI: Hide UART used by Xen
  xen/grant-table: Move xlated_setup_gnttab_pages to common place
  Xen: xlate: Use page_to_xen_pfn instead of page_to_pfn
  arm/xen: Use xen_xlate_map_ballooned_pages to setup grant table
  xen: memory : Add new XENMAPSPACE type XENMAPSPACE_dev_mmio
  Xen: ARM: Add support for mapping platform device mmio
  Xen: ARM: Add support for mapping AMBA device mmio
  Xen: public/hvm: sync changes of HVM_PARAM_CALLBACK_VIA ABI from Xen
  xen/hvm/params: Add a new delivery type for event-channel in
HVM_PARAM_CALLBACK_IRQ
  arm/xen: Get event-channel irq through HVM_PARAM when booting with
ACPI
  ARM: XEN: Move xen_early_init() before efi_init()
  ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI
  ARM: Xen: Document UEFI support on Xen ARM virtual platforms
  XEN: EFI: Move x86 specific codes to architecture directory
  ARM64: XEN: Add a function to initialize Xen specific UEFI runtime
services
  FDT: Add a helper to get the subnode by given name
  Xen: EFI: Parse DT parameters for Xen specific UEFI

 Documentation/devicetree/bindings/arm/xen.txt |  33 +
 arch/arm/include/asm/xen/xen-ops.h|   6 +
 arch/arm/xen/Makefile |   1 +
 arch/arm/xen/efi.c|  40 ++
 arch/arm/xen/enlighten.c  | 109 +++
 arch/arm64/include/asm/xen/xen-ops.h  |   6 +
 arch/arm64/kernel/acpi.c  |  12 +-
 arch/arm64/kernel/setup.c |   2 +-
 arch/arm64/xen/Makefile   |   1 +
 arch/x86/xen/efi.c| 112 
 arch/x86/xen/grant-table.c|  57 +---
 drivers/acpi/scan.c   |  68 ++
 drivers/firmware/efi/arm-runtime.c|  17 ++-
 drivers/firmware/efi/efi.c|  45 ++-
 drivers/of/fdt.c  |  13 ++
 drivers/xen/Kconfig   |   2 +-
 drivers/xen/Makefile  |   1 +
 drivers/xen/arm-device.c  | 184 ++
 drivers/xen/efi.c | 174 +---
 drivers/xen/xlate_mmu.c   |  67 ++
 include/linux/of_fdt.h|   2 +
 include/xen/interface/hvm/params.h|  37 +-
 include/xen/interface/memory.h|   1 +
 include/xen/xen-ops.h |  32 +++--
 24 files changed, 775 insertions(+), 247 deletions(-)
 create mode 100644 arch/arm/include/asm/xen/xen-ops.h
 create 

[Xen-devel] [PATCH v5 04/17] arm/xen: Use xen_xlate_map_ballooned_pages to setup grant table

[Shannon Zhao]

From: Shannon Zhao 

Use xen_xlate_map_ballooned_pages to setup grant table. Then it doesn't
rely on DT or ACPI to pass the start address and size of grant table.

Signed-off-by: Shannon Zhao 
Acked-by: Stefano Stabellini 
---
 arch/arm/xen/enlighten.c | 13 -
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 75cd734..d94f726 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -282,18 +282,10 @@ static int __init xen_guest_init(void)
 {
struct xen_add_to_physmap xatp;
struct shared_info *shared_info_page = NULL;
-   struct resource res;
-   phys_addr_t grant_frames;
 
if (!xen_domain())
return 0;
 
-   if (of_address_to_resource(xen_node, GRANT_TABLE_PHYSADDR, )) {
-   pr_err("Xen grant table base address not found\n");
-   return -ENODEV;
-   }
-   grant_frames = res.start;
-
xen_events_irq = irq_of_parse_and_map(xen_node, 0);
if (!xen_events_irq) {
pr_err("Xen event channel interrupt not found\n");
@@ -328,7 +320,10 @@ static int __init xen_guest_init(void)
if (xen_vcpu_info == NULL)
return -ENOMEM;
 
-   if (gnttab_setup_auto_xlat_frames(grant_frames)) {
+   xen_auto_xlat_grant_frames.count = gnttab_max_grant_frames();
+   if (xen_xlate_map_ballooned_pages(_auto_xlat_grant_frames.pfn,
+ _auto_xlat_grant_frames.vaddr,
+ xen_auto_xlat_grant_frames.count)) {
free_percpu(xen_vcpu_info);
return -ENOMEM;
}
-- 
2.0.4



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

[Xen-devel] [PATCH v5 02/17] xen/grant-table: Move xlated_setup_gnttab_pages to common place

[Shannon Zhao]

From: Shannon Zhao 

Move xlated_setup_gnttab_pages to common place, so it can be reused by
ARM to setup grant table.

Rename it to xen_xlate_map_ballooned_pages.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
 arch/x86/xen/grant-table.c | 57 +--
 drivers/xen/xlate_mmu.c| 61 ++
 include/xen/xen-ops.h  |  2 ++
 3 files changed, 69 insertions(+), 51 deletions(-)

diff --git a/arch/x86/xen/grant-table.c b/arch/x86/xen/grant-table.c
index e079500..de4144c 100644
--- a/arch/x86/xen/grant-table.c
+++ b/arch/x86/xen/grant-table.c
@@ -111,63 +111,18 @@ int arch_gnttab_init(unsigned long nr_shared)
 }
 
 #ifdef CONFIG_XEN_PVH
-#include 
 #include 
-#include 
-static int __init xlated_setup_gnttab_pages(void)
-{
-   struct page **pages;
-   xen_pfn_t *pfns;
-   void *vaddr;
-   int rc;
-   unsigned int i;
-   unsigned long nr_grant_frames = gnttab_max_grant_frames();
-
-   BUG_ON(nr_grant_frames == 0);
-   pages = kcalloc(nr_grant_frames, sizeof(pages[0]), GFP_KERNEL);
-   if (!pages)
-   return -ENOMEM;
-
-   pfns = kcalloc(nr_grant_frames, sizeof(pfns[0]), GFP_KERNEL);
-   if (!pfns) {
-   kfree(pages);
-   return -ENOMEM;
-   }
-   rc = alloc_xenballooned_pages(nr_grant_frames, pages);
-   if (rc) {
-   pr_warn("%s Couldn't balloon alloc %ld pfns rc:%d\n", __func__,
-   nr_grant_frames, rc);
-   kfree(pages);
-   kfree(pfns);
-   return rc;
-   }
-   for (i = 0; i < nr_grant_frames; i++)
-   pfns[i] = page_to_pfn(pages[i]);
-
-   vaddr = vmap(pages, nr_grant_frames, 0, PAGE_KERNEL);
-   if (!vaddr) {
-   pr_warn("%s Couldn't map %ld pfns rc:%d\n", __func__,
-   nr_grant_frames, rc);
-   free_xenballooned_pages(nr_grant_frames, pages);
-   kfree(pages);
-   kfree(pfns);
-   return -ENOMEM;
-   }
-   kfree(pages);
-
-   xen_auto_xlat_grant_frames.pfn = pfns;
-   xen_auto_xlat_grant_frames.count = nr_grant_frames;
-   xen_auto_xlat_grant_frames.vaddr = vaddr;
-
-   return 0;
-}
-
+#include 
 static int __init xen_pvh_gnttab_setup(void)
 {
if (!xen_pvh_domain())
return -ENODEV;
 
-   return xlated_setup_gnttab_pages();
+   xen_auto_xlat_grant_frames.count = gnttab_max_grant_frames();
+
+   return xen_xlate_map_ballooned_pages(_auto_xlat_grant_frames.pfn,
+_auto_xlat_grant_frames.vaddr,
+xen_auto_xlat_grant_frames.count);
 }
 /* Call it _before_ __gnttab_init as we need to initialize the
  * xen_auto_xlat_grant_frames first. */
diff --git a/drivers/xen/xlate_mmu.c b/drivers/xen/xlate_mmu.c
index 5063c5e..9692656 100644
--- a/drivers/xen/xlate_mmu.c
+++ b/drivers/xen/xlate_mmu.c
@@ -29,6 +29,8 @@
  */
 #include 
 #include 
+#include 
+#include 
 
 #include 
 #include 
@@ -37,6 +39,7 @@
 #include 
 #include 
 #include 
+#include 
 
 typedef void (*xen_gfn_fn_t)(unsigned long gfn, void *data);
 
@@ -185,3 +188,61 @@ int xen_xlate_unmap_gfn_range(struct vm_area_struct *vma,
return 0;
 }
 EXPORT_SYMBOL_GPL(xen_xlate_unmap_gfn_range);
+
+/**
+ * xen_xlate_map_ballooned_pages - map a new set of ballooned pages
+ * @gfns: returns the array of corresponding GFNs
+ * @virt: returns the virtual address of the mapped region
+ * @nr_grant_frames: number of GFNs
+ * @return 0 on success, error otherwise
+ *
+ * This allocates a set of ballooned pages and maps them into the
+ * kernel's address space.
+ */
+int __init xen_xlate_map_ballooned_pages(xen_pfn_t **gfns, void **virt,
+unsigned long nr_grant_frames)
+{
+   struct page **pages;
+   xen_pfn_t *pfns;
+   void *vaddr;
+   int rc;
+   unsigned int i;
+
+   BUG_ON(nr_grant_frames == 0);
+   pages = kcalloc(nr_grant_frames, sizeof(pages[0]), GFP_KERNEL);
+   if (!pages)
+   return -ENOMEM;
+
+   pfns = kcalloc(nr_grant_frames, sizeof(pfns[0]), GFP_KERNEL);
+   if (!pfns) {
+   kfree(pages);
+   return -ENOMEM;
+   }
+   rc = alloc_xenballooned_pages(nr_grant_frames, pages);
+   if (rc) {
+   pr_warn("%s Couldn't balloon alloc %ld pfns rc:%d\n", __func__,
+   nr_grant_frames, rc);
+   kfree(pages);
+   kfree(pfns);
+   return rc;
+   }
+   for (i = 0; i < nr_grant_frames; i++)
+   pfns[i] = page_to_pfn(pages[i]);
+
+   vaddr = vmap(pages, nr_grant_frames, 0, PAGE_KERNEL);
+   if (!vaddr) {
+   pr_warn("%s Couldn't map %ld pfns rc:%d\n", 

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

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  03720ea541382a3ca80eaaec2aa11932b03aacaf
baseline version:
 xen  7ba900efe5f526c941b1ca055e5347947bb7eb4b

Last test of basis85080  2016-03-02 16:00:54 Z1 days
Testing same since85178  2016-03-03 09:20:13 Z0 days   10 attempts


People who touched revisions under test:
  Andrew Cooper 
  Aravind Gopalakrishnan 
  Boris Ostrovsky 
  Dario Faggioli 
  Hanjun Guo 
  Jan Beulich 
  Juergen Gross 
  Naresh Bhat 
  Parth Dixit 
  Shannon Zhao 
  Shannon Zhao 
  Stefano Stabellini 
  Tomasz Nowicki 

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



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

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

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

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


Not pushing.

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

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

[Xen-devel] [PATCH v5 19/22] hvm/params: Add a new delivery type for event-channel in HVM_PARAM_CALLBACK_IRQ

[Shannon Zhao]

From: Shannon Zhao 

Add a new delivery type:
val[63:56] == 3: val[15:8] is flag: val[7:0] is a PPI.
To the flag, bit 8 stands the interrupt mode is edge(1) or level(0) and
bit 9 stands the interrupt polarity is active low(1) or high(0).

Cc: Jan Beulich 
Signed-off-by: Shannon Zhao 
---
v5: fix the statement
---
 xen/include/public/hvm/params.h | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/xen/include/public/hvm/params.h b/xen/include/public/hvm/params.h
index 73d4718..2ea8d62 100644
--- a/xen/include/public/hvm/params.h
+++ b/xen/include/public/hvm/params.h
@@ -55,6 +55,16 @@
  * if this delivery method is available.
  */
 
+#define HVM_PARAM_CALLBACK_TYPE_EVENT3
+/*
+ * val[55:16] need to be zero.
+ * val[15:8] is flag of event-channel interrupt:
+ *  bit 8: interrupt is edge(1) or level(0) triggered
+ *  bit 9: interrupt is active low(1) or high(0)
+ * val[7:0] is PPI number used by event-channel.
+ * This is only used by ARM/ARM64.
+ */
+
 /*
  * These are not used by Xen. They are here for convenience of HVM-guest
  * xenbus implementations.
-- 
2.0.4



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

[Xen-devel] [PATCH v5 21/22] xen/arm: Add a hypercall for device mmio mapping

[Shannon Zhao]

From: Shannon Zhao 

It needs to map platform or amba device mmio to Dom0 on ARM. But when
booting with ACPI, it can't get the mmio region in Xen due to lack of
AML interpreter to parse DSDT table. Therefore, let Dom0 call a
hypercall to map mmio region when it adds the devices.

Here we add a new map space like the XEN_DOMCTL_memory_mapping to map
mmio region for Dom0.

Cc: Jan Beulich 
Signed-off-by: Shannon Zhao 
---
v5: fix coding style and commit message
---
 xen/arch/arm/mm.c   |  3 +++
 xen/arch/arm/p2m.c  | 23 +++
 xen/common/memory.c | 16 
 xen/include/asm-arm/p2m.h   |  5 +
 xen/include/public/memory.h |  1 +
 5 files changed, 48 insertions(+)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 81f9e2e..0aae6c5 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -1138,6 +1138,9 @@ int xenmem_add_to_physmap_one(
 rcu_unlock_domain(od);
 break;
 }
+case XENMAPSPACE_dev_mmio:
+rc = map_dev_mmio_region(d, gpfn, 1, idx);
+return rc;
 
 default:
 return -ENOSYS;
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index d206616..7264ed2 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1270,6 +1271,28 @@ int unmap_mmio_regions(struct domain *d,
  d->arch.p2m.default_access);
 }
 
+int map_dev_mmio_region(struct domain *d,
+unsigned long start_gfn,
+unsigned long nr,
+unsigned long mfn)
+{
+int res;
+
+if(!iomem_access_permitted(d, start_gfn, start_gfn + nr))
+return 0;
+
+res = map_mmio_regions(d, start_gfn, nr, mfn);
+if ( res < 0 )
+{
+printk(XENLOG_ERR "Unable to map 0x%lx - 0x%lx in domain %d\n",
+   start_gfn << PAGE_SHIFT, (start_gfn + nr) << PAGE_SHIFT,
+   d->domain_id);
+return res;
+}
+
+return 0;
+}
+
 int guest_physmap_add_entry(struct domain *d,
 unsigned long gpfn,
 unsigned long mfn,
diff --git a/xen/common/memory.c b/xen/common/memory.c
index ef57219..98db1cb 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -980,6 +980,14 @@ long do_memory_op(unsigned long cmd, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 if ( d == NULL )
 return -ESRCH;
 
+/*
+ * XENMAPSPACE_dev_mmio mapping is only supported for hardware Domain
+ * to map this kind of space to itself.
+ */
+if ( (xatp.space == XENMAPSPACE_dev_mmio) &&
+ (!is_hardware_domain(current->domain) || (d != current->domain)) )
+return -EACCES;
+
 rc = xsm_add_to_physmap(XSM_TARGET, current->domain, d);
 if ( rc )
 {
@@ -1024,6 +1032,14 @@ long do_memory_op(unsigned long cmd, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 if ( d == NULL )
 return -ESRCH;
 
+/*
+ * XENMAPSPACE_dev_mmio mapping is only supported for hardware Domain
+ * to map this kind of space to itself.
+ */
+if ( (xatpb.space == XENMAPSPACE_dev_mmio) &&
+ (!is_hardware_domain(current->domain) || (d != current->domain)) )
+return -EACCES;
+
 rc = xsm_add_to_physmap(XSM_TARGET, current->domain, d);
 if ( rc )
 {
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index 17be6ad..5fc7ff3 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -154,6 +154,11 @@ int unmap_regions_rw(struct domain *d,
 unsigned long nr_mfns,
 unsigned long mfn);
 
+int map_dev_mmio_region(struct domain *d,
+unsigned long start_gfn,
+unsigned long nr,
+unsigned long mfn);
+
 int guest_physmap_add_entry(struct domain *d,
 unsigned long gfn,
 unsigned long mfn,
diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
index f69e92f..fe52ee1 100644
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -220,6 +220,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_machphys_mapping_t);
 #define XENMAPSPACE_gmfn_range   3 /* GMFN range, XENMEM_add_to_physmap only. 
*/
 #define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another dom,
 * XENMEM_add_to_physmap_batch only. */
+#define XENMAPSPACE_dev_mmio 5 /* device mmio region */
 /* ` } */
 
 /*
-- 
2.0.4



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

[Xen-devel] [PATCH v5 17/22] arm/gic: Add a new callback to deny Dom0 access to GIC regions

[Shannon Zhao]

From: Shannon Zhao 

Add a new member in gic_hw_operations which is used to deny Dom0 access
to GIC regions.

Signed-off-by: Shannon Zhao 
---
 xen/arch/arm/gic-v2.c | 31 +++
 xen/arch/arm/gic-v3.c | 44 
 xen/arch/arm/gic.c|  5 +
 xen/include/asm-arm/gic.h |  3 +++
 4 files changed, 83 insertions(+)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 02db5f2..186f944 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -714,6 +715,31 @@ static u32 gicv2_make_hwdom_madt(const struct domain *d, 
u32 offset)
 return table_len;
 }
 
+static int gicv2_iomem_deny_access(const struct domain *d)
+{
+int rc;
+unsigned long gfn, nr;
+
+gfn = dbase >> PAGE_SHIFT;
+rc = iomem_deny_access(d, gfn, gfn + 1);
+if ( rc )
+return rc;
+
+gfn = hbase >> PAGE_SHIFT;
+rc = iomem_deny_access(d, gfn, gfn + 1);
+if ( rc )
+return rc;
+
+gfn = cbase >> PAGE_SHIFT;
+nr = DIV_ROUND_UP(csize, PAGE_SIZE);
+rc = iomem_deny_access(d, gfn, gfn + nr);
+if ( rc )
+return rc;
+
+gfn = vbase >> PAGE_SHIFT;
+return iomem_deny_access(d, gfn, gfn + nr);
+}
+
 static int __init
 gic_acpi_parse_madt_cpu(struct acpi_subtable_header *header,
 const unsigned long end)
@@ -809,6 +835,10 @@ static u32 gicv2_make_hwdom_madt(const struct domain *d, 
u32 offset)
 {
 return 0;
 }
+static int gicv2_iomem_deny_access(const struct domain *d)
+{
+return 0;
+}
 #endif
 
 static int __init gicv2_init(void)
@@ -902,6 +932,7 @@ const static struct gic_hw_operations gicv2_ops = {
 .read_apr= gicv2_read_apr,
 .make_hwdom_dt_node  = gicv2_make_hwdom_dt_node,
 .make_hwdom_madt = gicv2_make_hwdom_madt,
+.iomem_deny_access   = gicv2_iomem_deny_access,
 };
 
 /* Set up the GIC */
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index d9fce4b..67797f2 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1278,6 +1279,44 @@ static u32 gicv3_make_hwdom_madt(const struct domain *d, 
u32 offset)
 return table_len;
 }
 
+static int gicv3_iomem_deny_access(const struct domain *d)
+{
+int rc, i;
+unsigned long gfn, nr;
+
+gfn = dbase >> PAGE_SHIFT;
+rc = iomem_deny_access(d, gfn, gfn + 1);
+if ( rc )
+return rc;
+
+for ( i = 0; i < gicv3.rdist_count; i++ )
+{
+gfn = gicv3.rdist_regions[i].base >> PAGE_SHIFT;
+nr = DIV_ROUND_UP(gicv3.rdist_regions[i].size, PAGE_SIZE);
+rc = iomem_deny_access(d, gfn, gfn + nr);
+if ( rc )
+return rc;
+}
+
+if ( cbase != INVALID_PADDR )
+{
+gfn = cbase >> PAGE_SHIFT;
+nr = DIV_ROUND_UP(csize, PAGE_SIZE);
+rc = iomem_deny_access(d, gfn, gfn + nr);
+if ( rc )
+return rc;
+}
+
+if ( vbase != INVALID_PADDR )
+{
+gfn = vbase >> PAGE_SHIFT;
+nr = DIV_ROUND_UP(csize, PAGE_SIZE);
+return iomem_deny_access(d, gfn, gfn + nr);
+}
+
+return 0;
+}
+
 static int __init
 gic_acpi_parse_madt_cpu(struct acpi_subtable_header *header,
 const unsigned long end)
@@ -1426,6 +1465,10 @@ static u32 gicv3_make_hwdom_madt(const struct domain *d, 
u32 offset)
 {
 return 0;
 }
+static int gicv3_iomem_deny_access(const struct domain *d)
+{
+return 0;
+}
 #endif
 
 /* Set up the GIC */
@@ -1521,6 +1564,7 @@ static const struct gic_hw_operations gicv3_ops = {
 .secondary_init  = gicv3_secondary_cpu_init,
 .make_hwdom_dt_node  = gicv3_make_hwdom_dt_node,
 .make_hwdom_madt = gicv3_make_hwdom_madt,
+.iomem_deny_access   = gicv3_iomem_deny_access,
 };
 
 static int __init gicv3_dt_preinit(struct dt_device_node *node, const void 
*data)
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 6d32432..65022ee 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -744,6 +744,11 @@ u32 gic_make_hwdom_madt(const struct domain *d, u32 offset)
 return gic_hw_ops->make_hwdom_madt(d, offset);
 }
 
+int gic_iomem_deny_access(const struct domain *d)
+{
+return gic_hw_ops->iomem_deny_access(d);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 4cf003d..932fc02 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -360,6 +360,8 @@ struct gic_hw_operations {
   const struct dt_device_node *gic, void *fdt);
 /* Create MADT table for the hardware domain */
 u32 (*make_hwdom_madt)(const struct domain *d, u32 offset);
+/* Deny access to GIC regions */
+int (*iomem_deny_access)(const struct domain *d);

[Xen-devel] [PATCH v5 22/22] xen/arm64: Add ACPI support

[Shannon Zhao]

From: Naresh Bhat 

Add ACPI support on arm64 xen hypervisor. Enable EFI support on ARM.

Cc: Jan Beulich 
Signed-off-by: Naresh Bhat 
Signed-off-by: Shannon Zhao 
---
v5: make ACPI selectable option
---
 xen/arch/arm/Kconfig |  9 +
 xen/common/efi/runtime.c | 12 +++-
 xen/include/asm-arm/config.h |  4 
 3 files changed, 20 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index cb99df5..25cec31 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -33,6 +33,15 @@ menu "Architecture Features"
 
 source "arch/Kconfig"
 
+config ACPI
+   bool "ACPI (Advanced Configuration and Power Interface) Support"
+   depends on ARM_64
+   default y
+   ---help---
+
+ Advanced Configuration and Power Interface (ACPI) support for Xen is
+ an alternative to device tree on ARM64.
+
 # Select HAS_GICV3 if GICv3 is supported
 config HAS_GICV3
bool
diff --git a/xen/common/efi/runtime.c b/xen/common/efi/runtime.c
index ae87557..c256814 100644
--- a/xen/common/efi/runtime.c
+++ b/xen/common/efi/runtime.c
@@ -10,14 +10,16 @@ DEFINE_XEN_GUEST_HANDLE(CHAR16);
 
 #ifndef COMPAT
 
-#ifdef CONFIG_ARM  /* Disabled until runtime services implemented */
-const bool_t efi_enabled = 0;
-#else
+/*
+ * Currently runtime services are not implemented on ARM. To boot Xen with 
ACPI,
+ * set efi_enabled to 1, so that Xen can get the ACPI root pointer from EFI.
+ */
+const bool_t efi_enabled = 1;
+
+#ifndef CONFIG_ARM
 # include 
 # include 
 # include 
-
-const bool_t efi_enabled = 1;
 #endif
 
 unsigned int __read_mostly efi_num_ct;
diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
index 7ceb5c5..5fc9aa2 100644
--- a/xen/include/asm-arm/config.h
+++ b/xen/include/asm-arm/config.h
@@ -31,6 +31,10 @@
 
 #define CONFIG_ARM_L1_CACHE_SHIFT 7 /* XXX */
 
+#ifdef CONFIG_ACPI
+#define CONFIG_ACPI_BOOT 1
+#endif
+
 #define CONFIG_SMP 1
 
 #define CONFIG_IRQ_HAS_MULTIPLE_ACTION 1
-- 
2.0.4



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

[Xen-devel] [PATCH v5 03/22] arm/acpi: Prepare FADT table for Dom0

[Shannon Zhao]

From: Shannon Zhao 

Copy and modify FADT table before passing it to Dom0. Set PSCI_COMPLIANT
and PSCI_USE_HVC.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
 xen/arch/arm/domain_build.c | 43 +++
 1 file changed, 43 insertions(+)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 4e20499..d9b7213 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1357,6 +1357,44 @@ static int prepare_dtb(struct domain *d, struct 
kernel_info *kinfo)
 }
 
 #ifdef CONFIG_ACPI
+
+static int acpi_create_fadt(struct domain *d, struct membank tbl_add[])
+{
+struct acpi_table_header *table = NULL;
+struct acpi_table_fadt *fadt = NULL;
+u64 table_size;
+acpi_status status;
+u8 *base_ptr;
+u8 checksum;
+
+status = acpi_get_table(ACPI_SIG_FADT, 0, );
+
+if ( ACPI_FAILURE(status) )
+{
+const char *msg = acpi_format_exception(status);
+
+printk("Failed to get FADT table, %s\n", msg);
+return -EINVAL;
+}
+
+table_size = table->length;
+base_ptr = d->arch.efi_acpi_table
+   + acpi_get_table_offset(tbl_add, TBL_FADT);
+ACPI_MEMCPY(base_ptr, table, table_size);
+fadt = (struct acpi_table_fadt *)base_ptr;
+
+/* Set PSCI_COMPLIANT and PSCI_USE_HVC */
+fadt->arm_boot_flags |= (ACPI_FADT_PSCI_COMPLIANT | 
ACPI_FADT_PSCI_USE_HVC);
+checksum = acpi_tb_checksum(ACPI_CAST_PTR(u8, fadt), table_size);
+fadt->header.checksum -= checksum;
+
+tbl_add[TBL_FADT].start = d->arch.efi_acpi_gpa
+  + acpi_get_table_offset(tbl_add, TBL_FADT);
+tbl_add[TBL_FADT].size = table_size;
+
+return 0;
+}
+
 static int estimate_acpi_efi_size(struct domain *d, struct kernel_info *kinfo)
 {
 size_t efi_size, acpi_size, madt_size;
@@ -1401,6 +1439,7 @@ static int prepare_acpi(struct domain *d, struct 
kernel_info *kinfo)
 {
 int rc = 0;
 int order;
+struct membank tbl_add[TBL_MMAX] = {};
 
 rc = estimate_acpi_efi_size(d, kinfo);
 if ( rc != 0 )
@@ -1419,6 +1458,10 @@ static int prepare_acpi(struct domain *d, struct 
kernel_info *kinfo)
  * region. So we use it as the ACPI table mapped address. */
 d->arch.efi_acpi_gpa = kinfo->gnttab_start;
 
+rc = acpi_create_fadt(d, tbl_add);
+if ( rc != 0 )
+return rc;
+
 return 0;
 }
 #else
-- 
2.0.4



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

[Xen-devel] [PATCH v5 00/22] Prepare UEFI and ACPI tables for Dom0 on ARM64

[Shannon Zhao]

From: Shannon Zhao 

These patches are Part 4 (and last part) of the previous patch set I
sent which adds ACPI support for arm64 on Xen[1]. Split them as an
individual set for convenient reviewing.

These patches create UEFI and ACPI tables which are mapped to Dom0's
space and add other preparations for Dom0 to use ACPI. Then at last
enable ACPI support on ARM64.

See individual patch for changes.

Thanks,
Shannon
[1] http://lists.xenproject.org/archives/html/xen-devel/2015-11/msg01831.html

Naresh Bhat (1):
  xen/arm64: Add ACPI support

Parth Dixit (1):
  arm/p2m: Add helper functions to map memory regions

Shannon Zhao (20):
  arm/acpi: Estimate memory required for acpi/efi tables
  arm/acpi: Add a helper function to get the acpi table offset
  arm/acpi: Prepare FADT table for Dom0
  arm/gic: Add a new callback for creating MADT table for Dom0
  arm/acpi: Prepare MADT table for Dom0
  arm/acpi: Prepare STAO table for Dom0
  arm/acpi: Prepare XSDT table for Dom0
  arm/acpi: Prepare RSDP table for Dom0
  arm/acpi: Map all other tables for Dom0
  arm/acpi: Prepare EFI system table for Dom0
  arm/acpi: Prepare EFI memory descriptor for Dom0
  arm/acpi: Map the new created EFI and ACPI tables to Dom0
  arm/acpi: Create min DT stub for Dom0
  arm/acpi: Permit access all Xen unused SPIs for Dom0
  arm/acpi: Configure SPI interrupt type and route to Dom0 dynamically
  arm/gic: Add a new callback to deny Dom0 access to GIC regions
  arm/acpi: Permit MMIO access of Xen unused devices for Dom0
  hvm/params: Add a new delivery type for event-channel in
HVM_PARAM_CALLBACK_IRQ
  xen/acpi: Fix event-channel interrupt when booting with ACPI
  xen/arm: Add a hypercall for device mmio mapping

 docs/misc/arm/device-tree/uefi.txt |  58 
 xen/arch/arm/Kconfig   |   9 +
 xen/arch/arm/acpi/lib.c|  15 +
 xen/arch/arm/domain.c  |   4 +
 xen/arch/arm/domain_build.c| 588 -
 xen/arch/arm/efi/Makefile  |   2 +-
 xen/arch/arm/efi/efi-dom0.c| 187 
 xen/arch/arm/gic-v2.c  |  65 
 xen/arch/arm/gic-v3.c  |  91 ++
 xen/arch/arm/gic.c |  10 +
 xen/arch/arm/mm.c  |   3 +
 xen/arch/arm/p2m.c |  49 
 xen/arch/arm/vgic.c|  38 +++
 xen/common/efi/boot.c  |   7 +
 xen/common/efi/efi.h   |   4 +
 xen/common/efi/runtime.c   |  12 +-
 xen/common/memory.c|  16 +
 xen/include/asm-arm/acpi.h |   6 +
 xen/include/asm-arm/config.h   |   4 +
 xen/include/asm-arm/gic.h  |   6 +
 xen/include/asm-arm/p2m.h  |  15 +
 xen/include/asm-arm/setup.h|  12 +
 xen/include/public/hvm/params.h|  10 +
 xen/include/public/memory.h|   1 +
 24 files changed, 1205 insertions(+), 7 deletions(-)
 create mode 100644 docs/misc/arm/device-tree/uefi.txt
 create mode 100644 xen/arch/arm/efi/efi-dom0.c

-- 
2.0.4



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

[Xen-devel] [PATCH v5 13/22] arm/acpi: Map the new created EFI and ACPI tables to Dom0

[Shannon Zhao]

From: Shannon Zhao 

Map the UEFI and ACPI tables which we created to non-RAM space in Dom0.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
 xen/arch/arm/domain_build.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 008fc76..e036887 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1691,6 +1691,21 @@ static int prepare_acpi(struct domain *d, struct 
kernel_info *kinfo)
 acpi_create_efi_mmap_table(d->arch.efi_acpi_gpa, d->arch.efi_acpi_len,
d->arch.efi_acpi_table, >mem, tbl_add);
 
+/* Map the EFI and ACPI tables to Dom0 */
+rc = map_regions_rw(d,
+paddr_to_pfn(d->arch.efi_acpi_gpa),
+PFN_UP(d->arch.efi_acpi_len),
+paddr_to_pfn(virt_to_maddr(d->arch.efi_acpi_table)));
+if ( rc != 0 )
+{
+printk(XENLOG_ERR "Unable to map 0x%"PRIx64
+   " - 0x%"PRIx64" in domain %d\n",
+   d->arch.efi_acpi_gpa & PAGE_MASK,
+   PAGE_ALIGN(d->arch.efi_acpi_gpa + d->arch.efi_acpi_len) - 1,
+   d->domain_id);
+return rc;
+}
+
 return 0;
 }
 #else
-- 
2.0.4



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

[Xen-devel] [PATCH v5 16/22] arm/acpi: Configure SPI interrupt type and route to Dom0 dynamically

[Shannon Zhao]

From: Shannon Zhao 

Interrupt information is described in DSDT and is not available at the
time of booting. Check if the interrupt is permitted to access and set
the interrupt type, route it to guest dynamically only for SPI
and Dom0.

Signed-off-by: Parth Dixit 
Signed-off-by: Shannon Zhao 
---
v5: add a small function to get the irq type from ICFG
---
 xen/arch/arm/vgic.c | 38 ++
 1 file changed, 38 insertions(+)

diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index ee35683..52378a3 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -25,6 +25,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 
@@ -334,6 +336,21 @@ void vgic_disable_irqs(struct vcpu *v, uint32_t r, int n)
 }
 }
 
+#ifdef CONFIG_ACPI
+#define VGIC_ICFG_MASK(intr) ( 1 << ( ( 2 * ( intr % 16 ) ) + 1 ) )
+
+static unsigned int get_the_irq_type(struct vcpu *v, int n, int index)
+{
+struct vgic_irq_rank *vr = vgic_get_rank(v, n);
+uint32_t tr = vr->icfg[index >> 4];
+
+if ( tr & VGIC_ICFG_MASK(index) )
+return IRQ_TYPE_EDGE_BOTH;
+else
+return IRQ_TYPE_LEVEL_MASK;
+}
+#endif
+
 void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n)
 {
 const unsigned long mask = r;
@@ -342,9 +359,30 @@ void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n)
 unsigned long flags;
 int i = 0;
 struct vcpu *v_target;
+#ifdef CONFIG_ACPI
+struct domain *d = v->domain;
+int ret;
+#endif
 
 while ( (i = find_next_bit(, 32, i)) < 32 ) {
 irq = i + (32 * n);
+#ifdef CONFIG_ACPI
+/* Set the irq type and route it to guest only for SPI and Dom0 */
+if( irq_access_permitted(d, irq) && is_hardware_domain(d) &&
+( irq >= 32 ) && ( !acpi_disabled ) )
+{
+ret = irq_set_spi_type(irq, get_the_irq_type(v, n, i));
+if ( ret )
+printk(XENLOG_WARNING "The irq type is not correct\n");
+
+vgic_reserve_virq(d, irq);
+
+ret = route_irq_to_guest(d, irq, irq, NULL);
+if ( ret )
+printk(XENLOG_ERR "Unable to route IRQ %u to domain %u\n",
+   irq, d->domain_id);
+}
+#endif
 v_target = __vgic_get_target_vcpu(v, irq);
 p = irq_to_pending(v_target, irq);
 set_bit(GIC_IRQ_GUEST_ENABLED, >status);
-- 
2.0.4



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

[Xen-devel] [PATCH v5 02/22] arm/acpi: Add a helper function to get the acpi table offset

[Shannon Zhao]

From: Shannon Zhao 

These tables are aligned with 64bit.

Signed-off-by: Shannon Zhao 
---
v5: make the return value type and variable type consistent
---
 xen/arch/arm/acpi/lib.c| 15 +++
 xen/include/asm-arm/acpi.h |  6 ++
 2 files changed, 21 insertions(+)

diff --git a/xen/arch/arm/acpi/lib.c b/xen/arch/arm/acpi/lib.c
index db5c4d8..79f7edd 100644
--- a/xen/arch/arm/acpi/lib.c
+++ b/xen/arch/arm/acpi/lib.c
@@ -60,3 +60,18 @@ bool_t __init acpi_psci_hvc_present(void)
 {
 return acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_USE_HVC;
 }
+
+paddr_t __init acpi_get_table_offset(struct membank tbl_add[],
+ EFI_MEM_RES index)
+{
+int i;
+paddr_t offset = 0;
+
+for ( i = 0; i < index; i++ )
+{
+/* Aligned with 64bit (8 bytes) */
+offset += ROUNDUP(tbl_add[i].size, 8);
+}
+
+return offset;
+}
diff --git a/xen/include/asm-arm/acpi.h b/xen/include/asm-arm/acpi.h
index 7f59761..6db3711 100644
--- a/xen/include/asm-arm/acpi.h
+++ b/xen/include/asm-arm/acpi.h
@@ -25,6 +25,7 @@
 
 #include 
 #include 
+#include 
 
 #define COMPILER_DEPENDENT_INT64   long long
 #define COMPILER_DEPENDENT_UINT64  unsigned long long
@@ -58,10 +59,15 @@ static inline void enable_acpi(void)
 {
 acpi_disabled = 0;
 }
+
+paddr_t acpi_get_table_offset(struct membank tbl_add[], EFI_MEM_RES index);
 #else
 #define acpi_disabled (1)
 #define disable_acpi()
 #define enable_acpi()
+paddr_t inline acpi_get_table_offset(struct membank tbl_add[],
+ EFI_MEM_RES index)
+{ return 0; }
 #endif
 
 #endif /*_ASM_ARM_ACPI_H*/
-- 
2.0.4



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

[Xen-devel] [PATCH v5 15/22] arm/acpi: Permit access all Xen unused SPIs for Dom0

[Shannon Zhao]

From: Shannon Zhao 

Permit access all Xen unused SPIs for Dom0 except the interrupts that
Xen uses. Then when Dom0 configures the interrupt, it could set the
interrupt type and route it to Dom0.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
 xen/arch/arm/domain_build.c | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 6726e45..1e5ee0e 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1359,6 +1359,33 @@ static int prepare_dtb(struct domain *d, struct 
kernel_info *kinfo)
 #ifdef CONFIG_ACPI
 #define ACPI_DOM0_FDT_MIN_SIZE 4096
 
+static int acpi_permit_spi_access(struct domain *d)
+{
+int i, res;
+struct irq_desc *desc;
+
+/* Here just permit Dom0 to access the SPIs which Xen doesn't use. Then 
when
+ * Dom0 configures the interrupt, set the interrupt type and route it to
+ * Dom0.
+ */
+for( i = NR_LOCAL_IRQS; i < vgic_num_irqs(d); i++ )
+{
+desc = irq_to_desc(i);
+if( desc->action != NULL)
+continue;
+
+res = irq_permit_access(d, i);
+if ( res )
+{
+printk(XENLOG_ERR "Unable to permit to dom%u access to IRQ %u\n",
+   d->domain_id, i);
+return res;
+}
+}
+
+return 0;
+}
+
 static int make_chosen_node(const struct kernel_info *kinfo,
 struct membank tbl_add[])
 {
@@ -1849,6 +1876,10 @@ static int prepare_acpi(struct domain *d, struct 
kernel_info *kinfo)
 if ( rc != 0 )
 return rc;
 
+rc = acpi_permit_spi_access(d);
+if ( rc != 0 )
+return rc;
+
 return 0;
 }
 #else
-- 
2.0.4



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

[Xen-devel] [PATCH v5 09/22] arm/p2m: Add helper functions to map memory regions

[Shannon Zhao]

From: Parth Dixit 

Create a helper function for mapping with cached attributes and
read-write range.

Signed-off-by: Parth Dixit 
Signed-off-by: Shannon Zhao 
---
v5: use p2m_access_rw and rename to map_regions_rw
---
 xen/arch/arm/p2m.c| 26 ++
 xen/include/asm-arm/p2m.h | 10 ++
 2 files changed, 36 insertions(+)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index a2a9c4b..d206616 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1218,6 +1218,32 @@ int p2m_populate_ram(struct domain *d,
  d->arch.p2m.default_access);
 }
 
+int map_regions_rw(struct domain *d,
+ unsigned long start_gfn,
+ unsigned long nr,
+ unsigned long mfn)
+{
+return apply_p2m_changes(d, INSERT,
+ pfn_to_paddr(start_gfn),
+ pfn_to_paddr(start_gfn + nr),
+ pfn_to_paddr(mfn),
+ MATTR_MEM, 0, p2m_mmio_direct,
+ p2m_access_rw);
+}
+
+int unmap_regions_rw(struct domain *d,
+   unsigned long start_gfn,
+   unsigned long nr,
+   unsigned long mfn)
+{
+return apply_p2m_changes(d, REMOVE,
+ pfn_to_paddr(start_gfn),
+ pfn_to_paddr(start_gfn + nr),
+ pfn_to_paddr(mfn),
+ MATTR_MEM, 0, p2m_invalid,
+ p2m_access_rw);
+}
+
 int map_mmio_regions(struct domain *d,
  unsigned long start_gfn,
  unsigned long nr,
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index 433952a..17be6ad 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -144,6 +144,16 @@ int p2m_cache_flush(struct domain *d, xen_pfn_t start_mfn, 
xen_pfn_t end_mfn);
 /* Setup p2m RAM mapping for domain d from start-end. */
 int p2m_populate_ram(struct domain *d, paddr_t start, paddr_t end);
 
+int map_regions_rw(struct domain *d,
+unsigned long start_gfn,
+unsigned long nr_mfns,
+unsigned long mfn);
+
+int unmap_regions_rw(struct domain *d,
+unsigned long start_gfn,
+unsigned long nr_mfns,
+unsigned long mfn);
+
 int guest_physmap_add_entry(struct domain *d,
 unsigned long gfn,
 unsigned long mfn,
-- 
2.0.4



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

[Xen-devel] [PATCH v5 04/22] arm/gic: Add a new callback for creating MADT table for Dom0

[Shannon Zhao]

From: Shannon Zhao 

Add a new member in gic_hw_operations which is used to creat MADT table
for Dom0.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
 xen/arch/arm/gic-v2.c | 34 ++
 xen/arch/arm/gic-v3.c | 47 +++
 xen/arch/arm/gic.c|  5 +
 xen/include/asm-arm/gic.h |  3 +++
 4 files changed, 89 insertions(+)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 0fcb894..02db5f2 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -685,6 +685,35 @@ static void __init gicv2_dt_init(void)
 }
 
 #ifdef CONFIG_ACPI
+static u32 gicv2_make_hwdom_madt(const struct domain *d, u32 offset)
+{
+struct acpi_subtable_header *header;
+struct acpi_madt_generic_interrupt *host_gicc, *gicc;
+u32 i, size, table_len = 0;
+u8 *base_ptr = d->arch.efi_acpi_table + offset;
+
+header = acpi_table_get_entry_madt(ACPI_MADT_TYPE_GENERIC_INTERRUPT, 0);
+if ( !header )
+panic("Can't get GICC entry");
+host_gicc = container_of(header, struct acpi_madt_generic_interrupt,
+ header);
+
+size = sizeof(struct acpi_madt_generic_interrupt);
+/* Add Generic Interrupt */
+for ( i = 0; i < d->max_vcpus; i++ )
+{
+gicc = (struct acpi_madt_generic_interrupt *)(base_ptr + table_len);
+ACPI_MEMCPY(gicc, host_gicc, size);
+gicc->cpu_interface_number = i;
+gicc->uid = i;
+gicc->flags = ACPI_MADT_ENABLED;
+gicc->arm_mpidr = vcpuid_to_vaffinity(i);
+table_len += size;
+}
+
+return table_len;
+}
+
 static int __init
 gic_acpi_parse_madt_cpu(struct acpi_subtable_header *header,
 const unsigned long end)
@@ -776,6 +805,10 @@ static void __init gicv2_acpi_init(void)
 }
 #else
 static void __init gicv2_acpi_init(void) { }
+static u32 gicv2_make_hwdom_madt(const struct domain *d, u32 offset)
+{
+return 0;
+}
 #endif
 
 static int __init gicv2_init(void)
@@ -868,6 +901,7 @@ const static struct gic_hw_operations gicv2_ops = {
 .read_vmcr_priority  = gicv2_read_vmcr_priority,
 .read_apr= gicv2_read_apr,
 .make_hwdom_dt_node  = gicv2_make_hwdom_dt_node,
+.make_hwdom_madt = gicv2_make_hwdom_madt,
 };
 
 /* Set up the GIC */
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index f83fd88..d9fce4b 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1236,6 +1236,48 @@ static void __init gicv3_dt_init(void)
 }
 
 #ifdef CONFIG_ACPI
+static u32 gicv3_make_hwdom_madt(const struct domain *d, u32 offset)
+{
+struct acpi_subtable_header *header;
+struct acpi_madt_generic_interrupt *host_gicc, *gicc;
+struct acpi_madt_generic_redistributor *gicr;
+u8 *base_ptr = d->arch.efi_acpi_table + offset;
+u32 i, table_len = 0, size;
+
+/* Add Generic Interrupt */
+header = acpi_table_get_entry_madt(ACPI_MADT_TYPE_GENERIC_INTERRUPT, 0);
+if ( !header )
+panic("Can't get GICC entry");
+host_gicc = container_of(header, struct acpi_madt_generic_interrupt,
+ header);
+
+size = sizeof(struct acpi_madt_generic_interrupt);
+for ( i = 0; i < d->max_vcpus; i++ )
+{
+gicc = (struct acpi_madt_generic_interrupt *)(base_ptr + table_len);
+ACPI_MEMCPY(gicc, host_gicc, size);
+gicc->cpu_interface_number = i;
+gicc->uid = i;
+gicc->flags = ACPI_MADT_ENABLED;
+gicc->arm_mpidr = vcpuid_to_vaffinity(i);
+table_len += size;
+}
+
+/* Add Generic Redistributor */
+size = sizeof(struct acpi_madt_generic_redistributor);
+for ( i = 0; i < d->arch.vgic.nr_regions; i++ )
+{
+gicr = (struct acpi_madt_generic_redistributor *)(base_ptr + 
table_len);
+gicr->header.type = ACPI_MADT_TYPE_GENERIC_REDISTRIBUTOR;
+gicr->header.length = size;
+gicr->base_address = d->arch.vgic.rdist_regions[i].base;
+gicr->length = d->arch.vgic.rdist_regions[i].size;
+table_len += size;
+}
+
+return table_len;
+}
+
 static int __init
 gic_acpi_parse_madt_cpu(struct acpi_subtable_header *header,
 const unsigned long end)
@@ -1380,6 +1422,10 @@ static void __init gicv3_acpi_init(void)
 }
 #else
 static void __init gicv3_acpi_init(void) { }
+static u32 gicv3_make_hwdom_madt(const struct domain *d, u32 offset)
+{
+return 0;
+}
 #endif
 
 /* Set up the GIC */
@@ -1474,6 +1520,7 @@ static const struct gic_hw_operations gicv3_ops = {
 .read_apr= gicv3_read_apr,
 .secondary_init  = gicv3_secondary_cpu_init,
 .make_hwdom_dt_node  = gicv3_make_hwdom_dt_node,
+.make_hwdom_madt = gicv3_make_hwdom_madt,
 };
 
 static int __init gicv3_dt_preinit(struct dt_device_node *node, const void 
*data)
diff --git a/xen/arch/arm/gic.c 

[Xen-devel] [PATCH v5 12/22] arm/acpi: Prepare EFI memory descriptor for Dom0

[Shannon Zhao]

From: Shannon Zhao 

Create a few EFI memory descriptors to tell Dom0 the RAM region
information, ACPI table regions and EFI tables reserved resions.

Signed-off-by: Parth Dixit 
Signed-off-by: Shannon Zhao 
---
v5: move to efi-dom0.c
---
 xen/arch/arm/domain_build.c |  2 ++
 xen/arch/arm/efi/efi-dom0.c | 47 +
 xen/include/asm-arm/setup.h |  5 +
 3 files changed, 54 insertions(+)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 613551c..008fc76 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1688,6 +1688,8 @@ static int prepare_acpi(struct domain *d, struct 
kernel_info *kinfo)
 acpi_map_other_tables(d);
 acpi_create_efi_system_table(d->arch.efi_acpi_gpa, d->arch.efi_acpi_table,
  tbl_add);
+acpi_create_efi_mmap_table(d->arch.efi_acpi_gpa, d->arch.efi_acpi_len,
+   d->arch.efi_acpi_table, >mem, tbl_add);
 
 return 0;
 }
diff --git a/xen/arch/arm/efi/efi-dom0.c b/xen/arch/arm/efi/efi-dom0.c
index 36a1283..0ff6309 100644
--- a/xen/arch/arm/efi/efi-dom0.c
+++ b/xen/arch/arm/efi/efi-dom0.c
@@ -22,6 +22,7 @@
  */
 
 #include "efi.h"
+#include 
 #include 
 #include 
 
@@ -90,3 +91,49 @@ void __init acpi_create_efi_system_table(paddr_t paddr, void 
*efi_acpi_table,
 tbl_add[TBL_EFIT].start = table_addr;
 tbl_add[TBL_EFIT].size = table_size;
 }
+
+void __init acpi_create_efi_mmap_table(paddr_t paddr, paddr_t size,
+   void *efi_acpi_table,
+   const struct meminfo *mem,
+   struct membank tbl_add[])
+{
+EFI_MEMORY_DESCRIPTOR *memory_map;
+struct meminfo *acpi_mem;
+int acpi_mem_nr_banks = 0;
+unsigned int i, offset;
+u8 *base_ptr;
+
+base_ptr = efi_acpi_table + acpi_get_table_offset(tbl_add, TBL_MMAP);
+memory_map = (EFI_MEMORY_DESCRIPTOR *)(base_ptr);
+
+offset = 0;
+for( i = 0; i < mem->nr_banks; i++, offset++ )
+{
+memory_map[offset].Type = EfiConventionalMemory;
+memory_map[offset].PhysicalStart = mem->bank[i].start;
+memory_map[offset].NumberOfPages = PFN_UP(mem->bank[i].size);
+memory_map[offset].Attribute = EFI_MEMORY_WB;
+}
+
+if ( !acpi_disabled )
+{
+acpi_mem = get_acpi_meminfo();
+acpi_mem_nr_banks = acpi_mem->nr_banks;
+for( i = 0; i < acpi_mem_nr_banks; i++, offset++ )
+{
+memory_map[offset].Type = EfiACPIReclaimMemory;
+memory_map[offset].PhysicalStart = acpi_mem->bank[i].start;
+memory_map[offset].NumberOfPages = PFN_UP(acpi_mem->bank[i].size);
+memory_map[offset].Attribute = EFI_MEMORY_WB;
+}
+}
+
+memory_map[offset].Type = EfiACPIReclaimMemory;
+memory_map[offset].PhysicalStart = paddr;
+memory_map[offset].NumberOfPages = PFN_UP(size);
+memory_map[offset].Attribute = EFI_MEMORY_WB;
+
+tbl_add[TBL_MMAP].start = paddr + acpi_get_table_offset(tbl_add, TBL_MMAP);
+tbl_add[TBL_MMAP].size = sizeof(EFI_MEMORY_DESCRIPTOR)
+ * (mem->nr_banks + acpi_mem_nr_banks + 1);
+}
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index e423b15..b2899f2 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -56,6 +56,11 @@ size_t estimate_efi_size(int mem_nr_banks);
 void acpi_create_efi_system_table(paddr_t paddr, void *efi_acpi_table,
   struct membank tbl_add[]);
 
+void acpi_create_efi_mmap_table(paddr_t paddr, paddr_t size,
+void *efi_acpi_table,
+const struct meminfo *mem,
+struct membank tbl_add[]);
+
 int construct_dom0(struct domain *d);
 
 void discard_initial_modules(void);
-- 
2.0.4



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

[Xen-devel] [PATCH v5 06/22] arm/acpi: Prepare STAO table for Dom0

[Shannon Zhao]

From: Shannon Zhao 

Create STAO table for Dom0. This table is used to tell Dom0 whether it
should ignore UART defined in SPCR table or the ACPI namespace names.

Look at below url for details:
http://wiki.xenproject.org/mediawiki/images/0/02/Status-override-table.pdf

Signed-off-by: Parth Dixit 
Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
 xen/arch/arm/domain_build.c | 41 +
 1 file changed, 41 insertions(+)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index ed257e0..b369f2e 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1357,6 +1357,43 @@ static int prepare_dtb(struct domain *d, struct 
kernel_info *kinfo)
 }
 
 #ifdef CONFIG_ACPI
+static int acpi_create_stao(struct domain *d, struct membank tbl_add[])
+{
+struct acpi_table_header *table = NULL;
+struct acpi_table_stao *stao = NULL;
+u32 table_size = sizeof(struct acpi_table_stao);
+u32 offset = acpi_get_table_offset(tbl_add, TBL_STAO);
+acpi_status status;
+u8 *base_ptr, checksum;
+
+/* Copy OEM and ASL compiler fields from another table, use MADT */
+status = acpi_get_table(ACPI_SIG_MADT, 0, );
+
+if ( ACPI_FAILURE(status) )
+{
+const char *msg = acpi_format_exception(status);
+
+printk("Failed to get MADT table, %s\n", msg);
+return -EINVAL;
+}
+
+base_ptr = d->arch.efi_acpi_table + offset;
+ACPI_MEMCPY(base_ptr, table, sizeof(struct acpi_table_header));
+
+stao = (struct acpi_table_stao *)base_ptr;
+ACPI_MEMCPY(stao->header.signature, ACPI_SIG_STAO, 4);
+stao->header.revision = 1;
+stao->header.length = table_size;
+stao->ignore_uart = 1;
+checksum = acpi_tb_checksum(ACPI_CAST_PTR(u8, stao), table_size);
+stao->header.checksum -= checksum;
+
+tbl_add[TBL_STAO].start = d->arch.efi_acpi_gpa + offset;
+tbl_add[TBL_STAO].size = table_size;
+
+return 0;
+}
+
 static int acpi_create_madt(struct domain *d, struct membank tbl_add[])
 {
 struct acpi_table_header *table = NULL;
@@ -1512,6 +1549,10 @@ static int prepare_acpi(struct domain *d, struct 
kernel_info *kinfo)
 if ( rc != 0 )
 return rc;
 
+rc = acpi_create_stao(d, tbl_add);
+if ( rc != 0 )
+return rc;
+
 return 0;
 }
 #else
-- 
2.0.4



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

[Xen-devel] [PATCH v5 11/22] arm/acpi: Prepare EFI system table for Dom0

[Shannon Zhao]

From: Shannon Zhao 

Prepare EFI system table for Dom0 to describe the information of UEFI.

Signed-off-by: Parth Dixit 
Signed-off-by: Shannon Zhao 
---
v5: move to efi-dom0.c
---
 xen/arch/arm/domain_build.c |  2 ++
 xen/arch/arm/efi/efi-dom0.c | 44 
 xen/include/asm-arm/setup.h |  3 +++
 3 files changed, 49 insertions(+)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index c71976c..613551c 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1686,6 +1686,8 @@ static int prepare_acpi(struct domain *d, struct 
kernel_info *kinfo)
 return rc;
 
 acpi_map_other_tables(d);
+acpi_create_efi_system_table(d->arch.efi_acpi_gpa, d->arch.efi_acpi_table,
+ tbl_add);
 
 return 0;
 }
diff --git a/xen/arch/arm/efi/efi-dom0.c b/xen/arch/arm/efi/efi-dom0.c
index d54c38f..36a1283 100644
--- a/xen/arch/arm/efi/efi-dom0.c
+++ b/xen/arch/arm/efi/efi-dom0.c
@@ -46,3 +46,47 @@ size_t __init estimate_efi_size(int mem_nr_banks)
 
 return size;
 }
+
+#include "../../../common/decompress.h"
+#define XZ_EXTERN STATIC
+#include "../../../common/xz/crc32.c"
+
+void __init acpi_create_efi_system_table(paddr_t paddr, void *efi_acpi_table,
+ struct membank tbl_add[])
+{
+u64 table_addr, table_size, offset = 0;
+u8 *base_ptr;
+EFI_CONFIGURATION_TABLE *efi_conf_tbl;
+EFI_SYSTEM_TABLE *efi_sys_tbl;
+
+table_addr = paddr + acpi_get_table_offset(tbl_add, TBL_EFIT);
+table_size = sizeof(EFI_SYSTEM_TABLE) + sizeof(EFI_CONFIGURATION_TABLE)
+ + sizeof(xen_efi_fw_vendor);
+base_ptr = efi_acpi_table + acpi_get_table_offset(tbl_add, TBL_EFIT);
+efi_sys_tbl = (EFI_SYSTEM_TABLE *)base_ptr;
+
+efi_sys_tbl->Hdr.Signature = EFI_SYSTEM_TABLE_SIGNATURE;
+/* Specify the revision as 2.5 */
+efi_sys_tbl->Hdr.Revision = (2 << 16 | 50);
+efi_sys_tbl->Hdr.HeaderSize = table_size;
+
+efi_sys_tbl->FirmwareRevision = 1;
+efi_sys_tbl->NumberOfTableEntries = 1;
+offset += sizeof(EFI_SYSTEM_TABLE);
+memcpy((CHAR16 *)(base_ptr + offset), xen_efi_fw_vendor,
+   sizeof(xen_efi_fw_vendor));
+efi_sys_tbl->FirmwareVendor = (CHAR16 *)(table_addr + offset);
+
+offset += sizeof(xen_efi_fw_vendor);
+efi_conf_tbl = (EFI_CONFIGURATION_TABLE *)(base_ptr + offset);
+efi_conf_tbl->VendorGuid = (EFI_GUID)ACPI_20_TABLE_GUID;
+efi_conf_tbl->VendorTable = (VOID *)tbl_add[TBL_RSDP].start;
+efi_sys_tbl->ConfigurationTable = (EFI_CONFIGURATION_TABLE *)(table_addr
+  + offset);
+xz_crc32_init();
+efi_sys_tbl->Hdr.CRC32 = xz_crc32((uint8_t *)efi_sys_tbl,
+  efi_sys_tbl->Hdr.HeaderSize, 0);
+
+tbl_add[TBL_EFIT].start = table_addr;
+tbl_add[TBL_EFIT].size = table_size;
+}
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index 7f233a1..e423b15 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -53,6 +53,9 @@ void copy_from_paddr(void *dst, paddr_t paddr, unsigned long 
len);
 
 size_t estimate_efi_size(int mem_nr_banks);
 
+void acpi_create_efi_system_table(paddr_t paddr, void *efi_acpi_table,
+  struct membank tbl_add[]);
+
 int construct_dom0(struct domain *d);
 
 void discard_initial_modules(void);
-- 
2.0.4



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

[Xen-devel] [PATCH v5 20/22] xen/acpi: Fix event-channel interrupt when booting with ACPI

[Shannon Zhao]

From: Shannon Zhao 

Store the event-channel interrupt number and flag in HVM parameter
HVM_PARAM_CALLBACK_IRQ. Then Dom0 could get it through hypercall
HVMOP_get_param.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
 xen/arch/arm/domain_build.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index a4abf28..5b1d583 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2008,6 +2008,7 @@ static void initrd_load(struct kernel_info *kinfo)
 static void evtchn_fixup(struct domain *d, struct kernel_info *kinfo)
 {
 int res, node;
+u64 val;
 gic_interrupt_t intr;
 
 /*
@@ -2023,6 +2024,15 @@ static void evtchn_fixup(struct domain *d, struct 
kernel_info *kinfo)
 printk("Allocating PPI %u for event channel interrupt\n",
d->arch.evtchn_irq);
 
+/* Set the value of domain param HVM_PARAM_CALLBACK_IRQ */
+val = (u64)HVM_PARAM_CALLBACK_TYPE_EVENT << 56;
+val |= (2 << 8); /* Active-low level-sensitive  */
+val |= d->arch.evtchn_irq & 0xff;
+d->arch.hvm_domain.params[HVM_PARAM_CALLBACK_IRQ] = val;
+
+if ( !acpi_disabled )
+return;
+
 /* Fix up "interrupts" in /hypervisor node */
 node = fdt_path_offset(kinfo->fdt, "/hypervisor");
 if ( node < 0 )
-- 
2.0.4



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

[Xen-devel] [PATCH v5 07/22] arm/acpi: Prepare XSDT table for Dom0

[Shannon Zhao]

From: Shannon Zhao 

Copy and modify XSDT table before passing it to Dom0. Repalce the entry
value of the copied table. Add a new entry for STAO table as well. And
keep entry value of other reused tables unchanged.

Signed-off-by: Shannon Zhao 
Acked-by: Stefano Stabellini 
---
 xen/arch/arm/domain_build.c | 72 +
 1 file changed, 72 insertions(+)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index b369f2e..f9fe289 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1357,6 +1357,74 @@ static int prepare_dtb(struct domain *d, struct 
kernel_info *kinfo)
 }
 
 #ifdef CONFIG_ACPI
+static void acpi_xsdt_modify_entry(u64 entry[], unsigned long entry_count,
+   char *signature, u64 addr)
+{
+int i;
+struct acpi_table_header *table;
+u64 size = sizeof(struct acpi_table_header);
+
+for( i = 0; i < entry_count; i++ )
+{
+table = acpi_os_map_memory(entry[i], size);
+if ( ACPI_COMPARE_NAME(table->signature, signature) )
+{
+entry[i] = addr;
+acpi_os_unmap_memory(table, size);
+break;
+}
+acpi_os_unmap_memory(table, size);
+}
+}
+
+static int acpi_create_xsdt(struct domain *d, struct membank tbl_add[])
+{
+struct acpi_table_header *table = NULL;
+struct acpi_table_rsdp *rsdp_tbl;
+struct acpi_table_xsdt *xsdt = NULL;
+u64 table_size, addr;
+unsigned long entry_count;
+u8 *base_ptr;
+u8 checksum;
+
+addr = acpi_os_get_root_pointer();
+if ( !addr )
+{
+printk("Unable to get acpi root pointer\n");
+return -EINVAL;
+}
+rsdp_tbl = acpi_os_map_memory(addr, sizeof(struct acpi_table_rsdp));
+table = acpi_os_map_memory(rsdp_tbl->xsdt_physical_address,
+   sizeof(struct acpi_table_header));
+
+/* Add place for STAO table in XSDT table */
+table_size = table->length + sizeof(u64);
+entry_count = (table->length - sizeof(struct acpi_table_header))
+  / sizeof(u64);
+base_ptr = d->arch.efi_acpi_table
+   + acpi_get_table_offset(tbl_add, TBL_XSDT);
+ACPI_MEMCPY(base_ptr, table, table->length);
+acpi_os_unmap_memory(table, sizeof(struct acpi_table_header));
+acpi_os_unmap_memory(rsdp_tbl, sizeof(struct acpi_table_rsdp));
+
+xsdt = (struct acpi_table_xsdt *)base_ptr;
+acpi_xsdt_modify_entry(xsdt->table_offset_entry, entry_count,
+   ACPI_SIG_FADT, tbl_add[TBL_FADT].start);
+acpi_xsdt_modify_entry(xsdt->table_offset_entry, entry_count,
+   ACPI_SIG_MADT, tbl_add[TBL_MADT].start);
+xsdt->table_offset_entry[entry_count] = tbl_add[TBL_STAO].start;
+
+xsdt->header.length = table_size;
+checksum = acpi_tb_checksum(ACPI_CAST_PTR(u8, xsdt), table_size);
+xsdt->header.checksum -= checksum;
+
+tbl_add[TBL_XSDT].start = d->arch.efi_acpi_gpa
+  + acpi_get_table_offset(tbl_add, TBL_XSDT);
+tbl_add[TBL_XSDT].size = table_size;
+
+return 0;
+}
+
 static int acpi_create_stao(struct domain *d, struct membank tbl_add[])
 {
 struct acpi_table_header *table = NULL;
@@ -1553,6 +1621,10 @@ static int prepare_acpi(struct domain *d, struct 
kernel_info *kinfo)
 if ( rc != 0 )
 return rc;
 
+rc = acpi_create_xsdt(d, tbl_add);
+if ( rc != 0 )
+return rc;
+
 return 0;
 }
 #else
-- 
2.0.4



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

[Xen-devel] [PATCH v5 14/22] arm/acpi: Create min DT stub for Dom0

[Shannon Zhao]

From: Shannon Zhao 

Create a DT for Dom0 for ACPI-case only. DT contains minimal required
informations such as Dom0 bootargs, initrd, efi description table and
address of uefi memory table.

Also port the document of this device tree bindings from Linux.

Signed-off-by: Naresh Bhat 
Signed-off-by: Parth Dixit 
Signed-off-by: Shannon Zhao 
---
v5: change the file name
---
 docs/misc/arm/device-tree/uefi.txt |  58 +++
 xen/arch/arm/domain_build.c| 143 +
 xen/arch/arm/efi/efi-dom0.c|  48 +
 xen/include/asm-arm/setup.h|   2 +
 4 files changed, 251 insertions(+)
 create mode 100644 docs/misc/arm/device-tree/uefi.txt

diff --git a/docs/misc/arm/device-tree/uefi.txt 
b/docs/misc/arm/device-tree/uefi.txt
new file mode 100644
index 000..41a8be0
--- /dev/null
+++ b/docs/misc/arm/device-tree/uefi.txt
@@ -0,0 +1,58 @@
+* Xen hypervisor device tree bindings
+
+Xen ARM virtual platforms shall have a top-level "hypervisor" node with
+the following properties:
+
+- compatible:
+   compatible = "xen,xen-", "xen,xen";
+  where  is the version of the Xen ABI of the platform.
+
+- reg: specifies the base physical address and size of a region in
+  memory where the grant table should be mapped to, using an
+  HYPERVISOR_memory_op hypercall. The memory region is large enough to map
+  the whole grant table (it is larger or equal to gnttab_max_grant_frames()).
+
+- interrupts: the interrupt used by Xen to inject event notifications.
+  A GIC node is also required.
+
+To support UEFI on Xen ARM virtual platforms, Xen populates the FDT "uefi" node
+under /hypervisor with following parameters:
+
+
+Name  | Size   | Description
+
+xen,uefi-system-table | 64-bit | Guest physical address of the UEFI System
+  || Table.
+
+xen,uefi-mmap-start   | 64-bit | Guest physical address of the UEFI memory
+  || map.
+
+xen,uefi-mmap-size| 32-bit | Size in bytes of the UEFI memory map
+  || pointed to in previous entry.
+
+xen,uefi-mmap-desc-size   | 32-bit | Size in bytes of each entry in the UEFI
+  || memory map.
+
+xen,uefi-mmap-desc-ver| 32-bit | Version of the mmap descriptor format.
+
+
+Example (assuming #address-cells = <2> and #size-cells = <2>):
+
+hypervisor {
+   compatible = "xen,xen-4.3", "xen,xen";
+   reg = <0 0xb000 0 0x2>;
+   interrupts = <1 15 0xf08>;
+   uefi {
+   xen,uefi-system-table = <0x>;
+   xen,uefi-mmap-start = <0x>;
+   xen,uefi-mmap-size = <0x>;
+   xen,uefi-mmap-desc-size = <0x>;
+   xen,uefi-mmap-desc-ver = <0x>;
+};
+};
+
+The format and meaning of the "xen,uefi-*" parameters are similar to those in
+Documentation/arm/uefi.txt in Linux, which are provided by the regular Linux
+UEFI stub. However they differ because they are provided by the Xen hypervisor,
+together with a set of UEFI runtime services implemented via hypercalls, see
+xen/include/public/platform.h.
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index e036887..6726e45 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1357,6 +1357,145 @@ static int prepare_dtb(struct domain *d, struct 
kernel_info *kinfo)
 }
 
 #ifdef CONFIG_ACPI
+#define ACPI_DOM0_FDT_MIN_SIZE 4096
+
+static int make_chosen_node(const struct kernel_info *kinfo,
+struct membank tbl_add[])
+{
+int res;
+const char *bootargs = NULL;
+const struct bootmodule *mod = kinfo->kernel_bootmodule;
+void *fdt = kinfo->fdt;
+
+DPRINT("Create chosen node\n");
+res = fdt_begin_node(fdt, "chosen");
+if ( res )
+return res;
+
+if ( mod && mod->cmdline[0] )
+{
+bootargs = >cmdline[0];
+res = fdt_property(fdt, "bootargs", bootargs, strlen(bootargs) + 1);
+if ( res )
+   return res;
+}
+
+/*
+ * If the bootloader provides an initrd, we must create a placeholder
+ * for the initrd properties. The values will be replaced later.
+ */
+if ( mod && mod->size )
+{
+u64 a = 0;
+

[Xen-devel] [PATCH v5 10/22] arm/acpi: Map all other tables for Dom0

[Shannon Zhao]

From: Shannon Zhao 

Map all other tables to Dom0 using 1:1 mappings.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
 xen/arch/arm/domain_build.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index ea7d6a5..c71976c 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1357,6 +1357,30 @@ static int prepare_dtb(struct domain *d, struct 
kernel_info *kinfo)
 }
 
 #ifdef CONFIG_ACPI
+static void acpi_map_other_tables(struct domain *d)
+{
+int i;
+unsigned long res;
+u64 addr, size;
+
+/* Map all other tables to Dom0 using 1:1 mappings. */
+for( i = 0; i < acpi_gbl_root_table_list.count; i++ )
+{
+addr = acpi_gbl_root_table_list.tables[i].address;
+size = acpi_gbl_root_table_list.tables[i].length;
+res = map_regions_rw(d,
+ paddr_to_pfn(addr & PAGE_MASK),
+ DIV_ROUND_UP(size, PAGE_SIZE),
+ paddr_to_pfn(addr & PAGE_MASK));
+if ( res )
+{
+ panic(XENLOG_ERR "Unable to map 0x%"PRIx64
+   " - 0x%"PRIx64" in domain \n",
+   addr & PAGE_MASK, PAGE_ALIGN(addr + size) - 1);
+}
+}
+}
+
 static int acpi_create_rsdp(struct domain *d, struct membank tbl_add[])
 {
 
@@ -1661,6 +1685,8 @@ static int prepare_acpi(struct domain *d, struct 
kernel_info *kinfo)
 if ( rc != 0 )
 return rc;
 
+acpi_map_other_tables(d);
+
 return 0;
 }
 #else
-- 
2.0.4



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

[Xen-devel] [PATCH v5 05/22] arm/acpi: Prepare MADT table for Dom0

[Shannon Zhao]

From: Shannon Zhao 

Copy main MADT table contents and distributor subtable from physical
ACPI MADT table. Make other subtables through the callback of
gic_hw_ops.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
 xen/arch/arm/domain_build.c | 50 +
 1 file changed, 50 insertions(+)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index d9b7213..ed257e0 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1357,6 +1357,52 @@ static int prepare_dtb(struct domain *d, struct 
kernel_info *kinfo)
 }
 
 #ifdef CONFIG_ACPI
+static int acpi_create_madt(struct domain *d, struct membank tbl_add[])
+{
+struct acpi_table_header *table = NULL;
+struct acpi_table_madt *madt = NULL;
+struct acpi_subtable_header *header;
+struct acpi_madt_generic_distributor *gicd;
+u32 table_size = sizeof(struct acpi_table_madt);
+u32 offset = acpi_get_table_offset(tbl_add, TBL_MADT);
+acpi_status status;
+u8 *base_ptr, checksum;
+
+status = acpi_get_table(ACPI_SIG_MADT, 0, );
+
+if ( ACPI_FAILURE(status) )
+{
+const char *msg = acpi_format_exception(status);
+
+printk("Failed to get MADT table, %s\n", msg);
+return -EINVAL;
+}
+
+base_ptr = d->arch.efi_acpi_table + offset;
+ACPI_MEMCPY(base_ptr, table, table_size);
+
+/* Add Generic Distributor */
+header = acpi_table_get_entry_madt(ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR, 0);
+if ( !header )
+panic("Can't get GICD entry");
+gicd = container_of(header, struct acpi_madt_generic_distributor, header);
+ACPI_MEMCPY(base_ptr + table_size, gicd,
+sizeof(struct acpi_madt_generic_distributor));
+table_size += sizeof(struct acpi_madt_generic_distributor);
+
+/* Add other subtables*/
+table_size += gic_make_hwdom_madt(d, offset + table_size);
+
+madt = (struct acpi_table_madt *)base_ptr;
+madt->header.length = table_size;
+checksum = acpi_tb_checksum(ACPI_CAST_PTR(u8, madt), table_size);
+madt->header.checksum -= checksum;
+
+tbl_add[TBL_MADT].start = d->arch.efi_acpi_gpa + offset;
+tbl_add[TBL_MADT].size = table_size;
+
+return 0;
+}
 
 static int acpi_create_fadt(struct domain *d, struct membank tbl_add[])
 {
@@ -1462,6 +1508,10 @@ static int prepare_acpi(struct domain *d, struct 
kernel_info *kinfo)
 if ( rc != 0 )
 return rc;
 
+rc = acpi_create_madt(d, tbl_add);
+if ( rc != 0 )
+return rc;
+
 return 0;
 }
 #else
-- 
2.0.4



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

[Xen-devel] [PATCH v5 08/22] arm/acpi: Prepare RSDP table for Dom0

[Shannon Zhao]

From: Shannon Zhao 

Copy RSDP table and replace rsdp->xsdt_physical_address with new address
of XSDT table, so it can point to the right XSDT table.

Signed-off-by: Shannon Zhao 
Acked-by: Stefano Stabellini 
---
 xen/arch/arm/domain_build.c | 36 
 1 file changed, 36 insertions(+)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index f9fe289..ea7d6a5 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1357,6 +1357,38 @@ static int prepare_dtb(struct domain *d, struct 
kernel_info *kinfo)
 }
 
 #ifdef CONFIG_ACPI
+static int acpi_create_rsdp(struct domain *d, struct membank tbl_add[])
+{
+
+struct acpi_table_rsdp *rsdp = NULL;
+u64 addr;
+u64 table_size = sizeof(struct acpi_table_rsdp);
+u8 *base_ptr;
+u8 checksum;
+
+addr = acpi_os_get_root_pointer();
+if( !addr )
+panic("Unable to get acpi root pointer\n");
+
+rsdp = acpi_os_map_memory(addr, table_size);
+base_ptr = d->arch.efi_acpi_table
+   + acpi_get_table_offset(tbl_add, TBL_RSDP);
+ACPI_MEMCPY(base_ptr, rsdp, table_size);
+acpi_os_unmap_memory(rsdp, table_size);
+
+rsdp = (struct acpi_table_rsdp *)base_ptr;
+/* Replace xsdt_physical_address */
+rsdp->xsdt_physical_address = tbl_add[TBL_XSDT].start;
+checksum = acpi_tb_checksum(ACPI_CAST_PTR(u8, rsdp), table_size);
+rsdp->checksum = rsdp->checksum - checksum;
+
+tbl_add[TBL_RSDP].start = d->arch.efi_acpi_gpa
+  + acpi_get_table_offset(tbl_add, TBL_RSDP);
+tbl_add[TBL_RSDP].size = table_size;
+
+return 0;
+}
+
 static void acpi_xsdt_modify_entry(u64 entry[], unsigned long entry_count,
char *signature, u64 addr)
 {
@@ -1625,6 +1657,10 @@ static int prepare_acpi(struct domain *d, struct 
kernel_info *kinfo)
 if ( rc != 0 )
 return rc;
 
+rc = acpi_create_rsdp(d, tbl_add);
+if ( rc != 0 )
+return rc;
+
 return 0;
 }
 #else
-- 
2.0.4



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

[Xen-devel] [PATCH v5 01/22] arm/acpi: Estimate memory required for acpi/efi tables

[Shannon Zhao]

From: Shannon Zhao 

Estimate the memory required for loading acpi/efi tables in Dom0. Make
the length of each table aligned with 64bit. Alloc the pages to store
the new created EFI and ACPI tables and free these pages when
destroying domain.

Cc: Jan Beulich 
Signed-off-by: Parth Dixit 
Signed-off-by: Shannon Zhao 
---
v5: add a new file efi-dom0.c
---
 xen/arch/arm/domain.c   |  4 +++
 xen/arch/arm/domain_build.c | 81 -
 xen/arch/arm/efi/Makefile   |  2 +-
 xen/arch/arm/efi/efi-dom0.c | 48 +++
 xen/common/efi/boot.c   |  7 
 xen/common/efi/efi.h|  4 +++
 xen/include/asm-arm/setup.h |  2 ++
 7 files changed, 146 insertions(+), 2 deletions(-)
 create mode 100644 xen/arch/arm/efi/efi-dom0.c

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 3d274ae..1365b4a 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -640,6 +640,10 @@ void arch_domain_destroy(struct domain *d)
 domain_vgic_free(d);
 domain_vuart_free(d);
 free_xenheap_page(d->shared_info);
+#ifdef CONFIG_ACPI
+free_xenheap_pages(d->arch.efi_acpi_table,
+   get_order_from_bytes(d->arch.efi_acpi_len));
+#endif
 }
 
 void arch_domain_shutdown(struct domain *d)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 83676e4..4e20499 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -12,6 +12,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -1354,6 +1356,79 @@ static int prepare_dtb(struct domain *d, struct 
kernel_info *kinfo)
 return -EINVAL;
 }
 
+#ifdef CONFIG_ACPI
+static int estimate_acpi_efi_size(struct domain *d, struct kernel_info *kinfo)
+{
+size_t efi_size, acpi_size, madt_size;
+u64 addr;
+struct acpi_table_rsdp *rsdp_tbl;
+struct acpi_table_header *table;
+
+efi_size = estimate_efi_size(kinfo->mem.nr_banks);
+
+acpi_size = ROUNDUP(sizeof(struct acpi_table_fadt), 8);
+acpi_size += ROUNDUP(sizeof(struct acpi_table_stao), 8);
+
+madt_size = sizeof(struct acpi_table_madt)
++ sizeof(struct acpi_madt_generic_interrupt) * d->max_vcpus
++ sizeof(struct acpi_madt_generic_distributor);
+if ( d->arch.vgic.version == GIC_V3 )
+madt_size += sizeof(struct acpi_madt_generic_redistributor)
+ * d->arch.vgic.nr_regions;
+acpi_size += ROUNDUP(madt_size, 8);
+
+addr = acpi_os_get_root_pointer();
+if ( !addr )
+{
+printk("Unable to get acpi root pointer\n");
+return -EINVAL;
+}
+rsdp_tbl = acpi_os_map_memory(addr, sizeof(struct acpi_table_rsdp));
+table = acpi_os_map_memory(rsdp_tbl->xsdt_physical_address,
+   sizeof(struct acpi_table_header));
+/* Add place for STAO table in XSDT table */
+acpi_size += ROUNDUP(table->length + sizeof(u64), 8);
+acpi_os_unmap_memory(table, sizeof(struct acpi_table_header));
+acpi_os_unmap_memory(rsdp_tbl, sizeof(struct acpi_table_rsdp));
+
+acpi_size += ROUNDUP(sizeof(struct acpi_table_rsdp), 8);
+d->arch.efi_acpi_len = ROUNDUP(efi_size, 8) + ROUNDUP(acpi_size, 8);
+
+return 0;
+}
+
+static int prepare_acpi(struct domain *d, struct kernel_info *kinfo)
+{
+int rc = 0;
+int order;
+
+rc = estimate_acpi_efi_size(d, kinfo);
+if ( rc != 0 )
+return rc;
+
+order = get_order_from_bytes(d->arch.efi_acpi_len);
+d->arch.efi_acpi_table = alloc_xenheap_pages(order, 0);
+if ( d->arch.efi_acpi_table == NULL )
+{
+printk("unable to allocate memory!\n");
+return -ENOMEM;
+}
+memset(d->arch.efi_acpi_table, 0, d->arch.efi_acpi_len);
+
+/* For ACPI, Dom0 doesn't use kinfo->gnttab_start to get the grant table
+ * region. So we use it as the ACPI table mapped address. */
+d->arch.efi_acpi_gpa = kinfo->gnttab_start;
+
+return 0;
+}
+#else
+static int prepare_acpi(struct domain *d, struct kernel_info *kinfo)
+{
+/* Only booting with ACPI will hit here */
+BUG_ON(1);
+return -EINVAL;
+}
+#endif
 static void dtb_load(struct kernel_info *kinfo)
 {
 void * __user dtb_virt = (void * __user)(register_t)kinfo->dtb_paddr;
@@ -1540,7 +1615,11 @@ int construct_dom0(struct domain *d)
 allocate_memory(d, );
 find_gnttab_region(d, );
 
-rc = prepare_dtb(d, );
+if ( acpi_disabled )
+rc = prepare_dtb(d, );
+else
+rc = prepare_acpi(d, );
+
 if ( rc < 0 )
 return rc;
 
diff --git a/xen/arch/arm/efi/Makefile b/xen/arch/arm/efi/Makefile
index 729e53e..b38a0c9 100644
--- a/xen/arch/arm/efi/Makefile
+++ b/xen/arch/arm/efi/Makefile
@@ -1,3 +1,3 @@
 CFLAGS += -fshort-wchar
 
-obj-y +=  boot.init.o runtime.o
+obj-y +=  boot.init.o runtime.o efi-dom0.init.o
diff --git a/xen/arch/arm/efi/efi-dom0.c 

[Xen-devel] [PATCH v5 18/22] arm/acpi: Permit MMIO access of Xen unused devices for Dom0

[Shannon Zhao]

From: Shannon Zhao 

Firstly it permits full MMIO capabilities for Dom0. Then deny MMIO
access of Xen used devices, such as UART, GIC, SMMU. Currently, it only
denies the MMIO access of UART and GIC regions. For other Xen used
devices it could be added later when they are supported.

Signed-off-by: Shannon Zhao 
---
v5: deny access to GIC regions
---
 xen/arch/arm/domain_build.c | 36 
 1 file changed, 36 insertions(+)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 1e5ee0e..a4abf28 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1359,6 +1359,38 @@ static int prepare_dtb(struct domain *d, struct 
kernel_info *kinfo)
 #ifdef CONFIG_ACPI
 #define ACPI_DOM0_FDT_MIN_SIZE 4096
 
+static int acpi_iomem_deny_access(struct domain *d)
+{
+acpi_status status;
+struct acpi_table_spcr *spcr = NULL;
+unsigned long gfn;
+int rc;
+
+/* Firstly permit full MMIO capabilities. */
+rc = iomem_permit_access(d, 0UL, ~0UL);
+if ( rc )
+return rc;
+
+/* TODO: Deny MMIO access for SMMU, GIC ITS */
+status = acpi_get_table(ACPI_SIG_SPCR, 0,
+(struct acpi_table_header **));
+
+if ( ACPI_FAILURE(status) )
+{
+printk("Failed to get SPCR table\n");
+return -EINVAL;
+}
+
+gfn = spcr->serial_port.address >> PAGE_SHIFT;
+/* Deny MMIO access for UART */
+rc = iomem_deny_access(d, gfn, gfn + 1);
+if ( rc )
+return rc;
+
+/* Deny MMIO access for GIC regions */
+return gic_iomem_deny_access(d);
+}
+
 static int acpi_permit_spi_access(struct domain *d)
 {
 int i, res;
@@ -1880,6 +1912,10 @@ static int prepare_acpi(struct domain *d, struct 
kernel_info *kinfo)
 if ( rc != 0 )
 return rc;
 
+rc = acpi_iomem_deny_access(d);
+if ( rc != 0 )
+return rc;
+
 return 0;
 }
 #else
-- 
2.0.4



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

[Xen-devel] [PATCH V16 5/6] domcreate: support pvusb in configuration file

[Chunyan Liu]

Add code to support pvusb in domain config file. One could specify
usbctrl and usb in domain's configuration file and create domain,
then usb controllers will be created and usb device would be attached
to guest automatically.

One could specify usb controllers and usb devices in config file
like this:
usbctrl=['version=2,ports=4', 'version=1, ports=4', ]
usbdev=['hostbus=2, hostaddr=1, controller=0,port=1', ]

Signed-off-by: Chunyan Liu 
Signed-off-by: Simon Cao 
Reviewed-by: George Dunlap 
Acked-by: Ian Jackson 
---
 docs/man/xl.cfg.pod.5|  84 +
 tools/libxl/libxl_create.c   |  73 +++--
 tools/libxl/libxl_device.c   |   4 ++
 tools/libxl/libxl_internal.h |   8 
 tools/libxl/xl_cmdimpl.c | 107 ++-
 5 files changed, 272 insertions(+), 4 deletions(-)

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index 56b1117..b156caa 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -722,6 +722,90 @@ Note this may be overridden by rdm_policy option in PCI 
device configuration.
 
 =back
 
+=item 

[Xen-devel] [PATCH V16 6/6] xl: add pvusb commands

[Chunyan Liu]

Add pvusb commands: usbctrl-attach, usbctrl-detach, usb-list,
usbdev-attach and usbdev-detach.

To attach a usb device to guest through pvusb, one could follow
following example:

 #xl usbctrl-attach test_vm version=1 ports=8

 #xl usb-list test_vm
 will show the usb controllers and port usage under the domain.

 #xl usbdev-attach test_vm hostbus=1 hostaddr=2
 will find the first usable controller:port, and attach usb
 device whose busnum is 1 and devnum is 6.
 One could also specify which  and which .

 #xl usbdev-detach test_vm 0 1
 will detach USB device under controller 0 port 1.

 #xl usbctrl-detach test_vm dev_id
 will destroy the controller with specified dev_id. Dev_id
 can be traced in usb-list info.

Signed-off-by: Chunyan Liu 
Signed-off-by: Simon Cao 
Reviewed-by: George Dunlap 
---
 docs/man/xl.pod.1 |  37 +
 tools/libxl/xl.h  |   5 ++
 tools/libxl/xl_cmdimpl.c  | 190 ++
 tools/libxl/xl_cmdtable.c |  25 ++
 4 files changed, 257 insertions(+)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index 4279c7c..dc6213e 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -1345,6 +1345,43 @@ List pass-through pci devices for a domain.
 
 =back
 
+=head1 USB PASS-THROUGH
+
+=over 4
+
+=item B I I
+
+Create a new USB controller in the domain specified by I,
+I describes the device to attach, using form

[Xen-devel] [PATCH V16 4/6] libxl: add pvusb API

[Chunyan Liu]

Add pvusb APIs, including:
 - attach/detach (create/destroy) virtual usb controller.
 - attach/detach usb device
 - list usb controller and usb devices
 - some other helper functions

Signed-off-by: Simon Cao 
Signed-off-by: George Dunlap 
Signed-off-by: Chunyan Liu 
---
Changes:
  * Address George's comments

 tools/libxl/Makefile |3 +-
 tools/libxl/libxl.c  |   18 +
 tools/libxl/libxl.h  |   77 ++
 tools/libxl/libxl_device.c   |5 +-
 tools/libxl/libxl_internal.h |   18 +
 tools/libxl/libxl_osdeps.h   |   13 +
 tools/libxl/libxl_pvusb.c| 1620 ++
 tools/libxl/libxl_types.idl  |   46 +
 tools/libxl/libxl_types_internal.idl |1 +
 tools/libxl/libxl_utils.c|   18 +
 tools/libxl/libxl_utils.h|5 +
 11 files changed, 1822 insertions(+), 2 deletions(-)
 create mode 100644 tools/libxl/libxl_pvusb.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 789a12e..8fa7b87 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -105,7 +105,8 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o 
libxl_pci.o \
libxl_stream_read.o libxl_stream_write.o \
libxl_save_callout.o _libxl_save_msgs_callout.o \
libxl_qmp.o libxl_event.o libxl_fork.o \
-   libxl_dom_suspend.o libxl_dom_save.o $(LIBXL_OBJS-y)
+   libxl_dom_suspend.o libxl_dom_save.o libxl_pvusb.o \
+$(LIBXL_OBJS-y)
 LIBXL_OBJS += libxl_genid.o
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 2ab5ad3..1e68688 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -4102,6 +4102,8 @@ out:
  * libxl_device_vkb_destroy
  * libxl_device_vfb_remove
  * libxl_device_vfb_destroy
+ * libxl_device_usbctrl_remove
+ * libxl_device_usbctrl_destroy
  */
 #define DEFINE_DEVICE_REMOVE_EXT(type, remtype, removedestroy, f)\
 int libxl_device_##type##_##removedestroy(libxl_ctx *ctx,   \
@@ -4159,6 +4161,10 @@ DEFINE_DEVICE_REMOVE(vfb, destroy, 1)
 DEFINE_DEVICE_REMOVE(vtpm, remove, 0)
 DEFINE_DEVICE_REMOVE(vtpm, destroy, 1)
 
+/* usbctrl */
+DEFINE_DEVICE_REMOVE_CUSTOM(usbctrl, remove, 0)
+DEFINE_DEVICE_REMOVE_CUSTOM(usbctrl, destroy, 1)
+
 /* channel/console hotunplug is not implemented. There are 2 possibilities:
  * 1. add support for secondary consoles to xenconsoled
  * 2. dynamically add/remove qemu chardevs via qmp messages. */
@@ -4174,6 +4180,8 @@ DEFINE_DEVICE_REMOVE(vtpm, destroy, 1)
  * libxl_device_disk_add
  * libxl_device_nic_add
  * libxl_device_vtpm_add
+ * libxl_device_usbctrl_add
+ * libxl_device_usbdev_add
  */
 
 #define DEFINE_DEVICE_ADD(type) \
@@ -4205,6 +4213,12 @@ DEFINE_DEVICE_ADD(nic)
 /* vtpm */
 DEFINE_DEVICE_ADD(vtpm)
 
+/* usbctrl */
+DEFINE_DEVICE_ADD(usbctrl)
+
+/* usb */
+DEFINE_DEVICE_ADD(usbdev)
+
 #undef DEFINE_DEVICE_ADD
 
 
/**/
@@ -6750,6 +6764,10 @@ int libxl_retrieve_domain_configuration(libxl_ctx *ctx, 
uint32_t domid,
 
 MERGE(pci, pcidevs, COMPARE_PCI, {});
 
+MERGE(usbctrl, usbctrls, COMPARE_USBCTRL, {});
+
+MERGE(usbdev, usbdevs, COMPARE_USB, {});
+
 /* Take care of removable device. We maintain invariant in the
  * insert / remove operation so that:
  * 1. if xenstore is "empty" while JSON is not, the result
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 0859383..5cc3ce3 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -123,6 +123,12 @@
 #define LIBXL_HAVE_DOMAIN_NODEAFFINITY 1
 
 /*
+ * LIBXL_HAVE_PVUSB indicates functions for plugging in USB devices
+ * through pvusb -- both hotplug and at domain creation time..
+ */
+#define LIBXL_HAVE_PVUSB 1
+
+/*
  * LIBXL_HAVE_BUILDINFO_HVM_VENDOR_DEVICE indicates that the
  * libxl_vendor_device field is present in the hvm sections of
  * libxl_domain_build_info. This field tells libxl which
@@ -1536,6 +1542,77 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, 
libxl_device_disk *disk,
const libxl_asyncop_how *ao_how)
LIBXL_EXTERNAL_CALLERS_ONLY;
 
+/*
+ * USB
+ *
+ * For each device removed or added, one of these protocols is available:
+ * - PV (i.e., PVUSB)
+ * - DEVICEMODEL (i.e, qemu)
+ *
+ * PV is available for either PV or HVM domains.  DEVICEMODEL is only
+ * available for HVM domains.  The caller can additionally specify
+ * "AUTO", in which case the library will try to determine the best
+ * protocol automatically.
+ *
+ * At the moment, the only protocol implemented is PV.
+ *
+ * One can add/remove USB controllers to/from guest, and attach/detach USB
+ * devices to/from USB 

[Xen-devel] [PATCH V16 2/6] libxl_utils: add internal function to read sysfs file contents

[Chunyan Liu]

Add a new function libxl_read_sysfs_file_contents to handle sysfs file
specially. It would be used in later pvusb work.

Signed-off-by: Chunyan Liu 
Acked-by: Ian Jackson 
---
 tools/libxl/libxl_internal.h |  4 +++
 tools/libxl/libxl_utils.c| 74 
 2 files changed, 78 insertions(+)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 9c8519a..429ea32 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -4078,6 +4078,10 @@ void libxl__bitmap_copy_best_effort(libxl__gc *gc, 
libxl_bitmap *dptr,
 
 int libxl__count_physical_sockets(libxl__gc *gc, int *sockets);
 
+_hidden int libxl__read_sysfs_file_contents(libxl__gc *gc,
+const char *filename,
+void **data_r,
+int *datalen_r);
 
 #define LIBXL_QEMU_USER_PREFIX "xen-qemuuser"
 #define LIBXL_QEMU_USER_BASE   LIBXL_QEMU_USER_PREFIX"-domid"
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 672d3f8..b0cb9e1 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -396,6 +396,80 @@ int libxl_read_file_contents(libxl_ctx *ctx, const char 
*filename,
 return e;
 }
 
+int libxl__read_sysfs_file_contents(libxl__gc *gc, const char *filename,
+void **data_r, int *datalen_r)
+{
+FILE *f = 0;
+uint8_t *data = 0;
+int datalen = 0;
+int e;
+struct stat stab;
+ssize_t rs;
+
+f = fopen(filename, "r");
+if (!f) {
+if (errno == ENOENT) return ENOENT;
+LOGE(ERROR, "failed to open %s", filename);
+goto xe;
+}
+
+if (fstat(fileno(f), )) {
+LOGE(ERROR, "failed to fstat %s", filename);
+goto xe;
+}
+
+if (!S_ISREG(stab.st_mode)) {
+LOGE(ERROR, "%s is not a plain file", filename);
+errno = ENOTTY;
+goto xe;
+}
+
+if (stab.st_size > INT_MAX) {
+LOG(ERROR, "file %s is far too large", filename);
+errno = EFBIG;
+goto xe;
+}
+
+datalen = stab.st_size;
+
+if (stab.st_size && data_r) {
+data = libxl__malloc(gc, datalen);
+
+/* For sysfs file, datalen is always PAGE_SIZE. 'read'
+ * will return the number of bytes of the actual content,
+ * rs <= datalen is expected.
+ */
+rs = fread(data, 1, datalen, f);
+if (rs < datalen) {
+if (ferror(f)) {
+LOGE(ERROR, "failed to read %s", filename);
+goto xe;
+}
+
+datalen = rs;
+data = libxl__realloc(gc, data, datalen);
+}
+}
+
+if (fclose(f)) {
+f = 0;
+LOGE(ERROR, "failed to close %s", filename);
+goto xe;
+}
+
+if (data_r) *data_r = data;
+if (datalen_r) *datalen_r = datalen;
+
+return 0;
+
+ xe:
+e = errno;
+assert(e != ENOENT);
+if (f) fclose(f);
+return e;
+}
+
+
 #define READ_WRITE_EXACTLY(rw, zero_is_eof, constdata)\
   \
   int libxl_##rw##_exactly(libxl_ctx *ctx, int fd, \
-- 
2.1.4


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

[Xen-devel] [PATCH V16 3/6] refactor DEFINE_DEVICE_REMOVE to fit for more device types

[Chunyan Liu]

For some device type, device removal operation needs to be
handled specially, like usbctrl, it needs to remove all usb
devices under it first, then remove usbctrl. Extend
DEFINE_DEVICE_REMOVE to support generic and custom way
For those need to be handled specially, call
DEFINE_DEVICE_REMOVE_CUSTOM, it requires user defined
libxl__initiate_device_##type##_remove. Otherwise, just
call DEFINE_DEVICE_REMOVE as before.

Signed-off-by: George Dunlap 
Signed-off-by: Chunyan Liu 
---
 tools/libxl/libxl.c  | 18 +-
 tools/libxl/libxl_device.c   | 10 +-
 tools/libxl/libxl_internal.h |  4 ++--
 3 files changed, 20 insertions(+), 12 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 2ac9c0f..2ab5ad3 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -3134,7 +3134,7 @@ void libxl__device_disk_local_initiate_detach(libxl__egc 
*egc,
 aodev->dev = device;
 aodev->callback = local_device_detach_cb;
 aodev->force = 0;
-libxl__initiate_device_remove(egc, aodev);
+libxl__initiate_device_generic_remove(egc, aodev);
 return;
 }
 
@@ -4103,7 +4103,7 @@ out:
  * libxl_device_vfb_remove
  * libxl_device_vfb_destroy
  */
-#define DEFINE_DEVICE_REMOVE(type, removedestroy, f)\
+#define DEFINE_DEVICE_REMOVE_EXT(type, remtype, removedestroy, f)\
 int libxl_device_##type##_##removedestroy(libxl_ctx *ctx,   \
 uint32_t domid, libxl_device_##type *type,  \
 const libxl_asyncop_how *ao_how)\
@@ -4123,13 +4123,19 @@ out:
 aodev->dev = device;\
 aodev->callback = device_addrm_aocomplete;  \
 aodev->force = f;   \
-libxl__initiate_device_remove(egc, aodev);  \
+libxl__initiate_device_##remtype##_remove(egc, aodev);  \
 \
 out:\
-if (rc) return AO_CREATE_FAIL(rc);\
+if (rc) return AO_CREATE_FAIL(rc);  \
 return AO_INPROGRESS;   \
 }
 
+#define DEFINE_DEVICE_REMOVE(type, removedestroy, f) \
+DEFINE_DEVICE_REMOVE_EXT(type, generic, removedestroy, f)
+
+#define DEFINE_DEVICE_REMOVE_CUSTOM(type, removedestroy, f)  \
+DEFINE_DEVICE_REMOVE_EXT(type, type, removedestroy, f)
+
 /* Define all remove/destroy functions and undef the macro */
 
 /* disk */
@@ -4158,6 +4164,8 @@ DEFINE_DEVICE_REMOVE(vtpm, destroy, 1)
  * 2. dynamically add/remove qemu chardevs via qmp messages. */
 
 #undef DEFINE_DEVICE_REMOVE
+#undef DEFINE_DEVICE_REMOVE_CUSTOM
+#undef DEFINE_DEVICE_REMOVE_EXT
 
 
/**/
 
@@ -4362,7 +4370,7 @@ static int remove_device(libxl__egc *egc, libxl__ao *ao,
 aodev->dev = dev;
 aodev->action = LIBXL__DEVICE_ACTION_REMOVE;
 aodev->callback = device_complete;
-libxl__initiate_device_remove(egc, aodev);
+libxl__initiate_device_generic_remove(egc, aodev);
 break;
 case LIBXL__DEVICE_KIND_QDISK:
 if (--dguest->num_qdisks == 0) {
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index 8bb5e93..a356e2a 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -676,7 +676,7 @@ void libxl__devices_destroy(libxl__egc *egc, 
libxl__devices_remove_state *drs)
 aodev->action = LIBXL__DEVICE_ACTION_REMOVE;
 aodev->dev = dev;
 aodev->force = drs->force;
-libxl__initiate_device_remove(egc, aodev);
+libxl__initiate_device_generic_remove(egc, aodev);
 }
 }
 }
@@ -775,8 +775,8 @@ out:
 return;
 }
 
-void libxl__initiate_device_remove(libxl__egc *egc,
-   libxl__ao_device *aodev)
+void libxl__initiate_device_generic_remove(libxl__egc *egc,
+   libxl__ao_device *aodev)
 {
 STATE_AO_GC(aodev->ao);
 xs_transaction_t t = 0;
@@ -806,7 +806,7 @@ void libxl__initiate_device_remove(libxl__egc *egc,
 (info.paused || info.dying || info.shutdown)) {
 /*
  * TODO: 4.2 Bodge due to QEMU, see comment on top of
- * libxl__initiate_device_remove in libxl_internal.h
+ * libxl__initiate_device_generic_remove in libxl_internal.h
  */
 rc = libxl__ev_time_register_rel(ao, >timeout,
  device_qemu_timeout,
@@ -942,7 +942,7 @@ static void device_backend_callback(libxl__egc *egc, 
libxl__ev_devstate 

[Xen-devel] [PATCH V16 0/6] xen pvusb toolstack work

[Chunyan Liu]

This patch series is to add pvusb toolstack work, supporting hot add|remove
USB device to|from guest and specify USB device in domain configuration file.

Changes to V15:
* address George's comments (patch 4/6)

V15:
http://lists.xen.org/archives/html/xen-devel/2016-03/msg00040.html

V14:
http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg02745.html

V13:
http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg02125.html

V12:
http://lists.xen.org/archives/html/xen-devel/2015-12/msg02697.html

V11:
http://lists.xen.org/archives/html/xen-devel/2015-12/msg01626.html

V10:
http://lists.xen.org/archives/html/xen-devel/2015-12/msg01172.html

V9:
http://lists.xen.org/archives/html/xen-devel/2015-11/msg02744.html

V8:
http://lists.xen.org/archives/html/xen-devel/2015-10/msg02178.html

V7:
http://lists.xen.org/archives/html/xen-devel/2015-09/msg03115.html

V6:
http://lists.xen.org/archives/html/xen-devel/2015-08/msg00750.html

V5:
http://lists.xen.org/archives/html/xen-devel/2015-06/msg04052.html

V4:
http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg01327.html

Related Discussion Threads:
http://www.redhat.com/archives/libvir-list/2014-June/msg00038.html
http://lists.xen.org/archives/html/xen-devel/2014-06/msg00086.html

  <<< pvusb work introduction >>>

1. Overview

There are two general methods for passing through individual host
devices to a guest. The first is via an emulated USB device
controller; the second is PVUSB.

Additionally, there are two ways to add USB devices to a guest: via
the config file at domain creation time, and via hot-plug while the VM
is running.

* Emulated USB

In emulated USB, the device model (qemu) presents an emulated USB
controller to the guest. The device model process then grabs control
of the device from domain 0 and and passes the USB commands between
the guest OS and the host USB device.

This method is only available to HVM domains, and is not available for
domains running with device model stubdomains.

* PVUSB

PVUSB uses a paravirtialized front-end/back-end interface, similar to
the traditional Xen PV network and disk protocols. In order to use
PVUSB, you need usbfront in your guest OS, and usbback in dom0 (or
your USB driver domain).

2. Specifying a host USB device

QEMU qmp commands allows USB devices to be specified either by their
bus address (in the form bus.device) or their device tag (in the form
vendorid:deviceid).

Each way of specifying has its advantages:

Specifying by device tag will always get the same device,
regardless of where the device ends up in the USB bus topology.
However, if there are two identical devices, it will not allow you to
specify which one.

Specifying by bus address will always allow you to choose a
specific device, even if you have duplicates. However, the bus address
may change depending on which port you plugged the device into, and
possibly also after a reboot.

To avoid duplication of vendorid:deviceid, we'll use bus address to
specify host USB device in xl toolstack.

You can use lsusb to list the USB devices on the system:

Bus 001 Device 003: ID 0424:2514 Standard Microsystems Corp. USB 2.0
Hub
Bus 003 Device 002: ID f617:0905
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 004: ID 0424:2640 Standard Microsystems Corp. USB 2.0
Hub
Bus 001 Device 005: ID 0424:4060 Standard Microsystems Corp. Ultra
Fast Media Reader
Bus 001 Device 006: ID 046d:c016 Logitech, Inc. Optical Wheel Mouse

To pass through the Logitec mouse, for instance, you could specify
1.6 (remove leading zeroes).

Note: USB hubs can not be assigned to guest.

3. PVUSB toolstack

* Specify USB device in xl config file

You can just specify usb devices, like:
usbdev=['hostbus=1, hostaddr=6']

Then it will create a USB controller automatically and attach the USB
device to the first available USB controller:port.

or, you can explicitly specify usb controllers and usb devices, like:
usbctrl=['verison=1, ports=4', 'version=2, ports=8', ]
usbdev=['hostbus=1, hostaddr=6, controller=0, port=1']

Then it will create two USB controllers as you specified.
And if controller and port are specified in usb config, then it will
attach the USB device to that controller:port. About the controller
and port value:
Each USB controller has a index (or called devid) based on 0. The 1st
controller has index 0, the 2nd controller has index 1, ...
Under controller, each port has a port number based on 1. In above
configuration, the 1st controller will have port 1,2,3,4.

* Hot-Plug USB device

To attach a USB device, you should first create a USB controller.
e.g.
xl usbctrl-attach domain [version=1|2] [ports=value]
By default, it will create a USB2.0 controller with 8 ports.

Then you could attach a USB device.
e.g.
xl usbdev-attach domain hostbus=1 hostaddr=6 [controller=index port=number]
By default, it will find the 1st available controller:port to attach
the USB device.

You could view USB device status 

[Xen-devel] [PATCH V16 1/6] libxl: export some functions for pvusb use

[Chunyan Liu]

Signed-off-by: Chunyan Liu 
Signed-off-by: Simon Cao 
Reviewed-by: Wei Liu 
Acked-by: Ian Jackson 
---
 tools/libxl/libxl.c  | 5 ++---
 tools/libxl/libxl_internal.h | 3 +++
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 833fd40..2ac9c0f 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1966,7 +1966,7 @@ out:
 }
 
 /* common function to get next device id */
-static int libxl__device_nextid(libxl__gc *gc, uint32_t domid, char *device)
+int libxl__device_nextid(libxl__gc *gc, uint32_t domid, char *device)
 {
 char *dompath, **l;
 unsigned int nb;
@@ -1985,8 +1985,7 @@ static int libxl__device_nextid(libxl__gc *gc, uint32_t 
domid, char *device)
 return nextid;
 }
 
-static int libxl__resolve_domid(libxl__gc *gc, const char *name,
-uint32_t *domid)
+int libxl__resolve_domid(libxl__gc *gc, const char *name, uint32_t *domid)
 {
 if (!name)
 return 0;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index cb9790b..9c8519a 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1180,6 +1180,9 @@ _hidden int libxl__init_console_from_channel(libxl__gc 
*gc,
  libxl__device_console *console,
  int dev_num,
  libxl_device_channel *channel);
+_hidden int libxl__device_nextid(libxl__gc *gc, uint32_t domid, char *device);
+_hidden int libxl__resolve_domid(libxl__gc *gc, const char *name,
+ uint32_t *domid);
 
 /*
  * For each aggregate type which can be used as an input we provide:
-- 
2.1.4


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

[Xen-devel] [PATCH V16 3/6] refactor DEFINE_DEVICE_REMOVE to fit for more device types

[Chunyan Liu]

For some device type, device removal operation needs to be
handled specially, like usbctrl, it needs to remove all usb
devices under it first, then remove usbctrl. Extend
DEFINE_DEVICE_REMOVE to support generic and custom way
For those need to be handled specially, call
DEFINE_DEVICE_REMOVE_CUSTOM, it requires user defined
libxl__initiate_device_##type##_remove. Otherwise, just
call DEFINE_DEVICE_REMOVE as before.

Signed-off-by: George Dunlap 
Signed-off-by: Chunyan Liu 
---
 tools/libxl/libxl.c  | 18 +-
 tools/libxl/libxl_device.c   | 10 +-
 tools/libxl/libxl_internal.h |  4 ++--
 3 files changed, 20 insertions(+), 12 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 2ac9c0f..2ab5ad3 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -3134,7 +3134,7 @@ void libxl__device_disk_local_initiate_detach(libxl__egc 
*egc,
 aodev->dev = device;
 aodev->callback = local_device_detach_cb;
 aodev->force = 0;
-libxl__initiate_device_remove(egc, aodev);
+libxl__initiate_device_generic_remove(egc, aodev);
 return;
 }
 
@@ -4103,7 +4103,7 @@ out:
  * libxl_device_vfb_remove
  * libxl_device_vfb_destroy
  */
-#define DEFINE_DEVICE_REMOVE(type, removedestroy, f)\
+#define DEFINE_DEVICE_REMOVE_EXT(type, remtype, removedestroy, f)\
 int libxl_device_##type##_##removedestroy(libxl_ctx *ctx,   \
 uint32_t domid, libxl_device_##type *type,  \
 const libxl_asyncop_how *ao_how)\
@@ -4123,13 +4123,19 @@ out:
 aodev->dev = device;\
 aodev->callback = device_addrm_aocomplete;  \
 aodev->force = f;   \
-libxl__initiate_device_remove(egc, aodev);  \
+libxl__initiate_device_##remtype##_remove(egc, aodev);  \
 \
 out:\
-if (rc) return AO_CREATE_FAIL(rc);\
+if (rc) return AO_CREATE_FAIL(rc);  \
 return AO_INPROGRESS;   \
 }
 
+#define DEFINE_DEVICE_REMOVE(type, removedestroy, f) \
+DEFINE_DEVICE_REMOVE_EXT(type, generic, removedestroy, f)
+
+#define DEFINE_DEVICE_REMOVE_CUSTOM(type, removedestroy, f)  \
+DEFINE_DEVICE_REMOVE_EXT(type, type, removedestroy, f)
+
 /* Define all remove/destroy functions and undef the macro */
 
 /* disk */
@@ -4158,6 +4164,8 @@ DEFINE_DEVICE_REMOVE(vtpm, destroy, 1)
  * 2. dynamically add/remove qemu chardevs via qmp messages. */
 
 #undef DEFINE_DEVICE_REMOVE
+#undef DEFINE_DEVICE_REMOVE_CUSTOM
+#undef DEFINE_DEVICE_REMOVE_EXT
 
 
/**/
 
@@ -4362,7 +4370,7 @@ static int remove_device(libxl__egc *egc, libxl__ao *ao,
 aodev->dev = dev;
 aodev->action = LIBXL__DEVICE_ACTION_REMOVE;
 aodev->callback = device_complete;
-libxl__initiate_device_remove(egc, aodev);
+libxl__initiate_device_generic_remove(egc, aodev);
 break;
 case LIBXL__DEVICE_KIND_QDISK:
 if (--dguest->num_qdisks == 0) {
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index 8bb5e93..a356e2a 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -676,7 +676,7 @@ void libxl__devices_destroy(libxl__egc *egc, 
libxl__devices_remove_state *drs)
 aodev->action = LIBXL__DEVICE_ACTION_REMOVE;
 aodev->dev = dev;
 aodev->force = drs->force;
-libxl__initiate_device_remove(egc, aodev);
+libxl__initiate_device_generic_remove(egc, aodev);
 }
 }
 }
@@ -775,8 +775,8 @@ out:
 return;
 }
 
-void libxl__initiate_device_remove(libxl__egc *egc,
-   libxl__ao_device *aodev)
+void libxl__initiate_device_generic_remove(libxl__egc *egc,
+   libxl__ao_device *aodev)
 {
 STATE_AO_GC(aodev->ao);
 xs_transaction_t t = 0;
@@ -806,7 +806,7 @@ void libxl__initiate_device_remove(libxl__egc *egc,
 (info.paused || info.dying || info.shutdown)) {
 /*
  * TODO: 4.2 Bodge due to QEMU, see comment on top of
- * libxl__initiate_device_remove in libxl_internal.h
+ * libxl__initiate_device_generic_remove in libxl_internal.h
  */
 rc = libxl__ev_time_register_rel(ao, >timeout,
  device_qemu_timeout,
@@ -942,7 +942,7 @@ static void device_backend_callback(libxl__egc *egc, 
libxl__ev_devstate 

[Xen-devel] [PATCH V16 2/6] libxl_utils: add internal function to read sysfs file contents

[Chunyan Liu]

Add a new function libxl_read_sysfs_file_contents to handle sysfs file
specially. It would be used in later pvusb work.

Signed-off-by: Chunyan Liu 
Acked-by: Ian Jackson 
---
 tools/libxl/libxl_internal.h |  4 +++
 tools/libxl/libxl_utils.c| 74 
 2 files changed, 78 insertions(+)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 9c8519a..429ea32 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -4078,6 +4078,10 @@ void libxl__bitmap_copy_best_effort(libxl__gc *gc, 
libxl_bitmap *dptr,
 
 int libxl__count_physical_sockets(libxl__gc *gc, int *sockets);
 
+_hidden int libxl__read_sysfs_file_contents(libxl__gc *gc,
+const char *filename,
+void **data_r,
+int *datalen_r);
 
 #define LIBXL_QEMU_USER_PREFIX "xen-qemuuser"
 #define LIBXL_QEMU_USER_BASE   LIBXL_QEMU_USER_PREFIX"-domid"
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 672d3f8..b0cb9e1 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -396,6 +396,80 @@ int libxl_read_file_contents(libxl_ctx *ctx, const char 
*filename,
 return e;
 }
 
+int libxl__read_sysfs_file_contents(libxl__gc *gc, const char *filename,
+void **data_r, int *datalen_r)
+{
+FILE *f = 0;
+uint8_t *data = 0;
+int datalen = 0;
+int e;
+struct stat stab;
+ssize_t rs;
+
+f = fopen(filename, "r");
+if (!f) {
+if (errno == ENOENT) return ENOENT;
+LOGE(ERROR, "failed to open %s", filename);
+goto xe;
+}
+
+if (fstat(fileno(f), )) {
+LOGE(ERROR, "failed to fstat %s", filename);
+goto xe;
+}
+
+if (!S_ISREG(stab.st_mode)) {
+LOGE(ERROR, "%s is not a plain file", filename);
+errno = ENOTTY;
+goto xe;
+}
+
+if (stab.st_size > INT_MAX) {
+LOG(ERROR, "file %s is far too large", filename);
+errno = EFBIG;
+goto xe;
+}
+
+datalen = stab.st_size;
+
+if (stab.st_size && data_r) {
+data = libxl__malloc(gc, datalen);
+
+/* For sysfs file, datalen is always PAGE_SIZE. 'read'
+ * will return the number of bytes of the actual content,
+ * rs <= datalen is expected.
+ */
+rs = fread(data, 1, datalen, f);
+if (rs < datalen) {
+if (ferror(f)) {
+LOGE(ERROR, "failed to read %s", filename);
+goto xe;
+}
+
+datalen = rs;
+data = libxl__realloc(gc, data, datalen);
+}
+}
+
+if (fclose(f)) {
+f = 0;
+LOGE(ERROR, "failed to close %s", filename);
+goto xe;
+}
+
+if (data_r) *data_r = data;
+if (datalen_r) *datalen_r = datalen;
+
+return 0;
+
+ xe:
+e = errno;
+assert(e != ENOENT);
+if (f) fclose(f);
+return e;
+}
+
+
 #define READ_WRITE_EXACTLY(rw, zero_is_eof, constdata)\
   \
   int libxl_##rw##_exactly(libxl_ctx *ctx, int fd, \
-- 
2.1.4


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

[Xen-devel] [PATCH V16 1/6] libxl: export some functions for pvusb use

[Chunyan Liu]

Signed-off-by: Chunyan Liu 
Signed-off-by: Simon Cao 
Reviewed-by: Wei Liu 
Acked-by: Ian Jackson 
---
 tools/libxl/libxl.c  | 5 ++---
 tools/libxl/libxl_internal.h | 3 +++
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 833fd40..2ac9c0f 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1966,7 +1966,7 @@ out:
 }
 
 /* common function to get next device id */
-static int libxl__device_nextid(libxl__gc *gc, uint32_t domid, char *device)
+int libxl__device_nextid(libxl__gc *gc, uint32_t domid, char *device)
 {
 char *dompath, **l;
 unsigned int nb;
@@ -1985,8 +1985,7 @@ static int libxl__device_nextid(libxl__gc *gc, uint32_t 
domid, char *device)
 return nextid;
 }
 
-static int libxl__resolve_domid(libxl__gc *gc, const char *name,
-uint32_t *domid)
+int libxl__resolve_domid(libxl__gc *gc, const char *name, uint32_t *domid)
 {
 if (!name)
 return 0;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index cb9790b..9c8519a 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1180,6 +1180,9 @@ _hidden int libxl__init_console_from_channel(libxl__gc 
*gc,
  libxl__device_console *console,
  int dev_num,
  libxl_device_channel *channel);
+_hidden int libxl__device_nextid(libxl__gc *gc, uint32_t domid, char *device);
+_hidden int libxl__resolve_domid(libxl__gc *gc, const char *name,
+ uint32_t *domid);
 
 /*
  * For each aggregate type which can be used as an input we provide:
-- 
2.1.4


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

[Xen-devel] [PATCH V16 0/6] xen pvusb toolstack work

[Chunyan Liu]

This patch series is to add pvusb toolstack work, supporting hot add|remove
USB device to|from guest and specify USB device in domain configuration file.

Changes to V15:
* address George's comments (patch 4/6)

V15:
http://lists.xen.org/archives/html/xen-devel/2016-03/msg00040.html

V14:
http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg02745.html

V13:
http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg02125.html

V12:
http://lists.xen.org/archives/html/xen-devel/2015-12/msg02697.html

V11:
http://lists.xen.org/archives/html/xen-devel/2015-12/msg01626.html

V10:
http://lists.xen.org/archives/html/xen-devel/2015-12/msg01172.html

V9:
http://lists.xen.org/archives/html/xen-devel/2015-11/msg02744.html

V8:
http://lists.xen.org/archives/html/xen-devel/2015-10/msg02178.html

V7:
http://lists.xen.org/archives/html/xen-devel/2015-09/msg03115.html

V6:
http://lists.xen.org/archives/html/xen-devel/2015-08/msg00750.html

V5:
http://lists.xen.org/archives/html/xen-devel/2015-06/msg04052.html

V4:
http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg01327.html

Related Discussion Threads:
http://www.redhat.com/archives/libvir-list/2014-June/msg00038.html
http://lists.xen.org/archives/html/xen-devel/2014-06/msg00086.html

  <<< pvusb work introduction >>>

1. Overview

There are two general methods for passing through individual host
devices to a guest. The first is via an emulated USB device
controller; the second is PVUSB.

Additionally, there are two ways to add USB devices to a guest: via
the config file at domain creation time, and via hot-plug while the VM
is running.

* Emulated USB

In emulated USB, the device model (qemu) presents an emulated USB
controller to the guest. The device model process then grabs control
of the device from domain 0 and and passes the USB commands between
the guest OS and the host USB device.

This method is only available to HVM domains, and is not available for
domains running with device model stubdomains.

* PVUSB

PVUSB uses a paravirtialized front-end/back-end interface, similar to
the traditional Xen PV network and disk protocols. In order to use
PVUSB, you need usbfront in your guest OS, and usbback in dom0 (or
your USB driver domain).

2. Specifying a host USB device

QEMU qmp commands allows USB devices to be specified either by their
bus address (in the form bus.device) or their device tag (in the form
vendorid:deviceid).

Each way of specifying has its advantages:

Specifying by device tag will always get the same device,
regardless of where the device ends up in the USB bus topology.
However, if there are two identical devices, it will not allow you to
specify which one.

Specifying by bus address will always allow you to choose a
specific device, even if you have duplicates. However, the bus address
may change depending on which port you plugged the device into, and
possibly also after a reboot.

To avoid duplication of vendorid:deviceid, we'll use bus address to
specify host USB device in xl toolstack.

You can use lsusb to list the USB devices on the system:

Bus 001 Device 003: ID 0424:2514 Standard Microsystems Corp. USB 2.0
Hub
Bus 003 Device 002: ID f617:0905
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 004: ID 0424:2640 Standard Microsystems Corp. USB 2.0
Hub
Bus 001 Device 005: ID 0424:4060 Standard Microsystems Corp. Ultra
Fast Media Reader
Bus 001 Device 006: ID 046d:c016 Logitech, Inc. Optical Wheel Mouse

To pass through the Logitec mouse, for instance, you could specify
1.6 (remove leading zeroes).

Note: USB hubs can not be assigned to guest.

3. PVUSB toolstack

* Specify USB device in xl config file

You can just specify usb devices, like:
usbdev=['hostbus=1, hostaddr=6']

Then it will create a USB controller automatically and attach the USB
device to the first available USB controller:port.

or, you can explicitly specify usb controllers and usb devices, like:
usbctrl=['verison=1, ports=4', 'version=2, ports=8', ]
usbdev=['hostbus=1, hostaddr=6, controller=0, port=1']

Then it will create two USB controllers as you specified.
And if controller and port are specified in usb config, then it will
attach the USB device to that controller:port. About the controller
and port value:
Each USB controller has a index (or called devid) based on 0. The 1st
controller has index 0, the 2nd controller has index 1, ...
Under controller, each port has a port number based on 1. In above
configuration, the 1st controller will have port 1,2,3,4.

* Hot-Plug USB device

To attach a USB device, you should first create a USB controller.
e.g.
xl usbctrl-attach domain [version=1|2] [ports=value]
By default, it will create a USB2.0 controller with 8 ports.

Then you could attach a USB device.
e.g.
xl usbdev-attach domain hostbus=1 hostaddr=6 [controller=index port=number]
By default, it will find the 1st available controller:port to attach
the USB device.

You could view USB device status 

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

[osstest service owner]

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

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-debianhvm-i386 9 debian-hvm-install fail pass in 
85248

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  03720ea541382a3ca80eaaec2aa11932b03aacaf
baseline version:
 xen  7ba900efe5f526c941b1ca055e5347947bb7eb4b

Last test of basis85080  2016-03-02 16:00:54 Z1 days
Testing same since85178  2016-03-03 09:20:13 Z0 days9 attempts


People who touched revisions under test:
  Andrew Cooper 
  Aravind Gopalakrishnan 
  Boris Ostrovsky 
  Dario Faggioli 
  Hanjun Guo 
  Jan Beulich 
  Juergen Gross 
  Naresh Bhat 
  Parth Dixit 
  Shannon Zhao 
  Shannon Zhao 
  Stefano Stabellini 
  Tomasz Nowicki 

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



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

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

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

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


Not pushing.

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

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

Re: [Xen-devel] [PATCH v4 14/24] arm/acpi: Prepare EFI system table for Dom0

[Shannon Zhao]

On 2016/3/1 20:49, Stefano Stabellini wrote:
> On Tue, 1 Mar 2016, Jan Beulich wrote:
> > >>> On 01.03.16 at 03:35,  wrote:
>> > 
>>> > > 
>>> > > On 2016/2/29 22:36, Jan Beulich wrote:
>>> > > On 29.02.16 at 15:25,  wrote:
>> > >>> > On Mon, 29 Feb 2016, Jan Beulich wrote:
 >  >> Also it doesn't look very nice to me to (ab)use xz's CRC32 
 >  >> code
 >  >> here; I don't know who has suggested doing so.
>> > >>> >  
>> > >>> > It was suggested by Julien.
>> > >>> > 
>> > >>> > I agree that including ../../../common/xz/crc32.c seems a bit 
>> > >>> > fragile
>> > >>> > but introducing another copy of xz_crc32 seems even worse to me 
>> > >>> > (see
>> > >>> > http://marc.info/?l=xen-devel=144775375427921=2). Maybe you 
>> > >>> > have a
>> > >>> > better suggestion?
 > >> Well, at some point there was talk of ARM not wanting to
 > >> ExitBootServices() as early as x86 does. In that case there
 > >> would be a CRC32 function among the various boot services
 > >> ones.
 > >> 
>>> > > At this point, I think it already ExitBootServices() while it's creating
>>> > > Dom0.
>> > 
>> > I understand that's the case today, hence my saying "at some
>> > point there was talk of ...".
>> > 
 > >> The other option would be to have a generic crc32() function,
 > >> and maybe make xz use it.
>>> > > Ok, I'll go for this way.
>> > 
>> > Well, for the avoidance of doubt: With the code moving into an
>> > ARM specific file, if Stefano is fine with the xz hack, I certainly
>> > won't insist on you adding a separate crc32().
> Having a generic crc32() function like you suggested would be nicer than
> the xz hack. If Shannon is OK with doing that, it would be best.
Since this will introduce more changes, I want to stay with current way.

Thanks,
-- 
Shannon


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

Re: [Xen-devel] Fixation on polarssl 1.1.4 - EOL was 2013-10-01

[Xu, Quan]

On February 16, 2016 1:08am,  wrote:
> On Mon, Feb 15, 2016 at 10:45:48AM -0600, Doug Goldstein wrote:
> > On 2/15/16 10:28 AM, Wei Liu wrote:
> > > On Sun, Feb 14, 2016 at 07:39:35PM +1100, Steven Haigh wrote:
> > >> Hi all,
> > >>
> > >> Just been looking at the polarssl parts in Xen 4.6 and others -
> > >> seems like we're hard coded to version 1.1.4 which was released on 31st
> May 2012.
> > >>
> > >> Branch 1.1.x has been EOL for a number of years, 1.2.x has been EOL
> > >> since Jan.
> > >>
> > >> It's now called mbedtls and current versions are 2.2.1 released in
> > >> Jan this year.
> > >>
> > >> I'm not exactly clear on what polarssl is used for (and why not
> > >> openssl?) - but is it time this was shown some loving?
> > >>
> > >
> > > I grep'ed for polarssl in tree and the only user seems to be vtpm.
> > > I've CC'ed Daniel and Quan for you.
> > >
> > > Wei.
> > >
> >
> > Looks like pv-grub has a build dependency on it as well based on the
> > snippet from stubdom/Makefile.
> >
> > .PHONY: grub
> > grub: cross-polarssl grub-upstream $(CROSS_ROOT)
> >
> 
> Oh, yes, you're right.
> 
> Looking at the source code pv-grub only needs the sha1 function from polarssl
> which might be easy to dealt with though. On the other hand, if there is no
> critical bug fix to the sha1 function, I wouldn't bother upgrading polarssl.
> 
> In fact, I think vtpm also only cares about some crypto algorithms like AES 
> and
> SHA. We'd better check if there is any critical update to those functions 
> before
> doing anything.
> 


Agreed.
If you really want to upgrade it, IMO this change would be backward compatible.
btw, it may be not an easy task to build the test env, and I can help you test 
your patch.

Quan

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

Re: [Xen-devel] [PATCH V15 4/6] libxl: add pvusb API

[Chun Yan Liu]

>>> On 3/3/2016 at 05:27 PM, in message
, George
Dunlap  wrote: 
> On Thu, Mar 3, 2016 at 2:59 AM, Chun Yan Liu  wrote: 
> On 3/3/2016 at 02:46 AM, in message <56d7350f.7010...@citrix.com>, George 
> > Dunlap  wrote: 
> >> Sorry, just looked through the rest of the series, and there's one more 
> >> thing. 
> >> 
> >> Neither here nor in the man page do we explain what to do if something 
> >> goes wrong with the detach.  I think the best thing to do is probably to 
> >> make the logged error messages more helpful. 
> >> 
> >> What about something like this: 
> >> 
> >> * On failure to unbind: "Error removing device from guest.  Try running 
> >> usbdev-detach again." 
> >> 
> >> * On failure to rebind: "USB device removed from guest, but couldn't 
> >> re-bind to domain 0.  Try removing and re-inserting the USB device or 
> >> reloading the driver modules." 
> > Here, user could first try 'echo xxx > sysfs_driver_path/bind", so maybe: 
> > "Try binding USB device to original driver by echoing the device to 
> > [driver_path]/bind, or removing and re-inserting the USB device, or 
> > reloading the driver modules." 
>  
> Yes, I had thought about the idea of giving the user specific commands 
> to retry.  The question is how much we can expect the user to do to 
> recover the state.  At some point "reloading the driver module" was 
> seen as something reasonable for a reasonably advanced user, while 
> "messing around with sysfs" was seen to be something too technical. 
> But as you say, giving them the exact command to cut-and-paste might 
> be somewhat more reasonable. 
>  
> I'm still inclined to say that we should just stick with module 
> reloading and removing and re-inserting the device, but I wouldn't 
> insist on it. 

I see. Just use what you suggested. Will update and repost.

Thanks,
Chunyan

>  
> If we do print this kind of help message, then we should make sure to 
> print a more complete message that includes cut-and-paste commands for 
> *all* remaining unbound interfaces. 
>  
>  -George 
>  
> ___ 
> Xen-devel mailing list 
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 
>  



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

Re: [Xen-devel] [PATCH V15 4/6] libxl: add pvusb API

[Chun Yan Liu]

>>> On 3/3/2016 at 05:20 PM, in message
, George
Dunlap  wrote: 
> On Thu, Mar 3, 2016 at 3:11 AM, Chun Yan Liu  wrote: 
> On 3/3/2016 at 02:32 AM, in message <56d731b1.60...@citrix.com>, George 
> Dunlap 
> >  wrote: 
> >> On 01/03/16 08:09, Chunyan Liu wrote: 
> >> > +static int usbdev_rebind(libxl__gc *gc, const char *busid) 
> >> > +{ 
> >> > +char **intfs = NULL; 
> >> > +char *usbdev_encode = NULL; 
> >> > +char *path = NULL; 
> >> > +int i, num = 0; 
> >> > +int rc; 
> >> > + 
> >> > +rc = usbdev_get_all_interfaces(gc, busid, , ); 
> >> > +if (rc) goto out; 
> >> > + 
> >> > +usbdev_encode = usb_interface_xenstore_encode(gc, busid); 
> >> > + 
> >> > +for (i = 0; i < num; i++) { 
> >> > +char *intf = intfs[i]; 
> >> > +char *usbintf_encode = NULL; 
> >> > +const char *drvpath; 
> >> > + 
> >> > +/* rebind USB interface to its originial driver */ 
> >> > +usbintf_encode = usb_interface_xenstore_encode(gc, intf); 
> >> > +path = GCSPRINTF(USBBACK_INFO_PATH "/%s/%s/driver_path", 
> >> > + usbdev_encode, usbintf_encode); 
> >> > +rc = libxl__xs_read_checked(gc, XBT_NULL, path, ); 
> >> > +if (rc) goto out; 
> >> > + 
> >> > +if (drvpath) { 
> >> > +rc = bind_usbintf(gc, intf, drvpath); 
> >> > +if (rc) { 
> >> > +LOGE(ERROR, "Couldn't rebind %s to %s", intf, drvpath); 
> >> > +goto out; 
> >> > +} 
> >> > +} 
> >> > +} 
> >> > + 
> >> > +path = GCSPRINTF(USBBACK_INFO_PATH "/%s", usbdev_encode); 
> >> > +rc = libxl__xs_rm_checked(gc, XBT_NULL, path); 
> >> > + 
> >> > +out: 
> >> 
> >> So it looks like if one of the re-binds fails, then it stops where it is 
> >> and leaves the USBBACK re-bind info in xenstore.  In that case it's not 
> >> clear to me how that information would ever be removed. 
> >> 
> >> I think until such time as we have a command to re-attempt the re-bind, 
> >>  if there's an error in the actual rebind, it should just break out of 
> >> the for loop, and remove the re-bind nodes, and document a way to let 
> >> the user try to clean things up. 
> > 
> > Just according to last time discussion about how to handle the rebind 
> > failure, seems Ian preferred to add a xl command to deal with rebind 
> > in future, based on that need, I think driver_path info should be kept 
> > in xenstore then. Without that need, I agree it's best to remove 
> > xenstore nodes. So, keep or remove? 
>  
> Well when we have such a command, then yes, we'll need to keep the 
> nodes for it to use and delete.  But at the moment, we have no such 
> command, so these nodes will just sit around cluttering up the libxl 
> xenstore space, and nothing will delete them (unless a user manually 
> runs xenstore-rm). 
>  
> So I think for now we should delete them on failure; and at some point 
> later, when someone implements a recovery command, then they should 
> change this code to not delete the xenstore nodes (and also change the 
> log messages to point to that command). 

OK. Got it. Will update.

-  Chunyan

>  
>  -George 
>  
>  


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

Re: [Xen-devel] [PATCH v6 3/5] IOMMU: Make the pcidevs_lock a recursive one

[Xu, Quan]

On March 04, 2016 7:59am,  wrote:
> On Wed, 2016-03-02 at 22:31 +0800, Quan Xu wrote:
> > Signed-off-by: Quan Xu 
> >
> So, this patch looks ok to me.
> 
> I spotted something, though, that I think needs some attention.
> 
> Since I'm jumping on this series only now, if this has been discussed before 
> and I
> missed it, sorry for the noise.
> 

Dario, Welcome~  it's never too late.:)

> > @@ -788,10 +787,10 @@ static bool_t __init
> > set_iommu_interrupt_handler(struct amd_iommu *iommu)
> >  return 0;
> >  }
> >
> > -spin_lock_irqsave(_lock, flags);
> > +pcidevs_lock();
> >
> So, spin_lock_irqsave() does:
>   local_irq_save()
>     local_save_flags()
>     local_irq_disable()
>   _spin_lock()
> 
> i.e., it saves the flags and disable interrupts.
> 
> pcidevs_lock() does:
>   spin_lock_recursive()
>     ... //handle recursion
>     _spin_lock()
> 
> i.e., it does not disable interrupts.
> 
> And therefore it is possible that we are actually skipping disabling 
> interrupts (if
> they're not disabled already), isn't it?
> 
> And, of course, the same reasoning --mutatis mutandis-- applies to the unlock
> side of things.
> 
> >  iommu->msi.dev = pci_get_pdev(iommu->seg, PCI_BUS(iommu->bdf),
> >    PCI_DEVFN2(iommu->bd
> f));
> > -spin_unlock_irqrestore(_lock, flags);
> > +pcidevs_unlock();
> >
> i.e., spin_unlock_irqrestore() restore the flags, including the interrupt
> enabled/disabled status, which means it can re-enable the interrupts or not,
> depending on whether they were enabled at the time of the previous
> spin_lock_irqsave(); pcidevs_unlock() just don't affect interrupt
> enabling/disabling at all.
> 
> So, if the original code is correct in using
> spin_lock_irqsave()/spin_unlock_irqrestore(), I think that we need
> _irqsave() and _irqrestore() variants of recursive spinlocks, in order to 
> deal with
> this case.
> 
> However, from a quick inspection, it looks to me that:
>  - this can only be called (during initialization), with interrupt
>    enabled, so least saving & restoring flags shouldn't be necessary
>    (unless I missed where they can be disabled in the call chain
>    from iommu_setup() toward set_iommu_interrupt_handler()).
>  - This protects pci_get_dev(); looking at other places where
>    pci_get_dev() is called, I don't think it is really necessary to
>    disable interrupts.
> 
> If I'm right, it means that the original code could well have been using just 
> plain
> spin_lock() and spin_unlock(), and it would then be fine to turn them into
> pcidevs_lock() and pcidevs_unlock(), and so no need to add more
> spin_[un]lock_recursive() variants.
> 
> That would also mean that the patch is indeed ok, 

Yes, I fully agree your analysis and conclusion.
I tried to implement _irqsave() and _irqrestore() variants of recursive 
spinlocks, but I found that it is no need to add them.

Also I'd highlight the below modification:
-if ( !spin_trylock(_lock) )
-return -ERESTART;
-
+pcidevs_lock();

IMO, it is right too.


> but I'd add a mention of this in the changelog.

In git log?


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

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

[osstest service owner]

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

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-debianhvm-i386 9 debian-hvm-install fail pass in 
85248

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  03720ea541382a3ca80eaaec2aa11932b03aacaf
baseline version:
 xen  7ba900efe5f526c941b1ca055e5347947bb7eb4b

Last test of basis85080  2016-03-02 16:00:54 Z1 days
Testing same since85178  2016-03-03 09:20:13 Z0 days8 attempts


People who touched revisions under test:
  Andrew Cooper 
  Aravind Gopalakrishnan 
  Boris Ostrovsky 
  Dario Faggioli 
  Hanjun Guo 
  Jan Beulich 
  Juergen Gross 
  Naresh Bhat 
  Parth Dixit 
  Shannon Zhao 
  Shannon Zhao 
  Stefano Stabellini 
  Tomasz Nowicki 

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



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

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

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

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


Not pushing.

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

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

Re: [Xen-devel] [RFC Design Doc] Add vNVDIMM support for Xen

[Haozhong Zhang]

On 03/02/16 06:03, Jan Beulich wrote:
> >>> On 02.03.16 at 08:14,  wrote:
> > It means NVDIMM is very possibly mapped in page granularity, and
> > hypervisor needs per-page data structures like page_info (rather than the
> > range set style nvdimm_pages) to manage those mappings.
> > 
> > Then we will face the problem that the potentially huge number of
> > per-page data structures may not fit in the normal ram. Linux kernel
> > developers came across the same problem, and their solution is to
> > reserve an area of NVDIMM and put the page structures in the reserved
> > area (https://lwn.net/Articles/672457/). I think we may take the similar
> > solution:
> > (1) Dom0 Linux kernel reserves an area on each NVDIMM for Xen usage
> > (besides the one used by Linux kernel itself) and reports the address
> > and size to Xen hypervisor.
> > 
> > Reasons to choose Linux kernel to make the reservation include:
> > (a) only Dom0 Linux kernel has the NVDIMM driver,
> > (b) make it flexible for Dom0 Linux kernel to handle all
> > reservations (for itself and Xen).
> > 
> > (2) Then Xen hypervisor builds the page structures for NVDIMM pages and
> > stores them in above reserved areas.
> 
> Another argument against this being primarily Dom0-managed,
> I would say.

Yes, Xen should, at least, manage all address mappings for NVDIMM. Dom0
Linux and QEMU then provide a user-friendly interface to configure
NVDIMM and vNVDIMM: like providing files (instead of address) as the
abstract of SPA ranges in/of NVDIMM.

> Furthermore - why would Dom0 waste space
> creating per-page control structures for regions which are
> meant to be handed to guests anyway?
> 

I found my description was not accurate after consulting with our driver
developers. By default the linux kernel does not create page structures
for NVDIMM which is called by kernel the "raw mode". We could enforce
the Dom0 kernel to pin NVDIMM in "raw mode" so as to avoid waste.

Haozhong

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

Re: [Xen-devel] Patching error while setting up COLO

[Wen Congyang]

On 03/04/2016 10:01 AM, Yu-An(Victor) Chen wrote:
> Hi,
> 
> So I git clone https://github.com/wencongyang/qemu-xen.git
> 
> but i only see branch "con-xen-v2" instead of " colo-xen-v2" so I assume I 
> use just use con-xen-v2.
> 
> But then the following step:
> 
> in both ~/qemu-colo and ~/qemu-xen
> 
> ./configure --enable-xen --target-list=x86_64-softmmu 
> --extra-cflags="-I$path_to_xen_source/tools/include 
> -I$path_to_xen_source/tools/libxc -I$path_to_xen_source/tools/xenstore" 
> --extra-ldflags="-L$path_to_xen_source/tools/libxc 
> -L$path_to_xen_source/tools/xenstore"


This command line is out of dated. The following is my building scripts:
#! /bin/bash

path_to_xen_source=/work/src/xen
#./configure --enable-xen --target-list=i386-softmmu \
#--extra-cflags="-I$path_to_xen_source/tools/include 
-I$path_to_xen_source/tools/libxc/include 
-I$path_to_xen_source/tools/xenstore/include" \
#--extra-ldflags="-L$path_to_xen_source/tools/libxc 
-L$path_to_xen_source/tools/xenstore"

extra_cflags=""
extra_cflags+=" -DXC_WANT_COMPAT_EVTCHN_API=1"
extra_cflags+=" -DXC_WANT_COMPAT_GNTTAB_API=1"
extra_cflags+=" -DXC_WANT_COMPAT_MAP_FOREIGN_API=1"
extra_cflags+=" -I$path_to_xen_source/tools/include"
extra_cflags+=" -I$path_to_xen_source/tools/libs/toollog/include"
extra_cflags+=" -I$path_to_xen_source/tools/libs/evtchn/include"
extra_cflags+=" -I$path_to_xen_source/tools/libs/gnttab/include"
extra_cflags+=" -I$path_to_xen_source/tools/libs/foreignmemory/include"
extra_cflags+=" -I$path_to_xen_source/tools/libxc/include"
extra_cflags+=" -I$path_to_xen_source/tools/xenstore/include"
extra_cflags+=" -I$path_to_xen_source/tools/xenstore/compat/include"
extra_cflags+=" "

extra_ldflags=""
extra_ldflags+=" -L$path_to_xen_source/tools/libxc"
extra_ldflags+=" -L$path_to_xen_source/tools/xenstore"
extra_ldflags+=" -L$path_to_xen_source/tools/libs/evtchn"
extra_ldflags+=" -L$path_to_xen_source/tools/libs/gnttab"
extra_ldflags+=" -L$path_to_xen_source/tools/libs/foreignmemory"
extra_ldflags+=" -Wl,-rpath-link=$path_to_xen_source/tools/libs/toollog"
extra_ldflags+=" -Wl,-rpath-link=$path_to_xen_source/tools/libs/evtchn"
extra_ldflags+=" -Wl,-rpath-link=$path_to_xen_source/tools/libs/gnttab"
extra_ldflags+=" -Wl,-rpath-link=$path_to_xen_source/tools/libs/call"
extra_ldflags+=" -Wl,-rpath-link=$path_to_xen_source/tools/libs/foreignmemory"
extra_ldflags+=" "

./configure --enable-xen --target-list=i386-softmmu \
--extra-cflags="$extra_cflags" \
--extra-ldflags="$extra_ldflags"

if [[ $? -ne 0 ]]; then
exit 1
fi

#make -j8 && make clean
make -j8

You can find the newest building way in tools/Makefile(xen's codes):
subdir-all-qemu-xen-dir: qemu-xen-dir-find  
if test -d $(QEMU_UPSTREAM_LOC) ; then \
source=$(QEMU_UPSTREAM_LOC); \  
else \  
source=.; \ 
fi; \   
cd qemu-xen-dir; \  
if $$source/scripts/tracetool.py --check-backend --backend stderr ; 
then \
enable_trace_backend='--enable-trace-backend=stderr'; \ 
else \  
enable_trace_backend='' ; \ 
fi ; \  
$$source/configure --enable-xen --target-list=i386-softmmu \
$(QEMU_XEN_ENABLE_DEBUG) \  
$$enable_trace_backend \
--prefix=$(LIBEXEC) \   
--libdir=$(LIBEXEC_LIB) \   
--includedir=$(LIBEXEC_INC) \


Thanks
Wen Congyang

> 
> 
> I got the following error message:
> 
> "ERROR: User requested feature xen
>configure was not able to find it.
>Install xen devel"
> 
> I found out the the error came from just simply doing this:
> 
> ./configure --enable-xen  
> 
> I am thinking the reason is because I did this step wrong:
> 
> "path_to_xen_source=~/xen"
> 
> Do I just simply copy and paste the above command into the terminal and 
> execute?
> 
> Thank you!
> 
> Victor
> 
> 
> 
> 
> 
> 
> 
> 
> Thank you!
> 
> On Thu, Mar 3, 2016 at 2:46 AM, Wen Congyang  > wrote:
> 
> On 03/03/2016 05:39 PM, Yu-An(Victor) Chen wrote:
> > Hi Changlong,
> >
> > Thanks for the reply,
> >
> > Again when I am trying to do the following:
> >
> > 5. build qemu-colo
>  

Re: [Xen-devel] Patching error while setting up COLO

[Yu-An(Victor) Chen]

Hi,

So I git clone https://github.com/wencongyang/qemu-xen.git

but i only see branch "con-xen-v2" instead of " colo-xen-v2" so I assume I
use just use con-xen-v2.

But then the following step:

in both ~/qemu-colo and ~/qemu-xen

./configure --enable-xen --target-list=x86_64-softmmu
--extra-cflags="-I$path_to_xen_source/tools/include
-I$path_to_xen_source/tools/libxc -I$path_to_xen_source/tools/xenstore"
--extra-ldflags="-L$path_to_xen_source/tools/libxc
-L$path_to_xen_source/tools/xenstore"


I got the following error message:

"ERROR: User requested feature xen
   configure was not able to find it.
   Install xen devel"

I found out the the error came from just simply doing this:

./configure --enable-xen

I am thinking the reason is because I did this step wrong:

"path_to_xen_source=~/xen"

Do I just simply copy and paste the above command into the terminal and
execute?

Thank you!

Victor








Thank you!

On Thu, Mar 3, 2016 at 2:46 AM, Wen Congyang  wrote:

> On 03/03/2016 05:39 PM, Yu-An(Victor) Chen wrote:
> > Hi Changlong,
> >
> > Thanks for the reply,
> >
> > Again when I am trying to do the following:
> >
> > 5. build qemu-colo
> > 1) cd ~/qemu-colo/; *git checkout colo-xen-v2*
> > *
> > *
> > I got this error message *"error: pathspec 'colo-xen-v2' did not match
> any file(s) known to git."* Even if I do git fetch, I still get the same
> error.
> >
> > the qemu-colo I cloned from is provided by you
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_wencongyang_qemu-2Dcolo.git=CwICaQ=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI=IitX1U91-NhsQt0q4MJOLQ=Mgaousw-OxgAf6f9NTOk2AidO8unmTx8nKwiGLUCISU=Tz2SiQ2gjQexttffgWiqgwj07qsfY4TpG4Hfcpo9Lco=
>
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_wencongyang_qemu-2Dxen=CwICaQ=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI=IitX1U91-NhsQt0q4MJOLQ=Mgaousw-OxgAf6f9NTOk2AidO8unmTx8nKwiGLUCISU=z-KexB48-yzsD9EEJ5tC3p8tHRiRi7LoUiP-gF6kKX0=
> , not qemu-colo
>
> >
> > Thank you!
> >
> > Victor
> >
> >
> >
> > On Thu, Feb 25, 2016 at 9:07 PM, Changlong Xie <
> xiecl.f...@cn.fujitsu.com > wrote:
> >
> > On 02/26/2016 12:55 PM, Yu-An(Victor) Chen wrote:
> >
> > Hi Changlong,
> >
> > Are you suggesting I should hold off on setting up COLO for now?
> >
> >
> > No, just following my steps.
> >
> > Thanks
> > -Xie
> >
> >
> > Thanks!
> >
> > Victor
> >
> > On Thu, Feb 25, 2016 at 8:19 PM, Changlong Xie <
> xiecl.f...@cn.fujitsu.com >
> > wrote:
> >
> > On 02/26/2016 11:38 AM, Yu-An(Victor) Chen wrote:
> >
> > Hi Changlong,
> >
> > Thanks for the reply!
> >
> > So I am trying to follow your new instructions, but when
> I am trying to do
> > this:
> >
> >cd ~/colo-proxy/; git checkout 405527cbfa9f
> >
> > I got the following error:
> >
> > "error: pathspec '405527cbfa9f' did not match any
> file(s) known to git."
> >
> > I assume it is just a typo? Thank you!
> >
> >
> > Hi victor
> >
> > Please git clone
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Pating_colo-2Dproxy_tree_changlox=CwICaQ=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI=IitX1U91-NhsQt0q4MJOLQ=pCAkg_8tEQmGEZZoUlyePZjK7z-6aEmp-n6UrQRLWo4=Ww-EAIszC-zQuVcDc4XpigwVbMG_4t2SpTg2PV6HTjM=
> > *Notice* that, currently we implement colo proxy as a kernel
> module what
> > is a temporary measure. But further more we'll intergrate it
> in qemu and
> > drop this one, so both qemu-colo and xen-colo will share the
> same proxy.
> > Please don't test this colo proxy now, there maybe some
> bugs, but it's
> > acceptable.
> >
> > Thanks
> >  -Xie
> >
> >
> > Victor
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] arm/timer: fix panic when booting with DT

[Shannon Zhao]

On 2016/3/3 23:44, Stefano Stabellini wrote:
> On Thu, 3 Mar 2016, Shannon Zhao wrote:
>> > From: Shannon Zhao 
>> > 
>> > While to support ACPI, patch "arm/acpi: Parse GTDT to initialize timer"
>> > refactors the functions preinit_xen_time and init_xen_time. But it
>> > wrongly moves the platform_get_irq from init_xen_time to
>> > preinit_dt_xen_time and this will cause booting failure.
>> > 
>> > So move platform_get_irq back to init_xen_time to fix it.
>> > 
>> > Signed-off-by: Shannon Zhao 
> Shannon,
> thank you for fixing the issue so quickly, very appreciated!
> 
> 
>> >  xen/arch/arm/time.c | 27 ---
>> >  1 file changed, 16 insertions(+), 11 deletions(-)
>> > 
>> > diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
>> > index 5f8f974..66a4520 100644
>> > --- a/xen/arch/arm/time.c
>> > +++ b/xen/arch/arm/time.c
>> > @@ -119,7 +119,6 @@ static void __init preinit_dt_xen_time(void)
>> >  };
>> >  int res;
>> >  u32 rate;
>> > -unsigned int i;
>> >  
>> >  timer = dt_find_matching_node(NULL, timer_ids);
>> >  if ( !timer )
>> > @@ -133,16 +132,6 @@ static void __init preinit_dt_xen_time(void)
>> >  cpu_khz = rate / 1000;
>> >  timer_dt_clock_frequency = rate;
>> >  }
>> > -
>> > -/* Retrieve all IRQs for the timer */
>> > -for ( i = TIMER_PHYS_SECURE_PPI; i < MAX_TIMER_PPI; i++ )
>> > -{
>> > -res = platform_get_irq(timer, i);
>> > -
>> > -if ( res < 0 )
>> > -panic("Timer: Unable to retrieve IRQ %u from the device 
>> > tree", i);
>> > -timer_irq[i] = res;
>> > -}
>> >  }
>> >  
>> >  void __init preinit_xen_time(void)
>> > @@ -168,6 +157,22 @@ void __init preinit_xen_time(void)
>> >  /* Set up the timer on the boot CPU (late init function) */
>> >  int __init init_xen_time(void)
>> >  {
>> > +int res;
>> > +unsigned int i;
>> > +
>> > +if ( acpi_disabled )
>> > +{
>> > +/* Retrieve all IRQs for the timer */
>> > +for ( i = TIMER_PHYS_SECURE_PPI; i < MAX_TIMER_PPI; i++ )
>> > +{
>> > +res = platform_get_irq(timer, i);
>> > +
>> > +if ( res < 0 )
>> > +panic("Timer: Unable to retrieve IRQ %u from the device 
>> > tree", i);
>> > +timer_irq[i] = res;
>> > +}
>> > +}
> Could you please introduce a small little init_dt_xen_time function and
> call that instead from here?  Thanks!
> 
Not sure if it's necessary since it's only used here. But if you really
want that I'll add.

Thanks,
-- 
Shannon


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

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

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  03720ea541382a3ca80eaaec2aa11932b03aacaf
baseline version:
 xen  7ba900efe5f526c941b1ca055e5347947bb7eb4b

Last test of basis85080  2016-03-02 16:00:54 Z1 days
Testing same since85178  2016-03-03 09:20:13 Z0 days7 attempts


People who touched revisions under test:
  Andrew Cooper 
  Aravind Gopalakrishnan 
  Boris Ostrovsky 
  Dario Faggioli 
  Hanjun Guo 
  Jan Beulich 
  Juergen Gross 
  Naresh Bhat 
  Parth Dixit 
  Shannon Zhao 
  Shannon Zhao 
  Stefano Stabellini 
  Tomasz Nowicki 

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



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

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

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

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


Not pushing.

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

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

[Xen-devel] [xen-4.4-testing baseline-only test] 44214: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl 19 guest-start/debian.repeat fail blocked in 44165
 test-amd64-i386-qemut-rhel6hvm-amd 11 guest-start/redhat.repeat fail blocked 
in 44165
 test-amd64-i386-xl-qemuu-win7-amd64 13 guest-localmigrate fail blocked in 44165
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stopfail blocked in 44165
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-localmigrate fail blocked in 44165

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 build-i386-rumpuserxen6 xen-buildfail   never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt 11 guest-start  fail   never pass
 build-amd64-rumpuserxen   6 xen-buildfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-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-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   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-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 20 leak-check/checkfail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass

version targeted for testing:
 xen  83c5e46c5d6af7adc4bc46cf41e415e34846c719
baseline version:
 xen  02426e9202336bb666464d84f0537874689b30fc

Last test of basis44165  2016-02-26 11:49:23 Z6 days
Testing same since44214  2016-03-03 09:33:25 Z0 days1 attempts


People who touched revisions under test:
  Ian Campbell 
  Ian Jackson 
  Wei Liu 

jobs:
 build-amd64-xend pass
 build-i386-xend  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
 build-amd64-rumpuserxen  fail
 build-i386-rumpuserxen   fail
 test-amd64-amd64-xl  fail
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-i386-qemut-rhel6hvm-amd   fail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-rumpuserxen-amd64   blocked 

Re: [Xen-devel] [PATCH v6 4/5] VT-d: Reduce spin timeout to 1ms, which can be boot-time changed

[Dario Faggioli]

[Trimmed the Cc-list a bit again]

On Wed, 2016-03-02 at 22:31 +0800, Quan Xu wrote:
> Signed-off-by: Quan Xu 
>  
> diff --git a/xen/drivers/passthrough/vtd/qinval.c
> b/xen/drivers/passthrough/vtd/qinval.c
> index b81b0bd..882b9f4 100644
> --- a/xen/drivers/passthrough/vtd/qinval.c
> +++ b/xen/drivers/passthrough/vtd/qinval.c
> @@ -28,6 +28,11 @@
>  #include "vtd.h"
>  #include "extern.h"
>  
> +static unsigned int __read_mostly vtd_qi_timeout = 1;
> +integer_param("vtd_qi_timeout", vtd_qi_timeout);
> +
> +#define IOMMU_QI_TIMEOUT (vtd_qi_timeout * MILLISECS(1))
> +
>  static void print_qi_regs(struct iommu *iommu)
>  {
>  u64 val;
> @@ -130,6 +135,10 @@ static void queue_invalidate_iotlb(struct iommu
> *iommu,
>  spin_unlock_irqrestore(>register_lock, flags);
>  }
>  
> +/*
> + * NB. We must check all kinds of error and all the way up the
> + * call trees.
> + */
>  static int queue_invalidate_wait(struct iommu *iommu,
>  u8 iflag, u8 sw, u8 fn)
>  {
> @@ -167,10 +176,12 @@ static int queue_invalidate_wait(struct iommu
> *iommu,
>  start_time = NOW();
>  while ( poll_slot != QINVAL_STAT_DONE )
>  {
> -if ( NOW() > (start_time + DMAR_OPERATION_TIMEOUT) )
> +if ( NOW() > (start_time + IOMMU_QI_TIMEOUT) )
>
Since this now involves a time unit conversion, can't we:
 - instead of start_time, above, compute, once and for all:
     timeout = NOW() + IOMMU_QI_TIMEOUT;
 - check whether ( NOW() > timeout )

I appreciate that the default for vtd_qi_timeout is 1, so it's most
likely not that a big deal, but it still looks better to me.

>  {
>  print_qi_regs(iommu);
> -panic("queue invalidate wait descriptor was not
> executed");
> +printk(XENLOG_WARNING VTDPREFIX
> +   "Queue invalidate wait descriptor was
> timeout.\n");
>
"Queue invalidate wait descriptor timed out"  ?

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
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v6 3/5] IOMMU: Make the pcidevs_lock a recursive one

[Dario Faggioli]

[I've removed some of the people that shouldn't be involved in this
discussion any longer from the Cc-list]

On Wed, 2016-03-02 at 22:31 +0800, Quan Xu wrote:
> Signed-off-by: Quan Xu 
> 
So, this patch looks ok to me.

I spotted something, though, that I think needs some attention.

Since I'm jumping on this series only now, if this has been discussed
before and I missed it, sorry for the noise.

> @@ -788,10 +787,10 @@ static bool_t __init
> set_iommu_interrupt_handler(struct amd_iommu *iommu)
>  return 0;
>  }
>  
> -spin_lock_irqsave(_lock, flags);
> +pcidevs_lock();
>
So, spin_lock_irqsave() does:
  local_irq_save()
    local_save_flags()
    local_irq_disable()
  _spin_lock()

i.e., it saves the flags and disable interrupts.

pcidevs_lock() does:
  spin_lock_recursive()
    ... //handle recursion
    _spin_lock()

i.e., it does not disable interrupts.

And therefore it is possible that we are actually skipping disabling
interrupts (if they're not disabled already), isn't it?

And, of course, the same reasoning --mutatis mutandis-- applies to the
unlock side of things.

>  iommu->msi.dev = pci_get_pdev(iommu->seg, PCI_BUS(iommu->bdf),
>    PCI_DEVFN2(iommu->bdf));
> -spin_unlock_irqrestore(_lock, flags);
> +pcidevs_unlock();
>
i.e., spin_unlock_irqrestore() restore the flags, including the
interrupt enabled/disabled status, which means it can re-enable the
interrupts or not, depending on whether they were enabled at the time
of the previous spin_lock_irqsave(); pcidevs_unlock() just don't affect
interrupt enabling/disabling at all.

So, if the original code is correct in using
spin_lock_irqsave()/spin_unlock_irqrestore(), I think that we need
_irqsave() and _irqrestore() variants of recursive spinlocks, in order
to deal with this case.

However, from a quick inspection, it looks to me that:
 - this can only be called (during initialization), with interrupt
   enabled, so least saving & restoring flags shouldn't be necessary
   (unless I missed where they can be disabled in the call chain
   from iommu_setup() toward set_iommu_interrupt_handler()).
 - This protects pci_get_dev(); looking at other places where 
   pci_get_dev() is called, I don't think it is really necessary to
   disable interrupts.

If I'm right, it means that the original code could well have been
using just plain spin_lock() and spin_unlock(), and it would then be
fine to turn them into pcidevs_lock() and pcidevs_unlock(), and so no
need to add more spin_[un]lock_recursive() variants.

That would also mean that the patch is indeed ok, but I'd add a mention
of this in the changelog.

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
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 0/2] x86/entry/32: Get rid of paravirt_enabled in ESPFIX

[Andy Lutomirski]

On Thu, Mar 3, 2016 at 2:18 AM, Borislav Petkov  wrote:
> On Wed, Mar 02, 2016 at 04:47:38PM -0800, Andy Lutomirski wrote:
>> Because I'm mixing paravirt and cpufeatures a bit oddly.
>
> That's fine. All X86_BUG_* are synthetic and exactly for stuff like
> that.
>
> --
> Regards/Gruss,
> Boris.
>
> ECO tip #101: Trim your mails when you reply.

So should these patches just go in as is?

--Andy

-- 
Andy Lutomirski
AMA Capital Management, LLC

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail REGR. vs. 65543

version targeted for testing:
 ovmf db54ae0845e321e4cce35f0ccbb16b7fcb2b57db
baseline version:
 ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1

Last test of basis65543  2015-12-08 08:45:15 Z   86 days
Failing since 65593  2015-12-08 23:44:51 Z   85 days   90 attempts
Testing same since85082  2016-03-02 16:16:29 Z1 days1 attempts


People who touched revisions under test:
  "Samer El-Haj-Mahmoud" 
  "Yao, Jiewen" 
  Alcantara, Paulo 
  Anbazhagan Baraneedharan 
  Andrew Fish 
  Ard Biesheuvel 
  Arthur Crippa Burigo 
  Cecil Sheng 
  Chao Zhang 
  Charles Duffy 
  Cinnamon Shia 
  Cohen, Eugene 
  Dandan Bi 
  Daocheng Bu 
  Daryl McDaniel 
  edk2 dev 
  edk2-devel 
  Eric Dong 
  Eric Dong 
  Eugene Cohen 
  Evan Lloyd 
  Feng Tian 
  Fu Siyuan 
  Hao Wu 
  Haojian Zhuang 
  Hess Chen 
  Heyi Guo 
  Jaben Carsey 
  Jeff Fan 
  Jiaxin Wu 
  jiewen yao 
  Jim Dailey 
  jim_dai...@dell.com 
  Jordan Justen 
  Karyne Mayer 
  Larry Hauch 
  Laszlo Ersek 
  Leahy, Leroy P 
  Lee Leahy 
  Leekha Shaveta 
  Leif Lindholm 
  Liming Gao 
  Mark Rutland 
  Marvin Haeuser 
  Michael Kinney 
  Michael LeMay 
  Michael Thomas 
  Ni, Ruiyu 
  Paolo Bonzini 
  Paulo Alcantara 
  Paulo Alcantara Cavalcanti 
  Qin Long 
  Qiu Shumin 
  Rodrigo Dias Correa 
  Ruiyu Ni 
  Ryan Harkin 
  Samer El-Haj-Mahmoud 
  Samer El-Haj-Mahmoud 
  Star Zeng 
  Supreeth Venkatesh 
  Tapan Shah 
  Tian, Feng 
  Vladislav Vovchenko 
  Yao Jiewen 
  Yao, Jiewen 
  Ye Ting 
  Yonghong Zhu 
  Zhang Lubo 
  Zhang, Chao B 
  Zhangfei Gao 

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 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail



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 10839 lines long.)

___
Xen-devel mailing list

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

[osstest service owner]

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

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 84935
 test-armhf-armhf-xl-rtds 11 guest-start  fail   like 84935

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  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-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-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-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-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-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 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-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-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-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-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 qemuued6128ebbdd7cd885d39980659dad4b5c8ae8158
baseline version:
 qemuu9c279bec754a84c790b70674a5a224379c8dcda2

Last test of basis84935  2016-03-01 14:15:01 Z2 days
Testing same since85076  2016-03-02 15:32:30 Z1 days1 attempts


People who touched revisions under test:
  Alex Bennée 
  Christian Borntraeger 
  Denis V. Lunev 
  Greg Kurz 
  Hollis Blanchard 
  Lluís Vilanova 
  Peter Maydell 
  Richard Henderson 
  Stefan Hajnoczi 

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

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

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  03720ea541382a3ca80eaaec2aa11932b03aacaf
baseline version:
 xen  7ba900efe5f526c941b1ca055e5347947bb7eb4b

Last test of basis85080  2016-03-02 16:00:54 Z1 days
Testing same since85178  2016-03-03 09:20:13 Z0 days6 attempts


People who touched revisions under test:
  Andrew Cooper 
  Aravind Gopalakrishnan 
  Boris Ostrovsky 
  Dario Faggioli 
  Hanjun Guo 
  Jan Beulich 
  Juergen Gross 
  Naresh Bhat 
  Parth Dixit 
  Shannon Zhao 
  Shannon Zhao 
  Stefano Stabellini 
  Tomasz Nowicki 

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



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

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

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

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


Not pushing.

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

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

Re: [Xen-devel] [PATCH 0/1] ARM: Implement support for write-ctrlreg vm-events

[Razvan Cojocaru]

>>> With that said, another thing crossed my mind. Since the DENY flag will
>>> be implemented for ARM w/ the next
>>> revision and the actual write will be done on the scheduler tail,
>>> similarly to X86 ((hvm_do_resume), wouldn't
>>> it be good if we separated the code that checks monitor_write_data from
>>> there into an arch-dependent function,
>>> e.g. vm_event_monitor_write_data? That way the scheduler tail function
>>> won't be 'polluted' w/ that code and IMHO
>>> it will make the vm-events design more clear (since that functionality
>>> will also be in vm_event.c along w/ the other
>>> vm_event_* functions).
>> Sounds good, except perhaps for the function name but I'm not sure what
>> a better one might be unfortunately, maybe someone else with chime in
>> with a suggestion.
> 
> I was thinking of the option of giving this function the significance of
> it being called by the
> scheduler tail, i.e. just before "entering" a vcpu, in which case we
> could use a name
> like vm_event_schedtail.
> To me this sounds pretty good since it generalizes the function and it
> makes sense to have
> a vm_event_* function that is called just before a vcpu is scheduled,
> i.e. a vm-events function
> that would add-in a "final touch" before the "final stage" of actually
> entering the vcpu.
> 
> Let me know what you think.

Sounds good to me. Let's see if somebody else objects.


Thanks,
Razvan

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

[Xen-devel] [xen-unstable test] 85064: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 11 guest-start  fail   like 84610
 build-i386-rumpuserxen6 xen-buildfail   like 84928
 build-amd64-rumpuserxen   6 xen-buildfail   like 84928
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 84928
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 84928
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 84928

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   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
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-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-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-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-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-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-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-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-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-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-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  3f19ca9ad0b66c57c91921dc8a695634eee0c679
baseline version:
 xen  986d9fc3bbf8a6d9d088ca22d1422bd5de249396

Last test of basis84928  2016-03-01 13:45:59 Z2 days
Testing same since85064  2016-03-02 13:39:46 Z1 days1 attempts


People who touched revisions under test:
  Boris Ostrovsky  for SVM bits
  Doug Goldstein 
  Feng Wu 
  Haozhong Zhang 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Kevin Tian 
  Liang Li 
  Wei Liu 

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-oldkern  pass
 

Re: [Xen-devel] [PATCH 0/1] ARM: Implement support for write-ctrlreg vm-events

[Corneliu ZUZU]

On 3/3/2016 8:51 PM, Razvan Cojocaru wrote:

On 03/03/2016 08:04 PM, Corneliu ZUZU wrote:

On 3/3/2016 6:15 PM, Razvan Cojocaru wrote:

On 03/03/2016 04:10 PM, Corneliu ZUZU wrote:

Q2) About VM_EVENT_FLAG_DENY

Q2.1)
  Doesn't it require sync = 1 (i.e. the vcpu to be paused) to work?
  If so, shouldn't we call vm_event_register_write_resume only
after checking
  that VM_EVENT_FLAG_VCPU_PAUSED flag is set (vm_event_resume).
Moreover, if
  we do that, wouldn't it be 'cleaner' to rename
  vm_event_register_write_resume->vm_event_deny, check for the
  VM_EVENT_FLAG_DENY flag in vm_event_resume instead and call
vm_event_deny
  from there after this check?

Yes, it does require the VCPU to be paused to work, and yes, it's a good
idea to check that that flag is set in the response.

Beyond that, I'd prefer we keep vm_event_register_write_resume()
because, while today all we do there is check that VM_EVENT_FLAG_DENY is
set, we might want do to other things as well there as well (for
example, maybe validate the content of some register). That was really
the point of the "bigger-named" function.

But that's just my opinion, if Tamas prefers your rename suggestion I'll
consider myself outnumbered.

Oh, ok, then the check for VM_EVENT_FLAG_VCPU_PAUSED would be done in
vm_event_register_write_resume instead of vm_event_resume,
since I suppose vm_event_register_write_resume shouldn't be called only
when the vcpu is paused, we only apply that to the DENY flag, correct?

Yes, I think that's the path of least resistance.


Q2.2)
  VM_EVENT_FLAG_DENY functionality is not implemented w/ this
change-set.
  What is done instead is that the control-register write is done
*before*
  sending the vm-event (vm_event_put_request). This way, the user can
  override the written register value after receiving the
vm-event, which
  in effect provides the same flexibility as VM_EVENT_FLAG_DENY does.
  Using this strategy instead would simplify both Xen's code and
the libxc
  user's code.
  Thoughts?

That's how I initially did it with CR events, but with an application
dealing with huge numbers of events, an extra hypercall (to re-set the
register) can be quite expensive, so I had to rework it to the present
state. On these grounds I'm opposed to it - and for consistency I would
prefer that all register write events are pre-write events, and deniable
with a single vm_event reply.


Ah, I understand. I figured the utility of the DENY flag was only for
cases where you'd want to actively
override the value written to the register (set register to overridden
value + resume w/ DENY), instead
of just forbidding the write and leaving the register untouched (i.e.
set on the old value).
If the latter is a  desirable functionality then it indeed makes sense
to have a DENY flag.

Yes, that's the goal.


With that said, another thing crossed my mind. Since the DENY flag will
be implemented for ARM w/ the next
revision and the actual write will be done on the scheduler tail,
similarly to X86 ((hvm_do_resume), wouldn't
it be good if we separated the code that checks monitor_write_data from
there into an arch-dependent function,
e.g. vm_event_monitor_write_data? That way the scheduler tail function
won't be 'polluted' w/ that code and IMHO
it will make the vm-events design more clear (since that functionality
will also be in vm_event.c along w/ the other
vm_event_* functions).

Sounds good, except perhaps for the function name but I'm not sure what
a better one might be unfortunately, maybe someone else with chime in
with a suggestion.


Thanks,
Razvan




I was thinking of the option of giving this function the significance of 
it being called by the
scheduler tail, i.e. just before "entering" a vcpu, in which case we 
could use a name

like vm_event_schedtail.
To me this sounds pretty good since it generalizes the function and it 
makes sense to have
a vm_event_* function that is called just before a vcpu is scheduled, 
i.e. a vm-events function
that would add-in a "final touch" before the "final stage" of actually 
entering the vcpu.


Let me know what you think.

Thanks,
Corneliu.

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

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

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  03720ea541382a3ca80eaaec2aa11932b03aacaf
baseline version:
 xen  7ba900efe5f526c941b1ca055e5347947bb7eb4b

Last test of basis85080  2016-03-02 16:00:54 Z1 days
Testing same since85178  2016-03-03 09:20:13 Z0 days5 attempts


People who touched revisions under test:
  Andrew Cooper 
  Aravind Gopalakrishnan 
  Boris Ostrovsky 
  Dario Faggioli 
  Hanjun Guo 
  Jan Beulich 
  Juergen Gross 
  Naresh Bhat 
  Parth Dixit 
  Shannon Zhao 
  Shannon Zhao 
  Stefano Stabellini 
  Tomasz Nowicki 

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



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

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

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

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


Not pushing.

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

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

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

[Platform Team regression test user]

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

Perfect :-)
All tests in this flight passed
baseline version:
 flight   38737

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
http://lists.xen.org/xen-devel

Re: [Xen-devel] [BUG] xs.watch and xs.unwatch are unreliable

[Wei Liu]

On Thu, Mar 03, 2016 at 05:18:31PM +, David Vrabel wrote:
> On 03/03/16 17:02, Wei Liu wrote:
> > On Thu, Mar 03, 2016 at 04:47:12PM +, David Vrabel wrote:
> >> On 01/03/16 20:17, Sergei Lebedev wrote:
> >>> Hi list,
> >>>
> >>> I’ve initially wanted to report another inconsistency in
> >>> ``xen.lowlevel.xs`` documentation, but this time the issue is more
> >>> subtle.
> >>
> >> [...]
> >>
> >>> Here’s another example with a string token
> >>>
> >>> >>> token1 = str(10)
> >>> >>> token2 = str(10)
> >>> >>> token1 == token2
> >>> True
> >>> >>> h.watch("@introduceDomain", token1)
> >>> >>> h.unwatch("@introduceDomain", token2)
> >>> Traceback (most recent call last):
> >>>   File "", line 1, in 
> >>> xen.lowlevel.xs.Error: (2, 'No such file or directory’)
> >>>
> >>> I’m not sure what would be the best way to handle this as there might
> >>> be existing code relying on this undocumented behaviour. What do you
> >>> think?
> >>
> >> I think you're stuck with this behaviour.  If you fix it there's a risk
> >> of breaking existing applications by unwatch removing the wrong watch.
> >>
> > 
> > I'm not sure I follow this. Do you have an example why it would remove
> > the wrong watch?
> 
>   token1 = str(10)
>   token2 = str(10)
> 
>   h.watch("path", token1)
>   h.watch("path", token2)
> 
> Created two unique tokens.
> 
>   h.unwatch("path", token1)
> 
> Which watch should be removed if token1 and token2 no longer have a
> unique token?  Although, I'm not sure of the behaviour of adding two
> watches with the same token.
> 

Right. I also have no idea what the behaviour should be...

But given the incarnation of the binding, user would expect it to behave
the same as the underlying C API. Python binding is not responsible for
covering up the undefined behaviour.

And a side note is that the bindings of xs_watch and xs_unwatch can only
be used safely in very restricted way. That is, user needs to stash the
exact token object somewhere, which is not impossible, but also very
inconvenient.

Let's either document this behaviour or change it. I don't have
preference here.

> It also occurs to me that if this area is going to be improved, it
> should be the kernel that provides the token since it has to be unique
> across all users.
> 

This would be good.

Wei.

> David

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

Re: [Xen-devel] Prototype Code Review Dashboards (input required)

[Lars Kurth]

Daniel, (added Jan - search for @Jan)

thanks for the feedback

> On 2 Mar 2016, at 22:45, Daniel Izquierdo  wrote:
> 
> On 01/03/16 18:04, Lars Kurth wrote:
>> Daniel, Jesus,
>> 
>> I am going to break my comments down into different sections to make this 
>> more consumable. Let's focus on the A1-A3 use-cases in this mail.
>> 
>> First I wanted to start of with some questions about definitions, as I am 
>> seeing some discrepancies in some of the data shown and am trying to 
>> understand exactly what the data means, and then have a look at the 
>> individual sections.
>> 
>> General, to the Xen-A1.A2.A3 dash board
>> - I played with some filters and noticed some oddities, e.g. if I filter on 
>> "merged: 0" all views change as expected
>> - If I filter on "merged: 1", a lot of widgets show no data. Is this showing 
>> that there is an issue with the data somewhere?
>> - I see similar issues with other filters, e.g. 'emailtype: "patch"'
> 
> In order to bring some context to the dataset, ElasticSearch was initially 
> used for parsing Apache logs. That means that data should be formatted as 'a 
> row = an event'.
> 
> In this dataset there are several events that are defined by the field 
> 'EmailType'. 'patchserie', 'patch', 'comment', 'flag'. And then, depending on 
> that 'EmailType', each of the columns may have some meaning or some other.

That makes sense and is quite important background information and different 
from the original. I think for people to be able to build sophisticated search 
queries - once we have finalised all the fields - we should probably document 
this and the exact meaning of fields (also see below). I was thinking - and I 
volunteer - to put together an extra view that acts like a legend. With the 
editable version of the dashboard, that should be easy to do.

I think we either
- need to look at the panels and come up with some cleaner and clearer 
terminology 
- or, split the panels and make sure that only views which refer  
let me think about it and make a proposal.

> This structure uses the 'EmailType' as the central key where the rest of the 
> columns provide extra syntax. For instance, post_ack_comment field only makes 
> sense for the EmailType:comment.

Now I understand.

> Coming back to the comments:
> 
> There are fields that apply only to specific type of events. In the case of 
> 'merge' this applies only in the case of patches. merge:1 would filter 
> patches that are merged (so the rest of the information is literally removed 
> as they are not merged). If we filter by merge:0, these are the rest of the 
> information (even including flags).

OK. I think this is very confusing because when you look at the tables at the 3 
tables at the bottom, all of them show the same fields. And the default for an 
undefined field seems to be 0. Is there any way to make sure that undefined 
fields are set to na or -1 or similar. That would make things clearer. 

> Thus, using the filter merge:1 leads to having info only related to 'patches' 
> in this case.
> 
> As this panel shows information about other types than 'patch', if you filter 
> by some 'emailtype' such as 'patch' then you're focusing only on patches data 
> and this will display the merged and not merged ones.
> 
> In order to improve this, we can either create a panel for type of analysis 
> (one panel for patches, one for comments, etc). Or we can play with adding 
> the 'merge' field to any flag, patchserie, patch and comment whose patch was 
> merged at some point. The latter may sound a bit weird as a 'merged' status 
> does not apply to a flag (Reviewed-by) for instance.

Given that we have a lot of stuff on the panels, we should probably go for the 
1st option. But there may be corner cases, when we may want to go for the 
second. When I go to the editable dashboard version, how can I tell which 
EmailType is used. I couldn't figure that out.

> 
>>> On 1 Mar 2016, at 13:53, Lars Kurth  wrote:
>>> 
>>> Case of Study A.1: Identify top reviewers (for both individuals and 
>>> companies)
>>> --
>>> 
>>> Goal: Highlight review contributions - ability to use the data to "reward" 
>>> review contributions and encourage more "review" contributions
>> The widgets in question are:
>> - Evolution 'Reviewed by-flag' (no patchseries, no patches)
>> - What is the difference to Evolution of patches
>> - Top People/Domains Reviewing patches
>> 
>> Q1: Are this the reviewed-by flags?
> 
> They are only the Reviewed-by flags.
> 
>> Q2: What is the scope? Do the number count
>> - the # files someone reviewed
>> - the # patches someone reviewed
>> - the # series someone reviewed
> 
> The number counts the number of reviews accomplished by a developer or by a 
> domain. A review is accomplished when the flag 'reviewed-by' is detected in a 
> email replying a patch.
> 
> If a developer reviews 

Re: [Xen-devel] [PATCH 0/1] ARM: Implement support for write-ctrlreg vm-events

[Razvan Cojocaru]

On 03/03/2016 08:04 PM, Corneliu ZUZU wrote:
> On 3/3/2016 6:15 PM, Razvan Cojocaru wrote:
>> On 03/03/2016 04:10 PM, Corneliu ZUZU wrote:
>>> Q2) About VM_EVENT_FLAG_DENY
>>>
>>>Q2.1)
>>>  Doesn't it require sync = 1 (i.e. the vcpu to be paused) to work?
>>>  If so, shouldn't we call vm_event_register_write_resume only
>>> after checking
>>>  that VM_EVENT_FLAG_VCPU_PAUSED flag is set (vm_event_resume).
>>> Moreover, if
>>>  we do that, wouldn't it be 'cleaner' to rename
>>>  vm_event_register_write_resume->vm_event_deny, check for the
>>>  VM_EVENT_FLAG_DENY flag in vm_event_resume instead and call
>>> vm_event_deny
>>>  from there after this check?
>> Yes, it does require the VCPU to be paused to work, and yes, it's a good
>> idea to check that that flag is set in the response.
>>
>> Beyond that, I'd prefer we keep vm_event_register_write_resume()
>> because, while today all we do there is check that VM_EVENT_FLAG_DENY is
>> set, we might want do to other things as well there as well (for
>> example, maybe validate the content of some register). That was really
>> the point of the "bigger-named" function.
>>
>> But that's just my opinion, if Tamas prefers your rename suggestion I'll
>> consider myself outnumbered.
> 
> Oh, ok, then the check for VM_EVENT_FLAG_VCPU_PAUSED would be done in
> vm_event_register_write_resume instead of vm_event_resume,
> since I suppose vm_event_register_write_resume shouldn't be called only
> when the vcpu is paused, we only apply that to the DENY flag, correct?

Yes, I think that's the path of least resistance.

>>>Q2.2)
>>>  VM_EVENT_FLAG_DENY functionality is not implemented w/ this
>>> change-set.
>>>  What is done instead is that the control-register write is done
>>> *before*
>>>  sending the vm-event (vm_event_put_request). This way, the user can
>>>  override the written register value after receiving the
>>> vm-event, which
>>>  in effect provides the same flexibility as VM_EVENT_FLAG_DENY does.
>>>  Using this strategy instead would simplify both Xen's code and
>>> the libxc
>>>  user's code.
>>>  Thoughts?
>> That's how I initially did it with CR events, but with an application
>> dealing with huge numbers of events, an extra hypercall (to re-set the
>> register) can be quite expensive, so I had to rework it to the present
>> state. On these grounds I'm opposed to it - and for consistency I would
>> prefer that all register write events are pre-write events, and deniable
>> with a single vm_event reply.
>>
> 
> Ah, I understand. I figured the utility of the DENY flag was only for
> cases where you'd want to actively
> override the value written to the register (set register to overridden
> value + resume w/ DENY), instead
> of just forbidding the write and leaving the register untouched (i.e.
> set on the old value).
> If the latter is a  desirable functionality then it indeed makes sense
> to have a DENY flag.

Yes, that's the goal.

> With that said, another thing crossed my mind. Since the DENY flag will
> be implemented for ARM w/ the next
> revision and the actual write will be done on the scheduler tail,
> similarly to X86 ((hvm_do_resume), wouldn't
> it be good if we separated the code that checks monitor_write_data from
> there into an arch-dependent function,
> e.g. vm_event_monitor_write_data? That way the scheduler tail function
> won't be 'polluted' w/ that code and IMHO
> it will make the vm-events design more clear (since that functionality
> will also be in vm_event.c along w/ the other
> vm_event_* functions).

Sounds good, except perhaps for the function name but I'm not sure what
a better one might be unfortunately, maybe someone else with chime in
with a suggestion.


Thanks,
Razvan


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

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

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  03720ea541382a3ca80eaaec2aa11932b03aacaf
baseline version:
 xen  7ba900efe5f526c941b1ca055e5347947bb7eb4b

Last test of basis85080  2016-03-02 16:00:54 Z1 days
Testing same since85178  2016-03-03 09:20:13 Z0 days4 attempts


People who touched revisions under test:
  Andrew Cooper 
  Aravind Gopalakrishnan 
  Boris Ostrovsky 
  Dario Faggioli 
  Hanjun Guo 
  Jan Beulich 
  Juergen Gross 
  Naresh Bhat 
  Parth Dixit 
  Shannon Zhao 
  Shannon Zhao 
  Stefano Stabellini 
  Tomasz Nowicki 

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



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

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

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

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


Not pushing.

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

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

[Xen-devel] [PATCH] RFC: libxl: Change hotplug script interface to use physical-device-path

[Ian Jackson]

* Change block-common.sh on Linux to write physical-device-path with
  the path of the device node, rather than physical-device with its
  major:minor numbers.

* Have the libxl Linux hotplug script scheduler convert this, by
  reading physical-device-path and writing physical-device.  This
  happens just when we have decided that there is no more script to
  run.

* When libxl itself writes the device to xenstore, have it write
  physical-device-path.  On Linux this will be converted to
  physical-device by the new code discussed above.

* Add a note about libxl__device_physdisk_major_minor's poor error
  handling.

* Add an xxx about the fact that the sharing check in
  tools/hotplug/Linux/block needs adjusting.  Note that WITHOUT THIS
  OTHER FIX THE CHANGE TO BLOCK-COMMON.SH IS BROKEN.  This is one
  reason this patch is RFC.

* Untested.  That is the other reason this patch is RFC.
  (I have checked that it does compile.)

I wasn't able to find a document describing the hotplug script
interface (!) so this patch does not contain docs hunks.

CC: George Dunlap 
CC: Roger Pau Monne 
CC: Wei Liu 
Signed-off-by: Ian Jackson 
---
 tools/hotplug/Linux/block-common.sh |   19 +++---
 tools/libxl/libxl.c |5 +--
 tools/libxl/libxl_internal.h|1 +
 tools/libxl/libxl_linux.c   |   70 ++-
 4 files changed, 75 insertions(+), 20 deletions(-)

diff --git a/tools/hotplug/Linux/block-common.sh 
b/tools/hotplug/Linux/block-common.sh
index ee95009..560f189 100644
--- a/tools/hotplug/Linux/block-common.sh
+++ b/tools/hotplug/Linux/block-common.sh
@@ -50,23 +50,14 @@ device_major_minor()
 
 
 ##
-# Write physical-device = MM,mm to the store, where MM and mm are the major 
-# and minor numbers of device respectively.
+# Write physical-device-path = "$1"
 #
-# @param device The device from which major and minor numbers are read, which
-#   will be written into the store.
+# @param device The device which will be written into the store.
 #
 write_dev() {
-  local mm
-  
-  mm=$(device_major_minor "$1")
- 
-  if [ -z $mm ]
-  then
-fatal "Backend device does not exist"
-  fi
- 
-  xenstore_write "$XENBUS_PATH/physical-device" "$mm"
+  xxx check_sharing in block needs fixing too
+
+  xenstore_write "$XENBUS_PATH/physical-device-path" "$1"
 
   success
 }
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 4cdc169..0bcfada 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2450,10 +2450,7 @@ static void device_disk_add(libxl__egc *egc, uint32_t 
domid,
  */
 if (!disk->script &&
 disk->backend_domid == LIBXL_TOOLSTACK_DOMID) {
-int major, minor;
-if (!libxl__device_physdisk_major_minor(dev, , 
))
-flexarray_append_pair(back, "physical-device",
-  GCSPRINTF("%x:%x", major, 
minor));
+flexarray_append_pair(back, "physical-device-path", dev);
 }
 
 assert(device->backend_kind == LIBXL__DEVICE_KIND_VBD);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 005fe53..ada5f40 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1154,6 +1154,7 @@ _hidden char 
*libxl__device_disk_string_of_format(libxl_disk_format format);
 _hidden int libxl__device_disk_set_backend(libxl__gc*, libxl_device_disk*);
 
 _hidden int libxl__device_physdisk_major_minor(const char *physpath, int 
*major, int *minor);
+/* xxx libxl__device_physdisk_major_minor has irregular error handling */
 _hidden int libxl__device_disk_dev_number(const char *virtpath,
   int *pdisk, int *ppartition);
 
diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c
index be4afc6..aa7b42d 100644
--- a/tools/libxl/libxl_linux.c
+++ b/tools/libxl/libxl_linux.c
@@ -233,6 +233,65 @@ error:
 return rc;
 }
 
+static int disk_copy_block_device(libxl__gc *gc, libxl__device *dev,
+  libxl__device_action action)
+{
+int rc;
+xs_transaction_t t = 0;
+const char *be_path = libxl__device_frontend_path(gc, dev);
+const char *majmin_path = GCSPRINTF("%s/physical-device", be_path);
+const char *path_path = GCSPRINTF("%s/physical-device-path", be_path);
+int major, minor;
+
+if (action != LIBXL__DEVICE_ACTION_ADD)
+return 0;
+
+for (;;) {
+rc = libxl__xs_transaction_start(gc, );
+if (rc) goto out;
+
+const char *majmin;
+rc = libxl__xs_read_checked(gc,t, majmin_path, );
+if (rc) goto out;
+if (majmin) {
+/* Old-style Linux-only hotplug script wrote physical-device */
+rc = 0;
+goto out;
+}
+
+const char 

Re: [Xen-devel] [PATCH v3 00/16] Load BIOS via toolstack instead of been embedded in hvmloader.

[Anthony PERARD]

In this series, there are plenty of places where one blob loaded by libxl
to be consume by hvmloader is called acpi_module or acpi_table... where in
fact it is only the DSDT table. I think I'm going to do some renaming to
include "dsdt" into those names.

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH 0/1] ARM: Implement support for write-ctrlreg vm-events

[Corneliu ZUZU]

On 3/3/2016 6:15 PM, Razvan Cojocaru wrote:

On 03/03/2016 04:10 PM, Corneliu ZUZU wrote:

Q2) About VM_EVENT_FLAG_DENY

   Q2.1)
 Doesn't it require sync = 1 (i.e. the vcpu to be paused) to work?
 If so, shouldn't we call vm_event_register_write_resume only after checking
 that VM_EVENT_FLAG_VCPU_PAUSED flag is set (vm_event_resume). Moreover, if
 we do that, wouldn't it be 'cleaner' to rename
 vm_event_register_write_resume->vm_event_deny, check for the
 VM_EVENT_FLAG_DENY flag in vm_event_resume instead and call vm_event_deny
 from there after this check?

Yes, it does require the VCPU to be paused to work, and yes, it's a good
idea to check that that flag is set in the response.

Beyond that, I'd prefer we keep vm_event_register_write_resume()
because, while today all we do there is check that VM_EVENT_FLAG_DENY is
set, we might want do to other things as well there as well (for
example, maybe validate the content of some register). That was really
the point of the "bigger-named" function.

But that's just my opinion, if Tamas prefers your rename suggestion I'll
consider myself outnumbered.


Oh, ok, then the check for VM_EVENT_FLAG_VCPU_PAUSED would be done in 
vm_event_register_write_resume instead of vm_event_resume,
since I suppose vm_event_register_write_resume shouldn't be called only 
when the vcpu is paused, we only apply that to the DENY flag, correct?



   Q2.2)
 VM_EVENT_FLAG_DENY functionality is not implemented w/ this change-set.
 What is done instead is that the control-register write is done *before*
 sending the vm-event (vm_event_put_request). This way, the user can
 override the written register value after receiving the vm-event, which
 in effect provides the same flexibility as VM_EVENT_FLAG_DENY does.
 Using this strategy instead would simplify both Xen's code and the libxc
 user's code.
 Thoughts?

That's how I initially did it with CR events, but with an application
dealing with huge numbers of events, an extra hypercall (to re-set the
register) can be quite expensive, so I had to rework it to the present
state. On these grounds I'm opposed to it - and for consistency I would
prefer that all register write events are pre-write events, and deniable
with a single vm_event reply.



Ah, I understand. I figured the utility of the DENY flag was only for 
cases where you'd want to actively
override the value written to the register (set register to overridden 
value + resume w/ DENY), instead
of just forbidding the write and leaving the register untouched (i.e. 
set on the old value).
If the latter is a  desirable functionality then it indeed makes sense 
to have a DENY flag.


With that said, another thing crossed my mind. Since the DENY flag will 
be implemented for ARM w/ the next
revision and the actual write will be done on the scheduler tail, 
similarly to X86 ((hvm_do_resume), wouldn't
it be good if we separated the code that checks monitor_write_data from 
there into an arch-dependent function,
e.g. vm_event_monitor_write_data? That way the scheduler tail function 
won't be 'polluted' w/ that code and IMHO
it will make the vm-events design more clear (since that functionality 
will also be in vm_event.c along w/ the other

vm_event_* functions).


HTH,
Razvan



Thanks,
Corneliu.

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

Re: [Xen-devel] [PATCH v3 13/16] hvmloader: Load ACPI tables from hvm_start_info module

[Anthony PERARD]

On Tue, Mar 01, 2016 at 09:17:25AM -0700, Jan Beulich wrote:
> >>> On 25.02.16 at 15:56,  wrote:
> > --- a/tools/firmware/hvmloader/hvmloader.c
> > +++ b/tools/firmware/hvmloader/hvmloader.c
> > @@ -365,8 +365,26 @@ int main(void)
> >  
> >  if ( bios->acpi_build_tables )
> >  {
> > +const struct hvm_modlist_entry *acpi_module;
> > +acpi_module = get_module_entry(hvm_start_info, "acpi");
> >  printf("Loading ACPI ...\n");
> > -bios->acpi_build_tables();
> > +if ( acpi_module )
> > +{
> > +uint32_t paddr = acpi_module->paddr;
> > +bios->acpi_build_tables((void*)paddr,
> > +acpi_module->size);
> > +}
> 
> Hmm, so far it was the build process which ensured the right ACPI
> tables would be used with the corresponding BIOS. The disconnect
> that gets introduced here worries me a little, since things having
> got out of sync may be rather hard to diagnose (as they may
> surface only much later).

So, my ultimate goal with this series was to be able to create a guest with
QEMU's Q35 machine, which would need a different ACPI tables.

Also, I would say that the ACPI tables are already disconnected from the
thing they describe, the device model QEMU. I don't think there is much
information about the BIOS backed into the DSDT table.

> > +#ifdef ENABLE_ROMBIOS
> > +else if ( bios == _config )
> > +{
> > +bios->acpi_build_tables(0, 0);
> > +}
> > +#endif
> > +else
> > +{
> > +printf("no ACPI DSDT image found\n");
> > +BUG();
> > +}
> 
> Is this really fatal? It's not like "no ACPI" == "end of the world",
> is it?

I guest it's not fatal, I'll give it a try and just print a warning.

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH 2/6] x86/HVM: remove unnecessary indirection from hvm_get_mem_pinned_cacheattr()

[Andrew Cooper]

On 03/03/16 16:36, Jan Beulich wrote:
> Its return value can easily serve the purpose. We cannot, however,
> return unspecific "success" anymore for a domain of the wrong type -
> since no caller exists that would call this for PV domains, simply add
> an ASSERT().
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH v3 11/16] hvmloader: Load OVMF from modules

[Anthony PERARD]

On Tue, Mar 01, 2016 at 09:03:42AM -0700, Jan Beulich wrote:
> >>> On 25.02.16 at 15:56,  wrote:
> > --- a/tools/firmware/hvmloader/ovmf.c
> > +++ b/tools/firmware/hvmloader/ovmf.c
> > @@ -34,17 +34,10 @@
> >  #include 
> >  #include 
> >  
> > -#define ROM_INCLUDE_OVMF
> > -#include "roms.inc"
> > -
> > -#define OVMF_SIZE   (sizeof(ovmf))
> >  #define OVMF_MAXOFFSET  0x000FULL
> > -#define OVMF_BEGIN  (0x1ULL - ((OVMF_SIZE + 
> > OVMF_MAXOFFSET) & ~OVMF_MAXOFFSET))
> > -#define OVMF_END(OVMF_BEGIN + OVMF_SIZE)
> >  #define LOWCHUNK_BEGIN  0x000F
> >  #define LOWCHUNK_SIZE   0x0001
> >  #define LOWCHUNK_MAXOFFSET  0x
> > -#define LOWCHUNK_END(OVMF_BEGIN + OVMF_SIZE)
> >  #define OVMF_INFO_PHYSICAL_ADDRESS 0x1000
> >  
> >  extern unsigned char dsdt_anycpu_qemu_xen[];
> > @@ -97,16 +90,20 @@ static void ovmf_load(const struct bios_config *config,
> >void *bios_addr, uint32_t bios_length)
> >  {
> >  xen_pfn_t mfn;
> > -uint64_t addr = OVMF_BEGIN;
> > +uint64_t addr = 0x1ULL
> > +- ((bios_length + OVMF_MAXOFFSET) & ~OVMF_MAXOFFSET);
> > +uint64_t ovmf_end = addr + bios_length;
> > +
> > +ovmf_config.bios_address = addr;
> > +ovmf_config.image_size = bios_length;
> >  
> >  /* Copy low-reset vector portion. */
> > -memcpy((void *) LOWCHUNK_BEGIN, (uint8_t *) config->image
> > -   + OVMF_SIZE
> > -   - LOWCHUNK_SIZE,
> > +memcpy((void *) LOWCHUNK_BEGIN,
> > +   (uint8_t *) bios_addr + bios_length - LOWCHUNK_SIZE,
> > LOWCHUNK_SIZE);
> >  
> >  /* Ensure we have backing page prior to moving FD. */
> > -while ( (addr >> PAGE_SHIFT) != (OVMF_END >> PAGE_SHIFT) )
> > +while ( (addr >> PAGE_SHIFT) != (ovmf_end >> PAGE_SHIFT) )
> >  {
> >  mfn = (uint32_t) (addr >> PAGE_SHIFT);
> >  addr += PAGE_SIZE;
> > @@ -114,7 +111,7 @@ static void ovmf_load(const struct bios_config *config,
> >  }
> >  
> >  /* Copy FD. */
> > -memcpy((void *) OVMF_BEGIN, config->image, OVMF_SIZE);
> > +memcpy((void *) ovmf_config.bios_address, bios_addr, bios_length);
> >  }
> 
> Is this safe, considering that source and destination may now
> overlap? Thinking about it, the same consideration applies to
> BIOS placement below 1Mb too.

It's probably not safe, it just happen to work right now. I guest I can add
some checking, or leave it up to libxc to manage the memory and write this
blob just after hvmloader, like it's done right now.

I think I'll add some bug_on to catch unexpected changes.

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH 6/6] x86/HVM: re-format cache attribute pinning code

[Andrew Cooper]

On 03/03/16 16:38, Jan Beulich wrote:
> No intended functional change, albeit it includes ditching a redundant
> is_hvm_domain().
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH 5/6] x86/HVM: adjust hvm_get_mem_pinned_cacheattr() GFN parameter

[Andrew Cooper]

On 03/03/16 16:38, Jan Beulich wrote:
> Make it gfn_t and rename it accordingly.
>
> Suggested-by: Andrew Cooper 
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH 4/6] x86/HVM: limit flushing on cache attribute pinning adjustments

[Andrew Cooper]

On 03/03/16 16:37, Jan Beulich wrote:
> Avoid cache flush on EPT when removing a UC- range, since when used
> this type gets converted to UC anyway (there's no UC- among the types
> valid in MTRRs and hence EPT's emt field).
>
> We might further wwant to consider only forcing write buffer flushes
> when removing WC ranges.
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH 1/6] x86/HVM: honor cache attribute pinning for RAM only

[Andrew Cooper]

On 03/03/16 16:33, Jan Beulich wrote:
> Call hvm_get_mem_pinned_cacheattr() for RAM ranges only, and only when
> the guest has a physical device assigned: XEN_DOMCTL_pin_mem_cacheattr
> is documented to be intended for RAM only.
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH 3/6] x86/HVM: adjust hvm_set_mem_pinned_cacheattr() error indications

[Andrew Cooper]

On 03/03/16 16:37, Jan Beulich wrote:
> Make it return an error on bad domain kind or obviously bad GFN range.
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [BUG] xs.watch and xs.unwatch are unreliable

[David Vrabel]

On 03/03/16 17:02, Wei Liu wrote:
> On Thu, Mar 03, 2016 at 04:47:12PM +, David Vrabel wrote:
>> On 01/03/16 20:17, Sergei Lebedev wrote:
>>> Hi list,
>>>
>>> I’ve initially wanted to report another inconsistency in
>>> ``xen.lowlevel.xs`` documentation, but this time the issue is more
>>> subtle.
>>
>> [...]
>>
>>> Here’s another example with a string token
>>>
>>> >>> token1 = str(10)
>>> >>> token2 = str(10)
>>> >>> token1 == token2
>>> True
>>> >>> h.watch("@introduceDomain", token1)
>>> >>> h.unwatch("@introduceDomain", token2)
>>> Traceback (most recent call last):
>>>   File "", line 1, in 
>>> xen.lowlevel.xs.Error: (2, 'No such file or directory’)
>>>
>>> I’m not sure what would be the best way to handle this as there might
>>> be existing code relying on this undocumented behaviour. What do you
>>> think?
>>
>> I think you're stuck with this behaviour.  If you fix it there's a risk
>> of breaking existing applications by unwatch removing the wrong watch.
>>
> 
> I'm not sure I follow this. Do you have an example why it would remove
> the wrong watch?

  token1 = str(10)
  token2 = str(10)

  h.watch("path", token1)
  h.watch("path", token2)

Created two unique tokens.

  h.unwatch("path", token1)

Which watch should be removed if token1 and token2 no longer have a
unique token?  Although, I'm not sure of the behaviour of adding two
watches with the same token.

It also occurs to me that if this area is going to be improved, it
should be the kernel that provides the token since it has to be unique
across all users.

David

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

Re: [Xen-devel] [PATCH v3 05/16] libxl: Load guest BIOS from file

[Anthony PERARD]

On Tue, Mar 01, 2016 at 11:51:40AM +, Wei Liu wrote:
> On Thu, Feb 25, 2016 at 02:56:03PM +, Anthony PERARD wrote:
> > The path to the BIOS blob can be override by the xl's bios_override option,
> > or provided by u.hvm.bios_firmware in the domain_build_info struct by other
> > libxl user.
> > 
> > Signed-off-by: Anthony PERARD 
> > 
> > ---
> > Change in V3:
> > - move seabios_path and ovmf_path to libxl_path.c (with renaming)
> > - fix some coding style
> > - warn for empty file
> > - remove rombios stuff (will still be built-in hvmloader)
> > - rename field bios_filename in domain_build_info to bios_firmware to
> >   follow naming of acpi and smbios.
> > - log an error after libxl_read_file_contents() only when it return ENOENT
> > - return an error on empty file.
> > - added #define LIBXL_HAVE_BUILDINFO_HVM_BIOS_FIRMWARE
> > ---
> >  tools/libxl/libxl.h  |  8 +++
> >  tools/libxl/libxl_dom.c  | 57 
> > 
> >  tools/libxl/libxl_internal.h |  2 ++
> >  tools/libxl/libxl_paths.c| 10 
> >  tools/libxl/libxl_types.idl  |  1 +
> >  tools/libxl/xl_cmdimpl.c | 11 ++---
> 
> You also need to patch manpage for this new option.

Yes, I'll do that.

> How does this new option interacts with bios= option?

That would be the same interaction that there is between
device_model_version and device_model_override.

If someone provide bios_override without bios, the guest could fail to
boot.

> >  6 files changed, 86 insertions(+), 3 deletions(-)
> > 
> > diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> > index fa87f53..d223c35 100644
> > --- a/tools/libxl/libxl.h
> > +++ b/tools/libxl/libxl.h
> > @@ -876,6 +876,14 @@ void libxl_mac_copy(libxl_ctx *ctx, libxl_mac *dst, 
> > libxl_mac *src);
> >   */
> >  #define LIBXL_HAVE_DEVICE_MODEL_VERSION_NONE 1
> >  
> > +/*
> > + * LIBXL_HAVE_BUILDINFO_HVM_BIOS_FIRMWARE
> > + *
> > + * libxl_domain_build_info has u.hvm.bios_firmware field which can be use
> > + * to provide a different bios blob (like SeaBIOS or OVMF).
> > + */
> > +#define LIBXL_HAVE_BUILDINFO_HVM_BIOS_FIRMWARE
> > +
> >  typedef char **libxl_string_list;
> >  void libxl_string_list_dispose(libxl_string_list *sl);
> >  int libxl_string_list_length(const libxl_string_list *sl);
> > diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> > index 2269998..50abfbc 100644
> > --- a/tools/libxl/libxl_dom.c
> > +++ b/tools/libxl/libxl_dom.c
> > @@ -863,6 +863,38 @@ err:
> >  return ret;
> >  }
> >  
> > +static int libxl__load_hvm_firmware_module(libxl__gc *gc,
> > +   const char *filename,
> > +   const char *what,
> > +   struct xc_hvm_firmware_module 
> > *m)
> > +{
> > +int datalen = 0;
> > +void *data = NULL;
> > +int e;
> > +
> > +LOG(DEBUG, "Loading %s: %s", what, filename);
> > +e = libxl_read_file_contents(CTX, filename, , );
> > +if (e) {
> > +/*
> > + * Print a message only on ENOENT, other error are logged by the
> > + * function libxl_read_file_contents().
> > + */
> > +if (e == ENOENT)
> > +LOGEV(ERROR, e, "failed to read %s file", what);
> > +return ERROR_FAIL;
> > +}
> > +libxl__ptr_add(gc, data);
> > +if (datalen) {
> > +/* Only accept non-empty files */
> > +m->data = data;
> > +m->length = datalen;
> > +} else {
> > +LOG(ERROR, "file %s for %s is empty", filename, what);
> > +return ERROR_FAIL;
> 
> ERROR_INVAL is more appropriate.

OK.

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH v3 06/16] libxl: Load guest ACPI table from file

[Anthony PERARD]

On Tue, Mar 01, 2016 at 11:51:43AM +, Wei Liu wrote:
> On Thu, Feb 25, 2016 at 02:56:04PM +, Anthony PERARD wrote:
> > A user can provide a different ACPI tables than the default one by using
> > the existing "acpi_firmware" xl's config option or the field
> > u.hvm.acpi_firmware.
> > 
> > libxl will check if the provided table is a DSDT or not.
> > 
> 
> According to xl.cfg manpage, acpi_firmware= cann't be used to override
> DSDT, so you seem to be changing the semantics of existing option.

Yes, that was an idea from Ian Campbell <1446634655.6461.48.ca...@citrix.com>
I should at least change the manual.

Would it be OK to reuse this options? Or should I add a new option, maybe
acpi_dsdt_override, or some other name?

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH 2/6] x86/HVM: remove unnecessary indirection from hvm_get_mem_pinned_cacheattr()

[Wei Liu]

On Thu, Mar 03, 2016 at 04:59:22PM +, Wei Liu wrote:
> On Thu, Mar 03, 2016 at 09:36:19AM -0700, Jan Beulich wrote:
> [...]
> >  sflags |= pat_type_2_pte_flags(type);
> >  else if ( d->arch.hvm_domain.is_in_uc_mode )
> >  sflags |= pat_type_2_pte_flags(PAT_TYPE_UNCACHABLE);
> > --- a/xen/include/asm-x86/hvm/cacheattr.h
> > +++ b/xen/include/asm-x86/hvm/cacheattr.h
> > @@ -15,8 +15,7 @@ void hvm_destroy_cacheattr_region_list(
> >  int hvm_get_mem_pinned_cacheattr(
> >  struct domain *d,
> >  uint64_t guest_fn,
> > -unsigned int order,
> > -uint32_t *type);
> > +unsigned int order);
> >  
> 
> You seem to have forgotten to update the comment for this function as
> you did in previous patch.

Oh well, the updated comment went into the final patch of this series.

Wei.

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