Re: [Xen-devel] [PATCH 3/3] mini-os: support "make config" for out-of-tree users

[Juergen Gross]

On 02/09/16 03:21, Samuel Thibault wrote:
> Hello,
> 
> Juergen Gross, on Thu 01 Sep 2016 08:21:33 +0200, wrote:
>> I stumbled over the problem with xenstore-stubdom: xenstore is using
>> __XEN_LATEST_INTERFACE_VERSION__ when being compiled. This produced a
>> build error with Mini-OS (console_evtchn in include/console.h was
>> #define'd to console.domU.evtchn by include/xen/xen.h). It was pure
>> luck such a problem didn't occur before my recent changes.
>>
>> I think it is much more reasonable to compile all parts of a stubdom
>> with the same Xen interface version instead of letting use the core of
>> Mini-OS an ancient version and the App using Mini-OS another one.
> 
> Ok, I agree with that.

Very good.

>> So I added XEN_INTERFACE_VERSION to be configurable.
>> This requires some adjustments in Mini-OS, of course. That is the
>> purpose of patch 1 of this series.
> 
> Ok, now I better understand the issue, pros and cons, etc. It would be
> better to clearly document and test it: AIUI,
> 
> - interface version compatibility is not so great: some features
> are e.g. just *not* available when using interface version 0, so if
> mini-os tries to use newer interfaces while stubdom asks for an older
> interface version, it will fail to build, so it may need #ifs to check
> for presence of the interface, and gracefully disable using the feature
> instead of failing-to-build.
> 
> - mini-os happens not to be able to build with interface version 0,
> basically because the current default is 0x00030205 and so nobody tests
> with 0. Notably due to the console_evtchn #define, but also the use of
> set_xen_guest_handle. Ideally we'd fix it, but I guess nobody will want
> something older than that anyway, so we probably don't want to handle
> the burden.

I think 0x00030205 should be the minimum version Mini-OS has to support.

> - to be able to let the stubdom application decide which interface
> version it wants to build against, mini-os must be buildable standalone
> with all versions from 0x00030205 to latest supported (which is what
> patch 1 fixes). A not too bad approximation of this would be to be
> able to build it with the minimum supported version and with latest
> version. Perhaps we can declare that Config.mk's default interface
> version is the minimum supported, so building standalone mini-os will
> test that, and since as you say we already build the xenstore-stubdom
> with latest version, building the xenstore-stubdom will test that.

I think I'll add a new make target "test" which will test different
build configurations (PARAVIRT y/n, BALLOON y/n, 32/64 bit, Xen
interface versions, all/no frontends). This can be easily added to
OSStest.

> - that way, stubdom applications can choose the level of compatibility
> they wish from mini-os' minimum supported to mini-os' latest supported.
> 
> - whenever somebody would like to use an interface version which is
> not supported by mini-os headers yet, we just need to update mini-os'
> headers, and we have to fix the build with the minimum supported version
> and with the latest supported version.

Right.

> So if you agree with my reasoning, I'd say that the patch series
> should document all that along the definition of XEN_INTERFACE_VERSION
> in Config.mk: explaining that this default is the minimum supported
> interface version, which the application can override up to the latest
> supported by mini-os, and if a yet-newer interface is needed, one should
> upgrade the headers, and before committing, try to build mini-os both
> with the same minimum supported version for compatibility, and with the
> latest version.

Okay, I'll update the patch description and add some README contents.


Juergen

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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf b8922094f6f8b5293f01a09035b74463fff12320
baseline version:
 ovmf 3ef3209d3028b77af9f56f183370e7b67cd7c849

Last test of basis   100709  2016-09-01 21:16:11 Z0 days
Testing same since   100710  2016-09-02 02:38:24 Z0 days1 attempts


People who touched revisions under test:
  Dong, Eric 
  Eric Dong 
  Ruiyu Ni 
  Star Zeng 

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



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=b8922094f6f8b5293f01a09035b74463fff12320
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
b8922094f6f8b5293f01a09035b74463fff12320
+ branch=ovmf
+ revision=b8922094f6f8b5293f01a09035b74463fff12320
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' xb8922094f6f8b5293f01a09035b74463fff12320 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' 

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 3ef3209d3028b77af9f56f183370e7b67cd7c849
baseline version:
 ovmf b10d5ddc0385f39d2c2c62843710b7609a4ca169

Last test of basis67622  2016-09-01 18:16:25 Z0 days
Testing same since67623  2016-09-02 02:46:24 Z0 days1 attempts


People who touched revisions under test:
  Laszlo Ersek 

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



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

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

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


Push not applicable.


commit 3ef3209d3028b77af9f56f183370e7b67cd7c849
Author: Laszlo Ersek 
Date:   Thu Aug 18 11:51:33 2016 +0200

ArmVirtPkg: remove PcdKludgeMapPciMmioAsCached

In ARM/AARCH64 guests that run on KVM, we can now use virtio-gpu-pci, so
PcdKludgeMapPciMmioAsCached is no longer necessary. Standard VGA continues
to work on TCG without the kludge.

Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=66
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
Reviewed-by: Ard Biesheuvel 
Reviewed-by: Jordan Justen 

commit 8731debefd1f0750cd033ce88a83f1d1dce9df3c
Author: Laszlo Ersek 
Date:   Wed Aug 17 22:45:02 2016 +0200

OvmfPkg/VirtioGpuDxe: implement EFI_GRAPHICS_OUTPUT_PROTOCOL

In this patch we replace our "dummy" Graphics Output Protocol interface
with the real one. We exploit that EFI_GRAPHICS_OUTPUT_BLT_PIXEL and
VirtioGpuFormatB8G8R8X8Unorm have identical representations; this lets us
forego any pixel format conversions in the guest. For messaging the VirtIo
GPU device, we use the primitives introduced in the previous patch.

Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=66
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
Reviewed-by: Jordan Justen 

commit a66ea3b5578ccebf22c2d1d673273f0dffc84ffa
Author: Laszlo Ersek 
Date:   Thu Aug 18 17:00:03 2016 +0200

OvmfPkg/VirtioGpuDxe: provide functions for sending VirtIo GPU commands

In this patch we add a "workhorse" function called VirtioGpuSendCommand(),
and implement seven simple RPCs atop, for the command types listed in
"OvmfPkg/Include/IndustryStandard/VirtioGpu.h".

These functions will be called by our EFI_GRAPHICS_OUTPUT_PROTOCOL
implementation.

Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=66
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
Reviewed-by: Jordan Justen 

commit c5f235bbf2ac6ecf9acec023a1840b03cbfb5efd
Author: Laszlo Ersek 
Date:   Thu Aug 18 01:31:27 2016 +0200

OvmfPkg/VirtioGpuDxe: initialize and tear down VirtIo GPU device

This patch implements the steps listed in section "3.1.1 Driver
Requirements: Device Initialization" of the Virtio V1.0 Committee Spec 04.
The VirtIo GPU is brought up in VirtioGpuDriverBindingStart(), and down in
VirtioGpuDriverBindingStop().

We also add an ExitBootServices() callback that resets the device. This
ensures that the device model abandons any guest memory areas when we
transfer control 

Re: [Xen-devel] [PATCH v3 6/6] VMX: Fixup PI descritpor when cpu is offline

[Wu, Feng]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, September 1, 2016 4:49 PM
> To: Wu, Feng 
> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com;
> george.dun...@eu.citrix.com; Tian, Kevin ; xen-
> de...@lists.xen.org
> Subject: Re: [PATCH v3 6/6] VMX: Fixup PI descritpor when cpu is offline
> 
> >>> On 31.08.16 at 05:56,  wrote:
> > +void vmx_pi_desc_fixup(int cpu)
> 
> unsigned int
> 
> > +{
> > +unsigned int new_cpu, dest;
> > +unsigned long flags;
> > +struct arch_vmx_struct *vmx, *tmp;
> > +spinlock_t *new_lock, *old_lock = _cpu(vmx_pi_blocking, cpu).lock;
> > +struct list_head *blocked_vcpus = _cpu(vmx_pi_blocking, cpu).list;
> > +
> > +if ( !iommu_intpost )
> > +return;
> > +
> > +spin_lock_irqsave(old_lock, flags);
> > +
> > +list_for_each_entry_safe(vmx, tmp, blocked_vcpus, pi_blocking.list)
> > +{
> > +/*
> > + * We need to find an online cpu as the NDST of the PI descriptor, 
> > it
> > + * doesn't matter whether it is within the cpupool of the domain or
> > + * not. As long as it is online, the vCPU will be woken up once the
> > + * notification event arrives.
> > + */
> > +restart:
> 
> I'd prefer if you did this without label and goto, but in any case
> labels should be indented by at least one space. Yet ...
> 
> > +new_cpu = cpumask_any(_online_map);
> > +new_lock = _cpu(vmx_pi_blocking, new_cpu).lock;
> > +
> > +spin_lock(new_lock);
> > +
> > +/*
> > + * If the new_cpu is not online, that means it became offline 
> > between
> > + * we got 'new_cpu' and acquiring its lock above, we need to find
> > + * another online cpu instead. Such as, this fucntion is being 
> > called
> > + * on 'new_cpu' at the same time. Can this happen??
> > + */
> > +if ( !cpu_online(new_cpu) )
> > +{
> > +spin_unlock(new_lock);
> > +goto restart;
> > +}
> 
> ... I think this too has been discussed before: Is this case really
> possible? You're in the context of a CPU_DEAD or CPU_UP_CANCELED
> notification, which both get issued with cpu_add_remove_lock held.
> How can a second CPU go down in parallel?

Here is the call chain:

cpu_down() ->
stop_machine_run() ->
get_cpu_maps()  /* Try to hold the cpu_add_remove_lock */
..
put_cpu_maps()  /* Release the lock */
notifier_call_chain(..., CPU_DEAD, ...) ->
vmx_vcpu_dead() ->
vmx_pi_desc_fixup()

Seems vmx_pi_desc_fixup() is not calling with holding cpu_add_remove_lock?
Or do I miss something? Thanks for further comments in advance!

Thanks,
Feng

> 
> Jan


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

[Xen-devel] fail to register IRQ for virtualization exception

[Big Strong]

Hello.

I'm recently trying to utilize the virtualization exception (#VE) feature.
As the document says, #VE is handled by guest interrupt handler. The IRQ
number of #VE is 20. However, when I tried to register an IRQ handler for
#VE, it returns errno -22, which means invalid arguments.

request_irq(20, ve_handler, IRQF_NO_SUSPEND, "ve", NULL)

Is there anything wrong?

To handle this system reserved exception, should I modify the linux kernel
instead of using loadable kernel module (LKM)? As the IRQ number 20 is not
defined in linux kernel (traps.h), also no exception handling function is
defined (traps.c). As it is defined as a system reserved exception, so I
can't register it using LKM?

BTW, I've already enabled #VE feature using HVMOP_altp2m_vcpu_enable_notify.

The attachment is the definition of #VE from Intel Manual.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Shannon Zhao]

From: Shannon Zhao 

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

Also use HVM_PARAM_CALLBACK_IRQ_TYPE_SHIFT in hvm_set_callback_via().

Cc: Jan Beulich 
Cc: Andrew Cooper 
Signed-off-by: Shannon Zhao 
---
 xen/arch/arm/domain_build.c | 8 +---
 xen/arch/x86/hvm/irq.c  | 2 +-
 xen/include/public/hvm/params.h | 3 +++
 3 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 60db9e4..494115b 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2019,9 +2019,11 @@ static void evtchn_fixup(struct domain *d, struct 
kernel_info *kinfo)
d->arch.evtchn_irq);
 
 /* Set the value of domain param HVM_PARAM_CALLBACK_IRQ */
-val = (u64)HVM_PARAM_CALLBACK_TYPE_PPI << 56;
-val |= (2 << 8); /* Active-low level-sensitive  */
-val |= d->arch.evtchn_irq & 0xff;
+val = (u64)HVM_PARAM_CALLBACK_TYPE_PPI << 
HVM_PARAM_CALLBACK_IRQ_TYPE_SHIFT;
+/* Active-low level-sensitive  */
+val |= (HVM_PARAM_CALLBACK_TYPE_PPI_FLAG_LOW_LEVEL <<
+HVM_PARAM_CALLBACK_TYPE_PPI_FLAG_SHIFT);
+val |= d->arch.evtchn_irq;
 d->arch.hvm_domain.params[HVM_PARAM_CALLBACK_IRQ] = val;
 
 /*
diff --git a/xen/arch/x86/hvm/irq.c b/xen/arch/x86/hvm/irq.c
index 5323d7c..7c5836b 100644
--- a/xen/arch/x86/hvm/irq.c
+++ b/xen/arch/x86/hvm/irq.c
@@ -325,7 +325,7 @@ void hvm_set_callback_via(struct domain *d, uint64_t via)
 unsigned int gsi=0, pdev=0, pintx=0;
 uint8_t via_type;
 
-via_type = (uint8_t)(via >> 56) + 1;
+via_type = (uint8_t)(via >> HVM_PARAM_CALLBACK_IRQ_TYPE_SHIFT) + 1;
 if ( ((via_type == HVMIRQ_callback_gsi) && (via == 0)) ||
  (via_type > HVMIRQ_callback_vector) )
 via_type = HVMIRQ_callback_none;
diff --git a/xen/include/public/hvm/params.h b/xen/include/public/hvm/params.h
index f7338a3..a161de1 100644
--- a/xen/include/public/hvm/params.h
+++ b/xen/include/public/hvm/params.h
@@ -30,6 +30,7 @@
  */
 
 #define HVM_PARAM_CALLBACK_IRQ 0
+#define HVM_PARAM_CALLBACK_IRQ_TYPE_SHIFT 56
 /*
  * How should CPU0 event-channel notifications be delivered?
  *
@@ -66,6 +67,8 @@
  * This is only used by ARM/ARM64 and masking/eoi the interrupt associated to
  * the notification is handled by the interrupt controller.
  */
+#define HVM_PARAM_CALLBACK_TYPE_PPI_FLAG_SHIFT 8
+#define HVM_PARAM_CALLBACK_TYPE_PPI_FLAG_LOW_LEVEL 2
 #endif
 
 /*
-- 
2.0.4



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

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

[Shannon Zhao]

From: Shannon Zhao 

Construct GTDT table with the interrupt information of timers.

Signed-off-by: Shannon Zhao 
---
 tools/libxl/libxl_arm_acpi.c | 38 ++
 1 file changed, 38 insertions(+)

diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
index 93ba2d1..ab49d57 100644
--- a/tools/libxl/libxl_arm_acpi.c
+++ b/tools/libxl/libxl_arm_acpi.c
@@ -25,10 +25,24 @@ typedef uint8_t u8;
 typedef uint16_t u16;
 typedef uint32_t u32;
 typedef uint64_t u64;
+typedef int64_t s64;
 
 #include 
 #include 
 
+#ifndef BITS_PER_LONG
+#ifdef _LP64
+#define BITS_PER_LONG 64
+#else
+#define BITS_PER_LONG 32
+#endif
+#endif
+#define ACPI_MACHINE_WIDTH __BITS_PER_LONG
+#define COMPILER_DEPENDENT_INT64 int64_t
+#define COMPILER_DEPENDENT_UINT64 uint64_t
+
+#include 
+
 _hidden
 extern const unsigned char dsdt_anycpu_arm[];
 _hidden
@@ -190,6 +204,29 @@ static void make_acpi_xsdt(libxl__gc *gc, struct 
xc_dom_image *dom,
acpitables[XSDT].size);
 }
 
+static void make_acpi_gtdt(libxl__gc *gc, struct xc_dom_image *dom,
+   struct acpitable acpitables[])
+{
+uint64_t offset = acpitables[GTDT].addr - GUEST_ACPI_BASE;
+struct acpi_table_gtdt *gtdt = (void *)dom->acpi_modules[0].data + offset;
+
+gtdt->non_secure_el1_interrupt = GUEST_TIMER_PHYS_NS_PPI;
+gtdt->non_secure_el1_flags =
+ (ACPI_LEVEL_SENSITIVE << ACPI_GTDT_INTERRUPT_MODE)
+ |(ACPI_ACTIVE_LOW << 
ACPI_GTDT_INTERRUPT_POLARITY);
+gtdt->virtual_timer_interrupt = GUEST_TIMER_VIRT_PPI;
+gtdt->virtual_timer_flags =
+ (ACPI_LEVEL_SENSITIVE << ACPI_GTDT_INTERRUPT_MODE)
+ |(ACPI_ACTIVE_LOW << 
ACPI_GTDT_INTERRUPT_POLARITY);
+
+gtdt->counter_block_addresss = 0x;
+gtdt->counter_read_block_address = 0x;
+
+make_acpi_header(>header, "GTDT", acpitables[GTDT].size, 2);
+calculate_checksum(gtdt, offsetof(struct acpi_table_header, checksum),
+   acpitables[GTDT].size);
+}
+
 int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
 libxl__domain_build_state *state,
 struct xc_dom_image *dom)
@@ -220,6 +257,7 @@ int libxl__prepare_acpi(libxl__gc *gc, 
libxl_domain_build_info *info,
 
 make_acpi_rsdp(gc, dom, acpitables);
 make_acpi_xsdt(gc, dom, acpitables);
+make_acpi_gtdt(gc, dom, acpitables);
 
 out:
 return rc;
-- 
2.0.4



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

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

[Shannon Zhao]

From: Shannon Zhao 

Signed-off-by: Shannon Zhao 
---
 tools/libxl/libxl_arm_acpi.c | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
index 83ad954..93ba2d1 100644
--- a/tools/libxl/libxl_arm_acpi.c
+++ b/tools/libxl/libxl_arm_acpi.c
@@ -161,6 +161,35 @@ static void make_acpi_rsdp(libxl__gc *gc, struct 
xc_dom_image *dom,
acpitables[RSDP].size);
 }
 
+static void make_acpi_header(struct acpi_table_header *h, const char *sig,
+ size_t len, uint8_t rev)
+{
+memcpy(h->signature, sig, 4);
+h->length = len;
+h->revision = rev;
+memcpy(h->oem_id, ACPI_OEM_ID, sizeof(h->oem_id));
+memcpy(h->oem_table_id, ACPI_OEM_TABLE_ID, sizeof(h->oem_table_id));
+h->oem_revision = 0;
+memcpy(h->asl_compiler_id, ACPI_ASL_COMPILER_ID,
+   sizeof(h->asl_compiler_id));
+h->asl_compiler_revision = 0;
+h->checksum = 0;
+}
+
+static void make_acpi_xsdt(libxl__gc *gc, struct xc_dom_image *dom,
+   struct acpitable acpitables[])
+{
+uint64_t offset = acpitables[XSDT].addr - GUEST_ACPI_BASE;
+struct acpi_table_xsdt *xsdt = (void *)dom->acpi_modules[0].data + offset;
+
+xsdt->table_offset_entry[0] = acpitables[MADT].addr;
+xsdt->table_offset_entry[1] = acpitables[GTDT].addr;
+xsdt->table_offset_entry[2] = acpitables[FADT].addr;
+make_acpi_header(>header, "XSDT", acpitables[XSDT].size, 1);
+calculate_checksum(xsdt, offsetof(struct acpi_table_header, checksum),
+   acpitables[XSDT].size);
+}
+
 int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
 libxl__domain_build_state *state,
 struct xc_dom_image *dom)
@@ -190,6 +219,7 @@ int libxl__prepare_acpi(libxl__gc *gc, 
libxl_domain_build_info *info,
 goto out;
 
 make_acpi_rsdp(gc, dom, acpitables);
+make_acpi_xsdt(gc, dom, acpitables);
 
 out:
 return rc;
-- 
2.0.4



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

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

[Shannon Zhao]

From: Shannon Zhao 

Here it adds the ACPI tables size to set the target maxmem to avoid
providing less available memory for guest.

Signed-off-by: Shannon Zhao 
---
 tools/libxl/libxl_arch.h|  2 +-
 tools/libxl/libxl_arm.c | 18 +-
 tools/libxl/libxl_arm.h |  4 
 tools/libxl/libxl_arm_acpi.c| 20 
 tools/libxl/libxl_arm_no_acpi.c |  6 ++
 tools/libxl/libxl_dom.c |  2 +-
 tools/libxl/libxl_x86.c |  2 +-
 7 files changed, 50 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/libxl_arch.h b/tools/libxl/libxl_arch.h
index 337061f..d62fa4c 100644
--- a/tools/libxl/libxl_arch.h
+++ b/tools/libxl/libxl_arch.h
@@ -30,7 +30,7 @@ int libxl__arch_domain_save_config(libxl__gc *gc,
 /* arch specific internal domain creation function */
 _hidden
 int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
-   uint32_t domid);
+  libxl__domain_build_state *state, uint32_t 
domid);
 
 /* setup arch specific hardware description, i.e. DTB on ARM */
 _hidden
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index e73d65e..c7d4f65 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -101,8 +101,24 @@ int libxl__arch_domain_save_config(libxl__gc *gc,
 }
 
 int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
-  uint32_t domid)
+  libxl__domain_build_state *state, uint32_t domid)
 {
+libxl_domain_build_info *const info = _config->b_info;
+libxl_ctx *ctx = libxl__gc_owner(gc);
+int size;
+
+/* Add the size of ACPI tables to maxmem if ACPI is enabled for guest. */
+if (libxl_defbool_val(info->acpi)) {
+size = libxl__get_acpi_size(gc, info, state);
+if (size < 0)
+return ERROR_FAIL;
+if (xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb +
+LIBXL_MAXMEM_CONSTANT + (size + 1023) / 1024)) 
{
+LOGE(ERROR, "Couldn't set max memory");
+return ERROR_FAIL;
+}
+}
+
 return 0;
 }
 
diff --git a/tools/libxl/libxl_arm.h b/tools/libxl/libxl_arm.h
index a91ff93..37b1f15 100644
--- a/tools/libxl/libxl_arm.h
+++ b/tools/libxl/libxl_arm.h
@@ -24,6 +24,10 @@ int libxl__prepare_acpi(libxl__gc *gc, 
libxl_domain_build_info *info,
 libxl__domain_build_state *state,
 struct xc_dom_image *dom);
 
