[Xen-devel] [libvirt test] 119943: tolerable all pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 libvirt  87876c7736646452f4139a4d3a8478c51b92abbe
baseline version:
 libvirt  ab59d3895bd2ea604aa336d2cd38aa374e43ed44

Last test of basis   119874  2018-02-22 09:50:39 Z1 days
Testing same since   119943  2018-02-23 06:46:50 Z1 days1 attempts


People who touched revisions under test:
  Daniel P. Berrangé 
  Jim Fehlig 
  John Ferlan 
  Michal Privoznik 
  Nikolay Shirokovskiy 

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



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

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

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

Re: [Xen-devel] [RFC Patch v4 8/8] x86/hvm: bump the maximum number of vcpus to 512

[Chao Gao]

On Fri, Feb 23, 2018 at 06:11:39PM +, Roger Pau Monné wrote:
>On Wed, Dec 06, 2017 at 03:50:14PM +0800, Chao Gao wrote:
>> Signed-off-by: Chao Gao 
>> ---
>>  xen/include/public/hvm/hvm_info_table.h | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/xen/include/public/hvm/hvm_info_table.h 
>> b/xen/include/public/hvm/hvm_info_table.h
>> index 08c252e..6833a4c 100644
>> --- a/xen/include/public/hvm/hvm_info_table.h
>> +++ b/xen/include/public/hvm/hvm_info_table.h
>> @@ -32,7 +32,7 @@
>>  #define HVM_INFO_PADDR   ((HVM_INFO_PFN << 12) + HVM_INFO_OFFSET)
>>  
>>  /* Maximum we can support with current vLAPIC ID mapping. */
>> -#define HVM_MAX_VCPUS128
>> +#define HVM_MAX_VCPUS512
>
>Wow, that looks like a pretty big jump. I certainly don't have access
>to any box with this number of vCPUs, so that's going to be quite hard
>to test. What the reasoning behind this bump?

There are 288 cpus on some Intel XEON-phi platform. Bumping this value to
288 would be weird because I think if I do that there would be some
questions -- why it should be 288 and why the number of vCPUs should be the
same with the number of pCPUs. I choose 512, just because it is the nearest
next power of 2 number.

>Is hardware with 512 ways expected soon-ish?

No. 

>
>Also osstest is not even able to test the current limit, so I would

Do we have any plan to test guest with 128 vCPUs on osstest?

>maybe bump this to 256, but as I expressed in other occasions I don't
>feel comfortable with have a number of vCPUs that the current test
>system doesn't have hardware to test with.

If we only test functionality (osstest doesn't test performance,
right?), hardware needn't have so many pCPUs.

Could we declare that more than 128 vCPUs support is only
experimental feature? Once some regular tests are available, we can
announce that On x86, Xen supports HVM with, for example, 128 vCPUs or
512 vCPUs. It seems Geroge's work on SUPPORT.md is for this kind of propose.

Thanks
Chao

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

Re: [Xen-devel] [RFC Patch v4 4/8] hvmloader: boot cpu through broadcast

[Chao Gao]

On Fri, Feb 23, 2018 at 04:42:10PM +, Roger Pau Monné wrote:
>On Wed, Dec 06, 2017 at 03:50:10PM +0800, Chao Gao wrote:
>> Intel SDM Extended XAPIC (X2APIC) -> "Initialization by System Software"
>> has the following description:
>> 
>> "The ACPI interfaces for the x2APIC are described in Section 5.2, “ACPI 
>> System
>> Description Tables,” of the Advanced Configuration and Power Interface
>> Specification, Revision 4.0a (http://www.acpi.info/spec.htm). The default
>> behavior for BIOS is to pass the control to the operating system with the
>> local x2APICs in xAPIC mode if all APIC IDs reported by CPUID.0BH:EDX are 
>> less
>> than 255, and in x2APIC mode if there are any logical processor reporting an
>> APIC ID of 255 or greater."
>> 
>> In this patch, hvmloader enables x2apic mode for all vcpus if there are cpus
>> with APIC ID > 255. To wake up processors whose APIC ID is greater than 255,
>> the SIPI is broadcasted to all APs. It is the way how Seabios wakes up APs.
>> APs may compete for the stack, thus a lock is introduced to protect the 
>> stack.
>
>Hm, how are we going to deal with this on PVH? hvmloader doesn't run
>for PVH guests, hence it seems like switching to x2APIC mode should be
>done somewhere else that shared between HVM and PVH.
>
>Maybe the hypercall that sets the number of vCPUs should change the
>APIC mode?

Yes. A flag can be passed when setting the maximum number of vCPUs. Xen
will switch all local APICs to x2APIC mode or xAPIC mode according to
the flag.

Thanks
Chao

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

Re: [Xen-devel] [PATCH v4 21/28] vvtd: update hvm_gmsi_info when binding guest msi with pirq or

[Chao Gao]

On Mon, Feb 12, 2018 at 03:38:07PM +, Roger Pau Monné wrote:
>On Fri, Nov 17, 2017 at 02:22:28PM +0800, Chao Gao wrote:
>> ... handlding guest's invalidation request.
>> 
>> To support pirq migration optimization and using VT-d posted interrupt to
>> inject msi from assigned devices, each time guest programs msi information
>> (affinity, vector), the struct hvm_gmsi_info should be updated accordingly.
>> But after introducing vvtd, guest only needs to update an IRTE, which is in
>> guest memory, to program msi information.  vvtd doesn't trap r/w to the 
>> memory
>> range. Instead, it traps the queue invalidation, which is a method used to
>> notify VT-d hardware that an IRTE has changed.
>> 
>> This patch updates hvm_gmsi_info structure and programs physical IRTEs to use
>> VT-d posted interrupt if possible when binding guest msi with pirq or 
>> handling
>> guest's invalidation request. For the latter, all physical interrupts bound
>> with the domain are gone through to find the ones matching with the IRTE.
>> 
>> Notes: calling vvtd_process_iq() in vvtd_read() rather than in
>> vvtd_handle_irq_request() is to avoid ABBA deadlock of d->event_lock and
>> vvtd->ie_lock.
>> 
>> Signed-off-by: Chao Gao 
>> Signed-off-by: Lan Tianyu 
>> ---
>> v4:
>>  - new
>> ---
>>  xen/arch/x86/hvm/hvm.c |  2 +-
>>  xen/drivers/passthrough/io.c   | 89 
>> --
>>  xen/drivers/passthrough/vtd/vvtd.c | 70 --
>>  xen/include/asm-x86/hvm/hvm.h  |  2 +
>>  xen/include/asm-x86/hvm/irq.h  |  1 +
>>  xen/include/asm-x86/viommu.h   | 11 +
>>  6 files changed, 147 insertions(+), 28 deletions(-)
>> 
>> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
>> index 964418a..d2c1372 100644
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -462,7 +462,7 @@ void hvm_migrate_timers(struct vcpu *v)
>>  pt_migrate(v);
>>  }
>>  
>> -static int hvm_migrate_pirq(struct domain *d, struct hvm_pirq_dpci 
>> *pirq_dpci,
>> +int hvm_migrate_pirq(struct domain *d, struct hvm_pirq_dpci *pirq_dpci,
>>  void *arg)
>>  {
>>  struct vcpu *v = arg;
>> diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
>> index d8c66bf..9198ef5 100644
>> --- a/xen/drivers/passthrough/io.c
>> +++ b/xen/drivers/passthrough/io.c
>> @@ -21,6 +21,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -275,6 +276,61 @@ static struct vcpu *vector_hashing_dest(const struct 
>> domain *d,
>>  return dest;
>>  }
>>  
>> +void pt_update_gmsi(struct domain *d, struct hvm_pirq_dpci *pirq_dpci)
>> +{
>> +uint8_t dest, delivery_mode;
>> +bool dest_mode;
>> +int dest_vcpu_id;
>> +const struct vcpu *vcpu;
>> +struct arch_irq_remapping_request request;
>> +struct arch_irq_remapping_info remap_info;
>> +
>> +ASSERT(spin_is_locked(>event_lock));
>> +
>> +/* Calculate dest_vcpu_id for MSI-type pirq migration. */
>> +irq_request_msi_fill(, pirq_dpci->gmsi.addr, 
>> pirq_dpci->gmsi.data);
>> +if ( viommu_check_irq_remapping(d, ) )
>> +{
>> +/* An error in IRTE, don't perform the optimization */
>> +if ( viommu_get_irq_info(d, , _info) )
>> +{
>> +pirq_dpci->gmsi.posted = false;
>> +pirq_dpci->gmsi.dest_vcpu_id = -1;
>> +pirq_dpci->gmsi.gvec = 0;
>> +return;
>> +}
>> +
>> +dest = remap_info.dest;
>> +dest_mode = remap_info.dest_mode;
>> +delivery_mode = remap_info.delivery_mode;
>> +pirq_dpci->gmsi.gvec = remap_info.vector;
>> +}
>> +else
>> +{
>> +dest = MASK_EXTR(pirq_dpci->gmsi.addr, MSI_ADDR_DEST_ID_MASK);
>> +dest_mode = pirq_dpci->gmsi.addr & MSI_ADDR_DESTMODE_MASK;
>> +delivery_mode = MASK_EXTR(pirq_dpci->gmsi.data,
>> +  MSI_DATA_DELIVERY_MODE_MASK);
>> +pirq_dpci->gmsi.gvec = pirq_dpci->gmsi.data & MSI_DATA_VECTOR_MASK;
>> +}
>> +
>> +dest_vcpu_id = hvm_girq_dest_2_vcpu_id(d, dest, dest_mode);
>> +pirq_dpci->gmsi.dest_vcpu_id = dest_vcpu_id;
>> +
>> +pirq_dpci->gmsi.posted = false;
>> +vcpu = (dest_vcpu_id >= 0) ? d->vcpu[dest_vcpu_id] : NULL;
>
>So you use dest_vcpu_id to get the vcpu here...
>
>> +if ( iommu_intpost )
>> +{
>> +if ( delivery_mode == dest_LowestPrio )
>> +vcpu = vector_hashing_dest(d, dest, dest_mode, 
>> pirq_dpci->gmsi.gvec);
>> +if ( vcpu )
>> +{
>> +pirq_dpci->gmsi.posted = true;
>> +pirq_dpci->gmsi.dest_vcpu_id = vcpu->vcpu_id;
>
>... which is only used here in order to get the dest_vcpu_id back. Is
>this really needed? Can't you just use dest_vcpu_id?
>
>I would rather do:
>
>if ( iommu_intpost && delivery_mode == dest_LowestPrio )
>{

These two 'if' cannot be combined. 

Re: [Xen-devel] [PATCH v3] tools: detect appropriate debug optimization level

[Doug Goldstein]

On 4/28/16 12:40 PM, Wei Liu wrote:
> On Tue, Apr 26, 2016 at 09:38:45AM -0500, Doug Goldstein wrote:
>> When building debug use -Og as the optimization level if its available,
>> otherwise retain the use of -O0. -Og has been added by GCC to enable all
>> optimizations that to not affect debugging while retaining full
>> debugability.
>>
>> Signed-off-by: Doug Goldstein 
>> ---
>> change since v2:
>> - switch back to cc-option-add to not call cc-option on every invocation
>> change since v1:
>> - switch to cc-option to only specify -O0 if -Og isn't supported
>> ---
>>  tools/Rules.mk | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/tools/Rules.mk b/tools/Rules.mk
>> index 9ef0b47..1b79a6e 100644
>> --- a/tools/Rules.mk
>> +++ b/tools/Rules.mk
>> @@ -138,6 +138,7 @@ SHLIB_libxenvchan  = $(SHDEPS_libxenvchan) 
>> -Wl,-rpath-link=$(XEN_LIBVCHAN)
>>  ifeq ($(debug),y)
>>  # Disable optimizations and enable debugging information for macros
>>  CFLAGS += -O0 -g3
>> +$(call cc-option-add,CFLAGS,CC,-Og)
>>  # But allow an override to -O0 in case Python enforces 
>> -D_FORTIFY_SOURCE=.
>>  PY_CFLAGS += $(PY_NOOPT_CFLAGS)
>>  endif
>> -- 
>> 2.7.3
> 
> Heh, this patch seems to has a (good) side effect. I will look into
> fixing that tomorrow.
> 
> make[10]: Entering directory 
> '/local/work/COMMITTER/xen.git/tools/firmware/rombios/32bit/tcgbios'
> gcc   -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing 
> -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement 
> -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -O0 -g3 -Og 
> -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__ -MMD -MF 
> .tcgbios.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE 
> -fno-optimize-sibling-calls -mno-tls-direct-seg-refs  -Werror 
> -fno-stack-protector -fno-exceptions -fno-builtin -msoft-float 
> -I/local/work/COMMITTER/xen.git/tools/firmware/rombios/32bit/tcgbios/../../../../../tools/include
>  -I.. -I../..  -c -o tcgbios.o tcgbios.c 
> gcc   -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing 
> -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement 
> -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -O0 -g3 -Og 
> -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__ -MMD -MF 
> .tpm_drivers.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE 
> -fno-optimize-sibling-calls -mno-tls-direct-seg-refs  -Werror 
> -fno-stack-protector -fno-exceptions -fno-builtin -msoft-float 
> -I/local/work/COMMITTER/xen.git/tools/firmware/rombios/32bit/tcgbios/../../../../../tools/include
>  -I.. -I../..  -c -o tpm_drivers.o tpm_drivers.c 
> tcgbios.c: In function ‘tcpa_extend_acpi_log’:
> tcgbios.c:362:3: error: ‘size’ may be used uninitialized in this function 
> [-Werror=maybe-uninitialized]
>memcpy((char *)lasa_last, (char *)entry_ptr, size);
>^
> tcgbios.c: In function ‘HashLogEvent32’:
> tcgbios.c:1142:22: error: ‘entry’ may be used uninitialized in this function 
> [-Werror=maybe-uninitialized]
> hleo->eventnumber = entry;
>   ^
> tcgbios.c:1131:10: error: ‘logdataptr’ may be used uninitialized in this 
> function [-Werror=maybe-uninitialized]
> entry = tcpa_extend_acpi_log(logdataptr);
>   ^

This appears to be fixed with 0b5e769ae3ac81f8a8dfaf476147ccdf41caeb68
but the patch referenced here never landed. The patch doesn't apply
cleanly anymore (due to context) but its a one-liner so maybe someone
can fix it up as its committed?

-- 
Doug Goldstein



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH RFC 00/10] x86 passthrough code cleanup

[Doug Goldstein]

On 2/22/18 11:12 PM, Tian, Kevin wrote:
>> From: Wei Liu
>> Sent: Thursday, February 22, 2018 5:47 AM
>>
>> Hi all
>>
>> At some point I would like to make CONFIG_HVM and CONFIG_PV work.
>> The
>> passthrough code is one of the road blocks for that work.
> 
> Can you elaborate the motivation of this change? why does someone
> want to disable HVM or PV logic completely from hypervisor?

I can say I recall advocating for this at Xen Summit in Cambridge. I
believe I talked about it in Toronto as well. There are a number of
users of Xen that would certainly want to ship without all the code
associated with PV compiled in. Given the nature of design "compromises"
in many parts of x86 systems there is certainly a non-zero sum of people
that would likely utilize the ability to remove code that doesn't need
to be there. I think every individual on this list who has been involved
in the security has been in a room of @intel.com folks has seen features
vs security win out many times.

I don't think its a hard stretch of the imagination to see people
disabling PV in data centers running newer workloads on PVH and HVM
only. I can see the real question being why HVM? That I would say lies
with the direction of discretionary access controls in Xen vs mandatory
access controls. To solve for the lack of functionality we've grown
things like "dmops" and I could certainly see a product like Qubes
running only PVH domains in the future.

Since I picked on Qubes I've CC'd Marek.

-- 
Doug Goldstein



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2] x86/HVM: don't give the wrong impression of WRMSR succeeding

[Tian, Kevin]

> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, February 23, 2018 4:37 PM
> 
> ... for non-existent MSRs: wrmsr_hypervisor_regs()'s comment clearly
> says that the function returns 0 for unrecognized MSRs, so
> {svm,vmx}_msr_write_intercept() should not convert this into success. We
> don't want to unconditionally fail the access though, as we can't be
> certain the list of handled MSRs is complete enough for the guest types
> we care about, so instead mirror what we do on the read paths and probe
> the MSR to decide whether to raise #GP.
> 
> Signed-off-by: Jan Beulich 

Reviewed-by: Kevin Tian 

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

Re: [Xen-devel] [PATCH v4 18/28] x86/vioapic: Hook interrupt delivery of vIOAPIC

[Tian, Kevin]

> From: Gao, Chao
> Sent: Saturday, February 24, 2018 9:51 AM
> 
> On Mon, Feb 12, 2018 at 02:54:02PM +, Roger Pau Monné wrote:
> >On Fri, Nov 17, 2017 at 02:22:25PM +0800, Chao Gao wrote:
> >> When irq remapping is enabled, IOAPIC Redirection Entry may be in
> remapping
> >> format. If that, generate an irq_remapping_request and call the
> common
> >
> >"If that's the case, ..."
> >
> >> VIOMMU abstraction's callback to handle this interrupt request. Device
> >> model is responsible for checking the request's validity.
> >
> >What does this exactly mean? Device model is not involved in what the
> >guest writes to the vIOAPIC RTE, so it's impossible for the device
> >model to validate this in any way.
> 
> How about this description:
> When irq remapping is enabled, IOAPIC Redirection Entry may be in
> remapping
> format. If that's the case, an irq_remapping_request will be generated and
> IOMMU-specific handler deals with this request. IOMMU-specific handler
> will check whether the request is valid or not, report error via
> IOMMU-specific machanism if invalid or otherwise transform the request
> to an
> interrupt info (including interrupt destination, vector and trigger mode
> etc.) according to IRT.
> 

the description should match what this patch actually does.
detail about how caller works should be left to the patch where
the caller is introduced. Here imo the subject line is already
clear enough... isn't it? 

Thanks
Kevin

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

Re: [Xen-devel] [PATCH v4 20/28] xen/pt: when binding guest msi, accept the whole msi message

[Chao Gao]

On Mon, Feb 12, 2018 at 03:16:25PM +, Roger Pau Monné wrote:
>On Fri, Nov 17, 2017 at 02:22:27PM +0800, Chao Gao wrote:
>> ... rather than a filtered one. Previously, some fields (reserved or
>> unalterable) are filtered by QEMU. These fields are useless for the
>> legacy interrupt format (i.e. non remappable format). However, these
>> fields are meaningful to remappable format. Accepting the whole msi
>> message will significantly reduce the efforts to support binding
>> remappable format msi.
>
>This should be sent as a separate patch series, together with the
>required QEMU change. Batching it in this series it's going to make it
>harder to commit IMO.

Will do.

>
>Also note that the QEMU side needs to be committed and backported to
>the qemu-xen tree before applying the Xen side.

As for compatibility, How about introducing an new API for binding
interrupt using an unfiltered message? QEMU maintainer thinks changing
an API between QEMU and Xen is not good.

>
>> Signed-off-by: Chao Gao 
>> Signed-off-by: Lan Tianyu 
>> ---
>> v4:
>>  - new
>> ---
>>  tools/libxc/include/xenctrl.h |  7 ---
>>  tools/libxc/xc_domain.c   | 14 --
>>  xen/arch/x86/hvm/vmsi.c   | 12 ++--
>>  xen/drivers/passthrough/io.c  | 36 +---
>>  xen/include/asm-x86/hvm/irq.h |  5 +++--
>>  xen/include/public/domctl.h   |  8 ++--
>>  6 files changed, 40 insertions(+), 42 deletions(-)
>> 
>> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
>> index 666db0b..8ade90c 100644
>> --- a/tools/libxc/include/xenctrl.h
>> +++ b/tools/libxc/include/xenctrl.h
>> @@ -1756,16 +1756,17 @@ int xc_domain_ioport_mapping(xc_interface *xch,
>>  int xc_domain_update_msi_irq(
>>  xc_interface *xch,
>>  uint32_t domid,
>> -uint32_t gvec,
>>  uint32_t pirq,
>> +uint64_t addr,
>> +uint32_t data,
>>  uint32_t gflags,
>
>If you pass addr and data, do you really need to also pass gflags?
>
>> diff --git a/xen/arch/x86/hvm/vmsi.c b/xen/arch/x86/hvm/vmsi.c
>> index 7126de7..5edb0e7 100644
>> --- a/xen/arch/x86/hvm/vmsi.c
>> +++ b/xen/arch/x86/hvm/vmsi.c
>> @@ -101,12 +101,12 @@ int vmsi_deliver(
>>  
>>  void vmsi_deliver_pirq(struct domain *d, const struct hvm_pirq_dpci 
>> *pirq_dpci)
>>  {
>> -uint32_t flags = pirq_dpci->gmsi.gflags;
>> -int vector = pirq_dpci->gmsi.gvec;
>> -uint8_t dest = (uint8_t)flags;
>> -bool dest_mode = flags & XEN_DOMCTL_VMSI_X86_DM_MASK;
>> -uint8_t delivery_mode = MASK_EXTR(flags, 
>> XEN_DOMCTL_VMSI_X86_DELIV_MASK);
>> -bool trig_mode = flags & XEN_DOMCTL_VMSI_X86_TRIG_MASK;
>> +uint8_t vector = pirq_dpci->gmsi.data & MSI_DATA_VECTOR_MASK;
>
>MASK_EXTR please (here and elsewhere).
>
>> +uint8_t dest = MASK_EXTR(pirq_dpci->gmsi.addr, MSI_ADDR_DEST_ID_MASK);
>> +bool dest_mode = pirq_dpci->gmsi.addr & MSI_ADDR_DESTMODE_MASK;
>> +uint8_t delivery_mode = MASK_EXTR(pirq_dpci->gmsi.data,
>> +  MSI_DATA_DELIVERY_MODE_MASK);
>> +bool trig_mode = pirq_dpci->gmsi.data & MSI_DATA_TRIGGER_MASK;
>>  
>>  HVM_DBG_LOG(DBG_LEVEL_IOAPIC,
>>  "msi: dest=%x dest_mode=%x delivery_mode=%x "
>> diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
>> index 8f16e6c..d8c66bf 100644
>> --- a/xen/drivers/passthrough/io.c
>> +++ b/xen/drivers/passthrough/io.c
>> @@ -339,19 +339,17 @@ int pt_irq_create_bind(
>>  {
>>  case PT_IRQ_TYPE_MSI:
>>  {
>> -uint8_t dest, delivery_mode;
>> +uint8_t dest, delivery_mode, gvec;
>
>I'm not sure you really need the gvec local variable, AFAICT it's used
>only once.
>
>> diff --git a/xen/include/asm-x86/hvm/irq.h b/xen/include/asm-x86/hvm/irq.h
>> index 3b6b4bd..3a8832c 100644
>> --- a/xen/include/asm-x86/hvm/irq.h
>> +++ b/xen/include/asm-x86/hvm/irq.h
>> @@ -132,9 +132,10 @@ struct dev_intx_gsi_link {
>>  #define HVM_IRQ_DPCI_TRANSLATE   (1u << _HVM_IRQ_DPCI_TRANSLATE_SHIFT)
>>  
>>  struct hvm_gmsi_info {
>> -uint32_t gvec;
>> -uint32_t gflags;
>> +uint32_t data;
>>  int dest_vcpu_id; /* -1 :multi-dest, non-negative: dest_vcpu_id */
>> +uint64_t addr;
>> +uint8_t gvec;
>
>Can't you just obtain the guest vector from addr and flags?

It seems yes. Will try to remove 'gvec' field.

>
>>  bool posted; /* directly deliver to guest via VT-d PI? */
>>  };
>>  
>> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
>> index 9f6f0aa..2717c68 100644
>> --- a/xen/include/public/domctl.h
>> +++ b/xen/include/public/domctl.h
>> @@ -536,15 +536,11 @@ struct xen_domctl_bind_pt_irq {
>>  uint8_t intx;
>>  } pci;
>>  struct {
>> -uint8_t gvec;
>>  uint32_t gflags;
>> -#define XEN_DOMCTL_VMSI_X86_DEST_ID_MASK 0xff
>> -#define XEN_DOMCTL_VMSI_X86_RH_MASK  0x000100
>> -#define XEN_DOMCTL_VMSI_X86_DM_MASK  0x000200
>> 

Re: [Xen-devel] [PATCH 7/7] x86: add iommu_ops to map and unmap pages, and also to flush the IOTLB

[Tian, Kevin]

> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Friday, February 23, 2018 5:35 PM
> 
> > -Original Message-
> > From: Tian, Kevin [mailto:kevin.t...@intel.com]
> > Sent: 23 February 2018 05:36
> > To: Paul Durrant ; xen-
> de...@lists.xenproject.org
> > Cc: Stefano Stabellini ; Wei Liu
> > ; George Dunlap ;
> > Andrew Cooper ; Ian Jackson
> > ; Tim (Xen.org) ; Jan Beulich
> > 
> > Subject: RE: [Xen-devel] [PATCH 7/7] x86: add iommu_ops to map and
> > unmap pages, and also to flush the IOTLB
> >
> > > From: Paul Durrant [mailto:paul.durr...@citrix.com]
> > > Sent: Tuesday, February 13, 2018 5:56 PM
> > >
> > > > -Original Message-
> > > > From: Tian, Kevin [mailto:kevin.t...@intel.com]
> > > > Sent: 13 February 2018 06:56
> > > > To: Paul Durrant ; xen-
> > > de...@lists.xenproject.org
> > > > Cc: Stefano Stabellini ; Wei Liu
> > > > ; George Dunlap ;
> > > > Andrew Cooper ; Ian Jackson
> > > > ; Tim (Xen.org) ; Jan Beulich
> > > > 
> > > > Subject: RE: [Xen-devel] [PATCH 7/7] x86: add iommu_ops to map and
> > > > unmap pages, and also to flush the IOTLB
> > > >
> > > > > From: Paul Durrant
> > > > > Sent: Monday, February 12, 2018 6:47 PM
> > > > >
> > > > > This patch adds iommu_ops to allow a domain with control_iommu
> > > > > privilege
> > > > > to map and unmap pages from any guest over which it has mapping
> > > > > privilege
> > > > > in the IOMMU.
> > > > > These operations implicitly disable IOTLB flushing so that the caller
> can
> > > > > batch operations and then explicitly flush the IOTLB using the
> > > iommu_op
> > > > > also added by this patch.
> > > >
> > > > given that last discussion is 2yrs ago and you said actual
> implementation
> > > > already biased from original spec, it'd be difficult to judge whether
> > > current
> > > > change is sufficient or just 1st step. Could you summarize what have
> > > > been changed from last spec, and also any further tasks in your TODO
> > list?
> > >
> > > Kevin,
> > >
> > > The main changes are:
> > >
> > > - there is no op to query mapping capability... instead the hypercall will
> fail
> > > with -EACCES
> > > - there is no longer an option to avoid reference counting map and
> unmap
> > > operations
> > > - there are no longer separate ops for mapping local and remote pages
> > > (DOMID_SELF should be passed to the map op for local pages), and ops
> > > always deal with GFNs not MFNs
> > >   - also I have dropped the idea of a global m2b map, so...
> > >   - it is now going to be the responsibility of the code running in the
> > > mapping domain to track what it has mapped [1]
> > > - there is no illusion that pages other 4k are supported at the moment
> > > - the flush operation is now explicit
> > >
> > > [1] this would be an issue if the interface becomes usable for anything
> > > other than dom0 as we'd also need something in Xen to release the
> page
> > > refs if the domain was forcibly destroyed, but I think the m2b was the
> > > wrong solution since it necessitates a full scan of *host* RAM on any
> > > domain destruction
> > >
> > > The main item on my TODO list is to implement a new IOREQ to allow
> > > invalidation of specific guest pages. Think of the current 'invalidate map
> > > cache' as a global flush... I need a specific flush so that a
> > > decrease_reservation hypercall issued by a guest can instead tell
> emulators
> > > exactly which pages are being removed from guest. It is then the
> > emulators'
> > > responsibilities to unmap those pages if they had them mapped (either
> > > through MMU or IOMMU) which then drop page refs and actually allow
> the
> > > pages to be recycled.
> > >
> > > I will, of course, need to come up with more Linux code to test all this,
> > > which will eventually lead to kernel and user APIs to allow emulators
> > > running in dom0 to IOMMU map guest pages.
> >
> > Thanks for elaboration. I didn't find original proposal. Can you
> > attach or point me to a link?
> >
> 
> FWIW, I've attached Malcolm's original for reference.

Thanks. I'll have a read.

> 
> > >
> > > >
> > > > at least just map/unmap operations definitely not meet XenGT
> > > > requirement...
> > > >
> > >
> > > What aspect of the hypercall interface does not meet XenGT's
> > > requirements? It would be good to know now then I can make any
> > > necessary adjustments in v2.
> > >
> >
> > XenGT needs to replace GFN with BFN into shadow GPU page table
> > for a given domain.
> 
> I assume xengt would be dynamically mapping the gfn at this point...
> 
> > Previously iirc there is a query interface for such
> > purpose, since the mapping is managed by 

Re: [Xen-devel] [PATCH 5/7] public / x86: introduce __HYPERCALL_iommu_op

[Tian, Kevin]

> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Friday, February 23, 2018 5:41 PM
> 
> > -Original Message-
> > From: Tian, Kevin [mailto:kevin.t...@intel.com]
> > Sent: 23 February 2018 05:17
> > To: Paul Durrant ; xen-
> de...@lists.xenproject.org
> > Cc: Stefano Stabellini ; Wei Liu
> > ; George Dunlap ;
> > Andrew Cooper ; Ian Jackson
> > ; Tim (Xen.org) ; Jan Beulich
> > ; Daniel De Graaf 
> > Subject: RE: [Xen-devel] [PATCH 5/7] public / x86: introduce
> > __HYPERCALL_iommu_op
> >
> > > From: Paul Durrant [mailto:paul.durr...@citrix.com]
> > > Sent: Tuesday, February 13, 2018 5:23 PM
> > >
> > > > -Original Message-
> > > > From: Tian, Kevin [mailto:kevin.t...@intel.com]
> > > > Sent: 13 February 2018 06:43
> > > > To: Paul Durrant ; xen-
> > > de...@lists.xenproject.org
> > > > Cc: Stefano Stabellini ; Wei Liu
> > > > ; George Dunlap ;
> > > > Andrew Cooper ; Ian Jackson
> > > > ; Tim (Xen.org) ; Jan Beulich
> > > > ; Daniel De Graaf 
> > > > Subject: RE: [Xen-devel] [PATCH 5/7] public / x86: introduce
> > > > __HYPERCALL_iommu_op
> > > >
> > > > > From: Paul Durrant
> > > > > Sent: Monday, February 12, 2018 6:47 PM
> > > > >
> > > > > This patch introduces the boilerplate for a new hypercall to allow a
> > > > > domain to control IOMMU mappings for its own pages.
> > > > > Whilst there is duplication of code between the native and compat
> > > entry
> > > > > points which appears ripe for some form of combination, I think it is
> > > > > better to maintain the separation as-is because the compat entry
> point
> > > > > will necessarily gain complexity in subsequent patches.
> > > > >
> > > > > NOTE: This hypercall is only implemented for x86 and is currently
> > > > >   restricted by XSM to dom0 since it could be used to cause
> IOMMU
> > > > >   faults which may bring down a host.
> > > > >
> > > > > Signed-off-by: Paul Durrant 
> > > > [...]
> > > > > +
> > > > > +
> > > > > +static bool can_control_iommu(void)
> > > > > +{
> > > > > +struct domain *currd = current->domain;
> > > > > +
> > > > > +/*
> > > > > + * IOMMU mappings cannot be manipulated if:
> > > > > + * - the IOMMU is not enabled or,
> > > > > + * - the IOMMU is passed through or,
> > > > > + * - shared EPT configured or,
> > > > > + * - Xen is maintaining an identity map.
> > > >
> > > > "for dom0"
> > > >
> > > > > + */
> > > > > +if ( !iommu_enabled || iommu_passthrough ||
> > > > > + iommu_use_hap_pt(currd) || need_iommu(currd) )
> > > >
> > > > I guess it's clearer to directly check iommu_dom0_strict here
> > >
> > > Well, the problem with that is that it totally ties this interface to 
> > > dom0.
> > > Whilst, in practice, that is the case at the moment (because of the xsm
> > > check) I do want to leave the potential to allow other PV domains to
> control
> > > their IOMMU mappings, if that make sense in future.
> > >
> >
> > first it's inconsistent from the comments - "Xen is maintaining
> > an identity map" which only applies to dom0.
> 
> That's not true. If I assign a PCI device to an HVM domain, for instance,
> then need_iommu() is true for that domain and indeed Xen maintains a 1:1
> BFN:GFN map for that domain.
> 
> >
> > second I'm afraid !need_iommu is not an accurate condition to represent
> > PV domain. what about iommu also enabled for future PV domains?
> >
> 
> I don't quite follow... need_iommu is a per-domain flag, set for dom0 when
> in strict mode, set for others when passing through a device. Either way, if
> Xen is maintaining the IOMMU pagetables then it is clearly unsafe for the
> domain to also be messing with them.
> 

I don't think it's a mess. Xen always maintains the IOMMU pagetables
in a way that guest expects:

1) for dom0 (w/o pvIOMMU) in strict mode, it's MFN:MFN identity mapping
2) for dom0 (w/ pvIOMMU), it's BFN:MFN mapping
3) for HVM (w/o virtual VTd) with passthrough device, it's GFN:MFN 
4) for HVM (w/ virtual VTd) with passthrough device, it's BFN:MFN

(from IOMMU p.o.v we can always call all 4 categories as BFN:MFN. 
I deliberately separate them from usage p.o.v, where 'BFN'
represents the cases where guest explicitly manages a new address
space - different from physical address space in its mind)

there is an address space switch in 2) and 4) before and after
enabling vIOMMU.

above is why I didn’t follow the assumption that "Xen is maintaining 
an identity map" is identical to need_iommu.

Thanks
Kevin
___
Xen-devel mailing list

Re: [Xen-devel] [PATCH v4 2/7] xen: xsm: flask: introduce XENMAPSPACE_gmfn_share for memory sharing

[Zhongze Liu]

Hi Jan,

(Last week was the Chinese Spring Festival, so I failed to follow up
timely. Sorry for that.)

2018-02-15 16:58 GMT+08:00 Jan Beulich :
 On 14.02.18 at 18:02,  wrote:
>> 2018-02-14 16:37 GMT+08:00 Jan Beulich :
>> On 14.02.18 at 08:15,  wrote:
 2018-02-13 23:26 GMT+08:00 Jan Beulich :
 On 13.02.18 at 16:15,  wrote:
>> I've updated the comments according to your previous suggestions,
>> do they look good to you?
>
> The one in the public header is way too verbose. I specifically don't
> see why you would need to spell out XSM privilege requirements
> there. Please make new comments match existing ones in style and
> verbosity if at all possible, while still conveying all necessary /
> relevant information.
>

 I shortened it a little bit, and now it looks like:

 #define XENMAPSPACE_gmfn_share   6 /* GMFN from another dom. Unlike
 gmfn_foreign,
   if (c) tries to map pages from (t) 
 into
   (d), this doesn't require that (d) 
 itself
   has the privilege to map the pages, 
 but
   instead requires that (c) has the
   privilege to do so, as long as (d) 
 and (t)
   are allowed to share memory pages.
   This is XENMEM_add_to_physmap_batch 
 only,
   and currently ARM only. */
>>>
>>> Which leaves unclear what (c), (d), and (t) are. How about
>>>
>>> "GMFN from another dom, XENMEM_add_to_physmap_batch (and
>>> currently ARM) only. Other than XENMAPSPACE_gmfn_foreign this
>>> ."
>>>
>>> (You can and should go into further detail in the commit message.)
>>> Without this _properly_ explained, I'll continue to ask why you
>>> can't simply make XENMAPSPACE_gmfn_foreign do what you want
>>> (as it already takes two domid_t-s as input), by suitably adjusting
>>> its XSM check(s).
>>
>> I'm sorry that I failed to see the reason why you say "which leaves
>> unclear what (c), (d), and (t) are". I think "if (c) tries to map pages
>> from (t) into (d)" has already included the necessary information
>> about this: (c) is the caller of the hypercall (current), (d) is the
>> dest domain, and (t) the source domain.
>> I think I still need more of your explanation here.
>
> Someone coming across _just_ this comment (while reading the
> public header) will not necessarily know what (c), (d), and (t)
> stand for, and (s)he shouldn't be forced to dig into git history to
> find the patch description. But anyway - all this should go away
> from the header anyway, as explained before. All that's needed
> here is a terse but understandable explanation of what's different
> from XENMAPSPACE_gmfn_foreign.
>

I think before we can reach a consensus on how the final comment
should look like, we need to reach an agreement on what should
be included in the  part. And according to our previous
discussion, below is what I think is necessary so far:

1. Different privilege requirements


2. Why we can't just modify the original hypercall to meet our needs.

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

Re: [Xen-devel] [PATCH v4 18/28] x86/vioapic: Hook interrupt delivery of vIOAPIC

[Chao Gao]

On Mon, Feb 12, 2018 at 02:54:02PM +, Roger Pau Monné wrote:
>On Fri, Nov 17, 2017 at 02:22:25PM +0800, Chao Gao wrote:
>> When irq remapping is enabled, IOAPIC Redirection Entry may be in remapping
>> format. If that, generate an irq_remapping_request and call the common
>
>"If that's the case, ..."
>
>> VIOMMU abstraction's callback to handle this interrupt request. Device
>> model is responsible for checking the request's validity.
>
>What does this exactly mean? Device model is not involved in what the
>guest writes to the vIOAPIC RTE, so it's impossible for the device
>model to validate this in any way.

How about this description:
When irq remapping is enabled, IOAPIC Redirection Entry may be in remapping
format. If that's the case, an irq_remapping_request will be generated and
IOMMU-specific handler deals with this request. IOMMU-specific handler
will check whether the request is valid or not, report error via
IOMMU-specific machanism if invalid or otherwise transform the request to an
interrupt info (including interrupt destination, vector and trigger mode
etc.) according to IRT.

>
>> Signed-off-by: Chao Gao 
>> Signed-off-by: Lan Tianyu 
>> 
>> ---
>> v3:
>>  - use the new interface to check remapping format.
>> ---
>>  xen/arch/x86/hvm/vioapic.c   | 9 +
>>  xen/include/asm-x86/viommu.h | 9 +
>>  2 files changed, 18 insertions(+)
>> 
>> diff --git a/xen/arch/x86/hvm/vioapic.c b/xen/arch/x86/hvm/vioapic.c
>> index 97b419f..0f20e3f 100644
>> --- a/xen/arch/x86/hvm/vioapic.c
>> +++ b/xen/arch/x86/hvm/vioapic.c
>> @@ -30,6 +30,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -387,9 +388,17 @@ static void vioapic_deliver(struct hvm_vioapic 
>> *vioapic, unsigned int pin)
>>  struct vlapic *target;
>>  struct vcpu *v;
>>  unsigned int irq = vioapic->base_gsi + pin;
>> +struct arch_irq_remapping_request request;
>>  
>>  ASSERT(spin_is_locked(>arch.hvm_domain.irq_lock));
>>  
>> +irq_request_ioapic_fill(, vioapic->id, 
>> vioapic->redirtbl[pin].bits);
>> +if ( viommu_check_irq_remapping(d, ) )
>> +{
>> +viommu_handle_irq_request(d, );
>> +return;
>> +}
>
>Will this compile if you disable vIOMMU in Kconfig?

Yes. Will fix this by wrapping this fragment with #ifdef and #endif.

Thanks
Chao

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

Re: [Xen-devel] [PATCH V5] x86/hvm: fix domain crash when CR3 has the noflush bit set

[Tian, Kevin]

> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com]
> Sent: Friday, February 23, 2018 3:32 PM
> 
> On 02/23/2018 09:29 AM, Razvan Cojocaru wrote:
> > Lacking PCID support in the emulation layer creates two different way of
> > handling the NOFLUSH being set: one is in hardware, and this happens for
> > everything except the introspection case, and one in the emulation layer
> > (this happens when an introspection agent asks Xen to emulate an
> > instruction when it replies to an EPT fault vm_event).
> 
> Sorry, not when the introspection agent asks Xen to emulate an
> instruction when it replies to an EPT fault vm_event, but when the
> introspection agent wants to be able to veto a CR3 write - i.e. when the
> introspection agent subscribes to CR3 write events.
> 

yes, that's what I wondered when reading your 1st reply. 

Now I understood the background and the patch overall looks
good to me. 

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

[Xen-devel] [xen-4.6-testing test] 119921: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 
119227

Tests which did not succeed, but are not blocking:
 test-xtf-amd64-amd64-2  50 xtf/test-hvm64-lbr-tsx-vmentry fail like 119187
 test-xtf-amd64-amd64-4  50 xtf/test-hvm64-lbr-tsx-vmentry fail like 119227
 test-xtf-amd64-amd64-5  50 xtf/test-hvm64-lbr-tsx-vmentry fail like 119227
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 119227
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 119227
 test-armhf-armhf-xl-rtds 12 guest-start  fail  like 119227
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 119227
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 119227
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 119227
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 119227
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 119227
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 119227
 test-xtf-amd64-amd64-4   37 xtf/test-hvm32pae-memop-seg  fail   never pass
 test-xtf-amd64-amd64-2   37 xtf/test-hvm32pae-memop-seg  fail   never pass
 test-xtf-amd64-amd64-5   37 xtf/test-hvm32pae-memop-seg  fail   never pass
 test-xtf-amd64-amd64-1   37 xtf/test-hvm32pae-memop-seg  fail   never pass
 test-xtf-amd64-amd64-4   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-2   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-5   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-1   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-4   76 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-3   37 xtf/test-hvm32pae-memop-seg  fail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-2   76 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-5   76 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-3   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-1   76 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-3   76 xtf/test-pv32pae-xsa-194 fail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail 

Re: [Xen-devel] Minutes of the Xen ARM community call Tuesday 13th February 5PM UTC

[Stefano Stabellini]

On Thu, 15 Feb 2018, Stefano Stabellini wrote:
> = AGL Whitepaper =
> Artem: please review the whitepaper, most of the content is already
> there.
> Everybody agrees that Xen Project should publish its own whitepaper.
> 
> Certifications are mostly not about the code. Artem about to share an
> analysis done by third parties on certification gaps. Then, we'll
> organize another call.
> ACTION Artem: send out the gap analysis

Hi Artem,

Have you had a chance to share the gap analysis whitepaper yet? If you
did, I might have missed it in my inbox.

Thank you!

Cheers,

Stefano

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

Re: [Xen-devel] [PATCH v3 2/2] vmx/hap: optimize CR4 trapping

[Tian, Kevin]

> From: Roger Pau Monné [mailto:roger@citrix.com]
> Sent: Friday, February 23, 2018 6:18 PM
> 
> On Fri, Feb 23, 2018 at 04:56:38AM +, Tian, Kevin wrote:
> > > From: Roger Pau Monne [mailto:roger@citrix.com]
> > > Sent: Tuesday, February 20, 2018 4:57 PM
> > >
> > > There a bunch of bits in CR4 that should be allowed to be set directly
> > > by the guest without requiring Xen intervention, currently this is
> > > already done by passing through guest writes into the CR4 used when
> > > running in non-root mode, but taking an expensive vmexit in order to
> > > do so.
> > >
> > > xenalyze reports the following when running a PV guest in shim mode:
> > >
> > >  CR_ACCESS 3885950  6.41s 17.04%  3957 cyc { 2361| 3378| 7920}
> > >cr4  3885940  6.41s 17.04%  3957 cyc { 2361| 3378| 7920}
> > >cr31  0.00s  0.00%  3480 cyc { 3480| 3480| 3480}
> > >  *[  0]1  0.00s  0.00%  3480 cyc { 3480| 3480| 3480}
> > >cr07  0.00s  0.00%  7112 cyc { 3248| 5960|17480}
> > >clts2  0.00s  0.00%  4588 cyc { 3456| 5720| 5720}
> > >
> > > After this change this turns into:
> > >
> > >  CR_ACCESS  12  0.00s  0.00%  9972 cyc { 3680|11024|24032}
> > >cr42  0.00s  0.00% 17528 cyc {11024|24032|24032}
> > >cr31  0.00s  0.00%  3680 cyc { 3680| 3680| 3680}
> > >  *[  0]1  0.00s  0.00%  3680 cyc { 3680| 3680| 3680}
> > >cr07  0.00s  0.00%  9209 cyc { 4184| 7848|17488}
> > >clts2  0.00s  0.00%  8232 cyc { 5352|2|2}
> > >
> > > Note that this optimized trapping is currently only applied to guests
> > > running with HAP on Intel hardware. If using shadow paging more CR4
> > > bits need to be unconditionally trapped, which makes this approach
> > > unlikely to yield any important performance improvements.
> > >
> > > Reported-by: Andrew Cooper 
> > > Signed-off-by: Roger Pau Monné 
> > > Acked-by: Razvan Cojocaru 
> > > ---
> > > Cc: Jun Nakajima 
> > > Cc: Kevin Tian 
> > > Cc: Jan Beulich 
> > > Cc: Andrew Cooper 
> > > Cc: Razvan Cojocaru 
> > > Cc: Tamas K Lengyel 
> > > ---
> > > Changes since v2:
> > >  - Use cr4_host_mask.
> > >
> > > Changes since v1:
> > >  - Use the mask_cr variable in order to cache the cr4 mask.
> > >  - Take into account write_ctrlreg_mask when introspection is enabled.
> > > ---
> > >  xen/arch/x86/hvm/vmx/vmx.c  | 39
> > > +++
> > >  xen/arch/x86/hvm/vmx/vvmx.c |  2 ++
> > >  xen/arch/x86/monitor.c  |  5 +++--
> > >  3 files changed, 44 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/xen/arch/x86/hvm/vmx/vmx.c
> b/xen/arch/x86/hvm/vmx/vmx.c
> > > index 5cd689e823..27cbbe8823 100644
> > > --- a/xen/arch/x86/hvm/vmx/vmx.c
> > > +++ b/xen/arch/x86/hvm/vmx/vmx.c
> > > @@ -1684,6 +1684,36 @@ static void vmx_update_guest_cr(struct vcpu
> *v,
> > > unsigned int cr)
> > >  }
> > >
> > >  __vmwrite(GUEST_CR4, v->arch.hvm_vcpu.hw_cr[4]);
> > > +
> > > +if ( !paging_mode_hap(v->domain) )
> > > +/*
> > > + * Shadow path has not been optimized because it requires
> > > + * unconditionally trapping more CR4 bits, at which point the
> > > + * performance benefit of doing this is quite dubious.
> > > + */
> > > +v->arch.hvm_vcpu.cr4_host_mask = ~0UL;
> > > +else
> > > +{
> > > +/*
> > > + * Update CR4 host mask to only trap when the guest tries to 
> > > set
> > > + * bits that are controlled by the hypervisor.
> > > + */
> > > +v->arch.hvm_vcpu.cr4_host_mask = HVM_CR4_HOST_MASK |
> > > X86_CR4_PKE |
> > > + 
> > > ~hvm_cr4_guest_valid_bits(v, 0);
> > > +v->arch.hvm_vcpu.cr4_host_mask |= v-
> > > >arch.hvm_vmx.vmx_realmode ?
> > > +  X86_CR4_VME : 0;
> > > +v->arch.hvm_vcpu.cr4_host_mask |= !hvm_paging_enabled(v) ?
> > > +  (X86_CR4_PSE | 
> > > X86_CR4_SMEP |
> > > +   X86_CR4_SMAP)
> > > +  : 0;
> > > +if ( v->domain->arch.monitor.write_ctrlreg_enabled &
> > > + monitor_ctrlreg_bitmask(VM_EVENT_X86_CR4) )
> > > +v->arch.hvm_vcpu.cr4_host_mask |=
> > > +~v->domain-
> > > >arch.monitor.write_ctrlreg_mask[VM_EVENT_X86_CR4];
> > > +
> > > +}
> > > +__vmwrite(CR4_GUEST_HOST_MASK, v-
> > > >arch.hvm_vcpu.cr4_host_mask);
> > > +
> >
> > what about doing a comparison to avoid vmwrite if nothing changed?
> 
> I can do that, but it doesn't 

Re: [Xen-devel] [PATCH] tools/xenstore: try to get minimum thread stack size for watch thread

[Jim Fehlig]

On 02/22/2018 06:53 AM, Juergen Gross wrote:

When creating a pthread in xs_watch() try to get the minimal needed
size of the thread from glibc instead of using a constant. This avoids
problems when the library is used in programs with large per-thread
memory.

Use dlsym() to get the pointer to __pthread_get_minstack() in order to
avoid linkage problems and fall back to the current constant size if
not found.

Signed-off-by: Juergen Gross 
---
Only compile tested. Jim, can you please verify this patch is solving
your original problem?


It didn't help, but it could be due to my buggy glibc

# gdb xl
...
(gdb) r create test-hvm.xl
Starting program: /usr/sbin/xl create test-hvm.xl
Parsing config from test-hvm.xl
Program received signal SIGSEGV, Segmentation fault.
0x772d51c2 in __pthread_get_minstack () from /lib64/libpthread.so.0
(gdb) thr a a bt

Thread 1 (Thread 0x77fd8780 (LWP 2568)):
#0  0x772d51c2 in __pthread_get_minstack () from /lib64/libpthread.so.0
#1  0x766ae259 in xs_watch (h=0x5578fc90,
path=path@entry=0x55798fa0 "/local/domain/0/device-model/2/state",
token=token@entry=0x557990b0 "3/0") at xs.c:826
#2  0x779476f4 in libxl__ev_xswatch_register 
(gc=gc@entry=0x557955f0,
w=w@entry=0x55797468, func=func@entry=0x7793dd10 
,
path=0x55798fa0 "/local/domain/0/device-model/2/state") at 
libxl_event.c:638

#3  0x7793deb0 in libxl__xswait_start (gc=gc@entry=0x557955f0,
xswa=xswa@entry=0x557973e0) at libxl_aoutils.c:53
#4  0x779326b0 in libxl__spawn_spawn (egc=egc@entry=0x7fffd950,
ss=ss@entry=0x55797370) at libxl_exec.c:292
#5  0x779258d3 in libxl__spawn_local_dm (egc=0x7fffd950, 
dmss=)

at libxl_dm.c:2400
#6  0x7791d3a7 in domcreate_launch_dm (egc=0x7fffd950, 
multidev=0x55798168,

ret=) at libxl_create.c:1379
#7  0x77967275 in libxl__bootloader_run (egc=egc@entry=0x7fffd950,
bl=bl@entry=0x55796cc0) at libxl_bootloader.c:403
#8  0x7791ffe3 in initiate_domain_create (egc=egc@entry=0x7fffd950,
dcs=dcs@entry=0x55796610) at libxl_create.c:997
#9  0x779201a1 in do_domain_create (ctx=ctx@entry=0x5578f2a0,
d_config=d_config@entry=0x7fffdb70, domid=domid@entry=0x7fffdaa8,
restore_fd=restore_fd@entry=-1, send_back_fd=send_back_fd@entry=-1, 
params=params@entry=0x0,