+_hidden
+int libxl__get_acpi_size(libxl__gc *gc, libxl_domain_build_info *info,
+ libxl__domain_build_state *state);
+
 static inline uint64_t libxl__compute_mpdir(unsigned int cpuid)
 {
 /*
diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
index 30e4d66..9854c7a 100644
--- a/tools/libxl/libxl_arm_acpi.c
+++ b/tools/libxl/libxl_arm_acpi.c
@@ -94,6 +94,26 @@ static int libxl__estimate_madt_size(libxl__gc *gc,
 return rc;
 }
 
+int libxl__get_acpi_size(libxl__gc *gc, libxl_domain_build_info *info,
+ libxl__domain_build_state *state)
+{
+int size;
+
+size = libxl__estimate_madt_size(gc, info, >config);
+if (size < 0)
+goto out;
+
+size = ROUNDUP(size, 3) +
+   ROUNDUP(sizeof(struct acpi_table_rsdp), 3) +
+   ROUNDUP(sizeof(struct acpi_table_xsdt), 3) +
+   ROUNDUP(sizeof(struct acpi_table_gtdt), 3) +
+   ROUNDUP(sizeof(struct acpi_table_fadt), 3) +
+   ROUNDUP(sizeof(dsdt_anycpu_arm_len), 3);
+
+out:
+return size;
+}
+
 static int libxl__estimate_acpi_size(libxl__gc *gc,
  libxl_domain_build_info *info,
  struct xc_dom_image *dom,
diff --git a/tools/libxl/libxl_arm_no_acpi.c b/tools/libxl/libxl_arm_no_acpi.c
index e7f7411..5eeb825 100644
--- a/tools/libxl/libxl_arm_no_acpi.c
+++ b/tools/libxl/libxl_arm_no_acpi.c
@@ -25,6 +25,12 @@ int libxl__prepare_acpi(libxl__gc *gc, 
libxl_domain_build_info *info,
 return ERROR_FAIL;
 }
 
+int libxl__get_acpi_size(libxl__gc *gc, libxl_domain_build_info *info,
+ libxl__domain_build_state *state)
+{
+return ERROR_FAIL;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 7dbf614..a2cd350 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -437,7 +437,7 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
 #endif
 }
 
-rc = libxl__arch_domain_create(gc, d_config, domid);
+rc = libxl__arch_domain_create(gc, d_config, state, domid);
 
 return rc;
 }
diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
index e9127bb..c872089 100644
--- a/tools/libxl/libxl_x86.c
+++ b/tools/libxl/libxl_x86.c
@@ -285,7 +285,7 @@ static int libxl__e820_alloc(libxl__gc *gc, uint32_t domid,
 }
 
 int 

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

[Shannon Zhao]

From: Shannon Zhao 

Construct ACPI RSDP table and add a helper to calculate the ACPI table
checksum.

Signed-off-by: Shannon Zhao 
---
 tools/libxl/libxl_arm_acpi.c | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
index b91f3f6..83ad954 100644
--- a/tools/libxl/libxl_arm_acpi.c
+++ b/tools/libxl/libxl_arm_acpi.c
@@ -34,6 +34,10 @@ extern const unsigned char dsdt_anycpu_arm[];
 _hidden
 extern const int dsdt_anycpu_arm_len;
 
+#define ACPI_OEM_ID "Xen"
+#define ACPI_OEM_TABLE_ID "ARM"
+#define ACPI_ASL_COMPILER_ID "XL"
+
 enum {
 RSDP,
 XSDT,
@@ -126,6 +130,37 @@ out:
 return rc;
 }
 
+static void calculate_checksum(void *table, uint32_t checksum_offset,
+   uint32_t length)
+{
+uint8_t *p, sum = 0;
+
+p = table;
+p[checksum_offset] = 0;
+
+while (length--)
+sum = sum + *p++;
+
+p = table;
+p[checksum_offset] = -sum;
+}
+
+static void make_acpi_rsdp(libxl__gc *gc, struct xc_dom_image *dom,
+   struct acpitable acpitables[])
+{
+uint64_t offset = acpitables[RSDP].addr - GUEST_ACPI_BASE;
+struct acpi_table_rsdp *rsdp = (void *)dom->acpi_modules[0].data + offset;
+
+memcpy(rsdp->signature, "RSD PTR ", sizeof(rsdp->signature));
+memcpy(rsdp->oem_id, ACPI_OEM_ID, sizeof(rsdp->oem_id));
+rsdp->length = acpitables[RSDP].size;
+rsdp->revision = 0x02;
+rsdp->xsdt_physical_address = acpitables[XSDT].addr;
+calculate_checksum(rsdp,
+   offsetof(struct acpi_table_rsdp, extended_checksum),
+   acpitables[RSDP].size);
+}
+
 int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
 libxl__domain_build_state *state,
 struct xc_dom_image *dom)
@@ -151,6 +186,10 @@ int libxl__prepare_acpi(libxl__gc *gc, 
libxl_domain_build_info *info,
 dom->acpi_modules[0].guest_addr_out = GUEST_ACPI_BASE;
 
 rc = libxl__estimate_acpi_size(gc, info, dom, xc_config, acpitables);
+if (rc)
+goto out;
+
+make_acpi_rsdp(gc, dom, acpitables);
 
 out:
 return rc;
-- 
2.0.4



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

[Xen-devel] [PATCH v5 00/16] Xen ARM DomU ACPI support

[Shannon Zhao]

From: Shannon Zhao 

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

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

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

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

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

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

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

Changes since v4:
* make changes in tools/configure.ac instead of tools/configure
* add libxl_arm_no_acpi.c for no acpi build
* add a function to get the acpi table size and use it to set maxmem
* drop HVM_PARAM_CALLBACK_TYPE_PPI_MASK and update hvm_set_callback_via
* add libxl__arch_domain_build_info_acpi_setdefault to set b_info->acpi
  default value separately
* update ACPI_OEM_ID
* set gtdt->counter_block_addresss and gtdt->counter_read_block_address
* add a BUILD_BUG_ON to check if GUEST_MAX_VCPUS >= MAX_VIRT_CPUS

Changes since v3:
* use goto style error handle
* unify configuration option for ACPI
* use extended_checksum instead of checksum in RSDP table
* only require iasl on arm64
* count acpi tables size for maxmem

Changes since v2:
* return error for 32bit domain with acpi enabled
* include actypes.h to reuse the definitions
* rename libxl_arm_acpi.h to libxl_arm.h
* use ACPI_MADT_ENABLED
* rebased on top of Boris's ACPI branch to reuse mk_dsdt.c

Changes since v1:
* move ACPI tables generation codes to a new file
* use static asl file to generate DSDT table and include processor
  device objects
* assign a non-RAM map for ACPI blob
* use existing ACPI table definitions under xen/include/acpi/
* add a configuration for user to enable/disable ACPI generation
* calculate the ACPI table checksum

Shannon Zhao (16):
  tools/libxl: Add an unified configuration option for ACPI
  libxl/arm: prepare for constructing ACPI tables
  libxl/arm: Generate static ACPI DSDT table
  libxl/arm: Estimate the size of ACPI tables
  libxl/arm: Construct ACPI RSDP table
  libxl/arm: Construct ACPI XSDT table
  libxl/arm: Construct ACPI GTDT table
  libxl/arm: Factor MPIDR computing codes out as a helper
  libxl/arm: Construct ACPI MADT table
  libxl/arm: Construct ACPI FADT table
  libxl/arm: Construct ACPI DSDT table
  libxl/arm: Factor finalise_one_memory_node as a gerneric function
  libxl/arm: Add ACPI module
  public/hvm/params.h: Add macros for HVM_PARAM_CALLBACK_TYPE_PPI
  libxl/arm: Initialize domain param HVM_PARAM_CALLBACK_IRQ
  libxl/arm: Add the size of ACPI tables to maxmem

 docs/man/xl.cfg.pod.5.in   |   1 +
 docs/misc/arm/device-tree/acpi.txt |  24 +++
 tools/configure.ac |   2 +-
 tools/libacpi/Makefile |  13 +-
 tools/libacpi/mk_dsdt.c|  27 ++-
 tools/libxl/Makefile   |  10 +
 tools/libxl/libxl_arch.h   |   6 +-
 tools/libxl/libxl_arm.c| 101 +++--
 tools/libxl/libxl_arm.h|  48 +
 tools/libxl/libxl_arm_acpi.c   | 409 +
 tools/libxl/libxl_arm_no_acpi.c|  40 
 tools/libxl/libxl_create.c |   4 +-
 tools/libxl/libxl_dm.c |   4 +-
 tools/libxl/libxl_dom.c|   2 +-
 tools/libxl/libxl_internal.h   |   6 +
 tools/libxl/libxl_types.idl|   4 +
 tools/libxl/libxl_x86.c|   8 +-
 tools/libxl/xl_cmdimpl.c   |   2 +-
 xen/arch/arm/domain.c  |   1 +
 xen/arch/arm/domain_build.c|   8 +-
 xen/arch/x86/hvm/irq.c |   2 +-
 xen/include/public/arch-arm.h  |   7 +
 xen/include/public/hvm/params.h|   3 +
 23 files changed, 705 insertions(+), 27 deletions(-)
 create mode 100644 docs/misc/arm/device-tree/acpi.txt
 create mode 100644 tools/libxl/libxl_arm.h
 create mode 100644 tools/libxl/libxl_arm_acpi.c
 create mode 100644 tools/libxl/libxl_arm_no_acpi.c

-- 
2.0.4



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

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

[Shannon Zhao]

From: Shannon Zhao 

Estimate the size of ACPI tables and reserve a memory map space for ACPI
tables.

Signed-off-by: Shannon Zhao 
---
 tools/libxl/libxl_arm_acpi.c | 98 
 1 file changed, 98 insertions(+)

diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
index 0851411..b91f3f6 100644
--- a/tools/libxl/libxl_arm_acpi.c
+++ b/tools/libxl/libxl_arm_acpi.c
@@ -34,12 +34,108 @@ extern const unsigned char dsdt_anycpu_arm[];
 _hidden
 extern const int dsdt_anycpu_arm_len;
 
+enum {
+RSDP,
+XSDT,
+GTDT,
+MADT,
+FADT,
+DSDT,
+NUMS,
+};
+
+struct acpitable {
+uint64_t addr;
+size_t size;
+};
+
+static int libxl__estimate_madt_size(libxl__gc *gc,
+ libxl_domain_build_info *info,
+ xc_domain_configuration_t *xc_config)
+{
+int rc;
+
+switch (xc_config->gic_version) {
+case XEN_DOMCTL_CONFIG_GIC_V2:
+rc = sizeof(struct acpi_table_madt) +
+ sizeof(struct acpi_madt_generic_interrupt) * info->max_vcpus +
+ sizeof(struct acpi_madt_generic_distributor);
+break;
+case XEN_DOMCTL_CONFIG_GIC_V3:
+rc = sizeof(struct acpi_table_madt) +
+ sizeof(struct acpi_madt_generic_interrupt) * info->max_vcpus +
+ sizeof(struct acpi_madt_generic_distributor) +
+ sizeof(struct acpi_madt_generic_redistributor);
+break;
+default:
+LOG(ERROR, "Unknown GIC version");
+rc = ERROR_FAIL;
+break;
+}
+
+return rc;
+}
+
+static int libxl__estimate_acpi_size(libxl__gc *gc,
+ libxl_domain_build_info *info,
+ struct xc_dom_image *dom,
+ xc_domain_configuration_t *xc_config,
+ struct acpitable acpitables[])
+{
+int rc;
+
+acpitables[RSDP].addr = GUEST_ACPI_BASE;
+acpitables[RSDP].size = sizeof(struct acpi_table_rsdp);
+dom->acpi_modules[0].length += ROUNDUP(acpitables[RSDP].size, 3);
+
+acpitables[XSDT].addr = GUEST_ACPI_BASE + dom->acpi_modules[0].length;
+/*
+ * Currently only 3 tables(GTDT, FADT, MADT) are pointed by XSDT. Alloc
+ * entries for them.
+ */
+acpitables[XSDT].size = sizeof(struct acpi_table_xsdt) +
+sizeof(uint64_t) * 2;
+dom->acpi_modules[0].length += ROUNDUP(acpitables[XSDT].size, 3);
+
+acpitables[GTDT].addr = GUEST_ACPI_BASE + dom->acpi_modules[0].length;
+acpitables[GTDT].size = sizeof(struct acpi_table_gtdt);
+dom->acpi_modules[0].length += ROUNDUP(acpitables[GTDT].size, 3);
+
+acpitables[MADT].addr = GUEST_ACPI_BASE + dom->acpi_modules[0].length;
+
+rc = libxl__estimate_madt_size(gc, info, xc_config);
+if (rc < 0)
+goto out;
+
+acpitables[MADT].size = rc;
+dom->acpi_modules[0].length += ROUNDUP(acpitables[MADT].size, 3);
+
+acpitables[FADT].addr = GUEST_ACPI_BASE + dom->acpi_modules[0].length;
+acpitables[FADT].size = sizeof(struct acpi_table_fadt);
+dom->acpi_modules[0].length += ROUNDUP(acpitables[FADT].size, 3);
+
+acpitables[DSDT].addr = GUEST_ACPI_BASE + dom->acpi_modules[0].length;
+acpitables[DSDT].size = dsdt_anycpu_arm_len;
+dom->acpi_modules[0].length += ROUNDUP(acpitables[DSDT].size, 3);
+
+assert(dom->acpi_modules[0].length <= GUEST_ACPI_SIZE);
+dom->acpi_modules[0].data = libxl__zalloc(gc, dom->acpi_modules[0].length);
+
+rc = 0;
+out:
+return rc;
+}
+
 int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
 libxl__domain_build_state *state,
 struct xc_dom_image *dom)
 {
 const libxl_version_info *vers;
 int rc = 0;
+struct acpitable acpitables[NUMS];
+
+/* convenience aliases */
+xc_domain_configuration_t *xc_config = >config;
 
 vers = libxl_get_version_info(CTX);
 if (vers == NULL) {
@@ -54,6 +150,8 @@ int libxl__prepare_acpi(libxl__gc *gc, 
libxl_domain_build_info *info,
 dom->acpi_modules[0].length = 0;
 dom->acpi_modules[0].guest_addr_out = GUEST_ACPI_BASE;
 
+rc = libxl__estimate_acpi_size(gc, info, dom, xc_config, acpitables);
+
 out:
 return rc;
 }
-- 
2.0.4



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

[Xen-devel] [PATCH v5 02/16] libxl/arm: prepare for constructing ACPI tables

[Shannon Zhao]

From: Shannon Zhao 

It only constructs the ACPI tables for 64-bit ARM DomU when user enables
acpi because 32-bit DomU doesn't support ACPI. And the generation codes
are only built for 64-bit toolstack.

Signed-off-by: Shannon Zhao 
---
 tools/libxl/Makefile|  7 +
 tools/libxl/libxl_arm.c | 24 +++-
 tools/libxl/libxl_arm.h | 33 ++
 tools/libxl/libxl_arm_acpi.c| 62 +
 tools/libxl/libxl_arm_no_acpi.c | 34 ++
 xen/include/public/arch-arm.h   |  4 +++
 6 files changed, 163 insertions(+), 1 deletion(-)
 create mode 100644 tools/libxl/libxl_arm.h
 create mode 100644 tools/libxl/libxl_arm_acpi.c
 create mode 100644 tools/libxl/libxl_arm_no_acpi.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index a148374..afd93de 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -90,6 +90,13 @@ acpi:
 
 LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o libxl_psr.o 
libxl_x86_acpi.o
 LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o libxl_arm.o libxl_libfdt_compat.o
+ifeq ($(CONFIG_ARM_64),y)
+LIBXL_OBJS-y += libxl_arm_acpi.o
+libxl_arm_acpi.o: libxl_arm_acpi.c
+   $(CC) -c $(CFLAGS) -I../../xen/include/ -o $@ libxl_arm_acpi.c
+else
+LIBXL_OBJS-$(CONFIG_ARM) += libxl_arm_no_acpi.o
+endif
 
 ifeq ($(CONFIG_NetBSD),y)
 LIBXL_OBJS-y += libxl_netbsd.o
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index 8ec5cd5..333c9a1 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -1,6 +1,7 @@
 #include "libxl_internal.h"
 #include "libxl_arch.h"
 #include "libxl_libfdt_compat.h"
+#include "libxl_arm.h"
 
 #include 
 #include 
@@ -885,8 +886,29 @@ int libxl__arch_domain_init_hw_description(libxl__gc *gc,
libxl__domain_build_state *state,
struct xc_dom_image *dom)
 {
+int rc;
+
 assert(info->type == LIBXL_DOMAIN_TYPE_PV);
-return libxl__prepare_dtb(gc, info, state, dom);
+rc = libxl__prepare_dtb(gc, info, state, dom);
+if (rc) goto out;
+
+if (!libxl_defbool_val(info->acpi)) {
+LOG(DEBUG, "Generating ACPI tables is disabled by user.");
+rc = 0;
+goto out;
+}
+
+if (strcmp(dom->guest_type, "xen-3.0-aarch64")) {
+/* ACPI is only supported for 64-bit guest currently. */
+LOG(ERROR, "Can not enable libxl option 'acpi' for %s", 
dom->guest_type);
+rc = ERROR_FAIL;
+goto out;
+}
+
+rc = libxl__prepare_acpi(gc, info, state, dom);
+
+out:
+return rc;
 }
 
 static void finalise_one_memory_node(libxl__gc *gc, void *fdt,
diff --git a/tools/libxl/libxl_arm.h b/tools/libxl/libxl_arm.h
new file mode 100644
index 000..1c01177
--- /dev/null
+++ b/tools/libxl/libxl_arm.h
@@ -0,0 +1,33 @@
+/*
+ * Copyright (C) 2016  Linaro Ltd.
+ *
+ * Author: Shannon Zhao 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * 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 Lesser General Public License for more details.
+ */
+
+#include "libxl_internal.h"
+#include "libxl_arch.h"
+
+#include 
+
+_hidden
+int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
+libxl__domain_build_state *state,
+struct xc_dom_image *dom);
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
new file mode 100644
index 000..810aed8
--- /dev/null
+++ b/tools/libxl/libxl_arm_acpi.c
@@ -0,0 +1,62 @@
+/*
+ * ARM DomU ACPI generation
+ *
+ * Copyright (C) 2016  Linaro Ltd.
+ *
+ * Author: Shannon Zhao 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * 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 Lesser General Public License for more details.
+ */
+
+#include "libxl_arm.h"
+
+#include 
+
+/* Below typedefs are useful for the headers under acpi/ */
+typedef uint8_t u8;
+typedef uint16_t u16;
+typedef uint32_t u32;
+typedef uint64_t u64;
+
+#include 
+#include 
+
+int 

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

[Shannon Zhao]

From: Shannon Zhao 

The guest kernel will get the event channel interrupt information via
domain param HVM_PARAM_CALLBACK_IRQ. Initialize it here.

Signed-off-by: Shannon Zhao 
---
 tools/libxl/libxl_arm.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index 6f0bc70..e73d65e 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -900,8 +900,21 @@ int libxl__arch_domain_init_hw_description(libxl__gc *gc,
struct xc_dom_image *dom)
 {
 int rc;
+uint64_t val;
 
 assert(info->type == LIBXL_DOMAIN_TYPE_PV);
+
+/* Set the value of domain param HVM_PARAM_CALLBACK_IRQ. */
+val = (uint64_t)HVM_PARAM_CALLBACK_TYPE_PPI << 
HVM_PARAM_CALLBACK_IRQ_TYPE_SHIFT;
+/* Active-low level-sensitive  */
+val |= (HVM_PARAM_CALLBACK_TYPE_PPI_FLAG_LOW_LEVEL <<
+HVM_PARAM_CALLBACK_TYPE_PPI_FLAG_SHIFT);
+val |= GUEST_EVTCHN_PPI;
+rc = xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_CALLBACK_IRQ,
+  val);
+if (rc)
+return rc;
+
 rc = libxl__prepare_dtb(gc, info, state, dom);
 if (rc) goto out;
 
-- 
2.0.4



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

[Xen-devel] [PATCH v5 01/16] tools/libxl: Add an unified configuration option for ACPI

[Shannon Zhao]

From: Shannon Zhao 

Since the existing configuration option "u.hvm.acpi" is x86 specific and
we want to reuse it on ARM as well, add a unified option "acpi" for
x86 and ARM, and for ARM it's disabled by default.

Signed-off-by: Shannon Zhao 
---
 docs/man/xl.cfg.pod.5.in | 1 +
 tools/libxl/libxl_arch.h | 4 
 tools/libxl/libxl_arm.c  | 6 ++
 tools/libxl/libxl_create.c   | 4 +++-
 tools/libxl/libxl_dm.c   | 4 ++--
 tools/libxl/libxl_internal.h | 6 ++
 tools/libxl/libxl_types.idl  | 4 
 tools/libxl/libxl_x86.c  | 6 ++
 tools/libxl/xl_cmdimpl.c | 2 +-
 9 files changed, 33 insertions(+), 4 deletions(-)

diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg.pod.5.in
index a685b83..9242e3d 100644
--- a/docs/man/xl.cfg.pod.5.in
+++ b/docs/man/xl.cfg.pod.5.in
@@ -1237,6 +1237,7 @@ the virtual firmware to the guest Operating System. ACPI 
is required
 by most modern guest Operating Systems. This option is enabled by
 default and usually you should omit it. However it may be necessary to
 disable ACPI for compatibility with some guest Operating Systems.
+This option is true for x86 while it's false for ARM by default.
 
 =item 

[Xen-devel] [PATCH v5 03/16] libxl/arm: Generate static ACPI DSDT table

[Shannon Zhao]

From: Shannon Zhao 

It uses static DSDT table like the way x86 uses. Currently the DSDT
table only contains processor device objects and it generates the
maximal objects which so far is 128.

While the GUEST_MAX_VCPUS is defined under __XEN__ or __XEN_TOOLS__, it
needs to add -D__XEN_TOOLS__ to compile mk_dsdt.c.

Also only check iasl for aarch64 in configure since ACPI on ARM32 is not
supported.

Signed-off-by: Shannon Zhao 
---
Note: this patch needs to be rebased on Boris's v3 patchset for only 
generating dsdt_anycpu_arm.c for ARM64.
---
 tools/configure.ac|  2 +-
 tools/libacpi/Makefile| 13 -
 tools/libacpi/mk_dsdt.c   | 27 ++-
 tools/libxl/Makefile  |  5 -
 tools/libxl/libxl_arm_acpi.c  |  5 +
 xen/arch/arm/domain.c |  1 +
 xen/include/public/arch-arm.h |  3 +++
 7 files changed, 52 insertions(+), 4 deletions(-)

diff --git a/tools/configure.ac b/tools/configure.ac
index 0229d44..b4e0c80 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -335,7 +335,7 @@ dnl "host" here means the platform on which the hypervisor 
and tools is
 dnl going to run, not the platform on which we are building (known as
 dnl "build" in gnu speak).
 case "$host_cpu" in
-i[[3456]]86|x86_64)
+i[[3456]]86|x86_64|aarch64)
 AX_PATH_PROG_OR_FAIL([IASL], [iasl])
 ;;
 esac
diff --git a/tools/libacpi/Makefile b/tools/libacpi/Makefile
index d741ac5..b1965cc 100644
--- a/tools/libacpi/Makefile
+++ b/tools/libacpi/Makefile
@@ -19,6 +19,7 @@ MK_DSDT = $(ACPI_BUILD_DIR)/mk_dsdt
 
 # Sources to be generated
 C_SRC = $(addprefix $(ACPI_BUILD_DIR)/, dsdt_anycpu.c dsdt_15cpu.c  
dsdt_anycpu_qemu_xen.c dsdt_pvh.c)
+C_SRC += $(ACPI_BUILD_DIR)/dsdt_anycpu_arm.c
 H_SRC = $(addprefix $(ACPI_BUILD_DIR)/, ssdt_s3.h ssdt_s4.h ssdt_pm.h 
ssdt_tpm.h)
 
 vpath iasl $(PATH)
@@ -32,7 +33,7 @@ $(H_SRC): $(ACPI_BUILD_DIR)/%.h: %.asl iasl
cd $(CURDIR)
 
 $(MK_DSDT): mk_dsdt.c
-   $(HOSTCC) $(HOSTCFLAGS) $(CFLAGS_xeninclude) -o $@ mk_dsdt.c
+   $(HOSTCC) $(HOSTCFLAGS) $(CFLAGS_xeninclude) -D__XEN_TOOLS__ -o $@ 
mk_dsdt.c
 
 $(ACPI_BUILD_DIR)/dsdt_anycpu_qemu_xen.asl: dsdt.asl dsdt_acpi_info.asl 
$(MK_DSDT)
awk 'NR > 1 {print s} {s=$$0}' $< > $@
@@ -62,6 +63,16 @@ $(ACPI_BUILD_DIR)/dsdt_pvh.c: iasl 
$(ACPI_BUILD_DIR)/dsdt_pvh.asl
echo "int dsdt_pvh_len=sizeof(dsdt_pvh);" >>$@
rm -f $(ACPI_BUILD_DIR)/$*.aml $(ACPI_BUILD_DIR)/$*.hex
 