ao_how=0x0, aop_console_how=0x0) at libxl_create.c:1682
#10 0x779204b6 in libxl_domain_create_new (ctx=0x5578f2a0,
d_config=d_config@entry=0x7fffdb70, domid=domid@entry=0x7fffdaa8,
ao_how=ao_how@entry=0x0, aop_console_how=aop_console_how@entry=0x0) at 
libxl_create.c:1885

#11 0x555780b4 in create_domain (dom_info=dom_info@entry=0x7fffe0b0)
at xl_vmcontrol.c:902
#12 0x555790c4 in main_create (argc=1, argv=0x7fffe378) at 
xl_vmcontrol.c:1207

#13 0x55560c5b in main (argc=2, argv=0x7fffe370) at xl.c:384

If you like, I can try a patched glibc after the weekend :-).

Regards,
Jim


---
  tools/xenstore/Makefile |  4 
  tools/xenstore/xs.c | 19 ++-
  2 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile
index 2b99d2bc1b..fb6c73e297 100644
--- a/tools/xenstore/Makefile
+++ b/tools/xenstore/Makefile
@@ -100,6 +100,10 @@ libxenstore.so.$(MAJOR): libxenstore.so.$(MAJOR).$(MINOR)
ln -sf $< $@
  
  xs.opic: CFLAGS += -DUSE_PTHREAD

+ifeq ($(CONFIG_Linux),y)
+xs.opic: CFLAGS += -DUSE_DLSYM
+xs.opic: LDFLAGS += -ldl
+endif
  
  libxenstore.so.$(MAJOR).$(MINOR): xs.opic xs_lib.opic

$(CC) $(LDFLAGS) $(PTHREAD_LDFLAGS) -Wl,$(SONAME_LDFLAG) 
-Wl,libxenstore.so.$(MAJOR) $(SHLIB_LDFLAGS) -o $@ $^ $(LDLIBS_libxentoolcore) 
$(SOCKET_LIBS) $(PTHREAD_LIBS) $(APPEND_LDFLAGS)
diff --git a/tools/xenstore/xs.c b/tools/xenstore/xs.c
index abffd9cd80..8372f5b1a4 100644
--- a/tools/xenstore/xs.c
+++ b/tools/xenstore/xs.c
@@ -47,6 +47,11 @@ struct xs_stored_msg {
  
  #include 
  
+#ifdef USE_DLSYM

+#define __USE_GNU
+#include 
+#endif
+
  struct xs_handle {
/* Communications channel to xenstore daemon. */
int fd;
@@ -810,12 +815,24 @@ bool xs_watch(struct xs_handle *h, const char *path, 
const char *token)
if (!h->read_thr_exists) {
sigset_t set, old_set;
pthread_attr_t attr;
+   static size_t stack_size;
+#ifdef USE_DLSYM
+   size_t (*getsz)(void);
+#endif
  
+		if (!stack_size) {

+#ifdef USE_DLSYM
+   getsz = dlsym(RTLD_DEFAULT, "__pthread_get_minstack");
+   stack_size = getsz ? getsz() : READ_THREAD_STACKSIZE;
+#else
+   stack_size = READ_THREAD_STACKSIZE;
+#endif
+   }
if (pthread_attr_init() != 0) {
mutex_unlock(>request_mutex);
return false;
 

Re: [Xen-devel] [PATCH v5 01/18] xen/arm: psci: Rework the PSCI definitions

[Stefano Stabellini]

On Fri, 23 Feb 2018, Julien Grall wrote:
> Some PSCI functions are only available in the 32-bit version. After
> recent changes, Xen always needs to know whether the call was made using
> 32-bit id or 64-bit id. So we don't emulate reserved one.
> 
> With the current naming scheme, it is not easy to know which call
> supports 32-bit and 64-bit id. So rework the definitions to encode the
> version in the name. From now the functions will be named PSCI_0_2_FNxx
> where xx is 32 or 64.
> 
> Signed-off-by: Julien Grall 
> Reviewed-by: Volodymyr Babchuk 

Acked-by: Stefano Stabellini 

> ---
> Changes in v2:
> - Add Volodymyr's reviewed-by
> ---
>  xen/arch/arm/platforms/seattle.c |  4 ++--
>  xen/arch/arm/psci.c  | 10 +-
>  xen/arch/arm/vpsci.c | 22 +++---
>  xen/include/asm-arm/psci.h   | 37 +
>  4 files changed, 39 insertions(+), 34 deletions(-)
> 
> diff --git a/xen/arch/arm/platforms/seattle.c 
> b/xen/arch/arm/platforms/seattle.c
> index 22c062293f..893cc17972 100644
> --- a/xen/arch/arm/platforms/seattle.c
> +++ b/xen/arch/arm/platforms/seattle.c
> @@ -33,12 +33,12 @@ static const char * const seattle_dt_compat[] __initconst 
> =
>   */
>  static void seattle_system_reset(void)
>  {
> -call_smc(PSCI_0_2_FN32(SYSTEM_RESET), 0, 0, 0);
> +call_smc(PSCI_0_2_FN32_SYSTEM_RESET, 0, 0, 0);
>  }
>  
>  static void seattle_system_off(void)
>  {
> -call_smc(PSCI_0_2_FN32(SYSTEM_OFF), 0, 0, 0);
> +call_smc(PSCI_0_2_FN32_SYSTEM_OFF, 0, 0, 0);
>  }
>  
>  PLATFORM_START(seattle, "SEATTLE")
> diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c
> index 1508a3be3a..5dda35cd7c 100644
> --- a/xen/arch/arm/psci.c
> +++ b/xen/arch/arm/psci.c
> @@ -31,9 +31,9 @@
>   * (native-width) function ID.
>   */
>  #ifdef CONFIG_ARM_64
> -#define PSCI_0_2_FN_NATIVE(name)PSCI_0_2_FN64(name)
> +#define PSCI_0_2_FN_NATIVE(name)PSCI_0_2_FN64_##name
>  #else
> -#define PSCI_0_2_FN_NATIVE(name)PSCI_0_2_FN32(name)
> +#define PSCI_0_2_FN_NATIVE(name)PSCI_0_2_FN32_##name
>  #endif
>  
>  uint32_t psci_ver;
> @@ -48,13 +48,13 @@ int call_psci_cpu_on(int cpu)
>  void call_psci_system_off(void)
>  {
>  if ( psci_ver > PSCI_VERSION(0, 1) )
> -call_smc(PSCI_0_2_FN32(SYSTEM_OFF), 0, 0, 0);
> +call_smc(PSCI_0_2_FN32_SYSTEM_OFF, 0, 0, 0);
>  }
>  
>  void call_psci_system_reset(void)
>  {
>  if ( psci_ver > PSCI_VERSION(0, 1) )
> -call_smc(PSCI_0_2_FN32(SYSTEM_RESET), 0, 0, 0);
> +call_smc(PSCI_0_2_FN32_SYSTEM_RESET, 0, 0, 0);
>  }
>  
>  int __init psci_is_smc_method(const struct dt_device_node *psci)
> @@ -144,7 +144,7 @@ int __init psci_init_0_2(void)
>  }
>  }
>  
> -psci_ver = call_smc(PSCI_0_2_FN32(PSCI_VERSION), 0, 0, 0);
> +psci_ver = call_smc(PSCI_0_2_FN32_PSCI_VERSION, 0, 0, 0);
>  
>  /* For the moment, we only support PSCI 0.2 and PSCI 1.x */
>  if ( psci_ver != PSCI_VERSION(0, 2) && PSCI_VERSION_MAJOR(psci_ver) != 1 
> )
> diff --git a/xen/arch/arm/vpsci.c b/xen/arch/arm/vpsci.c
> index 03fd4eb5b5..6ab8ab64d0 100644
> --- a/xen/arch/arm/vpsci.c
> +++ b/xen/arch/arm/vpsci.c
> @@ -243,35 +243,35 @@ bool do_vpsci_0_2_call(struct cpu_user_regs *regs, 
> uint32_t fid)
>   */
>  switch ( fid )
>  {
> -case PSCI_0_2_FN32(PSCI_VERSION):
> +case PSCI_0_2_FN32_PSCI_VERSION:
>  perfc_incr(vpsci_version);
>  PSCI_SET_RESULT(regs, do_psci_0_2_version());
>  return true;
>  
> -case PSCI_0_2_FN32(CPU_OFF):
> +case PSCI_0_2_FN32_CPU_OFF:
>  perfc_incr(vpsci_cpu_off);
>  PSCI_SET_RESULT(regs, do_psci_0_2_cpu_off());
>  return true;
>  
> -case PSCI_0_2_FN32(MIGRATE_INFO_TYPE):
> +case PSCI_0_2_FN32_MIGRATE_INFO_TYPE:
>  perfc_incr(vpsci_migrate_info_type);
>  PSCI_SET_RESULT(regs, do_psci_0_2_migrate_info_type());
>  return true;
>  
> -case PSCI_0_2_FN32(SYSTEM_OFF):
> +case PSCI_0_2_FN32_SYSTEM_OFF:
>  perfc_incr(vpsci_system_off);
>  do_psci_0_2_system_off();
>  PSCI_SET_RESULT(regs, PSCI_INTERNAL_FAILURE);
>  return true;
>  
> -case PSCI_0_2_FN32(SYSTEM_RESET):
> +case PSCI_0_2_FN32_SYSTEM_RESET:
>  perfc_incr(vpsci_system_reset);
>  do_psci_0_2_system_reset();
>  PSCI_SET_RESULT(regs, PSCI_INTERNAL_FAILURE);
>  return true;
>  
> -case PSCI_0_2_FN32(CPU_ON):
> -case PSCI_0_2_FN64(CPU_ON):
> +case PSCI_0_2_FN32_CPU_ON:
> +case PSCI_0_2_FN64_CPU_ON:
>  {
>  register_t vcpuid = PSCI_ARG(regs, 1);
>  register_t epoint = PSCI_ARG(regs, 2);
> @@ -282,8 +282,8 @@ bool do_vpsci_0_2_call(struct cpu_user_regs *regs, 
> uint32_t fid)
>  return true;
>  }
>  
> -case PSCI_0_2_FN32(CPU_SUSPEND):
> -case PSCI_0_2_FN64(CPU_SUSPEND):
> +case 

Re: [Xen-devel] [PATCH v5 11/18] xen/arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support

[Stefano Stabellini]

On Fri, 23 Feb 2018, Julien Grall wrote:
> Add the detection and runtime code for ARM_SMCCC_ARCH_WORKAROUND_1.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 

> ---
> Changes in v5:
> - Fold the fixup! patch which re-order registers into it.
> 
> Changes in v4:
> - Re-order saving/restoring registers in
>   __smccc_workaround_1_smc_start
> 
> Changes in v3:
> - Add the missing call to smc #0.
> 
> Changes in v2:
> - Patch added
> ---
>  xen/arch/arm/arm64/bpi.S| 13 +
>  xen/arch/arm/cpuerrata.c| 32 +++-
>  xen/include/asm-arm/smccc.h |  1 +
>  3 files changed, 45 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/arch/arm/arm64/bpi.S b/xen/arch/arm/arm64/bpi.S
> index 4b7f1dc21f..b59e307b0f 100644
> --- a/xen/arch/arm/arm64/bpi.S
> +++ b/xen/arch/arm/arm64/bpi.S
> @@ -16,6 +16,8 @@
>   * along with this program.  If not, see .
>   */
>  
> +#include 
> +
>  .macro ventry target
>  .rept 31
>  nop
> @@ -81,6 +83,17 @@ ENTRY(__psci_hyp_bp_inval_start)
>  add sp, sp, #(8 * 18)
>  ENTRY(__psci_hyp_bp_inval_end)
>  
> +ENTRY(__smccc_workaround_1_smc_start)
> +sub sp, sp, #(8 * 4)
> +stp x0, x1, [sp, #(8 * 2)]
> +stp x2, x3, [sp, #(8 * 0)]
> +mov w0, #ARM_SMCCC_ARCH_WORKAROUND_1_FID
> +smc #0
> +ldp x2, x3, [sp, #(8 * 0)]
> +ldp x0, x1, [sp, #(8 * 2)]
> +add sp, sp, #(8 * 4)
> +ENTRY(__smccc_workaround_1_smc_end)
> +
>  /*
>   * Local variables:
>   * mode: ASM
> diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
> index 8d5f8d372a..dec9074422 100644
> --- a/xen/arch/arm/cpuerrata.c
> +++ b/xen/arch/arm/cpuerrata.c
> @@ -147,6 +147,34 @@ install_bp_hardening_vec(const struct 
> arm_cpu_capabilities *entry,
>  return ret;
>  }
>  
> +extern char __smccc_workaround_1_smc_start[], __smccc_workaround_1_smc_end[];
> +
> +static bool
> +check_smccc_arch_workaround_1(const struct arm_cpu_capabilities *entry)
> +{
> +struct arm_smccc_res res;
> +
> +/*
> + * Enable callbacks are called on every CPU based on the
> + * capabilities. So double-check whether the CPU matches the
> + * entry.
> + */
> +if ( !entry->matches(entry) )
> +return false;
> +
> +if ( smccc_ver < SMCCC_VERSION(1, 1) )
> +return false;
> +
> +arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID,
> +  ARM_SMCCC_ARCH_WORKAROUND_1_FID, );
> +if ( res.a0 != ARM_SMCCC_SUCCESS )
> +return false;
> +
> +return install_bp_hardening_vec(entry,__smccc_workaround_1_smc_start,
> +__smccc_workaround_1_smc_end,
> +"call ARM_SMCCC_ARCH_WORKAROUND_1");
> +}
> +
>  extern char __psci_hyp_bp_inval_start[], __psci_hyp_bp_inval_end[];
>  
>  static int enable_psci_bp_hardening(void *data)
> @@ -154,12 +182,14 @@ static int enable_psci_bp_hardening(void *data)
>  bool ret = true;
>  static bool warned = false;
>  
> +if ( check_smccc_arch_workaround_1(data) )
> +return 0;
>  /*
>   * The mitigation is using PSCI version function to invalidate the
>   * branch predictor. This function is only available with PSCI 0.2
>   * and later.
>   */
> -if ( psci_ver >= PSCI_VERSION(0, 2) )
> +else if ( psci_ver >= PSCI_VERSION(0, 2) )
>  ret = install_bp_hardening_vec(data, __psci_hyp_bp_inval_start,
> __psci_hyp_bp_inval_end,
> "call PSCI get version");
> diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h
> index 154772b728..8342cc33fe 100644
> --- a/xen/include/asm-arm/smccc.h
> +++ b/xen/include/asm-arm/smccc.h
> @@ -261,6 +261,7 @@ struct arm_smccc_res {
>  /* SMCCC error codes */
>  #define ARM_SMCCC_ERR_UNKNOWN_FUNCTION  (-1)
>  #define ARM_SMCCC_NOT_SUPPORTED (-1)
> +#define ARM_SMCCC_SUCCESS   (0)
>  
>  /* SMCCC function identifier range which is reserved for existing APIs */
>  #define ARM_SMCCC_RESERVED_RANGE_START  0x0
> -- 
> 2.11.0
> 

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

[Xen-devel] [v1 0/1] Allow deferred page initialization for xen pv

[Pavel Tatashin]

From this discussion:
https://www.spinics.net/lists/linux-mm/msg145604.html

I investigated whether it is feasible to re-enable deferred page
initialization on xen's para-vitalized domains. After studying the
code, I found non-intrusive way to do just that.

All we need to do is to assume that page-table's pages are pinned early in
boot, which is always true, and add a new PV OP call to notify guests that
boot allocator is finished, so we can set all the necessary fields in
already initialized struct pages.

I have tested this on my laptop with 64-bit kernel, but I would appreciate
if someone could provide more xen testing.

Apply against: linux-next. Enable the following configs:

CONFIG_XEN_PV=y
CONFIG_DEFERRED_STRUCT_PAGE_INIT=y
The above two are needed to test deferred page initialization on PV Xen
domains. If fix is applied correctly, dmesg should output line(s) like this
during boot:
[0.266180] node 0 initialised, 717570 pages in 36ms

CONFIG_DEBUG_VM=y
This is needed to poison struct page's memory, otherwise it would be all
zero.

CONFIG_DEBUG_VM_PGFLAGS=y
Verifies that we do not access struct pages flags while memory is still
poisoned (struct pages are not initialized yet).

Pavel Tatashin (1):
  xen, mm: Allow deferred page initalization for xen pv domains

 arch/x86/include/asm/paravirt.h   |  9 +
 arch/x86/include/asm/paravirt_types.h |  3 +++
 arch/x86/kernel/paravirt.c|  1 +
 arch/x86/mm/init_32.c |  1 +
 arch/x86/mm/init_64.c |  1 +
 arch/x86/xen/mmu_pv.c | 38 ---
 mm/page_alloc.c   |  4 
 7 files changed, 41 insertions(+), 16 deletions(-)

-- 
2.16.2


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

[Xen-devel] [v1 1/1] xen, mm: Allow deferred page initialization for xen pv domains

[Pavel Tatashin]

Juergen Gross noticed that commit
f7f99100d8d ("mm: stop zeroing memory during allocation in vmemmap")
broke XEN PV domains when deferred struct page initialization is enabled.

This is because the xen's PagePinned() flag is getting erased from struct
pages when they are initialized later in boot.

Juergen fixed this problem by disabling deferred pages on xen pv domains.
However, it is desirable to have this feature available, as it reduces boot
time. This fix re-enables the feature for pv-dmains, and fixes the problem
the following way:

The fix is to delay setting PagePinned flag until struct pages for all
allocated memory are initialized (until free_all_bootmem()).

A new hypervisor op pv_init_ops.after_bootmem() is called to let xen know
that boot allocator is done, and hence struct pages for all the allocated
memory are now initialized. If deferred page initialization is enabled, the
rest of struct pages are going to be initialized later in boot once
page_alloc_init_late() is called.

xen_after_bootmem() is xen's implementation of pv_init_ops.after_bootmem(),
we walk page table and mark every page as pinned.

Signed-off-by: Pavel Tatashin 
---
 arch/x86/include/asm/paravirt.h   |  9 +
 arch/x86/include/asm/paravirt_types.h |  3 +++
 arch/x86/kernel/paravirt.c|  1 +
 arch/x86/mm/init_32.c |  1 +
 arch/x86/mm/init_64.c |  1 +
 arch/x86/xen/mmu_pv.c | 38 ---
 mm/page_alloc.c   |  4 
 7 files changed, 41 insertions(+), 16 deletions(-)

diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 9be2bf13825b..737e596a9836 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -820,6 +820,11 @@ static inline notrace unsigned long 
arch_local_irq_save(void)
 
 extern void default_banner(void);
 
+static inline void paravirt_after_bootmem(void)
+{
+   pv_init_ops.after_bootmem();
+}
+
 #else  /* __ASSEMBLY__ */
 
 #define _PVSITE(ptype, clobbers, ops, word, algn)  \
@@ -964,6 +969,10 @@ static inline void paravirt_arch_dup_mmap(struct mm_struct 
*oldmm,
 static inline void paravirt_arch_exit_mmap(struct mm_struct *mm)
 {
 }
+
+static inline void paravirt_after_bootmem(void)
+{
+}
 #endif /* __ASSEMBLY__ */
 #endif /* !CONFIG_PARAVIRT */
 #endif /* _ASM_X86_PARAVIRT_H */
diff --git a/arch/x86/include/asm/paravirt_types.h 
b/arch/x86/include/asm/paravirt_types.h
index 180bc0bff0fb..da78a3610168 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -86,6 +86,9 @@ struct pv_init_ops {
 */
unsigned (*patch)(u8 type, u16 clobber, void *insnbuf,
  unsigned long addr, unsigned len);
+
+   /* called right after we finish boot allocator */
+   void (*after_bootmem)(void);
 } __no_randomize_layout;
 
 
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index 99dc79e76bdc..7b5f931e2e3a 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -315,6 +315,7 @@ struct pv_info pv_info = {
 
 struct pv_init_ops pv_init_ops = {
.patch = native_patch,
+   .after_bootmem = paravirt_nop,
 };
 
 struct pv_time_ops pv_time_ops = {
diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c
index 79cb066f40c0..6096d0d9ecbc 100644
--- a/arch/x86/mm/init_32.c
+++ b/arch/x86/mm/init_32.c
@@ -763,6 +763,7 @@ void __init mem_init(void)
free_all_bootmem();
 
after_bootmem = 1;
+   paravirt_after_bootmem();
 
mem_init_print_info(NULL);
printk(KERN_INFO "virtual kernel memory layout:\n"
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 332f6e25977a..70b7b5093d07 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -1189,6 +1189,7 @@ void __init mem_init(void)
/* this will put all memory onto the freelists */
free_all_bootmem();
after_bootmem = 1;
+   paravirt_after_bootmem();
 
/*
 * Must be done after boot memory is put on freelist, because here we
diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c
index d20763472920..603589809334 100644
--- a/arch/x86/xen/mmu_pv.c
+++ b/arch/x86/xen/mmu_pv.c
@@ -116,6 +116,8 @@ DEFINE_PER_CPU(unsigned long, xen_current_cr3);  /* 
actual vcpu cr3 */
 
 static phys_addr_t xen_pt_base, xen_pt_size __initdata;
 
+static DEFINE_STATIC_KEY_FALSE(xen_struct_pages_ready);
+
 /*
  * Just beyond the highest usermode address.  STACK_TOP_MAX has a
  * redzone above it, so round it up to a PGD boundary.
@@ -155,11 +157,18 @@ void make_lowmem_page_readwrite(void *vaddr)
 }
 
 
+/*
+ * During early boot all pages are pinned, but we do not have struct pages,
+ * so return true until struct pages are ready.
+ */
 static bool xen_page_pinned(void *ptr)
 {
-   struct page *page = virt_to_page(ptr);
+   if 

[Xen-devel] [PATCH v2] fuzz/x86_emulate: fix bounds for input size

[Paul Semel]

The maximum size for the input size was set to INPUT_SIZE, which is actually
the size of the data array inside the fuzz_corpus structure and so was not
abling user (or AFL) to fill in the whole structure. Changing to
sizeof(struct fuzz_corpus) correct this problem.

Signed-off-by: Paul Semel 
---
 tools/fuzz/x86_instruction_emulator/fuzz-emul.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/tools/fuzz/x86_instruction_emulator/fuzz-emul.c 
b/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
index 964682aa1a..0ada613f52 100644
--- a/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
+++ b/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
@@ -33,6 +33,7 @@ struct fuzz_corpus
 unsigned char data[INPUT_SIZE];
 } input;
 #define DATA_OFFSET offsetof(struct fuzz_corpus, data)
+#define FUZZ_CORPUS_SIZE (sizeof(struct fuzz_corpus))
 
 /*
  * Internal state of the fuzzing harness.  Calculated initially from the input
@@ -828,7 +829,7 @@ int LLVMFuzzerTestOneInput(const uint8_t *data_p, size_t 
size)
 return 1;
 }
 
-if ( size > INPUT_SIZE )
+if ( size > FUZZ_CORPUS_SIZE )
 {
 printf("Input too large\n");
 return 1;
@@ -859,8 +860,6 @@ int LLVMFuzzerTestOneInput(const uint8_t *data_p, size_t 
size)
 
 unsigned int fuzz_minimal_input_size(void)
 {
-BUILD_BUG_ON(DATA_OFFSET > INPUT_SIZE);
-
 return DATA_OFFSET + 1;
 }
 
-- 
2.16.1


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 qemuuff8689611a1d954897d857b28f7ef404e11cfa2c
baseline version:
 qemuua6e0344fa0e09413324835ae122c4cadd7890231

Last test of basis   119797  2018-02-21 06:25:14 Z2 days
Testing same since   119894  2018-02-22 15:26:13 Z1 days1 attempts


People who touched revisions under test:
  Alex Bennée 
  David Gibson 
  Mark Cave-Ayland 
  Peter Maydell 
  Richard Henderson 

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

Re: [Xen-devel] [PATCH] fuzz/x86_emulate: fix bounds for input size

[Paul Semel]

On 02/23/2018 05:30 PM, Wei Liu wrote:

On Fri, Feb 23, 2018 at 12:57:26AM +0100, Paul Semel wrote:

The minimum size for the input size was set to DATA_OFFSET + 1 which was meaning
that we were requesting at least one character of the data array to be filled.
This is not needed for the fuzzer to get working correctly.


Sorry, I don't follow -- what do you expect the emulator to do if there
is no instruction to emulate?



Sure, I confused myself on this one, sorry about it !



The maximum size for the input size was set to INPUT_SIZE, which is actually
the size of the data array inside the fuzz_corpus structure and so was not
abling user (or AFL) to fill in the whole structure. Changing to
sizeof(struct fuzz_corpus) correct this problem.

Signed-off-by: Paul Semel 
---
  tools/fuzz/x86_instruction_emulator/fuzz-emul.c | 9 +
  1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/tools/fuzz/x86_instruction_emulator/fuzz-emul.c 
b/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
index 964682aa1a..f3ce2e7e27 100644
--- a/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
+++ b/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
@@ -33,6 +33,7 @@ struct fuzz_corpus
  unsigned char data[INPUT_SIZE];
  } input;
  #define DATA_OFFSET offsetof(struct fuzz_corpus, data)
+#define FUZZ_CORPUS_SIZE (sizeof(struct fuzz_corpus))
  
  /*

   * Internal state of the fuzzing harness.  Calculated initially from the input
@@ -822,13 +823,13 @@ int LLVMFuzzerTestOneInput(const uint8_t *data_p, size_t 
size)
  /* Reset all global state variables */
  memset(, 0, sizeof(input));
  
-if ( size <= DATA_OFFSET )

+if ( size < DATA_OFFSET )
  {
  printf("Input too small\n");
  return 1;
  }
  
-if ( size > INPUT_SIZE )

+if ( size > FUZZ_CORPUS_SIZE )
  {
  printf("Input too large\n");
  return 1;
@@ -859,9 +860,9 @@ int LLVMFuzzerTestOneInput(const uint8_t *data_p, size_t 
size)
  
  unsigned int fuzz_minimal_input_size(void)

  {
-BUILD_BUG_ON(DATA_OFFSET > INPUT_SIZE);
+BUILD_BUG_ON(DATA_OFFSET > FUZZ_CORPUS_SIZE);


Thinking more about it, this BUILD_BUG_ON is probably irrelevant
nowadays because we've opted to use struct fuzz_corpus instead of a
bunch of data structures (when the fuzzer was first implemented). I
don't think we will go back to the old model in the future so deleting
this BUILD_BUG_ON should be fine.



Yes, you're right 

I'm going to send my last version of this patch so that you can have it !


Wei.

  
-return DATA_OFFSET + 1;

+return DATA_OFFSET;
  }
  
  /*

--
2.16.1



--
Paul Semel

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

Re: [Xen-devel] [PATCH v2] x86/mm: Suppresses vm_events caused by page-walks

[Razvan Cojocaru]

On 02/24/2018 12:31 AM, Tamas K Lengyel wrote:
> On Fri, Feb 23, 2018 at 3:25 PM, Razvan Cojocaru
>  wrote:
>> On 02/24/2018 12:06 AM, Tamas K Lengyel wrote:
>>> On Mon, Jan 8, 2018 at 5:49 AM, Alexandru Isaila
>>>  wrote:
 This patch is adding a way to enable/disable nested pagefault
 events. It introduces the xc_monitor_nested_pagefault function
 and adds the nested_pagefault_disabled in the monitor structure.
 This is needed by the introspection so it will only get gla
 faults and not get spammed with other faults.
 In p2m_set_ad_bits the v->arch.sse_pg_dirty.eip and
 v->arch.sse_pg_dirty.gla are used to mark that this is the
 second time a fault occurs and the dirty bit is set.

 Signed-off-by: Alexandru Isaila 

 ---
 Changes since V1:
 - Rb V1
 - Add comment in domctl.h
 ---
  tools/libxc/include/xenctrl.h |  2 ++
  tools/libxc/xc_monitor.c  | 14 ++
  xen/arch/x86/mm/mem_access.c  | 27 +++
  xen/arch/x86/monitor.c| 13 +
  xen/include/asm-x86/domain.h  |  6 ++
  xen/include/asm-x86/monitor.h |  3 ++-
  xen/include/public/domctl.h   |  2 ++
  7 files changed, 66 insertions(+), 1 deletion(-)

 diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
 index 09e1363..112c974 100644
 --- a/tools/libxc/include/xenctrl.h
 +++ b/tools/libxc/include/xenctrl.h
 @@ -2056,6 +2056,8 @@ int xc_monitor_descriptor_access(xc_interface *xch, 
 uint32_t domain_id,
   bool enable);
  int xc_monitor_guest_request(xc_interface *xch, uint32_t domain_id,
   bool enable, bool sync, bool 
 allow_userspace);
 +int xc_monitor_nested_pagefault(xc_interface *xch, uint32_t domain_id,
 +bool disable);
  int xc_monitor_debug_exceptions(xc_interface *xch, uint32_t domain_id,
  bool enable, bool sync);
  int xc_monitor_cpuid(xc_interface *xch, uint32_t domain_id, bool enable);
 diff --git a/tools/libxc/xc_monitor.c b/tools/libxc/xc_monitor.c
 index 0233b87..e96c56d 100644
 --- a/tools/libxc/xc_monitor.c
 +++ b/tools/libxc/xc_monitor.c
 @@ -163,6 +163,20 @@ int xc_monitor_guest_request(xc_interface *xch, 
 uint32_t domain_id, bool enable,
  return do_domctl(xch, );
  }

 +int xc_monitor_nested_pagefault(xc_interface *xch, uint32_t domain_id,
 +bool disable)
 +{
 +DECLARE_DOMCTL;
 +
 +domctl.cmd = XEN_DOMCTL_monitor_op;
 +domctl.domain = domain_id;
 +domctl.u.monitor_op.op = disable ? XEN_DOMCTL_MONITOR_OP_ENABLE
 +: XEN_DOMCTL_MONITOR_OP_DISABLE;
 +domctl.u.monitor_op.event = XEN_DOMCTL_MONITOR_EVENT_NESTED_PAGEFAULT;
 +
 +return do_domctl(xch, );
 +}
 +
  int xc_monitor_emulate_each_rep(xc_interface *xch, uint32_t domain_id,
  bool enable)
  {
 diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c
 index c0cd017..07a334b 100644
 --- a/xen/arch/x86/mm/mem_access.c
 +++ b/xen/arch/x86/mm/mem_access.c
 @@ -137,6 +137,23 @@ bool p2m_mem_access_emulate_check(struct vcpu *v,
  return violation;
  }

 +static void p2m_set_ad_bits(struct vcpu *v, paddr_t ga)
 +{
 +struct hvm_hw_cpu ctxt;
 +uint32_t pfec = 0;
 +
 +hvm_funcs.save_cpu_ctxt(v, );
 +
 +if ( guest_cpu_user_regs()->eip == v->arch.pg_dirty.eip
 + && ga == v->arch.pg_dirty.gla )
 +pfec = PFEC_write_access;
 +
 +paging_ga_to_gfn_cr3(v, ctxt.cr3, ga, , NULL);
 +
 +v->arch.pg_dirty.eip = guest_cpu_user_regs()->eip;
 +v->arch.pg_dirty.gla = ga;
 +}
 +
  bool p2m_mem_access_check(paddr_t gpa, unsigned long gla,
struct npfec npfec,
vm_event_request_t **req_ptr)
 @@ -208,6 +225,16 @@ bool p2m_mem_access_check(paddr_t gpa, unsigned long 
 gla,
  }
  }

 +if ( vm_event_check_ring(d->vm_event_monitor) &&
 + d->arch.monitor.nested_pagefault_disabled &&
 + npfec.kind != npfec_kind_with_gla ) /* don't send a mem_event */
 +{
 +v->arch.vm_event->emulate_flags = 0;
 +p2m_set_ad_bits(v, gla);
 +
 +return true;
 +}
 +
  *req_ptr = NULL;
  req = xzalloc(vm_event_request_t);
  if ( req )
 diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c
 index f229e69..e35b619 100644
 --- a/xen/arch/x86/monitor.c
 +++ 

Re: [Xen-devel] [PATCH v2] x86/mm: Suppresses vm_events caused by page-walks

[Tamas K Lengyel]

On Fri, Feb 23, 2018 at 3:25 PM, Razvan Cojocaru
 wrote:
> On 02/24/2018 12:06 AM, Tamas K Lengyel wrote:
>> On Mon, Jan 8, 2018 at 5:49 AM, Alexandru Isaila
>>  wrote:
>>> This patch is adding a way to enable/disable nested pagefault
>>> events. It introduces the xc_monitor_nested_pagefault function
>>> and adds the nested_pagefault_disabled in the monitor structure.
>>> This is needed by the introspection so it will only get gla
>>> faults and not get spammed with other faults.
>>> In p2m_set_ad_bits the v->arch.sse_pg_dirty.eip and
>>> v->arch.sse_pg_dirty.gla are used to mark that this is the
>>> second time a fault occurs and the dirty bit is set.
>>>
>>> Signed-off-by: Alexandru Isaila 
>>>
>>> ---
>>> Changes since V1:
>>> - Rb V1
>>> - Add comment in domctl.h
>>> ---
>>>  tools/libxc/include/xenctrl.h |  2 ++
>>>  tools/libxc/xc_monitor.c  | 14 ++
>>>  xen/arch/x86/mm/mem_access.c  | 27 +++
>>>  xen/arch/x86/monitor.c| 13 +
>>>  xen/include/asm-x86/domain.h  |  6 ++
>>>  xen/include/asm-x86/monitor.h |  3 ++-
>>>  xen/include/public/domctl.h   |  2 ++
>>>  7 files changed, 66 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
>>> index 09e1363..112c974 100644
>>> --- a/tools/libxc/include/xenctrl.h
>>> +++ b/tools/libxc/include/xenctrl.h
>>> @@ -2056,6 +2056,8 @@ int xc_monitor_descriptor_access(xc_interface *xch, 
>>> uint32_t domain_id,
>>>   bool enable);
>>>  int xc_monitor_guest_request(xc_interface *xch, uint32_t domain_id,
>>>   bool enable, bool sync, bool allow_userspace);
>>> +int xc_monitor_nested_pagefault(xc_interface *xch, uint32_t domain_id,
>>> +bool disable);
>>>  int xc_monitor_debug_exceptions(xc_interface *xch, uint32_t domain_id,
>>>  bool enable, bool sync);
>>>  int xc_monitor_cpuid(xc_interface *xch, uint32_t domain_id, bool enable);
>>> diff --git a/tools/libxc/xc_monitor.c b/tools/libxc/xc_monitor.c
>>> index 0233b87..e96c56d 100644
>>> --- a/tools/libxc/xc_monitor.c
>>> +++ b/tools/libxc/xc_monitor.c
>>> @@ -163,6 +163,20 @@ int xc_monitor_guest_request(xc_interface *xch, 
>>> uint32_t domain_id, bool enable,
>>>  return do_domctl(xch, );
>>>  }
>>>
>>> +int xc_monitor_nested_pagefault(xc_interface *xch, uint32_t domain_id,
>>> +bool disable)
>>> +{
>>> +DECLARE_DOMCTL;
>>> +
>>> +domctl.cmd = XEN_DOMCTL_monitor_op;
>>> +domctl.domain = domain_id;
>>> +domctl.u.monitor_op.op = disable ? XEN_DOMCTL_MONITOR_OP_ENABLE
>>> +: XEN_DOMCTL_MONITOR_OP_DISABLE;
>>> +domctl.u.monitor_op.event = XEN_DOMCTL_MONITOR_EVENT_NESTED_PAGEFAULT;
>>> +
>>> +return do_domctl(xch, );
>>> +}
>>> +
>>>  int xc_monitor_emulate_each_rep(xc_interface *xch, uint32_t domain_id,
>>>  bool enable)
>>>  {
>>> diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c
>>> index c0cd017..07a334b 100644
>>> --- a/xen/arch/x86/mm/mem_access.c
>>> +++ b/xen/arch/x86/mm/mem_access.c
>>> @@ -137,6 +137,23 @@ bool p2m_mem_access_emulate_check(struct vcpu *v,
>>>  return violation;
>>>  }
>>>
>>> +static void p2m_set_ad_bits(struct vcpu *v, paddr_t ga)
>>> +{
>>> +struct hvm_hw_cpu ctxt;
>>> +uint32_t pfec = 0;
>>> +
>>> +hvm_funcs.save_cpu_ctxt(v, );
>>> +
>>> +if ( guest_cpu_user_regs()->eip == v->arch.pg_dirty.eip
>>> + && ga == v->arch.pg_dirty.gla )
>>> +pfec = PFEC_write_access;
>>> +
>>> +paging_ga_to_gfn_cr3(v, ctxt.cr3, ga, , NULL);
>>> +
>>> +v->arch.pg_dirty.eip = guest_cpu_user_regs()->eip;
>>> +v->arch.pg_dirty.gla = ga;
>>> +}
>>> +
>>>  bool p2m_mem_access_check(paddr_t gpa, unsigned long gla,
>>>struct npfec npfec,
>>>vm_event_request_t **req_ptr)
>>> @@ -208,6 +225,16 @@ bool p2m_mem_access_check(paddr_t gpa, unsigned long 
>>> gla,
>>>  }
>>>  }
>>>
>>> +if ( vm_event_check_ring(d->vm_event_monitor) &&
>>> + d->arch.monitor.nested_pagefault_disabled &&
>>> + npfec.kind != npfec_kind_with_gla ) /* don't send a mem_event */
>>> +{
>>> +v->arch.vm_event->emulate_flags = 0;
>>> +p2m_set_ad_bits(v, gla);
>>> +
>>> +return true;
>>> +}
>>> +
>>>  *req_ptr = NULL;
>>>  req = xzalloc(vm_event_request_t);
>>>  if ( req )
>>> diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c
>>> index f229e69..e35b619 100644
>>> --- a/xen/arch/x86/monitor.c
>>> +++ b/xen/arch/x86/monitor.c
>>> @@ -241,6 +241,19 @@ int arch_monitor_domctl_event(struct domain *d,
>>>  break;
>>>  }
>>>
>>> +case XEN_DOMCTL_MONITOR_EVENT_NESTED_PAGEFAULT:
>>> +  

Re: [Xen-devel] [PATCH v3] hvm/svm: Implement CPUID events

[Tamas K Lengyel]

On Fri, Feb 23, 2018 at 2:46 AM, Alexandru Isaila
 wrote:
> At this moment the CPUID events for the AMD architecture are not
> forwarded to the monitor layer.
>
> This patch adds the CPUID event to the common capabilities and then
> forwards the event to the monitor layer.
>
> ---
> Changes since V2:
> - Pass the inst_len to svm_vmexit_do_cpuid()
>
> Signed-off-by: Alexandru Isaila 

Acked-by: Tamas K Lengyel 

> ---
>  xen/arch/x86/hvm/svm/svm.c| 27 ++-
>  xen/include/asm-x86/monitor.h |  2 +-
>  2 files changed, 19 insertions(+), 10 deletions(-)
>
> diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
> index e36ad05..8ae2ae5 100644
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -1799,19 +1799,15 @@ static void svm_fpu_dirty_intercept(void)
>  vmcb_set_cr0(vmcb, vmcb_get_cr0(vmcb) & ~X86_CR0_TS);
>  }
>
> -static void svm_vmexit_do_cpuid(struct cpu_user_regs *regs)
> +static int svm_vmexit_do_cpuid(struct cpu_user_regs *regs, unsigned int 
> inst_len)
>  {
>  struct vcpu *curr = current;
> -unsigned int inst_len;
>  struct cpuid_leaf res;
>
> -if ( (inst_len = __get_instruction_length(curr, INSTR_CPUID)) == 0 )
> -return;
> -
>  if ( hvm_check_cpuid_faulting(curr) )
>  {
>  hvm_inject_hw_exception(TRAP_gp_fault, 0);
> -return;
> +return 1; /* Don't advance the guest IP! */
>  }
>
>  guest_cpuid(curr, regs->eax, regs->ecx, );
> @@ -1822,7 +1818,7 @@ static void svm_vmexit_do_cpuid(struct cpu_user_regs 
> *regs)
>  regs->rcx = res.c;
>  regs->rdx = res.d;
>
> -__update_guest_eip(regs, inst_len);
> +return hvm_monitor_cpuid(inst_len, regs->eax, regs->ecx);
>  }
>
>  static void svm_vmexit_do_cr_access(
> @@ -2768,9 +2764,22 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
>  }
>
>  case VMEXIT_CPUID:
> -svm_vmexit_do_cpuid(regs);
> -break;
> +{
> +unsigned int inst_len = __get_instruction_length(v, INSTR_CPUID);
> +int rc = 0;
>
> +if ( inst_len == 0 )
> +break;
> +
> +rc = svm_vmexit_do_cpuid(regs, inst_len);
> +
> +if ( rc < 0 )
> +goto unexpected_exit_type;
> +if ( !rc )
> +__update_guest_eip(regs, inst_len); /* Safe: CPUID */
> +
> +break;
> +}
>  case VMEXIT_HLT:
>  svm_vmexit_do_hlt(vmcb, regs);
>  break;
> diff --git a/xen/include/asm-x86/monitor.h b/xen/include/asm-x86/monitor.h
> index 7a9e1e8..99ed4b87 100644
> --- a/xen/include/asm-x86/monitor.h
> +++ b/xen/include/asm-x86/monitor.h
> @@ -81,12 +81,12 @@ static inline uint32_t 
> arch_monitor_get_capabilities(struct domain *d)
>  (1U << XEN_DOMCTL_MONITOR_EVENT_SOFTWARE_BREAKPOINT) |
>  (1U << XEN_DOMCTL_MONITOR_EVENT_MOV_TO_MSR) |
>  (1U << XEN_DOMCTL_MONITOR_EVENT_INTERRUPT) |
> +(1U << XEN_DOMCTL_MONITOR_EVENT_CPUID) |
>  (1U << XEN_DOMCTL_MONITOR_EVENT_WRITE_CTRLREG));
>
>  if ( cpu_has_vmx )
>  {
>  capabilities |= ((1U << XEN_DOMCTL_MONITOR_EVENT_DEBUG_EXCEPTION) |
> - (1U << XEN_DOMCTL_MONITOR_EVENT_CPUID) |
>   (1U << 
> XEN_DOMCTL_MONITOR_EVENT_EMUL_UNIMPLEMENTED));
>
>  /* Since we know this is on VMX, we can just call the hvm func */
> --
> 2.7.4

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

Re: [Xen-devel] [PATCH v2] x86/mm: Suppresses vm_events caused by page-walks

[Razvan Cojocaru]

On 02/24/2018 12:06 AM, Tamas K Lengyel wrote:
> On Mon, Jan 8, 2018 at 5:49 AM, Alexandru Isaila
>  wrote:
>> This patch is adding a way to enable/disable nested pagefault
>> events. It introduces the xc_monitor_nested_pagefault function
>> and adds the nested_pagefault_disabled in the monitor structure.
>> This is needed by the introspection so it will only get gla
>> faults and not get spammed with other faults.
>> In p2m_set_ad_bits the v->arch.sse_pg_dirty.eip and
>> v->arch.sse_pg_dirty.gla are used to mark that this is the
>> second time a fault occurs and the dirty bit is set.
>>
>> Signed-off-by: Alexandru Isaila 
>>
>> ---
>> Changes since V1:
>> - Rb V1
>> - Add comment in domctl.h
>> ---
>>  tools/libxc/include/xenctrl.h |  2 ++
>>  tools/libxc/xc_monitor.c  | 14 ++
>>  xen/arch/x86/mm/mem_access.c  | 27 +++
>>  xen/arch/x86/monitor.c| 13 +
>>  xen/include/asm-x86/domain.h  |  6 ++
>>  xen/include/asm-x86/monitor.h |  3 ++-
>>  xen/include/public/domctl.h   |  2 ++
>>  7 files changed, 66 insertions(+), 1 deletion(-)
>>
>> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
>> index 09e1363..112c974 100644
>> --- a/tools/libxc/include/xenctrl.h
>> +++ b/tools/libxc/include/xenctrl.h
>> @@ -2056,6 +2056,8 @@ int xc_monitor_descriptor_access(xc_interface *xch, 
>> uint32_t domain_id,
>>   bool enable);
>>  int xc_monitor_guest_request(xc_interface *xch, uint32_t domain_id,
>>   bool enable, bool sync, bool allow_userspace);
>> +int xc_monitor_nested_pagefault(xc_interface *xch, uint32_t domain_id,
>> +bool disable);
>>  int xc_monitor_debug_exceptions(xc_interface *xch, uint32_t domain_id,
>>  bool enable, bool sync);
>>  int xc_monitor_cpuid(xc_interface *xch, uint32_t domain_id, bool enable);
>> diff --git a/tools/libxc/xc_monitor.c b/tools/libxc/xc_monitor.c
>> index 0233b87..e96c56d 100644
>> --- a/tools/libxc/xc_monitor.c
>> +++ b/tools/libxc/xc_monitor.c
>> @@ -163,6 +163,20 @@ int xc_monitor_guest_request(xc_interface *xch, 
>> uint32_t domain_id, bool enable,
>>  return do_domctl(xch, );
>>  }
>>
>> +int xc_monitor_nested_pagefault(xc_interface *xch, uint32_t domain_id,
>> +bool disable)
>> +{
>> +DECLARE_DOMCTL;
>> +
>> +domctl.cmd = XEN_DOMCTL_monitor_op;
>> +domctl.domain = domain_id;
>> +domctl.u.monitor_op.op = disable ? XEN_DOMCTL_MONITOR_OP_ENABLE
>> +: XEN_DOMCTL_MONITOR_OP_DISABLE;
>> +domctl.u.monitor_op.event = XEN_DOMCTL_MONITOR_EVENT_NESTED_PAGEFAULT;
>> +
>> +return do_domctl(xch, );
>> +}
>> +
>>  int xc_monitor_emulate_each_rep(xc_interface *xch, uint32_t domain_id,
>>  bool enable)
>>  {
>> diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c
>> index c0cd017..07a334b 100644
>> --- a/xen/arch/x86/mm/mem_access.c
>> +++ b/xen/arch/x86/mm/mem_access.c
>> @@ -137,6 +137,23 @@ bool p2m_mem_access_emulate_check(struct vcpu *v,
>>  return violation;
>>  }
>>
>> +static void p2m_set_ad_bits(struct vcpu *v, paddr_t ga)
>> +{
>> +struct hvm_hw_cpu ctxt;
>> +uint32_t pfec = 0;
>> +
>> +hvm_funcs.save_cpu_ctxt(v, );
>> +
>> +if ( guest_cpu_user_regs()->eip == v->arch.pg_dirty.eip
>> + && ga == v->arch.pg_dirty.gla )
>> +pfec = PFEC_write_access;
>> +
>> +paging_ga_to_gfn_cr3(v, ctxt.cr3, ga, , NULL);
>> +
>> +v->arch.pg_dirty.eip = guest_cpu_user_regs()->eip;
>> +v->arch.pg_dirty.gla = ga;
>> +}
>> +
>>  bool p2m_mem_access_check(paddr_t gpa, unsigned long gla,
>>struct npfec npfec,
>>vm_event_request_t **req_ptr)
>> @@ -208,6 +225,16 @@ bool p2m_mem_access_check(paddr_t gpa, unsigned long 
>> gla,
>>  }
>>  }
>>
>> +if ( vm_event_check_ring(d->vm_event_monitor) &&
>> + d->arch.monitor.nested_pagefault_disabled &&
>> + npfec.kind != npfec_kind_with_gla ) /* don't send a mem_event */
>> +{
>> +v->arch.vm_event->emulate_flags = 0;
>> +p2m_set_ad_bits(v, gla);
>> +
>> +return true;
>> +}
>> +
>>  *req_ptr = NULL;
>>  req = xzalloc(vm_event_request_t);
>>  if ( req )
>> diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c
>> index f229e69..e35b619 100644
>> --- a/xen/arch/x86/monitor.c
>> +++ b/xen/arch/x86/monitor.c
>> @@ -241,6 +241,19 @@ int arch_monitor_domctl_event(struct domain *d,
>>  break;
>>  }
>>
>> +case XEN_DOMCTL_MONITOR_EVENT_NESTED_PAGEFAULT:
>> +{
>> +bool old_status = ad->monitor.nested_pagefault_disabled;
>> +
>> +if ( unlikely(old_status == requested_status) )
>> +return -EEXIST;
>> +
>> +domain_pause(d);
>> + 

Re: [Xen-devel] [PATCH v2] x86/mm: Suppresses vm_events caused by page-walks

[Tamas K Lengyel]

On Mon, Jan 8, 2018 at 5:49 AM, Alexandru Isaila
 wrote:
> This patch is adding a way to enable/disable nested pagefault
> events. It introduces the xc_monitor_nested_pagefault function
> and adds the nested_pagefault_disabled in the monitor structure.
> This is needed by the introspection so it will only get gla
> faults and not get spammed with other faults.
> In p2m_set_ad_bits the v->arch.sse_pg_dirty.eip and
> v->arch.sse_pg_dirty.gla are used to mark that this is the
> second time a fault occurs and the dirty bit is set.
>
> Signed-off-by: Alexandru Isaila 
>
> ---
> Changes since V1:
> - Rb V1
> - Add comment in domctl.h
> ---
>  tools/libxc/include/xenctrl.h |  2 ++
>  tools/libxc/xc_monitor.c  | 14 ++
>  xen/arch/x86/mm/mem_access.c  | 27 +++
>  xen/arch/x86/monitor.c| 13 +
>  xen/include/asm-x86/domain.h  |  6 ++
>  xen/include/asm-x86/monitor.h |  3 ++-
>  xen/include/public/domctl.h   |  2 ++
>  7 files changed, 66 insertions(+), 1 deletion(-)
>
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index 09e1363..112c974 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -2056,6 +2056,8 @@ int xc_monitor_descriptor_access(xc_interface *xch, 
> uint32_t domain_id,
>   bool enable);
>  int xc_monitor_guest_request(xc_interface *xch, uint32_t domain_id,
>   bool enable, bool sync, bool allow_userspace);
> +int xc_monitor_nested_pagefault(xc_interface *xch, uint32_t domain_id,
> +bool disable);
>  int xc_monitor_debug_exceptions(xc_interface *xch, uint32_t domain_id,
>  bool enable, bool sync);
>  int xc_monitor_cpuid(xc_interface *xch, uint32_t domain_id, bool enable);
> diff --git a/tools/libxc/xc_monitor.c b/tools/libxc/xc_monitor.c
> index 0233b87..e96c56d 100644
> --- a/tools/libxc/xc_monitor.c
> +++ b/tools/libxc/xc_monitor.c
> @@ -163,6 +163,20 @@ int xc_monitor_guest_request(xc_interface *xch, uint32_t 
> domain_id, bool enable,
>  return do_domctl(xch, );
>  }
>
> +int xc_monitor_nested_pagefault(xc_interface *xch, uint32_t domain_id,
> +bool disable)
> +{
> +DECLARE_DOMCTL;
> +
> +domctl.cmd = XEN_DOMCTL_monitor_op;
> +domctl.domain = domain_id;
> +domctl.u.monitor_op.op = disable ? XEN_DOMCTL_MONITOR_OP_ENABLE
> +: XEN_DOMCTL_MONITOR_OP_DISABLE;
> +domctl.u.monitor_op.event = XEN_DOMCTL_MONITOR_EVENT_NESTED_PAGEFAULT;
> +
> +return do_domctl(xch, );
> +}
> +
>  int xc_monitor_emulate_each_rep(xc_interface *xch, uint32_t domain_id,
>  bool enable)
>  {
> diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c
> index c0cd017..07a334b 100644
> --- a/xen/arch/x86/mm/mem_access.c
> +++ b/xen/arch/x86/mm/mem_access.c
> @@ -137,6 +137,23 @@ bool p2m_mem_access_emulate_check(struct vcpu *v,
>  return violation;
>  }
>
> +static void p2m_set_ad_bits(struct vcpu *v, paddr_t ga)
> +{
> +struct hvm_hw_cpu ctxt;
> +uint32_t pfec = 0;
> +
> +hvm_funcs.save_cpu_ctxt(v, );
> +
> +if ( guest_cpu_user_regs()->eip == v->arch.pg_dirty.eip
> + && ga == v->arch.pg_dirty.gla )
> +pfec = PFEC_write_access;
> +
> +paging_ga_to_gfn_cr3(v, ctxt.cr3, ga, , NULL);
> +
> +v->arch.pg_dirty.eip = guest_cpu_user_regs()->eip;
> +v->arch.pg_dirty.gla = ga;
> +}
> +
>  bool p2m_mem_access_check(paddr_t gpa, unsigned long gla,
>struct npfec npfec,
>vm_event_request_t **req_ptr)
> @@ -208,6 +225,16 @@ bool p2m_mem_access_check(paddr_t gpa, unsigned long gla,
>  }
>  }
>
> +if ( vm_event_check_ring(d->vm_event_monitor) &&
> + d->arch.monitor.nested_pagefault_disabled &&
> + npfec.kind != npfec_kind_with_gla ) /* don't send a mem_event */
> +{
> +v->arch.vm_event->emulate_flags = 0;
> +p2m_set_ad_bits(v, gla);
> +
> +return true;
> +}
> +
>  *req_ptr = NULL;
>  req = xzalloc(vm_event_request_t);
>  if ( req )
> diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c
> index f229e69..e35b619 100644
> --- a/xen/arch/x86/monitor.c
> +++ b/xen/arch/x86/monitor.c
> @@ -241,6 +241,19 @@ int arch_monitor_domctl_event(struct domain *d,
>  break;
>  }
>
> +case XEN_DOMCTL_MONITOR_EVENT_NESTED_PAGEFAULT:
> +{
> +bool old_status = ad->monitor.nested_pagefault_disabled;
> +
> +if ( unlikely(old_status == requested_status) )
> +return -EEXIST;
> +
> +domain_pause(d);
> +ad->monitor.nested_pagefault_disabled = requested_status;
> +domain_unpause(d);
> +break;
> +}
> +
>  case XEN_DOMCTL_MONITOR_EVENT_DESC_ACCESS:
> 

[Xen-devel] [linux-4.9 test] 119891: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 12 guest-start  fail REGR. vs. 119562

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

version targeted for testing:
 linux80c1c8322c331586a86e58d3f95026a1265ab396
baseline version:
 linux3e598a7089eef1fe04d5b87cc154295302960e62

Last test of basis   119562  2018-02-18 09:51:11 Z5 days
Testing same since   119891  2018-02-22 15:01:38 Z1 days1 attempts


People who touched revisions under test:
  Al Viro 
  alex chen 
  Alex Deucher 
  Alexander Potapenko 
  Andrew Morton 
  Andy Gross 

Re: [Xen-devel] libxl - avoid calling block script

[Marek Marczykowski-Górecki]

On Fri, Feb 23, 2018 at 06:28:56PM +, Wei Liu wrote:
> On Fri, Feb 09, 2018 at 12:35:13PM +0100, Marek Marczykowski-Górecki wrote:
> > On Fri, Feb 09, 2018 at 11:03:55AM +, Roger Pau Monné wrote:
> > > Really adding Ian and Wei.
> > > 
> > > On Fri, Feb 09, 2018 at 10:55:24AM +, Roger Pau Monné wrote:
> > > > So the problem is creation time for domains that have quite a lot of
> > > > disks attached. Adding Ian and Wei who know more about the async
> > > > dispatch system, but I think (at least from a technical PoV) it
> > > > should be possible to parallelize device attachment and thus hotplug
> > > > script execution. Devices are independent from each other.
> > 
> > In theory yes, but in practice block script (at least on Linux) takes a
> > lock and serialize execution...
> > 
> > > > Also the Linux hotplug scripts in general seem extremely convoluted,
> > > > I'm not sure whether we could gain some speed there just by
> > > > simplification.
> > 
> > Well, we're comparing a bunch of fork+exec(), including starting bash
> > (default /bin/sh on most systems), with just a single stat() call...
> > Handling scripts in libxl itself also takes some time (in my case libxl
> > live in libvirt, which may or may not have an impact). For a domU with
> > 4 disks, getting rid of hotplug scripts saved about 2s of startup time.
> > 
> 
> Sorry for the late reply.
> 
> If you really don't want block scripts, can you not specify a script
> that only does "exit 0"? That seems to be easier than modifying libxl
> and it is also useable in older versions of Xen.

But this is only one part of the picture. Something needs to set
physical-device xenstore entry. Libxl did that before, but it was
removed (see original message in this thread). I may write alternative
simplified block script for such case and measure performance of it, but
this feels overly complex, especially when libxl already have everything
it needs to quickly fill that xenstore entry.

Anyway, I'll go that way for now.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


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

Re: [Xen-devel] [PATCH] libxl: allow libxl_domain_suspend to simply suspend a domain, without saving it

[Marek Marczykowski-Górecki]

On Fri, Feb 23, 2018 at 06:47:57PM +, Wei Liu wrote:
> On Fri, Feb 09, 2018 at 12:14:03AM +0100, Marek Marczykowski-Górecki wrote:
> > When fd=-1, no savefile will be written, but the domain will still be
> > suspended (but not destroyed). The main reason for this functionality is
> > to suspend the host while some domains are running, potentially holding
> > PCI devices. This will give a chance to a driver in such a domain to
> > properly suspend device.
> > 
> > It would be better to have separate function for this, but in fact it
> > should be named libxl_domain_suspend, then the current one renamed to
> > libxl_domain_save. Since that would break API compatibility, keep it in
> > the same function.
> > 
> > Signed-off-by: Marek Marczykowski-Górecki 
> > Signed-off-by: Marcus of Wetware Labs 
> 
> The basic idea seems sensible.
> 
> Please add a comment to libxl.h to specify the new semantics.

Hmm, while I'm looking at it, maybe better idea would be to use flags
for that? I'd call it LIBXL_SUSPEND_SUSPEND, but it looks stupid, any
better idea?

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


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

[Xen-devel] [PATCH v2] libxl: do not fail device removal if backend domain is gone

[Marek Marczykowski-Górecki]

Backend domain may be independently destroyed - there is no
synchronization of libxl structures (including /libxl tree) elsewhere.
Backend might also remove the device info from its backend xenstore
subtree on its own.

We have various cases (not comprehensive list):

 - both frontend and backend operational: after setting
   be/state=XenbusStateClosing backend wait for frontend confirmation
   and respond with be/state=XenbusStateClosed; then libxl in dom0
   remove frontend entries and libxl in backend domain (which may be the
   same) remove backend entries
 - unresponsive backend/frontend: after a timeout, force=1 is used to remove
   frontend entries, instead of just setting
   be/state=XenbusStateClosing; then wait for be/state=XenbusStateClosed.
   If that timeout too, remove both frontend and backend entries
 - backend gone, with this patch: no place for setting/waiting on
   be/state - go directly to removing frontend entries, without waiting
   for be/state=XenbusStateClosed (this is the difference vs force=1)

Without this patch the end result is similar, both frontend and backend
entries are removed, but in case of backend gone:
 - libxl waits for be/state=XenbusStateClosed (and obviously timeout)
 - return value from the function signal an error, which for example
   confuse libvirt - it thinks the device remove failed, so is still
   there

If such situation is detected, do not fail the removal, but finish the
cleanup of the frontend side and return 0.

This is just workaround, the real fix should watch when the device
backend is removed (including backend domain destruction) and remove
frontend at that time. And report such event to higher layer code, so
for example libvirt could synchronize its state.

Signed-off-by: Marek Marczykowski-Górecki 

---
Changes in v2:
 - change WARN to INFO
 - detailed explanation in commit message
---
 tools/libxl/libxl_device.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index 1b796bd392..c60cafe774 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -997,6 +997,13 @@ void libxl__initiate_device_generic_remove(libxl__egc *egc,
 goto out;
 }
 
+/* if state_path is empty, assume backend is gone (backend domain
+ * shutdown?), cleanup frontend only; rc=0 */
+if (!state) {
+LOG(INFO, "backend %s already removed, cleanup frontend only", 
be_path);
+goto out;
+}
+
 rc = libxl__xs_write_checked(gc, t, online_path, "0");
 if (rc)
 goto out;
-- 
2.13.6


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

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

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

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

Information leak via side effects of speculative execution

UPDATES IN VERSION 12
=

Corrections to ARM SP2 information:

* ARM 32-bit requires new firmware on some CPUs.
* Provide link to the ARM firmware page, accordingly.
* ARM 32-bit mitigations are complete for Cortex-A CPUs.
  We do not have information for other ARM CPUs at this time.

ISSUE DESCRIPTION
=

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

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

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

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

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

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

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

Additional Xen-specific background:

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

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

IMPACT
==

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

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

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

NOTE ON TIMING
==

This vulnerability was originally scheduled to be made public on 9
January.  It was accelerated at the request of the discloser due to
one of the issues being made public.

VULNERABLE SYSTEMS
==

Systems running 

[Xen-devel] [examine test] 119971: tolerable ALL FAIL

[osstest service owner]

flight 119971 examine real [real]
http://logs.test-lab.xenproject.org/osstest/logs/119971/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 examine-laxton1   2 hosts-allocate  broken like 118286
 examine-cubietruck-metzinger  2 hosts-allocate  broken like 118286
 examine-chardonnay0   2 hosts-allocate  broken like 118286
 examine-arndale-westfield 2 hosts-allocate  broken like 118286
 examine-baroque1  2 hosts-allocate  broken like 118286
 examine-rimava0   2 hosts-allocate  broken like 118286
 examine-elbling0  2 hosts-allocate  broken like 118286
 examine-cubietruck-picasso2 hosts-allocate  broken like 118286
 examine-cubietruck-braque 2 hosts-allocate  broken like 118286
 examine-arndale-bluewater 2 hosts-allocate  broken like 118286
 examine-baroque0  2 hosts-allocate  broken like 118286
 examine-godello0  2 hosts-allocate  broken like 118286
 examine-arndale-lakeside  2 hosts-allocate  broken like 118286
 examine-italia1   2 hosts-allocate  broken like 118286
 examine-fiano12 hosts-allocate  broken like 118286
 examine-pinot12 hosts-allocate  broken like 118286
 examine-pinot02 hosts-allocate  broken like 118286
 examine-huxelrebe12 hosts-allocate  broken like 118286
 examine-fiano02 hosts-allocate  broken like 118286
 examine-chardonnay1   2 hosts-allocate  broken like 118286
 examine-italia0   2 hosts-allocate  broken like 118286
 examine-cubietruck-gleizes2 hosts-allocate  broken like 118286
 examine-arndale-metrocentre   2 hosts-allocate  broken like 118286
 examine-huxelrebe02 hosts-allocate  broken like 118286
 examine-godello1  2 hosts-allocate  broken like 118286
 examine-elbling1  2 hosts-allocate  broken like 118286

baseline version:
 flight   118286

jobs:
 examine-baroque0 fail
 examine-baroque1 fail
 examine-arndale-bluewaterfail
 examine-cubietruck-braquefail
 examine-chardonnay0  fail
 examine-chardonnay1  fail
 examine-elbling0 fail
 examine-elbling1 fail
 examine-fiano0   fail
 examine-fiano1   fail
 examine-cubietruck-gleizes   fail
 examine-godello0 fail
 examine-godello1 fail
 examine-huxelrebe0   fail
 examine-huxelrebe1   fail
 examine-italia0  fail
 examine-italia1  fail
 examine-arndale-lakeside fail
 examine-laxton1  fail
 examine-arndale-metrocentre  fail
 examine-cubietruck-metzinger fail
 examine-cubietruck-picasso   fail
 examine-pinot0   fail
 examine-pinot1   fail
 examine-rimava0  fail
 examine-arndale-westfieldfail



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


Push not applicable.


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

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

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

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

Information leak via side effects of speculative execution

UPDATES IN VERSION 11
=

Information provided about migitation for Spectre variant 2.

Mention whether CPU hardware virtualisation extensions are required
in the SP3 mitigations summary table.

An additional patch "x86: fix GET_STACK_END" is required to fix a
possible build failure in the PTI patches.  README.pti updated
accordingly.

ISSUE DESCRIPTION
=

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

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

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

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

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

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

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

Additional Xen-specific background:

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

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

IMPACT
==

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

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

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

NOTE ON TIMING
==

This vulnerability was originally scheduled to be made public on 9
January.  It was accelerated at the request of the discloser due to
one of the issues being made public.

Re: [Xen-devel] [PATCH v5 11/18] xen/arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support

[Volodymyr Babchuk]

Julien,

Looks good now

On 23.02.18 20:57, Julien Grall wrote:

Add the detection and runtime code for ARM_SMCCC_ARCH_WORKAROUND_1.

Signed-off-by: Julien Grall 

Reviewed-by: Volodymyr Babchuk 


---
 Changes in v5:
 - Fold the fixup! patch which re-order registers into it.

 Changes in v4:
 - Re-order saving/restoring registers in
   __smccc_workaround_1_smc_start

 Changes in v3:
 - Add the missing call to smc #0.

 Changes in v2:
 - Patch added
---
  xen/arch/arm/arm64/bpi.S| 13 +
  xen/arch/arm/cpuerrata.c| 32 +++-
  xen/include/asm-arm/smccc.h |  1 +
  3 files changed, 45 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/arm64/bpi.S b/xen/arch/arm/arm64/bpi.S
index 4b7f1dc21f..b59e307b0f 100644
--- a/xen/arch/arm/arm64/bpi.S
+++ b/xen/arch/arm/arm64/bpi.S
@@ -16,6 +16,8 @@
   * along with this program.  If not, see .
   */
  
+#include 

+
  .macro ventry target
  .rept 31
  nop
@@ -81,6 +83,17 @@ ENTRY(__psci_hyp_bp_inval_start)
  add sp, sp, #(8 * 18)
  ENTRY(__psci_hyp_bp_inval_end)
  
+ENTRY(__smccc_workaround_1_smc_start)

+sub sp, sp, #(8 * 4)
+stp x0, x1, [sp, #(8 * 2)]
+stp x2, x3, [sp, #(8 * 0)]
+mov w0, #ARM_SMCCC_ARCH_WORKAROUND_1_FID
+smc #0
+ldp x2, x3, [sp, #(8 * 0)]
+ldp x0, x1, [sp, #(8 * 2)]
+add sp, sp, #(8 * 4)
+ENTRY(__smccc_workaround_1_smc_end)
+
  /*
   * Local variables:
   * mode: ASM
diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index 8d5f8d372a..dec9074422 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -147,6 +147,34 @@ install_bp_hardening_vec(const struct arm_cpu_capabilities 
*entry,
  return ret;
  }
  
+extern char __smccc_workaround_1_smc_start[], __smccc_workaround_1_smc_end[];

+
+static bool
+check_smccc_arch_workaround_1(const struct arm_cpu_capabilities *entry)
+{
+struct arm_smccc_res res;
+
+/*
+ * Enable callbacks are called on every CPU based on the
+ * capabilities. So double-check whether the CPU matches the
+ * entry.
+ */
+if ( !entry->matches(entry) )
+return false;
+
+if ( smccc_ver < SMCCC_VERSION(1, 1) )
+return false;
+
+arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID,
+  ARM_SMCCC_ARCH_WORKAROUND_1_FID, );
+if ( res.a0 != ARM_SMCCC_SUCCESS )
+return false;
+
+return install_bp_hardening_vec(entry,__smccc_workaround_1_smc_start,
+__smccc_workaround_1_smc_end,
+"call ARM_SMCCC_ARCH_WORKAROUND_1");
+}
+
  extern char __psci_hyp_bp_inval_start[], __psci_hyp_bp_inval_end[];
  
  static int enable_psci_bp_hardening(void *data)

@@ -154,12 +182,14 @@ static int enable_psci_bp_hardening(void *data)
  bool ret = true;
  static bool warned = false;
  
+if ( check_smccc_arch_workaround_1(data) )

+return 0;
  /*
   * The mitigation is using PSCI version function to invalidate the
   * branch predictor. This function is only available with PSCI 0.2
   * and later.
   */
-if ( psci_ver >= PSCI_VERSION(0, 2) )
+else if ( psci_ver >= PSCI_VERSION(0, 2) )
  ret = install_bp_hardening_vec(data, __psci_hyp_bp_inval_start,
 __psci_hyp_bp_inval_end,
 "call PSCI get version");
diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h
index 154772b728..8342cc33fe 100644
--- a/xen/include/asm-arm/smccc.h
+++ b/xen/include/asm-arm/smccc.h
@@ -261,6 +261,7 @@ struct arm_smccc_res {
  /* SMCCC error codes */
  #define ARM_SMCCC_ERR_UNKNOWN_FUNCTION  (-1)
  #define ARM_SMCCC_NOT_SUPPORTED (-1)
+#define ARM_SMCCC_SUCCESS   (0)
  
  /* SMCCC function identifier range which is reserved for existing APIs */

  #define ARM_SMCCC_RESERVED_RANGE_START  0x0



--
Volodymyr Babchuk

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

Re: [Xen-devel] [PATCH RFC 3/3] xtf: add minimal HPET functionality test

[Wei Liu]

On Fri, Feb 23, 2018 at 01:27:43PM +, Roger Pau Monne wrote:
> Add a basic HPET functionality test, note that this test requires the
> HPET to support level triggered interrupts.
> 
> Further improvements should add support for interrupt delivery, and
> testing all the available timers.
> 
> Signed-off-by: Roger Pau Monné 
> ---
> Cc: Andrew Cooper 
> ---
>  arch/x86/include/arch/lib.h |  14 
>  docs/all-tests.dox  |   2 +
>  tests/hpet/Makefile |   9 +++
>  tests/hpet/main.c   | 187 
> 
>  4 files changed, 212 insertions(+)
>  create mode 100644 tests/hpet/Makefile
>  create mode 100644 tests/hpet/main.c
> 
> diff --git a/arch/x86/include/arch/lib.h b/arch/x86/include/arch/lib.h
> index 6714bdc..3400890 100644
> --- a/arch/x86/include/arch/lib.h
> +++ b/arch/x86/include/arch/lib.h
> @@ -392,6 +392,20 @@ static inline void write_xcr0(uint64_t xcr0)
>  xsetbv(0, xcr0);
>  }
>  
> +static inline uint64_t rdtsc(void)
> +{
> +uint32_t low, high;
> +
> +asm volatile ("rdtsc" : "=a" (low), "=d" (high));
> +

You probably need to add lfence or mfence. See rdtsc_ordered in Xen.

> +return ((uint64_t)high << 32) | low;
> +}
> +
[...]
> +static void set_freq(void)
> +{
> +uint32_t eax, ebx, ecx, edx, base;
> +bool found = false;
> +
> +/* Get tsc frequency from cpuid. */
> +for ( base = XEN_CPUID_FIRST_LEAF;
> +  base < XEN_CPUID_FIRST_LEAF + 0x1; base += 0x100 )
> +{
> +cpuid(base, , , , );
> +
> +if ( (ebx == XEN_CPUID_SIGNATURE_EBX) &&
> + (ecx == XEN_CPUID_SIGNATURE_ECX) &&
> + (edx == XEN_CPUID_SIGNATURE_EDX) &&
> + ((eax - base) >= 2) )
> +{
> +found = true;
> +break;
> +}
> +}
> +
> +if ( !found )
> +panic("Unable to locate Xen CPUID leaves\n");
> +

Finding Xen leaves should live in its own function and move to common
code if possible.

> +cpuid_count(base + 3, 0, , , , );
> +printk("TSC frequency %ukHz\n", freq);
> +}
> +
> +/* Busy-wait implementation based on tsc value. */
> +static void wait(unsigned int ms)
> +{
> +uint64_t end = rdtsc() + (uint64_t)ms * (uint64_t)freq;
> +
> +while ( rdtsc() < end )
> +pause();
> +}

Rename to mdelay and move to a helper file?

> +
> +void test_main(void)
> +{
[...]
> +HPET_REG(HPET_Tn_CFG(nr)) &= ~HPET_TN_LEVEL;
> +HPET_REG(HPET_STATUS) = 1 << nr;
> +wait(200);
> +if ( ((HPET_REG(HPET_STATUS) >> nr) & 1) )
> +return xtf_failure("Fail: Status bit set for edge interrupt in 
> periodic mode\n");
> +

Is it possible to use shorter time in the test? This test as-is will run
for 1 or 2 seconds which is a bit long as micro-kernel testing.

Wei.

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

Re: [Xen-devel] [RFC PATCH v2 2/9] hyper_dmabuf: architecture specification and reference guide

[Dongwon Kim]

Thanks for your comment, Roger
I will try to polish this doc and resubmit.
(I put some comments below as well.)

On Fri, Feb 23, 2018 at 04:15:00PM +, Roger Pau Monné wrote:
> On Tue, Feb 13, 2018 at 05:50:01PM -0800, Dongwon Kim wrote:
> > Reference document for hyper_DMABUF driver
> > 
> > Documentation/hyper-dmabuf-sharing.txt
> 
> This should likely be patch 1 in order for reviewers to have the
> appropriate context.
> 
> > 
> > Signed-off-by: Dongwon Kim 
> > ---
> >  Documentation/hyper-dmabuf-sharing.txt | 734 
> > +
> >  1 file changed, 734 insertions(+)
> >  create mode 100644 Documentation/hyper-dmabuf-sharing.txt
> > 
> > diff --git a/Documentation/hyper-dmabuf-sharing.txt 
> > b/Documentation/hyper-dmabuf-sharing.txt
> > new file mode 100644
> > index ..928e411931e3
> > --- /dev/null
> > +++ b/Documentation/hyper-dmabuf-sharing.txt
> > @@ -0,0 +1,734 @@
> > +Linux Hyper DMABUF Driver
> > +
> > +--
> > +Section 1. Overview
> > +--
> > +
> > +Hyper_DMABUF driver is a Linux device driver running on multiple Virtual
> > +achines (VMs), which expands DMA-BUF sharing capability to the VM 
> > environment
> > +where multiple different OS instances need to share same physical data 
> > without
> > +data-copy across VMs.
> > +
> > +To share a DMA_BUF across VMs, an instance of the Hyper_DMABUF drv on the
> > +exporting VM (so called, “exporter”) imports a local DMA_BUF from the 
> > original
> > +producer of the buffer,
> 
> The usage of export and import in the above sentence makes it almost
> impossible to understand.

Ok, it looks confusing. I think the problem is that those words are used for 
both
local and cross-VMs cases. I will try to clarify those. 

> 
> > then re-exports it with an unique ID, hyper_dmabuf_id
> > +for the buffer to the importing VM (so called, “importer”).
> 
> And this is even worse.
> 
> Maybe it would help to have some kind of flow diagram of all this
> import/export operations, but please read below.

I will add a diagram here.

> 
> > +
> > +Another instance of the Hyper_DMABUF driver on importer registers
> > +a hyper_dmabuf_id together with reference information for the shared 
> > physical
> > +pages associated with the DMA_BUF to its database when the export happens.
> > +
> > +The actual mapping of the DMA_BUF on the importer’s side is done by
> > +the Hyper_DMABUF driver when user space issues the IOCTL command to access
> > +the shared DMA_BUF. The Hyper_DMABUF driver works as both an importing and
> > +exporting driver as is, that is, no special configuration is required.
> > +Consequently, only a single module per VM is needed to enable cross-VM 
> > DMA_BUF
> > +exchange.
> 
> IMHO I need a more generic view of the problem you are trying to solve
> in the overview section. I've read the full overview, and I still have
> no idea why you need all this.

I will add some more paragrahs here to give some more generic view (and possibly
diagrams) of this driver.

> 
> I think the overview should contain at least:
> 
> 1. A description of the problem you are trying to solve.
> 2. A high level description of the proposed solution.
> 3. How the proposed solution deals with the problem described in 1.
> 
> This overview is not useful for people that don't know which problem
> you are trying to solve, like myself.

Thanks again.

> 
> Thanks, Roger.

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

[Xen-devel] [PATCH v5 05/18] xen/arm: Adapt smccc.h to be able to use it in assembly code

[Julien Grall]

Signed-off-by: Julien Grall 
Reviewed-by: Volodymyr Babchuk 
Acked-by: Stefano Stabellini 

---
Changes in v4:
- Add Stefano's acked-by

Changes in v2:
- Add Volodymyr's reviewed-by
---
 xen/include/asm-arm/smccc.h | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h
index 2951caa49d..30208d12ca 100644
--- a/xen/include/asm-arm/smccc.h
+++ b/xen/include/asm-arm/smccc.h
@@ -25,18 +25,20 @@
  * http://infocenter.arm.com/help/topic/com.arm.doc.den0028a/index.html
  */
 
-#define ARM_SMCCC_STD_CALL  0U
-#define ARM_SMCCC_FAST_CALL 1U
+#define ARM_SMCCC_STD_CALL  _AC(0,U)
+#define ARM_SMCCC_FAST_CALL _AC(1,U)
 #define ARM_SMCCC_TYPE_SHIFT31
 
-#define ARM_SMCCC_CONV_32   0U
-#define ARM_SMCCC_CONV_64   1U
+#define ARM_SMCCC_CONV_32   _AC(0,U)
+#define ARM_SMCCC_CONV_64   _AC(1,U)
 #define ARM_SMCCC_CONV_SHIFT30
 
-#define ARM_SMCCC_OWNER_MASK0x3FU
+#define ARM_SMCCC_OWNER_MASK_AC(0x3F,U)
 #define ARM_SMCCC_OWNER_SHIFT   24
 
-#define ARM_SMCCC_FUNC_MASK 0xU
+#define ARM_SMCCC_FUNC_MASK _AC(0x,U)
+
+#ifndef __ASSEMBLY__
 
 /* Check if this is fast call. */
 static inline bool smccc_is_fast_call(register_t funcid)
@@ -62,6 +64,8 @@ static inline uint32_t smccc_get_owner(register_t funcid)
 return (funcid >> ARM_SMCCC_OWNER_SHIFT) & ARM_SMCCC_OWNER_MASK;
 }
 
+#endif
+
 /*
  * Construct function identifier from call type (fast or standard),
  * calling convention (32 or 64 bit), service owner and function number.
-- 
2.11.0


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

[Xen-devel] [PATCH v5 17/18] xen/arm: vpsci: Introduce and use PSCI_INVALID_ADDRESS

[Julien Grall]

PSCI 1.0 added the error return PSCI_INVALID_ADDRESS. It is used to
indicate the entry point address is known to be invalid.

In Xen case, this error could be returned when a 64-bit vCPU is using a
Thumb entry address.

For PSCI 0.1 implementation, return PSCI_INVALID_PARAMETERS instead.

Suggested-by: mirela.simono...@aggios.com
Signed-off-by: Julien Grall 
Reviewed-by: Stefano Stabellini 
Cc: mirela.simono...@aggios.com

---
Changes in v4:
- Add Stefano's reviewed-by

Changes in v3:
- Patch added
---
 xen/arch/arm/vpsci.c   | 10 +++---
 xen/include/asm-arm/psci.h |  1 +
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/vpsci.c b/xen/arch/arm/vpsci.c
index 9a082aa6ee..1729f7071e 100644
--- a/xen/arch/arm/vpsci.c
+++ b/xen/arch/arm/vpsci.c
@@ -38,7 +38,7 @@ static int do_common_cpu_on(register_t target_cpu, register_t 
entry_point,
 
 /* THUMB set is not allowed with 64-bit domain */
 if ( is_64bit_domain(d) && is_thumb )
-return PSCI_INVALID_PARAMETERS;
+return PSCI_INVALID_ADDRESS;
 
 if ( !test_bit(_VPF_down, >pause_flags) )
 return PSCI_ALREADY_ON;
@@ -99,10 +99,14 @@ static int32_t do_psci_cpu_on(uint32_t vcpuid, register_t 
entry_point)
 
 ret = do_common_cpu_on(vcpuid, entry_point, 0);
 /*
- * PSCI 0.1 does not define the return code PSCI_ALREADY_ON.
+ * PSCI 0.1 does not define the return codes PSCI_ALREADY_ON and
+ * PSCI_INVALID_ADDRESS.
  * Instead, return PSCI_INVALID_PARAMETERS.
  */
-return (ret == PSCI_ALREADY_ON) ? PSCI_INVALID_PARAMETERS : ret;
+if ( ret == PSCI_ALREADY_ON || ret == PSCI_INVALID_ADDRESS )
+ret = PSCI_INVALID_PARAMETERS;
+
+return ret;
 }
 
 static int32_t do_psci_cpu_off(uint32_t power_state)
diff --git a/xen/include/asm-arm/psci.h b/xen/include/asm-arm/psci.h
index e2629eed01..9ac820e94a 100644
--- a/xen/include/asm-arm/psci.h
+++ b/xen/include/asm-arm/psci.h
@@ -13,6 +13,7 @@
 #define PSCI_INTERNAL_FAILURE   -6
 #define PSCI_NOT_PRESENT-7
 #define PSCI_DISABLED   -8
+#define PSCI_INVALID_ADDRESS-9
 
 /* availability of PSCI on the host for SMP bringup */
 extern uint32_t psci_ver;
-- 
2.11.0


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

[Xen-devel] [PATCH v5 16/18] xen/arm: vpsci: Update the return type for MIGRATE_INFO_TYPE

[Julien Grall]

From the specification, the PSCI call MIGRATE_INFO_TYPE will return an
int32_t. Update the function return type to match it.

Signed-off-by: Julien Grall 
Reviewed-by: Stefano Stabellini 
Cc: mirela.simono...@aggios.com

---
Changes in v4:
- Add Stefano's reviewed-by

Changes in v3:
- Patch added
---
 xen/arch/arm/vpsci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/arm/vpsci.c b/xen/arch/arm/vpsci.c
index 7ea3ea58e3..9a082aa6ee 100644
--- a/xen/arch/arm/vpsci.c
+++ b/xen/arch/arm/vpsci.c
@@ -186,7 +186,7 @@ static int32_t do_psci_0_2_affinity_info(register_t 
target_affinity,
 return PSCI_0_2_AFFINITY_LEVEL_OFF;
 }
 
-static uint32_t do_psci_0_2_migrate_info_type(void)
+static int32_t do_psci_0_2_migrate_info_type(void)
 {
 return PSCI_0_2_TOS_MP_OR_NOT_PRESENT;
 }
-- 
2.11.0


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

[Xen-devel] [PATCH v5 09/18] xen/arm: psci: Detect SMCCC version

[Julien Grall]

PSCI 1.0 and later allows the SMCCC version to be (indirectly) probed
via PSCI_FEATURES. If the PSCI_FEATURES does not exist (PSCI 0.2 or
earlier) and the function returns an error, then we assume SMCCC 1.0
is implemented.

Signed-off-by: Julien Grall 
Reviewed-by: Stefano Stabellini 
Reviewed-by: Andre Przywara 

---
Changes in v4:
- Add Stefano's reviewed-by
- Add Andre's reviewed-by
- Fix typoes

Changes in v2:
- Patch added
---
 xen/arch/arm/psci.c | 34 +-
 xen/include/asm-arm/smccc.h |  2 ++
 2 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c
index 5dda35cd7c..909d1c176f 100644
--- a/xen/arch/arm/psci.c
+++ b/xen/arch/arm/psci.c
@@ -37,6 +37,7 @@
 #endif
 
 uint32_t psci_ver;
+uint32_t smccc_ver;
 
 static uint32_t psci_cpu_on_nr;
 
@@ -57,6 +58,14 @@ void call_psci_system_reset(void)
 call_smc(PSCI_0_2_FN32_SYSTEM_RESET, 0, 0, 0);
 }
 
+static int __init psci_features(uint32_t psci_func_id)
+{
+if ( psci_ver < PSCI_VERSION(1, 0) )
+return PSCI_NOT_SUPPORTED;
+
+return call_smc(PSCI_1_0_FN32_PSCI_FEATURES, psci_func_id, 0, 0);
+}
+
 int __init psci_is_smc_method(const struct dt_device_node *psci)
 {
 int ret;
@@ -82,6 +91,24 @@ int __init psci_is_smc_method(const struct dt_device_node 
*psci)
 return 0;
 }
 
+static void __init psci_init_smccc(void)
+{
+/* PSCI is using at least SMCCC 1.0 calling convention. */
+smccc_ver = ARM_SMCCC_VERSION_1_0;
+
+if ( psci_features(ARM_SMCCC_VERSION_FID) != PSCI_NOT_SUPPORTED )
+{
+uint32_t ret;
+
+ret = call_smc(ARM_SMCCC_VERSION_FID, 0, 0, 0);
+if ( ret != ARM_SMCCC_NOT_SUPPORTED )
+smccc_ver = ret;
+}
+
+printk(XENLOG_INFO "Using SMC Calling Convention v%u.%u\n",
+   SMCCC_VERSION_MAJOR(smccc_ver), SMCCC_VERSION_MINOR(smccc_ver));
+}
+
 int __init psci_init_0_1(void)
 {
 int ret;
@@ -173,7 +200,12 @@ int __init psci_init(void)
 if ( ret )
 ret = psci_init_0_1();
 
-return ret;
+if ( ret )
+return ret;
+
+psci_init_smccc();
+
+return 0;
 }
 
 /*
diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h
index d0240d64bf..bc067892c7 100644
--- a/xen/include/asm-arm/smccc.h
+++ b/xen/include/asm-arm/smccc.h
@@ -52,6 +52,8 @@
 
 #ifndef __ASSEMBLY__
 
+extern uint32_t smccc_ver;
+
 /* Check if this is fast call. */
 static inline bool smccc_is_fast_call(register_t funcid)
 {
-- 
2.11.0


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

[Xen-devel] [PATCH v5 03/18] xen/arm: vsmc: Implement SMCCC 1.1

[Julien Grall]

The new SMC Calling Convention (v1.1) allows for a reduced overhead when
calling into the firmware, and provides a new feature discovery
mechanism. See "Firmware interfaces for mitigating CVE-2017-5715"
ARM DEN 00070A.

Signed-off-by: Julien Grall 
Reviewed-by: Volodymyr Babchuk 
Acked-by: Stefano Stabellini 

---
Changes in v4:
- Add Volodymyr's reviewed-by
- Add Stefano's acked-by

Changes in v3:
- Use ARM_SMCCC_NOT_SUPPORTED rather than hardcoded return

Changes in v2:
- Add a humand readable name for the specification
---
 xen/arch/arm/vpsci.c|  1 +
 xen/arch/arm/vsmc.c | 23 +++
 xen/include/asm-arm/smccc.h | 18 +-
 3 files changed, 41 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/vpsci.c b/xen/arch/arm/vpsci.c
index e82b62db1a..19ee7caeb4 100644
--- a/xen/arch/arm/vpsci.c
+++ b/xen/arch/arm/vpsci.c
@@ -212,6 +212,7 @@ static int32_t do_psci_1_0_features(uint32_t psci_func_id)
 case PSCI_0_2_FN32_SYSTEM_OFF:
 case PSCI_0_2_FN32_SYSTEM_RESET:
 case PSCI_1_0_FN32_PSCI_FEATURES:
+case ARM_SMCCC_VERSION_FID:
 return 0;
 default:
 return PSCI_NOT_SUPPORTED;
diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
index 3d3bd95fee..7ec492741b 100644
--- a/xen/arch/arm/vsmc.c
+++ b/xen/arch/arm/vsmc.c
@@ -81,6 +81,26 @@ static bool fill_function_call_count(struct cpu_user_regs 
*regs, uint32_t cnt)
 return true;
 }
 
+/* SMCCC interface for ARM Architecture */
+static bool handle_arch(struct cpu_user_regs *regs)
+{
+uint32_t fid = (uint32_t)get_user_reg(regs, 0);
+
+switch ( fid )
+{
+case ARM_SMCCC_VERSION_FID:
+set_user_reg(regs, 0, ARM_SMCCC_VERSION_1_1);
+return true;
+
+case ARM_SMCCC_ARCH_FEATURES_FID:
+/* Nothing supported yet */
+set_user_reg(regs, 0, ARM_SMCCC_NOT_SUPPORTED);
+return true;
+}
+
+return false;
+}
+
 /* SMCCC interface for hypervisor. Tell about itself. */
 static bool handle_hypervisor(struct cpu_user_regs *regs)
 {
@@ -188,6 +208,9 @@ static bool vsmccc_handle_call(struct cpu_user_regs *regs)
 {
 switch ( smccc_get_owner(funcid) )
 {
+case ARM_SMCCC_OWNER_ARCH:
+handled = handle_arch(regs);
+break;
 case ARM_SMCCC_OWNER_HYPERVISOR:
 handled = handle_hypervisor(regs);
 break;
diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h
index 62b3a8cdf5..629cc5150b 100644
--- a/xen/include/asm-arm/smccc.h
+++ b/xen/include/asm-arm/smccc.h
@@ -16,6 +16,9 @@
 #ifndef __ASM_ARM_SMCCC_H__
 #define __ASM_ARM_SMCCC_H__
 
+#define ARM_SMCCC_VERSION_1_0   0x1
+#define ARM_SMCCC_VERSION_1_1   0x10001
+
 /*
  * This file provides common defines for ARM SMC Calling Convention as
  * specified in
@@ -100,8 +103,21 @@ static inline uint32_t smccc_get_owner(register_t funcid)
ARM_SMCCC_OWNER_##owner, \
0xFF03)
 
-/* Only one error code defined in SMCCC */
+#define ARM_SMCCC_VERSION_FID   \
+ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+   ARM_SMCCC_CONV_32,   \
+   ARM_SMCCC_OWNER_ARCH,\
+   0x0) \
+
+#define ARM_SMCCC_ARCH_FEATURES_FID \
+ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+   ARM_SMCCC_CONV_32,   \
+   ARM_SMCCC_OWNER_ARCH,\
+   0x1)
+
+/* SMCCC error codes */
 #define ARM_SMCCC_ERR_UNKNOWN_FUNCTION  (-1)
+#define ARM_SMCCC_NOT_SUPPORTED (-1)
 
 /* SMCCC function identifier range which is reserved for existing APIs */
 #define ARM_SMCCC_RESERVED_RANGE_START  0x0
-- 
2.11.0


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

[Xen-devel] [PATCH v5 18/18] xen/arm: vpsci: Rework the logic to start AArch32 vCPU in Thumb mode

[Julien Grall]

32-bit domain is able to select the instruction (ARM vs Thumb) to use
when boot a new vCPU via CPU_ON. This is indicated via bit[0] of the
entry point address (see "T32 support" in PSCI v1.1 DEN0022D). bit[0]
must be cleared when setting the PC.

At the moment, Xen is setting the CPSR.T but never clear bit[0]. Clear
it to match the specification.

At the same time, slighlty rework the code to make clear thumb is only for
32-bit domain. Lastly, take the opportunity to switch is_thumb from int
to bool.

Signed-off-by: Julien Grall 
Reviewed-by: Stefano Stabellini 
Reviewed-by: Andre Przywara 

---
Changes in v4:
- Add Stefano's reviewed-by
- Add Andre's reviewed-by

Changes in v3:
- Patch added
---
 xen/arch/arm/vpsci.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/vpsci.c b/xen/arch/arm/vpsci.c
index 1729f7071e..9f4e5b8844 100644
--- a/xen/arch/arm/vpsci.c
+++ b/xen/arch/arm/vpsci.c
@@ -28,7 +28,7 @@ static int do_common_cpu_on(register_t target_cpu, register_t 
entry_point,
 struct domain *d = current->domain;
 struct vcpu_guest_context *ctxt;
 int rc;
-int is_thumb = entry_point & 1;
+bool is_thumb = entry_point & 1;
 register_t vcpuid;
 
 vcpuid = vaffinity_to_vcpuid(target_cpu);
@@ -62,6 +62,13 @@ static int do_common_cpu_on(register_t target_cpu, 
register_t entry_point,
 if ( is_32bit_domain(d) )
 {
 ctxt->user_regs.cpsr = PSR_GUEST32_INIT;
+/* Start the VCPU with THUMB set if it's requested by the kernel */
+if ( is_thumb )
+{
+ctxt->user_regs.cpsr |= PSR_THUMB;
+ctxt->user_regs.pc64 &= ~(u64)1;
+}
+
 ctxt->user_regs.r0_usr = context_id;
 }
 #ifdef CONFIG_ARM_64
@@ -71,10 +78,6 @@ static int do_common_cpu_on(register_t target_cpu, 
register_t entry_point,
 ctxt->user_regs.x0 = context_id;
 }
 #endif
-
-/* Start the VCPU with THUMB set if it's requested by the kernel */
-if ( is_thumb )
-ctxt->user_regs.cpsr |= PSR_THUMB;
 ctxt->flags = VGCF_online;
 
 domain_lock(d);
-- 
2.11.0


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

[Xen-devel] [PATCH v5 00/18] xen/arm: PSCI 1.1 and SMCCC-1.1 support and XSA-254 variant 2 update

[Julien Grall]

Hi all,

Arm has recently published a SMC Calling Convention (SMCCC)
specification update [1] that provides an optimised calling convention
and optional, discoverable support for mitigating CVE-2017-5715 (XSA-254
variant 2). ARM Trusted Firmware (ATF) has already gained such an
implementation[2].

This series addresses a few things:

- It provides a Xen implementation of PSCI v1.0, which is a
  prerequisite for being able to discover SMCCC v1.1.
- It allows Xen to advertise SMCCC v1.1
- It implements guest support for the
  ARM_WORKAROUND_1 function that is used
  to mitigate CVE-2017-5715 (if such mitigation is available on the
  hypervisor).
- It adds Xen support for branch predictor hardening via
  ARM_WORKAROUND_1 if the firmware supports it.

This method is intended to fully replace the initial PSCI_GET_VERSION
approach. Although PSCI_GET_VERSION still works, it has an obvious
overhead and is called on some of the hottest paths. We expect
ARCH_WORKAROUND_1 to be much faster.

Cheers,

[1] https://developer.arm.com/support/security-update/downloads

[2] https://github.com/ARM-software/arm-trusted-firmware/pull/1240

[3] https://lists.xen.org/archives/html/xen-devel/2018-02/msg00447.html

Julien Grall (18):
  xen/arm: psci: Rework the PSCI definitions
  xen/arm: vpsci: Add support for PSCI 1.1
  xen/arm: vsmc: Implement SMCCC 1.1
  xen/arm: vsmc: Implement SMCCC_ARCH_WORKAROUND_1 BP hardening support
  xen/arm: Adapt smccc.h to be able to use it in assembly code
  xen/arm64: Implement a fast path for handling SMCCC_ARCH_WORKAROUND_1
  xen/arm64: Print a per-CPU message with the BP hardening method used
  xen/arm: smccc: Add macros SMCCC_VERSION, SMCCC_VERSION_{MINOR, MAJOR}
  xen/arm: psci: Detect SMCCC version
  xen/arm: smccc: Implement SMCCC v1.1 inline primitive
  xen/arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support
  xen/arm64: Kill PSCI_GET_VERSION as a variant-2 workaround
  xen/arm: vpsci: Remove parameter 'ver' from do_common_cpu
  xen/arm: psci: Consolidate PSCI version print
  xen/arm: psci: Prefix with static any functions not exported
  xen/arm: vpsci: Update the return type for MIGRATE_INFO_TYPE
  xen/arm: vpsci: Introduce and use PSCI_INVALID_ADDRESS
  xen/arm: vpsci: Rework the logic to start AArch32 vCPU in Thumb mode

 tools/libxl/libxl_arm.c  |   3 +-
 xen/arch/arm/arm64/bpi.S |  34 +++-
 xen/arch/arm/arm64/entry.S   |  59 -
 xen/arch/arm/cpuerrata.c |  55 +
 xen/arch/arm/domain_build.c  |   1 +
 xen/arch/arm/platforms/seattle.c |   4 +-
 xen/arch/arm/psci.c  |  58 +
 xen/arch/arm/vpsci.c | 111 ++---
 xen/arch/arm/vsmc.c  |  41 +
 xen/include/asm-arm/perfc_defn.h |   1 +
 xen/include/asm-arm/processor.h  |   2 +
 xen/include/asm-arm/psci.h   |  39 +
 xen/include/asm-arm/smccc.h  | 174 +--
 xen/include/asm-arm/vpsci.h  |   2 +-
 14 files changed, 471 insertions(+), 113 deletions(-)

-- 
2.11.0


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

[Xen-devel] [PATCH v5 06/18] xen/arm64: Implement a fast path for handling SMCCC_ARCH_WORKAROUND_1

[Julien Grall]

The function SMCCC_ARCH_WORKAROUND_1 will be called by the guest for
hardening the branch predictor. So we want the handling to be as fast as
possible.

As the mitigation is applied on every guest exit, we can check for the
call before saving all the context and return very early.

For now, only provide a fast path for HVC64 call. Because the code rely
on 2 registers, x0 and x1 are saved in advance.

Signed-off-by: Julien Grall 
Reviewed-by: Volodymyr Babchuk 
Reviewed-by: Stefano Stabellini 

---
guest_sync only handle 64-bit guest, so I have only implemented the
64-bit side for now. We can discuss whether it is useful to
implement it for 32-bit guests.

We could also consider to implement the fast path for SMC64,
althought a guest should always use HVC.

I decided to keep the reviewed-by as mostly the documentation was
updated to make it clearer.

Changes in v4:
- Add Stefano's reviewed-by
- Use xzr to clobber x1 instead of x0
- Update comments in the code

Changes in v2:
- Add Volodymyr's reviewed-by
---
 xen/arch/arm/arm64/entry.S  | 59 +++--
 xen/include/asm-arm/processor.h |  2 ++
 2 files changed, 59 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/arm64/entry.S b/xen/arch/arm/arm64/entry.S
index 6d99e46f0f..ffa9a1c492 100644
--- a/xen/arch/arm/arm64/entry.S
+++ b/xen/arch/arm/arm64/entry.S
@@ -1,6 +1,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /*
@@ -90,8 +91,12 @@ lr  .reqx30 /* link register */
 .endm
 /*
  * Save state on entry to hypervisor, restore on exit
+ *
+ * save_x0_x1: Does the macro needs to save x0/x1? Defaults to 1
+ * If 0, we rely on the on x0/x1 to have been saved at the correct
+ * position on the stack before.
  */
-.macro  entry, hyp, compat
+.macro  entry, hyp, compat, save_x0_x1=1
 sub sp, sp, #(UREGS_SPSR_el1 - UREGS_LR) /* CPSR, PC, SP, LR */
 pushx28, x29
 pushx26, x27
@@ -107,7 +112,16 @@ lr  .reqx30 /* link register */
 pushx6, x7
 pushx4, x5
 pushx2, x3
+/*
+ * The caller may already have saved x0/x1 on the stack at the
+ * correct address and corrupt them with another value. Only
+ * save them if save_x0_x1 == 1.
+ */
+.if \save_x0_x1 == 1
 pushx0, x1
+.else
+sub sp, sp, #16
+.endif
 
 .if \hyp == 1/* Hypervisor mode */
 
@@ -200,7 +214,48 @@ hyp_irq:
 exithyp=1
 
 guest_sync:
-entry   hyp=0, compat=0
+/*
+ * Save x0, x1 in advance
+ */
+stp x0, x1, [sp, #-(UREGS_kernel_sizeof - UREGS_X0)]
+
+/*
+ * x1 is used because x0 may contain the function identifier.
+ * This avoids to restore x0 from the stack.
+ */
+mrs x1, esr_el2
+lsr x1, x1, #HSR_EC_SHIFT   /* x1 = ESR_EL2.EC */
+cmp x1, #HSR_EC_HVC64
+b.ne1f  /* Not a HVC skip fastpath. */
+
+mrs x1, esr_el2
+and x1, x1, #0x /* Check the immediate [0:16] 
*/
+cbnzx1, 1f  /* should be 0 for HVC #0 */
+
+/*
+ * Fastest path possible for ARM_SMCCC_ARCH_WORKAROUND_1.
+ * The workaround has already been applied on the exception
+ * entry from the guest, so let's quickly get back to the guest.
+ *
+ * Note that eor is used because the function identifier cannot
+ * be encoded as an immediate for cmp.
+ */
+eor w0, w0, #ARM_SMCCC_ARCH_WORKAROUND_1_FID
+cbnzw0, 1f
+
+/*
+ * Clobber both x0 and x1 to prevent leakage. Note that thanks
+ * the eor, x0 = 0.
+ */
+mov x1, xzr
+eret
+
+1:
+/*
+ * x0/x1 may have been scratch by the fast path above, so avoid
+ * to save them.
+ */
+entry   hyp=0, compat=0, save_x0_x1=0
 /*
  * The vSError will be checked while SKIP_SYNCHRONIZE_SERROR_ENTRY_EXIT
  * is not set. If a vSError took place, the initial exception will be
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index c0f79d0093..222a02dd99 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -306,6 +306,8 @@
 #define HDCR_TPM(_AC(1,U)<<6)   /* Trap Performance Monitors 
accesses */
 #define HDCR_TPMCR  (_AC(1,U)<<5)   /* Trap PMCR accesses */
 
+#define HSR_EC_SHIFT26
+
 #define HSR_EC_UNKNOWN  0x00
 #define HSR_EC_WFI_WFE  0x01
 #define HSR_EC_CP15_32  0x03
-- 
2.11.0

[Xen-devel] [PATCH v5 01/18] xen/arm: psci: Rework the PSCI definitions

[Julien Grall]

Some PSCI functions are only available in the 32-bit version. After
recent changes, Xen always needs to know whether the call was made using
32-bit id or 64-bit id. So we don't emulate reserved one.

With the current naming scheme, it is not easy to know which call
supports 32-bit and 64-bit id. So rework the definitions to encode the
version in the name. From now the functions will be named PSCI_0_2_FNxx
where xx is 32 or 64.

Signed-off-by: Julien Grall 
Reviewed-by: Volodymyr Babchuk 

---
Changes in v2:
- Add Volodymyr's reviewed-by
---
 xen/arch/arm/platforms/seattle.c |  4 ++--
 xen/arch/arm/psci.c  | 10 +-
 xen/arch/arm/vpsci.c | 22 +++---
 xen/include/asm-arm/psci.h   | 37 +
 4 files changed, 39 insertions(+), 34 deletions(-)

diff --git a/xen/arch/arm/platforms/seattle.c b/xen/arch/arm/platforms/seattle.c
index 22c062293f..893cc17972 100644
--- a/xen/arch/arm/platforms/seattle.c
+++ b/xen/arch/arm/platforms/seattle.c
@@ -33,12 +33,12 @@ static const char * const seattle_dt_compat[] __initconst =
  */
 static void seattle_system_reset(void)
 {
-call_smc(PSCI_0_2_FN32(SYSTEM_RESET), 0, 0, 0);
+call_smc(PSCI_0_2_FN32_SYSTEM_RESET, 0, 0, 0);
 }
 
 static void seattle_system_off(void)
 {
-call_smc(PSCI_0_2_FN32(SYSTEM_OFF), 0, 0, 0);
+call_smc(PSCI_0_2_FN32_SYSTEM_OFF, 0, 0, 0);
 }
 
 PLATFORM_START(seattle, "SEATTLE")
diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c
index 1508a3be3a..5dda35cd7c 100644
--- a/xen/arch/arm/psci.c
+++ b/xen/arch/arm/psci.c
@@ -31,9 +31,9 @@
  * (native-width) function ID.
  */
 #ifdef CONFIG_ARM_64
-#define PSCI_0_2_FN_NATIVE(name)PSCI_0_2_FN64(name)
+#define PSCI_0_2_FN_NATIVE(name)PSCI_0_2_FN64_##name
 #else
-#define PSCI_0_2_FN_NATIVE(name)PSCI_0_2_FN32(name)
+#define PSCI_0_2_FN_NATIVE(name)PSCI_0_2_FN32_##name
 #endif
 
 uint32_t psci_ver;
@@ -48,13 +48,13 @@ int call_psci_cpu_on(int cpu)
 void call_psci_system_off(void)
 {
 if ( psci_ver > PSCI_VERSION(0, 1) )
-call_smc(PSCI_0_2_FN32(SYSTEM_OFF), 0, 0, 0);
+call_smc(PSCI_0_2_FN32_SYSTEM_OFF, 0, 0, 0);
 }
 
 void call_psci_system_reset(void)
 {
 if ( psci_ver > PSCI_VERSION(0, 1) )
-call_smc(PSCI_0_2_FN32(SYSTEM_RESET), 0, 0, 0);
+call_smc(PSCI_0_2_FN32_SYSTEM_RESET, 0, 0, 0);
 }
 
 int __init psci_is_smc_method(const struct dt_device_node *psci)
@@ -144,7 +144,7 @@ int __init psci_init_0_2(void)
 }
 }
 
-psci_ver = call_smc(PSCI_0_2_FN32(PSCI_VERSION), 0, 0, 0);
+psci_ver = call_smc(PSCI_0_2_FN32_PSCI_VERSION, 0, 0, 0);
 
 /* For the moment, we only support PSCI 0.2 and PSCI 1.x */
 if ( psci_ver != PSCI_VERSION(0, 2) && PSCI_VERSION_MAJOR(psci_ver) != 1 )
diff --git a/xen/arch/arm/vpsci.c b/xen/arch/arm/vpsci.c
index 03fd4eb5b5..6ab8ab64d0 100644
--- a/xen/arch/arm/vpsci.c
+++ b/xen/arch/arm/vpsci.c
@@ -243,35 +243,35 @@ bool do_vpsci_0_2_call(struct cpu_user_regs *regs, 
uint32_t fid)
  */
 switch ( fid )
 {
-case PSCI_0_2_FN32(PSCI_VERSION):
+case PSCI_0_2_FN32_PSCI_VERSION:
 perfc_incr(vpsci_version);
 PSCI_SET_RESULT(regs, do_psci_0_2_version());
 return true;
 
-case PSCI_0_2_FN32(CPU_OFF):
+case PSCI_0_2_FN32_CPU_OFF:
 perfc_incr(vpsci_cpu_off);
 PSCI_SET_RESULT(regs, do_psci_0_2_cpu_off());
 return true;
 
-case PSCI_0_2_FN32(MIGRATE_INFO_TYPE):
+case PSCI_0_2_FN32_MIGRATE_INFO_TYPE:
 perfc_incr(vpsci_migrate_info_type);
 PSCI_SET_RESULT(regs, do_psci_0_2_migrate_info_type());
 return true;
 
-case PSCI_0_2_FN32(SYSTEM_OFF):
+case PSCI_0_2_FN32_SYSTEM_OFF:
 perfc_incr(vpsci_system_off);
 do_psci_0_2_system_off();
 PSCI_SET_RESULT(regs, PSCI_INTERNAL_FAILURE);
 return true;
 
-case PSCI_0_2_FN32(SYSTEM_RESET):
+case PSCI_0_2_FN32_SYSTEM_RESET:
 perfc_incr(vpsci_system_reset);
 do_psci_0_2_system_reset();
 PSCI_SET_RESULT(regs, PSCI_INTERNAL_FAILURE);
 return true;
 
-case PSCI_0_2_FN32(CPU_ON):
-case PSCI_0_2_FN64(CPU_ON):
+case PSCI_0_2_FN32_CPU_ON:
+case PSCI_0_2_FN64_CPU_ON:
 {
 register_t vcpuid = PSCI_ARG(regs, 1);
 register_t epoint = PSCI_ARG(regs, 2);
@@ -282,8 +282,8 @@ bool do_vpsci_0_2_call(struct cpu_user_regs *regs, uint32_t 
fid)
 return true;
 }
 
-case PSCI_0_2_FN32(CPU_SUSPEND):
-case PSCI_0_2_FN64(CPU_SUSPEND):
+case PSCI_0_2_FN32_CPU_SUSPEND:
+case PSCI_0_2_FN64_CPU_SUSPEND:
 {
 uint32_t pstate = PSCI_ARG32(regs, 1);
 register_t epoint = PSCI_ARG(regs, 2);
@@ -294,8 +294,8 @@ bool do_vpsci_0_2_call(struct cpu_user_regs *regs, uint32_t 
fid)
 return true;
 }
 
-case PSCI_0_2_FN32(AFFINITY_INFO):
-case PSCI_0_2_FN64(AFFINITY_INFO):
+case 

[Xen-devel] [PATCH v5 11/18] xen/arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support

[Julien Grall]

Add the detection and runtime code for ARM_SMCCC_ARCH_WORKAROUND_1.

Signed-off-by: Julien Grall 

---
Changes in v5:
- Fold the fixup! patch which re-order registers into it.

Changes in v4:
- Re-order saving/restoring registers in
  __smccc_workaround_1_smc_start

Changes in v3:
- Add the missing call to smc #0.

Changes in v2:
- Patch added
---
 xen/arch/arm/arm64/bpi.S| 13 +
 xen/arch/arm/cpuerrata.c| 32 +++-
 xen/include/asm-arm/smccc.h |  1 +
 3 files changed, 45 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/arm64/bpi.S b/xen/arch/arm/arm64/bpi.S
index 4b7f1dc21f..b59e307b0f 100644
--- a/xen/arch/arm/arm64/bpi.S
+++ b/xen/arch/arm/arm64/bpi.S
@@ -16,6 +16,8 @@
  * along with this program.  If not, see .
  */
 
+#include 
+
 .macro ventry target
 .rept 31
 nop
@@ -81,6 +83,17 @@ ENTRY(__psci_hyp_bp_inval_start)
 add sp, sp, #(8 * 18)
 ENTRY(__psci_hyp_bp_inval_end)
 
+ENTRY(__smccc_workaround_1_smc_start)
+sub sp, sp, #(8 * 4)
+stp x0, x1, [sp, #(8 * 2)]
+stp x2, x3, [sp, #(8 * 0)]
+mov w0, #ARM_SMCCC_ARCH_WORKAROUND_1_FID
+smc #0
+ldp x2, x3, [sp, #(8 * 0)]
+ldp x0, x1, [sp, #(8 * 2)]
+add sp, sp, #(8 * 4)
+ENTRY(__smccc_workaround_1_smc_end)
+
 /*
  * Local variables:
  * mode: ASM
diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index 8d5f8d372a..dec9074422 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -147,6 +147,34 @@ install_bp_hardening_vec(const struct arm_cpu_capabilities 
*entry,
 return ret;
 }
 
+extern char __smccc_workaround_1_smc_start[], __smccc_workaround_1_smc_end[];
+
+static bool
+check_smccc_arch_workaround_1(const struct arm_cpu_capabilities *entry)
+{
+struct arm_smccc_res res;
+
+/*
+ * Enable callbacks are called on every CPU based on the
+ * capabilities. So double-check whether the CPU matches the
+ * entry.
+ */
+if ( !entry->matches(entry) )
+return false;
+
+if ( smccc_ver < SMCCC_VERSION(1, 1) )
+return false;
+
+arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID,
+  ARM_SMCCC_ARCH_WORKAROUND_1_FID, );
+if ( res.a0 != ARM_SMCCC_SUCCESS )
+return false;
+
+return install_bp_hardening_vec(entry,__smccc_workaround_1_smc_start,
+__smccc_workaround_1_smc_end,
+"call ARM_SMCCC_ARCH_WORKAROUND_1");
+}
+
 extern char __psci_hyp_bp_inval_start[], __psci_hyp_bp_inval_end[];
 
 static int enable_psci_bp_hardening(void *data)
@@ -154,12 +182,14 @@ static int enable_psci_bp_hardening(void *data)
 bool ret = true;
 static bool warned = false;
 
+if ( check_smccc_arch_workaround_1(data) )
+return 0;
 /*
  * The mitigation is using PSCI version function to invalidate the
  * branch predictor. This function is only available with PSCI 0.2
  * and later.
  */
-if ( psci_ver >= PSCI_VERSION(0, 2) )
+else if ( psci_ver >= PSCI_VERSION(0, 2) )
 ret = install_bp_hardening_vec(data, __psci_hyp_bp_inval_start,
__psci_hyp_bp_inval_end,
"call PSCI get version");
diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h
index 154772b728..8342cc33fe 100644
--- a/xen/include/asm-arm/smccc.h
+++ b/xen/include/asm-arm/smccc.h
@@ -261,6 +261,7 @@ struct arm_smccc_res {
 /* SMCCC error codes */
 #define ARM_SMCCC_ERR_UNKNOWN_FUNCTION  (-1)
 #define ARM_SMCCC_NOT_SUPPORTED (-1)
+#define ARM_SMCCC_SUCCESS   (0)
 
 /* SMCCC function identifier range which is reserved for existing APIs */
 #define ARM_SMCCC_RESERVED_RANGE_START  0x0
-- 
2.11.0


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

[Xen-devel] [PATCH v5 14/18] xen/arm: psci: Consolidate PSCI version print

[Julien Grall]

Xen is printing the same way the PSCI version for 0.1, 0.2 and later.
The only different is the former is hardcoded.

Furthermore PSCI is now used for other things than SMP bring up. So only
print the PSCI version in psci_init.

Signed-off-by: Julien Grall 
Reviewed-by: Volodymyr Babchuk 
Acked-by: Stefano Stabellini 

---
Changes in v4:
- Add Stefano's acked-by

Changes in v3:
- Add Volodymyr's reviewed-by

Changes in v2:
- Patch added
---
 xen/arch/arm/psci.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c
index 909d1c176f..6e6980bfe2 100644
--- a/xen/arch/arm/psci.c
+++ b/xen/arch/arm/psci.c
@@ -136,8 +136,6 @@ int __init psci_init_0_1(void)
 
 psci_ver = PSCI_VERSION(0, 1);
 
-printk(XENLOG_INFO "Using PSCI-0.1 for SMP bringup\n");
-
 return 0;
 }
 
@@ -183,9 +181,6 @@ int __init psci_init_0_2(void)
 
 psci_cpu_on_nr = PSCI_0_2_FN_NATIVE(CPU_ON);
 
-printk(XENLOG_INFO "Using PSCI-%u.%u for SMP bringup\n",
-   PSCI_VERSION_MAJOR(psci_ver), PSCI_VERSION_MINOR(psci_ver));
-
 return 0;
 }
 
@@ -205,6 +200,9 @@ int __init psci_init(void)
 
 psci_init_smccc();
 
+printk(XENLOG_INFO "Using PSCI v%u.%u\n",
+   PSCI_VERSION_MAJOR(psci_ver), PSCI_VERSION_MINOR(psci_ver));
+
 return 0;
 }
 
-- 
2.11.0


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

[Xen-devel] [PATCH v5 15/18] xen/arm: psci: Prefix with static any functions not exported

[Julien Grall]

A bunch of PSCI functions are not prefixed with static despite no one is
using them outside the file and the prototype is not available in
psci.h.

Signed-off-by: Julien Grall 
Reviewed-by: Volodymyr Babchuk 
Acked-by: Stefano Stabellini 

---
Changes in v4:
- Add Stefano's acked-by

Changes in v2:
- Patch added
---
 xen/arch/arm/psci.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c
index 6e6980bfe2..94b616df9b 100644
--- a/xen/arch/arm/psci.c
+++ b/xen/arch/arm/psci.c
@@ -66,7 +66,7 @@ static int __init psci_features(uint32_t psci_func_id)
 return call_smc(PSCI_1_0_FN32_PSCI_FEATURES, psci_func_id, 0, 0);
 }
 
-int __init psci_is_smc_method(const struct dt_device_node *psci)
+static int __init psci_is_smc_method(const struct dt_device_node *psci)
 {
 int ret;
 const char *prop_str;
@@ -109,7 +109,7 @@ static void __init psci_init_smccc(void)
SMCCC_VERSION_MAJOR(smccc_ver), SMCCC_VERSION_MINOR(smccc_ver));
 }
 
-int __init psci_init_0_1(void)
+static int __init psci_init_0_1(void)
 {
 int ret;
 const struct dt_device_node *psci;
@@ -139,7 +139,7 @@ int __init psci_init_0_1(void)
 return 0;
 }
 
-int __init psci_init_0_2(void)
+static int __init psci_init_0_2(void)
 {
 static const struct dt_device_match psci_ids[] __initconst =
 {
-- 
2.11.0


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

[Xen-devel] [PATCH v5 13/18] xen/arm: vpsci: Remove parameter 'ver' from do_common_cpu

[Julien Grall]

Currently, the behavior of do_common_cpu will slightly change depending
on the PSCI version passed in parameter. Looking at the code, more the
specific 0.2 behavior could move out of the function or adapted for 0.1:

- x0/r0 can be updated on PSCI 0.1 because general purpose registers
are undefined upon CPU on. This was deduced from the spec not
mentioning the state of general purpose registers on CPU on.
- PSCI 0.1 does not defined PSCI_ALREADY_ON. However, it would be
safer to bail out if the CPU is already on.

Based on this, the parameter 'ver' is removed and do_psci_cpu_on
(implementation for PSCI 0.1) is adapted to avoid returning
PSCI_ALREADY_ON.

Signed-off-by: Julien Grall 
Reviewed-by: Volodymyr Babchuk 
Acked-by: Stefano Stabellini 
Reviewed-by: Andre Przywara 

---
The reviewed-by was kept despite move this patch towards the end
of the series because there was no clash with the rest of the series.

Changes in v4:
- Slightly update the comment to mention the spec
- Add Stefano's acked-by
- Add Andre's reviewed-by

Changes in v2:
- Move the patch towards the end of the series as not strictly
necessary for SP2.
- Add Volodymyr's reviewed-by
---
 xen/arch/arm/vpsci.c | 28 ++--
 1 file changed, 18 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/vpsci.c b/xen/arch/arm/vpsci.c
index 19ee7caeb4..7ea3ea58e3 100644
--- a/xen/arch/arm/vpsci.c
+++ b/xen/arch/arm/vpsci.c
@@ -22,7 +22,7 @@
 #include 
 
 static int do_common_cpu_on(register_t target_cpu, register_t entry_point,
-   register_t context_id,int ver)
+register_t context_id)
 {
 struct vcpu *v;
 struct domain *d = current->domain;
@@ -40,8 +40,7 @@ static int do_common_cpu_on(register_t target_cpu, register_t 
entry_point,
 if ( is_64bit_domain(d) && is_thumb )
 return PSCI_INVALID_PARAMETERS;
 
-if ( (ver == PSCI_VERSION(0, 2)) &&
-!test_bit(_VPF_down, >pause_flags) )
+if ( !test_bit(_VPF_down, >pause_flags) )
 return PSCI_ALREADY_ON;
 
 if ( (ctxt = alloc_vcpu_guest_context()) == NULL )
@@ -55,18 +54,21 @@ static int do_common_cpu_on(register_t target_cpu, 
register_t entry_point,
 ctxt->ttbr0 = 0;
 ctxt->ttbr1 = 0;
 ctxt->ttbcr = 0; /* Defined Reset Value */
+
+/*
+ * x0/r0_usr are always updated because for PSCI 0.1 the general
+ * purpose registers are undefined upon CPU_on.
+ */
 if ( is_32bit_domain(d) )
 {
 ctxt->user_regs.cpsr = PSR_GUEST32_INIT;
-if ( ver == PSCI_VERSION(0, 2) )
-ctxt->user_regs.r0_usr = context_id;
+ctxt->user_regs.r0_usr = context_id;
 }
 #ifdef CONFIG_ARM_64
 else
 {
 ctxt->user_regs.cpsr = PSR_GUEST64_INIT;
-if ( ver == PSCI_VERSION(0, 2) )
-ctxt->user_regs.x0 = context_id;
+ctxt->user_regs.x0 = context_id;
 }
 #endif
 
@@ -93,7 +95,14 @@ static int do_common_cpu_on(register_t target_cpu, 
register_t entry_point,
 
 static int32_t do_psci_cpu_on(uint32_t vcpuid, register_t entry_point)
 {
-return do_common_cpu_on(vcpuid, entry_point, 0 , PSCI_VERSION(0, 1));
+int32_t ret;
+
+ret = do_common_cpu_on(vcpuid, entry_point, 0);
+/*
+ * PSCI 0.1 does not define the return code PSCI_ALREADY_ON.
+ * Instead, return PSCI_INVALID_PARAMETERS.
+ */
+return (ret == PSCI_ALREADY_ON) ? PSCI_INVALID_PARAMETERS : ret;
 }
 
 static int32_t do_psci_cpu_off(uint32_t power_state)
@@ -137,8 +146,7 @@ static int32_t do_psci_0_2_cpu_on(register_t target_cpu,
   register_t entry_point,
   register_t context_id)
 {
-return do_common_cpu_on(target_cpu, entry_point, context_id,
-PSCI_VERSION(0, 2));
+return do_common_cpu_on(target_cpu, entry_point, context_id);
 }
 
 static const unsigned long target_affinity_mask[] = {
-- 
2.11.0


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

[Xen-devel] [PATCH v5 08/18] xen/arm: smccc: Add macros SMCCC_VERSION, SMCCC_VERSION_{MINOR, MAJOR}

[Julien Grall]

Add macros SMCCC_VERSION, SMCCC_VERSION_{MINOR, MAJOR} to easily convert
between a 32-bit value and a version number. The encoding is based on
2.2.2 in "Firmware interfaces for mitigation CVE-2017-5715" (ARM DEN 0070A).

Also re-use them to define ARM_SMCCC_VERSION_1_0 and ARM_SMCCC_VERSION_1_1.

Signed-off-by: Julien Grall 
Reviewed-by: Volodymyr Babchuk 
Acked-by: Stefano Stabellini 

---
Changes in v4:
- Add Stefano's acked-by

Changes in v3:
- Add Volodymyr's reviewed-by

Changes in v2:
- Patch added
---
 xen/include/asm-arm/smccc.h | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h
index 30208d12ca..d0240d64bf 100644
--- a/xen/include/asm-arm/smccc.h
+++ b/xen/include/asm-arm/smccc.h
@@ -16,8 +16,20 @@
 #ifndef __ASM_ARM_SMCCC_H__
 #define __ASM_ARM_SMCCC_H__
 
-#define ARM_SMCCC_VERSION_1_0   0x1
-#define ARM_SMCCC_VERSION_1_1   0x10001
+#define SMCCC_VERSION_MAJOR_SHIFT16
+#define SMCCC_VERSION_MINOR_MASK \
+((1U << SMCCC_VERSION_MAJOR_SHIFT) - 1)
+#define SMCCC_VERSION_MAJOR_MASK ~SMCCC_VERSION_MINOR_MASK
+#define SMCCC_VERSION_MAJOR(ver) \
+(((ver) & SMCCC_VERSION_MAJOR_MASK) >> SMCCC_VERSION_MAJOR_SHIFT)
+#define SMCCC_VERSION_MINOR(ver) \
+((ver) & SMCCC_VERSION_MINOR_MASK)
+
+#define SMCCC_VERSION(major, minor)  \
+(((major) << SMCCC_VERSION_MAJOR_SHIFT) | (minor))
+
+#define ARM_SMCCC_VERSION_1_0   SMCCC_VERSION(1, 0)
+#define ARM_SMCCC_VERSION_1_1   SMCCC_VERSION(1, 1)
 
 /*
  * This file provides common defines for ARM SMC Calling Convention as
-- 
2.11.0


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

[Xen-devel] [PATCH v5 12/18] xen/arm64: Kill PSCI_GET_VERSION as a variant-2 workaround

[Julien Grall]

Now that we've standardised on SMCCC v1.1 to perform the branch
prediction invalidation, let's drop the previous band-aid. If vendors
haven't updated their firmware to do SMCCC 1.1, they haven't updated
PSCI either, so we don't loose anything.

This is aligned with the Linux commit 3a0a397ff5ff.

Signed-off-by: Julien Grall 
Reviewed-by: Volodymyr Babchuk 
Reviewed-by: Stefano Stabellini 

---
Note that the patch is in arm64/for-next/core and should be merged
in master soon.

Changes in v4:
- Add Stefano's reviewed-by

Changes in v3:
- Add Volodymyr's reviewed-by

Changes in v2:
- Patch added
---
 xen/arch/arm/arm64/bpi.S | 25 --
 xen/arch/arm/cpuerrata.c | 54 +---
 2 files changed, 19 insertions(+), 60 deletions(-)

diff --git a/xen/arch/arm/arm64/bpi.S b/xen/arch/arm/arm64/bpi.S
index b59e307b0f..d8743d955c 100644
--- a/xen/arch/arm/arm64/bpi.S
+++ b/xen/arch/arm/arm64/bpi.S
@@ -58,31 +58,6 @@ ENTRY(__bp_harden_hyp_vecs_start)
 .endr
 ENTRY(__bp_harden_hyp_vecs_end)
 
-ENTRY(__psci_hyp_bp_inval_start)
-sub sp, sp, #(8 * 18)
-stp x16, x17, [sp, #(16 * 0)]
-stp x14, x15, [sp, #(16 * 1)]
-stp x12, x13, [sp, #(16 * 2)]
-stp x10, x11, [sp, #(16 * 3)]
-stp x8, x9, [sp, #(16 * 4)]
-stp x6, x7, [sp, #(16 * 5)]
-stp x4, x5, [sp, #(16 * 6)]
-stp x2, x3, [sp, #(16 * 7)]
-stp x0, x1, [sp, #(16 * 8)]
-mov x0, #0x8400
-smc #0
-ldp x16, x17, [sp, #(16 * 0)]
-ldp x14, x15, [sp, #(16 * 1)]
-ldp x12, x13, [sp, #(16 * 2)]
-ldp x10, x11, [sp, #(16 * 3)]
-ldp x8, x9, [sp, #(16 * 4)]
-ldp x6, x7, [sp, #(16 * 5)]
-ldp x4, x5, [sp, #(16 * 6)]
-ldp x2, x3, [sp, #(16 * 7)]
-ldp x0, x1, [sp, #(16 * 8)]
-add sp, sp, #(8 * 18)
-ENTRY(__psci_hyp_bp_inval_end)
-
 ENTRY(__smccc_workaround_1_smc_start)
 sub sp, sp, #(8 * 4)
 stp x0, x1, [sp, #(8 * 2)]
diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index dec9074422..4eb1567589 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -149,10 +149,11 @@ install_bp_hardening_vec(const struct 
arm_cpu_capabilities *entry,
 
 extern char __smccc_workaround_1_smc_start[], __smccc_workaround_1_smc_end[];
 
-static bool
-check_smccc_arch_workaround_1(const struct arm_cpu_capabilities *entry)
+static int enable_smccc_arch_workaround_1(void *data)
 {
 struct arm_smccc_res res;
+static bool warned = false;
+const struct arm_cpu_capabilities *entry = data;
 
 /*
  * Enable callbacks are called on every CPU based on the
@@ -160,47 +161,30 @@ check_smccc_arch_workaround_1(const struct 
arm_cpu_capabilities *entry)
  * entry.
  */
 if ( !entry->matches(entry) )
-return false;
+return 0;
 
 if ( smccc_ver < SMCCC_VERSION(1, 1) )
-return false;
+goto warn;
 
 arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID,
   ARM_SMCCC_ARCH_WORKAROUND_1_FID, );
 if ( res.a0 != ARM_SMCCC_SUCCESS )
-return false;
-
-return install_bp_hardening_vec(entry,__smccc_workaround_1_smc_start,
-__smccc_workaround_1_smc_end,
-"call ARM_SMCCC_ARCH_WORKAROUND_1");
-}
+goto warn;
 
-extern char __psci_hyp_bp_inval_start[], __psci_hyp_bp_inval_end[];
+return !install_bp_hardening_vec(entry,__smccc_workaround_1_smc_start,
+ __smccc_workaround_1_smc_end,
+ "call ARM_SMCCC_ARCH_WORKAROUND_1");
 
-static int enable_psci_bp_hardening(void *data)
-{
-bool ret = true;
-static bool warned = false;
-
-if ( check_smccc_arch_workaround_1(data) )
-return 0;
-/*
- * The mitigation is using PSCI version function to invalidate the
- * branch predictor. This function is only available with PSCI 0.2
- * and later.
- */
-else if ( psci_ver >= PSCI_VERSION(0, 2) )
-ret = install_bp_hardening_vec(data, __psci_hyp_bp_inval_start,
-   __psci_hyp_bp_inval_end,
-   "call PSCI get version");
-else if ( !warned )
+warn:
+if ( !warned )
 {
 ASSERT(system_state < SYS_STATE_active);
-warning_add("PSCI 0.2 or later is required for the branch predictor 
hardening.\n");
-warned = true;
+warning_add("No support for ARM_SMCCC_ARCH_WORKAROUND_1.\n"
+"Please update your firmware.\n");
+warned = false;
 }
 
-return !ret;
+return 0;
 }
 
 #endif /* CONFIG_ARM64_HARDEN_BRANCH_PREDICTOR */
@@ -316,22 +300,22 @@ static const struct arm_cpu_capabilities arm_errata[] = {
 {
 .capability = 

[Xen-devel] [PATCH v5 07/18] xen/arm64: Print a per-CPU message with the BP hardening method used

[Julien Grall]

This will make easier to know whether BP hardening has been enabled for
a CPU and which method is used.

Signed-off-by: Julien Grall 
Reviewed-by: Volodymyr Babcuk 
Acked-by: Stefano Stabellini 

---
Changes in v4:
- Add Stefano's acked-by

Changes in v3:
- Add Volodymyr's reviewed-by

Changes in v2:
- Patch added
---
 xen/arch/arm/cpuerrata.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index c243521ed4..8d5f8d372a 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -79,7 +79,8 @@ static bool copy_hyp_vect_bpi(unsigned int slot, const char 
*hyp_vec_start,
 static bool __maybe_unused
 install_bp_hardening_vec(const struct arm_cpu_capabilities *entry,
  const char *hyp_vec_start,
- const char *hyp_vec_end)
+ const char *hyp_vec_end,
+ const char *desc)
 {
 static int last_slot = -1;
 static DEFINE_SPINLOCK(bp_lock);
@@ -94,6 +95,9 @@ install_bp_hardening_vec(const struct arm_cpu_capabilities 
*entry,
 if ( !entry->matches(entry) )
 return true;
 
+printk(XENLOG_INFO "CPU%u will %s on exception entry\n",
+   smp_processor_id(), desc);
+
 /*
  * No need to install hardened vector when the processor has
  * ID_AA64PRF0_EL1.CSV2 set.
@@ -157,7 +161,8 @@ static int enable_psci_bp_hardening(void *data)
  */
 if ( psci_ver >= PSCI_VERSION(0, 2) )
 ret = install_bp_hardening_vec(data, __psci_hyp_bp_inval_start,
-   __psci_hyp_bp_inval_end);
+   __psci_hyp_bp_inval_end,
+   "call PSCI get version");
 else if ( !warned )
 {
 ASSERT(system_state < SYS_STATE_active);
-- 
2.11.0


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

[Xen-devel] [PATCH v5 10/18] xen/arm: smccc: Implement SMCCC v1.1 inline primitive

[Julien Grall]

One of the major improvement of SMCCC v1.1 is that it only clobbers the
first 4 registers, both on 32 and 64bit. This means that it becomes very
easy to provide an inline version of the SMC call primitive, and avoid
performing a function call to stash the registers that woudl otherwise
be clobbered by SMCCC v1.0.

This patch has been adapted to Xen from Linux commit f2d3b2e8759a. The
changes mades are:
- Using Xen coding style
- Remove HVC as not used by Xen
- Add arm_smccc_res structure

 Reviewed-by: Robin Murphy 
 Tested-by: Ard Biesheuvel 
 Signed-off-by: Marc Zyngier 
 Signed-off-by: Catalin Marinas 

Signed-off-by: Julien Grall 
Acked-by: Stefano Stabellini 

---

Note that the patch is in arm64/for-next/core and should be merged
in master soon.

Changes in v4:
- Add Stefano's acked-by

Changes in v2:
- Patch added
---
 xen/include/asm-arm/smccc.h | 119 
 1 file changed, 119 insertions(+)

diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h
index bc067892c7..154772b728 100644
--- a/xen/include/asm-arm/smccc.h
+++ b/xen/include/asm-arm/smccc.h
@@ -78,6 +78,125 @@ static inline uint32_t smccc_get_owner(register_t funcid)
 return (funcid >> ARM_SMCCC_OWNER_SHIFT) & ARM_SMCCC_OWNER_MASK;
 }
 
+/*
+ * struct arm_smccc_res - Result from SMC call
+ * @a0 - @a3 result values from registers 0 to 3
+ */
+struct arm_smccc_res {
+unsigned long a0;
+unsigned long a1;
+unsigned long a2;
+unsigned long a3;
+};
+
+/* SMCCC v1.1 implementation madness follows */
+#define ___count_args(_0, _1, _2, _3, _4, _5, _6, _7, _8, x, ...) x
+
+#define __count_args(...)   \
+___count_args(__VA_ARGS__, 7, 6, 5, 4, 3, 2, 1, 0)
+
+#define __constraint_write_0\
+"+r" (r0), "=" (r1), "=" (r2), "=" (r3)
+#define __constraint_write_1\
+"+r" (r0), "+r" (r1), "=" (r2), "=" (r3)
+#define __constraint_write_2\
+"+r" (r0), "+r" (r1), "+r" (r2), "=" (r3)
+#define __constraint_write_3\
+"+r" (r0), "+r" (r1), "+r" (r2), "+r" (r3)
+#define __constraint_write_4__constraint_write_3
+#define __constraint_write_5__constraint_write_4
+#define __constraint_write_6__constraint_write_5
+#define __constraint_write_7__constraint_write_6
+
+#define __constraint_read_0
+#define __constraint_read_1
+#define __constraint_read_2
+#define __constraint_read_3
+#define __constraint_read_4 "r" (r4)
+#define __constraint_read_5 __constraint_read_4, "r" (r5)
+#define __constraint_read_6 __constraint_read_5, "r" (r6)
+#define __constraint_read_7 __constraint_read_6, "r" (r7)
+
+#define __declare_arg_0(a0, res)\
+struct arm_smccc_res*___res = res;  \
+register uin32_tr0 asm("r0") = a0;  \
+register unsigned long  r1 asm("r1");   \
+register unsigned long  r2 asm("r2");   \
+register unsigned long  r3 asm("r3")
+
+#define __declare_arg_1(a0, a1, res)\
+struct arm_smccc_res*___res = res;  \
+register uint32_t   r0 asm("r0") = a0;  \
+register typeof(a1) r1 asm("r1") = a1;  \
+register unsigned long  r2 asm("r2");   \
+register unsigned long  r3 asm("r3")
+
+#define __declare_arg_2(a0, a1, a2, res)\
+struct arm_smccc_res*___res = res; \
+register u32r0 asm("r0") = a0;  \
+register typeof(a1) r1 asm("r1") = a1;  \
+register typeof(a2) r2 asm("r2") = a2;  \
+register unsigned long  r3 asm("r3")
+
+#define __declare_arg_3(a0, a1, a2, a3, res)\
+struct arm_smccc_res*___res = res;  \
+register u32r0 asm("r0") = a0;  \
+register typeof(a1) r1 asm("r1") = a1;  \
+register typeof(a2) r2 asm("r2") = a2;  \
+register typeof(a3) r3 asm("r3") = a3
+
+#define __declare_arg_4(a0, a1, a2, a3, a4, res)\
+__declare_arg_3(a0, a1, a2, a3, res);   \
+register typeof(a4) r4 asm("r4") = a4
+
+#define __declare_arg_5(a0, a1, a2, a3, a4, a5, res)\
+__declare_arg_4(a0, a1, a2, a3, a4, res);   \
+register typeof(a5) r5 asm("r5") = a5
+
+#define __declare_arg_6(a0, a1, a2, a3, a4, a5, a6, res)\
+__declare_arg_5(a0, a1, a2, a3, a4, a5, res);   \
+register typeof(a6) r6 asm("r6") = a6
+
+#define __declare_arg_7(a0, a1, a2, a3, a4, a5, a6, a7, res)\
+__declare_arg_6(a0, a1, a2, a3, a4, a5, a6, res);   \
+register typeof(a7) r7 asm("r7") = a7
+
+#define ___declare_args(count, ...) __declare_arg_ ## 

[Xen-devel] [PATCH v5 04/18] xen/arm: vsmc: Implement SMCCC_ARCH_WORKAROUND_1 BP hardening support

[Julien Grall]

SMCCC 1.1 offers firmware-based CPU workarounds. In particular,
SMCCC_ARCH_WORKAROUND_1 provides BP hardening for variant 2 of XSA-254
(CVE-2017-5715).

If the hypervisor has some mitigation for this issue, report that we
deal with it using SMCCC_ARCH_WORKAROUND_1, as we apply the hypervisor
workaround on every guest exit.

Signed-off-by: Julien Grall 
Reviewed-by: Volodymyr Babchuk 
Acked-by: Stefano Stabellini 
Reviewed-by: Andre Przywara 

---
Changes in v4:
- Add Stefano's acked-by
- Add Andre's reviewed-by

Changes in v3:
- Fix minor conflict during rebase

Changes in v2:
- Add Volodymyr's reviewed-by
---
 xen/arch/arm/vsmc.c | 22 --
 xen/include/asm-arm/smccc.h |  6 ++
 2 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
index 7ec492741b..40a80d5760 100644
--- a/xen/arch/arm/vsmc.c
+++ b/xen/arch/arm/vsmc.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -93,8 +94,25 @@ static bool handle_arch(struct cpu_user_regs *regs)
 return true;
 
 case ARM_SMCCC_ARCH_FEATURES_FID:
-/* Nothing supported yet */
-set_user_reg(regs, 0, ARM_SMCCC_NOT_SUPPORTED);
+{
+uint32_t arch_func_id = get_user_reg(regs, 1);
+int ret = ARM_SMCCC_NOT_SUPPORTED;
+
+switch ( arch_func_id )
+{
+case ARM_SMCCC_ARCH_WORKAROUND_1_FID:
+if ( cpus_have_cap(ARM_HARDEN_BRANCH_PREDICTOR) )
+ret = 0;
+break;
+}
+
+set_user_reg(regs, 0, ret);
+
+return true;
+}
+
+case ARM_SMCCC_ARCH_WORKAROUND_1_FID:
+/* No return value */
 return true;
 }
 
diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h
index 629cc5150b..2951caa49d 100644
--- a/xen/include/asm-arm/smccc.h
+++ b/xen/include/asm-arm/smccc.h
@@ -115,6 +115,12 @@ static inline uint32_t smccc_get_owner(register_t funcid)
ARM_SMCCC_OWNER_ARCH,\
0x1)
 
+#define ARM_SMCCC_ARCH_WORKAROUND_1_FID \
+ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+  ARM_SMCCC_CONV_32,\
+  ARM_SMCCC_OWNER_ARCH, \
+  0x8000)
+
 /* SMCCC error codes */
 #define ARM_SMCCC_ERR_UNKNOWN_FUNCTION  (-1)
 #define ARM_SMCCC_NOT_SUPPORTED (-1)
-- 
2.11.0


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

[Xen-devel] [PATCH v5 02/18] xen/arm: vpsci: Add support for PSCI 1.1

[Julien Grall]

At the moment, Xen provides virtual PSCI interface compliant with 0.1
and 0.2. Since them, the specification has been updated and the latest
version is 1.1 (see ARM DEN 0022D).

From an implementation point of view, only PSCI_FEATURES is mandatory.
The rest is optional and can be left unimplemented for now.

At the same time, the compatible for PSCI node have been updated to
expose "arm,psci-1.0".

Signed-off-by: Julien Grall 
Acked-by: Wei Liu 
Reviewed-by: Volodymyr Babchuk 
Acked-by: Stefano Stabellini 
Cc: Ian Jackson 
Cc: mirela.simono...@aggios.com

---
We may want to provide a way for the toolstack to specify a PSCI
version. This could be useful if a guest is expecting a given
version.

Changes in v4:
- Add Stefano's acked-by

Changes in v3:
- Add Wei's acked-by
- Add Volodymyr's reviewed-by

Changes in v2:
- Return v1.1 on GET_VERSION call as claimed by this patch
- Order by function ID the calls in FEATURES call
---
 tools/libxl/libxl_arm.c  |  3 ++-
 xen/arch/arm/domain_build.c  |  1 +
 xen/arch/arm/vpsci.c | 39 ++-
 xen/include/asm-arm/perfc_defn.h |  1 +
 xen/include/asm-arm/psci.h   |  1 +
 xen/include/asm-arm/vpsci.h  |  2 +-
 6 files changed, 44 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index 3e46554301..86f59c0d80 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -410,7 +410,8 @@ static int make_psci_node(libxl__gc *gc, void *fdt)
 res = fdt_begin_node(fdt, "psci");
 if (res) return res;
 
-res = fdt_property_compat(gc, fdt, 2, "arm,psci-0.2","arm,psci");
+res = fdt_property_compat(gc, fdt, 3, "arm,psci-1.0",
+  "arm,psci-0.2", "arm,psci");
 if (res) return res;
 
 res = fdt_property_string(fdt, "method", "hvc");
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 155c952349..941688a2ce 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -637,6 +637,7 @@ static int make_psci_node(void *fdt, const struct 
dt_device_node *parent)
 {
 int res;
 const char compat[] =
+"arm,psci-1.0""\0"
 "arm,psci-0.2""\0"
 "arm,psci";
 
diff --git a/xen/arch/arm/vpsci.c b/xen/arch/arm/vpsci.c
index 6ab8ab64d0..e82b62db1a 100644
--- a/xen/arch/arm/vpsci.c
+++ b/xen/arch/arm/vpsci.c
@@ -106,7 +106,11 @@ static int32_t do_psci_cpu_off(uint32_t power_state)
 
 static uint32_t do_psci_0_2_version(void)
 {
-return PSCI_VERSION(0, 2);
+/*
+ * PSCI is backward compatible from 0.2. So we can bump the version
+ * without any issue.
+ */
+return PSCI_VERSION(1, 1);
 }
 
 static register_t do_psci_0_2_cpu_suspend(uint32_t power_state,
@@ -191,6 +195,29 @@ static void do_psci_0_2_system_reset(void)
 domain_shutdown(d,SHUTDOWN_reboot);
 }
 
+static int32_t do_psci_1_0_features(uint32_t psci_func_id)
+{
+/* /!\ Ordered by function ID and not name */
+switch ( psci_func_id )
+{
+case PSCI_0_2_FN32_PSCI_VERSION:
+case PSCI_0_2_FN32_CPU_SUSPEND:
+case PSCI_0_2_FN64_CPU_SUSPEND:
+case PSCI_0_2_FN32_CPU_OFF:
+case PSCI_0_2_FN32_CPU_ON:
+case PSCI_0_2_FN64_CPU_ON:
+case PSCI_0_2_FN32_AFFINITY_INFO:
+case PSCI_0_2_FN64_AFFINITY_INFO:
+case PSCI_0_2_FN32_MIGRATE_INFO_TYPE:
+case PSCI_0_2_FN32_SYSTEM_OFF:
+case PSCI_0_2_FN32_SYSTEM_RESET:
+case PSCI_1_0_FN32_PSCI_FEATURES:
+return 0;
+default:
+return PSCI_NOT_SUPPORTED;
+}
+}
+
 #define PSCI_SET_RESULT(reg, val) set_user_reg(reg, 0, val)
 #define PSCI_ARG(reg, n) get_user_reg(reg, n)
 
@@ -304,6 +331,16 @@ bool do_vpsci_0_2_call(struct cpu_user_regs *regs, 
uint32_t fid)
 PSCI_SET_RESULT(regs, do_psci_0_2_affinity_info(taff, laff));
 return true;
 }
+
+case PSCI_1_0_FN32_PSCI_FEATURES:
+{
+uint32_t psci_func_id = PSCI_ARG32(regs, 1);
+
+perfc_incr(vpsci_features);
+PSCI_SET_RESULT(regs, do_psci_1_0_features(psci_func_id));
+return true;
+}
+
 default:
 return false;
 }
diff --git a/xen/include/asm-arm/perfc_defn.h b/xen/include/asm-arm/perfc_defn.h
index a7acb7d21c..87866264ca 100644
--- a/xen/include/asm-arm/perfc_defn.h
+++ b/xen/include/asm-arm/perfc_defn.h
@@ -31,6 +31,7 @@ PERFCOUNTER(vpsci_system_off,  "vpsci: system_off")
 PERFCOUNTER(vpsci_system_reset,"vpsci: system_reset")
 PERFCOUNTER(vpsci_cpu_suspend, "vpsci: cpu_suspend")
 PERFCOUNTER(vpsci_cpu_affinity_info,   "vpsci: cpu_affinity_info")
+PERFCOUNTER(vpsci_features,"vpsci: features")
 
 PERFCOUNTER(vgicd_reads,"vgicd: read")
 PERFCOUNTER(vgicd_writes,   "vgicd: write")
diff --git a/xen/include/asm-arm/psci.h 

Re: [Xen-devel] [PATCH v4 11/19] xen/arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support

[Julien Grall]

On 23/02/18 18:18, Volodymyr Babchuk wrote:

Hi Julien,


Hi Volodymyr,


On 23.02.18 18:47, Julien Grall wrote:

Add the detection and runtime code for ARM_SMCCC_ARCH_WORKAROUND_1.

Signed-off-by: Julien Grall 

---
 Changes in v4:
 - Re-order saving/restoring registers in
   __smccc_workaround_1_smc_start
Looks like you missed to run --autosquash, so the real change is in the 
next patch.


Whoops yes. Thank you for spotting it. I will resend the version.

Cheers,



 Changes in v3:
 - Add the missing call to smc #0.

 Changes in v2:
 - Patch added
---
  xen/arch/arm/arm64/bpi.S    | 13 +
  xen/arch/arm/cpuerrata.c    | 32 +++-
  xen/include/asm-arm/smccc.h |  1 +
  3 files changed, 45 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/arm64/bpi.S b/xen/arch/arm/arm64/bpi.S
index 4b7f1dc21f..981fb83a88 100644
--- a/xen/arch/arm/arm64/bpi.S
+++ b/xen/arch/arm/arm64/bpi.S
@@ -16,6 +16,8 @@
   * along with this program.  If not, see 
.

   */
+#include 
+
  .macro ventry target
  .rept 31
  nop
@@ -81,6 +83,17 @@ ENTRY(__psci_hyp_bp_inval_start)
  add sp, sp, #(8 * 18)
  ENTRY(__psci_hyp_bp_inval_end)
+ENTRY(__smccc_workaround_1_smc_start)
+    sub sp, sp, #(8 * 4)
+    stp x2, x3, [sp, #(8 * 0)]
+    stp x0, x1, [sp, #(8 * 2)]
+    mov w0, #ARM_SMCCC_ARCH_WORKAROUND_1_FID
+    smc #0
+    ldp x2, x3, [sp, #(8 * 0)]
+    ldp x0, x1, [sp, #(8 * 2)]
+    add sp, sp, #(8 * 4)
+ENTRY(__smccc_workaround_1_smc_end)
+
  /*
   * Local variables:
   * mode: ASM
diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index 8d5f8d372a..dec9074422 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -147,6 +147,34 @@ install_bp_hardening_vec(const struct 
arm_cpu_capabilities *entry,

  return ret;
  }
+extern char __smccc_workaround_1_smc_start[], 
__smccc_workaround_1_smc_end[];

+
+static bool
+check_smccc_arch_workaround_1(const struct arm_cpu_capabilities *entry)
+{
+    struct arm_smccc_res res;
+
+    /*
+ * Enable callbacks are called on every CPU based on the
+ * capabilities. So double-check whether the CPU matches the
+ * entry.
+ */
+    if ( !entry->matches(entry) )
+    return false;
+
+    if ( smccc_ver < SMCCC_VERSION(1, 1) )
+    return false;
+
+    arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID,
+  ARM_SMCCC_ARCH_WORKAROUND_1_FID, );
+    if ( res.a0 != ARM_SMCCC_SUCCESS )
+    return false;
+
+    return 
install_bp_hardening_vec(entry,__smccc_workaround_1_smc_start,

+    __smccc_workaround_1_smc_end,
+    "call ARM_SMCCC_ARCH_WORKAROUND_1");
+}
+
  extern char __psci_hyp_bp_inval_start[], __psci_hyp_bp_inval_end[];
  static int enable_psci_bp_hardening(void *data)
@@ -154,12 +182,14 @@ static int enable_psci_bp_hardening(void *data)
  bool ret = true;
  static bool warned = false;
+    if ( check_smccc_arch_workaround_1(data) )
+    return 0;
  /*
   * The mitigation is using PSCI version function to invalidate the
   * branch predictor. This function is only available with PSCI 0.2
   * and later.
   */
-    if ( psci_ver >= PSCI_VERSION(0, 2) )
+    else if ( psci_ver >= PSCI_VERSION(0, 2) )
  ret = install_bp_hardening_vec(data, __psci_hyp_bp_inval_start,
 __psci_hyp_bp_inval_end,
 "call PSCI get version");
diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h
index 154772b728..8342cc33fe 100644
--- a/xen/include/asm-arm/smccc.h
+++ b/xen/include/asm-arm/smccc.h
@@ -261,6 +261,7 @@ struct arm_smccc_res {
  /* SMCCC error codes */
  #define ARM_SMCCC_ERR_UNKNOWN_FUNCTION  (-1)
  #define ARM_SMCCC_NOT_SUPPORTED (-1)
+#define ARM_SMCCC_SUCCESS   (0)
  /* SMCCC function identifier range which is reserved for existing 
APIs */

  #define ARM_SMCCC_RESERVED_RANGE_START  0x0





--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 3/5] tools: libxl/xl: allow to get/set Credit1's vcpu_migration_delay

[Wei Liu]

On Fri, Feb 23, 2018 at 05:41:48PM +0100, Dario Faggioli wrote:
> Make it possible to get and set a (Credit1) scheduler's
> vCPU migration delay via the SCHEDOP sysctl, from both
> libxl and xl (no change needed in libxc).
> 
> Signed-off-by: Dario Faggioli 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH] libxl: do not fail device removal if backend domain is gone

[Wei Liu]

On Fri, Feb 09, 2018 at 12:22:13AM +0100, Marek Marczykowski-Górecki wrote:
> Backend domain may be independently destroyed - there is no
> synchronization of libxl structures (including /libxl tree) elsewhere.
> Backend might also remove the device info from its backend xenstore
> subtree on its own.
> If such situation is detected, do not fail the removal, but finish the
> cleanup of the frontend side.
> 
> This is just workaround, the real fix should watch when the device
> backend is removed (including backend domain destruction) and remove
> frontend at that time. And report such event to higher layer code, so
> for example libvirt could synchronize its state.
> 
> Signed-off-by: Marek Marczykowski-Górecki 

Acked-by: Wei Liu 

Can you please resend with commit message updated, thanks.

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

Re: [Xen-devel] [PATCH] libxl: allow libxl_domain_suspend to simply suspend a domain, without saving it

[Wei Liu]

On Fri, Feb 09, 2018 at 12:14:03AM +0100, Marek Marczykowski-Górecki wrote:
> When fd=-1, no savefile will be written, but the domain will still be
> suspended (but not destroyed). The main reason for this functionality is
> to suspend the host while some domains are running, potentially holding
> PCI devices. This will give a chance to a driver in such a domain to
> properly suspend device.
> 
> It would be better to have separate function for this, but in fact it
> should be named libxl_domain_suspend, then the current one renamed to
> libxl_domain_save. Since that would break API compatibility, keep it in
> the same function.
> 
> Signed-off-by: Marek Marczykowski-Górecki 
> Signed-off-by: Marcus of Wetware Labs 

The basic idea seems sensible.

Please add a comment to libxl.h to specify the new semantics.

Wei.

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

Re: [Xen-devel] libxl - avoid calling block script

[Wei Liu]

On Fri, Feb 09, 2018 at 12:35:13PM +0100, Marek Marczykowski-Górecki wrote:
> On Fri, Feb 09, 2018 at 11:03:55AM +, Roger Pau Monné wrote:
> > Really adding Ian and Wei.
> > 
> > On Fri, Feb 09, 2018 at 10:55:24AM +, Roger Pau Monné wrote:
> > > So the problem is creation time for domains that have quite a lot of
> > > disks attached. Adding Ian and Wei who know more about the async
> > > dispatch system, but I think (at least from a technical PoV) it
> > > should be possible to parallelize device attachment and thus hotplug
> > > script execution. Devices are independent from each other.
> 
> In theory yes, but in practice block script (at least on Linux) takes a
> lock and serialize execution...
> 
> > > Also the Linux hotplug scripts in general seem extremely convoluted,
> > > I'm not sure whether we could gain some speed there just by
> > > simplification.
> 
> Well, we're comparing a bunch of fork+exec(), including starting bash
> (default /bin/sh on most systems), with just a single stat() call...
> Handling scripts in libxl itself also takes some time (in my case libxl
> live in libvirt, which may or may not have an impact). For a domU with
> 4 disks, getting rid of hotplug scripts saved about 2s of startup time.
> 

Sorry for the late reply.

If you really don't want block scripts, can you not specify a script
that only does "exit 0"? That seems to be easier than modifying libxl
and it is also useable in older versions of Xen.

Wei.

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

Re: [Xen-devel] [PATCH] libxl: set channel devid when not provided by application

[Wei Liu]

On Wed, Feb 07, 2018 at 08:04:10PM -0700, Jim Fehlig wrote:
> Applications like libvirt may not populate a device devid field,
> delegating that to libxl. If needed, the application can later
> retrieve the libxl-produced devid. Indeed most devices are handled
> this way in libvirt, channel devices included.
> 
> This works well when only one channel device is defined, but more
> than one results in
> 
> qemu-system-i386: -chardev socket,id=libxl-channel-1,\
> path=/tmp/test-org.qemu.guest_agent.00,server,nowait:
> Duplicate ID 'libxl-channel-1' for chardev
> 
> Besides the odd '-1' value in the id, multiple channels have the same
> id, causing qemu to fail. A simple fix is to set an uninitialized
> devid (-1) to the dev_num passed to libxl__init_console_from_channel().
> 
> Signed-off-by: Jim Fehlig 
> ---
> 
> I get the feeling that if needed devid should be set earlier, but
> this seems like the most opportune spot. Suggestions for improvements
> welcome.

I think this approach is fine.

Wei.

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

Re: [Xen-devel] [PATCH v4 11/19] xen/arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support

[Volodymyr Babchuk]

Hi Julien,

On 23.02.18 18:47, Julien Grall wrote:

Add the detection and runtime code for ARM_SMCCC_ARCH_WORKAROUND_1.

Signed-off-by: Julien Grall 

---
 Changes in v4:
 - Re-order saving/restoring registers in
   __smccc_workaround_1_smc_start
Looks like you missed to run --autosquash, so the real change is in the 
next patch.


 Changes in v3:
 - Add the missing call to smc #0.

 Changes in v2:
 - Patch added
---
  xen/arch/arm/arm64/bpi.S| 13 +
  xen/arch/arm/cpuerrata.c| 32 +++-
  xen/include/asm-arm/smccc.h |  1 +
  3 files changed, 45 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/arm64/bpi.S b/xen/arch/arm/arm64/bpi.S
index 4b7f1dc21f..981fb83a88 100644
--- a/xen/arch/arm/arm64/bpi.S
+++ b/xen/arch/arm/arm64/bpi.S
@@ -16,6 +16,8 @@
   * along with this program.  If not, see .
   */
  
+#include 

+
  .macro ventry target
  .rept 31
  nop
@@ -81,6 +83,17 @@ ENTRY(__psci_hyp_bp_inval_start)
  add sp, sp, #(8 * 18)
  ENTRY(__psci_hyp_bp_inval_end)
  
+ENTRY(__smccc_workaround_1_smc_start)

+sub sp, sp, #(8 * 4)
+stp x2, x3, [sp, #(8 * 0)]
+stp x0, x1, [sp, #(8 * 2)]
+mov w0, #ARM_SMCCC_ARCH_WORKAROUND_1_FID
+smc #0
+ldp x2, x3, [sp, #(8 * 0)]
+ldp x0, x1, [sp, #(8 * 2)]
+add sp, sp, #(8 * 4)
+ENTRY(__smccc_workaround_1_smc_end)
+
  /*
   * Local variables:
   * mode: ASM
diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index 8d5f8d372a..dec9074422 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -147,6 +147,34 @@ install_bp_hardening_vec(const struct arm_cpu_capabilities 
*entry,
  return ret;
  }
  
+extern char __smccc_workaround_1_smc_start[], __smccc_workaround_1_smc_end[];

+
+static bool
+check_smccc_arch_workaround_1(const struct arm_cpu_capabilities *entry)
+{
+struct arm_smccc_res res;
+
+/*
+ * Enable callbacks are called on every CPU based on the
+ * capabilities. So double-check whether the CPU matches the
+ * entry.
+ */
+if ( !entry->matches(entry) )
+return false;
+
+if ( smccc_ver < SMCCC_VERSION(1, 1) )
+return false;
+
+arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID,
+  ARM_SMCCC_ARCH_WORKAROUND_1_FID, );
+if ( res.a0 != ARM_SMCCC_SUCCESS )
+return false;
+
+return install_bp_hardening_vec(entry,__smccc_workaround_1_smc_start,
+__smccc_workaround_1_smc_end,
+"call ARM_SMCCC_ARCH_WORKAROUND_1");
+}
+
  extern char __psci_hyp_bp_inval_start[], __psci_hyp_bp_inval_end[];
  
  static int enable_psci_bp_hardening(void *data)

@@ -154,12 +182,14 @@ static int enable_psci_bp_hardening(void *data)
  bool ret = true;
  static bool warned = false;
  
+if ( check_smccc_arch_workaround_1(data) )

+return 0;
  /*
   * The mitigation is using PSCI version function to invalidate the
   * branch predictor. This function is only available with PSCI 0.2
   * and later.
   */
-if ( psci_ver >= PSCI_VERSION(0, 2) )
+else if ( psci_ver >= PSCI_VERSION(0, 2) )
  ret = install_bp_hardening_vec(data, __psci_hyp_bp_inval_start,
 __psci_hyp_bp_inval_end,
 "call PSCI get version");
diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h
index 154772b728..8342cc33fe 100644
--- a/xen/include/asm-arm/smccc.h
+++ b/xen/include/asm-arm/smccc.h
@@ -261,6 +261,7 @@ struct arm_smccc_res {
  /* SMCCC error codes */
  #define ARM_SMCCC_ERR_UNKNOWN_FUNCTION  (-1)
  #define ARM_SMCCC_NOT_SUPPORTED (-1)
+#define ARM_SMCCC_SUCCESS   (0)
  
  /* SMCCC function identifier range which is reserved for existing APIs */

  #define ARM_SMCCC_RESERVED_RANGE_START  0x0



--
Volodymyr Babchuk

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

Re: [Xen-devel] [RFC PATCH 38/49] ARM: new VGIC: handle hardware mapped IRQs

[Julien Grall]

On 23/02/18 18:02, Andre Przywara wrote:

Hi,


Hi Andre,


On 19/02/18 12:19, Julien Grall wrote:

Hi,

On 09/02/18 14:39, Andre Przywara wrote:

The VGIC supports virtual IRQs to be connected to a hardware IRQ, so
when a guest EOIs the virtual interrupt, it affects the state of that
corresponding interrupt on the hardware side at the same time.
Implement the interface that the Xen arch/core code expects to connect
the virtual and the physical world.

Signed-off-by: Andre Przywara 
---
   xen/arch/arm/vgic/vgic.c | 63

   1 file changed, 63 insertions(+)

diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
index dc5e011fa3..8d5260a7db 100644
--- a/xen/arch/arm/vgic/vgic.c
+++ b/xen/arch/arm/vgic/vgic.c
@@ -693,6 +693,69 @@ void vgic_kick_vcpus(struct domain *d)
   }
   }
   +struct irq_desc *vgic_get_hw_irq_desc(struct domain *d, struct vcpu
*v,
+  unsigned int virq)
+{
+    struct irq_desc *desc = NULL;
+    struct vgic_irq *irq = vgic_get_irq(d, v, virq);
+    unsigned long flags;
+
+    if ( !irq )
+    return NULL;
+
+    spin_lock_irqsave(>irq_lock, flags);
+    if ( irq->hw )
+    desc = irq_to_desc(irq->hwintid);


This is not going to work well for PPIs. We should consider to add at
least an ASSERT(...) in the code to prevent bad use of it.


Yeah, done. But I wonder if we eventually should extend the
irq_to_desc() function to take the vCPU, since we will need it anyway
once we use hardware mapped timer IRQs (PPIs) in the future. But this
should not be in this series, I guess.


irq_to_desc only deal with hardware interrupt, so you mean pCPU instead 
of vCPU?





+    spin_unlock_irqrestore(>irq_lock, flags);
+
+    vgic_put_irq(d, irq);
+
+    return desc;
+}
+
+/*
+ * was:
+ *  int kvm_vgic_map_phys_irq(struct vcpu *vcpu, u32 virt_irq,
u32 phys_irq)
+ *  int kvm_vgic_unmap_phys_irq(struct vcpu *vcpu, unsigned int
virt_irq)
+ */
+int vgic_connect_hw_irq(struct domain *d, struct vcpu *vcpu,
+    unsigned int virt_irq, struct irq_desc *desc,
+    bool connect)


Indentation.


+{
+    struct vgic_irq *irq = vgic_get_irq(d, vcpu, virt_irq);
+    unsigned long flags;
+    int ret = 0;
+
+    if ( !irq )
+    return -EINVAL;
+
+    spin_lock_irqsave(>irq_lock, flags);
+
+    if ( connect )  /* assign a mapped IRQ */
+    {
+    /* The VIRQ should not be already enabled by the guest */
+    if ( !irq->hw && !irq->enabled )
+    {
+    irq->hw = true;
+    irq->hwintid = desc->irq;
+    }
+    else
+    {
+    ret = -EBUSY;
+    }


I know that it should not matter for SPIs today. But aren't you meant to
get a reference on that interrupt if you connect it?


No, the refcount feature is strictly for the pointer to the structure,
not for everything related to this virtual IRQ.
We store only the virtual IRQ number in the dev_id/info members, we will
get the struct vgic_irq pointer via the vIRQ number on do_IRQ().
Does that make sense?


But technically you "allocate" the virtual SPI at that time, right? So 
this would mean you need to get a reference, otherwise it might disappear.


So I am not entirely sure why the reference is not necessary here.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [RFC Patch v4 8/8] x86/hvm: bump the maximum number of vcpus to 512

[Roger Pau Monné]

On Wed, Dec 06, 2017 at 03:50:14PM +0800, Chao Gao wrote:
> Signed-off-by: Chao Gao 
> ---
>  xen/include/public/hvm/hvm_info_table.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xen/include/public/hvm/hvm_info_table.h 
> b/xen/include/public/hvm/hvm_info_table.h
> index 08c252e..6833a4c 100644
> --- a/xen/include/public/hvm/hvm_info_table.h
> +++ b/xen/include/public/hvm/hvm_info_table.h
> @@ -32,7 +32,7 @@
>  #define HVM_INFO_PADDR   ((HVM_INFO_PFN << 12) + HVM_INFO_OFFSET)
>  
>  /* Maximum we can support with current vLAPIC ID mapping. */
> -#define HVM_MAX_VCPUS128
> +#define HVM_MAX_VCPUS512

Wow, that looks like a pretty big jump. I certainly don't have access
to any box with this number of vCPUs, so that's going to be quite hard
to test. What the reasoning behind this bump? Is hardware with 512
ways expected soon-ish?

Also osstest is not even able to test the current limit, so I would
maybe bump this to 256, but as I expressed in other occasions I don't
feel comfortable with have a number of vCPUs that the current test
system doesn't have hardware to test with.

Thanks, Roger.

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

Re: [Xen-devel] [PATCH v4 12/16] xen/mm: Switch common/memory.c to use typesafe MFN

[Wei Liu]

On Fri, Feb 23, 2018 at 06:06:55PM +, Julien Grall wrote:
> Hi,
> 
> On 23/02/18 18:05, Wei Liu wrote:
> > On Fri, Feb 23, 2018 at 05:46:39PM +, Julien Grall wrote:
> > > 
> > > 
> > > On 23/02/18 17:26, Wei Liu wrote:
> > > > On Wed, Feb 21, 2018 at 02:02:55PM +, Julien Grall wrote:
> > > > > A new helper copy_mfn_to_guest is introduced to easily to copy a MFN 
> > > > > to
> > > > > the guest memory.
> > > > > 
> > > > > Not functional change intended
> > > > 
> > > > Is there a reason to not make all guest accessors tyep-safe instead?
> > > 
> > > Could you clarify what you mean? MFN and xen_pfn_t have different type on
> > > Arm. So I am not sure how you would be able to make them typesafe.
> > 
> > What I meant was to make copy_{to,from}_guest* type-safe. I just feel it
> > a bit strange you only created a wrapper for this file. I wonder why.
> 
> Oh, I can have a look at that.
> 

Before you do any real work please wait for other people to comment.

I haven't entirely convinced myself it is a good idea. ;-)

Wei.

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

Re: [Xen-devel] [PATCH v4 12/16] xen/mm: Switch common/memory.c to use typesafe MFN

[Julien Grall]

Hi,

On 23/02/18 18:05, Wei Liu wrote:

On Fri, Feb 23, 2018 at 05:46:39PM +, Julien Grall wrote:



On 23/02/18 17:26, Wei Liu wrote:

On Wed, Feb 21, 2018 at 02:02:55PM +, Julien Grall wrote:

A new helper copy_mfn_to_guest is introduced to easily to copy a MFN to
the guest memory.

Not functional change intended


Is there a reason to not make all guest accessors tyep-safe instead?


Could you clarify what you mean? MFN and xen_pfn_t have different type on
Arm. So I am not sure how you would be able to make them typesafe.


What I meant was to make copy_{to,from}_guest* type-safe. I just feel it
a bit strange you only created a wrapper for this file. I wonder why.


Oh, I can have a look at that.



Note I'm just asking question. That's not necessarily a good idea to
turn them all in the end.


Cheers,


--
Julien Grall

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

Re: [Xen-devel] [PATCH v4 12/16] xen/mm: Switch common/memory.c to use typesafe MFN

[Wei Liu]

On Fri, Feb 23, 2018 at 05:46:39PM +, Julien Grall wrote:
> 
> 
> On 23/02/18 17:26, Wei Liu wrote:
> > On Wed, Feb 21, 2018 at 02:02:55PM +, Julien Grall wrote:
> > > A new helper copy_mfn_to_guest is introduced to easily to copy a MFN to
> > > the guest memory.
> > > 
> > > Not functional change intended
> > 
> > Is there a reason to not make all guest accessors tyep-safe instead?
> 
> Could you clarify what you mean? MFN and xen_pfn_t have different type on
> Arm. So I am not sure how you would be able to make them typesafe.

What I meant was to make copy_{to,from}_guest* type-safe. I just feel it
a bit strange you only created a wrapper for this file. I wonder why.

Note I'm just asking question. That's not necessarily a good idea to
turn them all in the end.

Wei.

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

Re: [Xen-devel] [RFC PATCH 38/49] ARM: new VGIC: handle hardware mapped IRQs

[Andre Przywara]

Hi,

On 19/02/18 12:19, Julien Grall wrote:
> Hi,
> 
> On 09/02/18 14:39, Andre Przywara wrote:
>> The VGIC supports virtual IRQs to be connected to a hardware IRQ, so
>> when a guest EOIs the virtual interrupt, it affects the state of that
>> corresponding interrupt on the hardware side at the same time.
>> Implement the interface that the Xen arch/core code expects to connect
>> the virtual and the physical world.
>>
>> Signed-off-by: Andre Przywara 
>> ---
>>   xen/arch/arm/vgic/vgic.c | 63
>> 
>>   1 file changed, 63 insertions(+)
>>
>> diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
>> index dc5e011fa3..8d5260a7db 100644
>> --- a/xen/arch/arm/vgic/vgic.c
>> +++ b/xen/arch/arm/vgic/vgic.c
>> @@ -693,6 +693,69 @@ void vgic_kick_vcpus(struct domain *d)
>>   }
>>   }
>>   +struct irq_desc *vgic_get_hw_irq_desc(struct domain *d, struct vcpu
>> *v,
>> +  unsigned int virq)
>> +{
>> +    struct irq_desc *desc = NULL;
>> +    struct vgic_irq *irq = vgic_get_irq(d, v, virq);
>> +    unsigned long flags;
>> +
>> +    if ( !irq )
>> +    return NULL;
>> +
>> +    spin_lock_irqsave(>irq_lock, flags);
>> +    if ( irq->hw )
>> +    desc = irq_to_desc(irq->hwintid);
> 
> This is not going to work well for PPIs. We should consider to add at
> least an ASSERT(...) in the code to prevent bad use of it.

Yeah, done. But I wonder if we eventually should extend the
irq_to_desc() function to take the vCPU, since we will need it anyway
once we use hardware mapped timer IRQs (PPIs) in the future. But this
should not be in this series, I guess.

>> +    spin_unlock_irqrestore(>irq_lock, flags);
>> +
>> +    vgic_put_irq(d, irq);
>> +
>> +    return desc;
>> +}
>> +
>> +/*
>> + * was:
>> + *  int kvm_vgic_map_phys_irq(struct vcpu *vcpu, u32 virt_irq,
>> u32 phys_irq)
>> + *  int kvm_vgic_unmap_phys_irq(struct vcpu *vcpu, unsigned int
>> virt_irq)
>> + */
>> +int vgic_connect_hw_irq(struct domain *d, struct vcpu *vcpu,
>> +    unsigned int virt_irq, struct irq_desc *desc,
>> +    bool connect)
> 
> Indentation.
> 
>> +{
>> +    struct vgic_irq *irq = vgic_get_irq(d, vcpu, virt_irq);
>> +    unsigned long flags;
>> +    int ret = 0;
>> +
>> +    if ( !irq )
>> +    return -EINVAL;
>> +
>> +    spin_lock_irqsave(>irq_lock, flags);
>> +
>> +    if ( connect )  /* assign a mapped IRQ */
>> +    {
>> +    /* The VIRQ should not be already enabled by the guest */
>> +    if ( !irq->hw && !irq->enabled )
>> +    {
>> +    irq->hw = true;
>> +    irq->hwintid = desc->irq;
>> +    }
>> +    else
>> +    {
>> +    ret = -EBUSY;
>> +    }
> 
> I know that it should not matter for SPIs today. But aren't you meant to
> get a reference on that interrupt if you connect it?

No, the refcount feature is strictly for the pointer to the structure,
not for everything related to this virtual IRQ.
We store only the virtual IRQ number in the dev_id/info members, we will
get the struct vgic_irq pointer via the vIRQ number on do_IRQ().
Does that make sense?

>> +    }
>> +    else    /* remove a mapped IRQ */
>> +    {
>> +    irq->hw = false;
>> +    irq->hwintid = 0;
> 
> Here you blindly remove the interrupt without been sure it was the
> correct physical one. We should have a check like in the current vGIC
> version.

Fixed.

Cheers,
Andre.

>> +    }
>> +
>> +    spin_unlock_irqrestore(>irq_lock, flags);
>> +    vgic_put_irq(d, irq);
>> +
>> +    return ret;
>> +}
>> +
>>   /*
>>    * Local variables:
>>    * mode: C
>>
> 
> Cheers,
> 

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

Re: [Xen-devel] [PATCH v2] x86/mm: Suppresses vm_events caused by page-walks

[Wei Liu]

On Mon, Jan 08, 2018 at 02:49:44PM +0200, Alexandru Isaila wrote:
> This patch is adding a way to enable/disable nested pagefault
> events. It introduces the xc_monitor_nested_pagefault function
> and adds the nested_pagefault_disabled in the monitor structure.
> This is needed by the introspection so it will only get gla
> faults and not get spammed with other faults.
> In p2m_set_ad_bits the v->arch.sse_pg_dirty.eip and
> v->arch.sse_pg_dirty.gla are used to mark that this is the
> second time a fault occurs and the dirty bit is set.
> 
> Signed-off-by: Alexandru Isaila 
> 
> ---
> Changes since V1:
> - Rb V1
>   - Add comment in domctl.h
> ---
>  tools/libxc/include/xenctrl.h |  2 ++
>  tools/libxc/xc_monitor.c  | 14 ++

These changes look sensible to me.

>  xen/arch/x86/mm/mem_access.c  | 27 +++
>  xen/arch/x86/monitor.c| 13 +
>  xen/include/asm-x86/domain.h  |  6 ++
>  xen/include/asm-x86/monitor.h |  3 ++-
>  xen/include/public/domctl.h   |  2 ++

You might want to bump domctl version number it is has been done already
in this release.

Wei.

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

Re: [Xen-devel] [PATCH v4 12/16] xen/mm: Switch common/memory.c to use typesafe MFN

[Julien Grall]

On 23/02/18 17:26, Wei Liu wrote:

On Wed, Feb 21, 2018 at 02:02:55PM +, Julien Grall wrote:

A new helper copy_mfn_to_guest is introduced to easily to copy a MFN to
the guest memory.

Not functional change intended


Is there a reason to not make all guest accessors tyep-safe instead?


Could you clarify what you mean? MFN and xen_pfn_t have different type 
on Arm. So I am not sure how you would be able to make them typesafe.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v8 01/11] vpci: introduce basic handlers to trap accesses to the PCI config space

[Julien Grall]

Hi Roger,

On 23/02/18 17:25, Roger Pau Monné wrote:

On Fri, Feb 23, 2018 at 04:02:17PM +, Julien Grall wrote:

Hi,

On 23/02/18 15:55, Jan Beulich wrote:

On 23.01.18 at 16:07,  wrote:

diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index c9b9546435..98b82680c6 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -65,6 +65,13 @@ SECTIONS
  __param_start = .;
  *(.data.param)
  __param_end = .;
+
+#if defined(CONFIG_HAS_PCI) && defined(CONFIG_LATE_HWDOM)


Why this is conditional to CONFIG_LATE_HWDOM?


Currently PCI config space emulation is limited to Dom0 usage, hence
the setup part of it can live in the init section if not using a late
hardware domain.


Oh, I missed that bits. Make sense then.

Cheers,



Also, any reason to impose VPCI when CONFIG_HAS_PCI is set and not introduce
another config? The new config would help to add support for PCI in steps in
other architectures.


I could do that I guess, unless anyone objects I will add a
CONFIG_VPCI option.

Roger.



--
Julien Grall

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

Re: [Xen-devel] [PATCH] libxl: add libxl__is_driver_domain function

[Wei Liu]

On Tue, Feb 13, 2018 at 03:32:04PM +0200, Oleksandr Grytsov wrote:
> On Tue, Feb 13, 2018 at 2:06 PM, Wei Liu  wrote:
> 
> > On Tue, Feb 06, 2018 at 03:08:45PM +0200, Oleksandr Grytsov wrote:
> > > On Tue, Feb 6, 2018 at 2:36 PM, Wei Liu  wrote:
> > >
> > > > On Thu, Dec 14, 2017 at 04:14:12PM +0200, Oleksandr Grytsov wrote:
> > > > > From: Oleksandr Grytsov 
> > > > >
> > > > > We have following arm-based setup:
> > > > >
> > > > > - Dom0 with xen and xen tools;
> > > > > - Dom1 with device backends (but it is not the driver domain);
> > > >
> > > > What is your definition of a "driver domain"? What does it do in this
> > > > case?
> > > >
> > > > I seem to have seen people use this term in different contexts to mean
> > > > slightly different things. I need to figure out what you actually mean
> > > > first.
> > > >
> > > >
> > > I see in the libxl/xl sources that closing PV devices is done differently
> > > in case backends are in Dom0 and are in other domain. It is called as
> > > driver domain in the sources. So, I don't have clear understanding
> > > what does it mean. In our setup backends are in Dom1 and xl is in Dom0.
> > > And I see that xl dosn't close PV device on domain reboot or shutdown.
> >
> > Do you run xl devd in your backend domain?
> >
> > Wei.
> >
> 
> No I don't

Can you try that? I think xl devd should clean up the stale entries --
that's how we envisage driver domains to be used.

Wei.

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

Re: [Xen-devel] [PATCH v8 03/11] x86/physdev: enable PHYSDEVOP_pci_mmcfg_reserved for PVH Dom0

[Paul Durrant]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 23 February 2018 15:57
> To: Paul Durrant ; Roger Pau Monne
> 
> Cc: Andrew Cooper ; xen-
> de...@lists.xenproject.org; Boris Ostrovsky ;
> Konrad Rzeszutek Wilk 
> Subject: Re: [PATCH v8 03/11] x86/physdev: enable
> PHYSDEVOP_pci_mmcfg_reserved for PVH Dom0
> 
> >>> On 23.01.18 at 16:07,  wrote:
> > So that MMCFG regions not present in the MCFG ACPI table can be added
> > at run time by the hardware domain.
> >
> > Signed-off-by: Roger Pau Monné 
> > Reviewed-by: Jan Beulich 
> > ---
> > Cc: Jan Beulich 
> > Cc: Andrew Cooper 
> > ---
> > Changes since v7:
> >  - Add newline in hvm_physdev_op for non-fallthrough case.
> >
> > Changes since v6:
> >  - Do not return EEXIST if the same exact region is already tracked by
> >Xen.
> >
> > Changes since v5:
> >  - Check for has_vpci before calling register_vpci_mmcfg_handler
> >instead of checking for is_hvm_domain.
> >
> > Changes since v4:
> >  - Change the hardware_domain check in hvm_physdev_op to a vpci check.
> >  - Only register the MMCFG area, but don't scan it.
> >
> > Changes since v3:
> >  - New in this version.
> > ---
> >  xen/arch/x86/hvm/hypercall.c |  5 +
> >  xen/arch/x86/hvm/io.c| 16 +++-
> 
> Sadly you forgot to Cc Paul for this one. Paul - any chance you could
> take a look?
> 

Sure. LGTM.

Reviewed-by: Paul Durrant 

> Jan
> 
> >  xen/arch/x86/physdev.c   | 11 +++
> >  3 files changed, 27 insertions(+), 5 deletions(-)
> >
> > diff --git a/xen/arch/x86/hvm/hypercall.c b/xen/arch/x86/hvm/hypercall.c
> > index 5742dd1797..85eacd7d33 100644
> > --- a/xen/arch/x86/hvm/hypercall.c
> > +++ b/xen/arch/x86/hvm/hypercall.c
> > @@ -89,6 +89,11 @@ static long hvm_physdev_op(int cmd,
> > XEN_GUEST_HANDLE_PARAM(void) arg)
> >  if ( !has_pirq(curr->domain) )
> >  return -ENOSYS;
> >  break;
> > +
> > +case PHYSDEVOP_pci_mmcfg_reserved:
> > +if ( !has_vpci(curr->domain) )
> > +return -ENOSYS;
> > +break;
> >  }
> >
> >  if ( !curr->hcall_compat )
> > diff --git a/xen/arch/x86/hvm/io.c b/xen/arch/x86/hvm/io.c
> > index 04425c064b..556810c126 100644
> > --- a/xen/arch/x86/hvm/io.c
> > +++ b/xen/arch/x86/hvm/io.c
> > @@ -507,10 +507,9 @@ static const struct hvm_mmio_ops
> vpci_mmcfg_ops = {
> >  .write = vpci_mmcfg_write,
> >  };
> >
> > -int __hwdom_init register_vpci_mmcfg_handler(struct domain *d,
> paddr_t
> > addr,
> > - unsigned int start_bus,
> > - unsigned int end_bus,
> > - unsigned int seg)
> > +int register_vpci_mmcfg_handler(struct domain *d, paddr_t addr,
> > +unsigned int start_bus, unsigned int
> > end_bus,
> > +unsigned int seg)
> >  {
> >  struct hvm_mmcfg *mmcfg, *new = xmalloc(struct hvm_mmcfg);
> >
> > @@ -535,9 +534,16 @@ int __hwdom_init
> register_vpci_mmcfg_handler(struct
> > domain *d, paddr_t addr,
> >  if ( new->addr < mmcfg->addr + mmcfg->size &&
> >   mmcfg->addr < new->addr + new->size )
> >  {
> > +int ret = -EEXIST;
> > +
> > +if ( new->addr == mmcfg->addr &&
> > + new->start_bus == mmcfg->start_bus &&
> > + new->segment == mmcfg->segment &&
> > + new->size == mmcfg->size )
> > +ret = 0;
> >  write_unlock(>arch.hvm_domain.mmcfg_lock);
> >  xfree(new);
> > -return -EEXIST;
> > +return ret;
> >  }
> >
> >  if ( list_empty(>arch.hvm_domain.mmcfg_regions) )
> > diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
> > index 380d36f6b9..984491c3dc 100644
> > --- a/xen/arch/x86/physdev.c
> > +++ b/xen/arch/x86/physdev.c
> > @@ -557,6 +557,17 @@ ret_t do_physdev_op(int cmd,
> > XEN_GUEST_HANDLE_PARAM(void) arg)
> >
> >  ret = pci_mmcfg_reserved(info.address, info.segment,
> >   info.start_bus, info.end_bus, info.flags);
> > +if ( !ret && has_vpci(currd) )
> > +{
> > +/*
> > + * For HVM (PVH) domains try to add the newly found MMCFG to
> > the
> > + * domain.
> > + */
> > +ret = register_vpci_mmcfg_handler(currd, info.address,
> > +  info.start_bus, info.end_bus,
> > +  info.segment);
> > +}
> > +
> >  break;
> >  }
> >
> > --
> > 2.15.1
> 

___

Re: [Xen-devel] [PATCH v4 08/28] x86/vvtd: Add MMIO handler for VVTD

[Wei Liu]

On Fri, Feb 23, 2018 at 05:07:09PM +, Roger Pau Monné wrote:
> On Thu, Feb 22, 2018 at 02:20:12PM +0800, Chao Gao wrote:
> > On Fri, Feb 09, 2018 at 05:51:29PM +, Roger Pau Monné wrote:
> > >On Sat, Feb 10, 2018 at 01:21:09AM +0800, Chao Gao wrote:
> > >> On Fri, Feb 09, 2018 at 04:39:15PM +, Roger Pau Monné wrote:
> > >> >On Fri, Nov 17, 2017 at 02:22:15PM +0800, Chao Gao wrote:
> > >> >> This patch adds VVTD MMIO handler to deal with MMIO access.
> > >> >> 
> > >> >> Signed-off-by: Chao Gao 
> > >> >> Signed-off-by: Lan Tianyu 
> > >> >> ---
> > >> >> v4:
> > >> >>  - only trap the register emulated in vvtd_in_range().
> > >> >>i.e. replace PAGE_SIZE with the VVTD_MAX_OFFSET
> > >> >> ---
> > >> >>  xen/drivers/passthrough/vtd/vvtd.c | 55 
> > >> >> ++
> > >> >>  1 file changed, 55 insertions(+)
> > >> >> 
> > >> >> diff --git a/xen/drivers/passthrough/vtd/vvtd.c 
> > >> >> b/xen/drivers/passthrough/vtd/vvtd.c
> > >> >> index 9f76ccf..d78d878 100644
> > >> >> --- a/xen/drivers/passthrough/vtd/vvtd.c
> > >> >> +++ b/xen/drivers/passthrough/vtd/vvtd.c
> > >> >
> > >> >Now that I look at this, this is the wrong folder. This should be in
> > >> >xen/arch/x86/hvm with the rest of the emulated devices.
> > >> 
> > >> It is a problem we discussed in previous versions. AMD puts its vIOMMU
> > >> (iommu_guest.c) in xen/drivers/passthrough/amd/. We are following what
> > >> they did. I don't have special taste on this. If no one objects to your
> > >> suggestion, I will move it to xen/arch/x86/hvm/. Maybe create a new
> > >> intel directory since it's intel-specific and won't be used by AMD.
> > >
> > >Oh, it's been quite some time since I've reviewed that, so TBH I
> > >didn't remember that discussion.
> > >
> > >If the AMD viommu thing is already there I guess it doesn't hurt...
> > >Also, have you checked whether it can be converted to use the
> > >infrastructure that you add here?
> > 
> > Not yet. It seems that we have no method to use AMD vIOMMU now.
> > And I notice that Wei plans to remove AMD vIOMMU.
> > 
> > I can convert AMD vIOMMU implementation to use this infrastructure if we
> > finally decide to preserve AMD vIOMMU.
> 
> Oh, OK, I had no idea we where planning to remove the AMD vIOMMU
> stuff.

That code was never properly hooked up in the first place. It has been
dead code since 2012-ish so I assumed noone cared.

I don't know if AMD maintainer will object to the removal though.

Wei.

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

Re: [Xen-devel] [PATCH][next] xen-netback: make function xenvif_rx_skb static

[Wei Liu]

On Fri, Feb 23, 2018 at 05:16:57PM +, Colin King wrote:
> From: Colin Ian King 
> 
> The function xenvif_rx_skb is local to the source and does not need
> to be in global scope, so make it static.
> 
> Cleans up sparse warning:
> drivers/net/xen-netback/rx.c:422:6: warning: symbol 'xenvif_rx_skb'
> was not declared. Should it be static?
> 
> Signed-off-by: Colin Ian King 

Acked-by: Wei Liu 

Thanks

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

Re: [Xen-devel] [PATCH v4 16/16] xen: Convert page_to_mfn and mfn_to_page to use typesafe MFN

[Wei Liu]

On Wed, Feb 21, 2018 at 02:02:59PM +, Julien Grall wrote:
> Most of the users of page_to_mfn and mfn_to_page are either overriding
> the macros to make them work with mfn_t or use mfn_x/_mfn because the
> rest of the function use mfn_t.
> 
> So make page_to_mfn and mfn_to_page return mfn_t by default. The __*
> version are now dropped as this patch will convert all the remaining
> non-typesafe callers.
> 
> Only reasonable clean-ups are done in this patch. The rest will use
> _mfn/mfn_x for the time being.
> 
> Lastly, domain_page_to_mfn is also converted to use mfn_t given that
> most of the callers are now switched to _mfn(domain_page_to_mfn(...)).
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v4 14/16] xen/grant: Switch common/grant_table.c to use typesafe MFN

[Wei Liu]

On Wed, Feb 21, 2018 at 02:02:57PM +, Julien Grall wrote:
> No functional change intended.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v4 13/16] xen/grant: Switch {create, replace}_grant_p2m_mapping to typesafe MFN

[Wei Liu]

On Wed, Feb 21, 2018 at 02:02:56PM +, Julien Grall wrote:
> The current prototype is slightly confusing because it takes a guest
> physical address and a machine physical frame (not address!). Switching to
> MFN will improve safety and reduce the chance to mistakenly invert the
> 2 parameters.
> 
> Signed-off-by: Julien grall 
> 

Reviewed-by: Wei Liu 

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

Re: [Xen-devel] [PATCH 3/7] x86/alt: Clean up the assembly used to generate alternatives

[Jan Beulich]

>>> On 23.02.18 at 17:24,  wrote:
> On 23/02/18 15:12, Jan Beulich wrote:
> On 23.02.18 at 15:03,  wrote:
>>> On 13/02/18 14:37, Jan Beulich wrote:
  >>> On 12.02.18 at 12:23,  wrote:
> --- a/xen/include/asm-x86/alternative-asm.h
> +++ b/xen/include/asm-x86/alternative-asm.h
> @@ -9,60 +9,67 @@
>   * enough information for the alternatives patching code to patch an
>   * instruction. See apply_alternatives().
>   */
> -.macro altinstruction_entry orig alt feature orig_len alt_len
> +.macro altinstruction_entry orig repl feature orig_len repl_len
>  .long \orig - .
> -.long \alt - .
> +.long \repl - .
>  .word \feature
>  .byte \orig_len
> -.byte \alt_len
> +.byte \repl_len
>  .endm
>  
> +#define orig_len   (.L\@_orig_e   - .L\@_orig_s)
> +#define repl_len(nr)   (.L\@_repl_e\()nr  - .L\@_repl_s\()nr)
> +#define decl_repl(insn, nr) .L\@_repl_s\()nr: insn; .L\@_repl_e\()nr:
 Wouldn't it work equally well but look slightly less odd if you used
 \(nr) instead of \()nr?
>>> How would that work?  \() is the token separator.
>> When there's nothing inside the parentheses, this construct
>> can be used as a token separator, but that's not its main
>> purpose. Instead \() means to take  literally,
>> without e.g. expanding macro arguments inside it.
> 
> I've never come across it before, and I still can't find reference to it
> in the as manual.
> 
> As for why not to use it, Clang has no idea what \(nr) means, meaning
> that it doesn't expand the construct in the way you describe.  (Although
> I see that GCC/AS do behave as you describe).

Oh, if clang can't cope, then leave it as is.

Jan


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

Re: [Xen-devel] [PATCH v4 12/16] xen/mm: Switch common/memory.c to use typesafe MFN

[Wei Liu]

On Wed, Feb 21, 2018 at 02:02:55PM +, Julien Grall wrote:
> A new helper copy_mfn_to_guest is introduced to easily to copy a MFN to
> the guest memory.
> 
> Not functional change intended

Is there a reason to not make all guest accessors tyep-safe instead?

Wei.

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  a823a5280f25ad19a751dd9a41044f556471e61a
baseline version:
 xen  1e1da6ec3aeb289d885b6a2ad0ea50949426f3a4

Last test of basis   119959  2018-02-23 11:02:21 Z0 days
Testing same since   119966  2018-02-23 14:33:58 Z0 days1 attempts


People who touched revisions under test:
  Alan Robinson 
  Andrew Cooper 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   1e1da6ec3a..a823a5280f  a823a5280f25ad19a751dd9a41044f556471e61a -> smoke

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

Re: [Xen-devel] [PATCH v8 01/11] vpci: introduce basic handlers to trap accesses to the PCI config space

[Roger Pau Monné]

On Fri, Feb 23, 2018 at 04:02:17PM +, Julien Grall wrote:
> Hi,
> 
> On 23/02/18 15:55, Jan Beulich wrote:
> > > > > On 23.01.18 at 16:07,  wrote:
> > > diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
> > > index c9b9546435..98b82680c6 100644
> > > --- a/xen/arch/arm/xen.lds.S
> > > +++ b/xen/arch/arm/xen.lds.S
> > > @@ -65,6 +65,13 @@ SECTIONS
> > >  __param_start = .;
> > >  *(.data.param)
> > >  __param_end = .;
> > > +
> > > +#if defined(CONFIG_HAS_PCI) && defined(CONFIG_LATE_HWDOM)
> 
> Why this is conditional to CONFIG_LATE_HWDOM?

Currently PCI config space emulation is limited to Dom0 usage, hence
the setup part of it can live in the init section if not using a late
hardware domain.

> 
> Also, any reason to impose VPCI when CONFIG_HAS_PCI is set and not introduce
> another config? The new config would help to add support for PCI in steps in
> other architectures.

I could do that I guess, unless anyone objects I will add a
CONFIG_VPCI option.

Roger.

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

Re: [Xen-devel] [PATCH v4 10/16] xen/mm: Switch map_pages_to_xen to use MFN typesafe

[Wei Liu]

On Wed, Feb 21, 2018 at 02:02:53PM +, Julien Grall wrote:
> The current prototype is slightly confusing because it takes a virtual
> address and a physical frame (not address!). Switching to MFN will improve
> safety and reduce the chance to mistakenly invert the 2 parameters.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v4 11/16] xen/mm: Switch page_alloc.c to typesafe MFN

[Wei Liu]

On Wed, Feb 21, 2018 at 02:02:54PM +, Julien Grall wrote:
> No functional change intended.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v4 17/28] x86/vvtd: save and restore emulated VT-d

[Roger Pau Monné]

On Fri, Feb 23, 2018 at 01:22:23PM +0800, Chao Gao wrote:
> On Mon, Feb 12, 2018 at 02:49:12PM +, Roger Pau Monné wrote:
> >On Fri, Nov 17, 2017 at 02:22:24PM +0800, Chao Gao wrote:
> >
> >> +struct hvm_hw_vvtd
> >> +{
> >> +uint32_t eim_enabled : 1,
> >> + intremap_enabled : 1;
> >> +uint32_t fault_index;
> >> +
> >> +/* Interrupt remapping table base gfn and the max of entries */
> >> +uint32_t irt_max_entry;
> >> +uint64_t irt;
> >> +
> >> +uint32_t regs[VVTD_MAX_OFFSET/sizeof(uint32_t)];
> >> +};
> >> +
> >> +DECLARE_HVM_SAVE_TYPE(VVTD, 21, struct hvm_hw_vvtd);
> >
> >Adding new fields to this struct in a migration compatible way is
> >going to be a PITA, but there's no easy solution to this I'm afraid...
> 
> What do you mean by "migration compatible"? Do you mean migrating a hvm
> guest with viommu between different Xen versions? Could it be solved by
> leaving some padding fields here?

It's inevitable, but when new features are added to the vvtd
implementation the struct will likely change and then we will need
some conversion helper.

Roger.

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

Re: [Xen-devel] [RFC Patch v4 8/8] x86/hvm: bump the maximum number of vcpus to 512

[Wei Liu]

On Fri, Feb 23, 2018 at 01:50:05AM -0700, Jan Beulich wrote:
> >>> On 22.02.18 at 19:46,  wrote:
> > On Wed, Dec 06, 2017 at 03:50:14PM +0800, Chao Gao wrote:
> >> --- a/xen/include/public/hvm/hvm_info_table.h
> >> +++ b/xen/include/public/hvm/hvm_info_table.h
> >> @@ -32,7 +32,7 @@
> >>  #define HVM_INFO_PADDR   ((HVM_INFO_PFN << 12) + HVM_INFO_OFFSET)
> >>  
> >>  /* Maximum we can support with current vLAPIC ID mapping. */
> >> -#define HVM_MAX_VCPUS128
> >> +#define HVM_MAX_VCPUS512
> > 
> > I checked a few places where this is used, bumping the number doesn't
> > seem to be harmful on the surface.
> > 
> > Of course there is the question how many CPUs can upstream support,
> > I think it is still under argument at the moment.
> 
> Leaving the latter aside, it is never okay to simply change a #define
> in the public interface. See e.g. fb442e2171 ("x86_64: allow more
> vCPU-s per guest"), where we've already gone a somewhat harsh
> route by dropping the original #define altogether (thus at least
> causing build failures for consumers), taking the position that it
> wasn't correct to expose the value in the first place.
> 
> Hence at the very least I can't see how struct hvm_info_table
> (in the same public header) can be left alone with this change.

AIUI this change has made the structure larger by extending the trailing
array. The resulting structure still fits into one page. At least to me
the new ABI is still compatible with the old.

The commit you mentioned is different because it completely breaks ABI
compatibility.

Wei.

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

[Xen-devel] [PATCH][next] xen-netback: make function xenvif_rx_skb static

[Colin King]

From: Colin Ian King 

The function xenvif_rx_skb is local to the source and does not need
to be in global scope, so make it static.

Cleans up sparse warning:
drivers/net/xen-netback/rx.c:422:6: warning: symbol 'xenvif_rx_skb'
was not declared. Should it be static?

Signed-off-by: Colin Ian King 
---
 drivers/net/xen-netback/rx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/xen-netback/rx.c b/drivers/net/xen-netback/rx.c
index b1cf7c6f407a..ef5887037b22 100644
--- a/drivers/net/xen-netback/rx.c
+++ b/drivers/net/xen-netback/rx.c
@@ -419,7 +419,7 @@ static void xenvif_rx_extra_slot(struct xenvif_queue *queue,
BUG();
 }
 
-void xenvif_rx_skb(struct xenvif_queue *queue)
+static void xenvif_rx_skb(struct xenvif_queue *queue)
 {
struct xenvif_pkt_state pkt;
 
-- 
2.15.1


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

[Xen-devel] [PATCH LP-BUILD-TOOLS] Allow patching files compiled multiple times

[Ross Lagerwall]

gas prior to binutils commit fbdf9406b0 (appears in 2.27) outputs symbol
table entries resulting from .file in reverse order. If we get two
consecutive file symbols, prefer the first one if that names an object
file or has a directory component (to cover multiply compiled files).

This is the same workaround that was applied in Xen commit d37d63d4b548
("symbols: prefix static symbols with their source file names") for
Xen's internal symbol table.

This fixes building a livepatch for XSA-243.
---
 lookup.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/lookup.c b/lookup.c
index 39125c6..645b91a 100644
--- a/lookup.c
+++ b/lookup.c
@@ -149,16 +149,34 @@ int lookup_local_symbol(struct lookup_table *table, char 
*name, char *hint,
struct symbol *sym, *match = NULL;
int i;
char *curfile = NULL;
+   enum { other, multi_source } last_type = other;
 
memset(result, 0, sizeof(*result));
for_each_symbol(i, sym, table) {
if (sym->type == STT_FILE) {
+   const char *ext = strrchr(sym->name, '.');
+   int multi = strchr(sym->name, '/') ||
+   (ext && ext[1] == 'o');
+
+   /*
+* gas prior to binutils commit fbdf9406b0 (appears in
+* 2.27) outputs symbol table entries resulting from
+* .file in reverse order. If we get two consecutive
+* file symbols, prefer the first one if that names an
+* object file or has a directory component (to cover
+* multiply compiled files).
+*/
+   if (last_type == multi_source)
+   continue;
+
if (!strcmp(sym->name, hint)) {
curfile = sym->name;
+   last_type = multi ? multi_source : other;
continue; /* begin hint file symbols */
} else if (curfile)
curfile = NULL; /* end hint file symbols */
}
+   last_type = other;
if (!curfile)
continue;
if (sym->bind == STB_LOCAL && !strcmp(sym->name, name)) {
-- 
2.9.5


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

Re: [Xen-devel] [PATCH v4 08/28] x86/vvtd: Add MMIO handler for VVTD

[Roger Pau Monné]

On Thu, Feb 22, 2018 at 02:20:12PM +0800, Chao Gao wrote:
> On Fri, Feb 09, 2018 at 05:51:29PM +, Roger Pau Monné wrote:
> >On Sat, Feb 10, 2018 at 01:21:09AM +0800, Chao Gao wrote:
> >> On Fri, Feb 09, 2018 at 04:39:15PM +, Roger Pau Monné wrote:
> >> >On Fri, Nov 17, 2017 at 02:22:15PM +0800, Chao Gao wrote:
> >> >> This patch adds VVTD MMIO handler to deal with MMIO access.
> >> >> 
> >> >> Signed-off-by: Chao Gao 
> >> >> Signed-off-by: Lan Tianyu 
> >> >> ---
> >> >> v4:
> >> >>  - only trap the register emulated in vvtd_in_range().
> >> >>i.e. replace PAGE_SIZE with the VVTD_MAX_OFFSET
> >> >> ---
> >> >>  xen/drivers/passthrough/vtd/vvtd.c | 55 
> >> >> ++
> >> >>  1 file changed, 55 insertions(+)
> >> >> 
> >> >> diff --git a/xen/drivers/passthrough/vtd/vvtd.c 
> >> >> b/xen/drivers/passthrough/vtd/vvtd.c
> >> >> index 9f76ccf..d78d878 100644
> >> >> --- a/xen/drivers/passthrough/vtd/vvtd.c
> >> >> +++ b/xen/drivers/passthrough/vtd/vvtd.c
> >> >
> >> >Now that I look at this, this is the wrong folder. This should be in
> >> >xen/arch/x86/hvm with the rest of the emulated devices.
> >> 
> >> It is a problem we discussed in previous versions. AMD puts its vIOMMU
> >> (iommu_guest.c) in xen/drivers/passthrough/amd/. We are following what
> >> they did. I don't have special taste on this. If no one objects to your
> >> suggestion, I will move it to xen/arch/x86/hvm/. Maybe create a new
> >> intel directory since it's intel-specific and won't be used by AMD.
> >
> >Oh, it's been quite some time since I've reviewed that, so TBH I
> >didn't remember that discussion.
> >
> >If the AMD viommu thing is already there I guess it doesn't hurt...
> >Also, have you checked whether it can be converted to use the
> >infrastructure that you add here?
> 
> Not yet. It seems that we have no method to use AMD vIOMMU now.
> And I notice that Wei plans to remove AMD vIOMMU.
> 
> I can convert AMD vIOMMU implementation to use this infrastructure if we
> finally decide to preserve AMD vIOMMU.

Oh, OK, I had no idea we where planning to remove the AMD vIOMMU
stuff.

Thanks, Roger.

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

Re: [Xen-devel] [PATCH v4 11/28] x86/vvtd: Process interrupt remapping request

[Roger Pau Monné]

On Sun, Feb 11, 2018 at 01:31:41PM +0800, Chao Gao wrote:
> On Fri, Feb 09, 2018 at 05:44:17PM +, Roger Pau Monné wrote:
> >On Fri, Nov 17, 2017 at 02:22:18PM +0800, Chao Gao wrote:
> >> +static int vvtd_delivery(struct domain *d, uint8_t vector,
> >> + uint32_t dest, bool dest_mode,
> >> + uint8_t delivery_mode, uint8_t trig_mode)
> >> +{
> >> +struct vlapic *target;
> >> +struct vcpu *v;
> >> +
> >> +switch ( delivery_mode )
> >> +{
> >> +case dest_LowestPrio:
> >> +target = vlapic_lowest_prio(d, NULL, 0, dest, dest_mode);
> >> +if ( target != NULL )
> >> +{
> >> +vvtd_debug("d%d: dest=v%d dlm=%x vector=%d trig_mode=%d\n",
> >> +   vlapic_domain(target)->domain_id,
> >> +   vlapic_vcpu(target)->vcpu_id,
> >> +   delivery_mode, vector, trig_mode);
> >> +vlapic_set_irq(target, vector, trig_mode);
> >> +break;
> >> +}
> >> +vvtd_debug("d%d: null round robin: vector=%02x\n",
> >> +   d->domain_id, vector);
> >> +break;
> >> +
> >> +case dest_Fixed:
> >> +for_each_vcpu ( d, v )
> >> +if ( vlapic_match_dest(vcpu_vlapic(v), NULL, 0, dest, 
> >> dest_mode) )
> >> +{
> >> +vvtd_debug("d%d: dest=v%d dlm=%x vector=%d 
> >> trig_mode=%d\n",
> >> +   v->domain->domain_id, v->vcpu_id,
> >> +   delivery_mode, vector, trig_mode);
> >> +vlapic_set_irq(vcpu_vlapic(v), vector, trig_mode);
> >> +}
> >> +break;
> >> +
> >> +case dest_NMI:
> >> +for_each_vcpu ( d, v )
> >> +if ( vlapic_match_dest(vcpu_vlapic(v), NULL, 0, dest, 
> >> dest_mode) &&
> >> + !test_and_set_bool(v->nmi_pending) )
> >> +vcpu_kick(v);
> >
> >Doing this loops here seems quite bad from a preformance PoV,
> >specially taking into account that this code is going to be used with
> >> 128 vCPUs.
> 
> Maybe. But i prefer to not do optimization at this early stage.

I agree with not doing optimizations for first pass implementations,
but given this series is focused on increasing the number of vCPUs in
order to get better performance adding loops bounded to the number of
vCPUs seems quite incoherent.

There are several of those in the vlapic code for example, so I'm
wondering whether a preparatory patch should deal with those, or at
least have a plan.

I would like to at least see a 'TODO' tag here describing how to deal
with this in the future, so that the maximum allowed number of vCPUs
for HVM domain is not bumped until those TODOs are taken care of.

Roger.

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

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

[osstest service owner]

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

Regressions :-(

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

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

version targeted for testing:
 seabios  af0daeb2687ad2595482b8a71b02a082a5672ceb
baseline version:
 seabios  0ca6d6277dfafc671a5b3718cbeb5c78e2a888ea

Last test of basis   115539  2017-11-03 20:48:58 Z  111 days
Failing since115733  2017-11-10 17:19:59 Z  104 days  135 attempts
Testing same since   119258  2018-02-15 09:12:54 Z8 days   13 attempts


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

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-ws16-amd64 fail
 test-amd64-i386-xl-qemuu-ws16-amd64  fail
 test-amd64-amd64-xl-qemuu-win10-i386 fail
 test-amd64-i386-xl-qemuu-win10-i386  fail
 test-amd64-amd64-qemuu-nested-intel  pass
 test-amd64-i386-qemuu-rhel6hvm-intel pass



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

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

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

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


Not pushing.


commit af0daeb2687ad2595482b8a71b02a082a5672ceb
Author: Nikolay Nikolov 
Date:   Sat Feb 10 13:52:17 2018 +0200

floppy: Send 4 sense interrupt commands during controller initialization

During initialization, real floppy controllers need 4 sense interrupt 
commands
to clear the interrupt status (this represents the transition from "not 
ready"
to "ready" for each of the four virtual floppy drives), instead of just one.

This is described in detail in section 7.4 - Drive Polling of the Intel 
82077AA
datasheet.

Signed-off-by: Nikolay Nikolov 

commit 2611db472c0f0bad4987c20990a45c175342fc22
Author: Nikolay Nikolov 
Date:   Sat Feb 10 13:52:16 2018 +0200

floppy: Wait for the floppy motor to reach a stable speed, after starting

When starting up the 

[Xen-devel] [PATCH v4 04/19] xen/arm: vsmc: Implement SMCCC_ARCH_WORKAROUND_1 BP hardening support

[Julien Grall]

SMCCC 1.1 offers firmware-based CPU workarounds. In particular,
SMCCC_ARCH_WORKAROUND_1 provides BP hardening for variant 2 of XSA-254
(CVE-2017-5715).

If the hypervisor has some mitigation for this issue, report that we
deal with it using SMCCC_ARCH_WORKAROUND_1, as we apply the hypervisor
workaround on every guest exit.

Signed-off-by: Julien Grall 
Reviewed-by: Volodymyr Babchuk 
Acked-by: Stefano Stabellini 
Reviewed-by: Andre Przywara 

---
Changes in v4:
- Add Stefano's acked-by
- Add Andre's reviewed-by

Changes in v3:
- Fix minor conflict during rebase

Changes in v2:
- Add Volodymyr's reviewed-by
---
 xen/arch/arm/vsmc.c | 22 --
 xen/include/asm-arm/smccc.h |  6 ++
 2 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
index 7ec492741b..40a80d5760 100644
--- a/xen/arch/arm/vsmc.c
+++ b/xen/arch/arm/vsmc.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -93,8 +94,25 @@ static bool handle_arch(struct cpu_user_regs *regs)
 return true;
 
 case ARM_SMCCC_ARCH_FEATURES_FID:
-/* Nothing supported yet */
-set_user_reg(regs, 0, ARM_SMCCC_NOT_SUPPORTED);
+{
+uint32_t arch_func_id = get_user_reg(regs, 1);
+int ret = ARM_SMCCC_NOT_SUPPORTED;
+
+switch ( arch_func_id )
+{
+case ARM_SMCCC_ARCH_WORKAROUND_1_FID:
+if ( cpus_have_cap(ARM_HARDEN_BRANCH_PREDICTOR) )
+ret = 0;
+break;
+}
+
+set_user_reg(regs, 0, ret);
+
+return true;
+}
+
+case ARM_SMCCC_ARCH_WORKAROUND_1_FID:
+/* No return value */
 return true;
 }
 
diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h
index 629cc5150b..2951caa49d 100644
--- a/xen/include/asm-arm/smccc.h
+++ b/xen/include/asm-arm/smccc.h
@@ -115,6 +115,12 @@ static inline uint32_t smccc_get_owner(register_t funcid)
ARM_SMCCC_OWNER_ARCH,\
0x1)
 
+#define ARM_SMCCC_ARCH_WORKAROUND_1_FID \
+ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+  ARM_SMCCC_CONV_32,\
+  ARM_SMCCC_OWNER_ARCH, \
+  0x8000)
+
 /* SMCCC error codes */
 #define ARM_SMCCC_ERR_UNKNOWN_FUNCTION  (-1)
 #define ARM_SMCCC_NOT_SUPPORTED (-1)
-- 
2.11.0


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

[Xen-devel] [PATCH v4 12/19] fixup! xen/arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support

[Julien Grall]

---
 xen/arch/arm/arm64/bpi.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/arm/arm64/bpi.S b/xen/arch/arm/arm64/bpi.S
index 981fb83a88..b59e307b0f 100644
--- a/xen/arch/arm/arm64/bpi.S
+++ b/xen/arch/arm/arm64/bpi.S
@@ -85,8 +85,8 @@ ENTRY(__psci_hyp_bp_inval_end)
 
 ENTRY(__smccc_workaround_1_smc_start)
 sub sp, sp, #(8 * 4)
-stp x2, x3, [sp, #(8 * 0)]
 stp x0, x1, [sp, #(8 * 2)]
+stp x2, x3, [sp, #(8 * 0)]
 mov w0, #ARM_SMCCC_ARCH_WORKAROUND_1_FID
 smc #0
 ldp x2, x3, [sp, #(8 * 0)]
-- 
2.11.0


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

[Xen-devel] [PATCH v4 13/19] xen/arm64: Kill PSCI_GET_VERSION as a variant-2 workaround

[Julien Grall]

Now that we've standardised on SMCCC v1.1 to perform the branch
prediction invalidation, let's drop the previous band-aid. If vendors
haven't updated their firmware to do SMCCC 1.1, they haven't updated
PSCI either, so we don't loose anything.

This is aligned with the Linux commit 3a0a397ff5ff.

Signed-off-by: Julien Grall 
Reviewed-by: Volodymyr Babchuk 
Reviewed-by: Stefano Stabellini 

---
Note that the patch is in arm64/for-next/core and should be merged
in master soon.

Changes in v4:
- Add Stefano's reviewed-by

Changes in v3:
- Add Volodymyr's reviewed-by

Changes in v2:
- Patch added
---
 xen/arch/arm/arm64/bpi.S | 25 --
 xen/arch/arm/cpuerrata.c | 54 +---
 2 files changed, 19 insertions(+), 60 deletions(-)

diff --git a/xen/arch/arm/arm64/bpi.S b/xen/arch/arm/arm64/bpi.S
index b59e307b0f..d8743d955c 100644
--- a/xen/arch/arm/arm64/bpi.S
+++ b/xen/arch/arm/arm64/bpi.S
@@ -58,31 +58,6 @@ ENTRY(__bp_harden_hyp_vecs_start)
 .endr
 ENTRY(__bp_harden_hyp_vecs_end)
 
-ENTRY(__psci_hyp_bp_inval_start)
-sub sp, sp, #(8 * 18)
-stp x16, x17, [sp, #(16 * 0)]
-stp x14, x15, [sp, #(16 * 1)]
-stp x12, x13, [sp, #(16 * 2)]
-stp x10, x11, [sp, #(16 * 3)]
-stp x8, x9, [sp, #(16 * 4)]
-stp x6, x7, [sp, #(16 * 5)]
-stp x4, x5, [sp, #(16 * 6)]
-stp x2, x3, [sp, #(16 * 7)]
-stp x0, x1, [sp, #(16 * 8)]
-mov x0, #0x8400
-smc #0
-ldp x16, x17, [sp, #(16 * 0)]
-ldp x14, x15, [sp, #(16 * 1)]
-ldp x12, x13, [sp, #(16 * 2)]
-ldp x10, x11, [sp, #(16 * 3)]
-ldp x8, x9, [sp, #(16 * 4)]
-ldp x6, x7, [sp, #(16 * 5)]
-ldp x4, x5, [sp, #(16 * 6)]
-ldp x2, x3, [sp, #(16 * 7)]
-ldp x0, x1, [sp, #(16 * 8)]
-add sp, sp, #(8 * 18)
-ENTRY(__psci_hyp_bp_inval_end)
-
 ENTRY(__smccc_workaround_1_smc_start)
 sub sp, sp, #(8 * 4)
 stp x0, x1, [sp, #(8 * 2)]
diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index dec9074422..4eb1567589 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -149,10 +149,11 @@ install_bp_hardening_vec(const struct 
arm_cpu_capabilities *entry,
 
 extern char __smccc_workaround_1_smc_start[], __smccc_workaround_1_smc_end[];
 
-static bool
-check_smccc_arch_workaround_1(const struct arm_cpu_capabilities *entry)
+static int enable_smccc_arch_workaround_1(void *data)
 {
 struct arm_smccc_res res;
+static bool warned = false;
+const struct arm_cpu_capabilities *entry = data;
 
 /*
  * Enable callbacks are called on every CPU based on the
@@ -160,47 +161,30 @@ check_smccc_arch_workaround_1(const struct 
arm_cpu_capabilities *entry)
  * entry.
  */
 if ( !entry->matches(entry) )
-return false;
+return 0;
 
 if ( smccc_ver < SMCCC_VERSION(1, 1) )
-return false;
+goto warn;
 
 arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID,
   ARM_SMCCC_ARCH_WORKAROUND_1_FID, );
 if ( res.a0 != ARM_SMCCC_SUCCESS )
-return false;
-
-return install_bp_hardening_vec(entry,__smccc_workaround_1_smc_start,
-__smccc_workaround_1_smc_end,
-"call ARM_SMCCC_ARCH_WORKAROUND_1");
-}
+goto warn;
 
-extern char __psci_hyp_bp_inval_start[], __psci_hyp_bp_inval_end[];
+return !install_bp_hardening_vec(entry,__smccc_workaround_1_smc_start,
+ __smccc_workaround_1_smc_end,
+ "call ARM_SMCCC_ARCH_WORKAROUND_1");
 
-static int enable_psci_bp_hardening(void *data)
-{
-bool ret = true;
-static bool warned = false;
-
-if ( check_smccc_arch_workaround_1(data) )
-return 0;
-/*
- * The mitigation is using PSCI version function to invalidate the
- * branch predictor. This function is only available with PSCI 0.2
- * and later.
- */
-else if ( psci_ver >= PSCI_VERSION(0, 2) )
-ret = install_bp_hardening_vec(data, __psci_hyp_bp_inval_start,
-   __psci_hyp_bp_inval_end,
-   "call PSCI get version");
-else if ( !warned )
+warn:
+if ( !warned )
 {
 ASSERT(system_state < SYS_STATE_active);
-warning_add("PSCI 0.2 or later is required for the branch predictor 
hardening.\n");
-warned = true;
+warning_add("No support for ARM_SMCCC_ARCH_WORKAROUND_1.\n"
+"Please update your firmware.\n");
+warned = false;
 }
 
-return !ret;
+return 0;
 }
 
 #endif /* CONFIG_ARM64_HARDEN_BRANCH_PREDICTOR */
@@ -316,22 +300,22 @@ static const struct arm_cpu_capabilities arm_errata[] = {
 {
 .capability = 

[Xen-devel] [PATCH v4 17/19] xen/arm: vpsci: Update the return type for MIGRATE_INFO_TYPE

[Julien Grall]

From the specification, the PSCI call MIGRATE_INFO_TYPE will return an
int32_t. Update the function return type to match it.

Signed-off-by: Julien Grall 
Reviewed-by: Stefano Stabellini 
Cc: mirela.simono...@aggios.com

---
Changes in v4:
- Add Stefano's reviewed-by

Changes in v3:
- Patch added
---
 xen/arch/arm/vpsci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/arm/vpsci.c b/xen/arch/arm/vpsci.c
index 7ea3ea58e3..9a082aa6ee 100644
--- a/xen/arch/arm/vpsci.c
+++ b/xen/arch/arm/vpsci.c
@@ -186,7 +186,7 @@ static int32_t do_psci_0_2_affinity_info(register_t 
target_affinity,
 return PSCI_0_2_AFFINITY_LEVEL_OFF;
 }
 
-static uint32_t do_psci_0_2_migrate_info_type(void)
+static int32_t do_psci_0_2_migrate_info_type(void)
 {
 return PSCI_0_2_TOS_MP_OR_NOT_PRESENT;
 }
-- 
2.11.0


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

[Xen-devel] [PATCH v4 03/19] xen/arm: vsmc: Implement SMCCC 1.1

[Julien Grall]

The new SMC Calling Convention (v1.1) allows for a reduced overhead when
calling into the firmware, and provides a new feature discovery
mechanism. See "Firmware interfaces for mitigating CVE-2017-5715"
ARM DEN 00070A.

Signed-off-by: Julien Grall 
Reviewed-by: Volodymyr Babchuk 
Acked-by: Stefano Stabellini 

---
Changes in v4:
- Add Volodymyr's reviewed-by
- Add Stefano's acked-by

Changes in v3:
- Use ARM_SMCCC_NOT_SUPPORTED rather than hardcoded return

Changes in v2:
- Add a humand readable name for the specification
---
 xen/arch/arm/vpsci.c|  1 +
 xen/arch/arm/vsmc.c | 23 +++
 xen/include/asm-arm/smccc.h | 18 +-
 3 files changed, 41 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/vpsci.c b/xen/arch/arm/vpsci.c
index e82b62db1a..19ee7caeb4 100644
--- a/xen/arch/arm/vpsci.c
+++ b/xen/arch/arm/vpsci.c
@@ -212,6 +212,7 @@ static int32_t do_psci_1_0_features(uint32_t psci_func_id)
 case PSCI_0_2_FN32_SYSTEM_OFF:
 case PSCI_0_2_FN32_SYSTEM_RESET:
 case PSCI_1_0_FN32_PSCI_FEATURES:
+case ARM_SMCCC_VERSION_FID:
 return 0;
 default:
 return PSCI_NOT_SUPPORTED;
diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
index 3d3bd95fee..7ec492741b 100644
--- a/xen/arch/arm/vsmc.c
+++ b/xen/arch/arm/vsmc.c
@@ -81,6 +81,26 @@ static bool fill_function_call_count(struct cpu_user_regs 
*regs, uint32_t cnt)
 return true;
 }
 
+/* SMCCC interface for ARM Architecture */
+static bool handle_arch(struct cpu_user_regs *regs)
+{
+uint32_t fid = (uint32_t)get_user_reg(regs, 0);
+
+switch ( fid )
+{
+case ARM_SMCCC_VERSION_FID:
+set_user_reg(regs, 0, ARM_SMCCC_VERSION_1_1);
+return true;
+
+case ARM_SMCCC_ARCH_FEATURES_FID:
+/* Nothing supported yet */
+set_user_reg(regs, 0, ARM_SMCCC_NOT_SUPPORTED);
+return true;
+}
+
+return false;
+}
+
 /* SMCCC interface for hypervisor. Tell about itself. */
 static bool handle_hypervisor(struct cpu_user_regs *regs)
 {
@@ -188,6 +208,9 @@ static bool vsmccc_handle_call(struct cpu_user_regs *regs)
 {
 switch ( smccc_get_owner(funcid) )
 {
+case ARM_SMCCC_OWNER_ARCH:
+handled = handle_arch(regs);
+break;
 case ARM_SMCCC_OWNER_HYPERVISOR:
 handled = handle_hypervisor(regs);
 break;
diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h
index 62b3a8cdf5..629cc5150b 100644
--- a/xen/include/asm-arm/smccc.h
+++ b/xen/include/asm-arm/smccc.h
@@ -16,6 +16,9 @@
 #ifndef __ASM_ARM_SMCCC_H__
 #define __ASM_ARM_SMCCC_H__
 
+#define ARM_SMCCC_VERSION_1_0   0x1
+#define ARM_SMCCC_VERSION_1_1   0x10001
+
 /*
  * This file provides common defines for ARM SMC Calling Convention as
  * specified in
@@ -100,8 +103,21 @@ static inline uint32_t smccc_get_owner(register_t funcid)
ARM_SMCCC_OWNER_##owner, \
0xFF03)
 
-/* Only one error code defined in SMCCC */
+#define ARM_SMCCC_VERSION_FID   \
+ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+   ARM_SMCCC_CONV_32,   \
+   ARM_SMCCC_OWNER_ARCH,\
+   0x0) \
+
+#define ARM_SMCCC_ARCH_FEATURES_FID \
+ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+   ARM_SMCCC_CONV_32,   \
+   ARM_SMCCC_OWNER_ARCH,\
+   0x1)
+
+/* SMCCC error codes */
 #define ARM_SMCCC_ERR_UNKNOWN_FUNCTION  (-1)
+#define ARM_SMCCC_NOT_SUPPORTED (-1)
 
 /* SMCCC function identifier range which is reserved for existing APIs */
 #define ARM_SMCCC_RESERVED_RANGE_START  0x0
-- 
2.11.0


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