+$(ACPI_BUILD_DIR)/dsdt_anycpu_arm.asl: $(MK_DSDT)
+   printf "DefinitionBlock (\"DSDT.aml\", \"DSDT\", 3, \"Xen\", \"ARM\", 
1)\n{" > $@
+   $(MK_DSDT) --debug=$(debug) >> $@
+
+$(ACPI_BUILD_DIR)/dsdt_anycpu_arm.c: iasl $(ACPI_BUILD_DIR)/dsdt_anycpu_arm.asl
+   iasl -vs -p $(ACPI_BUILD_DIR)/$* -tc 
$(ACPI_BUILD_DIR)/dsdt_anycpu_arm.asl
+   sed -e 's/AmlCode/dsdt_anycpu_arm/g' $(ACPI_BUILD_DIR)/$*.hex >$@
+   echo "int dsdt_anycpu_arm_len=sizeof(dsdt_anycpu_arm);" >>$@
+   rm -f $(ACPI_BUILD_DIR)/$*.aml $(ACPI_BUILD_DIR)/$*.hex
+
 iasl:
@echo
@echo "ACPI ASL compiler (iasl) is needed"
diff --git a/tools/libacpi/mk_dsdt.c b/tools/libacpi/mk_dsdt.c
index 7d76784..a56e0f0 100644
--- a/tools/libacpi/mk_dsdt.c
+++ b/tools/libacpi/mk_dsdt.c
@@ -17,7 +17,11 @@
 #include 
 #include 
 #include 
+#if defined(__i386__) || defined(__x86_64__)
 #include 
+#elif defined(__aarch64__)
+#include 
+#endif
 
 static unsigned int indent_level;
 static bool debug = false;
@@ -104,10 +108,16 @@ static struct option options[] = {
 
 int main(int argc, char **argv)
 {
-unsigned int slot, dev, intx, link, cpu, max_cpus = HVM_MAX_VCPUS;
+unsigned int slot, dev, intx, link, cpu, max_cpus;
 dm_version dm_version = QEMU_XEN_TRADITIONAL;
 bool no_dm = 0;
 
+#if defined(__i386__) || defined(__x86_64__)
+max_cpus = HVM_MAX_VCPUS;
+#elif defined(__aarch64__)
+max_cpus = GUEST_MAX_VCPUS;
+#endif
+
 for ( ; ; )
 {
 int opt = getopt_long(argc, argv, "", options, NULL);
@@ -161,6 +171,7 @@ int main(int argc, char **argv)
 / Processor start /
 push_block("Scope", "\\_SB");
 
+#if defined(__i386__) || defined(__x86_64__)
 /* MADT checksum */
 stmt("OperationRegion", "MSUM, SystemMemory, \\_SB.MSUA, 1");
 push_block("Field", "MSUM, ByteAcc, NoLock, Preserve");
@@ -174,6 +185,7 @@ int main(int argc, char **argv)
 pop_block();
 stmt("Return", "Buffer() {0, 8, 0xff, 0xff, 0, 0, 0, 0}");
 pop_block();
+#endif
 
 /* Define processor objects and control methods. */
 for ( cpu = 0; cpu < max_cpus; cpu++)
@@ -182,6 +194,11 @@ int main(int argc, char **argv)
 
 stmt("Name", "_HID, \"ACPI0007\"");
 
+stmt("Name", "_UID, %d", cpu);
+#if defined(__aarch64__)
+pop_block();
+continue;
+#endif
 /* Name this processor's MADT LAPIC descriptor. */
 stmt("OperationRegion", 
  "MATR, SystemMemory, Add(\\_SB.MAPA, %d), 

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

[Shannon Zhao]

From: Shannon Zhao 

According to the GIC version, construct the MADT table.

Signed-off-by: Shannon Zhao 
---
 tools/libxl/libxl_arm_acpi.c | 84 
 1 file changed, 84 insertions(+)

diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
index ab49d57..d3358b3 100644
--- a/tools/libxl/libxl_arm_acpi.c
+++ b/tools/libxl/libxl_arm_acpi.c
@@ -227,6 +227,89 @@ static void make_acpi_gtdt(libxl__gc *gc, struct 
xc_dom_image *dom,
acpitables[GTDT].size);
 }
 
+static void make_acpi_madt_gicc(void *table, int nr_cpus, uint64_t gicc_base)
+{
+int i;
+struct acpi_madt_generic_interrupt *gicc = table;
+
+for (i = 0; i < nr_cpus; i++) {
+gicc->header.type = ACPI_MADT_TYPE_GENERIC_INTERRUPT;
+gicc->header.length = sizeof(*gicc);
+gicc->base_address = gicc_base;
+gicc->cpu_interface_number = i;
+gicc->arm_mpidr = libxl__compute_mpdir(i);
+gicc->uid = i;
+gicc->flags = ACPI_MADT_ENABLED;
+gicc++;
+}
+}
+
+static void make_acpi_madt_gicd(void *table, uint64_t gicd_base,
+uint8_t gic_version)
+{
+struct acpi_madt_generic_distributor *gicd = table;
+
+gicd->header.type = ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR;
+gicd->header.length = sizeof(*gicd);
+gicd->base_address = gicd_base;
+/* This version field has no meaning before ACPI 5.1 errata. */
+gicd->version = gic_version;
+}
+
+static void make_acpi_madt_gicr(void *table, uint64_t gicr_base,
+uint64_t gicr_size)
+{
+struct acpi_madt_generic_redistributor *gicr = table;
+
+gicr->header.type = ACPI_MADT_TYPE_GENERIC_REDISTRIBUTOR;
+gicr->header.length = sizeof(*gicr);
+gicr->base_address = gicr_base;
+gicr->length = gicr_size;
+}
+
+static int make_acpi_madt(libxl__gc *gc, struct xc_dom_image *dom, int nr_cpus,
+  xc_domain_configuration_t *xc_config,
+  struct acpitable acpitables[])
+{
+uint64_t offset = acpitables[MADT].addr - GUEST_ACPI_BASE;
+void *table = dom->acpi_modules[0].data + offset;
+struct acpi_table_madt *madt = table;
+int rc = 0;
+
+switch (xc_config->gic_version) {
+case XEN_DOMCTL_CONFIG_GIC_V2:
+table += sizeof(struct acpi_table_madt);
+make_acpi_madt_gicc(table, nr_cpus, GUEST_GICC_BASE);
+
+table += sizeof(struct acpi_madt_generic_interrupt) * nr_cpus;
+make_acpi_madt_gicd(table, GUEST_GICD_BASE, ACPI_MADT_GIC_VERSION_V2);
+break;
+case XEN_DOMCTL_CONFIG_GIC_V3:
+table += sizeof(struct acpi_table_madt);
+make_acpi_madt_gicc(table, nr_cpus, 0);
+
+table += sizeof(struct acpi_madt_generic_interrupt) * nr_cpus;
+make_acpi_madt_gicd(table, GUEST_GICV3_GICD_BASE,
+ACPI_MADT_GIC_VERSION_V3);
+
+table += sizeof(struct acpi_madt_generic_distributor);
+make_acpi_madt_gicr(table, GUEST_GICV3_GICR0_BASE,
+GUEST_GICV3_GICR0_SIZE);
+break;
+default:
+LOG(ERROR, "Unknown GIC version");
+rc = ERROR_FAIL;
+goto out;
+}
+
+make_acpi_header(>header, "APIC", acpitables[MADT].size, 3);
+calculate_checksum(madt, offsetof(struct acpi_table_header, checksum),
+   acpitables[MADT].size);
+
+out:
+return rc;
+}
+
 int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
 libxl__domain_build_state *state,
 struct xc_dom_image *dom)
@@ -258,6 +341,7 @@ int libxl__prepare_acpi(libxl__gc *gc, 
libxl_domain_build_info *info,
 make_acpi_rsdp(gc, dom, acpitables);
 make_acpi_xsdt(gc, dom, acpitables);
 make_acpi_gtdt(gc, dom, acpitables);
+rc = make_acpi_madt(gc, dom, info->max_vcpus, xc_config, acpitables);
 
 out:
 return rc;
-- 
2.0.4



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

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

[Shannon Zhao]

From: Shannon Zhao 

Signed-off-by: Shannon Zhao 
---
 tools/libxl/libxl_arm_acpi.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
index d3358b3..407f9d5 100644
--- a/tools/libxl/libxl_arm_acpi.c
+++ b/tools/libxl/libxl_arm_acpi.c
@@ -310,6 +310,25 @@ out:
 return rc;
 }
 
+static void make_acpi_fadt(libxl__gc *gc, struct xc_dom_image *dom,
+   struct acpitable acpitables[])
+{
+uint64_t offset = acpitables[FADT].addr - GUEST_ACPI_BASE;
+struct acpi_table_fadt *fadt = (void *)dom->acpi_modules[0].data + offset;
+
+/* Hardware Reduced = 1 and use PSCI 0.2+ and with HVC */
+fadt->flags = ACPI_FADT_HW_REDUCED;
+fadt->arm_boot_flags = ACPI_FADT_PSCI_COMPLIANT | ACPI_FADT_PSCI_USE_HVC;
+
+/* ACPI v5.1 (fadt->revision.fadt->minor_revision) */
+fadt->minor_revision = 0x1;
+fadt->dsdt = acpitables[DSDT].addr;
+
+make_acpi_header(>header, "FACP", acpitables[FADT].size, 5);
+calculate_checksum(fadt, offsetof(struct acpi_table_header, checksum),
+   acpitables[FADT].size);
+}
+
 int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
 libxl__domain_build_state *state,
 struct xc_dom_image *dom)
@@ -342,6 +361,10 @@ int libxl__prepare_acpi(libxl__gc *gc, 
libxl_domain_build_info *info,
 make_acpi_xsdt(gc, dom, acpitables);
 make_acpi_gtdt(gc, dom, acpitables);
 rc = make_acpi_madt(gc, dom, info->max_vcpus, xc_config, acpitables);
+if (rc)
+goto out;
+
+make_acpi_fadt(gc, dom, acpitables);
 
 out:
 return rc;
-- 
2.0.4



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

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

[Shannon Zhao]

From: Shannon Zhao 

Add the ARM Multiboot module for ACPI, so UEFI or DomU can get the base
address of ACPI tables from it.

Signed-off-by: Shannon Zhao 
Acked-by: Julien Grall 
---
 docs/misc/arm/device-tree/acpi.txt | 24 
 tools/libxl/libxl_arm.c| 24 
 2 files changed, 48 insertions(+)
 create mode 100644 docs/misc/arm/device-tree/acpi.txt

diff --git a/docs/misc/arm/device-tree/acpi.txt 
b/docs/misc/arm/device-tree/acpi.txt
new file mode 100644
index 000..3e70157
--- /dev/null
+++ b/docs/misc/arm/device-tree/acpi.txt
@@ -0,0 +1,24 @@
+DomU ACPI module
+
+
+Xen toolstack passes the domU ACPI tables via a reference in the /chosen node 
of
+the device tree.
+
+Each node contains the following properties:
+
+- compatible
+
+   "xen,guest-acpi", "multiboot,module"
+
+- reg
+
+   Specifies the physical address and the length of the module.
+   RSDP table is always located at the beginning of this region.
+
+Examples
+
+
+   module@0x2000 {
+   compatible = "xen,guest-acpi", "multiboot,module";
+   reg = <0x2000 0x1234>;
+   };
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index f7f2c60..6f0bc70 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -285,6 +285,25 @@ static int make_chosen_node(libxl__gc *gc, void *fdt, bool 
ramdisk,
 if (res) return res;
 }
 
+if (libxl_defbool_val(info->acpi)) {
+const uint64_t acpi_base = GUEST_ACPI_BASE;
+const char *name = GCSPRINTF("module@%"PRIx64, acpi_base);
+
+res = fdt_begin_node(fdt, name);
+if (res) return res;
+
+res = fdt_property_compat(gc, fdt, 2, "xen,guest-acpi",
+  "multiboot,module");
+if (res) return res;
+
+res = fdt_property_regs(gc, fdt, ROOT_ADDRESS_CELLS, ROOT_SIZE_CELLS,
+1, 0, 0);
+if (res) return res;
+
+res = fdt_end_node(fdt);
+if (res) return res;
+}
+
 res = fdt_end_node(fdt);
 if (res) return res;
 
@@ -975,6 +994,11 @@ int libxl__arch_domain_finalise_hw_description(libxl__gc 
*gc,
 finalise_one_node(gc, fdt, "/memory", bankbase[i], size);
 }
 
+if (dom->acpi_modules[0].data) {
+finalise_one_node(gc, fdt, "/chosen/module", GUEST_ACPI_BASE,
+  dom->acpi_modules[0].length);
+}
+
 debug_dump_fdt(gc, fdt);
 
 return 0;
-- 
2.0.4



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

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

[Shannon Zhao]

From: Shannon Zhao 

Rename finalise_one_memory_node to finalise_one_node and pass the node
name via function parameter.

This is useful for adding ACPI module which will be added by a later
patch.

Signed-off-by: Shannon Zhao 
Acked-by: Julien Grall 
---
 tools/libxl/libxl_arm.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index 2a4577c..f7f2c60 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -905,11 +905,11 @@ out:
 return rc;
 }
 
-static void finalise_one_memory_node(libxl__gc *gc, void *fdt,
- uint64_t base, uint64_t size)
+static void finalise_one_node(libxl__gc *gc, void *fdt, const char *uname,
+  uint64_t base, uint64_t size)
 {
 int node, res;
-const char *name = GCSPRINTF("/memory@%"PRIx64, base);
+const char *name = GCSPRINTF("%s@%"PRIx64, uname, base);
 
 node = fdt_path_offset(fdt, name);
 assert(node > 0);
@@ -972,7 +972,7 @@ int libxl__arch_domain_finalise_hw_description(libxl__gc 
*gc,
 for (i = 0; i < GUEST_RAM_BANKS; i++) {
 const uint64_t size = (uint64_t)dom->rambank_size[i] << XC_PAGE_SHIFT;
 
-finalise_one_memory_node(gc, fdt, bankbase[i], size);
+finalise_one_node(gc, fdt, "/memory", bankbase[i], size);
 }
 
 debug_dump_fdt(gc, fdt);
-- 
2.0.4



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

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

[Shannon Zhao]

From: Shannon Zhao 

Copy the static DSDT table into ACPI blob.

Signed-off-by: Shannon Zhao 
---
 tools/libxl/libxl_arm_acpi.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
index 407f9d5..30e4d66 100644
--- a/tools/libxl/libxl_arm_acpi.c
+++ b/tools/libxl/libxl_arm_acpi.c
@@ -329,6 +329,15 @@ static void make_acpi_fadt(libxl__gc *gc, struct 
xc_dom_image *dom,
acpitables[FADT].size);
 }
 
+static void make_acpi_dsdt(libxl__gc *gc, struct xc_dom_image *dom,
+   struct acpitable acpitables[])
+{
+uint64_t offset = acpitables[DSDT].addr - GUEST_ACPI_BASE;
+void *dsdt = dom->acpi_modules[0].data + offset;
+
+memcpy(dsdt, dsdt_anycpu_arm, dsdt_anycpu_arm_len);
+}
+
 int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
 libxl__domain_build_state *state,
 struct xc_dom_image *dom)
@@ -365,6 +374,7 @@ int libxl__prepare_acpi(libxl__gc *gc, 
libxl_domain_build_info *info,
 goto out;
 
 make_acpi_fadt(gc, dom, acpitables);
+make_acpi_dsdt(gc, dom, acpitables);
 
 out:
 return rc;
-- 
2.0.4



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

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

[Shannon Zhao]

From: Shannon Zhao 

Factor MPIDR computing codes out as a helper, so it could be shared
between DT and ACPI.

Signed-off-by: Shannon Zhao 
Acked-by: Julien Grall 
---
 tools/libxl/libxl_arm.c |  8 +---
 tools/libxl/libxl_arm.h | 11 +++
 2 files changed, 12 insertions(+), 7 deletions(-)

diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index 333c9a1..2a4577c 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -309,13 +309,7 @@ static int make_cpus_node(libxl__gc *gc, void *fdt, int 
nr_cpus,
 for (i = 0; i < nr_cpus; i++) {
 const char *name;
 
-/*
- * According to ARM CPUs bindings, the reg field should match
- * the MPIDR's affinity bits. We will use AFF0 and AFF1 when
- * constructing the reg value of the guest at the moment, for it
- * is enough for the current max vcpu number.
- */
-mpidr_aff = (i & 0x0f) | (((i >> 4) & 0xff) << 8);
+mpidr_aff = libxl__compute_mpdir(i);
 name = GCSPRINTF("cpu@%"PRIx64, mpidr_aff);
 
 res = fdt_begin_node(fdt, name);
diff --git a/tools/libxl/libxl_arm.h b/tools/libxl/libxl_arm.h
index 1c01177..a91ff93 100644
--- a/tools/libxl/libxl_arm.h
+++ b/tools/libxl/libxl_arm.h
@@ -24,6 +24,17 @@ int libxl__prepare_acpi(libxl__gc *gc, 
libxl_domain_build_info *info,
 libxl__domain_build_state *state,
 struct xc_dom_image *dom);
 
+static inline uint64_t libxl__compute_mpdir(unsigned int cpuid)
+{
+/*
+ * According to ARM CPUs bindings, the reg field should match
+ * the MPIDR's affinity bits. We will use AFF0 and AFF1 when
+ * constructing the reg value of the guest at the moment, for it
+ * is enough for the current max vcpu number.
+ */
+return (cpuid & 0x0f) | (((cpuid >> 4) & 0xff) << 8);
+}
+
 /*
  * Local variables:
  * mode: C
-- 
2.0.4



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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl  14 guest-stop   fail REGR. vs. 100674

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail  like 100667
 build-amd64-rumpuserxen   6 xen-buildfail  like 100674
 build-i386-rumpuserxen6 xen-buildfail  like 100674
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100674
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100674
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 100674
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100674
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 100674

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-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  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-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-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  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-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 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

version targeted for testing:
 xen  a4f39a6450abe5207cb33f877b4b6cd5db8a6cca
baseline version:
 xen  4b314c89be24c26abfad47900f806cebeafc805e

Last test of basis   100674  2016-08-31 08:49:52 Z1 days
Failing since100681  2016-08-31 18:14:20 Z1 days4 attempts
Testing same since   100706  2016-09-01 19:14:21 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Feng Wu 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Wei Liu 

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

[Xen-devel] [qemu-upstream-4.7-testing test] 100708: regressions - FAIL

[osstest service owner]

flight 100708 qemu-upstream-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100708/

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail REGR. vs. 100704

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

version targeted for testing:
 qemuue927b5f5a809f07b73b063831527c8a87f053933
baseline version:
 qemuu44a072f0de0d57c95c2212bbce0232b7b74f

Last test of basis   100704  2016-09-01 16:43:31 Z0 days
Testing same since   100708  2016-09-01 21:16:11 Z0 days1 attempts


People who touched revisions under test:
  P J P 
  Stefan Hajnoczi 
  Stefano Stabellini 

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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 3ef3209d3028b77af9f56f183370e7b67cd7c849
baseline version:
 ovmf b10d5ddc0385f39d2c2c62843710b7609a4ca169

Last test of basis   100703  2016-09-01 16:15:14 Z0 days
Testing same since   100709  2016-09-01 21:16:11 Z0 days1 attempts


People who touched revisions under test:
  Laszlo Ersek 

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



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=3ef3209d3028b77af9f56f183370e7b67cd7c849
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
3ef3209d3028b77af9f56f183370e7b67cd7c849
+ branch=ovmf
+ revision=3ef3209d3028b77af9f56f183370e7b67cd7c849
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' x3ef3209d3028b77af9f56f183370e7b67cd7c849 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'

Re: [Xen-devel] [PATCH 1/2] xen/x86: Convert to hotplug state machine

[Boris Ostrovsky]

On 08/31/2016 12:15 PM, Sebastian Andrzej Siewior wrote:
> On 2016-08-26 15:37:38 [-0400], Boris Ostrovsky wrote:
>>> If you do find the time, you might manage to rework the code to avoid
>>> using the _nocalls() function. If see this right, you use
>>> xen_setup_vcpu_info_placement() for the init in the first place. This
>>> uses for_each_possible_cpu macro. The cpuhp_setup_state() function would
>>> perform the init for all CPUs before they come up.
>> I am not sure I see what this would buy us.
>>
>> Besides, cpuhp_setup_state() uses for_each_present_cpu().
> Correct. So you would avoid running the init code on CPUs which are
> within the for_each_possible_cpu() set but not in for_each_present_cpu().
>
> Assuming a NUMA box with two CPUs, 8 cores each gives you 32 CPUs in
> Linux with hyper threading. BIOS may report 240 CPUs as the upper limit
> (possible CPUs) but if you never deploy them you don't need to
> initialize them… Should they be plugged physically then the
> for_each_present_cpu() loop will cover them once they come up.
>

That's not going to help Xen guests: all possible CPUs are brought up
right away and then those that are not in use are unplugged.


-boris

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

Re: [Xen-devel] [PATCH v3 5/6] VT-d: No need to set irq affinity for posted format IRTE

[Wu, Feng]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, September 1, 2016 4:39 PM
> To: Wu, Feng 
> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com;
> george.dun...@eu.citrix.com; Tian, Kevin ; xen-
> de...@lists.xen.org
> Subject: Re: [PATCH v3 5/6] VT-d: No need to set irq affinity for posted 
> format
> IRTE
> 
> >>> On 31.08.16 at 05:56,  wrote:
> > We don't set the affinity for posted format IRTE, since the
> > destination of these interrupts is vCPU and the vCPU affinity
> > is set during vCPU scheduling.
> 
> So is this based on the assumption that after initial setup the function
> would only ever get called for affinity changes? I'm not even sure
> this is the case today, but I don't think we should build in such a
> dependency.

I don't think we have such dependency, as you mentioned below, the
purpose of this patch if to void changing the affinity related bit when
the IRTE is in posted mode.

> 
> Assuming that the main motivation is to avoid ...
> 
> > @@ -637,9 +640,12 @@ static int msi_msg_to_remap_entry(
> >  remap_rte->address_hi = 0;
> >  remap_rte->data = index - i;
> >
> > -memcpy(iremap_entry, _ire, sizeof(struct iremap_entry));
> > -iommu_flush_cache_entry(iremap_entry, sizeof(struct iremap_entry));
> > -iommu_flush_iec_index(iommu, 0, index);
> > +if ( !iremap_entry->remap.p || !iremap_entry->remap.im )
> > +{
> > +memcpy(iremap_entry, _ire, sizeof(struct iremap_entry));
> > +iommu_flush_cache_entry(iremap_entry, sizeof(struct iremap_entry));
> > +iommu_flush_iec_index(iommu, 0, index);
> > +}
> 
> ... the actual updating here, may I suggest that you keep the
> construction of new_ire and modify the if() here to check whether
> nothing except affinity related bits changed? That would also take
> care of certain (older) compiler versions likely warning about new_ire
> potentially being used uninitialized.

Sure, maybe I can keep the construction of new_ire and only add this
if() part, since if we find the IRTE is in posted mode ('IM' is set), we don't
need to copy new_ire to iremap_entry.

Thanks,
Feng 

> 
> Jan


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

Re: [Xen-devel] [PATCH 2/2] xen_platform: SUSE xenlinux unplug for emulated PCI

[Stefano Stabellini]

On Thu, 1 Sep 2016, Konrad Rzeszutek Wilk wrote:
> On Thu, Sep 01, 2016 at 02:11:31PM +0200, Olaf Hering wrote:
> > Implement SUSE specific unplug protocol for emulated PCI devices
> > in PVonHVM guests. Its a simple 'outl(1, (ioaddr + 4));'.
> > This protocol was implemented and used since Xen 3.0.4.
> > It is used in all SUSE/SLES/openSUSE releases up to SLES11SP3 and
> > openSUSE 12.3.
> 
> Should this be documented in the protocol?

Yes, please. The file is docs/misc/hvm-emulated-unplug.markdown in the
Xen repository. Please also document the behavior with SCSI disks, which
is currently missing.


> > 
> > Signed-off-by: Olaf Hering 
> > ---
> >  hw/i386/xen/xen_platform.c | 31 ++-
> >  1 file changed, 30 insertions(+), 1 deletion(-)
> > 
> > diff --git a/hw/i386/xen/xen_platform.c b/hw/i386/xen/xen_platform.c
> > index d94b53c..8802482 100644
> > --- a/hw/i386/xen/xen_platform.c
> > +++ b/hw/i386/xen/xen_platform.c
> > @@ -314,13 +314,42 @@ static void xen_platform_ioport_writeb(void *opaque, 
> > hwaddr addr,
> > uint64_t val, unsigned int size)
> >  {
> >  PCIXenPlatformState *s = opaque;
> > +PCIDevice *pci_dev = PCI_DEVICE(s);
> >  
> >  switch (addr) {
> >  case 0: /* Platform flags */
> >  platform_fixed_ioport_writeb(opaque, 0, (uint32_t)val);
> >  break;
> > +case 4:
> > +if (val == 1) {
> > +/*
> > + * SUSE unplug for Xenlinux
> > + * xen-kmp used this since xen-3.0.4, instead the official 
> > protocol from xen-3.3+
> > + * It did an unconditional "outl(1, (ioaddr + 4));"
> > + * Pre VMDP 1.7 made use of 4 and 8 depending on how VMDP was 
> > configured.
> > + * If VMDP was to control both disk and LAN it would use 4.
> > + * If it controlled just disk or just LAN, it would use 8 
> > below.
> > + */
> > +blk_drain_all();
> > +blk_flush_all();
> > +pci_unplug_disks(pci_dev->bus);
> > +pci_unplug_nics(pci_dev->bus);
> > +}
> > +break;
> >  case 8:
> > -log_writeb(s, (uint32_t)val);
> > +switch (val) {
> > +case 1:
> > +blk_drain_all();
> > +blk_flush_all();
> > +pci_unplug_disks(pci_dev->bus);
> > +break;
> > +case 2:
> > +pci_unplug_nics(pci_dev->bus);
> > +break;
> > +default:
> > +log_writeb(s, (uint32_t)val);
> > +break;
> > +}
> >  break;
> >  default:
> >  break;
> > 
> > ___
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > https://lists.xen.org/xen-devel
> 

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

Re: [Xen-devel] [PATCH v3 4/6] Pause/Unpause the domain before/after assigning PI hooks

[Wu, Feng]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, September 1, 2016 4:30 PM
> To: Wu, Feng 
> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com;
> george.dun...@eu.citrix.com; Tian, Kevin ; xen-
> de...@lists.xen.org
> Subject: Re: [PATCH v3 4/6] Pause/Unpause the domain before/after assigning
> PI hooks
> 
> >>> On 31.08.16 at 05:56,  wrote:
> > --- a/xen/arch/x86/hvm/vmx/vmx.c
> > +++ b/xen/arch/x86/hvm/vmx/vmx.c
> > @@ -219,8 +219,19 @@ void vmx_pi_hooks_assign(struct domain *d)
> >
> >  ASSERT(!d->arch.hvm_domain.vmx.vcpu_block);
> >
> > +/*
> > + * Pausing the domain can make sure the vCPU is not
> > + * running and hence calling the hooks simultaneously
> > + * when deassigning the PI hooks. This makes sure that
> > + * all the appropriate state of PI descriptor is actually
> > + * set up for all vCPus before leaving this function.
> > + */
> > +domain_pause(d);
> > +
> >  d->arch.hvm_domain.vmx.vcpu_block = vmx_vcpu_block;
> >  d->arch.hvm_domain.vmx.pi_do_resume = vmx_pi_do_resume;
> > +
> > +domain_unpause(d);
> >  }
> 
> First of all I'm missing a word on whether the race mentioned in
> the description and comment can actually happen. Device
> (de)assignment should already be pretty much serialized (via
> the domctl lock, and maybe also via the pcidevs one).

The purpose of this patch is to address the race condition that
the _vCPU_ is running while we are installing these hooks. Do you
think this cannot happen?  This patch is trying to fix the issue
described at:
http://www.gossamer-threads.com/lists/xen/devel/433229
Consider that the other two hooks were installed when the VM
is created, seems no such race condition. However, according
to the discussion about patch 1 and patch 2 of series, we need
to install the other two hooks here as well, then the race
condition comes again, so we still need to handle it.

> 
> And then - isn't this overkill? Wouldn't a simple spin lock, taken
> here and in the deassign counterpart, do?
> 
> Or wait - is the comment perhaps wrongly talking about deassign?

Oh, yes, there are something wrong in the comments, this patch
has nothing to do with the _deassign_ stuff. The comments should
be like below:

+/*
+ * Pausing the domain can make sure the vCPU is not
+ * running and hence calling the hooks simultaneously
+ * when _assigning_ the PI hooks. This makes sure that
+ * all the appropriate state of PI descriptor is actually
+ * set up for all vCPus before leaving this function.
+ */

Sorry for that.

> 
> If so the change is still questionable, as the hooks get set before
> the first device gets actually assigned to a guest (I remember
> that I insisted on things getting done that way when those
> original patches had been under review).

Yes, the hooks were installed before the first device gets assigned.
Then could you please elaborate what is the question here?

Thanks,
Feng

> 
> Jan


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

Re: [Xen-devel] [Minios-devel] [PATCH 3/3] mini-os: support "make config" for out-of-tree users

[Samuel Thibault]

Wei Liu, on Tue 30 Aug 2016 14:57:50 +0100, wrote:
> On Tue, Aug 30, 2016 at 01:51:23PM +0200, Juergen Gross wrote:
> > Mini-OS applications being compiled using Mini-OS headers without
> > being integrated in the make environment of Mini-OS need a way to set
> > CONFIG_* defines according to their Mini-OS configuration.
> > 
> > Add a new make target "config" for that purpose creating a Makefile
> > snipplet $(CONFIG_FILE) (defaults to ./minios-config.mk) containing
> > the needed information.
> > 
> > Signed-off-by: Juergen Gross 
> 
> Reviewed-by: Wei Liu 

Acked-by: Samuel Thibault 

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

Re: [Xen-devel] [PATCH 3/3] mini-os: support "make config" for out-of-tree users

[Samuel Thibault]

Hello,

Juergen Gross, on Thu 01 Sep 2016 08:21:33 +0200, wrote:
> I stumbled over the problem with xenstore-stubdom: xenstore is using
> __XEN_LATEST_INTERFACE_VERSION__ when being compiled. This produced a
> build error with Mini-OS (console_evtchn in include/console.h was
> #define'd to console.domU.evtchn by include/xen/xen.h). It was pure
> luck such a problem didn't occur before my recent changes.
> 
> I think it is much more reasonable to compile all parts of a stubdom
> with the same Xen interface version instead of letting use the core of
> Mini-OS an ancient version and the App using Mini-OS another one.

Ok, I agree with that.

> So I added XEN_INTERFACE_VERSION to be configurable.
> This requires some adjustments in Mini-OS, of course. That is the
> purpose of patch 1 of this series.

Ok, now I better understand the issue, pros and cons, etc. It would be
better to clearly document and test it: AIUI,

- interface version compatibility is not so great: some features
are e.g. just *not* available when using interface version 0, so if
mini-os tries to use newer interfaces while stubdom asks for an older
interface version, it will fail to build, so it may need #ifs to check
for presence of the interface, and gracefully disable using the feature
instead of failing-to-build.

- mini-os happens not to be able to build with interface version 0,
basically because the current default is 0x00030205 and so nobody tests
with 0. Notably due to the console_evtchn #define, but also the use of
set_xen_guest_handle. Ideally we'd fix it, but I guess nobody will want
something older than that anyway, so we probably don't want to handle
the burden.

- to be able to let the stubdom application decide which interface
version it wants to build against, mini-os must be buildable standalone
with all versions from 0x00030205 to latest supported (which is what
patch 1 fixes). A not too bad approximation of this would be to be
able to build it with the minimum supported version and with latest
version. Perhaps we can declare that Config.mk's default interface
version is the minimum supported, so building standalone mini-os will
test that, and since as you say we already build the xenstore-stubdom
with latest version, building the xenstore-stubdom will test that.

- that way, stubdom applications can choose the level of compatibility
they wish from mini-os' minimum supported to mini-os' latest supported.

- whenever somebody would like to use an interface version which is
not supported by mini-os headers yet, we just need to update mini-os'
headers, and we have to fix the build with the minimum supported version
and with the latest supported version.


So if you agree with my reasoning, I'd say that the patch series
should document all that along the definition of XEN_INTERFACE_VERSION
in Config.mk: explaining that this default is the minimum supported
interface version, which the application can override up to the latest
supported by mini-os, and if a yet-newer interface is needed, one should
upgrade the headers, and before committing, try to build mini-os both
with the same minimum supported version for compatibility, and with the
latest version.

Samuel

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

Re: [Xen-devel] [PATCH v4 03/16] libxl/arm: Generate static ACPI DSDT table

[Boris Ostrovsky]

On 09/01/2016 08:55 PM, Shannon Zhao wrote:
>
> On 2016/9/1 20:53, Boris Ostrovsky wrote:
>> On 08/31/2016 11:18 PM, Shannon Zhao wrote:
 On 2016/8/30 1:46, Julien Grall wrote:
 diff --git a/tools/libacpi/Makefile b/tools/libacpi/Makefile
 index d741ac5..7f50a33 100644
 --- a/tools/libacpi/Makefile
 +++ b/tools/libacpi/Makefile
 @@ -19,6 +19,7 @@ MK_DSDT = $(ACPI_BUILD_DIR)/mk_dsdt

  # Sources to be generated
  C_SRC = $(addprefix $(ACPI_BUILD_DIR)/, dsdt_anycpu.c dsdt_15cpu.c 
 dsdt_anycpu_qemu_xen.c dsdt_pvh.c)
 +C_SRC += $(ACPI_BUILD_DIR)/dsdt_anycpu_arm.c
>> Do we really want to generate dsdt_anycpu_arm.c even for x86? Similarly,
>> do we want to generate x86 dsdt for ARM
 No need I think.
 Boris, will you change this in your next version?
>> You mean adding something along the lines of 'C_SRC-$(CONFIG_X86)'? Yes,
>> it's probably a good idea. I can add that.
> Yes. Then I'll rebase my series on your new version. BTW, when will you
> send out your new series?


I am out till Tuesday (US holiday and a day off), I'll try to post it by
the end of next week (I have v3 ready but need to run it through more tests)

-boris


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

Re: [Xen-devel] [PATCH v4 03/16] libxl/arm: Generate static ACPI DSDT table

[Shannon Zhao]

On 2016/9/1 20:53, Boris Ostrovsky wrote:
> On 08/31/2016 11:18 PM, Shannon Zhao wrote:
>> >
>> > On 2016/8/30 1:46, Julien Grall wrote:
 >>> diff --git a/tools/libacpi/Makefile b/tools/libacpi/Makefile
 >>> index d741ac5..7f50a33 100644
 >>> --- a/tools/libacpi/Makefile
 >>> +++ b/tools/libacpi/Makefile
 >>> @@ -19,6 +19,7 @@ MK_DSDT = $(ACPI_BUILD_DIR)/mk_dsdt
 >>>
 >>>  # Sources to be generated
 >>>  C_SRC = $(addprefix $(ACPI_BUILD_DIR)/, dsdt_anycpu.c dsdt_15cpu.c 
 >>> dsdt_anycpu_qemu_xen.c dsdt_pvh.c)
 >>> +C_SRC += $(ACPI_BUILD_DIR)/dsdt_anycpu_arm.c
>>> >> Do we really want to generate dsdt_anycpu_arm.c even for x86? Similarly,
>>> >> do we want to generate x86 dsdt for ARM
>> > No need I think.
>> > Boris, will you change this in your next version?
> You mean adding something along the lines of 'C_SRC-$(CONFIG_X86)'? Yes,
> it's probably a good idea. I can add that.
Yes. Then I'll rebase my series on your new version. BTW, when will you
send out your new series?

Thanks,
-- 
Shannon


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

Re: [Xen-devel] [PATCH 2/2] xen_platform: SUSE xenlinux unplug for emulated PCI

[Konrad Rzeszutek Wilk]

On Thu, Sep 01, 2016 at 02:11:31PM +0200, Olaf Hering wrote:
> Implement SUSE specific unplug protocol for emulated PCI devices
> in PVonHVM guests. Its a simple 'outl(1, (ioaddr + 4));'.
> This protocol was implemented and used since Xen 3.0.4.
> It is used in all SUSE/SLES/openSUSE releases up to SLES11SP3 and
> openSUSE 12.3.

Should this be documented in the protocol?

> 
> Signed-off-by: Olaf Hering 
> ---
>  hw/i386/xen/xen_platform.c | 31 ++-
>  1 file changed, 30 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/i386/xen/xen_platform.c b/hw/i386/xen/xen_platform.c
> index d94b53c..8802482 100644
> --- a/hw/i386/xen/xen_platform.c
> +++ b/hw/i386/xen/xen_platform.c
> @@ -314,13 +314,42 @@ static void xen_platform_ioport_writeb(void *opaque, 
> hwaddr addr,
> uint64_t val, unsigned int size)
>  {
>  PCIXenPlatformState *s = opaque;
> +PCIDevice *pci_dev = PCI_DEVICE(s);
>  
>  switch (addr) {
>  case 0: /* Platform flags */
>  platform_fixed_ioport_writeb(opaque, 0, (uint32_t)val);
>  break;
> +case 4:
> +if (val == 1) {
> +/*
> + * SUSE unplug for Xenlinux
> + * xen-kmp used this since xen-3.0.4, instead the official 
> protocol from xen-3.3+
> + * It did an unconditional "outl(1, (ioaddr + 4));"
> + * Pre VMDP 1.7 made use of 4 and 8 depending on how VMDP was 
> configured.
> + * If VMDP was to control both disk and LAN it would use 4.
> + * If it controlled just disk or just LAN, it would use 8 below.
> + */
> +blk_drain_all();
> +blk_flush_all();
> +pci_unplug_disks(pci_dev->bus);
> +pci_unplug_nics(pci_dev->bus);
> +}
> +break;
>  case 8:
> -log_writeb(s, (uint32_t)val);
> +switch (val) {
> +case 1:
> +blk_drain_all();
> +blk_flush_all();
> +pci_unplug_disks(pci_dev->bus);
> +break;
> +case 2:
> +pci_unplug_nics(pci_dev->bus);
> +break;
> +default:
> +log_writeb(s, (uint32_t)val);
> +break;
> +}
>  break;
>  default:
>  break;
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

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

Re: [Xen-devel] [PATCH v6 0/4] arm64, xen: add xen_boot support into grup-mkconfig

[Daniel Kiper]

Hey Julien,

On Thu, Sep 01, 2016 at 01:47:05PM +0100, Julien Grall wrote:
> Hi Daniel,
>
> I have heard you became co-maintainer of GRUB. Congratulations for that :).

Thanks a lot!

> We have a couple series (this series and [1]) to allow grub booting
> Xen on ARM that have been waiting on the GRUB ML for a while to be
> pushed.
>
> Those patches have been tested and already integrated in some
> distributions. It would be nice to get them in GRUB upstream.

As I can see at least some of them listed here:
https://docs.google.com/document/d/1O6wveo1_WsAyEHMD041xMYvhDTDp3jQYzmqkgBx57HM/

So, this is good sign. Currently, we are agreeing what should be
taken into 2.02 train. We are considering just most important things
and fixes. Hence, I am not able to promise that we include in 2.02
all ARM patches mentioned by you if they are not on the above list
right now. However, if it does not happen I will put them on the
list for release after 2.02 (assuming that they are OK).

> Would it be possible for you to take a look?

Sure thing. However, I am working on some stuff for Xen 4.8 and as
you may know deadline is quite close. So, I will take care of
GRUB2 things in the second half of September. Stay tuned...

Daniel

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

Re: [Xen-devel] [PATCH v5 15/16] x86: make Xen early boot code relocatable

[Daniel Kiper]

On Thu, Sep 01, 2016 at 01:46:24AM -0600, Jan Beulich wrote:
> >>> On 31.08.16 at 22:50,  wrote:
> > On Wed, Aug 31, 2016 at 09:46:31AM -0600, Jan Beulich wrote:
> >> >>> On 31.08.16 at 16:59,  wrote:
> >> > On Thu, Aug 25, 2016 at 08:41:39AM -0600, Jan Beulich wrote:
> >> >> >>> On 20.08.16 at 00:43,  wrote:
> >> >> > --- a/xen/arch/x86/boot/head.S
> >> >> > +++ b/xen/arch/x86/boot/head.S
> >> >> > @@ -12,13 +12,16 @@
> >> >> >  .text
> >> >> >  .code32
> >> >> >
> >> >> > -#define sym_phys(sym) ((sym) - __XEN_VIRT_START)
> >> >> > +#define sym_offset(sym)   ((sym) - __XEN_VIRT_START)
> >> >>
> >> >> In a patch already large and hence hard to review, did you really
> >> >> need to do this rename?
> >> >
> >> > I think that sym_offset() is better term here. However, if you wish
> >> > I can leave sym_phys() as is. Though, IMO, sym_phys() name suggests
> >> > that we are playing with physical addresses and it is not correct in
> >> > all contexts, e.g. loot at fs_offset() (or sym_fs() as you wish).
> >>
> >> After some more thinking about this I agree sym_phys() isn't
> >> ideal anymore after this patch. Still, to avoid unrelated changes in
> >> this quite hard to review patch, I'd like to ask that you keep the
> >> name here and do just the rename in a subsequent patch.
> >
> > Granted!
>
> Btw., to save on typing and since you will need to touch this anyway
> - can I talk you into using sym_offs() instead of sym_offset()?

Sure thing!

> >> >> >  .pushsection .trampoline_rel, "a"
> >> >> >  .long   trampoline_gdt + BOOT_PSEUDORM_CS + 2 - .
> >> >> >  .long   trampoline_gdt + BOOT_PSEUDORM_DS + 2 - .
> >> >> >  .popsection
> >> >> >
> >> >> > +GLOBAL(xen_img_load_base_addr)
> >> >> > +.long   0
> >> >>
> >> >> I've yet to understand the purpose of this symbol, but in any case:
> >> >> If the trampoline code doesn't reference it, why does it get placed
> >> >> here?
> >> >
> >> > This symbol was used by code which unconditionally relocated Xen image
> >> > even if boot loader did work for us. I removed most of this code because
> >> > we agreed that if boot loader relocated Xen image then we do not have to
> >> > relocate it higher once again. If you are still OK with this idea I can 
> >> > go
> >> > further, as I planned, and remove all such remnants from next release.
> >> > However, it looks that then I have to store load address in 
> >> > xen_phys_start
> >> > from 32-bit assembly code. So, it will be nice if I can define it as
> >> > "unsigned int" instead of "unsigned long". Is it safe?
> >>
> >> I don't see why you shouldn't be able to store into the low 32 bits of
> >> the variable without altering the high ones (which are all zero).
> >
> > I was thinking about that too but IMO it is not nice. However, if you
> > are OK with that I can do it.
>
> Well, imo that's something which is perfectly fine in assembly code.

OK, I will do that.

> >> >> >  s = (boot_e820.map[i].addr + mask) & ~mask;
> >> >> >  e = (boot_e820.map[i].addr + boot_e820.map[i].size) & ~mask;
> >> >> > -s = max_t(uint64_t, s, BOOTSTRAP_MAP_BASE);
> >> >> >  if ( (boot_e820.map[i].type != E820_RAM) || (s >= e) )
> >> >> >  continue;
> >> >>
> >> >> This means you now map memory between 2Mb and 16Mb here. Is
> >> >> this necessary?
> >> >
> >> > Without this change Xen relocated by boot loader crashes with:
> >> >
> >> > (XEN) Panic on CPU 0:
> >> > (XEN) Assertion 'l2e_get_flags(l2e) & _PAGE_PRESENT' failed at 
> >> > x86_64/mm.c:902
> >> >
> >> > So, it must be mapped.
> >>
> >> That's too little context to be useful for understanding the full
> >> background.
> >
> > Here it is:
> >[...]
> > Is it sufficient? If not please drop me a line what else do you need.
>
> I'm sorry, but no. I didn't mean the whole register and stack dump. I
> meant an explanation of _why_ this assertion triggers (after all it
> doesn't trigger without your patches, and hence I can't just go and
> check the relevant source files).

AIUI, if Xen image is not relocated by boot loader (e.g. GRUB2) then region
2 MiB - 16 MiB is mapped. Later Xen after relocating itself marks 1 MiB - 16 MiB
region as NX (if it is supported by hardware) in subarch_init_memory(). However,
if boot loader relocate Xen then region 2 MiB - 16 MiB is not mapped if change
under consideration is not applied. Then ASSERT(l2e_get_flags(l2e) & 
_PAGE_PRESENT)
in subarch_init_memory() is triggered and Xen crashes.

I hope that helps.

Daniel

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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf b10d5ddc0385f39d2c2c62843710b7609a4ca169
baseline version:
 ovmf 5322ee484b54bc78023383a546971b601dcc4ce1

Last test of basis67621  2016-09-01 16:18:30 Z0 days
Testing same since67622  2016-09-01 18:16:25 Z0 days1 attempts


People who touched revisions under test:
  Laszlo Ersek 
  Star Zeng 

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



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

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

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


Push not applicable.


commit b10d5ddc0385f39d2c2c62843710b7609a4ca169
Author: Star Zeng 
Date:   Wed Jul 20 10:24:58 2016 +0800

UefiCpuPkg/PiSmmCpuDxeSmm: Consume PcdAcpiS3Enable to control the code

if PcdAcpiS3Enable is disabled, then skip S3 related logic.

Cc: Jeff Fan 
Cc: Jiewen Yao 
Cc: Michael Kinney 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
Reviewed-by: Jeff Fan 
Reviewed-by: Laszlo Ersek 
Tested-by: Laszlo Ersek 

commit 0bdc9e75c0c31d5a508eac9353b2079f46b23f2f
Author: Star Zeng 
Date:   Tue Jul 19 16:44:16 2016 +0800

UefiCpuPkg/PiSmmCpuDxeSmm: Move S3 related code to CpuS3.c

Cc: Jeff Fan 
Cc: Jiewen Yao 
Cc: Michael Kinney 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
Reviewed-by: Jeff Fan 
Tested-by: Laszlo Ersek 
Acked-by: Laszlo Ersek 

commit ca98f60382943d4b40a8e60125120edc4d69f212
Author: Star Zeng 
Date:   Mon Jul 18 11:31:28 2016 +0800

UefiCpuPkg/CpuS3DataDxe: Consume PcdAcpiS3Enable to control the code

If PcdAcpiS3Enable is disabled, then return an EFI_UNSUPPORTED
error which forces the module to be unloaded.

Cc: Jeff Fan 
Cc: Jiewen Yao 
Cc: Michael Kinney 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
Reviewed-by: Jeff Fan 
Reviewed-by: Laszlo Ersek 
Tested-by: Laszlo Ersek 

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

[Xen-devel] [qemu-upstream-4.7-testing baseline test] 100704: tolerable FAIL

[osstest service owner]

"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate.  The baseline, if
any, is the most recent actually tested revision.

flight 100704 qemu-upstream-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100704/

Failures :-/ but no regressions.

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

version targeted for testing:
 qemuu44a072f0de0d57c95c2212bbce0232b7b74f
baseline version:
 qemuu44a072f0de0d57c95c2212bbce0232b7b74f

Last test of basis   100704  2016-09-01 16:43:31 Z0 days
Testing same since0  1970-01-01 00:00:00 Z 17045 days0 attempts

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

Re: [Xen-devel] [PATCH v5 14/16] x86/boot: implement early command line parser in C

[Daniel Kiper]

On Thu, Sep 01, 2016 at 01:41:26AM -0600, Jan Beulich wrote:
> >>> On 31.08.16 at 21:31,  wrote:
> > On Wed, Aug 31, 2016 at 07:01:10AM -0600, Jan Beulich wrote:
> >> >>> On 30.08.16 at 21:58,  wrote:
> >> > On Thu, Aug 25, 2016 at 07:27:21AM -0600, Jan Beulich wrote:
> >> >> >>> On 20.08.16 at 00:43,  wrote:
> >
> > [...]
> >
> >> >> > +static unsigned int strtoui(const char *s, const char *stop, const 
> >> >> > char
> > **next)
> >> >> > +{
> >> >> > +char l;
> >> >> > +unsigned int base = 10, ores = 0, res = 0;
> >> >> > +
> >> >> > +if ( *s == '0' )
> >> >> > +  base = (tolower(*++s) == 'x') ? (++s, 16) : 8;
> >> >> > +
> >> >> > +for ( ; *s != '\0'; ++s )
> >> >> > +{
> >> >> > +if ( stop && strchr(stop, *s) )
> >> >> > +goto out;
> >> >> > +
> >> >> > +if ( *s < '0' || (*s > '7' && base == 8) )
> >> >> > +{
> >> >> > +res = UINT_MAX;
> >> >> > +goto out;
> >> >> > +}
> >> >> > +
> >> >> > +l = tolower(*s);
> >> >> > +
> >> >> > +if ( *s > '9' && (base != 16 || l < 'a' || l > 'f') )
> >> >> > +{
> >> >> > +res = UINT_MAX;
> >> >> > +goto out;
> >> >> > +}
> >> >> > +
> >> >> > +res *= base;
> >> >> > +res += (l >= 'a') ? (l - 'a' + 10) : (*s - '0');
> >> >> > +
> >> >> > +if ( ores > res )
> >> >> > +{
> >> >> > +res = UINT_MAX;
> >> >> > +goto out;
> >> >> > +}
> >> >>
> >> >> Without having spent time to try and find an example, it feels like this
> >> >> check won't catch all possible overflow conditions. If you care about
> >> >> overflow, please make sure you catch all cases.
> >> >
> >> > Hmmm How come? Could you give an example?
> >>
> >> Excuse me, but shouldn't you instead demonstrate the logic is
> >> correct? Or - consider what I had said - try to find an example
> >> yourself? It's not that difficult: With 16-bit word size
> >> 0x * 10 = 0x1fffe, which truncates to 0xfffe and is hence
> >> larger than both inputs but still produced an overflow. This
> >> easily extends to 32- and 64-bit word size.
> >
> > Oh, boy. I forgot about multiplication. I think that we can define
> > res as unsigned long and then check that it is < UINT_MAX.
> > If not then return UINT_MAX.
>
> Aren't we in 32-bit code here, i.e. sizeof(int) == sizeof(long)?

Yep, this should be unsigned long long here.

Daniel

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

Re: [Xen-devel] [PATCH v5 13/16] x86: add multiboot2 protocol support for EFI platforms

[Daniel Kiper]

On Thu, Sep 01, 2016 at 01:40:11AM -0600, Jan Beulich wrote:
> >>> On 31.08.16 at 19:07,  wrote:
> > On Wed, Aug 31, 2016 at 06:49:51AM -0600, Jan Beulich wrote:
> >> >>> On 30.08.16 at 21:32,  wrote:
> >> > On Thu, Aug 25, 2016 at 06:59:54AM -0600, Jan Beulich wrote:
> >> >> >>> On 20.08.16 at 00:43,  wrote:
> >> >> > --- a/xen/arch/x86/efi/stub.c
> >> >> > +++ b/xen/arch/x86/efi/stub.c
> >> >> > @@ -3,6 +3,30 @@
> >> >> >  #include 
> >> >> >  #include 
> >> >> >  #include 
> >> >> > +#include 
> >> >> > +#include 
> >> >> > +#include 
> >> >> > +#include 
> >> >> > +#include 
> >> >> > +#include 
> >> >> > +
> >> >> > +paddr_t __init noreturn efi_multiboot2(EFI_HANDLE ImageHandle, 
> >> >> > EFI_SYSTEM_TABLE *SystemTable)
> >> >> > +{
> >> >> > +CHAR16 *err = L"Xen does not have EFI code build in!!!\r\nSystem 
> >> >> > halted!!!\r\n";
> >> >> > +SIMPLE_TEXT_OUTPUT_INTERFACE *StdErr;
> >> >> > +
> >> >> > +StdErr = SystemTable->StdErr ? SystemTable->StdErr : 
> >> >> > SystemTable->ConOut;
> >> >> > +
> >> >> > +/* Print error message and halt the system. */
> >> >> > +asm volatile(
> >> >> > +"call %2  \n"
> >> >> > +"0:  hlt  \n"
> >> >> > +"jmp  0b  \n"
> >> >> > +   : "+c" (StdErr), "+d" (err) : "g" (StdErr->OutputString)
> >> >> > +   : "rax", "r8", "r9", "r10", "r11", "cc", "memory");
> >> >>
> >> >> There are explanations missing here: First, a warning should be added
> >> >> alongside the EFI header inclusions, making clear that no services
> >> >> whatsoever can be called. And then the asm() here needs to explain
> >> >
> >> > I am not convinced but if you wish...
> >>
> >> Not convinced of what?
> >
> > About "... a warning should be added alongside the EFI header inclusions,
> > making clear that no services whatsoever can be called". AIUI, "warning" ==
> > "comment" here. However, I think that everybody who reads this file is
> > aware that "no services whatsoever can be called". So, I am not sure
> > where is the point.
>
> Odd - you do an EFI call here (in the asm()) and talk about reader's
> awareness?

I do this in quite strange way just to display clear error from file called
stub.c which contains just mostly function stubs. So, I have a feeling that
sane reader will be conscious here and will not expect code which does sensible
stuff. However, if you still think that these are insufficient then I can add
warninng/comment which assures potential reader that this is a stub file and
most functions does nothing except efi_multiboot2().

> >> >> need for an explicit "cc" clobber on x86.
> >> >
> >> > Why?
> >>
> >> Because such a clobber gets added to every asm() by the compiler,
> >> unless it uses the (new in gcc 6) flag output. I've actually suggested
> >> to upstream a patch making it possible to avoid that automatic
> >> addition, but there hadn't been a whole lot of useful feedback.
> >
> > So, when somebody uses this new flag then "cc" will not be add here.
> > This is not big deal but I think that extra "cc" clobbers does not
> > hurt too.
>
> It surely doesn't hurt, but it makes code bigger and hence results in
> it taking longer to be read and parsed (for all of these - even if just
> slightly). I'm sorry, but I'm opposed to adding unnecessary stuff.

As you wish...

Daniel

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

Re: [Xen-devel] Can't build ipxe with 6.1.1

[Andrew Cooper]

On 01/09/16 20:40, Boris Ostrovsky wrote:
> On 09/01/2016 03:35 PM, Andrew Cooper wrote:
>> On 01/09/16 20:27, Boris Ostrovsky wrote:
>>> Newer gcc (6.1.1 is what I am using with Fedora 24) is having trouble
>>> compiling ipxe that is fetched by Xen, mostly due to stricter checks.
>>>
>>> I have a patch that fixes all these warnings but do we want it or should
>>> we instead upgrade to latest ipxe version? (It builds fine but I haven't
>>> tested it).
>> We should really update to a newer iPXE.
>>
>> The version pulled from xenbits is ages old, and there is no excuse for
>> having a opencoded patch queue on top of it.
>>
>> It would be better if it could switch to being like seabios, with a git
>> tree rather than a tarball, and a --with-system-ipxe= ./configure
>> option.  This will finally get rid of the last wget'ism out of the
>> non-stubdom build, which is a distinct improvement for most downstream
>> consumers of the project.
>>
>> (I realise I am dumping part of my TODO list on you, but you literally
>> are asking for it with that question :) - if not, I will get around to
>> it some day.)
> Sure, I'll look at this.

Ian: Can we see about getting xenbits:ipxe.git which works, and is
tested by osstest, in the same way as seabios currently is?

iPXE has a rolling release with no specific version number, but does
have a xen-netfront implementation (when we start using a version which
isn't 6 years old), so some system testing of PXE booting HVM guests
would be a good move.

~Andrew

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

[Xen-devel] Reminder: Technical Call on PV Calls, Friday 2nd of Sept 9AM PST / 5PM UK

[Stefano Stabellini]

Hi all,

just a quick reminder that tomorrow, Friday the 2nd of September, at 9AM
PST / 5PM UK, there will be a technical community call on PV Calls.

To join the call, visit:

https://www.uberconference.com/stefano-aporeto

The webpage contains information on how to join the call via PC or
telephone. If you are in the US, just dial 669-999-0613 and you'll be
automatically joining the conference. International callers should dial
their national number, then enter the conference code (669-999-0613,
same as US telephone number) when prompted, followed by #. In case of
issues I'll be on #xendevel on Freenode.

In the meantime you might be interested in the recently published blog
article "PV Calls: a new paravirtualized protocol for POSIX syscalls":

https://blog.xenproject.org/2016/08/30/pv-calls-a-new-paravirtualized-protocol-for-posix-syscalls/

Cheers,

Stefano


On Thu, 25 Aug 2016, Stefano Stabellini wrote:
> Hi all,
> 
> if you are interested in PV Calls, or you just have any questions for me
> about it, please join the following technical call:
> 
> Friday the 2nd of September at 9AM PST, 5PM UK
> Join the call: https://www.uberconference.com/stefano-aporeto
> 
> Cheers,
> 
> Stefano

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

Re: [Xen-devel] Can't build ipxe with 6.1.1

[Boris Ostrovsky]

On 09/01/2016 03:35 PM, Andrew Cooper wrote:
> On 01/09/16 20:27, Boris Ostrovsky wrote:
>> Newer gcc (6.1.1 is what I am using with Fedora 24) is having trouble
>> compiling ipxe that is fetched by Xen, mostly due to stricter checks.
>>
>> I have a patch that fixes all these warnings but do we want it or should
>> we instead upgrade to latest ipxe version? (It builds fine but I haven't
>> tested it).
> We should really update to a newer iPXE.
>
> The version pulled from xenbits is ages old, and there is no excuse for
> having a opencoded patch queue on top of it.
>
> It would be better if it could switch to being like seabios, with a git
> tree rather than a tarball, and a --with-system-ipxe= ./configure
> option.  This will finally get rid of the last wget'ism out of the
> non-stubdom build, which is a distinct improvement for most downstream
> consumers of the project.
>
> (I realise I am dumping part of my TODO list on you, but you literally
> are asking for it with that question :) - if not, I will get around to
> it some day.)

Sure, I'll look at this.

-boris

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

Re: [Xen-devel] Can't build ipxe with 6.1.1

[Andrew Cooper]

On 01/09/16 20:27, Boris Ostrovsky wrote:
> Newer gcc (6.1.1 is what I am using with Fedora 24) is having trouble
> compiling ipxe that is fetched by Xen, mostly due to stricter checks.
>
> I have a patch that fixes all these warnings but do we want it or should
> we instead upgrade to latest ipxe version? (It builds fine but I haven't
> tested it).

We should really update to a newer iPXE.

The version pulled from xenbits is ages old, and there is no excuse for
having a opencoded patch queue on top of it.

It would be better if it could switch to being like seabios, with a git
tree rather than a tarball, and a --with-system-ipxe= ./configure
option.  This will finally get rid of the last wget'ism out of the
non-stubdom build, which is a distinct improvement for most downstream
consumers of the project.

(I realise I am dumping part of my TODO list on you, but you literally
are asking for it with that question :) - if not, I will get around to
it some day.)

~Andrew

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

[Xen-devel] Can't build ipxe with 6.1.1

[Boris Ostrovsky]

Newer gcc (6.1.1 is what I am using with Fedora 24) is having trouble
compiling ipxe that is fetched by Xen, mostly due to stricter checks.

I have a patch that fixes all these warnings but do we want it or should
we instead upgrade to latest ipxe version? (It builds fine but I haven't
tested it).


-boris





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

[Xen-devel] [PATCH 1/2] x86/shadow: More consistent printing for debug messages

[Andrew Cooper]

 * Use %pv or just d%d in preference to the multiple current ways of
   presenting the same information.
 * Use PRI_mfn instead of opencoding it.
 * Drop all explicit use of __func__ from SHADOW_{PRINTK,DEBUG}() calls.  The
   wrappers already include it.
 * Use hex rather than decimal for printing a pagefault error code.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Tim Deegan 
CC: George Dunlap 
---
 xen/arch/x86/mm/shadow/common.c | 23 ++
 xen/arch/x86/mm/shadow/multi.c  | 42 ++---
 2 files changed, 28 insertions(+), 37 deletions(-)

diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
index c22362f..04ce322 100644
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -723,8 +723,7 @@ static void _sh_resync(struct vcpu *v, mfn_t gmfn,
  & ~SHF_L1_ANY));
 ASSERT(!sh_page_has_multiple_shadows(mfn_to_page(gmfn)));
 
-SHADOW_PRINTK("d=%d, v=%d, gmfn=%05lx\n",
-  v->domain->domain_id, v->vcpu_id, mfn_x(gmfn));
+SHADOW_PRINTK("%pv gmfn=%"PRI_mfn"\n", v, mfn_x(gmfn));
 
 /* Need to pull write access so the page *stays* in sync. */
 if ( oos_remove_write_access(v, gmfn, fixup) )
@@ -900,7 +899,7 @@ void sh_resync_all(struct vcpu *v, int skip, int this, int 
others)
 mfn_t *oos_snapshot = v->arch.paging.shadow.oos_snapshot;
 struct oos_fixup *oos_fixup = v->arch.paging.shadow.oos_fixup;
 
-SHADOW_PRINTK("d=%d, v=%d\n", v->domain->domain_id, v->vcpu_id);
+SHADOW_PRINTK("%pv\n", v);
 
 ASSERT(paging_locked_by_me(v->domain));
 
@@ -961,8 +960,7 @@ int sh_unsync(struct vcpu *v, mfn_t gmfn)
 
 ASSERT(paging_locked_by_me(v->domain));
 
-SHADOW_PRINTK("d=%d, v=%d, gmfn=%05lx\n",
-  v->domain->domain_id, v->vcpu_id, mfn_x(gmfn));
+SHADOW_PRINTK("%pv gmfn=%"PRI_mfn"\n", v, mfn_x(gmfn));
 
 pg = mfn_to_page(gmfn);
 
@@ -2792,7 +2790,7 @@ void sh_remove_shadows(struct domain *d, mfn_t gmfn, int 
fast, int all)
  * can be called via put_page_type when we clear a shadow l1e).*/
 paging_lock_recursive(d);
 
-SHADOW_PRINTK("d=%d: gmfn=%lx\n", d->domain_id, mfn_x(gmfn));
+SHADOW_PRINTK("d%d gmfn=%"PRI_mfn"\n", d->domain_id, mfn_x(gmfn));
 
 /* Bail out now if the page is not shadowed */
 if ( (pg->count_info & PGC_page_table) == 0 )
@@ -2847,7 +2845,7 @@ void sh_remove_shadows(struct domain *d, mfn_t gmfn, int 
fast, int all)
 /* If that didn't catch the shadows, something is wrong */
 if ( !fast && all && (pg->count_info & PGC_page_table) )
 {
-SHADOW_ERROR("can't find all shadows of mfn %05lx "
+SHADOW_ERROR("can't find all shadows of mfn %"PRI_mfn" "
  "(shadow_flags=%08x)\n",
   mfn_x(gmfn), pg->shadow_flags);
 domain_crash(d);
@@ -3016,9 +3014,9 @@ static void sh_update_paging_modes(struct vcpu *v)
 
 if ( v->arch.paging.mode != old_mode )
 {
-SHADOW_PRINTK("new paging mode: d=%u v=%u pe=%d gl=%u "
+SHADOW_PRINTK("new paging mode: %pv pe=%d gl=%u "
   "sl=%u (was g=%u s=%u)\n",
-  d->domain_id, v->vcpu_id,
+  v,
   is_hvm_domain(d) ? hvm_paging_enabled(v) : 1,
   v->arch.paging.mode->guest_levels,
   v->arch.paging.mode->shadow.shadow_levels,
@@ -3033,11 +3031,10 @@ static void sh_update_paging_modes(struct vcpu *v)
 
 if ( v != current && vcpu_runnable(v) )
 {
-SHADOW_ERROR("Some third party (d=%u v=%u) is changing "
- "this HVM vcpu's (d=%u v=%u) paging mode "
+SHADOW_ERROR("Some third party (%pv) is changing "
+ "this HVM vcpu's (%pv) paging mode "
  "while it is running.\n",
- current->domain->domain_id, current->vcpu_id,
- v->domain->domain_id, v->vcpu_id);
+ current, v);
 /* It's not safe to do that because we can't change
  * the host CR3 for a running domain */
 domain_crash(v->domain);
diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index 833f279..6c45338 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -116,7 +116,7 @@ static inline void
 set_fl1_shadow_status(struct domain *d, gfn_t gfn, mfn_t smfn)
 /* Put an FL1 shadow into the hash table */
 {
-SHADOW_PRINTK("gfn=%"SH_PRI_gfn", type=%08x, smfn=%05lx\n",
+SHADOW_PRINTK("gfn=%"SH_PRI_gfn", type=%08x, smfn=%"PRI_mfn"\n",
gfn_x(gfn), SH_type_fl1_shadow, mfn_x(smfn));
 
 

[Xen-devel] [PATCH 2/2] xen/trace: Turn the stub debugtrace_{dump, printk}() macros into functions

[Andrew Cooper]

This allows printf format checking to be performed, and for
debugtrace_printk() to evaluate its arguments, even if debugtrace is disabled
at compile time.

No intended change.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Tim Deegan 
CC: George Dunlap 
---
 xen/include/xen/lib.h | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/xen/include/xen/lib.h b/xen/include/xen/lib.h
index d04864e..0008d63 100644
--- a/xen/include/xen/lib.h
+++ b/xen/include/xen/lib.h
@@ -68,8 +68,10 @@ extern void debugtrace_dump(void);
 extern void debugtrace_printk(const char *fmt, ...)
 __attribute__ ((format (printf, 1, 2)));
 #else
-#define debugtrace_dump()  ((void)0)
-#define debugtrace_printk(_f, ...) ((void)0)
+static inline void debugtrace_dump(void) {};
+static inline void
+ __attribute__ ((format (printf, 1, 2)))
+debugtrace_printk(const char *fmt, ...) {};
 #endif
 
 /* Allows us to use '%p' as general-purpose machine-word format char. */
-- 
2.1.4


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

[Xen-devel] [xen-unstable test] 100690: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf   4 host-build-prep  fail REGR. vs. 100674

Regressions which are regarded as allowable (not blocking):
 build-amd64-rumpuserxen   6 xen-buildfail  like 100674
 build-i386-rumpuserxen6 xen-buildfail  like 100674
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100674
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100674
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 100674
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100674
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 100674

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 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-xl-vhd   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  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-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-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-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   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

version targeted for testing:
 xen  fb1f0e95654c8f995ddcdbd114100515814c1238
baseline version:
 xen  4b314c89be24c26abfad47900f806cebeafc805e

Last test of basis   100674  2016-08-31 08:49:52 Z1 days
Failing since100681  2016-08-31 18:14:20 Z1 days3 attempts
Testing same since   100684  2016-09-01 01:46:49 Z0 days2 attempts


People who touched revisions under test:
  Feng Wu 
  Ian Jackson 
  Jan Beulich 
  Wei Liu 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  broken  
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  blocked 
 build-i386-libvirt   pass
 build-amd64-oldkern  pass
 build-i386-oldkern   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  fail
 build-i386-rumpuserxen   fail
 test-amd64-amd64-xl  pass
 

[Xen-devel] [PATCH] x86/levelling: Fix breakage on older Intel boxes from c/s 08e7738

[Andrew Cooper]

cpufeat_mask() yields an unsigned integer constant.  As a result, taking its
complement causes zero extention rather than sign extention.

The result is that, when a guest OS has OXSAVE disabled, all features in 1d
are hidden from native CPUID.  Amongst other things, this causes the early
code in Linux to find no LAPIC, but for everything to appear fine later when
userspace is up and running.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 

I wonder whether a better fix might be to put an explicit (int) cast in
cpufeat_mask() to yield an signed constant?
---
 xen/arch/x86/cpu/intel.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/cpu/intel.c b/xen/arch/x86/cpu/intel.c
index a9355cbf..7b60aaa 100644
--- a/xen/arch/x86/cpu/intel.c
+++ b/xen/arch/x86/cpu/intel.c
@@ -192,7 +192,7 @@ static void intel_ctxt_switch_levelling(const struct vcpu 
*next)
 */
if (next && is_pv_vcpu(next) && !is_idle_vcpu(next) &&
!(next->arch.pv_vcpu.ctrlreg[4] & X86_CR4_OSXSAVE))
-   val &= ~cpufeat_mask(X86_FEATURE_OSXSAVE);
+   val &= ~(uint64_t)cpufeat_mask(X86_FEATURE_OSXSAVE);
 
if (unlikely(these_masks->_1cd != val)) {
wrmsrl(msr_basic, val);
-- 
2.1.4


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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 5322ee484b54bc78023383a546971b601dcc4ce1
baseline version:
 ovmf 00afc8f82061677fedc86cb05e3b8c75a3c986ff

Last test of basis67620  2016-09-01 13:46:26 Z0 days
Testing same since67621  2016-09-01 16:18:30 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 

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



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

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

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


Push not applicable.


commit 5322ee484b54bc78023383a546971b601dcc4ce1
Author: Ard Biesheuvel 
Date:   Wed Aug 31 09:50:23 2016 +0100

ArmPkg: remove BaseMemoryLibVstm implementation of BaseMemoryLib

The BaseMemoryLibVstm implementation of BaseMemoryLib is ARM only, uses
the NEON register file despite the fact that the UEFI spec does not allow
it, and is currently not used anywhere. So remove it.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Leif Lindholm 

commit a0cf6b8d93d7fab44f8bcb850ebbe696d0c3d4bd
Author: Ard Biesheuvel 
Date:   Thu Aug 11 16:01:24 2016 +0200

ArmPkg/CompilerIntrinsicsLib: replace memcpy and memset with C code

This replaces the various implementations of memset and memcpy,
including the ARM RTABI ones (__aeabi_mem[set|clr]_[|4|8]) with
a single C implementation for each. The ones we have are either not
very sophisticated (ARM), or they are too sophisticated (memcpy() on
AARCH64, which may perform unaligned accesses) or already coded in C
(memset on AArch64).

The Tianocore codebase mandates the explicit use of its SetMem() and
CopyMem() equivalents, of which various implementations exist for use
in different contexts (PEI, DXE). Few compiler generated references to
these functions should remain, and so our implementations in this BASE
library should be small and usable with the MMU off.

So replace them with a simple C implementation that builds correctly
on GCC/AARCH64, CLANG/AARCH64, GCC/ARM, CLANG/ARM and RVCT/ARM.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Leif Lindholm 

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

[Xen-devel] [RFC] e1000: Don't save writes to ICS/ICR masked by IMS

[Ed Swierk]

Windows 8, 10 and Server 2012 guests hang intermittently while booting
on Xen 4.5.3 with 1 vCPU and 4 e1000 vNICs, shortly after the Windows
logo appears and the little dots start spinning.

Running strace on qemu shows its main thread doing the following every
couple of milliseconds:

 ppoll([..., {fd=30, events=POLLIN|POLLERR|POLLHUP},
...], ...) = 1 ([{fd=30, revents=POLLIN}], ...)
 read(30, "^\0\0\0", 4) = 4
 write(30, "^\0\0\0", 4) = 4
 ioctl(30, IOCTL_EVTCHN_NOTIFY, 0x7f1f9449d310) = 0
 clock_gettime(CLOCK_MONOTONIC, {6937, 449468262}) = 0
 clock_gettime(CLOCK_MONOTONIC, {6937, 449582903}) = 0
 gettimeofday({1472251376, 673434}, NULL) = 0
 clock_gettime(CLOCK_MONOTONIC, {6937, 449856205}) = 0
 gettimeofday({1472251376, 673679}, NULL) = 0

The event channel (identified by '^' or 94 in this example) is always
the third of the domain's four channels.

Two recent qemu patches (http://git.qemu.org/?p=qemu.git;h=9596ef7c and
http://git.qemu.org/?p=qemu.git;h=74004e8c) seem to address similar
issues, but don't help in this case.

The proposed fix from
https://bugzilla.redhat.com/show_bug.cgi?id=874406#c78 makes the hang
go away. It's not clear to me why it works, or if it's just papering
over a bug elsewhere, or if there are any possible side effects.

Suggested-by: Andrew Jones 
Signed-off-by: Ed Swierk 

diff --git a/hw/net/e1000.c b/hw/net/e1000.c
index 6eac66d..c891b67 100644
--- a/hw/net/e1000.c
+++ b/hw/net/e1000.c
@@ -293,6 +293,8 @@ set_interrupt_cause(E1000State *s, int index, uint32_t val)
 uint32_t pending_ints;
 uint32_t mit_delay;
 
+val &= s->mac_reg[IMS];
+
 s->mac_reg[ICR] = val;
 
 /*
@@ -305,7 +307,7 @@ set_interrupt_cause(E1000State *s, int index, uint32_t val)
  */
 s->mac_reg[ICS] = val;
 
-pending_ints = (s->mac_reg[IMS] & s->mac_reg[ICR]);
+pending_ints = s->mac_reg[ICR];
 if (!s->mit_irq_level && pending_ints) {
 /*
  * Here we detect a potential raising edge. We postpone raising the

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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf b10d5ddc0385f39d2c2c62843710b7609a4ca169
baseline version:
 ovmf 5322ee484b54bc78023383a546971b601dcc4ce1

Last test of basis   100699  2016-09-01 14:14:06 Z0 days
Testing same since   100703  2016-09-01 16:15:14 Z0 days1 attempts


People who touched revisions under test:
  Laszlo Ersek 
  Star Zeng 

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



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=b10d5ddc0385f39d2c2c62843710b7609a4ca169
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
b10d5ddc0385f39d2c2c62843710b7609a4ca169
+ branch=ovmf
+ revision=b10d5ddc0385f39d2c2c62843710b7609a4ca169
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' xb10d5ddc0385f39d2c2c62843710b7609a4ca169 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 

Re: [Xen-devel] [PATCH v3 10/38] arm/p2m: Move hostp2m init/teardown to individual functions

[Julien Grall]

Hello Sergej,

On 16/08/16 23:16, Sergej Proskurin wrote:

---
 xen/arch/arm/p2m.c| 71 +--
 xen/include/asm-arm/p2m.h | 11 
 2 files changed, 73 insertions(+), 9 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index e859fca..9ef19d4 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1245,27 +1245,53 @@ static void p2m_free_vmid(struct domain *d)
 spin_unlock(_alloc_lock);
 }

-void p2m_teardown(struct domain *d)
+/* Reset this p2m table to be empty. */
+void p2m_flush_table(struct p2m_domain *p2m)
 {
-struct p2m_domain *p2m = p2m_get_hostp2m(d);
-struct page_info *pg;
+struct page_info *page, *pg;
+unsigned int i;
+
+if ( p2m->root )
+{
+page = p2m->root;
+
+/* Clear all concatenated first level pages. */


s/first/root/


+for ( i = 0; i < P2M_ROOT_PAGES; i++ )
+clear_and_clean_page(page + i);


Clearing live page table like that is not safe. Each entry (64-bit) 
should be written atomically to avoid breaking coherency (e.g if the MMU 
is walking the page table at the same time). However you don't know the 
implementation of clear_and_clean_page.


Also, this adds a small overhead when tearing down a p2m because the 
clear is not necessary.



+}
+
+/*
+ * Flush TLBs before releasing remaining intermediate p2m page tables to
+ * prevent illegal access to stalled TLB entries.
+ */
+p2m_flush_tlb(p2m);


p2m_flush_table is called in 2 places:
- p2m_teardown_one
- altp2m_reset

For p2m_teardown_one, the p2m may not have been allocated because the 
initialization failed. So try flush the TLBs may lead to a panic in Xen 
(the vttbr is invalid).


For altp2m_reset, this is called while updating the page tables (see 
altp2m_propagate_change). vCPU may still use the page tables at that time.


I am a bit worry that clear_and_clean_page



+/* Free the rest of the trie pages back to the paging pool. */
 while ( (pg = page_list_remove_head(>pages)) )
 free_domheap_page(pg);

+p2m->lowest_mapped_gfn = INVALID_GFN;
+p2m->max_mapped_gfn = _gfn(0);
+}
+
+void p2m_teardown_one(struct p2m_domain *p2m)
+{
+p2m_flush_table(p2m);
+
 if ( p2m->root )
 free_domheap_pages(p2m->root, P2M_ROOT_ORDER);

 p2m->root = NULL;

-p2m_free_vmid(d);
+p2m_free_vmid(p2m->domain);
+
+p2m->vttbr = INVALID_VTTBR;


Why did you add this line?



 radix_tree_destroy(>mem_access_settings, NULL);
 }

-int p2m_init(struct domain *d)
+int p2m_init_one(struct domain *d, struct p2m_domain *p2m)
 {
-struct p2m_domain *p2m = p2m_get_hostp2m(d);
 int rc = 0;

 rwlock_init(>lock);
@@ -1278,11 +1304,14 @@ int p2m_init(struct domain *d)
 return rc;

 p2m->max_mapped_gfn = _gfn(0);
-p2m->lowest_mapped_gfn = _gfn(ULONG_MAX);
+p2m->lowest_mapped_gfn = INVALID_GFN;


Why this change?



 p2m->domain = d;
+p2m->access_required = false;


This is not necessary as the p2m is zeroed during the allocation.


 p2m->default_access = p2m_access_rwx;
 p2m->mem_access_enabled = false;
+p2m->root = NULL;
+p2m->vttbr = INVALID_VTTBR;


Why do you add those 2 lines?


 radix_tree_init(>mem_access_settings);

 /*
@@ -1293,9 +1322,33 @@ int p2m_init(struct domain *d)
 p2m->clean_pte = iommu_enabled &&
 !iommu_has_feature(d, IOMMU_FEAT_COHERENT_WALK);

-rc = p2m_alloc_table(d);
+return p2m_alloc_table(d);
+}

-return rc;
+static void p2m_teardown_hostp2m(struct domain *d)
+{
+struct p2m_domain *p2m = p2m_get_hostp2m(d);
+
+p2m_teardown_one(p2m);
+}
+
+void p2m_teardown(struct domain *d)
+{
+p2m_teardown_hostp2m(d);
+}
+
+static int p2m_init_hostp2m(struct domain *d)
+{
+struct p2m_domain *p2m = p2m_get_hostp2m(d);
+
+p2m->p2m_class = p2m_host;
+
+return p2m_init_one(d, p2m);
+}
+
+int p2m_init(struct domain *d)
+{
+return p2m_init_hostp2m(d);
 }

 /*
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index fa07e19..1a004ed 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -11,6 +11,8 @@

 #define paddr_bits PADDR_BITS

+#define INVALID_VTTBR (0UL)


Looking at the current use, you only use INVALID_VTTBR to set but not 
tested. However, the 2 places where it is use are not necessary.



+
 /* Holds the bit size of IPAs in p2m tables.  */
 extern unsigned int p2m_ipa_bits;

@@ -226,6 +228,15 @@ void guest_physmap_remove_page(struct domain *d,

 mfn_t gfn_to_mfn(struct domain *d, gfn_t gfn);

+/* Flushes the page table held by the p2m. */
+void p2m_flush_table(struct p2m_domain *p2m);
+
+/* Initialize the p2m structure. */
+int p2m_init_one(struct domain *d, struct p2m_domain *p2m);
+
+/* Release resources held by the p2m structure. */
+void p2m_teardown_one(struct p2m_domain *p2m);
+
 /*
  * P2M rwlock helpers.
  */



Regards,

--
Julien Grall

Re: [Xen-devel] [PATCH v3 08/38] arm/p2m: Free p2m entries only in the hostp2m

[Julien Grall]

Hello Sergej,

On 16/08/16 23:16, Sergej Proskurin wrote:

Freeing p2m entries of arbitrary p2m's (in particular in alternate
p2m's) will lead to unpredicted behavior as the entries might still be
used within the host's p2m. The host's p2m should, however, free the
entries, as it is the main instance responsible for their management. If
entries were freed in the host's p2m, but still reside in one or more of
the alternate p2m's, the change will be propagated to these functions as
will be shown in the following commits.

Signed-off-by: Sergej Proskurin 
---
Cc: Stefano Stabellini 
Cc: Julien Grall 
---
 xen/arch/arm/p2m.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 02e9ee7..bfbccca 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1004,7 +1004,9 @@ static int __p2m_set_entry(struct p2m_domain *p2m,
  * Free the entry only if the original pte was valid and the base
  * is different (to avoid freeing when permission is changed).
  */
-if ( p2m_valid(orig_pte) && entry->p2m.base != orig_pte.p2m.base )
+if ( p2m_valid(orig_pte) &&
+ entry->p2m.base != orig_pte.p2m.base &&
+ p2m_is_hostp2m(p2m) )


With this change, intermediate page table will not be freed which will 
lead to keep the memory used (and therefore unavailable for others) 
until the p2m is effectively destroyed.


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v3 06/38] arm/p2m: Add HVMOP_altp2m_get_domain_state

[Julien Grall]

Hello Sergej,

On 16/08/16 23:16, Sergej Proskurin wrote:

This commit adopts the x86 HVMOP_altp2m_get_domain_state implementation.

Signed-off-by: Sergej Proskurin 
---
Cc: Stefano Stabellini 
Cc: Julien Grall 
---
v3: Removed the "altp2m_enabled" check in HVMOP_altp2m_get_domain_state
case as it has been moved in front of the switch statement in
"do_altp2m_op".

Removed the macro "altp2m_enabled". Instead, check directly for the
HVM_PARAM_ALTP2M param in d->arch.hvm_domain.
---
 xen/arch/arm/hvm.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/hvm.c b/xen/arch/arm/hvm.c
index ce6a436..180154e 100644
--- a/xen/arch/arm/hvm.c
+++ b/xen/arch/arm/hvm.c
@@ -66,7 +66,7 @@ static int do_altp2m_op(XEN_GUEST_HANDLE_PARAM(void) arg)
 goto out;
 }

-if ( !(d)->arch.hvm_domain.params[HVM_PARAM_ALTP2M] )
+if ( !d->arch.hvm_domain.params[HVM_PARAM_ALTP2M] )


Spurious change. This should be merged in patch #4.


 {
 rc = -EINVAL;
 goto out;
@@ -78,7 +78,8 @@ static int do_altp2m_op(XEN_GUEST_HANDLE_PARAM(void) arg)
 switch ( a.cmd )
 {
 case HVMOP_altp2m_get_domain_state:
-rc = -EOPNOTSUPP;
+a.u.domain_state.state = altp2m_active(d);
+rc = __copy_to_guest(arg, , 1) ? -EFAULT : 0;
 break;

 case HVMOP_altp2m_set_domain_state:



Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 0/2] Xen HVM unplug changes

[Paolo Bonzini]

On 01/09/2016 14:11, Olaf Hering wrote:
> Update unplug in Xen HVM guests to cover more cases.
> Please review.
> 
> Olaf
> 
> Olaf Hering (2):
>   xen_platform: unplug also SCSI disks
>   xen_platform: SUSE xenlinux unplug for emulated PCI
> 
>  hw/i386/xen/xen_platform.c | 36 +++-
>  1 file changed, 35 insertions(+), 1 deletion(-)
> 

Looks good with the checkpatch complaints fixed.

Paolo

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

Re: [Xen-devel] [PATCH v3 04/38] arm/p2m: Add first altp2m HVMOP stubs

[Julien Grall]

Hello Sergej,

On 16/08/16 23:16, Sergej Proskurin wrote:

This commit moves the altp2m-related code from x86 to ARM. Functions


s/moves/copies/

However, this is not really true because the code is current patch is 
not a verbatim copy.


Lastly, what is the status to have x86 and ARM implementation of 
do_altp2m_op merged?


It would allow us to get code clean-up more easily. I have in mind the 
recent patch [1] from Paul Lai.


I am also worry to see the code diverging, for instance the locking is 
likely needed on x86 too.



that are no yet supported notify the caller or print a BUG message
stating their absence.

Also, the struct arch_domain is extended with the altp2m_active
attribute, representing the current altp2m activity configuration of the
domain.

Signed-off-by: Sergej Proskurin 
---
Cc: Stefano Stabellini 
Cc: Julien Grall 
---
v2: Removed altp2m command-line option: Guard through HVM_PARAM_ALTP2M.
Removed not used altp2m helper stubs in altp2m.h.

v3: Cosmetic fixes.

Added domain lock in "do_altp2m_op" to avoid concurrent execution of
altp2m-related HVMOPs.

Added check making sure that HVM_PARAM_ALTP2M is set before
execution of altp2m-related HVMOPs.
---
 xen/arch/arm/hvm.c   | 89 
 xen/include/asm-arm/altp2m.h |  4 +-
 xen/include/asm-arm/domain.h |  3 ++
 3 files changed, 94 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/hvm.c b/xen/arch/arm/hvm.c
index d999bde..45d51c6 100644
--- a/xen/arch/arm/hvm.c
+++ b/xen/arch/arm/hvm.c
@@ -32,6 +32,91 @@

 #include 

+#include 
+
+static int do_altp2m_op(XEN_GUEST_HANDLE_PARAM(void) arg)
+{
+struct xen_hvm_altp2m_op a;
+struct domain *d = NULL;
+int rc = 0;
+
+if ( copy_from_guest(, arg, 1) )
+return -EFAULT;
+
+if ( a.pad1 || a.pad2 ||
+ (a.version != HVMOP_ALTP2M_INTERFACE_VERSION) ||
+ (a.cmd < HVMOP_altp2m_get_domain_state) ||
+ (a.cmd > HVMOP_altp2m_change_gfn) )
+return -EINVAL;
+
+d = (a.cmd != HVMOP_altp2m_vcpu_enable_notify) ?
+rcu_lock_domain_by_any_id(a.domain) : rcu_lock_current_domain();
+
+if ( d == NULL )
+return -ESRCH;
+
+/* Prevent concurrent execution of the following HVMOPs. */
+domain_lock(d);


So you are not allowing concurrent call of set_mem_access on different 
altp2m. Is it something that you plan to fix in the future?



+
+if ( (a.cmd != HVMOP_altp2m_get_domain_state) &&
+ (a.cmd != HVMOP_altp2m_set_domain_state) &&
+ !altp2m_active(d) )
+{
+rc = -EOPNOTSUPP;
+goto out;
+}
+
+if ( !(d)->arch.hvm_domain.params[HVM_PARAM_ALTP2M] )
+{
+rc = -EINVAL;
+goto out;
+}
+
+if ( (rc = xsm_hvm_altp2mhvm_op(XSM_TARGET, d)) )
+goto out;
+
+switch ( a.cmd )
+{
+case HVMOP_altp2m_get_domain_state:
+rc = -EOPNOTSUPP;
+break;
+
+case HVMOP_altp2m_set_domain_state:
+rc = -EOPNOTSUPP;
+break;
+
+case HVMOP_altp2m_vcpu_enable_notify:
+rc = -EOPNOTSUPP;
+break;
+
+case HVMOP_altp2m_create_p2m:
+rc = -EOPNOTSUPP;
+break;
+
+case HVMOP_altp2m_destroy_p2m:
+rc = -EOPNOTSUPP;
+break;
+
+case HVMOP_altp2m_switch_p2m:
+rc = -EOPNOTSUPP;
+break;
+
+case HVMOP_altp2m_set_mem_access:
+rc = -EOPNOTSUPP;
+break;
+
+case HVMOP_altp2m_change_gfn:
+rc = -EOPNOTSUPP;
+break;
+}
+
+out:
+domain_unlock(d);
+rcu_unlock_domain(d);
+
+return rc;
+}
+
 long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
 long rc = 0;
@@ -80,6 +165,10 @@ long do_hvm_op(unsigned long op, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 rc = -EINVAL;
 break;

+case HVMOP_altp2m:
+rc = do_altp2m_op(arg);
+break;
+
 default:
 {
 gdprintk(XENLOG_DEBUG, "HVMOP op=%lu: not implemented\n", op);
diff --git a/xen/include/asm-arm/altp2m.h b/xen/include/asm-arm/altp2m.h
index a87747a..0711796 100644
--- a/xen/include/asm-arm/altp2m.h
+++ b/xen/include/asm-arm/altp2m.h
@@ -2,6 +2,7 @@
  * Alternate p2m
  *
  * Copyright (c) 2014, Intel Corporation.
+ * Copyright (c) 2016, Sergej Proskurin .
  *
  * This program is free software; you can redistribute it and/or modify it
  * under the terms and conditions of the GNU General Public License,
@@ -24,8 +25,7 @@
 /* Alternate p2m on/off per domain */
 static inline bool_t altp2m_active(const struct domain *d)
 {
-/* Not implemented on ARM. */
-return 0;
+return d->arch.altp2m_active;
 }

 /* Alternate p2m VCPU */
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 9452fcd..cc4bda0 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -126,6 +126,9 @@ struct arch_domain
 paddr_t 

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 5322ee484b54bc78023383a546971b601dcc4ce1
baseline version:
 ovmf 00afc8f82061677fedc86cb05e3b8c75a3c986ff

Last test of basis   100692  2016-09-01 09:14:38 Z0 days
Testing same since   100699  2016-09-01 14:14:06 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 

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



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=5322ee484b54bc78023383a546971b601dcc4ce1
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
5322ee484b54bc78023383a546971b601dcc4ce1
+ branch=ovmf
+ revision=5322ee484b54bc78023383a546971b601dcc4ce1
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' x5322ee484b54bc78023383a546971b601dcc4ce1 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 00afc8f82061677fedc86cb05e3b8c75a3c986ff
baseline version:
 ovmf 950a3bc788b5b101729b26aed3ff75fd2a64a570

Last test of basis67619  2016-09-01 09:16:28 Z0 days
Testing same since67620  2016-09-01 13:46:26 Z0 days1 attempts


People who touched revisions under test:
  Dandan Bi 

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



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

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

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


Push not applicable.


commit 00afc8f82061677fedc86cb05e3b8c75a3c986ff
Author: Dandan Bi 
Date:   Tue Aug 23 10:29:08 2016 +0800

ShellPkg: Fix the incorrect return status in function FindFiles()

According to the latest shell spec, in function FindFiles(),
when no files were found, it should return EFI_NOT_FOUND.
But current codes don't follow the spec.
This patch is to fix this issue.

Cc: Ruiyu Ni 
Cc: Jaben Carsey 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
Reviewed-by: Ruiyu Ni 

commit c6fc823413861c6bcafbb21bae9aab66b8ee5a24
Author: Dandan Bi 
Date:   Wed Aug 31 13:09:26 2016 +0800

ShellPkg: Add the check of parameter number in "DrvCfg" command

In shell spec, the usage of "Drvcfg" command is: drvcfg [-l XXX] [-c]
[-f |-v|-s] [DriverHandle [DeviceHandle [ChildHandle]]]
[-i filename] [-o filename]. The parameter number(doesn't include the flags)
cannot exceed 4, now we add this point to check whether using the command
correctly.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
Reviewed-by: Ruiyu Ni 
Reviewed-by: Jaben Carsey 
Reviewed-by: Tapan Shah 

commit d653d8062e48480a3ec689d688343306bb102b73
Author: Dandan Bi 
Date:   Thu Aug 25 09:37:05 2016 +0800

ShellPkg: Add check for "dump" parameter in "bcfg" command

When user uses the command "bcfg driver|boot [dump [-v]]",
the number of command line value parameters (doesn't include the
flag) must be three. We can add this point to check whether using
this command correctly.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
Reviewed-by: Ruiyu Ni 
Reviewed-by: Jaben Carsey 
Reviewed-by: Tapan Shah 

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

Re: [Xen-devel] [PATCH v3 03/38] arm/p2m: Introduce p2m_(switch|restore)_vttbr_and_(g|s)et_flags

[Julien Grall]

Hello Sergej,

On 16/08/16 23:16, Sergej Proskurin wrote:

This commit introduces macros for switching and restoring the vttbr
considering the currently set irq flags. We define these macros, as the
following commits will use the associated functionality multiple times
throughout the file ./xen/arch/arm/p2m.c.

Signed-off-by: Sergej Proskurin 
---
Cc: Stefano Stabellini 
Cc: Julien Grall 
---
 xen/arch/arm/p2m.c | 37 +++--
 1 file changed, 23 insertions(+), 14 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 08114d8..02e9ee7 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -27,6 +27,26 @@ static unsigned int __read_mostly p2m_root_level;

 #define P2M_ROOT_PAGES(1<vttbr )
-{
-local_irq_save(flags);
-WRITE_SYSREG64(p2m->vttbr, VTTBR_EL2);
-isb();
-}
+p2m_switch_vttbr_and_get_flags(ovttbr, p2m->vttbr, flags);

 flush_tlb();

-if ( ovttbr != READ_SYSREG64(VTTBR_EL2) )
-{
-WRITE_SYSREG64(ovttbr, VTTBR_EL2);
-isb();
-local_irq_restore(flags);
-}
+p2m_restore_vttbr_and_set_flags(ovttbr, flags);
 }

 /*



Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v3 02/38] arm/p2m: Expose p2m_*lock helpers

[Julien Grall]

Hello Sergej,

On 16/08/16 23:16, Sergej Proskurin wrote:

This commit exposes the "p2m_*lock" helpers, as they will be used within
the file ./xen/arch/arm/altp2m.c, as will be shown in the following
commits.

Signed-off-by: Sergej Proskurin 
---
Cc: Stefano Stabellini 
Cc: Julien Grall 
---
 xen/arch/arm/p2m.c| 12 ++--
 xen/include/asm-arm/p2m.h | 16 
 2 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index da6c7d4..08114d8 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -62,14 +62,14 @@ static inline bool_t p2m_is_superpage(lpae_t pte, unsigned 
int level)
 return (level < 3) && p2m_mapping(pte);
 }

-static inline void p2m_write_lock(struct p2m_domain *p2m)
+void p2m_write_lock(struct p2m_domain *p2m)


This will introduce an overhead when locking the p2m. Those helpers 
should be moved a inline in p2m.h and not transform to a functions.


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v3 01/38] arm/p2m: Cosmetic fixes - apply p2m_get_hostp2m

[Julien Grall]

Hello Sergej,

On 16/08/16 23:16, Sergej Proskurin wrote:

This commit substitutes the direct access of the host's p2m
(>arch.p2m) for the macro "p2m_get_hostp2m". This macro simplifies
the differentiation between the host's p2m and introduced alternative
p2m's, in the following commits.

Signed-off-by: Sergej Proskurin 


Acked-by: Julien Grall 

Regards,

--
Julien Grall

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 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

version targeted for testing:
 xen  a4f39a6450abe5207cb33f877b4b6cd5db8a6cca
baseline version:
 xen  08e7738ec3644350fbac0325085baac6b3c7cd11

Last test of basis   100697  2016-09-01 12:01:45 Z0 days
Testing same since   100698  2016-09-01 14:01:50 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=a4f39a6450abe5207cb33f877b4b6cd5db8a6cca
+ . ./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 xen-unstable-smoke 
a4f39a6450abe5207cb33f877b4b6cd5db8a6cca
+ branch=xen-unstable-smoke
+ revision=a4f39a6450abe5207cb33f877b4b6cd5db8a6cca
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.7-testing
+ '[' xa4f39a6450abe5207cb33f877b4b6cd5db8a6cca = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' 

Re: [Xen-devel] [PATCH] x86: correct CPUID output for out of bounds input

[Jan Beulich]

>>> On 01.09.16 at 16:27,  wrote:
> On 24/08/16 16:31, Jan Beulich wrote:
>> Another place where we should try to behave like real hardware; see
>> the code comments.
>>
>> Signed-off-by: Jan Beulich 
>>
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -3358,6 +3358,31 @@ void hvm_cpuid(unsigned int input, unsig
>>  if ( !edx )
>>  edx = 
>>  
>> +if ( input & 0x )
>> +{
>> +/*
>> + * Requests beyond the highest supported leaf within a group return
>> + * zero on AMD and the highest basic leaf output on others.
>> + */
>> +unsigned int lvl;
>> +
>> +hvm_cpuid(input & 0x, , NULL, NULL, NULL);
>> +if ( ((lvl ^ input) >> 16) || input > lvl )
> 
> This logic isn't correct.  It doesn't cope in the Intel case when lvl
> aliases the upper 16 bits of input, despite input being an unknown group.
> 
> When I considered the problem before, the only functioning logic I came
> up with was to know that for Intel, input = 0x8000 is the only
> special case which doesn't collapse into the highest basic leaf.

If we had followed to Intel model before the extended leaf got
introduced, we'd have been incompatible with the extended leaf.
If ever someone introduces another group, we'd then again be
screwed. Yes, we can follow the Intel model, but I intentionally
tried to make the code more forward compatible.

>> +{
>> +if ( d->arch.x86_vendor == X86_VENDOR_AMD )
>> +{
>> +*eax = 0;
>> +*ebx = 0;
>> +*ecx = 0;
>> +*edx = 0;
>> +return;
>> +}
>> +if ( input >> 16 )
>> +hvm_cpuid(0, , NULL, NULL, NULL);
> 
> Is this really the right way round?  The AMD method of "reserved always
> as zero" is the more sane default to take.

If anything I'd then say let's _always_ follow the AMD model.

> I have looked at the Transmeta and Cyrix CPUID docs, and they are
> non-specific as to what reserved means.

While the Cyrix box I have doesn't stay up long enough anymore
to try out in practice, I do recall that in various aspects they very
closely followed what Intel does. There not being any 64-bit
Transmeta CPUs we support, I don't think we currently care about
their behavior.

Jan


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

Re: [Xen-devel] [PATCH v2 19/20] livepatch/elf: Adjust section aligment to word

[Julien Grall]

Hi,

On 25/08/16 16:11, Jan Beulich wrote:

On 25.08.16 at 15:37,  wrote:

On most architectures it does not matter what the aligment is.

On ARM32 it is paramount that the aligment is word-size (4)
otherwise we get a Data Abort when trying to perform ELF
relocations. That is due to ARM 32 only being able to write to
word-aligned addresses.


Well, it is the same on ARM64. However we decided to disable the 
alignment check (SCTLR.A not set) because some of the primitives 
imported from Linux (e.g memcpy) rely on the hardware handling misalignment.


In any case, I would not recommend to use unaligned access on ARM as 
they may have a big performance impact.




That's not exactly true, afaik: ARM can write to byte- and
half-word-aligned addresses, but only bytes/half-words.


That's correct.

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH RFC] x86/32on64: don't modify guest descriptors without need

[Jan Beulich]

>>> On 01.09.16 at 16:37,  wrote:
> On 29/08/16 14:57, Jan Beulich wrote:
>> The less obvious (and potentially controversial) part is that of a call
>> gate with DPL < selector.RPL: Such gates can't be used either without
>> the hardware raising #GP, but the specific case of DPL=0 gets handled
>> in emulate_gate_op(). The purpose of the change is to avoid adjusting
>> a gate a second time when it did get adjusted already here, on the
>> assumption that guest OSes wouldn't normally install unusable gates
>> (i.e. we'd normally see DPL >= selector.RPL) and still have a way of
>> installing an unusable gate (by specifying a non-zero DPL right away).
>>
>> Aforementioned second time adjustments of gates are a problem for
>> environments where
>> - per-CPU GDTs get cloned from the boot CPU's after the boot CPU had
>>   already installed its GDT (e.g. Linux),
>> - individual descriptors get installed via hypercall prior to actually
>>   making the respective page a descriptor one (this could alternatively
>>   be taken care of by making do_update_descriptor() call
>>   check_descriptor() only when modifying a PGT_seg_desc page),
>> i.e. the hypervisor gets presented an already adjusted descriptor a
>> second time.
> 
> Are these problems which currently manifest themselves?

I've run into the first of the two issues when testing other gate
op emulation changes.

> I don't think we should be making any assumptions about what a guest
> might or might not do.

Generally I agree, but by modifying the RPL of the selector in the
gate descriptor we already fiddle with what the guest has given us.
Ideally we'd get away without doing so, but I can't see any
reasonable way to elsewhere store the two DPL bits. Hence I'd
prefer to at least get things as usable as possible.

Jan


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

Re: [Xen-devel] [PATCH v2 14/20] livepatch: ARM 32|64: Ignore mapping symbols: $[d, a, x, t]

[Julien Grall]

Hi Konrad,

On 25/08/16 14:37, Konrad Rzeszutek Wilk wrote:

Those symbols are used to help final linkers to replace insn.
The ARM ELF specification mandates that they are present
to denote the start of certain CPU features. There are two
variants of it - short and long format.

Either way - we can ignore these symbols.

Signed-off-by: Konrad Rzeszutek Wilk 

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

v1: First submission
v2: Update the order of symbols, fix title
Add {} in after the first if - per Jan's recommendation.
---
 xen/arch/arm/livepatch.c| 32 
 xen/arch/x86/livepatch.c|  7 +++
 xen/common/livepatch.c  |  2 +-
 xen/include/xen/livepatch.h |  2 ++
 4 files changed, 42 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/livepatch.c b/xen/arch/arm/livepatch.c
index f49e347..c290602 100644
--- a/xen/arch/arm/livepatch.c
+++ b/xen/arch/arm/livepatch.c
@@ -82,6 +82,38 @@ void arch_livepatch_unmask(void)
 local_abort_enable();
 }

+int arch_is_payload_symbol(const struct livepatch_elf *elf,
+   const struct livepatch_elf_sym *sym)


I think this function should return bool (or bool_t) as the return will 
be used by is_payload_symbol as bool.



+{
+/*
+ * - Mapping symbols - denote the "start of a sequence of bytes of the
+ *   appropiate type" to mark certain features - such as start of region


s/appropiate/appropriate/


+ *   containing data ($d); ARM ($a), A64 ($x), or Thumb instructions ($t).
+ *
+ * The format is either short: '$x' or long: '$x.'. We do not
+ * need this and more importantly - each payload will contain this
+ * resulting in symbol collisions.
+ */
+if ( *sym->name == '$' && sym->name[1] != '\0' )
+{
+char p = sym->name[1];
+size_t len = strlen(sym->name);
+
+if ( (len >= 3 && ( sym->name[2] == '.' )) || (len == 2) )
+{
+if ( p == 'd' ||
+#ifdef CONFIG_ARM_32
+ p == 'a' || p == 't'


Note that Xen is not using Thumb instructions which have variable 
length, so we shouldn't expect to see $t. symbols.



+#else
+ p == 'x'
+#endif
+   )
+return 0;


Please use false here.


+}
+}
+return 1;


Please use true here.


+}
+


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH RFC] x86/32on64: don't modify guest descriptors without need

[Andrew Cooper]

On 29/08/16 14:57, Jan Beulich wrote:
> There are two cases: The obvious one is that system gates with type 0
> shouldn't have what might be their DPL altered - such descriptors can't
> be used anyway without incurring a #GP, and hence adjusting its DPL is
> only risking to confuse the guest.

This is fine.

>
> The less obvious (and potentially controversial) part is that of a call
> gate with DPL < selector.RPL: Such gates can't be used either without
> the hardware raising #GP, but the specific case of DPL=0 gets handled
> in emulate_gate_op(). The purpose of the change is to avoid adjusting
> a gate a second time when it did get adjusted already here, on the
> assumption that guest OSes wouldn't normally install unusable gates
> (i.e. we'd normally see DPL >= selector.RPL) and still have a way of
> installing an unusable gate (by specifying a non-zero DPL right away).
>
> Aforementioned second time adjustments of gates are a problem for
> environments where
> - per-CPU GDTs get cloned from the boot CPU's after the boot CPU had
>   already installed its GDT (e.g. Linux),
> - individual descriptors get installed via hypercall prior to actually
>   making the respective page a descriptor one (this could alternatively
>   be taken care of by making do_update_descriptor() call
>   check_descriptor() only when modifying a PGT_seg_desc page),
> i.e. the hypervisor gets presented an already adjusted descriptor a
> second time.

Are these problems which currently manifest themselves?

I don't think we should be making any assumptions about what a guest
might or might not do.

~Andrew

>
> Signed-off-by: Jan Beulich 
> ---
> RFC reason: As mentioned above the change in behavior here might be
> controversial. The main question here appears to be whether
> this is viewed as having the potential for undermining
> guest OS security.


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

Re: [Xen-devel] [PATCH] x86: correct CPUID output for out of bounds input

[Andrew Cooper]

On 24/08/16 16:31, Jan Beulich wrote:
> Another place where we should try to behave like real hardware; see
> the code comments.
>
> Signed-off-by: Jan Beulich 
>
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -3358,6 +3358,31 @@ void hvm_cpuid(unsigned int input, unsig
>  if ( !edx )
>  edx = 
>  
> +if ( input & 0x )
> +{
> +/*
> + * Requests beyond the highest supported leaf within a group return
> + * zero on AMD and the highest basic leaf output on others.
> + */
> +unsigned int lvl;
> +
> +hvm_cpuid(input & 0x, , NULL, NULL, NULL);
> +if ( ((lvl ^ input) >> 16) || input > lvl )

This logic isn't correct.  It doesn't cope in the Intel case when lvl
aliases the upper 16 bits of input, despite input being an unknown group.

When I considered the problem before, the only functioning logic I came
up with was to know that for Intel, input = 0x8000 is the only
special case which doesn't collapse into the highest basic leaf.

> +{
> +if ( d->arch.x86_vendor == X86_VENDOR_AMD )
> +{
> +*eax = 0;
> +*ebx = 0;
> +*ecx = 0;
> +*edx = 0;
> +return;
> +}
> +if ( input >> 16 )
> +hvm_cpuid(0, , NULL, NULL, NULL);

Is this really the right way round?  The AMD method of "reserved always
as zero" is the more sane default to take.

I have looked at the Transmeta and Cyrix CPUID docs, and they are
non-specific as to what reserved means.

~Andrew

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

Re: [Xen-devel] [PATCH v2] x86/monitor: Include EAX/ECX in CPUID monitor events

[Andrew Cooper]

On 01/09/16 15:10, Tamas K Lengyel wrote:
> Extend the CPUID monitor event to include EAX and ECX values that were used
> when CPUID was executed. This is useful in identifying which leaf was queried.
> We also adjust the xen-access output format to more closely resemble the 
> output
> of the Linux cpuid tool's raw format.
>
> Signed-off-by: Tamas K Lengyel 
> ---
> Cc: Razvan Cojocaru 
> Cc: Ian Jackson 
> Cc: Wei Liu 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> Cc: Jun Nakajima 
> Cc: Kevin Tian 
>
> v2: Rename eax/ecx to leaf and subleaf
> Correct typo

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH] x86: correct CPUID output for out of bounds input

[Andrew Cooper]

On 01/09/16 13:56, Jan Beulich wrote:
 On 01.09.16 at 13:23,  wrote:
>> On 24/08/16 16:31, Jan Beulich wrote:
>>> Another place where we should try to behave like real hardware; see
>>> the code comments.
>>>
>>> Signed-off-by: Jan Beulich 
>>>
>>> --- a/xen/arch/x86/hvm/hvm.c
>>> +++ b/xen/arch/x86/hvm/hvm.c
>>> @@ -3358,6 +3358,31 @@ void hvm_cpuid(unsigned int input, unsig
>>>  if ( !edx )
>>>  edx = 
>>>  
>>> +if ( input & 0x )
>>> +{
>>> +/*
>>> + * Requests beyond the highest supported leaf within a group return
>>> + * zero on AMD and the highest basic leaf output on others.
>>> + */
>>> +unsigned int lvl;
>>> +
>>> +hvm_cpuid(input & 0x, , NULL, NULL, NULL);
>> I have specifically deferred fixing this issue so far, because I don't
>> want to increase the quantity of recursion with hvm_cpuid().
>>
>> Also, because of the poor datastructure for domain cpuid, this adds 1
>> and possibly 2 extra loops over the unordered list.
>>
>>
>> On the way back from Toronto, I started experimenting with my
>> full-policy plans, including a structured information layout so
>> cpuid.basic.max_leaf can be found directly, and starting a guest_cpuid()
>> function intending to replace both pv_cpuid() and hvm_cpuid() in due course.
>>
>> Would you be amenable to leaving this issue as-is for now, until there
>> is a more efficient way of fixing it?
> If you get this ready for 4.8, yes. Otherwise I think the variant here
> is better than nothing until yours arrives.

There is no way it will be done for 4.8.

~Andrew

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

Re: [Xen-devel] [PATCH v2 13/20] livepatch: Initial ARM64 support.

[Julien Grall]

Hi Konrad,

On 25/08/16 14:37, Konrad Rzeszutek Wilk wrote:

As compared to x86 the va of the hypervisor .text
is locked down - we cannot modify the running pagetables
to have the .ro flag unset. We borrow the same idea that
alternative patching has - which is to vmap the entire
.text region and use the alternative virtual address
for patching.

Since we are doing vmap we may fail, hence the
arch_livepatch_quiesce was changed (see "x86,arm:
Change arch_livepatch_quiesce() decleration") to return


s/decleration/declaration/


an error value which will be bubbled in payload->rc and
provided to the user (along with messages in the ring buffer).

The livepatch virtual address space (where the new functions
are) needs to be close to the hypervisor virtual address
so that the trampoline can reach it. As such we re-use
the BOOT_RELOC_VIRT_START which is not used after bootup
(alternatively we can also use the space after the _end to
FIXMAP_ADDR(0), but that may be too small).

The ELF relocation engine at the start was coded from
the "ELF for the ARM 64-bit Architecture (AArch64)"
(http://infocenter.arm.com/help/topic/com.arm.doc.ihi0056b/IHI0056B_aaelf64.pdf)
but after a while of trying to write the correct bit shifting
and masking from scratch I ended up borrowing from Linux, the
'reloc_insn_imm' (Linux v4.7 arch/arm64/kernel/module.c function.
See 257cb251925f854da435cbf79b140984413871ac "arm64: Loadable modules")

And while at it - we also utilize code from Linux to construct
the right branch instruction (see "arm64/insn: introduce
aarch64_insn_gen_{nop|branch_imm}() helper functions").

In the livepatch payload loading code we tweak the #ifdef to
only exclude ARM_32. The exceptions are not part of ARM 32/64 hence
they are still behind the #ifdef.

We also expand the MAINTAINERS file to include the arm64 and arm32
platform specific livepatch file.

Signed-off-by: Konrad Rzeszutek Wilk 


[...]


diff --git a/xen/arch/arm/arm64/livepatch.c b/xen/arch/arm/arm64/livepatch.c
new file mode 100644
index 000..0809a42
--- /dev/null
+++ b/xen/arch/arm/arm64/livepatch.c
@@ -0,0 +1,323 @@
+/*
+ *  Copyright (c) 2016 Oracle and/or its affiliates. All rights reserved.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+void arch_livepatch_apply_jmp(struct livepatch_func *func)
+{
+uint32_t insn;
+uint32_t *old_ptr;
+uint32_t *new_ptr;
+
+BUILD_BUG_ON(PATCH_INSN_SIZE > sizeof(func->opaque));
+BUILD_BUG_ON(PATCH_INSN_SIZE != sizeof(insn));
+
+ASSERT(vmap_of_xen_text);
+
+/* Save old one. */
+old_ptr = func->old_addr;
+memcpy(func->opaque, old_ptr, PATCH_INSN_SIZE);


I don't see any value to use a temporary variable (old_ptr) to hold 
func->old_addr here.



+
+if ( func->new_addr )
+insn = aarch64_insn_gen_branch_imm((unsigned long)func->old_addr,
+   (unsigned long)func->new_addr,
+   AARCH64_INSN_BRANCH_NOLINK);
+else
+insn = aarch64_insn_gen_nop();
+
+ASSERT(insn != AARCH64_BREAK_FAULT);


Could you document in the code what prevents aarch64_insn_gen_branch_imm 
to not generate a break fault instruction?



+new_ptr = func->old_addr - (void *)_start + vmap_of_xen_text;
+
+/* PATCH! */
+*(new_ptr) = cpu_to_le32(insn);
+
+clean_and_invalidate_dcache_va_range(new_ptr, sizeof(*new_ptr));
+}
+
+void arch_livepatch_revert_jmp(const struct livepatch_func *func)
+{
+uint32_t *new_ptr;
+uint32_t insn;
+
+memcpy(, func->opaque, PATCH_INSN_SIZE);
+
+new_ptr = (uint32_t *)func->old_addr - (u32 *)_start + vmap_of_xen_text;


The computation here looks wrong. You are mixing (u32 *) and (void *).


+
+/* PATCH! */
+*(new_ptr) = cpu_to_le32(insn);
+
+clean_and_invalidate_dcache_va_range(new_ptr, sizeof(*new_ptr));
+}
+
+int arch_livepatch_verify_elf(const struct livepatch_elf *elf)
+{
+const Elf_Ehdr *hdr = elf->hdr;
+
+if ( hdr->e_machine != EM_AARCH64 ||
+ hdr->e_ident[EI_CLASS] != ELFCLASS64 )
+{
+dprintk(XENLOG_ERR, LIVEPATCH "%s: Unsupported ELF Machine type!\n",
+elf->name);
+return -EOPNOTSUPP;
+}
+
+return 0;
+}
+
+enum aarch64_reloc_op {
+RELOC_OP_NONE,
+RELOC_OP_ABS,
+RELOC_OP_PREL,
+RELOC_OP_PAGE,
+};
+
+static u64 do_reloc(enum aarch64_reloc_op reloc_op, void *place, u64 val)
+{
+switch (reloc_op) {


This seems to be a left-over of the Linux coding style.


+case RELOC_OP_ABS:
+return val;
+
+case RELOC_OP_PREL:
+return val - (u64)place;
+
+case RELOC_OP_PAGE:
+return (val & ~0xfff) - ((u64)place & ~0xfff);
+
+case RELOC_OP_NONE:
+return 0;
+
+}
+
+dprintk(XENLOG_DEBUG, LIVEPATCH "do_reloc: unknown relocation operation 
%d\n", reloc_op);


NIT: Please add a blank line here.


+return 0;
+}
+

Re: [Xen-devel] [PATCH v2] x86/monitor: Include EAX/ECX in CPUID monitor events

[Razvan Cojocaru]

On 09/01/2016 05:10 PM, Tamas K Lengyel wrote:
> Extend the CPUID monitor event to include EAX and ECX values that were used
> when CPUID was executed. This is useful in identifying which leaf was queried.
> We also adjust the xen-access output format to more closely resemble the 
> output
> of the Linux cpuid tool's raw format.
> 
> Signed-off-by: Tamas K Lengyel 
> ---
> Cc: Razvan Cojocaru 
> Cc: Ian Jackson 
> Cc: Wei Liu 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> Cc: Jun Nakajima 
> Cc: Kevin Tian 
> 
> v2: Rename eax/ecx to leaf and subleaf
> Correct typo
> ---
>  tools/tests/xen-access/xen-access.c | 4 +++-
>  xen/arch/x86/hvm/monitor.c  | 5 -
>  xen/arch/x86/hvm/vmx/vmx.c  | 6 +-
>  xen/include/asm-x86/hvm/monitor.h   | 3 ++-
>  xen/include/public/vm_event.h   | 2 ++
>  5 files changed, 16 insertions(+), 4 deletions(-)

Acked-by: Razvan Cojocaru 


Thanks,
Razvan

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

[Xen-devel] [PATCH v2] x86/monitor: Include EAX/ECX in CPUID monitor events

[Tamas K Lengyel]

Extend the CPUID monitor event to include EAX and ECX values that were used
when CPUID was executed. This is useful in identifying which leaf was queried.
We also adjust the xen-access output format to more closely resemble the output
of the Linux cpuid tool's raw format.

Signed-off-by: Tamas K Lengyel 
---
Cc: Razvan Cojocaru 
Cc: Ian Jackson 
Cc: Wei Liu 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Jun Nakajima 
Cc: Kevin Tian 

v2: Rename eax/ecx to leaf and subleaf
Correct typo
---
 tools/tests/xen-access/xen-access.c | 4 +++-
 xen/arch/x86/hvm/monitor.c  | 5 -
 xen/arch/x86/hvm/vmx/vmx.c  | 6 +-
 xen/include/asm-x86/hvm/monitor.h   | 3 ++-
 xen/include/public/vm_event.h   | 2 ++
 5 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/tools/tests/xen-access/xen-access.c 
b/tools/tests/xen-access/xen-access.c
index ebb63b1..ed18c71 100644
--- a/tools/tests/xen-access/xen-access.c
+++ b/tools/tests/xen-access/xen-access.c
@@ -735,10 +735,12 @@ int main(int argc, char *argv[])
 break;
 case VM_EVENT_REASON_CPUID:
 printf("CPUID executed: rip=%016"PRIx64", vcpu %d. Insn 
length: %"PRIu32" " \
-   "EAX: 0x%"PRIx64" EBX: 0x%"PRIx64" ECX: 0x%"PRIx64" 
EDX: 0x%"PRIx64"\n",
+   "0x%"PRIx32" 0x%"PRIx32": EAX=0x%"PRIx64" 
EBX=0x%"PRIx64" ECX=0x%"PRIx64" EDX=0x%"PRIx64"\n",
req.data.regs.x86.rip,
req.vcpu_id,
req.u.cpuid.insn_length,
+   req.u.cpuid.leaf,
+   req.u.cpuid.subleaf,
req.data.regs.x86.rax,
req.data.regs.x86.rbx,
req.data.regs.x86.rcx,
diff --git a/xen/arch/x86/hvm/monitor.c b/xen/arch/x86/hvm/monitor.c
index 7277c12..53ab804 100644
--- a/xen/arch/x86/hvm/monitor.c
+++ b/xen/arch/x86/hvm/monitor.c
@@ -136,7 +136,8 @@ int hvm_monitor_debug(unsigned long rip, enum 
hvm_monitor_debug_type type,
 return monitor_traps(curr, sync, );
 }
 
-int hvm_monitor_cpuid(unsigned long insn_length)
+int hvm_monitor_cpuid(unsigned long insn_length, unsigned int leaf,
+  unsigned int subleaf)
 {
 struct vcpu *curr = current;
 struct arch_domain *ad = >domain->arch;
@@ -148,6 +149,8 @@ int hvm_monitor_cpuid(unsigned long insn_length)
 req.reason = VM_EVENT_REASON_CPUID;
 req.vcpu_id = curr->vcpu_id;
 req.u.cpuid.insn_length = insn_length;
+req.u.cpuid.leaf = leaf;
+req.u.cpuid.subleaf = subleaf;
 
 return monitor_traps(curr, 1, );
 }
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 3d330b6..bb7a329 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2402,12 +2402,16 @@ static void vmx_cpuid_intercept(
 static int vmx_do_cpuid(struct cpu_user_regs *regs)
 {
 unsigned int eax, ebx, ecx, edx;
+unsigned int leaf, subleaf;
 
 eax = regs->eax;
 ebx = regs->ebx;
 ecx = regs->ecx;
 edx = regs->edx;
 
+leaf = regs->eax;
+subleaf = regs->ecx;
+
 vmx_cpuid_intercept(, , , );
 
 regs->eax = eax;
@@ -2415,7 +2419,7 @@ static int vmx_do_cpuid(struct cpu_user_regs *regs)
 regs->ecx = ecx;
 regs->edx = edx;
 
-return hvm_monitor_cpuid(get_instruction_length());
+return hvm_monitor_cpuid(get_instruction_length(), leaf, subleaf);
 }
 
 static void vmx_dr_access(unsigned long exit_qualification,
diff --git a/xen/include/asm-x86/hvm/monitor.h 
b/xen/include/asm-x86/hvm/monitor.h
index a92f3fc..82b85ec 100644
--- a/xen/include/asm-x86/hvm/monitor.h
+++ b/xen/include/asm-x86/hvm/monitor.h
@@ -40,7 +40,8 @@ bool_t hvm_monitor_cr(unsigned int index, unsigned long value,
 void hvm_monitor_msr(unsigned int msr, uint64_t value);
 int hvm_monitor_debug(unsigned long rip, enum hvm_monitor_debug_type type,
   unsigned long trap_type, unsigned long insn_length);
-int hvm_monitor_cpuid(unsigned long insn_length);
+int hvm_monitor_cpuid(unsigned long insn_length, unsigned int leaf,
+  unsigned int subleaf);
 
 #endif /* __ASM_X86_HVM_MONITOR_H__ */
 
diff --git a/xen/include/public/vm_event.h b/xen/include/public/vm_event.h
index 64e6857..99d60ea 100644
--- a/xen/include/public/vm_event.h
+++ b/xen/include/public/vm_event.h
@@ -226,6 +226,8 @@ struct vm_event_mov_to_msr {
 
 struct vm_event_cpuid {
 uint32_t insn_length;
+uint32_t leaf;
+uint32_t subleaf;
 uint32_t _pad;
 };
 
-- 
2.9.3


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

Re: [Xen-devel] [PATCH] x86/monitor: Include EAX/ECX in CPUID monitor events

[Tamas K Lengyel]

On Thu, Sep 1, 2016 at 2:01 AM, Jan Beulich  wrote:
 On 01.09.16 at 01:52,  wrote:
>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> @@ -2402,12 +2402,17 @@ static void vmx_cpuid_intercept(
>>  static int vmx_do_cpuid(struct cpu_user_regs *regs)
>>  {
>>  unsigned int eax, ebx, ecx, edx;
>> +unsigned int _eax, _ecx;
>
> Please avoid adding new name space violations like this: Identifiers
> starting with an underscore and a lower case letter are intended to
> be used for file scope symbols. May I, just like for the public header,
> suggest using leaf and subleaf here?

Yeap, makes sense.

>
>> @@ -2415,7 +2420,7 @@ static int vmx_do_cpuid(struct cpu_user_regs *regs)
>>  regs->ecx = ecx;
>>  regs->edx = edx;
>>
>> -return hvm_monitor_cpuid(get_instruction_length());
>> +return hvm_monitor_cpuid(get_instruction_length(), _eax, _ecx);;
>
> Stray semicolon.

Ack,

>
>> --- a/xen/include/public/vm_event.h
>> +++ b/xen/include/public/vm_event.h
>> @@ -226,6 +226,13 @@ struct vm_event_mov_to_msr {
>>
>>  struct vm_event_cpuid {
>>  uint32_t insn_length;
>> +/*
>> + * Value of EAX and ECX when CPUID was executed.
>> + * Note that the resulting register values are accessible in
>> + * vm_event_regs_x86.
>> + */
>
> "resulting" is a little ambiguous. How about "output"?

So the point of the comment really was just to disambiguate the
eax/ecx here from the other set of registers. Now that the names
changed the comment is not needed.

Thanks,
Tamas

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

Re: [Xen-devel] [PATCH] x86/monitor: Include EAX/ECX in CPUID monitor events

[Tamas K Lengyel]

On Thu, Sep 1, 2016 at 2:02 AM, Razvan Cojocaru
 wrote:
> On 09/01/2016 10:58 AM, Jan Beulich wrote:
> On 01.09.16 at 09:26,  wrote:
>>> On 09/01/16 02:52, Tamas K Lengyel wrote:
 --- a/xen/include/public/vm_event.h
 +++ b/xen/include/public/vm_event.h
 @@ -226,6 +226,13 @@ struct vm_event_mov_to_msr {

  struct vm_event_cpuid {
  uint32_t insn_length;
 +/*
 + * Value of EAX and ECX when CPUID was executed.
 + * Note that the resulting register values are accessible in
 + * vm_event_regs_x86.
 + */
 +uint32_t eax;
 +uint32_t ecx;
  uint32_t _pad;
  };
>>>
>>> Would it not be clearer if you named these old_eax and old_ecx? In user
>>> code it would be hard to choose between these and the values in
>>> vm_event_regs_x86, and then hard to understand why the choice was made
>>> reading the user code later on (unless a comment is added) and so on.
>>>
>>> It doesn't have to be old_eax and old_ecx, any other naming that
>>> prevents cofusion would be great.
>>
>> What about leaf and subleaf?
>
> That's perfect.
>

Sounds good to me too!

Thanks,
Tamas

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 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

version targeted for testing:
 xen  08e7738ec3644350fbac0325085baac6b3c7cd11
baseline version:
 xen  d5498f7fd64add3b4810c418f9fa671a81901e36

Last test of basis   100695  2016-09-01 10:02:59 Z0 days
Testing same since   100697  2016-09-01 12:01:45 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=08e7738ec3644350fbac0325085baac6b3c7cd11
+ . ./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 xen-unstable-smoke 
08e7738ec3644350fbac0325085baac6b3c7cd11
+ branch=xen-unstable-smoke
+ revision=08e7738ec3644350fbac0325085baac6b3c7cd11
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.7-testing
+ '[' x08e7738ec3644350fbac0325085baac6b3c7cd11 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 00afc8f82061677fedc86cb05e3b8c75a3c986ff
baseline version:
 ovmf 950a3bc788b5b101729b26aed3ff75fd2a64a570

Last test of basis   100687  2016-09-01 07:14:06 Z0 days
Testing same since   100692  2016-09-01 09:14:38 Z0 days1 attempts


People who touched revisions under test:
  Dandan Bi 

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



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=00afc8f82061677fedc86cb05e3b8c75a3c986ff
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
00afc8f82061677fedc86cb05e3b8c75a3c986ff
+ branch=ovmf
+ revision=00afc8f82061677fedc86cb05e3b8c75a3c986ff
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' x00afc8f82061677fedc86cb05e3b8c75a3c986ff = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'

Re: [Xen-devel] [PATCH v2 12/20] x86, arm: Change arch_livepatch_quiesce() decleration.

[Julien Grall]

Hi Konrad,

NIT: title: s/decleration/declaration/

On 25/08/16 14:37, Konrad Rzeszutek Wilk wrote:

On ARM we need an alternative VA region to poke in the
hypervisor .text data. And since this is setup during runtime
we may fail (it uses vmap so most likely error is ENOMEM).

As such this error needs to be bubbled up and also abort
the livepatching if it occurs.

Signed-off-by: Konrad Rzeszutek Wilk 


Reviewed-by: Julien Grall 

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v3 2/6] VMX: Properly handle pi when all the assigned devices are removed

[Wu, Feng]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, September 1, 2016 6:24 PM
> To: Wu, Feng 
> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com;
> george.dun...@eu.citrix.com; Tian, Kevin ; xen-
> de...@lists.xen.org
> Subject: RE: [PATCH v3 2/6] VMX: Properly handle pi when all the assigned
> devices are removed
> 
> >>> On 01.09.16 at 11:22,  wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: Thursday, September 1, 2016 4:21 PM
> >> >>> On 31.08.16 at 05:56,  wrote:
> >> > This patch handles some concern cases when the last assigned device
> >> > is removed from the domain. In this case we should carefully handle
> >> > pi descriptor and the per-cpu blocking list, to make sure:
> >> > - all the PI descriptor are in the right state when next time a
> >> > devices is assigned to the domain again.
> >> > - No remaining vcpus of the domain in the per-cpu blocking list.
> >> >
> >> > Basically, we pause the domain before zapping the PI hooks and
> >> > removing the vCPU from the blocking list, then unpause it after
> >> > that.
> >> >
> >> > Signed-off-by: Feng Wu 
> >>
> >> Looks plausible, but
> >> a) as already for patch 1 I'm missing information on what changed
> >>since v2 and
> >
> > The biggest changes since v2 is that we use domain pause/unpause
> > (suggested by George) to handle the concern case, while v2 was using
> > some ugly and tricky method to do it, which was considered as hard
> > to maintain.
> >
> >> b) doesn't this make unnecessary patch 1?
> >
> > The purpose of patch 1 is to make sure the two hooks are installed
> > while CPU side PI is available event VT-d PI is not supported, I cannot
> > see why this patch will make it unnecessary.
> 
> So I guess this doesn't hold anymore with your subsequent reply
> to my comments on patch 1?

I think we still need patch 1, since we may pause a runnable vcpu
which is in the run queue ('SN' bit is set), and 'SN' continues to be set
when the vCPU is paused. If we zap these two hooks, the 'SN' can still
be set after the vCPU is unpaused

Thanks,
Feng

> 
> Jan


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

Re: [Xen-devel] [PATCH v2 11/20] arm/arm64: Update comment about VA layout.

[Julien Grall]

Hi Konrad,

On 25/08/16 14:37, Konrad Rzeszutek Wilk wrote:

It was missing 2MB.

Signed-off-by: Konrad Rzeszutek Wilk 


Reviewed-by: Julien Grall 

Regards,


---
Cc: Stefano Stabellini 
Cc: Julien Grall 

v2: First submission. Spun of from 'livepatch: Initial ARM64 support."
---
 xen/include/asm-arm/config.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
index a96f845..6772555 100644
--- a/xen/include/asm-arm/config.h
+++ b/xen/include/asm-arm/config.h
@@ -82,7 +82,7 @@
  *   8M -  10M   Early relocation address (used when relocating Xen)
  *
  * ARM32 layout:
- *   0  -   8M   
+ *   0  -  10M   
  *
  *  32M - 128M   Frametable: 24 bytes per page for 16GB of RAM
  * 256M -   1G   VMAP: ioremap and early_ioremap use this virtual address
@@ -93,7 +93,7 @@
  *
  * ARM64 layout:
  * 0x - 0x007f (512GB, L0 slot [0])
- *   0  -   8M   
+ *   0  -  10M   
  *
  *   1G -   2G   VMAP: ioremap and early_ioremap
  *



--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 10/20] arm64/insn: introduce aarch64_insn_gen_{nop|branch_imm}() helper functions

[Julien Grall]

Hi Konrad,

On 25/08/16 14:37, Konrad Rzeszutek Wilk wrote:

This is copied from Linux 4.7, and the initial commit
that put this in is 5c5bf25d4f7a950382f94fc120a5818197b48fe9
"arm64: introduce aarch64_insn_gen_{nop|branch_imm}() helper functions"

This lays the groundwork for Livepatch to generate the
trampoline to jump to the new replacement function.
Also allows us to NOP the callsites.

This lays the groundwork for Livepatch to generate the
trampoline to jump to the new replacement function.
And also to NOP insns.


NIT: Both paragraphs seem to stay the same things. Did you mean to keep 
only one?




Signed-off-by: Konrad Rzeszutek Wilk 


The rest of the patch looks good:

Acked-by: Julien Grall 

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 09/20] arm/mm: Introduce modify_xen_mappings

[Julien Grall]

Hi Konrad,

On 25/08/16 14:37, Konrad Rzeszutek Wilk wrote:

Which is only used by Livepatch code. The purpose behind
this call is to modify the page table entries flags.

Specifically the .ro and .nx flags. The current mechanism
puts cache attributes in the flags and the .ro and .nx are
locked down and assumed to be .ro=0, nx=1.

Livepatch needs .nx=0 and also .ro to be set to 1.

We introduce a new 'flags' where various bits determine
whether .ro and .nx bits are set or cleared. We can't use
an enum as the function prototype would diverge from x86.

Signed-off-by: Konrad Rzeszutek Wilk 


Reviewed-by: Julien Grall 

with one minor request (see below).


diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 05d9f82..2f66740 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -66,6 +66,17 @@
 #define PAGE_HYPERVISOR_WC  (DEV_WC)

 /*
+ * Defines for changing the PTE .ro and .nx bits. This is only to be


I would say "hypervisor PTE" because the stage-2 page tables have 
different permission (read and write have separate bits).



+ * used with modify_xen_mappings.
+ */
+#define _PTE_NX_BIT 0U
+#define _PTE_RO_BIT 1U
+#define PTE_NX  (1U << _PTE_NX_BIT)
+#define PTE_RO  (1U << _PTE_RO_BIT)
+#define PTE_NX_MASK(x)  (((x) >> _PTE_NX_BIT) & 0x1U)
+#define PTE_RO_MASK(x)  (((x) >> _PTE_RO_BIT) & 0x1U)
+
+/*
  * Stage 2 Memory Type.
  *
  * These are valid in the MemAttr[3:0] field of an LPAE stage 2 page



Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH] x86: correct CPUID output for out of bounds input

[Jan Beulich]

>>> On 01.09.16 at 13:23,  wrote:
> On 24/08/16 16:31, Jan Beulich wrote:
>> Another place where we should try to behave like real hardware; see
>> the code comments.
>>
>> Signed-off-by: Jan Beulich 
>>
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -3358,6 +3358,31 @@ void hvm_cpuid(unsigned int input, unsig
>>  if ( !edx )
>>  edx = 
>>  
>> +if ( input & 0x )
>> +{
>> +/*
>> + * Requests beyond the highest supported leaf within a group return
>> + * zero on AMD and the highest basic leaf output on others.
>> + */
>> +unsigned int lvl;
>> +
>> +hvm_cpuid(input & 0x, , NULL, NULL, NULL);
> 
> I have specifically deferred fixing this issue so far, because I don't
> want to increase the quantity of recursion with hvm_cpuid().
> 
> Also, because of the poor datastructure for domain cpuid, this adds 1
> and possibly 2 extra loops over the unordered list.
> 
> 
> On the way back from Toronto, I started experimenting with my
> full-policy plans, including a structured information layout so
> cpuid.basic.max_leaf can be found directly, and starting a guest_cpuid()
> function intending to replace both pv_cpuid() and hvm_cpuid() in due course.
> 
> Would you be amenable to leaving this issue as-is for now, until there
> is a more efficient way of fixing it?

If you get this ready for 4.8, yes. Otherwise I think the variant here
is better than nothing until yours arrives.

Jan


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

Re: [Xen-devel] [PATCH] x86/32on64: misc adjustments to call gate emulation

[Andrew Cooper]

On 01/09/16 12:31, Andrew Cooper wrote:
> On 29/08/16 14:57, Jan Beulich wrote:
>> - There's no 32-bit displacement in 16-bit addressing mode.
>> - It is wrong to ASSERT() anything on parts of an instruction fetched
>>   from guest memory.
>> - The two scaling bits of a SIB byte don't affect whether there is no
>>   scaled index register.

"whether there is a scaled index register or not."

>>
>> Signed-off-by: Jan Beulich 
>>
>> --- a/xen/arch/x86/traps.c
>> +++ b/xen/arch/x86/traps.c
>> @@ -3214,7 +3214,7 @@ static void emulate_gate_op(struct cpu_u
>>  sib = insn_fetch(u8, base, eip, limit);
>>  
>>  modrm = (modrm & ~7) | (sib & 7);
>> -if ( (sib >>= 3) != 4 )
>> +if ( ((sib >>= 3) & 7) != 4 )
>>  opnd_off = *(unsigned long *)
>>  decode_register(sib & 7, regs, 0);
>>  opnd_off <<= sib >> 3;
> Surely should shift sib by 6 rather than 3 here, so opnd_off doesn't
> have the index included in its scaling factor?

Oh wait no - the if condition has a destructive shift of sib already, so
this calculation is correct.  (Wow I hate trying to read this code.)

With the commit message tweak, Reviewed-by: Andrew Cooper


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

Re: [Xen-devel] [PATCH] x86/32on64: misc adjustments to call gate emulation

[Jan Beulich]

>>> On 01.09.16 at 13:31,  wrote:
> On 29/08/16 14:57, Jan Beulich wrote:
>> - There's no 32-bit displacement in 16-bit addressing mode.
>> - It is wrong to ASSERT() anything on parts of an instruction fetched
>>   from guest memory.
>> - The two scaling bits of a SIB byte don't affect whether there is no
>>   scaled index register.
>>
>> Signed-off-by: Jan Beulich 
>>
>> --- a/xen/arch/x86/traps.c
>> +++ b/xen/arch/x86/traps.c
>> @@ -3214,7 +3214,7 @@ static void emulate_gate_op(struct cpu_u
>>  sib = insn_fetch(u8, base, eip, limit);
>>  
>>  modrm = (modrm & ~7) | (sib & 7);
>> -if ( (sib >>= 3) != 4 )
>> +if ( ((sib >>= 3) & 7) != 4 )
>>  opnd_off = *(unsigned long *)
>>  decode_register(sib & 7, regs, 0);
>>  opnd_off <<= sib >> 3;
> 
> Surely should shift sib by 6 rather than 3 here, so opnd_off doesn't
> have the index included in its scaling factor?

Not really - sib gets shifted right by 3 already in the line being
modified.

Jan


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

Re: [Xen-devel] [PATCH v4 03/16] libxl/arm: Generate static ACPI DSDT table

[Boris Ostrovsky]

On 08/31/2016 11:18 PM, Shannon Zhao wrote:
>
> On 2016/8/30 1:46, Julien Grall wrote:
>>> diff --git a/tools/libacpi/Makefile b/tools/libacpi/Makefile
>>> index d741ac5..7f50a33 100644
>>> --- a/tools/libacpi/Makefile
>>> +++ b/tools/libacpi/Makefile
>>> @@ -19,6 +19,7 @@ MK_DSDT = $(ACPI_BUILD_DIR)/mk_dsdt
>>>
>>>  # Sources to be generated
>>>  C_SRC = $(addprefix $(ACPI_BUILD_DIR)/, dsdt_anycpu.c dsdt_15cpu.c 
>>> dsdt_anycpu_qemu_xen.c dsdt_pvh.c)
>>> +C_SRC += $(ACPI_BUILD_DIR)/dsdt_anycpu_arm.c
>> Do we really want to generate dsdt_anycpu_arm.c even for x86? Similarly,
>> do we want to generate x86 dsdt for ARM
> No need I think.
> Boris, will you change this in your next version?

You mean adding something along the lines of 'C_SRC-$(CONFIG_X86)'? Yes,
it's probably a good idea. I can add that.

-boris

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

Re: [Xen-devel] [PATCH v6 0/4] arm64, xen: add xen_boot support into grup-mkconfig

[Julien Grall]

Hi Daniel,

I have heard you became co-maintainer of GRUB. Congratulations for that :).

We have a couple series (this series and [1]) to allow grub booting Xen 
on ARM that have been waiting on the GRUB ML for a while to be pushed.


Those patches have been tested and already integrated in some 
distributions. It would be nice to get them in GRUB upstream.


Would it be possible for you to take a look?

Regards,

[1] https://lists.gnu.org/archive/html/grub-devel/2016-02/msg00205.html

On 26/07/16 10:13, fu@linaro.org wrote:

From: Fu Wei 

This patchset add xen_boot support into grup-mkconfig for
generating xen boot entrances automatically

Also update the docs/grub.texi for new xen_boot commands.

This patchset has been tested on Foudation model with a bug fix:
http://lists.gnu.org/archive/html/grub-devel/2016-02/msg00205.html

ChangeLog:
v6: http://lists.gnu.org/archive/html/grub-devel/2016-07/
Fix Coding style of util/grub.d/20_linux_xen.in, use soft tab.

v5: http://lists.gnu.org/archive/html/grub-devel/2016-07/msg8.html
Update the introduction of xen_module commands in docs/grub.texi,
according to the suggestion from Julien Grall

v4: http://lists.gnu.org/archive/html/grub-devel/2016-05/
according to the XSM loading mechanism of Xen(upstreamed),
update the introduction of xen_module commands in docs/grub.texi

v3: http://lists.gnu.org/archive/html/grub-devel/2016-02/msg00314.html
reorder the patches
update the introduction of xen_module commands in docs/grub.texi

v2: http://lists.gnu.org/archive/html/grub-devel/2016-02/msg00282.html
add "--nounzip" option support in xen_module
use "feature_xen_boot" instead of "grub_xen_boot"
update the introduction of xen boot commands in docs/grub.texi

v1 :first upstream patchset:
http://lists.gnu.org/archive/html/grub-devel/2016-02/msg00264.html

Fu Wei (4):
  i386,xen: Add xen_hypervisor and xen_module aliases for i386
  arm64: add "--nounzip" option support in xen_module command
  * util/grub.d/20_linux_xen.in: Add xen_boot command support
  arm64: update the introduction of xen boot commands in docs/grub.texi

 docs/grub.texi| 32 +---
 grub-core/loader/arm64/xen_boot.c | 17 +
 grub-core/loader/i386/xen.c   |  7 +++
 grub-core/normal/main.c   |  2 +-
 util/grub.d/20_linux_xen.in   | 13 ++---
 5 files changed, 44 insertions(+), 27 deletions(-)



--
Julien Grall

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

Re: [Xen-devel] [Qemu-devel] [PATCH 0/2] Xen HVM unplug changes

[no-reply]

Hi,

Your series seems to have some coding style problems. See output below for
more information:

Subject: [Qemu-devel] [PATCH 0/2] Xen HVM unplug changes
Type: series
Message-id: 20160901121131.16007-1-o...@aepfle.de

=== TEST SCRIPT BEGIN ===
#!/bin/bash

BASE=base
n=1
total=$(git log --oneline $BASE.. | wc -l)
failed=0

# Useful git options
git config --local diff.renamelimit 0
git config --local diff.renames True

commits="$(git log --format=%H --reverse $BASE..)"
for c in $commits; do
echo "Checking PATCH $n/$total: $(git show --no-patch --format=%s $c)..."
if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; then
failed=1
echo
fi
n=$((n+1))
done

exit $failed
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 * [new tag] patchew/20160901121131.16007-1-o...@aepfle.de -> 
patchew/20160901121131.16007-1-o...@aepfle.de
Switched to a new branch 'test'
bc12567 xen_platform: SUSE xenlinux unplug for emulated PCI
cfa2940 xen_platform: unplug also SCSI disks

=== OUTPUT BEGIN ===
Checking PATCH 1/2: xen_platform: unplug also SCSI disks...
ERROR: else should follow close brace '}'
#58: FILE: hw/i386/xen/xen_platform.c:118:
 }
+else if (pci_get_word(d->config + PCI_CLASS_DEVICE) ==

total: 1 errors, 0 warnings, 11 lines checked

Your patch has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

Checking PATCH 2/2: xen_platform: SUSE xenlinux unplug for emulated PCI...
ERROR: line over 90 characters
#33: FILE: hw/i386/xen/xen_platform.c:327:
+ * xen-kmp used this since xen-3.0.4, instead the official 
protocol from xen-3.3+

WARNING: line over 80 characters
#35: FILE: hw/i386/xen/xen_platform.c:329:
+ * Pre VMDP 1.7 made use of 4 and 8 depending on how VMDP was 
configured.

total: 1 errors, 1 warnings, 43 lines checked

Your patch has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

=== OUTPUT END ===

Test command exited with code: 1


---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to patchew-de...@freelists.org
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH 1/2] xen_platform: unplug also SCSI disks

[Olaf Hering]

Using 'vdev=sd[a-o]' will create an emulated LSI controller, which can
be used by the emulated BIOS to boot from disk. If the HVM domU has also
PV driver the disk may appear twice in the guest. To avoid this an
unplug of the emulated hardware is needed, similar to what is done for
IDE and NIC drivers already.

Since the SCSI controller provides only disks the entire controller can
be unplugged at once.

Impact of the change for classic and pvops based guest kernels:

 vdev=sda:disk0
before: pvops:   disk0=pv xvda + emulated sda
classic: disk0=pv sda  + emulated sdq
after:  pvops:   disk0=pv xvda
classic: disk0=pv sda

 vdev=hda:disk0, vdev=sda:disk1
before: pvops:   disk0=pv xvda
 disk1=emulated sda
classic: disk0=pv hda
 disk1=pv sda  + emulated sdq
after:  pvops:   disk0=pv xvda
 disk1=not accessible by blkfront, index hda==index sda
classic: disk0=pv hda
 disk1=pv sda

 vdev=hda:disk0, vdev=sda:disk1, vdev=sdb:disk2
before: pvops:   disk0=pv xvda
 disk1=emulated sda
 disk2=pv xvdb + emulated sdb
classic: disk0=pv hda
 disk1=pv sda  + emulated sdq
 disk2=pv sdb  + emulated sdr
after:  pvops:   disk0=pv xvda
 disk1=not accessible by blkfront, index hda==index sda
 disk2=pv xvdb
classic: disk0=pv hda
 disk1=pv sda
 disk2=pv sda

Signed-off-by: Olaf Hering 
---
 hw/i386/xen/xen_platform.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/hw/i386/xen/xen_platform.c b/hw/i386/xen/xen_platform.c
index aa78393..d94b53c 100644
--- a/hw/i386/xen/xen_platform.c
+++ b/hw/i386/xen/xen_platform.c
@@ -115,6 +115,11 @@ static void unplug_disks(PCIBus *b, PCIDevice *d, void *o)
 && strcmp(d->name, "xen-pci-passthrough") != 0) {
 pci_piix3_xen_ide_unplug(DEVICE(d));
 }
+else if (pci_get_word(d->config + PCI_CLASS_DEVICE) ==
+PCI_CLASS_STORAGE_SCSI
+&& strcmp(d->name, "xen-pci-passthrough") != 0) {
+object_unparent(OBJECT(d));
+}
 }
 
 static void pci_unplug_disks(PCIBus *bus)

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

[Xen-devel] [PATCH 2/2] xen_platform: SUSE xenlinux unplug for emulated PCI

[Olaf Hering]

Implement SUSE specific unplug protocol for emulated PCI devices
in PVonHVM guests. Its a simple 'outl(1, (ioaddr + 4));'.
This protocol was implemented and used since Xen 3.0.4.
It is used in all SUSE/SLES/openSUSE releases up to SLES11SP3 and
openSUSE 12.3.

Signed-off-by: Olaf Hering 
---
 hw/i386/xen/xen_platform.c | 31 ++-
 1 file changed, 30 insertions(+), 1 deletion(-)

diff --git a/hw/i386/xen/xen_platform.c b/hw/i386/xen/xen_platform.c
index d94b53c..8802482 100644
--- a/hw/i386/xen/xen_platform.c
+++ b/hw/i386/xen/xen_platform.c
@@ -314,13 +314,42 @@ static void xen_platform_ioport_writeb(void *opaque, 
hwaddr addr,
uint64_t val, unsigned int size)
 {
 PCIXenPlatformState *s = opaque;
+PCIDevice *pci_dev = PCI_DEVICE(s);
 
 switch (addr) {
 case 0: /* Platform flags */
 platform_fixed_ioport_writeb(opaque, 0, (uint32_t)val);
 break;
+case 4:
+if (val == 1) {
+/*
+ * SUSE unplug for Xenlinux
+ * xen-kmp used this since xen-3.0.4, instead the official 
protocol from xen-3.3+
+ * It did an unconditional "outl(1, (ioaddr + 4));"
+ * Pre VMDP 1.7 made use of 4 and 8 depending on how VMDP was 
configured.
+ * If VMDP was to control both disk and LAN it would use 4.
+ * If it controlled just disk or just LAN, it would use 8 below.
+ */
+blk_drain_all();
+blk_flush_all();
+pci_unplug_disks(pci_dev->bus);
+pci_unplug_nics(pci_dev->bus);
+}
+break;
 case 8:
-log_writeb(s, (uint32_t)val);
+switch (val) {
+case 1:
+blk_drain_all();
+blk_flush_all();
+pci_unplug_disks(pci_dev->bus);
+break;
+case 2:
+pci_unplug_nics(pci_dev->bus);
+break;
+default:
+log_writeb(s, (uint32_t)val);
+break;
+}
 break;
 default:
 break;

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

[Xen-devel] [PATCH 0/2] Xen HVM unplug changes

[Olaf Hering]

Update unplug in Xen HVM guests to cover more cases.
Please review.

Olaf

Olaf Hering (2):
  xen_platform: unplug also SCSI disks
  xen_platform: SUSE xenlinux unplug for emulated PCI

 hw/i386/xen/xen_platform.c | 36 +++-
 1 file changed, 35 insertions(+), 1 deletion(-)


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 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

version targeted for testing:
 xen  d5498f7fd64add3b4810c418f9fa671a81901e36
baseline version:
 xen  fb1f0e95654c8f995ddcdbd114100515814c1238

Last test of basis   100682  2016-08-31 19:03:04 Z0 days
Testing same since   100695  2016-09-01 10:02:59 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Julien Grall 

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=d5498f7fd64add3b4810c418f9fa671a81901e36
+ . ./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 xen-unstable-smoke 
d5498f7fd64add3b4810c418f9fa671a81901e36
+ branch=xen-unstable-smoke
+ revision=d5498f7fd64add3b4810c418f9fa671a81901e36
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.7-testing
+ '[' xd5498f7fd64add3b4810c418f9fa671a81901e36 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local 

Re: [Xen-devel] [RFC 12/22] xen/arm: p2m: Introduce p2m_get_entry and use it to implement __p2m_lookupo

[Julien Grall]

Hi Stefano,

On 31/08/16 20:33, Stefano Stabellini wrote:

On Wed, 31 Aug 2016, Julien Grall wrote:

@@ -236,28 +238,99 @@ static lpae_t *p2m_get_root_pointer(struct
p2m_domain *p2m,

 /*
  * Lookup the MFN corresponding to a domain's GFN.
+ * Lookup mem access in the ratrix tree.
+ * The entries associated to the GFN is considered valid.
+ */
+static p2m_access_t p2m_mem_access_radix_get(struct p2m_domain *p2m,
gfn_t gfn)
+{
+void *ptr;
+
+if ( !p2m->mem_access_enabled )
+return p2m_access_rwx;


Shouldn't this be p2m->default_access?


default_access will always be p2m_access_rwx when memaccess is disabled. It
will lead to crash a if you try to restrict permission without memaccess.

Note that, this is matching the behavior of __p2m_get_mem_access.


I would like to avoid some places to use p2m_access_rwx and others to
use p2m->default_access. But it is true that in this context both are
fine. This was just a suggestion.


Thinking a bit more, this will allow us to catch any error where 
mem_access is not enabled but default_access is not p2m_access_rwx.


I will use p2m->default_access here for this case (the one below should 
stay p2m_access_rwx).





+ptr = radix_tree_lookup(>mem_access_settings, gfn_x(gfn));
+if ( !ptr )
+return p2m_access_rwx;


Same here?


The radix tree will contain all the permission restriction but p2m_access_rwx.
This is because you may change the default_access whilst memaccess is enabled
and you don't know what page was restricted with the default access.

Note that this is matching the behavior of p2m_mem_access_radix_set.


[...]




  *
- * There are no processor functions to do a stage 2 only lookup therefore
we
- * do a a software walk.
+ * Return values:
+ *  GUEST_TABLE_MAP_FAILED: Either read_only was set and the entry
+ *  was empty, or allocating a new page failed.
+ *  GUEST_TABLE_NORMAL_PAGE: next level mapped normally
+ *  GUEST_TABLE_SUPER_PAGE: The next entry points to a superpage.
  */
-static mfn_t __p2m_lookup(struct domain *d, gfn_t gfn, p2m_type_t *t)
+static int p2m_next_level(struct p2m_domain *p2m, bool read_only,
+  lpae_t **table, unsigned int offset)
 {
-struct p2m_domain *p2m = >arch.p2m;
-const paddr_t paddr = pfn_to_paddr(gfn_x(gfn));
-const unsigned int offsets[4] = {
-zeroeth_table_offset(paddr),
-first_table_offset(paddr),
-second_table_offset(paddr),
-third_table_offset(paddr)
-};
-const paddr_t masks[4] = {
-ZEROETH_MASK, FIRST_MASK, SECOND_MASK, THIRD_MASK
-};
-lpae_t pte, *map;
+lpae_t *entry;
+int ret;
+mfn_t mfn;
+
+entry = *table + offset;
+
+if ( !p2m_valid(*entry) )
+{
+if ( read_only )
+return GUEST_TABLE_MAP_FAILED;
+
+ret = p2m_create_table(p2m, entry, /* not used */ ~0);
+if ( ret )
+return GUEST_TABLE_MAP_FAILED;
+}
+
+/* The function p2m_next_level is never called at the 3rd level */
+if ( p2m_mapping(*entry) )
+return GUEST_TABLE_SUPER_PAGE;
+
+mfn = _mfn(entry->p2m.base);
+
+unmap_domain_page(*table);
+*table = map_domain_page(mfn);
+
+return GUEST_TABLE_NORMAL_PAGE;


I am a bit worried about having the same function doing the lookup and
creating new tables, especially given it doesn't tell you whether the
entry was already there or it was created: the return value is the same
in both cases. At the very least the return values should be different.


I don't understand your worry here. Why would you care that the table has been
allocated or was already existing?

If the caller does not want to allocate table, it can request to browse the
entry in a read-only mode (see read_only).


To avoid unintentional side effects, such as calling this function for a
lookup but passing read-only as false by mistake. But maybe we just need
to be careful enough in the code reviews, after all this function won't
be called that many times.


This would be the same if the caller does not check the return value 
properly, thinking page table will not be allocated.


I prefer to keep the interface like that for now and rely on the review. 
I will also document the behavior of read_only bit in the next version.







+}
+
+/*
+ * Get the details of a given gfn.
+ *
+ * If the entry is present, the associated MFN will be returned and the
+ * access and type filled up. The page_order will correspond to the
+ * order of the mapping in the page table (i.e it could be a superpage).
+ *
+ * If the entry is not present, INVALID_MFN will be returned and the
+ * page_order will be set according to the order of the invalid range.
+ */
+static mfn_t p2m_get_entry(struct p2m_domain *p2m, gfn_t gfn,
+   p2m_type_t *t, p2m_access_t *a,
+   unsigned int *page_order)
+{
+paddr_t addr = pfn_to_paddr(gfn_x(gfn));
+unsigned int level = 0;
+lpae_t entry, *table;
+int rc;
   

Re: [Xen-devel] [PATCH] x86/32on64: misc adjustments to call gate emulation

[Andrew Cooper]

On 29/08/16 14:57, Jan Beulich wrote:
> - There's no 32-bit displacement in 16-bit addressing mode.
> - It is wrong to ASSERT() anything on parts of an instruction fetched
>   from guest memory.
> - The two scaling bits of a SIB byte don't affect whether there is no
>   scaled index register.
>
> Signed-off-by: Jan Beulich 
>
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -3214,7 +3214,7 @@ static void emulate_gate_op(struct cpu_u
>  sib = insn_fetch(u8, base, eip, limit);
>  
>  modrm = (modrm & ~7) | (sib & 7);
> -if ( (sib >>= 3) != 4 )
> +if ( ((sib >>= 3) & 7) != 4 )
>  opnd_off = *(unsigned long *)
>  decode_register(sib & 7, regs, 0);
>  opnd_off <<= sib >> 3;

Surely should shift sib by 6 rather than 3 here, so opnd_off doesn't
have the index included in its scaling factor?

The other two changes look fine.

~Andrew

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

Re: [Xen-devel] [PATCH] x86: correct CPUID output for out of bounds input

[Andrew Cooper]

On 24/08/16 16:31, Jan Beulich wrote:
> Another place where we should try to behave like real hardware; see
> the code comments.
>
> Signed-off-by: Jan Beulich 
>
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -3358,6 +3358,31 @@ void hvm_cpuid(unsigned int input, unsig
>  if ( !edx )
>  edx = 
>  
> +if ( input & 0x )
> +{
> +/*
> + * Requests beyond the highest supported leaf within a group return
> + * zero on AMD and the highest basic leaf output on others.
> + */
> +unsigned int lvl;
> +
> +hvm_cpuid(input & 0x, , NULL, NULL, NULL);

I have specifically deferred fixing this issue so far, because I don't
want to increase the quantity of recursion with hvm_cpuid().

Also, because of the poor datastructure for domain cpuid, this adds 1
and possibly 2 extra loops over the unordered list.


On the way back from Toronto, I started experimenting with my
full-policy plans, including a structured information layout so
cpuid.basic.max_leaf can be found directly, and starting a guest_cpuid()
function intending to replace both pv_cpuid() and hvm_cpuid() in due course.

Would you be amenable to leaving this issue as-is for now, until there
is a more efficient way of fixing it?

~Andrew

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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 950a3bc788b5b101729b26aed3ff75fd2a64a570
baseline version:
 ovmf 6c59c7c2f488d7c9b951b5ead780f6102dafae8a

Last test of basis67616  2016-08-31 11:19:42 Z0 days
Testing same since67619  2016-09-01 09:16:28 Z0 days1 attempts


People who touched revisions under test:
  Chao Zhang 
  Zhang, Chao B 

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



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

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

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


Push not applicable.


commit 950a3bc788b5b101729b26aed3ff75fd2a64a570
Author: Zhang, Chao B 
Date:   Wed Aug 31 09:26:08 2016 +0800

SecurityPkg: TPM12CommandLib: Add Response returnCode Check

   Check response return code before return from Tpm12Extend and
Tpm12PhysicalPresence.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Chao Zhang 
Reviewed-by: Yao Jiewen 
Reviewed-by: Long Qin 

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

Re: [Xen-devel] [PATCH 18/24] xen: credit2: soft-affinity awareness fallback_cpu() and cpu_pick()

[anshul makkar]

On 17/08/16 18:19, Dario Faggioli wrote:

For get_fallback_cpu(), by putting in place the "usual"
two steps (soft affinity step and hard affinity step)
loop. We just move the core logic of the function inside
the body of the loop itself.

For csched2_cpu_pick(), what is important is to find
the runqueue with the least average load. Currently,
we do that by looping on all runqueues and checking,
well, their load. For soft affinity, we want to know
which one is the runqueue with the least load, among
the ones where the vcpu would prefer to be assigned.

We find both the least loaded runqueue among the soft
affinity "friendly" ones, and the overall least loaded
one, in the same pass.

(Also, kill a spurious ';' when defining MAX_LOAD.)

Signed-off-by: Dario Faggioli 
Signed-off-by: Justin T. Weaver 
---
Cc: George Dunlap 
Cc: Anshul Makkar 
---
  xen/common/sched_credit2.c |  136 
  1 file changed, 111 insertions(+), 25 deletions(-)

diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 3aef1b4..2d7228a 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -506,34 +506,68 @@ void smt_idle_mask_clear(unsigned int cpu, cpumask_t 
*mask)
  }

  /*
- * When a hard affinity change occurs, we may not be able to check some
- * (any!) of the other runqueues, when looking for the best new processor
- * for svc (as trylock-s in csched2_cpu_pick() can fail). If that happens, we
- * pick, in order of decreasing preference:
- *  - svc's current pcpu;
- *  - another pcpu from svc's current runq;
- *  - any cpu.
+ * In csched2_cpu_pick(), it may not be possible to actually look at remote
+ * runqueues (the trylock-s on their spinlocks can fail!). If that happens,
With remote runqueues , do you mean runqs on remote socket ? Can't we 
just read their workload or we can change the locktype to allow reading ?

+ * we pick, in order of decreasing preference:
+ *  1) svc's current pcpu, if it is part of svc's soft affinity;
+ *  2) a pcpu in svc's current runqueue that is also in svc's soft affinity;
svc's current runqueue. Do you mean the runq in which svc is currently 
queued ?

+ *  3) just one valid pcpu from svc's soft affinity;
+ *  4) svc's current pcpu, if it is part of svc's hard affinity;
+ *  5) a pcpu in svc's current runqueue that is also in svc's hard affinity;
+ *  6) just one valid pcpu from svc's hard affinity
+ *
+ * Of course, 1, 2 and 3 makes sense only if svc has a soft affinity. Also
+ * note that at least 6 is guaranteed to _always_ return at least one pcpu.
   */
  static int get_fallback_cpu(struct csched2_vcpu *svc)
  {
  int cpu;
+unsigned int bs;

-if ( likely(cpumask_test_cpu(svc->vcpu->processor,
- svc->vcpu->cpu_hard_affinity)) )
-return svc->vcpu->processor;
+for_each_affinity_balance_step( bs )
+{
+if ( bs == BALANCE_SOFT_AFFINITY &&
+ !has_soft_affinity(svc->vcpu, svc->vcpu->cpu_hard_affinity) )
+continue;



Anshul

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

[Xen-devel] [PATCH] doc: fix some typos

[Juergen Gross]

Fix some typos in docs/man/xl.cfg.pod.5.in

Signed-off-by: Juergen Gross 
---
 docs/man/xl.cfg.pod.5.in | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg.pod.5.in
index 6feee52..77a1be3 100644
--- a/docs/man/xl.cfg.pod.5.in
+++ b/docs/man/xl.cfg.pod.5.in
@@ -32,7 +32,7 @@ A string, surrounded by either single or double quotes.
 =item B
 
 A number, in either decimal, octal (using a C<0> prefix) or
-hexadecimal (using an C<0x> prefix).
+hexadecimal (using a C<0x> prefix).
 
 =item B
 
@@ -480,7 +480,7 @@ devices which the guest will contain.
 
 Specifies the disks (both emulated disks and Xen virtual block
 devices) which are to be provided to the guest, and what objects on
-the they should map to.  See F.
+the host they should map to.  See F.
 
 =item 

Re: [Xen-devel] [PATCH 17/24] xen: credit2: soft-affinity awareness in runq_tickle()

[anshul makkar]

On 17/08/16 18:19, Dario Faggioli wrote:

This is done by means of the "usual" two steps loop:
  - soft affinity balance step;
  - hard affinity balance step.

The entire logic implemented in runq_tickle() is
applied, during the first step, considering only the
CPUs in the vcpu's soft affinity. In the second step,
we fall back to use all the CPUs from its hard
affinity (as it is doing now, without this patch).

Signed-off-by: Dario Faggioli 
Signed-off-by: Justin T. Weaver 
---
Cc: George Dunlap 
Cc: Anshul Makkar 
---
  xen/common/sched_credit2.c |  243 
  1 file changed, 157 insertions(+), 86 deletions(-)

diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 0d83bd7..3aef1b4 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -902,6 +902,42 @@ __runq_remove(struct csched2_vcpu *svc)
  list_del_init(>runq_elem);
  }

+/*
+ * During the soft-affinity step, only actually preempt someone if
+ * he does not have soft-affinity with cpu (while we have).
+ *
+ * BEWARE that this uses cpumask_scratch, trowing away what's in there!

Typo:* BEWARE that this uses cpumask_scratch, throwing away what's in there!


+ */
+static inline bool_t soft_aff_check_preempt(unsigned int bs, unsigned int cpu)
+{
+struct csched2_vcpu * cur = CSCHED2_VCPU(curr_on_cpu(cpu));
+
+/*
+ * If we're doing hard-affinity, always check whether to preempt cur.
+ * If we're doing soft-affinity, but cur doesn't have one, check as well.
+ */
+if ( bs == BALANCE_HARD_AFFINITY ||
+ !has_soft_affinity(cur->vcpu, cur->vcpu->cpu_hard_affinity) )
+return 1;
+
+/*
+ * We're doing soft-affinity, and we know that the current vcpu on cpu
+ * has a soft affinity. We now want to know whether cpu itself is in
Please can you explain the above statment. If the vcpu has soft affinity 
and its currently executing, doesn;t it always means that its running on 
one of the pcpu which is there in its soft affinity or hard affinity?

+ * such affinity. In fact, since we now that new (in runq_tickle()) is
Typo:   * such affinity. In fact, since now we know that new (in 
runq_tickle()) is

+ *  - if cpu is not in cur's soft-affinity, we should indeed check to
+ *see whether new should preempt cur. If that will be the case, that
+ *would be an improvement wrt respecting soft affinity;
+ *  - if cpu is in cur's soft-affinity, we leave it alone and (in
+ *runq_tickle()) move on to another cpu. In fact, we don't want to
+ *be too harsh with someone which is running within its soft-affinity.
+ *This is safe because later, if we don't fine anyone else during the
+ *soft-affinity step, we will check cpu for preemption anyway, when
+ *doing hard-affinity.
+ */
+affinity_balance_cpumask(cur->vcpu, BALANCE_SOFT_AFFINITY, 
cpumask_scratch);
+return !cpumask_test_cpu(cpu, cpumask_scratch);
+}
+
  void burn_credits(struct csched2_runqueue_data *rqd, struct csched2_vcpu *, 
s_time_t);

  /*
@@ -925,7 +961,7 @@ runq_tickle(const struct scheduler *ops, struct 
csched2_vcpu *new, s_time_t now)
  {
  int i, ipid = -1;
  s_time_t lowest = (1<<30);
-unsigned int cpu = new->vcpu->processor;
+unsigned int bs, cpu = new->vcpu->processor;
  struct csched2_runqueue_data *rqd = RQD(ops, cpu);
  cpumask_t mask;
  struct csched2_vcpu * cur;
@@ -947,109 +983,144 @@ runq_tickle(const struct scheduler *ops, struct 
csched2_vcpu *new, s_time_t now)
  (unsigned char *));
  }

-/*
- * First of all, consider idle cpus, checking if we can just
- * re-use the pcpu where we were running before.
- *
- * If there are cores where all the siblings are idle, consider
- * them first, honoring whatever the spreading-vs-consolidation
- * SMT policy wants us to do.
- */
-if ( unlikely(sched_smt_power_savings) )
-cpumask_andnot(, >idle, >smt_idle);
-else
-cpumask_copy(, >smt_idle);
-cpumask_and(, , new->vcpu->cpu_hard_affinity);
-i = cpumask_test_or_cycle(cpu, );
-if ( i < nr_cpu_ids )
+for_each_affinity_balance_step( bs )
  {
-SCHED_STAT_CRANK(tickled_idle_cpu);
-ipid = i;
-goto tickle;
-}
+/*
+ * First things first: if we are at the first (soft affinity) step,
+ * but new doesn't have a soft affinity, skip this step.
+ */
+if ( bs == BALANCE_SOFT_AFFINITY &&
+ !has_soft_affinity(new->vcpu, new->vcpu->cpu_hard_affinity) )
+continue;

-/*
- * If there are no fully idle cores, check all idlers, after
- * having filtered out pcpus that have been tickled but haven't
- * gone through the scheduler yet.
- */
-cpumask_andnot(, >idle, >tickled);
-