Re: [Xen-devel] [PATCH] MAINTAINERS: add the iommu list for swiotlb and xen-swiotlb

[Christoph Hellwig]

On Thu, Jan 25, 2018 at 09:26:18AM -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Jan 16, 2018 at 08:56:24AM +0100, Christoph Hellwig wrote:
> > All other discussions related to the dma mapping interfaces are on the
> > iommu list, so let's make it the official list for swiotlb and the
> > second list for xen-swiotlb.
> > 
> > Signed-off-by: Christoph Hellwig 
> 
> I am so behind emails.. I am not sure if I had replied to this, but just
> in case I hadn't:
> 
> Acked-by: Konrad Rzeszutek Wilk 

Thanks, I've added this patch to the dma-mapping tree.

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

Re: [Xen-devel] Xen Introspection, KPTI, and CR3 bit 63 leads to guest VMENTRY failures during introspection

[Razvan Cojocaru]

On 01/26/2018 02:02 AM, Bitweasil . wrote:
> This also impacts the "on change only" control setting code.
> 
> From some debugging code: hvm_event_cr, value: 80001aad, old:
> 1aad
> 
> This should not count as a changed CR3 value for reporting purposes.
> 
> The following patch resolves this reasonably, for a sane value of
> "change only" reporting.  Apologies for the old Xen version, but I
> assume this is still an issue if the other issue was not resolved in
> staging.
> 
> 
> 
> --- xenserver-4.7.1-clean/xen/arch/x86/hvm/event.c    2017-05-10
> 11:29:14.135332964 -0600
> +++ xenserver-4.7.1/xen/arch/x86/hvm/event.c    2018-01-25
> 16:52:05.938251000 -0700
> @@ -33,6 +33,11 @@
>  struct arch_domain *ad = >domain->arch;
>  unsigned int ctrlreg_bitmask = monitor_ctrlreg_bitmask(index);
>  
> +
> +    // Patch in work from Razvan
> +    if ( hvm_pcid_enabled(curr) )
> +    value &= ((1ull << 63) - 1);
> +
>  if ( (ad->monitor.write_ctrlreg_enabled & ctrlreg_bitmask) &&
>   (!(ad->monitor.write_ctrlreg_onchangeonly & ctrlreg_bitmask) ||
>    value != old) )

Thanks, that's right. But I keep thinking that the proposed changes
would now incur the flush even on non-introspection paths (which for
some reason seem to work fine with the noflush bit set).

So I think this patch will affect all CR3 writes, since the only
difference between introspection and no introspection is that
hvm_set_cr3() is called with may_defer == true in the first case, and
false in the second, and both cases eventually end up clearing noflush.

I this acceptable to everyone, or do we make this smarter?


Thanks,
Razvan

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

[Xen-devel] [xen-4.10-testing test] 118315: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail like 118165
 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-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   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-amd64-amd64-libvirt-vhd 12 migrate-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-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-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  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-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  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-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass

version targeted for testing:
 xen  728fadb586a2a14a244dabd70463bcc1654ecc85
baseline version:
 xen  7cccd6f748ec724cf9408cec6b3ec8e54a8a2c1f

Last test of basis   118244  2018-01-20 10:03:04 Z5 days
Testing same since   118315  2018-01-24 21:44:19 Z1 days1 attempts


People who touched revisions under test:
  Julien Grall 
  Stefano Stabellini 

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

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

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt 13 migrate-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  bb5400b20a0c2c2dce114075b09063038ad373db
baseline version:
 xen  2375832c7e51b67f076e6b07854c4a541cb4bdc3

Last test of basis   118326  2018-01-25 11:01:28 Z0 days
Failing since118327  2018-01-25 13:01:30 Z0 days6 attempts
Testing same since   118344  2018-01-25 20:01:07 Z0 days3 attempts


People who touched revisions under test:
  Andrew Cooper 
  Daniel De Graaf 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Oleksandr Grytsov 
  Roger Pau Monné 
  Ross Lagerwall 
  Wei Liu 

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



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

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

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

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


Not pushing.


commit bb5400b20a0c2c2dce114075b09063038ad373db
Author: George Dunlap 
Date:   Mon Jan 8 15:50:53 2018 +

xl: Don't warn on using 'deprecated' mode selection

We generally support old config formats indefinintely (see the disk
format) without emitting warnings.

Signed-off-by: George Dunlap 
Acked-by: Ian Jackson 

commit 5b6b15acebfc6ef3dcb72385f328c985526a33e3
Author: Oleksandr Grytsov 
Date:   Wed Jan 24 19:19:59 2018 +0200

libxl: move ibxl_devid_to_device_... to LIBXL_DEFINE_DEVID_TO_DEVICE

Signed-off-by: Oleksandr Grytsov 
Acked-by: Wei Liu 

commit 32e31182ea3178ab04c8f66ee3b1465f0fc9b255
Author: Oleksandr Grytsov 
Date:   Wed Jan 24 19:19:58 2018 +0200

libxl: move libxl__device_from_ to LIBXL_DEFINE_DEVICE_FROM_TYPE

LIBXL_DEFINE_DEVICE_FROM_TYPE uses libxl__..._devtype.type to
be assigned as device and backend type.

Signed-off-by: Oleksandr Grytsov 
Acked-by: Wei Liu 

commit 4b3dd5439e24cc85c54cae01815bdb3e57234955
Author: Oleksandr Grytsov 
Date:   Wed Jan 24 19:19:57 2018 +0200

libxl: use libxl__device_kind in LIBXL_DEFINE_UPDATE_DEVID

Use libxl__..._devtype.type to update device id.

Signed-off-by: Oleksandr Grytsov 
Acked-by: Wei Liu 

commit 43a858403e9d0ce8c8282e3baade4b8e29c03b54
Author: Oleksandr Grytsov 
Date:   Wed Jan 24 19:19:56 2018 +0200

libxl: use libxl__device_kind to get device XS entry

On adding to XS name of device is taken from
libxl__device_kind enum. On getting device from XS
the name is hardcoded. It leads to potential
mistmatch errors. The patch is using libxl__device_kind
everywere to have one source of device name.

Signed-off-by: Oleksandr Grytsov 
Acked-by: Wei Liu 

commit 8155476765a5bdecea1534b46562cf28e0113a9a
Author: Wei Liu 
Date:  

Re: [Xen-devel] [RFC v4 1/8] Port WARN_ON_ONCE() from Linux

[Sameer Goel]

On 1/23/2018 9:13 AM, Wei Liu wrote:
> On Mon, Dec 18, 2017 at 08:16:56PM -0700, Sameer Goel wrote:
>> Port WARN_ON_ONCE macro from Linux.
>>
>> Signed-off-by: Sameer Goel 
>> ---
>>  xen/include/xen/lib.h | 11 +++
>>  1 file changed, 11 insertions(+)
>>
>> diff --git a/xen/include/xen/lib.h b/xen/include/xen/lib.h
>> index ed00ae1379..83206c0848 100644
>> --- a/xen/include/xen/lib.h
>> +++ b/xen/include/xen/lib.h
>> @@ -11,6 +11,17 @@
>>  #define BUG_ON(p)  do { if (unlikely(p)) BUG();  } while (0)
>>  #define WARN_ON(p) do { if (unlikely(p)) WARN(); } while (0)
>>  
>> +#define WARN_ON_ONCE(p) ({  \
>> +static bool __section(".data.unlikely") __warned; \
> You introduced a new section without corresponding changes to
> {arm,x86}/xen.lds.S
I will fix this.
>
>> +int __ret_warn_once = !!(p);\
>> +\
>> +if (unlikely(__ret_warn_once && !__warned)) {   \
>> +__warned = true;\
>> +WARN_ON(1); \
> This isn't really a direct port from Linux. At this point I wonder why
> you didn't use WARN() directly?
>
> Wei.
>
>> +}   \
>> +unlikely(__ret_warn_once);  \
>> +})
>> +
>>  #if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 6)
>>  /* Force a compilation error if condition is true */
>>  #define BUILD_BUG_ON(cond) ({ _Static_assert(!(cond), "!(" #cond ")"); })
>> -- 
>> 2.14.1
>>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel


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

Re: [Xen-devel] [PATCH v10 09/11] x86/ctxt: Issue a speculation barrier between vcpu contexts

[Dario Faggioli]

On Thu, 2018-01-25 at 19:49 +0100, Dario Faggioli wrote:
> On Thu, 2018-01-25 at 16:09 +, Andrew Cooper wrote:
> > On 25/01/18 15:57, Jan Beulich wrote:
> > >
> > > For the record, the overwhelming majority of calls to
> > > __sync_local_execstate() being responsible for the behavior
> > > come from invalidate_interrupt(), which suggests to me that
> > > there's a meaningful number of cases where a vCPU is migrated
> > > to another CPU and then back, without another vCPU having
> > > run on the original CPU in between. If I'm not wrong with this,
> > > I have to question why the vCPU is migrated then in the first
> > > place.
> > 
> > Dario made a different fix to Credit1 upstream which was supposed
> > to
> > resolve this behaviour (although I can't locate the patch by a list
> > of
> > titles), but based on these observations, I'd say the misfeature
> > hasn't
> > been fixed.
> > 
> Yes, it's 341450eaf753 ("xen: credit1: increase efficiency and
> scalability of load balancing."), and that commit and the XenServer
> patch are functionally equivalent.
> 
> So, I'm not convinced about that being the actual cause of the
> described behaviour. Tracing would be the way to tell (hopefully) for
> sure.
> 
And in order to go and investigate this a bit further, Jan, what is it
that you were doing when you saw what you described above? AFAIUI,
that's booting an HVM guest, isn't it?

How many vCPUs on how many pCPUs? Basically, I would just need a
confirmation that the system was not oversubscribed, but if, while
we're here, you can tell me the details, I'll put together an as much
as possible similar scenario.

Thanks,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Software Engineer @ SUSE https://www.suse.com/

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

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

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt 13 migrate-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  bb5400b20a0c2c2dce114075b09063038ad373db
baseline version:
 xen  2375832c7e51b67f076e6b07854c4a541cb4bdc3

Last test of basis   118326  2018-01-25 11:01:28 Z0 days
Failing since118327  2018-01-25 13:01:30 Z0 days5 attempts
Testing same since   118344  2018-01-25 20:01:07 Z0 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Daniel De Graaf 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Oleksandr Grytsov 
  Roger Pau Monné 
  Ross Lagerwall 
  Wei Liu 

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



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

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

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

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


Not pushing.


commit bb5400b20a0c2c2dce114075b09063038ad373db
Author: George Dunlap 
Date:   Mon Jan 8 15:50:53 2018 +

xl: Don't warn on using 'deprecated' mode selection

We generally support old config formats indefinintely (see the disk
format) without emitting warnings.

Signed-off-by: George Dunlap 
Acked-by: Ian Jackson 

commit 5b6b15acebfc6ef3dcb72385f328c985526a33e3
Author: Oleksandr Grytsov 
Date:   Wed Jan 24 19:19:59 2018 +0200

libxl: move ibxl_devid_to_device_... to LIBXL_DEFINE_DEVID_TO_DEVICE

Signed-off-by: Oleksandr Grytsov 
Acked-by: Wei Liu 

commit 32e31182ea3178ab04c8f66ee3b1465f0fc9b255
Author: Oleksandr Grytsov 
Date:   Wed Jan 24 19:19:58 2018 +0200

libxl: move libxl__device_from_ to LIBXL_DEFINE_DEVICE_FROM_TYPE

LIBXL_DEFINE_DEVICE_FROM_TYPE uses libxl__..._devtype.type to
be assigned as device and backend type.

Signed-off-by: Oleksandr Grytsov 
Acked-by: Wei Liu 

commit 4b3dd5439e24cc85c54cae01815bdb3e57234955
Author: Oleksandr Grytsov 
Date:   Wed Jan 24 19:19:57 2018 +0200

libxl: use libxl__device_kind in LIBXL_DEFINE_UPDATE_DEVID

Use libxl__..._devtype.type to update device id.

Signed-off-by: Oleksandr Grytsov 
Acked-by: Wei Liu 

commit 43a858403e9d0ce8c8282e3baade4b8e29c03b54
Author: Oleksandr Grytsov 
Date:   Wed Jan 24 19:19:56 2018 +0200

libxl: use libxl__device_kind to get device XS entry

On adding to XS name of device is taken from
libxl__device_kind enum. On getting device from XS
the name is hardcoded. It leads to potential
mistmatch errors. The patch is using libxl__device_kind
everywere to have one source of device name.

Signed-off-by: Oleksandr Grytsov 
Acked-by: Wei Liu 

commit 8155476765a5bdecea1534b46562cf28e0113a9a
Author: Wei Liu 
Date:  

Re: [Xen-devel] GPU passthrough on ARM

[Martin Kelly]

On 01/25/2018 04:17 AM, Julien Grall wrote:



On 24/01/18 22:10, Martin Kelly wrote:

Hi,


Hello,

Does anyone know if GPU passthrough is supported on ARM? (e.g. for a 
GPU integrated into an ARM SoC). I checked documentation and the code, 
but I couldn't tell for sure.


If so, what are the hardware requirements for it? If not, is it 
feasible to do in the future?


Xen Arm supports device integrated into an ARM SoC. In general we highly 
recommend to have the GPU behind an IOMMU. So passthrough would be fully 
secure.


Does your platform has an IOMMU? If so which one? Do you know if the GPU 
is behind it?


It would be possible to do passthrough without IOMMU, but that's more 
complex and would require some hack in Xen to make sure the guest memory 
is direct mapped (e.g guest physical address = host physical address).


For more documentation on how to do it (see [1] and [2]).

Cheers,

[1] 
https://events.static.linuxfound.org/sites/events/files/slides/talk_5.pdf

[2] https://wiki.xen.org/images/1/17/Device_passthrough_xen.pdf



Hi Julien,

Thanks very much for the information. I'm looking at the Renesas R-Car 
H3 R8A7795, which has an IOMMU (using the Linux ipmmu-vmsa driver in 
drivers/iommu/ipmmu-vmsa.c). Looking at the device tree for it 
(r8a7795.dtsi), it appears you could pass through the display@feb0 
node for the DRM driver.


I did notice this patch series, which didn't get merged:

https://lists.xenproject.org/archives/html/xen-devel/2017-07/msg02679.html

Presumably that driver would be needed in Xen.

Are there any gotchas I'm missing? Is GPU passthrough on ARM something 
that is "theoretically doable" or something that has been done already 
and shown to be performant?


Thanks again,
Martin

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

[Xen-devel] [xen-4.9-testing test] 118314: regressions - trouble: broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-credit2  broken
 test-armhf-armhf-xl-credit2   4 host-install(4)broken REGR. vs. 118222
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stopfail REGR. vs. 118167
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
118222

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

version targeted for testing:
 xen  a2567d6b54b7b187ecc0165021b6dd07dafaf06a
baseline version:
 xen  dc7d46580d9c633a59be1c3776f79c01dd0cb98b

Last test of basis   118222  2018-01-19 06:53:40 Z6 days
Testing same since   118314  2018-01-24 21:44:17 Z1 days1 attempts


People who touched revisions under test:
  Julien Grall 
  Stefano Stabellini 

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

Re: [Xen-devel] Xen Introspection, KPTI, and CR3 bit 63 leads to guest VMENTRY failures during introspection

[Razvan Cojocaru]

On 01/26/2018 12:17 AM, Bitweasil . wrote:
> Razvan -
> 
> Yes, that patch resolves the issues.  Performance is abysmal (as
> expected with a CR3 switch on every syscall), but things behave properly.>
> Jan -
> 
> It turns out that unrelated code in my livepatch was causing the
> crashing when I filtered the high bit - I was not properly gating some
> other CR3 processing code in the livepatch, and that was causing the
> invalid opcode errors, not the filtered CR3 value.  You are correct that
> masking the bit should not cause any correctness issues, only
> performance issues.
> 
> Will one of you take up submitting this patch into the proper places? 
> I'm afraid I'm not very familiar with the Xen patch submission process.

Yes, I'll send a proper patch.


Thanks for pointing the issue out,
Razvan

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

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

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt 13 migrate-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  bb5400b20a0c2c2dce114075b09063038ad373db
baseline version:
 xen  2375832c7e51b67f076e6b07854c4a541cb4bdc3

Last test of basis   118326  2018-01-25 11:01:28 Z0 days
Failing since118327  2018-01-25 13:01:30 Z0 days4 attempts
Testing same since   118344  2018-01-25 20:01:07 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Daniel De Graaf 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Oleksandr Grytsov 
  Roger Pau Monné 
  Ross Lagerwall 
  Wei Liu 

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



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

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

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

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


Not pushing.


commit bb5400b20a0c2c2dce114075b09063038ad373db
Author: George Dunlap 
Date:   Mon Jan 8 15:50:53 2018 +

xl: Don't warn on using 'deprecated' mode selection

We generally support old config formats indefinintely (see the disk
format) without emitting warnings.

Signed-off-by: George Dunlap 
Acked-by: Ian Jackson 

commit 5b6b15acebfc6ef3dcb72385f328c985526a33e3
Author: Oleksandr Grytsov 
Date:   Wed Jan 24 19:19:59 2018 +0200

libxl: move ibxl_devid_to_device_... to LIBXL_DEFINE_DEVID_TO_DEVICE

Signed-off-by: Oleksandr Grytsov 
Acked-by: Wei Liu 

commit 32e31182ea3178ab04c8f66ee3b1465f0fc9b255
Author: Oleksandr Grytsov 
Date:   Wed Jan 24 19:19:58 2018 +0200

libxl: move libxl__device_from_ to LIBXL_DEFINE_DEVICE_FROM_TYPE

LIBXL_DEFINE_DEVICE_FROM_TYPE uses libxl__..._devtype.type to
be assigned as device and backend type.

Signed-off-by: Oleksandr Grytsov 
Acked-by: Wei Liu 

commit 4b3dd5439e24cc85c54cae01815bdb3e57234955
Author: Oleksandr Grytsov 
Date:   Wed Jan 24 19:19:57 2018 +0200

libxl: use libxl__device_kind in LIBXL_DEFINE_UPDATE_DEVID

Use libxl__..._devtype.type to update device id.

Signed-off-by: Oleksandr Grytsov 
Acked-by: Wei Liu 

commit 43a858403e9d0ce8c8282e3baade4b8e29c03b54
Author: Oleksandr Grytsov 
Date:   Wed Jan 24 19:19:56 2018 +0200

libxl: use libxl__device_kind to get device XS entry

On adding to XS name of device is taken from
libxl__device_kind enum. On getting device from XS
the name is hardcoded. It leads to potential
mistmatch errors. The patch is using libxl__device_kind
everywere to have one source of device name.

Signed-off-by: Oleksandr Grytsov 
Acked-by: Wei Liu 

commit 8155476765a5bdecea1534b46562cf28e0113a9a
Author: Wei Liu 
Date:  

Re: [Xen-devel] Xen Introspection, KPTI, and CR3 bit 63 leads to guest VMENTRY failures during introspection

[Bitweasil .]

Razvan -

Yes, that patch resolves the issues.  Performance is abysmal (as expected
with a CR3 switch on every syscall), but things behave properly.

Jan -

It turns out that unrelated code in my livepatch was causing the crashing
when I filtered the high bit - I was not properly gating some other CR3
processing code in the livepatch, and that was causing the invalid opcode
errors, not the filtered CR3 value.  You are correct that masking the bit
should not cause any correctness issues, only performance issues.

Will one of you take up submitting this patch into the proper places?  I'm
afraid I'm not very familiar with the Xen patch submission process.

Thank you!

-Bit



On Thu, Jan 25, 2018 at 8:07 AM, Razvan Cojocaru 
wrote:

> On 01/25/2018 12:31 AM, Bitweasil . wrote:
> > I've recently discovered that if you attempt to use introspection to
> > capture CR3 changes with the new KPTI enabled kernels, the guest dies
> > shortly after the start of introspection with failed VM entry due to
> > invalid guest state.
> >
> > I believe the invalid state here is the high bit being set in CR3 -
> > while this is how one indicates that PCID should not invalidate the
> > various page table caches, introspection leads to this being set in the
> > VMCS, which appears to be wrong.
> >
> > With the XenServer 4.7.1 code base (which is my working code base at the
> > moment), I have not found a way around this, as the
> > vm_event_set_registers function (xen/arch/x86/vm_event.c) does not set
> > the CR3 value, and vm_event_register_write_resume only allows inhibiting
> > the write, not writing a modified value.
> >
> > I've attempted several ways to work around this with a livepatch, and
> > have not (yet) been successful.
> >
> > Masking at the top of hvm_set_cr3 allows the guest to continue, but
> > appears to do the wrong thing with regards to the guest (tasks begin
> > dying quickly from invalid opcode errors).
> >
> > In any case, Andrew mentions that this appears to still be an issue in
> > staging, so this likely needs addressing.  At this point in time, I
> > believe guests with KPTI enabled cannot be introspected if that
> > introspection involves capturing CR3 changes.
> >
> > Please let me know if you need any more details on this issue!
>
> I've managed to reproduce the problem and this patch has fixed it for me
> with Xen staging:
>
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index db282b5..7be962e 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -2320,6 +2320,9 @@ int hvm_set_cr3(unsigned long value, bool_t
> may_defer)
>  }
>  }
>
> +if ( hvm_pcid_enabled(v) )
> +value &= ((1ull << 63) - 1);
> +
>  if ( hvm_paging_enabled(v) && !paging_mode_hap(v->domain) &&
>   (value != v->arch.hvm_vcpu.guest_cr[3]) )
>  {
>
> Would you mind giving this a spin and confirm it also solves your problems?
>
>
> Thanks,
> Razvan
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [xen-unstable-smoke bisection] complete build-arm64-xsm

[osstest service owner]

branch xen-unstable-smoke
xenbranch xen-unstable-smoke
job build-arm64-xsm
testid xen-build

Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  e8d461497d9e23b01f9f6aeb9ddf92ff2693a2c1
  Bug not present: 7f76b3a06aefc1f201f6bfcb593b5d0b3dc68bff
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/118345/


  commit e8d461497d9e23b01f9f6aeb9ddf92ff2693a2c1
  Author: Roger Pau Monné 
  Date:   Thu Jan 25 12:27:44 2018 +0100
  
  gcov: rename sysctl and functions
  
  Change gcov to cov (for internal interfaces) or coverage (for the
  public ones).
  
  Signed-off-by: Roger Pau Monné 
  Reviewed-by: Konrad Rzeszutek Wilk 
  Acked-by: Ian Jackson 
  Acked-by: Wei Liu 


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable-smoke/build-arm64-xsm.xen-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/xen-unstable-smoke/build-arm64-xsm.xen-build
 --summary-out=tmp/118345.bisection-summary --basis-template=118326 
--blessings=real,real-bisect xen-unstable-smoke build-arm64-xsm xen-build
Searching for failure / basis pass:
 118339 fail [host=laxton1] / 118326 ok.
Failure / basis pass flights: 118339 / 118326
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 2b033e396f4fa0981bae1213cdacd15775655a97 
5b6b15acebfc6ef3dcb72385f328c985526a33e3
Basis pass 2b033e396f4fa0981bae1213cdacd15775655a97 
2375832c7e51b67f076e6b07854c4a541cb4bdc3
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/qemu-xen.git#2b033e396f4fa0981bae1213cdacd15775655a97-2b033e396f4fa0981bae1213cdacd15775655a97
 
git://xenbits.xen.org/xen.git#2375832c7e51b67f076e6b07854c4a541cb4bdc3-5b6b15acebfc6ef3dcb72385f328c985526a33e3
Loaded 1001 nodes in revision graph
Searching for test results:
 118331 fail 2b033e396f4fa0981bae1213cdacd15775655a97 
5b6b15acebfc6ef3dcb72385f328c985526a33e3
 118326 pass 2b033e396f4fa0981bae1213cdacd15775655a97 
2375832c7e51b67f076e6b07854c4a541cb4bdc3
 118327 fail 2b033e396f4fa0981bae1213cdacd15775655a97 
5b6b15acebfc6ef3dcb72385f328c985526a33e3
 118330 pass 2b033e396f4fa0981bae1213cdacd15775655a97 
2375832c7e51b67f076e6b07854c4a541cb4bdc3
 118332 fail 2b033e396f4fa0981bae1213cdacd15775655a97 
5b6b15acebfc6ef3dcb72385f328c985526a33e3
 118333 fail 2b033e396f4fa0981bae1213cdacd15775655a97 
e8d461497d9e23b01f9f6aeb9ddf92ff2693a2c1
 118334 pass 2b033e396f4fa0981bae1213cdacd15775655a97 
642123c5123ff48d76d7ee376219ab50336636b9
 118335 pass 2b033e396f4fa0981bae1213cdacd15775655a97 
af2a20e40e92da6c5383b66bc507bdb7d15ff829
 118336 pass 2b033e396f4fa0981bae1213cdacd15775655a97 
7f76b3a06aefc1f201f6bfcb593b5d0b3dc68bff
 118338 fail 2b033e396f4fa0981bae1213cdacd15775655a97 
e8d461497d9e23b01f9f6aeb9ddf92ff2693a2c1
 118340 pass 2b033e396f4fa0981bae1213cdacd15775655a97 
7f76b3a06aefc1f201f6bfcb593b5d0b3dc68bff
 118342 fail 2b033e396f4fa0981bae1213cdacd15775655a97 
e8d461497d9e23b01f9f6aeb9ddf92ff2693a2c1
 118339 fail 2b033e396f4fa0981bae1213cdacd15775655a97 
5b6b15acebfc6ef3dcb72385f328c985526a33e3
 118343 pass 2b033e396f4fa0981bae1213cdacd15775655a97 
7f76b3a06aefc1f201f6bfcb593b5d0b3dc68bff
 118345 fail 2b033e396f4fa0981bae1213cdacd15775655a97 
e8d461497d9e23b01f9f6aeb9ddf92ff2693a2c1
Searching for interesting versions
 Result found: flight 118326 (pass), for basis pass
 Result found: flight 118327 (fail), for basis failure
 Repro found: flight 118330 (pass), for basis pass
 Repro found: flight 118331 (fail), for basis failure
 0 revisions at 2b033e396f4fa0981bae1213cdacd15775655a97 
7f76b3a06aefc1f201f6bfcb593b5d0b3dc68bff
No revisions left to test, checking graph state.
 Result found: flight 118336 (pass), for last pass
 Result found: flight 118338 (fail), for first failure
 Repro found: flight 118340 (pass), for last pass
 Repro found: flight 118342 (fail), for first failure
 Repro found: flight 118343 (pass), for last pass
 Repro found: flight 118345 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  e8d461497d9e23b01f9f6aeb9ddf92ff2693a2c1
  Bug not present: 7f76b3a06aefc1f201f6bfcb593b5d0b3dc68bff
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/118345/


  commit e8d461497d9e23b01f9f6aeb9ddf92ff2693a2c1
  Author: Roger Pau Monné 
  Date:   Thu Jan 25 12:27:44 2018 +0100
  
  gcov: rename sysctl and functions
  
  Change gcov to cov (for internal interfaces) or coverage (for the
  public ones).
 

Re: [Xen-devel] [PATCH] xen,x86: introduce tcg_errata

[Andrew Cooper]

On 25/01/18 19:43, Stefano Stabellini wrote:
> On Thu, 25 Jan 2018, Andrew Cooper wrote:
>> On 25/01/18 18:37, Stefano Stabellini wrote:
>>> The TCG emulator in QEMU is not good enough to pass the the tests in
>>> stub_selftest. Detect if Xen is running on TCG early, then drop the
>>> tests if it is the case.
>>>
>>> Signed-off-by: Stefano Stabellini 
>> I'm still opposed to this change.  The selftests demonstrate that TCG
>> doesn't work for an architectural area we depend, and simply pretending
>> its not buggy isn't ok.  If this were a piece of real hardware, it would
>> be blacklisted in a similar fashion to XSA-9.
>> I still haven't seen a convincing enough usecase to cause Xen to
>> proactively look for Qemu in all cases including release builds on real
>> hardware.
> Testing is a very good use case.

Testing is good. I approve of testing.

The problem is that what you are doing here is using a broken testing
tool and instead of fixing the tool, you're bodging Xen to pro-actively
search for your broken testing tool in all cases including release
builds, and ignore one of Xen's safety checks.

This is why I'm unconvinced by the argument.

~Andrew

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

Re: [Xen-devel] [PATCH 1/2] tools/ocaml: Drop coredump infrastructure

[Christian Lindig]

> On 25. Jan 2018, at 19:50, Andrew Cooper  wrote:
> 
> On 25/01/18 19:47, Christian Lindig wrote:
>> 
>>> On 19. Jan 2018, at 19:19, Andrew Cooper  wrote:
>>> 
>>> It is unused, and uses an obsolete hypercall which has never ever functioned
>>> for HVM guests.
>>> 
>>> Signed-off-by: Andrew Cooper 
>>> ---
>>> CC: Ian Jackson 
>>> CC: Wei Liu 
>>> CC: Christian Lindig 
>>> ---
>>> tools/ocaml/libs/xc/xenctrl.ml  | 86 
>>> -
>>> tools/ocaml/libs/xc/xenctrl.mli | 16 ---
>>> tools/ocaml/libs/xc/xenctrl_stubs.c | 41 --
>>> 3 files changed, 143 deletions(-)
>> I’m fine with this.
> 
> Is that an acked-by or reviewed-by then?
> 
> ~Andrew

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

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

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt 13 migrate-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  5b6b15acebfc6ef3dcb72385f328c985526a33e3
baseline version:
 xen  2375832c7e51b67f076e6b07854c4a541cb4bdc3

Last test of basis   118326  2018-01-25 11:01:28 Z0 days
Testing same since   118327  2018-01-25 13:01:30 Z0 days3 attempts


People who touched revisions under test:
  Andrew Cooper 
  Daniel De Graaf 
  Ian Jackson 
  Jan Beulich 
  Oleksandr Grytsov 
  Roger Pau Monné 
  Ross Lagerwall 
  Wei Liu 

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



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

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

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

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


Not pushing.


commit 5b6b15acebfc6ef3dcb72385f328c985526a33e3
Author: Oleksandr Grytsov 
Date:   Wed Jan 24 19:19:59 2018 +0200

libxl: move ibxl_devid_to_device_... to LIBXL_DEFINE_DEVID_TO_DEVICE

Signed-off-by: Oleksandr Grytsov 
Acked-by: Wei Liu 

commit 32e31182ea3178ab04c8f66ee3b1465f0fc9b255
Author: Oleksandr Grytsov 
Date:   Wed Jan 24 19:19:58 2018 +0200

libxl: move libxl__device_from_ to LIBXL_DEFINE_DEVICE_FROM_TYPE

LIBXL_DEFINE_DEVICE_FROM_TYPE uses libxl__..._devtype.type to
be assigned as device and backend type.

Signed-off-by: Oleksandr Grytsov 
Acked-by: Wei Liu 

commit 4b3dd5439e24cc85c54cae01815bdb3e57234955
Author: Oleksandr Grytsov 
Date:   Wed Jan 24 19:19:57 2018 +0200

libxl: use libxl__device_kind in LIBXL_DEFINE_UPDATE_DEVID

Use libxl__..._devtype.type to update device id.

Signed-off-by: Oleksandr Grytsov 
Acked-by: Wei Liu 

commit 43a858403e9d0ce8c8282e3baade4b8e29c03b54
Author: Oleksandr Grytsov 
Date:   Wed Jan 24 19:19:56 2018 +0200

libxl: use libxl__device_kind to get device XS entry

On adding to XS name of device is taken from
libxl__device_kind enum. On getting device from XS
the name is hardcoded. It leads to potential
mistmatch errors. The patch is using libxl__device_kind
everywere to have one source of device name.

Signed-off-by: Oleksandr Grytsov 
Acked-by: Wei Liu 

commit 8155476765a5bdecea1534b46562cf28e0113a9a
Author: Wei Liu 
Date:   Wed Jan 24 20:26:26 2018 +

x86: fix GET_STACK_END

AIUI the purpose of having the .if directive is to make GET_STACK_END
work with any general purpose registers. The code as-is would produce
the wrong result for r8. Fix it.

Signed-off-by: Wei Liu 
Acked-by: Andrew Cooper 

commit 6d53d4ce621ee80e732152a545a55ab6762a830b
Author: Roger Pau Monné 
Date:   Thu Jan 25 12:30:01 2018 +0100

coverage: introduce generic file

It 

Re: [Xen-devel] [PATCH 1/2] tools/ocaml: Drop coredump infrastructure

[Andrew Cooper]

On 25/01/18 19:47, Christian Lindig wrote:
>
>> On 19. Jan 2018, at 19:19, Andrew Cooper  wrote:
>>
>> It is unused, and uses an obsolete hypercall which has never ever functioned
>> for HVM guests.
>>
>> Signed-off-by: Andrew Cooper 
>> ---
>> CC: Ian Jackson 
>> CC: Wei Liu 
>> CC: Christian Lindig 
>> ---
>> tools/ocaml/libs/xc/xenctrl.ml  | 86 
>> -
>> tools/ocaml/libs/xc/xenctrl.mli | 16 ---
>> tools/ocaml/libs/xc/xenctrl_stubs.c | 41 --
>> 3 files changed, 143 deletions(-)
> I’m fine with this.

Is that an acked-by or reviewed-by then?

~Andrew

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

Re: [Xen-devel] [PATCH 1/2] tools/ocaml: Drop coredump infrastructure

[Christian Lindig]

> On 19. Jan 2018, at 19:19, Andrew Cooper  wrote:
> 
> It is unused, and uses an obsolete hypercall which has never ever functioned
> for HVM guests.
> 
> Signed-off-by: Andrew Cooper 
> ---
> CC: Ian Jackson 
> CC: Wei Liu 
> CC: Christian Lindig 
> ---
> tools/ocaml/libs/xc/xenctrl.ml  | 86 -
> tools/ocaml/libs/xc/xenctrl.mli | 16 ---
> tools/ocaml/libs/xc/xenctrl_stubs.c | 41 --
> 3 files changed, 143 deletions(-)

I’m fine with this.

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

Re: [Xen-devel] [PATCH] xen,x86: introduce tcg_errata

[Stefano Stabellini]

On Thu, 25 Jan 2018, Andrew Cooper wrote:
> On 25/01/18 18:37, Stefano Stabellini wrote:
> > The TCG emulator in QEMU is not good enough to pass the the tests in
> > stub_selftest. Detect if Xen is running on TCG early, then drop the
> > tests if it is the case.
> >
> > Signed-off-by: Stefano Stabellini 
> 
> I'm still opposed to this change.  The selftests demonstrate that TCG
> doesn't work for an architectural area we depend, and simply pretending
> its not buggy isn't ok.  If this were a piece of real hardware, it would
> be blacklisted in a similar fashion to XSA-9.

> I still haven't seen a convincing enough usecase to cause Xen to
> proactively look for Qemu in all cases including release builds on real
> hardware.

Testing is a very good use case. It doesn't have to replace testing on
real hardware, it can complement it. You can try it yourself, it might
become your new favorite test environment :-) Just launch
qemu-system-x86_64 with -cpu qemu64,+svm. FYI this is my full command
line:

qemu-system-x86_64 -m 4G -smp 2 -cpu qemu64,+svm \
-nographic -serial stdio -monitor none \
--bios /usr/share/ovmf/OVMF.fd \
-netdev user,id=hostnet0 -device 
virtio-net-pci,netdev=hostnet0,bus=pci.0,addr=0x3 \
-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 \
-drive file=$DISK,if=none,id=drive-virtio-disk0,format=raw,cache=none \
-device 
virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
 \
-device virtio-rng-pci


I haven't investigated yet the QEMU side of the problem. I can dig
deeper there, then, once we understand the full extent of the issue,
we could decide what to do with this patch. However, I performed a few
tests so far and I haven't seen any other issues. I can start HVM and
PVH guests without issues.___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 4/7] xen/arm32: Add skeleton to harden branch predictor aliasing attacks

[Stefano Stabellini]

On Thu, 25 Jan 2018, Julien Grall wrote:
> Hi,
> 
> On 25/01/18 18:45, Stefano Stabellini wrote:
> > On Thu, 25 Jan 2018, Julien Grall wrote:
> > > Hi Stefano,
> > > 
> > > On 24/01/18 23:54, Stefano Stabellini wrote:
> > > > On Fri, 19 Jan 2018, Julien Grall wrote:
> > > > > Aliasing attacked against CPU branch predictors can allow an attacker
> > > > > to
> > > > > redirect speculative control flow on some CPUs and potentially divulge
> > > > > information from one context to another.
> > > > > 
> > > > > This patch adds initiatial skeleton code behind a new Kconfig option
> > > > > to enable implementation-specific mitigations against these attacks
> > > > > for CPUs that are affected.
> > > > > 
> > > > > Most of mitigations will have to be applied when entering to the
> > > > > hypervisor from the guest context.
> > > > > 
> > > > > Because the attack is against branch predictor, it is not possible to
> > > > > safely use branch instruction before the mitigation is applied.
> > > > > Therefore this has to be done in the vector entry before jump to the
> > > > > helper handling a given exception.
> > > > > 
> > > > > However, on arm32, each vector contain a single instruction. This
> > > > > means
> > > > > that the hardened vector tables may rely on the state of registers
> > > > > that
> > > > > does not hold when in the hypervisor (e.g SP is 8 bytes aligned).
> > > > > Therefore hypervisor code running with guest vectors table should be
> > > > > minimized and always have interrupts masked to reduce the risk to use
> > > > > them.
> > > > > 
> > > > > This patch provides an infrastructure to switch vector tables before
> > > > > entering to the guest and when leaving it.
> > > > > 
> > > > > Note that alternative could have been used, but older Xen (4.8 or
> > > > > earlier) doesn't have support. So avoid using alternative to ease
> > > > > backporting.
> > > > > 
> > > > > This is part of XSA-254.
> > > > > 
> > > > > Signed-off-by: Julien Grall 
> > > > 
> > > > I only have a couple of questions. It looks good.
> > > > 
> > > > 
> > > > > ---
> > > > >xen/arch/arm/Kconfig   |  3 +++
> > > > >xen/arch/arm/arm32/entry.S | 41
> > > > > -
> > > > >xen/arch/arm/cpuerrata.c   | 30 ++
> > > > >3 files changed, 73 insertions(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> > > > > index 06fd85cc77..2782ee6589 100644
> > > > > --- a/xen/arch/arm/Kconfig
> > > > > +++ b/xen/arch/arm/Kconfig
> > > > > @@ -191,6 +191,9 @@ config HARDEN_BRANCH_PREDICTOR
> > > > >config ARM64_HARDEN_BRANCH_PREDICTOR
> > > > >def_bool y if ARM_64 && HARDEN_BRANCH_PREDICTOR
> > > > >+config ARM32_HARDEN_BRANCH_PREDICTOR
> > > > > +def_bool y if ARM_32 && HARDEN_BRANCH_PREDICTOR
> > > > > +
> > > > >source "common/Kconfig"
> > > > >  source "drivers/Kconfig"
> > > > > diff --git a/xen/arch/arm/arm32/entry.S b/xen/arch/arm/arm32/entry.S
> > > > > index c2fad5fe9b..54a1733f87 100644
> > > > > --- a/xen/arch/arm/arm32/entry.S
> > > > > +++ b/xen/arch/arm/arm32/entry.S
> > > > > @@ -34,6 +34,20 @@
> > > > >blne save_guest_regs
> > > > >  save_guest_regs:
> > > > > +#ifdef CONFIG_ARM32_HARDEN_BRANCH_PREDICTOR
> > > > > +/*
> > > > > + * Restore vectors table to the default as it may have been
> > > > > + * changed when returning to the guest (see
> > > > > + * return_to_hypervisor). We need to do that early (e.g
> > > > > before
> > > > > + * any interrupts are unmasked) because hardened vectors
> > > > > requires
> > > > > + * SP to be 8 bytes aligned. This does not hold when running
> > > > > in
> > > > > + * the hypervisor.
> > > > > + */
> > > > > +ldr r1, =hyp_traps_vector
> > > > > +mcr p15, 4, r1, c12, c0, 0
> > > > > +isb
> > > > > +#endif
> > > > > +
> > > > >ldr r11, =0x  /* Clobber SP which is only valid for
> > > > > hypervisor frames. */
> > > > >str r11, [sp, #UREGS_sp]
> > > > >SAVE_ONE_BANKED(SP_usr)
> > > > > @@ -179,12 +193,37 @@ return_to_guest:
> > > > >RESTORE_ONE_BANKED(R11_fiq); RESTORE_ONE_BANKED(R12_fiq);
> > > > >/* Fall thru */
> > > > >return_to_hypervisor:
> > > > > -cpsid i
> > > > > +cpsid ai
> > > > 
> > > > Why?
> > > 
> > > Asynchronous abort is a kind of interrupt, as we are going to switch to
> > > the
> > > hardened vector tables you don't want an interrupt to come up.
> > > 
> > > This is because the hardened vector tables requires SP to be 8 bytes
> > > aligned.
> > > When in the hypervisor, and particularly when restoring the register (as
> > > below), this assumption does not hold.
> > > 
> > > So masking all interrupts (as mentioned a few time within the patch and
> > > the
> > > commit message) will reduce the risk to 

Re: [Xen-devel] [PATCH 5/7] xen/arm32: Invalidate BTB on guest exit for Cortex A17 and 12

[Stefano Stabellini]

On Thu, 25 Jan 2018, Julien Grall wrote:
> Hi Stefano,
> 
> On 25/01/18 01:02, Stefano Stabellini wrote:
> > On Fri, 19 Jan 2018, Julien Grall wrote:
> > > In order to avoid aliasing attackes agains the branch predictor, let's
> > > invalidate the BTB on guest exist. This is made complicated by the fact
> > > that we cannot take a branch invalidating the BTB.
> > > 
> > > This is based on the first version posrted by Marc Zyngier on Linux-arm
> > > mailing list (see [1]).
> > > 
> > > This is part of XSA-254.
> > > 
> > > Signed-off-by: Marc Zyngier 
> > > Signed-off-by: Julien Grall 
> > > 
> > > [1] https://www.spinics.net/lists/arm-kernel/msg627032.html
> > > ---
> > >   xen/arch/arm/arm32/entry.S | 55
> > > ++
> > >   xen/arch/arm/cpuerrata.c   | 19 
> > >   2 files changed, 74 insertions(+)
> > > 
> > > diff --git a/xen/arch/arm/arm32/entry.S b/xen/arch/arm/arm32/entry.S
> > > index 54a1733f87..c6ec0aa399 100644
> > > --- a/xen/arch/arm/arm32/entry.S
> > > +++ b/xen/arch/arm/arm32/entry.S
> > > @@ -160,6 +160,61 @@ GLOBAL(hyp_traps_vector)
> > >   b trap_irq  /* 0x18 - IRQ */
> > >   b trap_fiq  /* 0x1c - FIQ */
> > >   +.align 5
> > > +GLOBAL(hyp_traps_vector_bp_inv)
> > > +/*
> > > + * We encode the exception entry in the bottom 3 bits of
> > > + * SP, and we have to guarantee to be 8 bytes aligned.
> > > + */
> > > +add sp, sp, #1  /* Reset7 */
> > > +add sp, sp, #1  /* Undef6 */
> > > +add sp, sp, #1  /* Hypervisor Call  5 */
> > > +add sp, sp, #1  /* Prefetch abort   4 */
> > > +add sp, sp, #1  /* Data abort   3 */
> > > +add sp, sp, #1  /* Hypervisor   2 */
> > > +add sp, sp, #1  /* IRQ  1 */
> > > +nop /* FIQ  0 */
> > 
> > Clever! Things that you don't read every day :-)
> 
> Thanks Marc for the idea :).
> 
> > 
> > 
> > > +mcr  p15, 0, r0, c7, c5, 6   /* BPIALL */
> > > +isb
> > > +
> > > +/*
> > > + * As we cannot use any temporary registers and cannot
> > > + * clobber SP, we can decode the exception entry using
> > > + * an unrolled binary search.
> > > + */
> > > +tst sp, #4
> > > +bne 1f
> > > +
> > > +tst sp, #2
> > > +bne 3f
> > > +
> > > +tst sp, #1
> > > +bic sp, sp, #0x7
> > > +bne trap_irq
> > > +b   trap_fiq
> > 
> > I might be confused, but this is the case where sp == 0x7, right?
> > Shouldn't we have b trap_reset here?
> > 
> > Similarly the branch just above corresponds to 0x6, which should be
> > bne trap_undefined_instruction.
> > 
> > What am I getting wrong?
> 
> The tst instruction performs a bitwise AND on a register value (here sp). The
> result will be used to update the condition flags.
> 
> So with tst sp, #4 the result will either be 0x100 or 0x000. The former will
> clear Z flag while the latter set Z flag.
> 
> This means that bne will branch only when bit 2 is set. So the only way to end
> here is because the first 3-bit are equal to 0x00X. This corresponds to
> IRQ/FIQ vector.

I got it the other way around, thanks for the explanation :-)

Signed-off-by: Stefano Stabellini 

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

[Xen-devel] [PING] Re: [PATCH 1/2] tools/ocaml: Drop coredump infrastructure

[Andrew Cooper]

On 19/01/18 19:19, Andrew Cooper wrote:
> It is unused, and uses an obsolete hypercall which has never ever functioned
> for HVM guests.
>
> Signed-off-by: Andrew Cooper 
> ---
> CC: Ian Jackson 
> CC: Wei Liu 
> CC: Christian Lindig 
> ---
>  tools/ocaml/libs/xc/xenctrl.ml  | 86 
> -
>  tools/ocaml/libs/xc/xenctrl.mli | 16 ---
>  tools/ocaml/libs/xc/xenctrl_stubs.c | 41 --
>  3 files changed, 143 deletions(-)
>
> diff --git a/tools/ocaml/libs/xc/xenctrl.ml b/tools/ocaml/libs/xc/xenctrl.ml
> index 9116aa2..a3ba488 100644
> --- a/tools/ocaml/libs/xc/xenctrl.ml
> +++ b/tools/ocaml/libs/xc/xenctrl.ml
> @@ -126,14 +126,6 @@ exception Error of string
>  
>  type handle
>  
> -(* this is only use by coredumping *)
> -external sizeof_core_header: unit -> int
> -   = "stub_sizeof_core_header"
> -external sizeof_vcpu_guest_context: unit -> int
> -   = "stub_sizeof_vcpu_guest_context"
> -external sizeof_xen_pfn: unit -> int = "stub_sizeof_xen_pfn"
> -(* end of use *)
> -
>  external interface_open: unit -> handle = "stub_xc_interface_open"
>  external interface_close: handle -> unit = "stub_xc_interface_close"
>  
> @@ -275,84 +267,6 @@ external get_cpu_featureset : handle -> featureset_index 
> -> int64 array = "stub_
>  external watchdog : handle -> int -> int32 -> int
>= "stub_xc_watchdog"
>  
> -(* core dump structure *)
> -type core_magic = Magic_hvm | Magic_pv
> -
> -type core_header = {
> - xch_magic: core_magic;
> - xch_nr_vcpus: int;
> - xch_nr_pages: nativeint;
> - xch_index_offset: int64;
> - xch_ctxt_offset: int64;
> - xch_pages_offset: int64;
> -}
> -
> -external marshall_core_header: core_header -> string = 
> "stub_marshall_core_header"
> -
> -(* coredump *)
> -let coredump xch domid fd =
> - let dump s =
> - let wd = Unix.write fd s 0 (String.length s) in
> - if wd <> String.length s then
> - failwith "error while writing";
> - in
> -
> - let info = domain_getinfo xch domid in
> -
> - let nrpages = info.total_memory_pages in
> - let ctxt = Array.make info.max_vcpu_id None in
> - let nr_vcpus = ref 0 in
> - for i = 0 to info.max_vcpu_id - 1
> - do
> - ctxt.(i) <- try
> - let v = vcpu_context_get xch domid i in
> - incr nr_vcpus;
> - Some v
> - with _ -> None
> - done;
> -
> - (* FIXME page offset if not rounded to sup *)
> - let page_offset =
> - Int64.add
> - (Int64.of_int (sizeof_core_header () +
> -  (sizeof_vcpu_guest_context () * !nr_vcpus)))
> - (Int64.of_nativeint (
> - Nativeint.mul
> - (Nativeint.of_int (sizeof_xen_pfn ()))
> - nrpages)
> - )
> - in
> -
> - let header = {
> - xch_magic = if info.hvm_guest then Magic_hvm else Magic_pv;
> - xch_nr_vcpus = !nr_vcpus;
> - xch_nr_pages = nrpages;
> - xch_ctxt_offset = Int64.of_int (sizeof_core_header ());
> - xch_index_offset = Int64.of_int (sizeof_core_header ()
> - + sizeof_vcpu_guest_context ());
> - xch_pages_offset = page_offset;
> - } in
> -
> - dump (marshall_core_header header);
> - for i = 0 to info.max_vcpu_id - 1
> - do
> - match ctxt.(i) with
> - | None -> ()
> - | Some ctxt_i -> dump ctxt_i
> - done;
> - let pfns = domain_get_pfn_list xch domid nrpages in
> - if Array.length pfns <> Nativeint.to_int nrpages then
> - failwith "could not get the page frame list";
> -
> - let page_size = Xenmmap.getpagesize () in
> - for i = 0 to Nativeint.to_int nrpages - 1
> - do
> - let page = map_foreign_range xch domid page_size pfns.(i) in
> - let data = Xenmmap.read page 0 page_size in
> - Xenmmap.unmap page;
> - dump data
> - done
> -
>  (* ** Misc ** *)
>  
>  (**
> diff --git a/tools/ocaml/libs/xc/xenctrl.mli b/tools/ocaml/libs/xc/xenctrl.mli
> index 54c099c..ed02124 100644
> --- a/tools/ocaml/libs/xc/xenctrl.mli
> +++ b/tools/ocaml/libs/xc/xenctrl.mli
> @@ -95,10 +95,6 @@ type domain_create_flag = CDF_HVM | CDF_HAP
>  
>  exception Error of string
>  type handle
> -external sizeof_core_header : unit -> int = "stub_sizeof_core_header"
> -external sizeof_vcpu_guest_context : unit -> int
> -  = "stub_sizeof_vcpu_guest_context"
> -external sizeof_xen_pfn : unit -> int = "stub_sizeof_xen_pfn"
>  external interface_open : unit -> handle = "stub_xc_interface_open"
>  external interface_close : handle -> unit = 

[Xen-devel] [PING] [PATCH 2/2] xen: Drop DOMCTL_getmemlist and xc_get_pfn_list()

[Andrew Cooper]

On 19/01/18 19:19, Andrew Cooper wrote:
> c/s 4ddf474e2 "tools/xen-mceinj: Pass in GPA when injecting through
> MSR_MCI_ADDR" removed the remaining user of hypercall.
>
> It has been listed as broken, deprecated and wont-fix since XSA-74, so take
> this opportunity to remove it completely.
>
> Signed-off-by: Andrew Cooper 
> ---
> CC: Jan Beulich 
> CC: Ian Jackson 
> CC: Wei Liu 
> CC: Christian Lindig 
> ---
>  tools/libxc/include/xenctrl.h   |  7 -
>  tools/libxc/xc_private.c| 27 --
>  tools/ocaml/libs/xc/xenctrl.ml  |  3 --
>  tools/ocaml/libs/xc/xenctrl.mli |  3 --
>  tools/ocaml/libs/xc/xenctrl_stubs.c | 32 -
>  xen/arch/x86/domctl.c   | 56 
> -
>  xen/include/public/domctl.h |  2 +-
>  7 files changed, 1 insertion(+), 129 deletions(-)
>
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index ecb0312..30171a2 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -1520,13 +1520,6 @@ unsigned long 
> xc_translate_foreign_address(xc_interface *xch, uint32_t dom,
> int vcpu, unsigned long long 
> virt);
>  
>  
> -/**
> - * DEPRECATED.  Avoid using this, as it does not correctly account for PFNs
> - * without a backing MFN.
> - */
> -int xc_get_pfn_list(xc_interface *xch, uint32_t domid, uint64_t *pfn_buf,
> -unsigned long max_pfns);
> -
>  int xc_copy_to_domain_page(xc_interface *xch, uint32_t domid,
> unsigned long dst_pfn, const char *src_page);
>  
> diff --git a/tools/libxc/xc_private.c b/tools/libxc/xc_private.c
> index 36ead5f..fcda981 100644
> --- a/tools/libxc/xc_private.c
> +++ b/tools/libxc/xc_private.c
> @@ -387,33 +387,6 @@ int xc_machphys_mfn_list(xc_interface *xch,
>  return rc;
>  }
>  
> -int xc_get_pfn_list(xc_interface *xch,
> -uint32_t domid,
> -uint64_t *pfn_buf,
> -unsigned long max_pfns)
> -{
> -DECLARE_DOMCTL;
> -DECLARE_HYPERCALL_BOUNCE(pfn_buf, max_pfns * sizeof(*pfn_buf), 
> XC_HYPERCALL_BUFFER_BOUNCE_OUT);
> -int ret;
> -
> -if ( xc_hypercall_bounce_pre(xch, pfn_buf) )
> -{
> -PERROR("xc_get_pfn_list: pfn_buf bounce failed");
> -return -1;
> -}
> -
> -domctl.cmd = XEN_DOMCTL_getmemlist;
> -domctl.domain = domid;
> -domctl.u.getmemlist.max_pfns = max_pfns;
> -set_xen_guest_handle(domctl.u.getmemlist.buffer, pfn_buf);
> -
> -ret = do_domctl(xch, );
> -
> -xc_hypercall_bounce_post(xch, pfn_buf);
> -
> -return (ret < 0) ? -1 : domctl.u.getmemlist.num_pfns;
> -}
> -
>  long xc_get_tot_pages(xc_interface *xch, uint32_t domid)
>  {
>  xc_dominfo_t info;
> diff --git a/tools/ocaml/libs/xc/xenctrl.ml b/tools/ocaml/libs/xc/xenctrl.ml
> index a3ba488..1a01faa 100644
> --- a/tools/ocaml/libs/xc/xenctrl.ml
> +++ b/tools/ocaml/libs/xc/xenctrl.ml
> @@ -244,9 +244,6 @@ external map_foreign_range: handle -> domid -> int
>   -> nativeint -> Xenmmap.mmap_interface
> = "stub_map_foreign_range"
>  
> -external domain_get_pfn_list: handle -> domid -> nativeint -> nativeint array
> -   = "stub_xc_domain_get_pfn_list"
> -
>  external domain_assign_device: handle -> domid -> (int * int * int * int) -> 
> unit
> = "stub_xc_domain_assign_device"
>  external domain_deassign_device: handle -> domid -> (int * int * int * int) 
> -> unit
> diff --git a/tools/ocaml/libs/xc/xenctrl.mli b/tools/ocaml/libs/xc/xenctrl.mli
> index ed02124..7d2e6f0 100644
> --- a/tools/ocaml/libs/xc/xenctrl.mli
> +++ b/tools/ocaml/libs/xc/xenctrl.mli
> @@ -154,9 +154,6 @@ external domain_memory_increase_reservation :
>  external map_foreign_range :
>handle -> domid -> int -> nativeint -> Xenmmap.mmap_interface
>= "stub_map_foreign_range"
> -external domain_get_pfn_list :
> -  handle -> domid -> nativeint -> nativeint array
> -  = "stub_xc_domain_get_pfn_list"
>  
>  external domain_assign_device: handle -> domid -> (int * int * int * int) -> 
> unit
> = "stub_xc_domain_assign_device"
> diff --git a/tools/ocaml/libs/xc/xenctrl_stubs.c 
> b/tools/ocaml/libs/xc/xenctrl_stubs.c
> index d1801e1..f97070c 100644
> --- a/tools/ocaml/libs/xc/xenctrl_stubs.c
> +++ b/tools/ocaml/libs/xc/xenctrl_stubs.c
> @@ -1009,38 +1009,6 @@ CAMLprim value stub_shadow_allocation_set(value xch, 
> value domid,
>   CAMLreturn(Val_unit);
>  }
>  
> -CAMLprim value stub_xc_domain_get_pfn_list(value xch, value domid,
> -   value nr_pfns)
> -{
> - CAMLparam3(xch, domid, nr_pfns);
> - CAMLlocal2(array, v);
> - unsigned long c_nr_pfns;
> - long ret, i;
> - uint64_t *c_array;
> -
> - c_nr_pfns = 

[Xen-devel] [PATCH RFC] x86/irq: Fix maybe uninitalised issue in map_domain_pirq()

[Andrew Cooper]

When compiling at -O3, GCC 7.2 reports:

  irq.c: In function 'map_domain_pirq':
  irq.c:1271:20: error: 'info' may be used uninitialized in this function 
[-Werror=maybe-uninitialized]
   pirq->arch.irq = irq;
   ~~~^
  irq.c:1917:18: note: 'info' was declared here
   struct pirq *info;
^~~~

This is a real issue, and is caused by different error style confusion in
prepare_domain_irq_pirq().  A positive return value from radix_tree_insert()
will take the early error path, and report success to map_domain_pirq().

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

I don't think this is the right change to make, but initialising note to NULL
is definitely the wrong thing to do.  Thoughts?
---
 xen/arch/x86/irq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c
index 87ef2e8..b613733 100644
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -1249,7 +1249,7 @@ static int prepare_domain_irq_pirq(struct domain *d, int 
irq, int pirq,
 radix_tree_int_to_ptr(0));
 struct pirq *info;
 
-if ( err && err != -EEXIST )
+if ( err < 0 && err != -EEXIST )
 return err;
 info = pirq_get_info(d, pirq);
 if ( !info )
-- 
2.1.4


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

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

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-multivcpu broken
 test-armhf-armhf-xl-multivcpu  4 host-install(4)   broken REGR. vs. 118287

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

Last test of basis   118287  2018-01-23 16:14:02 Z2 days
Testing same since   118308  2018-01-24 15:44:37 Z1 days1 attempts


People who touched revisions under test:
  Alistair Francis 
  Christian Borntraeger 
  Claudio Imbrenda 
  Cornelia Huck 
  David Hildenbrand 
  Peter Maydell 

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

Re: [Xen-devel] [PATCH 4/7] xen/arm32: Add skeleton to harden branch predictor aliasing attacks

[Julien Grall]

Hi,

On 25/01/18 18:45, Stefano Stabellini wrote:

On Thu, 25 Jan 2018, Julien Grall wrote:

Hi Stefano,

On 24/01/18 23:54, Stefano Stabellini wrote:

On Fri, 19 Jan 2018, Julien Grall wrote:

Aliasing attacked against CPU branch predictors can allow an attacker to
redirect speculative control flow on some CPUs and potentially divulge
information from one context to another.

This patch adds initiatial skeleton code behind a new Kconfig option
to enable implementation-specific mitigations against these attacks
for CPUs that are affected.

Most of mitigations will have to be applied when entering to the
hypervisor from the guest context.

Because the attack is against branch predictor, it is not possible to
safely use branch instruction before the mitigation is applied.
Therefore this has to be done in the vector entry before jump to the
helper handling a given exception.

However, on arm32, each vector contain a single instruction. This means
that the hardened vector tables may rely on the state of registers that
does not hold when in the hypervisor (e.g SP is 8 bytes aligned).
Therefore hypervisor code running with guest vectors table should be
minimized and always have interrupts masked to reduce the risk to use
them.

This patch provides an infrastructure to switch vector tables before
entering to the guest and when leaving it.

Note that alternative could have been used, but older Xen (4.8 or
earlier) doesn't have support. So avoid using alternative to ease
backporting.

This is part of XSA-254.

Signed-off-by: Julien Grall 


I only have a couple of questions. It looks good.



---
   xen/arch/arm/Kconfig   |  3 +++
   xen/arch/arm/arm32/entry.S | 41
-
   xen/arch/arm/cpuerrata.c   | 30 ++
   3 files changed, 73 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 06fd85cc77..2782ee6589 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -191,6 +191,9 @@ config HARDEN_BRANCH_PREDICTOR
   config ARM64_HARDEN_BRANCH_PREDICTOR
   def_bool y if ARM_64 && HARDEN_BRANCH_PREDICTOR
   +config ARM32_HARDEN_BRANCH_PREDICTOR
+def_bool y if ARM_32 && HARDEN_BRANCH_PREDICTOR
+
   source "common/Kconfig"
 source "drivers/Kconfig"
diff --git a/xen/arch/arm/arm32/entry.S b/xen/arch/arm/arm32/entry.S
index c2fad5fe9b..54a1733f87 100644
--- a/xen/arch/arm/arm32/entry.S
+++ b/xen/arch/arm/arm32/entry.S
@@ -34,6 +34,20 @@
   blne save_guest_regs
 save_guest_regs:
+#ifdef CONFIG_ARM32_HARDEN_BRANCH_PREDICTOR
+/*
+ * Restore vectors table to the default as it may have been
+ * changed when returning to the guest (see
+ * return_to_hypervisor). We need to do that early (e.g before
+ * any interrupts are unmasked) because hardened vectors requires
+ * SP to be 8 bytes aligned. This does not hold when running in
+ * the hypervisor.
+ */
+ldr r1, =hyp_traps_vector
+mcr p15, 4, r1, c12, c0, 0
+isb
+#endif
+
   ldr r11, =0x  /* Clobber SP which is only valid for
hypervisor frames. */
   str r11, [sp, #UREGS_sp]
   SAVE_ONE_BANKED(SP_usr)
@@ -179,12 +193,37 @@ return_to_guest:
   RESTORE_ONE_BANKED(R11_fiq); RESTORE_ONE_BANKED(R12_fiq);
   /* Fall thru */
   return_to_hypervisor:
-cpsid i
+cpsid ai


Why?


Asynchronous abort is a kind of interrupt, as we are going to switch to the
hardened vector tables you don't want an interrupt to come up.

This is because the hardened vector tables requires SP to be 8 bytes aligned.
When in the hypervisor, and particularly when restoring the register (as
below), this assumption does not hold.

So masking all interrupts (as mentioned a few time within the patch and the
commit message) will reduce the risk to use the hardened vectors. I say reduce
because you may have receive data abort (imagine an unlikely error in the few
instructions to restore state).

It is also why switching vector tables are done very early in entry path and
very late in the exit path.


All right, thanks for the explanation. Please add "and mask asynchronous
aborts" in the commit message.


I am not surely what you exactly suggest here. The commit message 
currently contains:


"Therefore hypervisor code running with guest vectors table should be
minimized and always have interrupts masked to reduce the risk to use
them."

What are you suggesting?

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v10 09/11] x86/ctxt: Issue a speculation barrier between vcpu contexts

[Dario Faggioli]

On Thu, 2018-01-25 at 16:09 +, Andrew Cooper wrote:
> On 25/01/18 15:57, Jan Beulich wrote:
> > > > > 
> > For the record, the overwhelming majority of calls to
> > __sync_local_execstate() being responsible for the behavior
> > come from invalidate_interrupt(), which suggests to me that
> > there's a meaningful number of cases where a vCPU is migrated
> > to another CPU and then back, without another vCPU having
> > run on the original CPU in between. If I'm not wrong with this,
> > I have to question why the vCPU is migrated then in the first
> > place.
> 
> This is a known (mis)feature of the Credit scheduler.  When a PCPU
> goes
> idle, it aggressively steals work from the adjacent cpus, even if the
> adjacent cpu only has a single vcpu to run and is running it.
> 
> XenServer has this gross hack which makes aggregate networking
> measurements far far better
> 
> https://github.com/xenserver/xen.pg/blob/XS-7.1.x/master/sched-credit
> 1-use-per-pcpu-runqueue-count.patch
> 
> Dario made a different fix to Credit1 upstream which was supposed to
> resolve this behaviour (although I can't locate the patch by a list
> of
> titles), but based on these observations, I'd say the misfeature
> hasn't
> been fixed.
> 
Yes, it's 341450eaf753 ("xen: credit1: increase efficiency and
scalability of load balancing."), and that commit and the XenServer
patch are functionally equivalent.

So, I'm not convinced about that being the actual cause of the
described behaviour. Tracing would be the way to tell (hopefully) for
sure.

Regards,
Dario

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

Re: [Xen-devel] [PATCH 4/7] xen/arm32: Add skeleton to harden branch predictor aliasing attacks

[Stefano Stabellini]

On Thu, 25 Jan 2018, Julien Grall wrote:
> Hi Stefano,
> 
> On 24/01/18 23:54, Stefano Stabellini wrote:
> > On Fri, 19 Jan 2018, Julien Grall wrote:
> > > Aliasing attacked against CPU branch predictors can allow an attacker to
> > > redirect speculative control flow on some CPUs and potentially divulge
> > > information from one context to another.
> > > 
> > > This patch adds initiatial skeleton code behind a new Kconfig option
> > > to enable implementation-specific mitigations against these attacks
> > > for CPUs that are affected.
> > > 
> > > Most of mitigations will have to be applied when entering to the
> > > hypervisor from the guest context.
> > > 
> > > Because the attack is against branch predictor, it is not possible to
> > > safely use branch instruction before the mitigation is applied.
> > > Therefore this has to be done in the vector entry before jump to the
> > > helper handling a given exception.
> > > 
> > > However, on arm32, each vector contain a single instruction. This means
> > > that the hardened vector tables may rely on the state of registers that
> > > does not hold when in the hypervisor (e.g SP is 8 bytes aligned).
> > > Therefore hypervisor code running with guest vectors table should be
> > > minimized and always have interrupts masked to reduce the risk to use
> > > them.
> > > 
> > > This patch provides an infrastructure to switch vector tables before
> > > entering to the guest and when leaving it.
> > > 
> > > Note that alternative could have been used, but older Xen (4.8 or
> > > earlier) doesn't have support. So avoid using alternative to ease
> > > backporting.
> > > 
> > > This is part of XSA-254.
> > > 
> > > Signed-off-by: Julien Grall 
> > 
> > I only have a couple of questions. It looks good.
> > 
> > 
> > > ---
> > >   xen/arch/arm/Kconfig   |  3 +++
> > >   xen/arch/arm/arm32/entry.S | 41
> > > -
> > >   xen/arch/arm/cpuerrata.c   | 30 ++
> > >   3 files changed, 73 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> > > index 06fd85cc77..2782ee6589 100644
> > > --- a/xen/arch/arm/Kconfig
> > > +++ b/xen/arch/arm/Kconfig
> > > @@ -191,6 +191,9 @@ config HARDEN_BRANCH_PREDICTOR
> > >   config ARM64_HARDEN_BRANCH_PREDICTOR
> > >   def_bool y if ARM_64 && HARDEN_BRANCH_PREDICTOR
> > >   +config ARM32_HARDEN_BRANCH_PREDICTOR
> > > +def_bool y if ARM_32 && HARDEN_BRANCH_PREDICTOR
> > > +
> > >   source "common/Kconfig"
> > > source "drivers/Kconfig"
> > > diff --git a/xen/arch/arm/arm32/entry.S b/xen/arch/arm/arm32/entry.S
> > > index c2fad5fe9b..54a1733f87 100644
> > > --- a/xen/arch/arm/arm32/entry.S
> > > +++ b/xen/arch/arm/arm32/entry.S
> > > @@ -34,6 +34,20 @@
> > >   blne save_guest_regs
> > > save_guest_regs:
> > > +#ifdef CONFIG_ARM32_HARDEN_BRANCH_PREDICTOR
> > > +/*
> > > + * Restore vectors table to the default as it may have been
> > > + * changed when returning to the guest (see
> > > + * return_to_hypervisor). We need to do that early (e.g before
> > > + * any interrupts are unmasked) because hardened vectors requires
> > > + * SP to be 8 bytes aligned. This does not hold when running in
> > > + * the hypervisor.
> > > + */
> > > +ldr r1, =hyp_traps_vector
> > > +mcr p15, 4, r1, c12, c0, 0
> > > +isb
> > > +#endif
> > > +
> > >   ldr r11, =0x  /* Clobber SP which is only valid for
> > > hypervisor frames. */
> > >   str r11, [sp, #UREGS_sp]
> > >   SAVE_ONE_BANKED(SP_usr)
> > > @@ -179,12 +193,37 @@ return_to_guest:
> > >   RESTORE_ONE_BANKED(R11_fiq); RESTORE_ONE_BANKED(R12_fiq);
> > >   /* Fall thru */
> > >   return_to_hypervisor:
> > > -cpsid i
> > > +cpsid ai
> > 
> > Why?
> 
> Asynchronous abort is a kind of interrupt, as we are going to switch to the
> hardened vector tables you don't want an interrupt to come up.
> 
> This is because the hardened vector tables requires SP to be 8 bytes aligned.
> When in the hypervisor, and particularly when restoring the register (as
> below), this assumption does not hold.
> 
> So masking all interrupts (as mentioned a few time within the patch and the
> commit message) will reduce the risk to use the hardened vectors. I say reduce
> because you may have receive data abort (imagine an unlikely error in the few
> instructions to restore state).
> 
> It is also why switching vector tables are done very early in entry path and
> very late in the exit path.

All right, thanks for the explanation. Please add "and mask asynchronous
aborts" in the commit message.


> > 
> > 
> > >   ldr lr, [sp, #UREGS_lr]
> > >   ldr r11, [sp, #UREGS_pc]
> > >   msr ELR_hyp, r11
> > >   ldr r11, [sp, #UREGS_cpsr]
> > >   msr SPSR_hyp, r11
> > > +#ifdef 

[Xen-devel] [PATCH] x86/build: Untangle CONFIG_DEBUG and CONFIG_FRAME_POINTER

[Andrew Cooper]

Both options are independently choseable in KConfig, but currently a DEBUG
build without FRAME_POINTER is left to the compilers default choice, not the
users choice.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
---
 xen/Rules.mk | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index 3cf4075..541ed13 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -43,7 +43,13 @@ ALL_OBJS-$(CONFIG_CRYPTO)   += $(BASEDIR)/crypto/built_in.o
 ifeq ($(CONFIG_DEBUG),y)
 CFLAGS += -O1
 else
-CFLAGS += -O2 -fomit-frame-pointer
+CFLAGS += -O2
+endif
+
+ifeq ($(CONFIG_FRAME_POINTER),y)
+CFLAGS += -fno-omit-frame-pointer
+else
+CFLAGS += -fomit-frame-pointer
 endif
 
 CFLAGS += -nostdinc -fno-builtin -fno-common
@@ -58,8 +64,6 @@ ifneq ($(clang),y)
 CFLAGS += -Wa,--strip-local-absolute
 endif
 
-CFLAGS-$(CONFIG_FRAME_POINTER) += -fno-omit-frame-pointer
-
 ifneq ($(max_phys_irqs),)
 CFLAGS-y+= -DMAX_PHYS_IRQS=$(max_phys_irqs)
 endif
-- 
2.1.4


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

[Xen-devel] [PATCH] xen,x86: introduce tcg_errata

[Stefano Stabellini]

The TCG emulator in QEMU is not good enough to pass the the tests in
stub_selftest. Detect if Xen is running on TCG early, then drop the
tests if it is the case.

Signed-off-by: Stefano Stabellini 

diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
index 4306e59..4229b30 100644
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -621,6 +621,18 @@ void detect_ht(struct cpuinfo_x86 *c)
}
 }
 
+bool tcg_errata = false;
+void __init detect_tcg_errata(void)
+{
+   uint32_t base, eax, signature[3];
+   char *sig = "TCGTCGTCGTCG";
+
+   base = 0x4000;
+   cpuid(base, , [0], [1], [2]);
+   if ( !memcmp(sig, signature, 12) )
+   tcg_errata = true;
+}
+
 unsigned int __init apicid_to_socket(unsigned int apicid)
 {
unsigned int dummy;
diff --git a/xen/arch/x86/extable.c b/xen/arch/x86/extable.c
index 72f30d9..6255f72 100644
--- a/xen/arch/x86/extable.c
+++ b/xen/arch/x86/extable.c
@@ -146,6 +146,9 @@ static int __init stub_selftest(void)
 unsigned long addr = this_cpu(stubs.addr) + STUB_BUF_SIZE / 2;
 unsigned int i;
 
+if ( tcg_errata )
+return 0;
+
 printk("Running stub recovery selftests...\n");
 
 for ( i = 0; i < ARRAY_SIZE(tests); ++i )
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 9407247..e33b76a 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1521,6 +1521,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 early_microcode_init();
 
 identify_cpu(_cpu_data);
+detect_tcg_errata();
 
 set_in_cr4(X86_CR4_OSFXSR | X86_CR4_OSXMMEXCPT);
 
diff --git a/xen/include/asm-x86/processor.h b/xen/include/asm-x86/processor.h
index e8c2f02..96b6125 100644
--- a/xen/include/asm-x86/processor.h
+++ b/xen/include/asm-x86/processor.h
@@ -169,6 +169,9 @@ extern void detect_extended_topology(struct cpuinfo_x86 *c);
 
 extern void detect_ht(struct cpuinfo_x86 *c);
 
+extern bool tcg_errata;
+extern void detect_tcg_errata(void);
+
 #define cpu_to_core(_cpu)   (cpu_data[_cpu].cpu_core_id)
 #define cpu_to_socket(_cpu) (cpu_data[_cpu].phys_proc_id)
 

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

Re: [Xen-devel] PCI Device Subtree Change from Traditional to Upstream

[George Dunlap]

On 01/25/2018 06:04 PM, Anthony PERARD wrote:
> On Thu, Jan 25, 2018 at 05:54:36PM +, George Dunlap wrote:
>> On 01/04/2018 12:52 PM, Anthony PERARD wrote:
>>> From: Anthony PERARD 
>>> Subject: [PATCH] libxl_dm: Explicitly put xen-platform device on PCI slot 3
>>>
>>> In order to do that, we don't use xenfv machine anymore and explicity
>>> add the platform device on the command line.
>>>
>>> Signed-off-by: Anthony PERARD 
>>
>> Anthony,
>>
>> It seems like we might want to add the ability to specify which slot we
>> want the xen-platform device to occupy. Is it worth thinking of the best
>> way to add a patch like this upstream?
> 
> I think that would be nice for people who switch from qemu-trad to
> QEMU. The only question that remain is, how to name the xl config
> option?  The rest is to simply take my libxl patch and make it use
> the new config option.

Well the other half would be to make sure something like this doesn't
happen by accident in the future -- i.e., that no future changes in QEMU
will accidentally move it away from whatever the current slot is now.

 -George

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

Re: [Xen-devel] [RFC PATCH 02/10] arm64: Add hook to handle guest GICv3 sysreg accesses

[Julien Grall]

Hi,

I forgot to mention one thing about the placement of do_fixup_vgic_errata.

On 16/01/18 15:42, mja...@caviumnetworks.com wrote:

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index f6f6de3691..d4f0581d33 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2103,6 +2103,17 @@ void do_trap_guest_sync(struct cpu_user_regs *regs)
  {
  const union hsr hsr = { .bits = regs->hsr };
  
+#ifdef CONFIG_VGIC_ERRATA

+int ret;
+
+ret  = do_fixup_vgic_errata(regs,hsr);
+if ( !ret )
+{
+advance_pc(regs, hsr);
+return;


I am fully aware that I suggested this solution and still support that 
the vGIC errata should be fully separated. After all, it deals with 
hardware bug and the errata will just update the LRs as the hardware 
would do.


enter_hypervisor_head() will sync the LRs state to the internal vGIC 
state. leave_hypervisor_head() will process pending softirq and 
write/update the LRs based on the internal vGIC state.


As you rightfully did, the do_fixup_vgic_errata should be called before 
syncing the LRs. However, even if you return early here, you will still 
execute leave_hypervisor_tail(). This mean that pending softirqs will be 
processed and potentially the vCPU rescheduled. Because the LRs were not 
synced (enter_hypervisor_head()) was not called, then the vGIC state 
will not out-of-date and would lead to all sort of potential issues.


As the vGIC errata implies trapping the register such as IAR1 (reading 
interrupt), we want to get a fastpath for it (e.g not trying to execute 
softirq...). So I think we should bypass leave_hypervisor_tail(). I am 
not entirely sure how to do it nicely thought.


Cheers,


+}
+#endif
+
  enter_hypervisor_head(regs);
  
  switch (hsr.ec) {

diff --git a/xen/include/asm-arm/arm64/traps.h 
b/xen/include/asm-arm/arm64/traps.h
index 2379b578cb..7378a1b022 100644
--- a/xen/include/asm-arm/arm64/traps.h
+++ b/xen/include/asm-arm/arm64/traps.h
@@ -5,6 +5,8 @@ void inject_undef64_exception(struct cpu_user_regs *regs, int 
instr_len);
  
  void do_sysreg(struct cpu_user_regs *regs,

 const union hsr hsr);
+int do_fixup_vgic_errata(struct cpu_user_regs *regs,
+   const union hsr hsr);
  
  #endif /* __ASM_ARM64_TRAPS__ */

  /*



--
Julien Grall

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

Re: [Xen-devel] PCI Device Subtree Change from Traditional to Upstream

[Anthony PERARD]

On Thu, Jan 25, 2018 at 05:54:36PM +, George Dunlap wrote:
> On 01/04/2018 12:52 PM, Anthony PERARD wrote:
> > From: Anthony PERARD 
> > Subject: [PATCH] libxl_dm: Explicitly put xen-platform device on PCI slot 3
> > 
> > In order to do that, we don't use xenfv machine anymore and explicity
> > add the platform device on the command line.
> > 
> > Signed-off-by: Anthony PERARD 
> 
> Anthony,
> 
> It seems like we might want to add the ability to specify which slot we
> want the xen-platform device to occupy. Is it worth thinking of the best
> way to add a patch like this upstream?

I think that would be nice for people who switch from qemu-trad to
QEMU. The only question that remain is, how to name the xl config
option?  The rest is to simply take my libxl patch and make it use
the new config option.

-- 
Anthony PERARD

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

Re: [Xen-devel] PCI Device Subtree Change from Traditional to Upstream

[George Dunlap]

On 01/04/2018 12:52 PM, Anthony PERARD wrote:
> On Wed, Jan 03, 2018 at 05:10:54PM -0600, Kevin Stange wrote:
>> On 01/03/2018 11:57 AM, Anthony PERARD wrote:
>>> On Wed, Dec 20, 2017 at 11:40:03AM -0600, Kevin Stange wrote:
 Hi,

 I've been working on transitioning a number of Windows guests under HVM
 from using QEMU traditional to QEMU upstream as is recommended in the
 documentation.  When I move these guests, the PCI subtree for Xen
 devices changes and Windows creates a totally new copy of each device.
 Windows tracks down the storage without issue, but it treats the new
 instance of the NIC driver as a new device and clears the network
 configuration even though the MAC address is unchanged.  Manually
 booting the guest back on the traditional device model reactivates the
 original PCI subtree and the old network configuration with it.

 The only thing that I have been able to find that's substantially
 different comparing the device trees is that the device instance ID
 values differ on the parent Xen PCI device:

 PCI\VEN_5853_0001_00015853_01\3&267A616A&3&18

 PCI\VEN_5853_0001_00015853_01\3&267A616A&3&10

 Besides actually setting the guest to boot using QEMU traditional, is
 there a way to convince Windows to treat these devices as the same?  A
 patch-based solution would be acceptable to me if there is one, but I
 don't understand the code well enough to create my own solution.
>>>
>>> Hi Kevin,
>>>
>>> I've got a patch to QEMU that seems to do the trick:
>>>
>>> From: Anthony PERARD 
>>> Subject: [PATCH] xen-platform: Hardcode PCI slot to 3
>>>
>>> Signed-off-by: Anthony PERARD 
>>> ---
>>>  hw/i386/pc_piix.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
>>> index 5e47528993..93e3a9a916 100644
>>> --- a/hw/i386/pc_piix.c
>>> +++ b/hw/i386/pc_piix.c
>>> @@ -405,7 +405,7 @@ static void pc_xen_hvm_init(MachineState *machine)
>>>  
>>>  bus = pci_find_primary_bus();
>>>  if (bus != NULL) {
>>> -pci_create_simple(bus, -1, "xen-platform");
>>> +pci_create_simple(bus, PCI_DEVFN(3, 0), "xen-platform");
>>>  }
>>>  }
>>>  #endif
>>>
>>>
>>> The same thing could be done by libxl, by providing specific command
>>> line options to qemu. (I think that could even be done via a different
>>> config file for the guest.)
>>
>> This patch doesn't seem to work for me.  It seems like the device model
>> process is exiting immediately, but I haven't been able to find any
>> information as to what is going wrong.  I tested with Xen 4.6.6 and the
>> QEMU packaged with that release.  Should I try it on a different version
>> of Xen and QEMU?
> 
> What this patch does is asking QEMU to insert the PCI card
> "xen-platform" into the 3rd PCI slot. My guess is that failed because
> there is already a PCI device there.
> 
> You could check qemu's logs, it's in
> /var/log/xen/qemu-dm-${guest_name}.log
> 
> 
> Let's try something else, instead of patching QEMU, we can patch libxl,
> that might work better. Can you try this patch? (I've only test
> compiled.) I've write the patch for Xen 4.6, since that the version you
> are using.
> 
> 
> From: Anthony PERARD 
> Subject: [PATCH] libxl_dm: Explicitly put xen-platform device on PCI slot 3
> 
> In order to do that, we don't use xenfv machine anymore and explicity
> add the platform device on the command line.
> 
> Signed-off-by: Anthony PERARD 

Anthony,

It seems like we might want to add the ability to specify which slot we
want the xen-platform device to occupy. Is it worth thinking of the best
way to add a patch like this upstream?

 -George

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

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

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt 13 migrate-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  5b6b15acebfc6ef3dcb72385f328c985526a33e3
baseline version:
 xen  2375832c7e51b67f076e6b07854c4a541cb4bdc3

Last test of basis   118326  2018-01-25 11:01:28 Z0 days
Testing same since   118327  2018-01-25 13:01:30 Z0 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Daniel De Graaf 
  Ian Jackson 
  Jan Beulich 
  Oleksandr Grytsov 
  Roger Pau Monné 
  Ross Lagerwall 
  Wei Liu 

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



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

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

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

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


Not pushing.


commit 5b6b15acebfc6ef3dcb72385f328c985526a33e3
Author: Oleksandr Grytsov 
Date:   Wed Jan 24 19:19:59 2018 +0200

libxl: move ibxl_devid_to_device_... to LIBXL_DEFINE_DEVID_TO_DEVICE

Signed-off-by: Oleksandr Grytsov 
Acked-by: Wei Liu 

commit 32e31182ea3178ab04c8f66ee3b1465f0fc9b255
Author: Oleksandr Grytsov 
Date:   Wed Jan 24 19:19:58 2018 +0200

libxl: move libxl__device_from_ to LIBXL_DEFINE_DEVICE_FROM_TYPE

LIBXL_DEFINE_DEVICE_FROM_TYPE uses libxl__..._devtype.type to
be assigned as device and backend type.

Signed-off-by: Oleksandr Grytsov 
Acked-by: Wei Liu 

commit 4b3dd5439e24cc85c54cae01815bdb3e57234955
Author: Oleksandr Grytsov 
Date:   Wed Jan 24 19:19:57 2018 +0200

libxl: use libxl__device_kind in LIBXL_DEFINE_UPDATE_DEVID

Use libxl__..._devtype.type to update device id.

Signed-off-by: Oleksandr Grytsov 
Acked-by: Wei Liu 

commit 43a858403e9d0ce8c8282e3baade4b8e29c03b54
Author: Oleksandr Grytsov 
Date:   Wed Jan 24 19:19:56 2018 +0200

libxl: use libxl__device_kind to get device XS entry

On adding to XS name of device is taken from
libxl__device_kind enum. On getting device from XS
the name is hardcoded. It leads to potential
mistmatch errors. The patch is using libxl__device_kind
everywere to have one source of device name.

Signed-off-by: Oleksandr Grytsov 
Acked-by: Wei Liu 

commit 8155476765a5bdecea1534b46562cf28e0113a9a
Author: Wei Liu 
Date:   Wed Jan 24 20:26:26 2018 +

x86: fix GET_STACK_END

AIUI the purpose of having the .if directive is to make GET_STACK_END
work with any general purpose registers. The code as-is would produce
the wrong result for r8. Fix it.

Signed-off-by: Wei Liu 
Acked-by: Andrew Cooper 

commit 6d53d4ce621ee80e732152a545a55ab6762a830b
Author: Roger Pau Monné 
Date:   Thu Jan 25 12:30:01 2018 +0100

coverage: introduce generic file

It 

Re: [Xen-devel] [Xen-users] xen_pt_region_update: Error: create new mem mapping failed! (err: 22)

[Håkon Alstadheim]

Den 25. jan. 2018 12:29, skrev Anthony PERARD:
> On Thu, Jan 25, 2018 at 10:28:14AM +, George Dunlap wrote:
>> On Wed, Jan 24, 2018 at 9:59 PM, Håkon Alstadheim
>>  wrote:
>>> I'm trying, and failing, to launch a vm with bios = 'ovmf' under xen 4.10.
>>>
>>> The domain launches OK as long as I do not pass any pci devices through,
>>> but with pci devices passed through,
>>
>> Anthony,
>>
>> Does OVMF support PCI pass-through yet?
> 
> I don't think OVMF cares if a PCI device is pass-through or not. Does
> the VM works with bios=seabios ?
Yes, it does (i.e without a bios= line, which amounts to the same
thing?) . I'd like to get ovmf working with these devices, primarily to
see if maybe ovmf might play nicer with windows and my pcie usb card
than it does at present. I'm doing my tests on another VM, that is
working well without ovmf, just to be sure that I have not messed up
something obvious.

Here is a diff between a working (steam.hvm.bios) and non-working
working domU config:
# diff -u steam.hvm.bios steam.hvm.ovmf
--- steam.hvm.bios  2017-12-02 15:34:58.673709262 +0100
+++ steam.hvm.ovmf  2018-01-25 16:32:57.375284572 +0100
@@ -1,7 +1,7 @@
 name = "steam.hvm"
 builder = "hvm"
 nestedhvm = 1
-xen_platform_pci = '1'
+#xen_platform_pci = '1'
 pvh=1
 vcpus = 8
 cpu_weight=5120
@@ -10,13 +10,13 @@
 memory = 7680
 mmio_hole = 3072
 no_migrate = 1
-timer_mode = "one_missed_tick_pending"
+#timer_mode = "one_missed_tick_pending"
 #timer_mode = "no_missed_ticks_pending"
 soundhw="hda"
 #soundhw="ac97"
 device_model_version="qemu-xen"
-boot = 'n'
-
+boot = 'cd'
+bios = 'ovmf'
 disk = [ 'vdev=xvda, format=raw, no-discard, target=/dev/system/steam-efi',
  'vdev=xvdb, format=raw, no-discard,
target=/dev/bcache/by-label/steam-b',
  'vdev=xvdc, format=raw, no-discard,
target=/dev/system/steam-swap',
@@ -33,10 +33,14 @@
 keymap="en-us"
 spice=0
 sdl = '0'
-vnc = '1'
+vnc = '0'
 serial = 'pty'
-usbctrl=["version=1"]
+#usbctrl=["version=1"]
+device_model_args_hvm = [
+  '-chardev', 'file,id=debugcon,mux=on,path=/tmp/OVMF.logs,',
+  '-device', 'isa-debugcon,iobase=0x402,chardev=debugcon',
+]
---
The .ovmf one boots as long as I do not add a pci=... option to the xl
create command-line.

The arg I add is:
pci=["82:00.0,rdm_policy=relaxed,permissive=1,msitranslate=1","81:00.0","81:00.1"]
, or some subset. All failing for ovmf, working OK with seabios.

> 
> There is maybe somethings wrong with the way OVMF handles PCI devices
> that doesn't work with pass-through.
> 
> Håkon, could you add the following in the VM config? With that, we could
> get some logs from OVMF:
> device_model_args_hvm = [
>   '-chardev', 'file,id=debugcon,mux=on,path=/tmp/OVMF.logs,',
>   '-device', 'isa-debugcon,iobase=0x402,chardev=debugcon',
> ]
I just did that, and /tmp/OVMF.logs gets created, but it is empty.

I happened to look at xl dmesg, and this is what I get from starting the vm:
-
(XEN) [2018-01-25 17:05:52] HVM6 save: CPU
(XEN) [2018-01-25 17:05:52] HVM6 save: PIC
(XEN) [2018-01-25 17:05:52] HVM6 save: IOAPIC
(XEN) [2018-01-25 17:05:52] HVM6 save: LAPIC
(XEN) [2018-01-25 17:05:52] HVM6 save: LAPIC_REGS
(XEN) [2018-01-25 17:05:52] HVM6 save: PCI_IRQ
(XEN) [2018-01-25 17:05:52] HVM6 save: ISA_IRQ
(XEN) [2018-01-25 17:05:52] HVM6 save: PCI_LINK
(XEN) [2018-01-25 17:05:52] HVM6 save: PIT
(XEN) [2018-01-25 17:05:52] HVM6 save: RTC
(XEN) [2018-01-25 17:05:52] HVM6 save: HPET
(XEN) [2018-01-25 17:05:52] HVM6 save: PMTIMER
(XEN) [2018-01-25 17:05:52] HVM6 save: MTRR
(XEN) [2018-01-25 17:05:52] HVM6 save: VIRIDIAN_DOMAIN
(XEN) [2018-01-25 17:05:52] HVM6 save: CPU_XSAVE
(XEN) [2018-01-25 17:05:52] HVM6 save: VIRIDIAN_VCPU
(XEN) [2018-01-25 17:05:52] HVM6 save: VMCE_VCPU
(XEN) [2018-01-25 17:05:52] HVM6 save: TSC_ADJUST
(XEN) [2018-01-25 17:05:52] HVM6 save: CPU_MSR
(XEN) [2018-01-25 17:05:52] HVM6 restore: CPU 0
(XEN) [2018-01-25 17:05:55] d6: bind: m_gsi=56 g_gsi=40 dev=00.00.6 intx=0
(XEN) [2018-01-25 17:05:55] [VT-D]d0:PCIe: unmap :81:00.0
(XEN) [2018-01-25 17:05:55] [VT-D]d6:PCIe: map :81:00.0
(XEN) [2018-01-25 17:05:56] d6: bind: m_gsi=60 g_gsi=45 dev=00.00.7 intx=1
(XEN) [2018-01-25 17:05:56] [VT-D]d0:PCIe: unmap :81:00.1
(XEN) [2018-01-25 17:05:56] [VT-D]d6:PCIe: map :81:00.1
(XEN) [2018-01-25 17:05:57] d6: bind: m_gsi=64 g_gsi=17 dev=00.01.0 intx=0
(XEN) [2018-01-25 17:05:57] [VT-D] It's risky to assign :82:00.0
with shared RMRR at 7db85000 for Dom6.
(XEN) [2018-01-25 17:05:57] [VT-D]d0:PCIe: unmap :82:00.0
(XEN) [2018-01-25 17:05:57] [VT-D]d6:PCIe: map :82:00.0
(d6) [2018-01-25 17:05:58] HVM Loader
(d6) [2018-01-25 17:05:58] Detected Xen v4.10.0
(d6) [2018-01-25 17:05:58] Xenbus rings @0xfeffc000, event channel 1
(d6) [2018-01-25 17:05:58] System requested OVMF
(d6) [2018-01-25 17:05:58] CPU speed is 2395 MHz
(d6) [2018-01-25 17:05:58] Relocating guest memory for lowmem MMIO space
disabled
(d6) [2018-01-25 17:05:58] PCI-ISA link 

Re: [Xen-devel] XSA-254 SP2 for ARM (was Re: [PATCH 1/5] xen/arm: Introduce enable callback to enable a capabilities on each online CPU)

[Stefano Stabellini]

On Thu, 25 Jan 2018, Julien Grall wrote:
> Hi,
> 
> On 24/01/18 22:43, Stefano Stabellini wrote:
> > On Wed, 24 Jan 2018, Julien Grall wrote:
> > > Hi Stefano,
> > > 
> > > On 24 January 2018 at 22:14, Stefano Stabellini 
> > > wrote:
> > > > On Thu, 18 Jan 2018, Julien Grall wrote:
> > > > > (+ Security team)
> > > > > 
> > > > > Hi Stefano,
> > > > > 
> > > > > On 17/01/18 21:47, Stefano Stabellini wrote:
> > > > > > On Wed, 17 Jan 2018, Stefano Stabellini wrote:
> > > > > > > On Wed, 17 Jan 2018, Lars Kurth wrote:
> > > > > > > > Regarding README.source, this is covering file and
> > > > > > > > contain the
> > > > > > > > same mention as in the commit message. As this is a single
> > > > > > > > function.
> > > > > > > > Isn't the commit message
> > > > > > > > enough?
> > > > > > > > 
> > > > > > > > 
> > > > > > > >   From a legal viewpoint it is enough.
> > > > > > > 
> > > > > > > If that is enough from a legal viewpoint, then it is enough for
> > > > > > > me.
> > > > > > > 
> > > > > > > However, from a legal viewpoint, I thought we needed to explicitly
> > > > > > > mention all the original signed-off-bys because Julien is not
> > > > > > > actually
> > > > > > > the copyright holder for that function, hence, we need to add the
> > > > > > > signed-off-bys of all the missing copyright holders.
> > > > > > 
> > > > > > Actually, reading again the Developer’s Certificate of Origin, it
> > > > > > states:
> > > > > > 
> > > > > > "The contribution is based upon previous work that, to the best of
> > > > > > my
> > > > > > knowledge, is covered under an appropriate open source license and I
> > > > > > have
> > > > > > the right under that license to submit that work with modifications,
> > > > > > whether
> > > > > > created in whole or in part by me, under the same open source
> > > > > > license
> > > > > > (unless I am permitted to submit under a different license), as
> > > > > > indicated in
> > > > > > the file"
> > > > > > 
> > > > > > so I think Lars is right. In that case, there is no need to resubmit
> > > > > > this series, I'll commit to staging as is. If tests go well, I'll
> > > > > > backport it to the stable trees.
> > > > > Thank you! I have created branches with patches backported up to Xen
> > > > > 4.8. With
> > > > > minor changes:
> > > > > 
> > > > > - Xen 4.10: No changes
> > > > > - Xen 4.9:
> > > > >* minor conflict in some files
> > > > >* compilation failure in cpuerrata.c (__virt_to_mfn does not
> > > > > exist)
> > > > > - Xen 4.8:
> > > > >* conflict in some files (one medium as the number of
> > > > > "features" is
> > > > > different)
> > > > >* compilation failure in cpuerrata.c (__virt_to_mfn does not
> > > > > exist)
> > > > > 
> > > > > The branches can be found on xenbits [1] : xsa-254-sp2-X.XX where X.XX
> > > > > is the
> > > > > version of Xen.
> > > > > 
> > > > > Xen 4.7 and earlier does not have cpufeature/cpuerrata infrastructure
> > > > > and will
> > > > > require backport. The only difficulty here should be finding the list
> > > > > of
> > > > > commits required.
> > > > > 
> > > > > Also, we probably want to update the XSA pointing to the patches. So
> > > > > if
> > > > > someone wants to backport to Xen 4.7 (or earlier) they can. Any
> > > > > opinions?
> > > > 
> > > > These are the commits for the XSA 254 mitigation for the arm64
> > > > architecture:
> > > > 
> > > > staging-4.10
> > > > b829d42829c1ff626a02756acae4dd482fc20c9a
> > > > 0f7a4faafb2d79920cc63457cfca3e03990af4cc
> > > > d1f4283a1d8405a480b4121e1efcfaec8bbdbffa
> > > > cae6e1572f39a1906be0fc3bdaf49fe514c6a9c0
> > > > 928112900e5b4a92ccebb2eea11665fd76aa0f0d
> > > > 728fadb586a2a14a244dabd70463bcc1654ecc85
> > > > 
> > > > staging-4.9
> > > > 2ec7ccbffc6b788f65e55498e4347c1ee3a44b01
> > > > 50450c1f33dc72f2138a671d738934f796be3318
> > > > 3790833ef16b95653424ec9b145e460ec1a56d16
> > > > fba48eff18c02d716c95b92df804a755620be82e
> > > > 9f79e8d846e8413c828f5fc7cc6ac733728dff00
> > > > a2567d6b54b7b187ecc0165021b6dd07dafaf06a
> > > > 
> > > > staging-4.8
> > > > 946dd2eefae2faeecbeb9662e66935c8070f64f5
> > > > 85990bf53addcdb0ce8e458a3d8fad199710ac59
> > > > cf0b584c8c5030588bc47a3614ad860af7482c53
> > > > 44139fed7c794eb4e47a9bb93061e325bd57fe8c
> > > > 6f6786ef0d7f7025860d360f6b1267193ffd1b27
> > > 
> > > Something looks quite odd. The commit message have two cherry-pick commit
> > > ID.
> > > 
> > > Why didn't you just merged the branches I provided?
> > 
> > Basically I did the backports on my own, then I double-checked that they
> > matched your own version of the backports. I did it for safety: this way
> > we can be quite sure that the backports are good, or both of us did
> > exactly the same mistakes :-)
> > It was very helpful to have branches to compare against, thank you for
> > that.
> 
> I also double checked it yesterday because I wasn't sure what you did :).
> 
> > 
> > 
> > > > 
> > > 

Re: [Xen-devel] [PATCH v3] x86/p2m: force return value checking of p2m_set_entry()

[George Dunlap]

On 01/23/2018 09:56 AM, Jan Beulich wrote:
> As XSAs 246 and 247 have shown, not doing so is rather dangerous.
> 
> Signed-off-by: Jan Beulich 
> Acked-by: Andrew Cooper 
> Acked-by: Kevin Tian 

Thanks,

Reviewed-by: George Dunlap 

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

Re: [Xen-devel] [PATCH 10/10] Enable Trapping of Group1 registers which is controlled by command line

[Julien Grall]

Hi Manish,

On 16/01/18 15:43, mja...@caviumnetworks.com wrote:

From: Manish Jaggi 

In order to be able to trap Group-1 GICv3 system registers, we need to
set ICH_HCR_EL2.TALL1 before entering the guest. This is controlled by
the command line parameter group1_trap.


I was expecting a patch to enable group1_trap by default on affected 
platform.




Singed-off-by: Manish Jaggi 
---
  xen/arch/arm/gic-v3.c | 11 ++-
  xen/include/asm-arm/gic.h |  1 +
  2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 5dba8bc932..f22877c468 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -833,9 +833,12 @@ static void gicv3_cpu_disable(void)
  isb();
  }
  
+static unsigned int group1_trap = 0;

+integer_param("group1_trap", group1_trap);


New parameter should be describe in docs/misc/xen-command-line.markdown.

Also, you likely want to use a boolean_param here.


+
  static void gicv3_hyp_init(void)
  {
-uint32_t vtr;
+uint32_t vtr, reg32;
  
  vtr = READ_SYSREG32(ICH_VTR_EL2);

  gicv3_info.nr_lrs  = (vtr & GICH_VTR_NRLRGS) + 1;
@@ -847,6 +850,12 @@ static void gicv3_hyp_init(void)
  
  WRITE_SYSREG32(GICH_VMCR_EOI | GICH_VMCR_VENG1, ICH_VMCR_EL2);

  WRITE_SYSREG32(GICH_HCR_EN, ICH_HCR_EL2);
+
+reg32 = READ_SYSREG32(ICH_HCR_EL2);


There are no point to read ICH_HCR_EL2. You know the value (see the line 
above).


So this code could simplified as:

reg32 = GICH_HCR_EN;
reg32 |= (group1_trap) ? GICH_HCR_TALL1 : 0;

WRITE_SYSREG32(reg32, ICH_HCR_EL2);


+if ( group1_trap )
+reg32 |= GICH_HCR_TALL1;
+
+WRITE_SYSREG32(reg32, ICH_HCR_EL2);
  }
  
  /* Set up the per-CPU parts of the GIC for a secondary CPU */

diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index d3d7bda50d..e4c77fefd6 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -117,6 +117,7 @@
  #define GICH_HCR_VGRP0DIE (1 << 5)
  #define GICH_HCR_VGRP1EIE (1 << 6)
  #define GICH_HCR_VGRP1DIE (1 << 7)
+#define GICH_HCR_TALL1(1 << 12)
  
  #define GICH_MISR_EOI (1 << 0)

  #define GICH_MISR_U   (1 << 1) >


Cheers,

--
Julien Grall

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

[Xen-devel] [PATCH v11 6/11] x86/entry: Organise the clobbering of the RSB/RAS on entry to Xen

[Andrew Cooper]

ret instructions are speculated directly to values recorded in the Return
Stack Buffer/Return Address Stack, as there is no uncertainty in well-formed
code.  Guests can take advantage of this in two ways:

  1) If they can find a path in Xen which executes more ret instructions than
 call instructions.  (At least one in the waitqueue infrastructure,
 probably others.)

  2) Use the fact that the RSB/RAS in hardware is actually a circular stack
 without a concept of empty.  (When it logically empties, stale values
 will start being used.)

To mitigate, overwrite the RSB on entry to Xen with gadgets which will capture
and contain rogue speculation.

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

v10:
 * Spelling/comment improvements.
 * Split to fit around IST safety.  Other half of the patch moved into
   "x86/boot: Calculate the most appropriate BTI mitigation to use"
 * Avoid using numeric labels in DO_OVERWRITE_RSB
v11:
 * Use pause;lfence;jmp to capture speculation, for AMD processors.
---
 xen/include/asm-x86/cpufeatures.h   |  2 ++
 xen/include/asm-x86/nops.h  |  1 +
 xen/include/asm-x86/spec_ctrl_asm.h | 44 +
 3 files changed, 47 insertions(+)

diff --git a/xen/include/asm-x86/cpufeatures.h 
b/xen/include/asm-x86/cpufeatures.h
index dd2388f..0ee4a1f 100644
--- a/xen/include/asm-x86/cpufeatures.h
+++ b/xen/include/asm-x86/cpufeatures.h
@@ -28,3 +28,5 @@ XEN_CPUFEATURE(IND_THUNK_JMP,   (FSCAPINTS+0)*32+14) /* Use 
IND_THUNK_JMP */
 XEN_CPUFEATURE(XEN_IBPB,(FSCAPINTS+0)*32+15) /* IBRSB || IBPB */
 XEN_CPUFEATURE(XEN_IBRS_SET,(FSCAPINTS+0)*32+16) /* IBRSB && IRBS set in 
Xen */
 XEN_CPUFEATURE(XEN_IBRS_CLEAR,  (FSCAPINTS+0)*32+17) /* IBRSB && IBRS clear in 
Xen */
+XEN_CPUFEATURE(RSB_NATIVE,  (FSCAPINTS+0)*32+18) /* RSB overwrite needed 
for native */
+XEN_CPUFEATURE(RSB_VMEXIT,  (FSCAPINTS+0)*32+20) /* RSB overwrite needed 
for vmexit */
diff --git a/xen/include/asm-x86/nops.h b/xen/include/asm-x86/nops.h
index 80126c1..61319cc 100644
--- a/xen/include/asm-x86/nops.h
+++ b/xen/include/asm-x86/nops.h
@@ -70,6 +70,7 @@
 #define ASM_NOP24 ASM_NOP8; ASM_NOP8; ASM_NOP8
 #define ASM_NOP29 ASM_NOP8; ASM_NOP8; ASM_NOP8; ASM_NOP5
 #define ASM_NOP32 ASM_NOP8; ASM_NOP8; ASM_NOP8; ASM_NOP8
+#define ASM_NOP40 ASM_NOP8; ASM_NOP8; ASM_NOP8; ASM_NOP8; ASM_NOP8
 
 #define ASM_NOP_MAX 9
 
diff --git a/xen/include/asm-x86/spec_ctrl_asm.h 
b/xen/include/asm-x86/spec_ctrl_asm.h
index ba55574..e27ea2b 100644
--- a/xen/include/asm-x86/spec_ctrl_asm.h
+++ b/xen/include/asm-x86/spec_ctrl_asm.h
@@ -74,6 +74,44 @@
  *  - SPEC_CTRL_EXIT_TO_GUEST
  */
 
+.macro DO_OVERWRITE_RSB
+/*
+ * Requires nothing
+ * Clobbers %rax, %rcx
+ *
+ * Requires 256 bytes of stack space, but %rsp has no net change. Based on
+ * Google's performance numbers, the loop is unrolled to 16 iterations and two
+ * calls per iteration.
+ *
+ * The call filling the RSB needs a nonzero displacement.  A nop would do, but
+ * we use "1: pause; lfence; jmp 1b" to safely contains any ret-based
+ * speculation, even if the loop is speculatively executed prematurely.
+ *
+ * %rsp is preserved by using an extra GPR because a) we've got plenty spare,
+ * b) the two movs are shorter to encode than `add $32*8, %rsp`, and c) can be
+ * optimised with mov-elimination in modern cores.
+ */
+mov $16, %ecx   /* 16 iterations, two calls per loop */
+mov %rsp, %rax  /* Store the current %rsp */
+
+.L\@_fill_rsb_loop:
+
+.irp n, 1, 2/* Unrolled twice. */
+call .L\@_insert_rsb_entry_\n   /* Create an RSB entry. */
+
+.L\@_capture_speculation_\n:
+pause
+lfence
+jmp .L\@_capture_speculation_\n /* Capture rogue speculation. */
+
+.L\@_insert_rsb_entry_\n:
+.endr
+
+sub $1, %ecx
+jnz .L\@_fill_rsb_loop
+mov %rax, %rsp  /* Restore old %rsp */
+.endm
+
 .macro DO_SPEC_CTRL_ENTRY_FROM_VMEXIT ibrs_val:req
 /*
  * Requires %rbx=current, %rsp=regs/cpuinfo
@@ -173,6 +211,8 @@
 
 /* Use after a VMEXIT from an HVM guest. */
 #define SPEC_CTRL_ENTRY_FROM_VMEXIT \
+ALTERNATIVE __stringify(ASM_NOP40), \
+DO_OVERWRITE_RSB, X86_FEATURE_RSB_VMEXIT;   \
 ALTERNATIVE_2 __stringify(ASM_NOP32),   \
 __stringify(DO_SPEC_CTRL_ENTRY_FROM_VMEXIT  \
 ibrs_val=SPEC_CTRL_IBRS),   \
@@ -183,6 +223,8 @@
 
 /* Use after an entry from PV context (syscall/sysenter/int80/int82/etc). */
 #define SPEC_CTRL_ENTRY_FROM_PV \
+ALTERNATIVE __stringify(ASM_NOP40), \
+DO_OVERWRITE_RSB, X86_FEATURE_RSB_NATIVE;   \
 ALTERNATIVE_2 __stringify(ASM_NOP21), 

[Xen-devel] [PATCH v11 5/11] x86/entry: Organise the use of MSR_SPEC_CTRL at each entry/exit point

[Andrew Cooper]

We need to be able to either set or clear IBRS in Xen context, as well as
restore appropriate guest values in guest context.  See the documentation in
asm-x86/spec_ctrl_asm.h for details.

With the contemporary microcode, writes to %cr3 are slower when SPEC_CTRL.IBRS
is set.  Therefore, the positioning of SPEC_CTRL_{ENTRY/EXIT}* is important.

Ideally, the IBRS_SET/IBRS_CLEAR hunks might be positioned either side of the
%cr3 change, but that is rather more complicated to arrange, and could still
result in a guest controlled value in SPEC_CTRL during the %cr3 change,
negating the saving if the guest chose to have IBRS set.

Therefore, we optimise for the pre-Skylake case (being far more common in the
field than Skylake and later, at the moment), where we have a Xen-preferred
value of IBRS clear when switching %cr3.

There is a semi-unrelated bugfix, where various asm_defn.h macros have a
hidden dependency on PAGE_SIZE, which results in an assembler error if used in
a .macro definition.

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 
---
v10:
 * Fix the restore of SPEC_CTRL on the exit-to-HVM paths.
 * Adjust comments and commit message
 * Pull the GET_STACK_END() out of DO_SPEC_CTRL_ENTRY and use %r14.
v11:
 * Optimise ASM a bit more.  Remove a branch in DO_SPEC_CTRL_ENTRY for the
   maybexen case, and use %dl rather than $0
---
 xen/arch/x86/hvm/svm/entry.S|  11 +-
 xen/arch/x86/hvm/vmx/entry.S|  19 +++
 xen/arch/x86/setup.c|   1 +
 xen/arch/x86/smpboot.c  |   2 +
 xen/arch/x86/x86_64/asm-offsets.c   |   6 +
 xen/arch/x86/x86_64/compat/entry.S  |  14 +++
 xen/arch/x86/x86_64/entry.S |  48 +++-
 xen/include/asm-x86/asm_defns.h |   3 +
 xen/include/asm-x86/current.h   |   6 +
 xen/include/asm-x86/nops.h  |   6 +
 xen/include/asm-x86/spec_ctrl.h |   9 ++
 xen/include/asm-x86/spec_ctrl_asm.h | 225 
 12 files changed, 344 insertions(+), 6 deletions(-)
 create mode 100644 xen/include/asm-x86/spec_ctrl_asm.h

diff --git a/xen/arch/x86/hvm/svm/entry.S b/xen/arch/x86/hvm/svm/entry.S
index df86da0..bf092fe 100644
--- a/xen/arch/x86/hvm/svm/entry.S
+++ b/xen/arch/x86/hvm/svm/entry.S
@@ -79,6 +79,12 @@ UNLIKELY_END(svm_trace)
 or   $X86_EFLAGS_MBS,%rax
 mov  %rax,VMCB_rflags(%rcx)
 
+mov VCPU_arch_msr(%rbx), %rax
+mov VCPUMSR_spec_ctrl_raw(%rax), %eax
+
+/* WARNING! `ret`, `call *`, `jmp *` not safe beyond this point. */
+SPEC_CTRL_EXIT_TO_GUEST /* Req: a=spec_ctrl %rsp=regs/cpuinfo, Clob: 
cd */
+
 pop  %r15
 pop  %r14
 pop  %r13
@@ -101,8 +107,11 @@ UNLIKELY_END(svm_trace)
 SAVE_ALL
 
 GET_CURRENT(bx)
-mov  VCPU_svm_vmcb(%rbx),%rcx
 
+SPEC_CTRL_ENTRY_FROM_VMEXIT /* Req: b=curr %rsp=regs/cpuinfo, Clob: 
acd */
+/* WARNING! `ret`, `call *`, `jmp *` not safe before this point. */
+
+mov  VCPU_svm_vmcb(%rbx),%rcx
 movb $0,VCPU_svm_vmcb_in_sync(%rbx)
 mov  VMCB_rax(%rcx),%rax
 mov  %rax,UREGS_rax(%rsp)
diff --git a/xen/arch/x86/hvm/vmx/entry.S b/xen/arch/x86/hvm/vmx/entry.S
index b2f98be..e750544 100644
--- a/xen/arch/x86/hvm/vmx/entry.S
+++ b/xen/arch/x86/hvm/vmx/entry.S
@@ -38,6 +38,9 @@ ENTRY(vmx_asm_vmexit_handler)
 movb $1,VCPU_vmx_launched(%rbx)
 mov  %rax,VCPU_hvm_guest_cr2(%rbx)
 
+SPEC_CTRL_ENTRY_FROM_VMEXIT /* Req: b=curr %rsp=regs/cpuinfo, Clob: 
acd */
+/* WARNING! `ret`, `call *`, `jmp *` not safe before this point. */
+
 mov  %rsp,%rdi
 call vmx_vmexit_handler
 
@@ -68,6 +71,13 @@ UNLIKELY_END(realmode)
 call vmx_vmenter_helper
 test %al, %al
 jz .Lvmx_vmentry_restart
+
+mov VCPU_arch_msr(%rbx), %rax
+mov VCPUMSR_spec_ctrl_raw(%rax), %eax
+
+/* WARNING! `ret`, `call *`, `jmp *` not safe beyond this point. */
+SPEC_CTRL_EXIT_TO_GUEST /* Req: a=spec_ctrl %rsp=regs/cpuinfo, Clob: 
cd */
+
 mov  VCPU_hvm_guest_cr2(%rbx),%rax
 
 pop  %r15
@@ -99,6 +109,15 @@ UNLIKELY_END(realmode)
 .Lvmx_vmentry_fail:
 sti
 SAVE_ALL
+
+/*
+ * PV variant needed here as no guest code has executed (so
+ * MSR_SPEC_CTRL can't have changed value), and NMIs/MCEs are liable
+ * to hit (in which case the HVM variant might corrupt things).
+ */
+SPEC_CTRL_ENTRY_FROM_PV /* Req: %rsp=regs/cpuinfo Clob: acd */
+/* WARNING! `ret`, `call *`, `jmp *` not safe before this point. */
+
 call vmx_vmentry_failure
 BUG  /* vmx_vmentry_failure() shouldn't return. */
 
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 9407247..ac530ec 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -678,6 +678,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 set_processor_id(0);
 set_current(INVALID_VCPU); /* 

Re: [Xen-devel] [PATCH 06/10] Expose gicv3_ich_read/write_lr

[Julien Grall]

Hi,

On 16/01/18 15:43, mja...@caviumnetworks.com wrote:

From: Manish Jaggi 

gicv3_ich_read/write_lr functions are static in gic-v3.c
This patch creates wrapper functions which can be used from outside the file.

Signed-off-by: Manish Jaggi 
---
  xen/arch/arm/gic-v3.c| 10 ++
  xen/include/asm-arm/gic_v3.h |  7 +++
  2 files changed, 17 insertions(+)

diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 473e26111f..5dba8bc932 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -184,6 +184,11 @@ static uint64_t gicv3_ich_read_lr(int lr)
  }
  }
  
+uint64_t __gicv3_ich_read_lr(int lr)


I see no reason to have a wrapper with exactly the same parameters. Just 
export the current one.


But I think I would prefer the function to be redefined in the cpu if 
implementation. So we vGIC errata is fully separated from the rest of Xen.



+{
+return gicv3_ich_read_lr(lr);
+}
+
  static void gicv3_ich_write_lr(int lr, uint64_t val)
  {
  switch ( lr )
@@ -242,6 +247,11 @@ static void gicv3_ich_write_lr(int lr, uint64_t val)
  isb();
  }
  
+void __gicv3_ich_write_lr(int lr, uint64_t val)

+{
+return gicv3_ich_write_lr(lr, val);
+}
+
  /*
   * System Register Enable (SRE). Enable to access CPU & Virtual
   * interface registers as system registers in EL2
diff --git a/xen/include/asm-arm/gic_v3.h b/xen/include/asm-arm/gic_v3.h
new file mode 100644
index 00..544aad5932
--- /dev/null
+++ b/xen/include/asm-arm/gic_v3.h
@@ -0,0 +1,7 @@
+#ifndef GICV3_H
+#define GICV3_H
+
+uint64_t __gicv3_ich_read_lr(int lr);
+void __gicv3_ich_write_lr(int lr, uint64_t val);
+
+#endif



Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v10 09/11] x86/ctxt: Issue a speculation barrier between vcpu contexts

[Andrew Cooper]

On 25/01/18 16:31, Jan Beulich wrote:
 On 25.01.18 at 17:09,  wrote:
>> On 25/01/18 15:57, Jan Beulich wrote:
>> On 24.01.18 at 14:12,  wrote:
 @@ -1743,6 +1744,34 @@ void context_switch(struct vcpu *prev, struct vcpu 
 *next)
  }
  
  ctxt_switch_levelling(next);
 +
 +if ( opt_ibpb && !is_idle_domain(nextd) )
>>> Is the idle domain check here really useful?
>> Yes, because as you pointed out in v9, the outer condition isn't
>> sufficient to exclude nextd being idle.
> True, but then again - what's wrong with an idle vCPU making it
> into the block? It'll be a pointless barrier that you issue, but no
> other harm afaics. Remember that I complained about the missing
> check only because of the chosen variable naming, but you've
> renamed the variables in question, so I don't see why you've also
> added the extra condition.

The barrier would be pointless, yes, but at 8k cycles, the cost is massive.

~Andrew

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

Re: [Xen-devel] [PATCH 03/10] arm64: Add ICV_BPR1_EL1 handler

[Julien Grall]

Hi Manish,

On 16/01/18 15:42, mja...@caviumnetworks.com wrote:

From: Manish Jaggi 

Add a handler for reading/writing the guest's view of the ICC_BPR1_EL1
register, which is located in the ICH_VMCR_EL2.BPR1 field.


This commit (and likely the followings) is coming from Linux, right? If 
it matches commit from Linux, then you need to keep tags and point to 
the Linux commit. See commit 7762c2d6f4 in Xen as an example to how to 
do it.


If you make changes for Xen, then write "Adapted for Xen...".

But looking at the patch the major difference is you use Xen coding 
style. The rest is pretty much use Xen name for access register and 
adding missing define.


I think it would be beneficial for Xen to re-use Linux code. The 
compatibility layer should be very limited. Stefano any opinions?


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v10 09/11] x86/ctxt: Issue a speculation barrier between vcpu contexts

[Jan Beulich]

>>> On 25.01.18 at 17:09,  wrote:
> On 25/01/18 15:57, Jan Beulich wrote:
> On 24.01.18 at 14:12,  wrote:
>>> @@ -1743,6 +1744,34 @@ void context_switch(struct vcpu *prev, struct vcpu 
>>> *next)
>>>  }
>>>  
>>>  ctxt_switch_levelling(next);
>>> +
>>> +if ( opt_ibpb && !is_idle_domain(nextd) )
>> Is the idle domain check here really useful?
> 
> Yes, because as you pointed out in v9, the outer condition isn't
> sufficient to exclude nextd being idle.

True, but then again - what's wrong with an idle vCPU making it
into the block? It'll be a pointless barrier that you issue, but no
other harm afaics. Remember that I complained about the missing
check only because of the chosen variable naming, but you've
renamed the variables in question, so I don't see why you've also
added the extra condition.

Jan


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

Re: [Xen-devel] [PATCH v10 09/11] x86/ctxt: Issue a speculation barrier between vcpu contexts

[Andrew Cooper]

CC'ing Dario with a working email address this time...

On 25/01/18 16:09, Andrew Cooper wrote:
> On 25/01/18 15:57, Jan Beulich wrote:
> On 24.01.18 at 14:12,  wrote:
>>> @@ -1743,6 +1744,34 @@ void context_switch(struct vcpu *prev, struct vcpu 
>>> *next)
>>>  }
>>>  
>>>  ctxt_switch_levelling(next);
>>> +
>>> +if ( opt_ibpb && !is_idle_domain(nextd) )
>> Is the idle domain check here really useful?
> Yes, because as you pointed out in v9, the outer condition isn't
> sufficient to exclude nextd being idle.
>
>>> +{
>>> +static DEFINE_PER_CPU(unsigned int, last);
>>> +unsigned int *last_id = _cpu(last);
>>> +
>>> +/*
>>> + * Squash the domid and vcpu id together for comparason
>>> + * efficiency.  We could in principle stash and compare the 
>>> struct
>>> + * vcpu pointer, but this risks a false alias if a domain has 
>>> died
>>> + * and the same 4k page gets reused for a new vcpu.
>>> + */
>>> +unsigned int next_id = (((unsigned int)nextd->domain_id << 16) 
>>> |
>>> +(uint16_t)next->vcpu_id);
>>> +BUILD_BUG_ON(MAX_VIRT_CPUS > 0x);
>>> +
>>> +/*
>>> + * When scheduling from a vcpu, to idle, and back to the same 
>>> vcpu
>>> + * (which might be common in a lightly loaded system, or when
>>> + * using vcpu pinning), there is no need to issue IBPB, as we 
>>> are
>>> + * returning to the same security context.
>>> + */
>>> +if ( *last_id != next_id )
>>> +{
>>> +wrmsrl(MSR_PRED_CMD, PRED_CMD_IBPB);
>>> +*last_id = next_id;
>>> +}
>>> +}
>>>  }
>>>  
>>>  context_saved(prev);
>> Short of any real numbers (or a proper explanation) having been
>> provided, I've done some measurements. Indeed I can see quite
>> high a rate of cases of execution coming this way despite the
>> vCPU not really changing during early boot of HVM guests. This
>> goes down quite a bit later on, but obviously that's also workload
>> dependent. But the number of cases where the barrier emission
>> could be avoided remains non-negligible, so I agree the extra
>> avoidance logic is probably warranted. On that basis (perhaps
>> with the idle check above removed)
>> Reviewed-by: Jan Beulich 
>>
>> For the record, the overwhelming majority of calls to
>> __sync_local_execstate() being responsible for the behavior
>> come from invalidate_interrupt(), which suggests to me that
>> there's a meaningful number of cases where a vCPU is migrated
>> to another CPU and then back, without another vCPU having
>> run on the original CPU in between. If I'm not wrong with this,
>> I have to question why the vCPU is migrated then in the first
>> place.
> This is a known (mis)feature of the Credit scheduler.  When a PCPU goes
> idle, it aggressively steals work from the adjacent cpus, even if the
> adjacent cpu only has a single vcpu to run and is running it.
>
> XenServer has this gross hack which makes aggregate networking
> measurements far far better
>
> https://github.com/xenserver/xen.pg/blob/XS-7.1.x/master/sched-credit1-use-per-pcpu-runqueue-count.patch
>
> Dario made a different fix to Credit1 upstream which was supposed to
> resolve this behaviour (although I can't locate the patch by a list of
> titles), but based on these observations, I'd say the misfeature hasn't
> been fixed.
>
> ~Andrew
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel


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

Re: [Xen-devel] [PATCH v10 07/11] x86/entry: Avoid using alternatives in NMI/#MC paths

[Jan Beulich]

>>> On 25.01.18 at 16:19,  wrote:
> On 25/01/18 15:14, Jan Beulich wrote:
> On 25.01.18 at 16:04,  wrote:
>>> On 25/01/18 13:43, Jan Beulich wrote:
>>> On 24.01.18 at 14:12,  wrote:
> @@ -256,6 +261,69 @@
>  DO_SPEC_CTRL_EXIT_TO_GUEST, X86_FEATURE_XEN_IBRS_SET,   \
>  DO_SPEC_CTRL_EXIT_TO_GUEST, X86_FEATURE_XEN_IBRS_CLEAR
>  
> +/* TODO: Drop these when the alternatives infrastructure is NMI/#MC 
> safe. 
> */
> +.macro SPEC_CTRL_ENTRY_FROM_INTR_IST
> +/*
> + * Requires %rsp=regs, %r14=stack_end
> + * Clobbers %rax, %rcx, %rdx
> + *
> + * This is logical merge of DO_OVERWRITE_RSB and DO_SPEC_CTRL_ENTRY
> + * maybexen=1, but with conditionals rather than alternatives.
> + */
> +movzbl STACK_CPUINFO_FIELD(bti_ist_info)(%r14), %eax
> +
> +testb $BTI_IST_RSB, %al
> +jz .L\@_skip_rsb
> +
> +DO_OVERWRITE_RSB
> +
> +.L\@_skip_rsb:
> +
> +testb $BTI_IST_WRMSR, %al
> +jz .L\@_skip_wrmsr
> +
> +testb $3, UREGS_cs(%rsp)
> +jz .L\@_entry_from_xen
> +
> +movb $0, STACK_CPUINFO_FIELD(use_shadow_spec_ctrl)(%r14)
> +
> +.L\@_entry_from_xen:
> +/*
> + * Load Xen's intended value.  SPEC_CTRL_IBRS vs 0 is encoded in the
> + * bottom bit of bti_ist_info, via a deliberate alias with 
> BTI_IST_IBRS.
> + */
> +mov $MSR_SPEC_CTRL, %ecx
> +and $BTI_IST_IBRS, %eax
> +xor %edx, %edx
> +wrmsr
> +
> +/* Opencoded UNLIKELY_START() with no condition. */
> +.Ldispatch.\@_serialise:
> +.subsection 1
 How about adding .ifnb to UNLIKELY_START(), instead of open coding?
 Or wait - why can't you use it as-is above (instead of the
 "jz .L\@_skip_wrmsr")?
>>> Because then the end label is wrong.  One way of another, we either need
>>> to opencode something, or implement UNLIKELY_ELSE() which is actually
>>> the likely case, and this is a substantially larger can of worms.
>> I'm willing to trust you for now (until I get around to play with this
>> myself), but I don't follow: In an UNLIKELY_START() /
>> UNLIKELY_END() pair, how could the labels be wrong if both specify
>> the same tag?
> 
> The problem is that execution needs to jmp to after the wrmsr, rather
> than before the testb $3, UREGS_cs(%rsp), which is where UNLIKELY_END()
> would currently leave it.
> 
> We do not have suitable UNLIKELY() infrastructure to express a non-empty
> likely basic block.

At least we have UNLIKELY_DISPATCH_LABEL() - may I ask you
don't open-code that one then. UNLIKELY_DONE(), as it looks,
won't be of any help here, otoh.

Jan


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

Re: [Xen-devel] [PATCH v10 09/11] x86/ctxt: Issue a speculation barrier between vcpu contexts

[Andrew Cooper]

On 25/01/18 15:57, Jan Beulich wrote:
 On 24.01.18 at 14:12,  wrote:
>> @@ -1743,6 +1744,34 @@ void context_switch(struct vcpu *prev, struct vcpu 
>> *next)
>>  }
>>  
>>  ctxt_switch_levelling(next);
>> +
>> +if ( opt_ibpb && !is_idle_domain(nextd) )
> Is the idle domain check here really useful?

Yes, because as you pointed out in v9, the outer condition isn't
sufficient to exclude nextd being idle.

>
>> +{
>> +static DEFINE_PER_CPU(unsigned int, last);
>> +unsigned int *last_id = _cpu(last);
>> +
>> +/*
>> + * Squash the domid and vcpu id together for comparason
>> + * efficiency.  We could in principle stash and compare the 
>> struct
>> + * vcpu pointer, but this risks a false alias if a domain has 
>> died
>> + * and the same 4k page gets reused for a new vcpu.
>> + */
>> +unsigned int next_id = (((unsigned int)nextd->domain_id << 16) |
>> +(uint16_t)next->vcpu_id);
>> +BUILD_BUG_ON(MAX_VIRT_CPUS > 0x);
>> +
>> +/*
>> + * When scheduling from a vcpu, to idle, and back to the same 
>> vcpu
>> + * (which might be common in a lightly loaded system, or when
>> + * using vcpu pinning), there is no need to issue IBPB, as we 
>> are
>> + * returning to the same security context.
>> + */
>> +if ( *last_id != next_id )
>> +{
>> +wrmsrl(MSR_PRED_CMD, PRED_CMD_IBPB);
>> +*last_id = next_id;
>> +}
>> +}
>>  }
>>  
>>  context_saved(prev);
> Short of any real numbers (or a proper explanation) having been
> provided, I've done some measurements. Indeed I can see quite
> high a rate of cases of execution coming this way despite the
> vCPU not really changing during early boot of HVM guests. This
> goes down quite a bit later on, but obviously that's also workload
> dependent. But the number of cases where the barrier emission
> could be avoided remains non-negligible, so I agree the extra
> avoidance logic is probably warranted. On that basis (perhaps
> with the idle check above removed)
> Reviewed-by: Jan Beulich 
>
> For the record, the overwhelming majority of calls to
> __sync_local_execstate() being responsible for the behavior
> come from invalidate_interrupt(), which suggests to me that
> there's a meaningful number of cases where a vCPU is migrated
> to another CPU and then back, without another vCPU having
> run on the original CPU in between. If I'm not wrong with this,
> I have to question why the vCPU is migrated then in the first
> place.

This is a known (mis)feature of the Credit scheduler.  When a PCPU goes
idle, it aggressively steals work from the adjacent cpus, even if the
adjacent cpu only has a single vcpu to run and is running it.

XenServer has this gross hack which makes aggregate networking
measurements far far better

https://github.com/xenserver/xen.pg/blob/XS-7.1.x/master/sched-credit1-use-per-pcpu-runqueue-count.patch

Dario made a different fix to Credit1 upstream which was supposed to
resolve this behaviour (although I can't locate the patch by a list of
titles), but based on these observations, I'd say the misfeature hasn't
been fixed.

~Andrew

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

Re: [Xen-devel] [Xen EFI] Impossible to limit the dom0 memory

[msd+xen-de...@msd.im]

I have installed `linux-image-amd64-dbg` and `binutils`.

I can now execute `addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 `.

I have generated a file "commands.txt" with all the addresses after 
"Guest stack trace from rsp=82003cb0:" in my log file 
"dom0_crash_with_dom0_memory.txt".


I attached the result : "result.txt".

We can see inside this file "xen/mmu_pv.c:1548" and 
"drivers/firmware/efi/efi.c:558", so I hope it will be helpful.


Is that ok for you ?
Can I do something more ?

Regards,


Guillaume
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 0010
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 303030363838
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 0003
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 8240723c
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 0001e030
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 00010086
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 82003cf0
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 e02b
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 8241c3ef
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 86bb5000
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 0001
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 824355f9
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 0af0
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 1000
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 8163
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 05be82003d38
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 86bb5af0
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 0010
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 0018
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 000c
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 885f2e18
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 000c
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 8243582e
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 ff2001f8
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 82003de0
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 8245400f
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 824355f9
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 824c6fc0
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 45963d3ad719b2cb
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 6f65670ed0dabca3
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 05fe
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 0018
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 82003df8
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 ff2000d8
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 824c6fc0
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 0018
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 824540e3
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 824540e3
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 ff200260
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 024ac1e0
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 82003f18
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 8241fa00
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 204b444582003f18
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 20534f4942204949
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 30303231533a4449
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 302e4236382e5053
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 3230302e31302e33
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 3032373239302e36
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 393237303731
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 0100
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 8100
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 8240a82a
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 810d12fd
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 0010
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 82003f18
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 82003ed0
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 02633000
addr2line -pfi -e vmlinux-4.14.0-0.bpo.3-amd64 

Re: [Xen-devel] [PATCH v10 09/11] x86/ctxt: Issue a speculation barrier between vcpu contexts

[Jan Beulich]

>>> On 24.01.18 at 14:12,  wrote:
> @@ -1743,6 +1744,34 @@ void context_switch(struct vcpu *prev, struct vcpu 
> *next)
>  }
>  
>  ctxt_switch_levelling(next);
> +
> +if ( opt_ibpb && !is_idle_domain(nextd) )

Is the idle domain check here really useful?

> +{
> +static DEFINE_PER_CPU(unsigned int, last);
> +unsigned int *last_id = _cpu(last);
> +
> +/*
> + * Squash the domid and vcpu id together for comparason
> + * efficiency.  We could in principle stash and compare the 
> struct
> + * vcpu pointer, but this risks a false alias if a domain has 
> died
> + * and the same 4k page gets reused for a new vcpu.
> + */
> +unsigned int next_id = (((unsigned int)nextd->domain_id << 16) |
> +(uint16_t)next->vcpu_id);
> +BUILD_BUG_ON(MAX_VIRT_CPUS > 0x);
> +
> +/*
> + * When scheduling from a vcpu, to idle, and back to the same 
> vcpu
> + * (which might be common in a lightly loaded system, or when
> + * using vcpu pinning), there is no need to issue IBPB, as we are
> + * returning to the same security context.
> + */
> +if ( *last_id != next_id )
> +{
> +wrmsrl(MSR_PRED_CMD, PRED_CMD_IBPB);
> +*last_id = next_id;
> +}
> +}
>  }
>  
>  context_saved(prev);

Short of any real numbers (or a proper explanation) having been
provided, I've done some measurements. Indeed I can see quite
high a rate of cases of execution coming this way despite the
vCPU not really changing during early boot of HVM guests. This
goes down quite a bit later on, but obviously that's also workload
dependent. But the number of cases where the barrier emission
could be avoided remains non-negligible, so I agree the extra
avoidance logic is probably warranted. On that basis (perhaps
with the idle check above removed)
Reviewed-by: Jan Beulich 

For the record, the overwhelming majority of calls to
__sync_local_execstate() being responsible for the behavior
come from invalidate_interrupt(), which suggests to me that
there's a meaningful number of cases where a vCPU is migrated
to another CPU and then back, without another vCPU having
run on the original CPU in between. If I'm not wrong with this,
I have to question why the vCPU is migrated then in the first
place.

Jan


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

Re: [Xen-devel] [PATCH v2 2/2] xen: add acpi_arch_get_root_pointer() for pvh guests

[Boris Ostrovsky]

On 01/25/2018 09:36 AM, Juergen Gross wrote:

Add acpi_arch_get_root_pointer() for Xen PVH guests to communicate
the address of the RSDP table given to the kernel via Xen start info.

This makes the kernel boot again in PVH mode after on recent Xen the
RSDP was moved to higher addresses. So up to that change it was pure
luck that the legacy method to locate the RSDP was working when
running as PVH mode.

Cc:  # 4.11
Signed-off-by: Juergen Gross 



Reviewed-by: Boris Ostrovsky 

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

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

[Roger Pau Monné]

On Thu, Jan 25, 2018 at 02:03:35PM +, George Dunlap wrote:
> On Thu, Jan 25, 2018 at 9:14 AM, Roger Pau Monné  wrote:
> > On Wed, Jan 24, 2018 at 06:03:28PM +, George Dunlap wrote:
> >> On Wed, Jan 17, 2018 at 9:48 AM, Roger Pau Monne  
> >> wrote:
> >> > Since VCPUOP_{up/down} already identity pins vCPU hotplug to pCPU
> >> > hotplug also pin the vCPUs to the pCPUs in the scheduler. This prevent
> >> > vCPU migration and should improve performance.
> >> >
> >> > While there also use __cpumask_set_cpu instead of cpumask_set_cpu,
> >> > there's no need to use the locked variant.
> >> >
> >> > Signed-off-by: Roger Pau Monné 
> >>
> >> Sorry, I just realized this -- we already have a way to pin a VM 1:1
> >> -- d->is_pinned should do what you want here without having to
> >> special-case the pvshim.
> >>
> >> It seems like something like the attached might be better (compile-tested 
> >> only).
> >
> > I haven't tested the proposed patch, but there's a peculiarity of the
> > shim that I think makes this approach invalid.
> >
> > When Xen is booted in shim mode the APs are never started, which means
> > that dom0_cpus only contains the BSP, and that alloc_vcpu is always
> > going to be called with cpu == 0. This in turn means that
> > sched_init_vcpu is also always called with cpu_id == 0, and if
> > is_pinned is set it would force all vCPUs to be pinned to the BSP
> > AFAICT.
> 
> Right, I see -- dom0 may not actually be running on pcpus 0-N (and in
> theory there may be more vcpus than pcpus), so the code goes through
> and pins them one-by-one based on what cpus it actually has, rather
> than using the vcpu_id directly.
> 
> So it looks like you want to bring up cpus in Xen only when the guest
> brings them up.  So in shim mode, you only bring up the BSP.  You want
> all possible "dom0" (i.e. L2) vcpus *created* at boot time, and you
> also want them pinned to their respective "pcpus" (L1 vcpus).
> 
> But you can't call alloc_vcpu() with the appropriate "pcpuid", because
> then sched_init_vcpu() will set v->processor equal to a pcpu which
> isn't up yet.  So you set dom0_cpus to contain only cpu0, so that
> alloc_vcpu() will always be called with cpu 0; and then special-case
> the affinity so that when it *does* come up, the affinity is already
> set.
> 
> Is that about right?

Yes, I think so.

> What about setting the hard affinity in pv_shim_cpu_up() instead?

That would mean setting it up each time the CPU is brought up. Seems
easier to set only once during domain build and forget about it.

> (You don't need to set the soft affinity, as the hard affinity will
> override it.)

That seems fine to me. I more or less guessed that, but didn't look
that carefully.

Thanks, Roger.

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

Re: [Xen-devel] [PATCH v3 3/7] coverage: introduce generic file

[Ian Jackson]

George Dunlap writes ("Re: [PATCH v3 3/7] coverage: introduce generic file"):
> I'm pretty sure the copyright starts from the time the work is created,
> not the time it gets checked into a public tree.  Most of this would
> have been written last year.
> 
> Since we're being pedantic. ;-)

`(maintain) Copyright Notices' says:

   To update the list of year numbers, add each year in which you have
   made nontrivial changes to the package.  (Here we assume you're
   using a publicly accessible revision control server, so that every
   revision installed is also immediately and automatically
   published.) ...

So I think it is the date on which the _overall version_ is published,
ie for us the date it gets pushed to staging, or the date it gets
published by the submitter as a git branch (if sooner).  But I doubt
this really matters very much.

Ian.

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

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

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt 13 migrate-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  5b6b15acebfc6ef3dcb72385f328c985526a33e3
baseline version:
 xen  2375832c7e51b67f076e6b07854c4a541cb4bdc3

Last test of basis   118326  2018-01-25 11:01:28 Z0 days
Testing same since   118327  2018-01-25 13:01:30 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Daniel De Graaf 
  Ian Jackson 
  Jan Beulich 
  Oleksandr Grytsov 
  Roger Pau Monné 
  Ross Lagerwall 
  Wei Liu 

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



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

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

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

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


Not pushing.


commit 5b6b15acebfc6ef3dcb72385f328c985526a33e3
Author: Oleksandr Grytsov 
Date:   Wed Jan 24 19:19:59 2018 +0200

libxl: move ibxl_devid_to_device_... to LIBXL_DEFINE_DEVID_TO_DEVICE

Signed-off-by: Oleksandr Grytsov 
Acked-by: Wei Liu 

commit 32e31182ea3178ab04c8f66ee3b1465f0fc9b255
Author: Oleksandr Grytsov 
Date:   Wed Jan 24 19:19:58 2018 +0200

libxl: move libxl__device_from_ to LIBXL_DEFINE_DEVICE_FROM_TYPE

LIBXL_DEFINE_DEVICE_FROM_TYPE uses libxl__..._devtype.type to
be assigned as device and backend type.

Signed-off-by: Oleksandr Grytsov 
Acked-by: Wei Liu 

commit 4b3dd5439e24cc85c54cae01815bdb3e57234955
Author: Oleksandr Grytsov 
Date:   Wed Jan 24 19:19:57 2018 +0200

libxl: use libxl__device_kind in LIBXL_DEFINE_UPDATE_DEVID

Use libxl__..._devtype.type to update device id.

Signed-off-by: Oleksandr Grytsov 
Acked-by: Wei Liu 

commit 43a858403e9d0ce8c8282e3baade4b8e29c03b54
Author: Oleksandr Grytsov 
Date:   Wed Jan 24 19:19:56 2018 +0200

libxl: use libxl__device_kind to get device XS entry

On adding to XS name of device is taken from
libxl__device_kind enum. On getting device from XS
the name is hardcoded. It leads to potential
mistmatch errors. The patch is using libxl__device_kind
everywere to have one source of device name.

Signed-off-by: Oleksandr Grytsov 
Acked-by: Wei Liu 

commit 8155476765a5bdecea1534b46562cf28e0113a9a
Author: Wei Liu 
Date:   Wed Jan 24 20:26:26 2018 +

x86: fix GET_STACK_END

AIUI the purpose of having the .if directive is to make GET_STACK_END
work with any general purpose registers. The code as-is would produce
the wrong result for r8. Fix it.

Signed-off-by: Wei Liu 
Acked-by: Andrew Cooper 

commit 6d53d4ce621ee80e732152a545a55ab6762a830b
Author: Roger Pau Monné 
Date:   Thu Jan 25 12:30:01 2018 +0100

coverage: introduce generic file

It 

Re: [Xen-devel] [PATCH v10 07/11] x86/entry: Avoid using alternatives in NMI/#MC paths

[Andrew Cooper]

On 25/01/18 15:14, Jan Beulich wrote:
 On 25.01.18 at 16:04,  wrote:
>> On 25/01/18 13:43, Jan Beulich wrote:
>> On 24.01.18 at 14:12,  wrote:
 @@ -256,6 +261,69 @@
  DO_SPEC_CTRL_EXIT_TO_GUEST, X86_FEATURE_XEN_IBRS_SET,   \
  DO_SPEC_CTRL_EXIT_TO_GUEST, X86_FEATURE_XEN_IBRS_CLEAR
  
 +/* TODO: Drop these when the alternatives infrastructure is NMI/#MC safe. 
 */
 +.macro SPEC_CTRL_ENTRY_FROM_INTR_IST
 +/*
 + * Requires %rsp=regs, %r14=stack_end
 + * Clobbers %rax, %rcx, %rdx
 + *
 + * This is logical merge of DO_OVERWRITE_RSB and DO_SPEC_CTRL_ENTRY
 + * maybexen=1, but with conditionals rather than alternatives.
 + */
 +movzbl STACK_CPUINFO_FIELD(bti_ist_info)(%r14), %eax
 +
 +testb $BTI_IST_RSB, %al
 +jz .L\@_skip_rsb
 +
 +DO_OVERWRITE_RSB
 +
 +.L\@_skip_rsb:
 +
 +testb $BTI_IST_WRMSR, %al
 +jz .L\@_skip_wrmsr
 +
 +testb $3, UREGS_cs(%rsp)
 +jz .L\@_entry_from_xen
 +
 +movb $0, STACK_CPUINFO_FIELD(use_shadow_spec_ctrl)(%r14)
 +
 +.L\@_entry_from_xen:
 +/*
 + * Load Xen's intended value.  SPEC_CTRL_IBRS vs 0 is encoded in the
 + * bottom bit of bti_ist_info, via a deliberate alias with 
 BTI_IST_IBRS.
 + */
 +mov $MSR_SPEC_CTRL, %ecx
 +and $BTI_IST_IBRS, %eax
 +xor %edx, %edx
 +wrmsr
 +
 +/* Opencoded UNLIKELY_START() with no condition. */
 +.Ldispatch.\@_serialise:
 +.subsection 1
>>> How about adding .ifnb to UNLIKELY_START(), instead of open coding?
>>> Or wait - why can't you use it as-is above (instead of the
>>> "jz .L\@_skip_wrmsr")?
>> Because then the end label is wrong.  One way of another, we either need
>> to opencode something, or implement UNLIKELY_ELSE() which is actually
>> the likely case, and this is a substantially larger can of worms.
> I'm willing to trust you for now (until I get around to play with this
> myself), but I don't follow: In an UNLIKELY_START() /
> UNLIKELY_END() pair, how could the labels be wrong if both specify
> the same tag?

The problem is that execution needs to jmp to after the wrmsr, rather
than before the testb $3, UREGS_cs(%rsp), which is where UNLIKELY_END()
would currently leave it.

We do not have suitable UNLIKELY() infrastructure to express a non-empty
likely basic block.

>
>>> And then, having reached the end of the patch - where is the
>>> new struct cpu_info field written? Or is this again happening only in
>>> later patches, with the one here just setting the stage? If so,
>>> shouldn't you at least zero the field in init_shadow_spec_ctrl_state()?
>> Hmm - I should set 0 in init_shadow_spec_ctrl_state().
>>
>> All the other calculation logic needs to be deferred to the subsequent
>> patch for bisectiblaty.
> Of course. With this initialization fixed and the connection made
> between BTI_IST_IBRS and the MSR bit at the definition point of
> the former,
> Reviewed-by: Jan Beulich 

Thanks,

~Andrew

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

Re: [Xen-devel] [PATCH v10 07/11] x86/entry: Avoid using alternatives in NMI/#MC paths

[Jan Beulich]

>>> On 25.01.18 at 16:04,  wrote:
> On 25/01/18 13:43, Jan Beulich wrote:
> On 24.01.18 at 14:12,  wrote:
>>> @@ -256,6 +261,69 @@
>>>  DO_SPEC_CTRL_EXIT_TO_GUEST, X86_FEATURE_XEN_IBRS_SET,   \
>>>  DO_SPEC_CTRL_EXIT_TO_GUEST, X86_FEATURE_XEN_IBRS_CLEAR
>>>  
>>> +/* TODO: Drop these when the alternatives infrastructure is NMI/#MC safe. 
>>> */
>>> +.macro SPEC_CTRL_ENTRY_FROM_INTR_IST
>>> +/*
>>> + * Requires %rsp=regs, %r14=stack_end
>>> + * Clobbers %rax, %rcx, %rdx
>>> + *
>>> + * This is logical merge of DO_OVERWRITE_RSB and DO_SPEC_CTRL_ENTRY
>>> + * maybexen=1, but with conditionals rather than alternatives.
>>> + */
>>> +movzbl STACK_CPUINFO_FIELD(bti_ist_info)(%r14), %eax
>>> +
>>> +testb $BTI_IST_RSB, %al
>>> +jz .L\@_skip_rsb
>>> +
>>> +DO_OVERWRITE_RSB
>>> +
>>> +.L\@_skip_rsb:
>>> +
>>> +testb $BTI_IST_WRMSR, %al
>>> +jz .L\@_skip_wrmsr
>>> +
>>> +testb $3, UREGS_cs(%rsp)
>>> +jz .L\@_entry_from_xen
>>> +
>>> +movb $0, STACK_CPUINFO_FIELD(use_shadow_spec_ctrl)(%r14)
>>> +
>>> +.L\@_entry_from_xen:
>>> +/*
>>> + * Load Xen's intended value.  SPEC_CTRL_IBRS vs 0 is encoded in the
>>> + * bottom bit of bti_ist_info, via a deliberate alias with 
>>> BTI_IST_IBRS.
>>> + */
>>> +mov $MSR_SPEC_CTRL, %ecx
>>> +and $BTI_IST_IBRS, %eax
>>> +xor %edx, %edx
>>> +wrmsr
>>> +
>>> +/* Opencoded UNLIKELY_START() with no condition. */
>>> +.Ldispatch.\@_serialise:
>>> +.subsection 1
>> How about adding .ifnb to UNLIKELY_START(), instead of open coding?
>> Or wait - why can't you use it as-is above (instead of the
>> "jz .L\@_skip_wrmsr")?
> 
> Because then the end label is wrong.  One way of another, we either need
> to opencode something, or implement UNLIKELY_ELSE() which is actually
> the likely case, and this is a substantially larger can of worms.

I'm willing to trust you for now (until I get around to play with this
myself), but I don't follow: In an UNLIKELY_START() /
UNLIKELY_END() pair, how could the labels be wrong if both specify
the same tag?

>> And then, having reached the end of the patch - where is the
>> new struct cpu_info field written? Or is this again happening only in
>> later patches, with the one here just setting the stage? If so,
>> shouldn't you at least zero the field in init_shadow_spec_ctrl_state()?
> 
> Hmm - I should set 0 in init_shadow_spec_ctrl_state().
> 
> All the other calculation logic needs to be deferred to the subsequent
> patch for bisectiblaty.

Of course. With this initialization fixed and the connection made
between BTI_IST_IBRS and the MSR bit at the definition point of
the former,
Reviewed-by: Jan Beulich 

Jan


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

Re: [Xen-devel] [PATCH v10 05/11] x86/entry: Organise the use of MSR_SPEC_CTRL at each entry/exit point

[Andrew Cooper]

On 25/01/18 15:08, Jan Beulich wrote:
 On 25.01.18 at 15:46,  wrote:
>> On 25/01/18 14:36, Jan Beulich wrote:
>> On 25.01.18 at 15:12,  wrote:
 On 25/01/18 13:08, Jan Beulich wrote:
> It may also be worthwhile again to pull up the zeroing of %edx,
> using %dl instead of $0 in the movb (and maybe then also
> similarly in DO_SPEC_CTRL_EXIT_TO_XEN, but there I'm less
> certain it couldn't have a negative effect).
 What negative effects are you worried about?  These macros are self
 contained.
>>> The result of the xor then is an input to the cmp, which may be
>>> one cycle more latency than with the immediate zero.
>> Why?  Cmp writes all flags and reads none of them, so doesn't have any
>> flags dependency on earlier instructions.
>>
>> It is only instructions which partially preserve older flag bits (and
>> where undefined behaviour is complicated) which suffer flags-merge
>> penalties.
> I'm not talking about an eflags dependency, but that on the
> register (%edx being written by xor, %dl used by cmp).

xor %edx, %edx is a zeroing idiom and doesn't get executed.  Register
renaming will cause the %dl to be sourced from the microarchitectural
idea of zero, rather than from the real result of the xor.

~Andrew

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

Re: [Xen-devel] [PATCH] xen: fix xsm build

[Ian Jackson]

Roger Pau Monné writes ("Re: [PATCH] xen: fix xsm build"):
> On Thu, Jan 25, 2018 at 01:14:24PM +, Wei Liu wrote:
> > Commit e8d461497d9 renamed gcov_op to coverage_op but forgot to change
> > XSM handles.
> > 
> > Signed-off-by: Wei Liu 
> 
> Reviewed-by: Roger Pau Monné 

Acked-by: Ian Jackson 

(in case you feel it's needed)

Thanks,
Ian.

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

Re: [Xen-devel] [PATCH v10 05/11] x86/entry: Organise the use of MSR_SPEC_CTRL at each entry/exit point

[Jan Beulich]

>>> On 25.01.18 at 15:46,  wrote:
> On 25/01/18 14:36, Jan Beulich wrote:
> On 25.01.18 at 15:12,  wrote:
>>> On 25/01/18 13:08, Jan Beulich wrote:
 It may also be worthwhile again to pull up the zeroing of %edx,
 using %dl instead of $0 in the movb (and maybe then also
 similarly in DO_SPEC_CTRL_EXIT_TO_XEN, but there I'm less
 certain it couldn't have a negative effect).
>>> What negative effects are you worried about?  These macros are self
>>> contained.
>> The result of the xor then is an input to the cmp, which may be
>> one cycle more latency than with the immediate zero.
> 
> Why?  Cmp writes all flags and reads none of them, so doesn't have any
> flags dependency on earlier instructions.
> 
> It is only instructions which partially preserve older flag bits (and
> where undefined behaviour is complicated) which suffer flags-merge
> penalties.

I'm not talking about an eflags dependency, but that on the
register (%edx being written by xor, %dl used by cmp).

Jan


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

Re: [Xen-devel] Xen Introspection, KPTI, and CR3 bit 63 leads to guest VMENTRY failures during introspection

[Razvan Cojocaru]

On 01/25/2018 12:31 AM, Bitweasil . wrote:
> I've recently discovered that if you attempt to use introspection to
> capture CR3 changes with the new KPTI enabled kernels, the guest dies
> shortly after the start of introspection with failed VM entry due to
> invalid guest state.
> 
> I believe the invalid state here is the high bit being set in CR3 -
> while this is how one indicates that PCID should not invalidate the
> various page table caches, introspection leads to this being set in the
> VMCS, which appears to be wrong.
> 
> With the XenServer 4.7.1 code base (which is my working code base at the
> moment), I have not found a way around this, as the
> vm_event_set_registers function (xen/arch/x86/vm_event.c) does not set
> the CR3 value, and vm_event_register_write_resume only allows inhibiting
> the write, not writing a modified value.
> 
> I've attempted several ways to work around this with a livepatch, and
> have not (yet) been successful.
> 
> Masking at the top of hvm_set_cr3 allows the guest to continue, but
> appears to do the wrong thing with regards to the guest (tasks begin
> dying quickly from invalid opcode errors).
> 
> In any case, Andrew mentions that this appears to still be an issue in
> staging, so this likely needs addressing.  At this point in time, I
> believe guests with KPTI enabled cannot be introspected if that
> introspection involves capturing CR3 changes.
> 
> Please let me know if you need any more details on this issue!

I've managed to reproduce the problem and this patch has fixed it for me
with Xen staging:

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index db282b5..7be962e 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2320,6 +2320,9 @@ int hvm_set_cr3(unsigned long value, bool_t may_defer)
 }
 }

+if ( hvm_pcid_enabled(v) )
+value &= ((1ull << 63) - 1);
+
 if ( hvm_paging_enabled(v) && !paging_mode_hap(v->domain) &&
  (value != v->arch.hvm_vcpu.guest_cr[3]) )
 {

Would you mind giving this a spin and confirm it also solves your problems?


Thanks,
Razvan

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

Re: [Xen-devel] [PATCH v10 07/11] x86/entry: Avoid using alternatives in NMI/#MC paths

[Andrew Cooper]

On 25/01/18 13:43, Jan Beulich wrote:
 On 24.01.18 at 14:12,  wrote:
>> --- a/xen/include/asm-x86/spec_ctrl_asm.h
>> +++ b/xen/include/asm-x86/spec_ctrl_asm.h
>> @@ -20,6 +20,11 @@
>>  #ifndef __X86_SPEC_CTRL_ASM_H__
>>  #define __X86_SPEC_CTRL_ASM_H__
>>  
>> +/* Encoding of the bottom bits in cpuinfo.bti_ist_info */
>> +#define BTI_IST_IBRS  (1 << 0)
> This should be annotated to make clear it can't change its value. Or
> maybe have something BUILD_BUG_ON()-like elsewhere.

Ok, although I don't intend for this code to stay around for very long.

>
>> @@ -256,6 +261,69 @@
>>  DO_SPEC_CTRL_EXIT_TO_GUEST, X86_FEATURE_XEN_IBRS_SET,   \
>>  DO_SPEC_CTRL_EXIT_TO_GUEST, X86_FEATURE_XEN_IBRS_CLEAR
>>  
>> +/* TODO: Drop these when the alternatives infrastructure is NMI/#MC safe. */
>> +.macro SPEC_CTRL_ENTRY_FROM_INTR_IST
>> +/*
>> + * Requires %rsp=regs, %r14=stack_end
>> + * Clobbers %rax, %rcx, %rdx
>> + *
>> + * This is logical merge of DO_OVERWRITE_RSB and DO_SPEC_CTRL_ENTRY
>> + * maybexen=1, but with conditionals rather than alternatives.
>> + */
>> +movzbl STACK_CPUINFO_FIELD(bti_ist_info)(%r14), %eax
>> +
>> +testb $BTI_IST_RSB, %al
>> +jz .L\@_skip_rsb
>> +
>> +DO_OVERWRITE_RSB
>> +
>> +.L\@_skip_rsb:
>> +
>> +testb $BTI_IST_WRMSR, %al
>> +jz .L\@_skip_wrmsr
>> +
>> +testb $3, UREGS_cs(%rsp)
>> +jz .L\@_entry_from_xen
>> +
>> +movb $0, STACK_CPUINFO_FIELD(use_shadow_spec_ctrl)(%r14)
>> +
>> +.L\@_entry_from_xen:
>> +/*
>> + * Load Xen's intended value.  SPEC_CTRL_IBRS vs 0 is encoded in the
>> + * bottom bit of bti_ist_info, via a deliberate alias with BTI_IST_IBRS.
>> + */
>> +mov $MSR_SPEC_CTRL, %ecx
>> +and $BTI_IST_IBRS, %eax
>> +xor %edx, %edx
>> +wrmsr
>> +
>> +/* Opencoded UNLIKELY_START() with no condition. */
>> +.Ldispatch.\@_serialise:
>> +.subsection 1
> How about adding .ifnb to UNLIKELY_START(), instead of open coding?
> Or wait - why can't you use it as-is above (instead of the
> "jz .L\@_skip_wrmsr")?

Because then the end label is wrong.  One way of another, we either need
to opencode something, or implement UNLIKELY_ELSE() which is actually
the likely case, and this is a substantially larger can of worms.

>
>> +/*
>> + * In the case that we might need to write to MSR_SPEC_CTRL for safety, 
>> we
>> + * need to ensure that an attacker can't poison the `jz 
>> .L\@_skip_wrmsr`
>> + * to speculate around the WRMSR.  As a result, we need a dispatch
>> + * serialising instruction in the else clause.
>> + */
>> +.L\@_skip_wrmsr:
>> +lfence
>> +UNLIKELY_END(\@_serialise)
>> +.endm
> Is LFENCE alone sufficient here for AMD in case "x86/amd: Try to
> set lfence as being Dispatch Serialising" failed to achieve the intended
> effect?

Technically, no.  In practice, yes.

The lfence is only needed when we require the WRMSR to set
SPEC_CTRL.IBRS to 1, and AMD don't implement IBRS yet.

>  In fact an LFENCE -> MFENCE conversion (through
> alternatives patching) would even be safe on the IST paths, as the
> two encodings differ by a single byte only.
>
>> +.macro SPEC_CTRL_EXIT_TO_XEN_IST
>> +/*
>> + * Requires %rbx=stack_end
>> + * Clobbers %rax, %rcx, %rdx
>> + */
>> +testb $BTI_IST_WRMSR, STACK_CPUINFO_FIELD(bti_ist_info)(%rbx)
>> +jz .L\@_skip
>> +
>> +DO_SPEC_CTRL_EXIT_TO_XEN
>> +
>> +.L\@_skip:
>> +.endm
> Why a new macro, instead of modifying the existing
> SPEC_CTRL_EXIT_TO_XEN, the sole use site of which is being
> changed? Just for the ease of eventually reverting?

Correct.  Having the IST name also makes it more obvious when reading
entry.S

> And then, having reached the end of the patch - where is the
> new struct cpu_info field written? Or is this again happening only in
> later patches, with the one here just setting the stage? If so,
> shouldn't you at least zero the field in init_shadow_spec_ctrl_state()?

Hmm - I should set 0 in init_shadow_spec_ctrl_state().

All the other calculation logic needs to be deferred to the subsequent
patch for bisectiblaty.

~Andrew

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

[Xen-devel] [PATCH] xen/arm: Fix platform name for Xilinx ZynqMP

[Amit Singh Tomar]

This seems to be copy/paste error.This patch simply
replace string xgene_storm with xilink_zymp for xilink
platform.

Signed-off-by: Amit Singh Tomar 
---
 xen/arch/arm/platforms/xilinx-zynqmp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/arm/platforms/xilinx-zynqmp.c 
b/xen/arch/arm/platforms/xilinx-zynqmp.c
index 2adee91..38f2c16 100644
--- a/xen/arch/arm/platforms/xilinx-zynqmp.c
+++ b/xen/arch/arm/platforms/xilinx-zynqmp.c
@@ -32,7 +32,7 @@ static const struct dt_device_match zynqmp_blacklist_dev[] 
__initconst =
 { /* sentinel */ },
 };
 
-PLATFORM_START(xgene_storm, "Xilinx ZynqMP")
+PLATFORM_START(xilink_zynqmp, "Xilinx ZynqMP")
 .compatible = zynqmp_dt_compat,
 .blacklist_dev = zynqmp_blacklist_dev,
 PLATFORM_END
-- 
1.9.1


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

Re: [Xen-devel] [PATCH RFC] xen: Improvements to domain_crash_sync()

[Konrad Rzeszutek Wilk]

On Wed, Jan 24, 2018 at 03:49:16PM +, Andrew Cooper wrote:
> The use of __LINE__ in a printk() is problematic for livepatching, as it
> causes unnecessary binary differences.
> 
> Furthermore, diagnostic information around calls is inconsistent and
> occasionally unhelpful.  (e.g. diagnosing logs from the field which might be
> release builds, or likely without exact source code).
> 
> Take the opportunity to improve things.  Shorten the name to
> domain_crash_sync() and require the user to pass a print message in.
> 
> Internally, the current vcpu and calling function are identified, and the
> message is emitted as a non-debug guest error.
> 
> Signed-off-by: Andrew Cooper 

I think I saw this at some point, from Ross like a year ago?

Anyhow: Reviewed-by: Konrad Rzeszutek Wilk 

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

Re: [Xen-devel] [PATCH v3 3/7] coverage: introduce generic file

[George Dunlap]

On 01/25/2018 02:47 PM, Konrad Rzeszutek Wilk wrote:
> On Wed, Jan 24, 2018 at 10:01:21AM +, Roger Pau Monne wrote:
>> It will contain the generic implementation of sysctl_cov_op, which
>> will be shared between all the coverage implementations.
>>
>> Signed-off-by: Roger Pau Monné 
>> Reviewed-by: Konrad Rzeszutek Wilk 
>> ---
>> Cc: Andrew Cooper 
>> Cc: George Dunlap 
>> Cc: Ian Jackson 
>> Cc: Jan Beulich 
>> Cc: Konrad Rzeszutek Wilk 
>> Cc: Stefano Stabellini 
>> Cc: Tim Deegan 
>> Cc: Wei Liu 
>> ---
>> Changes since v1:
>>  - Use private coverage.h header.
>>  - Sort alphabetically the obj-y list.
>> ---
>>  xen/common/coverage/Makefile   |  2 +-
>>  xen/common/coverage/coverage.c | 73 
>> ++
>>  xen/common/coverage/coverage.h |  1 +
>>  xen/common/coverage/gcov.c | 39 +-
>>  4 files changed, 76 insertions(+), 39 deletions(-)
>>  create mode 100644 xen/common/coverage/coverage.c
>>
>> diff --git a/xen/common/coverage/Makefile b/xen/common/coverage/Makefile
>> index a7a48494ca..5387bc6429 100644
>> --- a/xen/common/coverage/Makefile
>> +++ b/xen/common/coverage/Makefile
>> @@ -1,4 +1,4 @@
>> -obj-y += gcov_base.o gcov.o
>> +obj-y += coverage.o gcov_base.o gcov.o
>>  obj-y += $(call cc-ifversion,lt,0x040700, \
>>  gcc_3_4.o, $(call cc-ifversion,lt,0x040900, \
>>  gcc_4_7.o, $(call cc-ifversion,lt,0x05, \
>> diff --git a/xen/common/coverage/coverage.c b/xen/common/coverage/coverage.c
>> new file mode 100644
>> index 00..bd90f28663
>> --- /dev/null
>> +++ b/xen/common/coverage/coverage.c
>> @@ -0,0 +1,73 @@
>> +/*
>> + * Generic functionality for coverage analysis.
>> + *
>> + * Copyright (C) 2017 Citrix Systems R
> 
> 2018 now I believe.

I'm pretty sure the copyright starts from the time the work is created,
not the time it gets checked into a public tree.  Most of this would
have been written last year.

Since we're being pedantic. ;-)

 -George

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

Re: [Xen-devel] [PATCH v10 06/11] x86/entry: Organise the clobbering of the RSB/RAS on entry to Xen

[Jan Beulich]

>>> On 25.01.18 at 15:44,  wrote:
> On 25/01/18 14:40, Jan Beulich wrote:
> On 25.01.18 at 15:17,  wrote:
>>> On 25/01/18 13:19, Jan Beulich wrote:
  I think we want to have the same, to please AMD. I'd
 suggest to use alternative patching though (except again on the
 IST paths), but then again maybe in a follow-up patch.
>>> I trust the later patches are suitable in the IST regard?
>> I've responded to patch 7. What other later patches have anything
>> IST-related?
> 
> None, but my point was to inquire that your IST concern doesn't affect
> this patch?

No, it was just to re-emphasize that I think we'd be better off not
to patch any of the IST related code paths.

Jan


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

Re: [Xen-devel] [PATCH v3 3/7] coverage: introduce generic file

[Konrad Rzeszutek Wilk]

On Wed, Jan 24, 2018 at 10:01:21AM +, Roger Pau Monne wrote:
> It will contain the generic implementation of sysctl_cov_op, which
> will be shared between all the coverage implementations.
> 
> Signed-off-by: Roger Pau Monné 
> Reviewed-by: Konrad Rzeszutek Wilk 
> ---
> Cc: Andrew Cooper 
> Cc: George Dunlap 
> Cc: Ian Jackson 
> Cc: Jan Beulich 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Stefano Stabellini 
> Cc: Tim Deegan 
> Cc: Wei Liu 
> ---
> Changes since v1:
>  - Use private coverage.h header.
>  - Sort alphabetically the obj-y list.
> ---
>  xen/common/coverage/Makefile   |  2 +-
>  xen/common/coverage/coverage.c | 73 
> ++
>  xen/common/coverage/coverage.h |  1 +
>  xen/common/coverage/gcov.c | 39 +-
>  4 files changed, 76 insertions(+), 39 deletions(-)
>  create mode 100644 xen/common/coverage/coverage.c
> 
> diff --git a/xen/common/coverage/Makefile b/xen/common/coverage/Makefile
> index a7a48494ca..5387bc6429 100644
> --- a/xen/common/coverage/Makefile
> +++ b/xen/common/coverage/Makefile
> @@ -1,4 +1,4 @@
> -obj-y += gcov_base.o gcov.o
> +obj-y += coverage.o gcov_base.o gcov.o
>  obj-y += $(call cc-ifversion,lt,0x040700, \
>   gcc_3_4.o, $(call cc-ifversion,lt,0x040900, \
>   gcc_4_7.o, $(call cc-ifversion,lt,0x05, \
> diff --git a/xen/common/coverage/coverage.c b/xen/common/coverage/coverage.c
> new file mode 100644
> index 00..bd90f28663
> --- /dev/null
> +++ b/xen/common/coverage/coverage.c
> @@ -0,0 +1,73 @@
> +/*
> + * Generic functionality for coverage analysis.
> + *
> + * Copyright (C) 2017 Citrix Systems R

2018 now I believe.

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

Re: [Xen-devel] [PATCH v10 05/11] x86/entry: Organise the use of MSR_SPEC_CTRL at each entry/exit point

[Andrew Cooper]

On 25/01/18 14:36, Jan Beulich wrote:
 On 25.01.18 at 15:12,  wrote:
>> On 25/01/18 13:08, Jan Beulich wrote:
>>> It may also be worthwhile again to pull up the zeroing of %edx,
>>> using %dl instead of $0 in the movb (and maybe then also
>>> similarly in DO_SPEC_CTRL_EXIT_TO_XEN, but there I'm less
>>> certain it couldn't have a negative effect).
>> What negative effects are you worried about?  These macros are self
>> contained.
> The result of the xor then is an input to the cmp, which may be
> one cycle more latency than with the immediate zero.

Why?  Cmp writes all flags and reads none of them, so doesn't have any
flags dependency on earlier instructions.

It is only instructions which partially preserve older flag bits (and
where undefined behaviour is complicated) which suffer flags-merge
penalties.

~Andrew

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

Re: [Xen-devel] [PATCH v10 09/11] x86/ctxt: Issue a speculation barrier between vcpu contexts

[Konrad Rzeszutek Wilk]

On Wed, Jan 24, 2018 at 02:31:20PM +, David Woodhouse wrote:
> On Wed, 2018-01-24 at 13:49 +, Andrew Cooper wrote:
> > On 24/01/18 13:34, Woodhouse, David wrote:
> > > I am loath to suggest *more* tweakables, but given the IBPB cost is
> > > there any merit in having a mode which does it only if the *domain* is
> > > different, regardless of vcpu_id?
> >
> > This would only be a win if you were regularly cross-scheduling vcpus
> > from the same domain, which case you've probably other issues to be
> > worried about.
> 
> Of course. If the guest *knows* about HT siblings that kind of implies
> you've told it about the topology and thus you're pinning vCPU. I don't
> think there *is* a world in which what I said makes sense.

You can expose vNUMA and topology in the guest (and pin the vCPUS) so that
it will be not moving at all.

> 
> > > 
> > > If a given domain is running on HT siblings, it ought to be doing its
> > > own mitigation — setting STIBP for userspace if it wants, ensuring its
> > > own kernel is safe by having IBRS set or using retpoline, etc.
> > ~Andrew
> > 
> > [1] Is this trying to be a subtle hint?
> 
> Heh, no. When I get to that bit, and the *reasons* we do that, it'll be
> far from subtle. But as with so many other things, NOT THIS WEEK :)



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


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

Re: [Xen-devel] [PATCH v10 05/11] x86/entry: Organise the use of MSR_SPEC_CTRL at each entry/exit point

[Jan Beulich]

>>> On 25.01.18 at 15:12,  wrote:
> On 25/01/18 13:08, Jan Beulich wrote:
>> It may also be worthwhile again to pull up the zeroing of %edx,
>> using %dl instead of $0 in the movb (and maybe then also
>> similarly in DO_SPEC_CTRL_EXIT_TO_XEN, but there I'm less
>> certain it couldn't have a negative effect).
> 
> What negative effects are you worried about?  These macros are self
> contained.

The result of the xor then is an input to the cmp, which may be
one cycle more latency than with the immediate zero.

Jan


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

[Xen-devel] [PATCH v2 2/2] xen: add acpi_arch_get_root_pointer() for pvh guests

[Juergen Gross]

Add acpi_arch_get_root_pointer() for Xen PVH guests to communicate
the address of the RSDP table given to the kernel via Xen start info.

This makes the kernel boot again in PVH mode after on recent Xen the
RSDP was moved to higher addresses. So up to that change it was pure
luck that the legacy method to locate the RSDP was working when
running as PVH mode.

Cc:  # 4.11
Signed-off-by: Juergen Gross 
---
 arch/x86/xen/enlighten_pvh.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c
index 436c4f003e17..f08fd43f2aa2 100644
--- a/arch/x86/xen/enlighten_pvh.c
+++ b/arch/x86/xen/enlighten_pvh.c
@@ -16,15 +16,23 @@
 /*
  * PVH variables.
  *
- * xen_pvh and pvh_bootparams need to live in data segment since they
- * are used after startup_{32|64}, which clear .bss, are invoked.
+ * xen_pvh, pvh_bootparams and pvh_start_info need to live in data segment
+ * since they are used after startup_{32|64}, which clear .bss, are invoked.
  */
 bool xen_pvh __attribute__((section(".data"))) = 0;
 struct boot_params pvh_bootparams __attribute__((section(".data")));
+struct hvm_start_info pvh_start_info __attribute__((section(".data")));
 
-struct hvm_start_info pvh_start_info;
 unsigned int pvh_start_info_sz = sizeof(pvh_start_info);
 
+acpi_physical_address acpi_arch_get_root_pointer(void)
+{
+   if (xen_pvh)
+   return pvh_start_info.rsdp_paddr;
+
+   return 0;
+}
+
 static void __init init_pvh_bootparams(void)
 {
struct xen_memory_map memmap;
-- 
2.13.6


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

[Xen-devel] [PATCH v2 1/2] x86/acpi: add retrieval function for rsdp address

[Juergen Gross]

Add a function to get the address of the RSDP table. Per default use a
__weak annotated function being a nop.

Cc:  # 4.11
Signed-off-by: Juergen Gross 
---
 drivers/acpi/osl.c   | 10 +-
 include/linux/acpi.h |  2 ++
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 3bb46cb24a99..2b77db914752 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -178,6 +178,11 @@ void acpi_os_vprintf(const char *fmt, va_list args)
 #endif
 }
 
+__weak acpi_physical_address acpi_arch_get_root_pointer(void)
+{
+   return 0;
+}
+
 #ifdef CONFIG_KEXEC
 static unsigned long acpi_rsdp;
 static int __init setup_acpi_rsdp(char *arg)
@@ -189,12 +194,15 @@ early_param("acpi_rsdp", setup_acpi_rsdp);
 
 acpi_physical_address __init acpi_os_get_root_pointer(void)
 {
-   acpi_physical_address pa = 0;
+   acpi_physical_address pa;
 
 #ifdef CONFIG_KEXEC
if (acpi_rsdp)
return acpi_rsdp;
 #endif
+   pa = acpi_arch_get_root_pointer();
+   if (pa)
+   return pa;
 
if (efi_enabled(EFI_CONFIG_TABLES)) {
if (efi.acpi20 != EFI_INVALID_TABLE_ADDR)
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index dc1ebfeeb5ec..aa603cc5ad30 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -1266,4 +1266,6 @@ static inline int lpit_read_residency_count_address(u64 
*address)
 }
 #endif
 
+acpi_physical_address acpi_arch_get_root_pointer(void);
+
 #endif /*_LINUX_ACPI_H*/
-- 
2.13.6


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

[Xen-devel] [PATCH v2 0/2] xen: re-enable booting as Xen PVH guest

[Juergen Gross]

The Xen PVH boot protocol passes vital information to the kernel via
a start_info block. One of the data transferred is the physical address
of the RSDP table.

Unfortunately PVH support in the kernel didn't use that passed address
for RSDP, but relied on the legacy mechanism searching for the RSDP in
low memory. After a recent change in Xen putting the RSDP to a higher
address booting as PVH guest is now failing.

This small series repairs that by passing the RSDP address from the
start_info block to ACPI handling.

Juergen Gross (2):
  x86/acpi: add retrieval function for rsdp address
  xen: add acpi_arch_get_root_pointer() for pvh guests

 arch/x86/xen/enlighten_pvh.c | 14 +++---
 drivers/acpi/osl.c   | 10 +-
 include/linux/acpi.h |  2 ++
 3 files changed, 22 insertions(+), 4 deletions(-)

-- 
2.13.6


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

Re: [Xen-devel] [PATCH] MAINTAINERS: add the iommu list for swiotlb and xen-swiotlb

[Konrad Rzeszutek Wilk]

On Tue, Jan 16, 2018 at 08:56:24AM +0100, Christoph Hellwig wrote:
> All other discussions related to the dma mapping interfaces are on the
> iommu list, so let's make it the official list for swiotlb and the
> second list for xen-swiotlb.
> 
> Signed-off-by: Christoph Hellwig 

I am so behind emails.. I am not sure if I had replied to this, but just
in case I hadn't:

Acked-by: Konrad Rzeszutek Wilk 

P.S.
I am behind on the review of your dma rework - really sorry it is taking
that long.
> ---
>  MAINTAINERS | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 2d54e636d625..30dcafd388ac 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -13034,7 +13034,7 @@ F:arch/x86/boot/video*
>  
>  SWIOTLB SUBSYSTEM
>  M:   Konrad Rzeszutek Wilk 
> -L:   linux-ker...@vger.kernel.org
> +L:   io...@lists.linux-foundation.org
>  T:   git git://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb.git
>  S:   Supported
>  F:   lib/swiotlb.c
> @@ -14969,6 +14969,7 @@ F:include/xen/interface/io/vscsiif.h
>  XEN SWIOTLB SUBSYSTEM
>  M:   Konrad Rzeszutek Wilk 
>  L:   xen-devel@lists.xenproject.org (moderated for non-subscribers)
> +L:   io...@lists.linux-foundation.org
>  S:   Supported
>  F:   arch/x86/xen/*swiotlb*
>  F:   drivers/xen/*swiotlb*
> -- 
> 2.14.2
> 

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

Re: [Xen-devel] [PATCH v10 06/11] x86/entry: Organise the clobbering of the RSB/RAS on entry to Xen

[Andrew Cooper]

On 25/01/18 13:19, Jan Beulich wrote:
 On 24.01.18 at 14:12,  wrote:
>> --- a/xen/include/asm-x86/spec_ctrl_asm.h
>> +++ b/xen/include/asm-x86/spec_ctrl_asm.h
>> @@ -74,6 +74,43 @@
>>   *  - SPEC_CTRL_EXIT_TO_GUEST
>>   */
>>  
>> +.macro DO_OVERWRITE_RSB
>> +/*
>> + * Requires nothing
>> + * Clobbers %rax, %rcx
>> + *
>> + * Requires 256 bytes of stack space, but %rsp has no net change. Based on
>> + * Google's performance numbers, the loop is unrolled to 16 iterations and 
>> two
>> + * calls per iteration.
>> + *
>> + * The call filling the RSB needs a nonzero displacement.  A nop would do, 
>> but
>> + * we use "1: pause, jmp 1b" to safely contains any ret-based speculation,
>> + * even if the loop is speculatively executed prematurely.
>> + *
>> + * %rsp is preserved by using an extra GPR because a) we've got plenty 
>> spare,
>> + * b) the two movs are shorter to encode than `add $32*8, %rsp`, and c) can 
>> be
>> + * optimised with mov-elimination in modern cores.
>> + */
>> +mov $16, %ecx   /* 16 iterations, two calls per loop */
>> +mov %rsp, %rax  /* Store the current %rsp */
>> +
>> +.L\@_fill_rsb_loop:
>> +
>> +.irp n, 1, 2/* Unrolled twice. */
>> +call .L\@_insert_rsb_entry_\n   /* Create an RSB entry. */
>> +
>> +.L\@_capture_speculation_\n:
>> +pause
>> +jmp .L\@_capture_speculation_\n /* Capture rogue speculation. */
> Have you seen Linux commit 28d437d550e1e39f805d99f9f8ac399c778827b7
> ("x86/retpoline: Add LFENCE to the retpoline/RSB filling RSB
> macros")?

I saw the patch, but hadn't realised it had gone in.  There was quite a
long discussion.

>  I think we want to have the same, to please AMD. I'd
> suggest to use alternative patching though (except again on the
> IST paths), but then again maybe in a follow-up patch.

I trust the later patches are suitable in the IST regard?

~Andrew

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

Re: [Xen-devel] [RFC v2] xen/arm: Suspend to RAM Support in Xen for ARM

[Edgar E. Iglesias]

On Wed, Jan 24, 2018 at 07:04:35PM +0100, Mirela Simonovic wrote:
> Hi Oleksandr, Edgar,
> 
> 
> Thanks, you're right.
> 
> 
> On 01/23/2018 12:58 PM, Edgar E. Iglesias wrote:
> >On Tue, Jan 23, 2018 at 01:52:50PM +0200, Oleksandr Tyshchenko wrote:
> >>Hi Mirela,
> >>
> >>Just some remarks regarding the scope of work:
> >>
> >>+In addition, the following have to be implemented:
> >>+* Suspend/resume vCPU (triggered by vSYSTEM_SUSPEND call)
> >>+* Suspend/resume Xen (triggered by vSYSTEM_SUSPEND called by Dom0), 
> >>including:
> >>+   * Disable wathdog on suspend, enable it on resume
> >>+   * Pause domains on suspend, unpause them on resume
> >>+   * Disable non-boot pCPUs on suspend, enable them on resume
> >>+   * Save/restore of GIC configuration
> >>+   * Suspend/resume timer
> >>+   * Save/restore of EL2 context
> >>+   * Implement resume entry point in Xen, including MMU configuration
> >>
> >>I think that saving/restoring IOMMU registers/context should be
> >>implemented as well.
> >Yes, good point.
> >Mirela, I think that in the ZU+ case the IOMMU actually gets powered down
> >with the FPD.
> 
> Yes, it is in FPD.

Having said that it may still be useful from a patch review perspective
to incrementally add things. Perhaps the IOMMU suspending support could
come in follow-up patch series if others agree.

Best regards,
Edgar



> >
> >
> >>In other words, each involved platform device driver in Xen on ARM
> >>(IOMMU-XX, UART-XX, etc) should have suspend/resume callbacks
> >>implemented.
> 
> Yes, callback should be platform specific but not each platform has to have
> all callbacks implemented. E.g. on ZU+ UART is in differrent power domain
> compared to APU/Xen. Xen can suspend and its power domain can go down even
> if UART is not suspended. However, suspending UART even in this case may be
> beneficial from power perspective. We should definitely provide the option
> to implement the callback.
> 
> AFAIU, the following devices has to be suspended:
> 1. timer
> 2. IOMMU
> 3. UART
> 4. GIC
> 
> Please let me know if I missed something. I'll update this in next design
> spec version. Thank you very much for good feedback!
> 
> Cheers,
> Mirela
> >Yes agreed.
> >
> >Best regards,
> >Edgar
> >
> >
> >>-- 
> >>Regards,
> >>
> >>Oleksandr Tyshchenko
> 

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

Re: [Xen-devel] [PATCH v10 05/11] x86/entry: Organise the use of MSR_SPEC_CTRL at each entry/exit point

[Andrew Cooper]

On 25/01/18 13:08, Jan Beulich wrote:
 On 24.01.18 at 14:12,  wrote:
>> We need to be able to either set or clear IBRS in Xen context, as well as
>> restore appropriate guest values in guest context.  See the documentation in
>> asm-x86/spec_ctrl_asm.h for details.
>>
>> With the contemporary microcode, writes to %cr3 are slower when 
>> SPEC_CTRL.IBRS
>> is set.  Therefore, the positioning of SPEC_CTRL_{ENTRY/EXIT}* is important.
>>
>> Ideally, the IBRS_SET/IBRS_CLEAR hunks might be positioned either side of the
>> %cr3 change, but that is rather more complicated to arrange, and could still
>> result in a guest controlled value in SPEC_CTRL during the %cr3 change,
>> negating the saving if the guest chose to have IBRS set.
>>
>> Therefore, we optimise for the pre-Skylake case (being far more common in the
>> field than Skylake and later, at the moment), where we have a Xen-preferred
>> value of IBRS clear when switching %cr3.
>>
>> There is a semi-unrelated bugfix, where various asm_defn.h macros have a
>> hidden dependency on PAGE_SIZE, which results in an assembler error if used 
>> in
>> a .macro definition.
>>
>> Signed-off-by: Andrew Cooper 
> Reviewed-by: Jan Beulich 
>
> with a spelling observation and a question / perhaps implied
> suggestion:
>
>> @@ -99,6 +109,15 @@ UNLIKELY_END(realmode)
>>  .Lvmx_vmentry_fail:
>>  sti
>>  SAVE_ALL
>> +
>> +/*
>> + * PV variant needed here as no guest code has executed (so
>> + * MSR_SPEC_CTRL can't have changed value), and NMIs/MCEs are liable
>> + * to hit (in which case the HVM varient might corrupt things).
> variant

Fixed.

>
>> +.macro DO_SPEC_CTRL_ENTRY maybexen:req ibrs_val:req
>> +/*
>> + * Requires %rsp=regs (also cpuinfo if !maybexen)
>> + * Requires %r14=stack_end (if maybexen)
>> + * Clobbers %rax, %rcx, %rdx
>> + *
>> + * PV guests can't update MSR_SPEC_CTRL behind Xen's back, so no need to 
>> read
>> + * it back.  Entries from guest context need to clear SPEC_CTRL shadowing,
>> + * while entries from Xen must leave shadowing in its current state.
>> + */
>> +mov $MSR_SPEC_CTRL, %ecx
>> +
>> +.if \maybexen
>> +testb $3, UREGS_cs(%rsp)
>> +jz .L\@_entry_from_xen
>> +.endif
>> +
>> +/*
>> + * Clear SPEC_CTRL shadowing *before* loading Xen's value.  If entering
>> + * from a possibly-xen context, %rsp doesn't necessarily alias the 
>> cpuinfo
>> + * block so calculate the position directly.
>> + */
>> +.if \maybexen
>> +movb $0, STACK_CPUINFO_FIELD(use_shadow_spec_ctrl)(%r14)
>> +.else
>> +movb $0, CPUINFO_use_shadow_spec_ctrl(%rsp)
>> +.endif
>> +
>> +.L\@_entry_from_xen:
>> +/* Load Xen's intended value. */
>> +mov $\ibrs_val, %eax
>> +xor %edx, %edx
>> +wrmsr
>> +.endm
> Did you consider avoiding the conditional branch here altogether,
> by doing something like
>
> .if \maybexen
> testb $3, UREGS_cs(%rsp)
> setz %al
> neg %al
> and %al, STACK_CPUINFO_FIELD(use_shadow_spec_ctrl)(%r14)
> .else
>
> ?

That is quite subtle, although if you are looking to optimise further,
use_shadow_spec_ctrl being a bool means you can drop the neg.  An and
with the result of setz is good enough not to change the boolean value.

> It may also be worthwhile again to pull up the zeroing of %edx,
> using %dl instead of $0 in the movb (and maybe then also
> similarly in DO_SPEC_CTRL_EXIT_TO_XEN, but there I'm less
> certain it couldn't have a negative effect).

What negative effects are you worried about?  These macros are self
contained.

~Andrew

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

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

[George Dunlap]

On Thu, Jan 25, 2018 at 9:14 AM, Roger Pau Monné  wrote:
> On Wed, Jan 24, 2018 at 06:03:28PM +, George Dunlap wrote:
>> On Wed, Jan 17, 2018 at 9:48 AM, Roger Pau Monne  
>> wrote:
>> > Since VCPUOP_{up/down} already identity pins vCPU hotplug to pCPU
>> > hotplug also pin the vCPUs to the pCPUs in the scheduler. This prevent
>> > vCPU migration and should improve performance.
>> >
>> > While there also use __cpumask_set_cpu instead of cpumask_set_cpu,
>> > there's no need to use the locked variant.
>> >
>> > Signed-off-by: Roger Pau Monné 
>>
>> Sorry, I just realized this -- we already have a way to pin a VM 1:1
>> -- d->is_pinned should do what you want here without having to
>> special-case the pvshim.
>>
>> It seems like something like the attached might be better (compile-tested 
>> only).
>
> I haven't tested the proposed patch, but there's a peculiarity of the
> shim that I think makes this approach invalid.
>
> When Xen is booted in shim mode the APs are never started, which means
> that dom0_cpus only contains the BSP, and that alloc_vcpu is always
> going to be called with cpu == 0. This in turn means that
> sched_init_vcpu is also always called with cpu_id == 0, and if
> is_pinned is set it would force all vCPUs to be pinned to the BSP
> AFAICT.

Right, I see -- dom0 may not actually be running on pcpus 0-N (and in
theory there may be more vcpus than pcpus), so the code goes through
and pins them one-by-one based on what cpus it actually has, rather
than using the vcpu_id directly.

So it looks like you want to bring up cpus in Xen only when the guest
brings them up.  So in shim mode, you only bring up the BSP.  You want
all possible "dom0" (i.e. L2) vcpus *created* at boot time, and you
also want them pinned to their respective "pcpus" (L1 vcpus).

But you can't call alloc_vcpu() with the appropriate "pcpuid", because
then sched_init_vcpu() will set v->processor equal to a pcpu which
isn't up yet.  So you set dom0_cpus to contain only cpu0, so that
alloc_vcpu() will always be called with cpu 0; and then special-case
the affinity so that when it *does* come up, the affinity is already
set.

Is that about right?

What about setting the hard affinity in pv_shim_cpu_up() instead?
(You don't need to set the soft affinity, as the hard affinity will
override it.)

-George

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

Re: [Xen-devel] [PATCH v10 08/11] x86/boot: Calculate the most appropriate BTI mitigation to use

[Jan Beulich]

>>> On 24.01.18 at 14:12,  wrote:
> See the logic and comments in init_speculation_mitigations() for further
> details.
> 
> There are two controls for RSB overwriting, because in principle there are
> cases where it might be safe to forego rsb_native (Off the top of my head,
> SMEP active, no 32bit PV guests at all, no use of vmevent/paging subsystems
> for HVM guests, but I make no guarantees that this list of restrictions is
> exhaustive).
> 
> Signed-off-by: Andrew Cooper 

With the exception of the Intel model specific things
Reviewed-by: Jan Beulich 
Nevetherless ...

> ---
> CC: Jan Beulich 
> CC: Asit K Mallick 
> CC: Jun Nakajima 
> 
> TODO: Confirm Broadwell microcode details, and Atom safety WRT retpoline.
> These details should not block this series.

... I agree here, and hence the ack implied by the R-b extends to this.

> @@ -147,6 +237,50 @@ void __init init_speculation_mitigations(void)
>  else if ( thunk == THUNK_JMP )
>  setup_force_cpu_cap(X86_FEATURE_IND_THUNK_JMP);
>  
> +if ( boot_cpu_has(X86_FEATURE_IBRSB) )
> +{
> +/*
> + * Even if we've chosen to not have IBRS set in Xen context, we still
> + * need the IBRS entry/exit logic to virtualise IBRS support for
> + * guests.
> + */
> +if ( ibrs )
> +setup_force_cpu_cap(X86_FEATURE_XEN_IBRS_SET);
> +else
> +setup_force_cpu_cap(X86_FEATURE_XEN_IBRS_CLEAR);
> +
> +default_bti_ist_info |= BTI_IST_WRMSR | ibrs;
> +}
> +
> +/*
> + * PV guests can poison the RSB to any virtual address from which
> + * they can execute a call instruction.  This is necessarily outside
> + * of the Xen supervisor mappings.
> + *
> + * With SMEP enabled, the processor won't speculate into user mappings.
> + * Therefore, in this case, we don't need to worry about poisoned entries
> + * from 64bit PV guests.
> + *
> + * 32bit PV guest kernels run in ring 1, so use supervisor mappings.
> + * If a processors speculates to 32bit PV guest kernel mappings, it is
> + * speculating in 64bit supervisor mode, and can leak data.
> + */
> +if ( opt_rsb_native )
> +{
> +setup_force_cpu_cap(X86_FEATURE_RSB_NATIVE);
> +default_bti_ist_info |= BTI_IST_RSB;
> +}
> +
> +/*
> + * HVM guests can always poison the RSB to point at Xen supervisor
> + * mappings.
> + */
> +if ( opt_rsb_vmexit )
> +setup_force_cpu_cap(X86_FEATURE_RSB_VMEXIT);
> +
> +/* (Re)init BSP state how that default_bti_ist_info has been calculated. 
> */

... now that ...

Jan


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

[Xen-devel] [xen-4.8-testing test] 118302: regressions - trouble: broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm  broken
 test-xtf-amd64-amd64-3 49 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 118170

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 4 host-install(4) broken 
pass in 118285
 test-amd64-i386-xl-qemut-win10-i386 6 xen-install fail in 118285 pass in 118302
 test-xtf-amd64-amd64-5 49 xtf/test-hvm64-lbr-tsx-vmentry fail in 118285 pass 
in 118302
 test-armhf-armhf-xl  18 guest-destroyfail in 118285 pass in 118302
 test-xtf-amd64-amd64-4   49 xtf/test-hvm64-lbr-tsx-vmentry fail pass in 118285

Tests which did not succeed, but are not blocking:
 test-xtf-amd64-amd64-2 49 xtf/test-hvm64-lbr-tsx-vmentry fail in 118285 like 
118170
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail in 118285 never pass
 test-xtf-amd64-amd64-1  49 xtf/test-hvm64-lbr-tsx-vmentry fail like 118170
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 118170
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 118170
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 118170
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 118170
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 118170
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 118170
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 118170
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 118170
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 118170
 build-amd64-prev  7 xen-build/dist-test  fail   never pass
 build-i386-prev   7 xen-build/dist-test  fail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  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-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  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-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 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 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 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-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-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-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail 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-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   

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

[osstest service owner]

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

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 are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-saverestore  fail pass in 118289

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

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

Last test of basis   115539  2017-11-03 20:48:58 Z   82 days
Failing since115733  2017-11-10 17:19:59 Z   75 days   90 attempts
Testing same since   118140  2018-01-17 05:09:48 Z8 days   11 attempts


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

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



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

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

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

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


Not pushing.


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

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

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

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

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

Removed also a wrong debug print "PCI: invalid QEMU resource 

Re: [Xen-devel] [PATCH] xen: fix xsm build

[Andrew Cooper]

On 25/01/18 13:14, Wei Liu wrote:
> Commit e8d461497d9 renamed gcov_op to coverage_op but forgot to change
> XSM handles.
>
> Signed-off-by: Wei Liu 

Acked-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH v10 06/11] x86/entry: Organise the clobbering of the RSB/RAS on entry to Xen

[Jan Beulich]

>>> On 24.01.18 at 14:12,  wrote:
> --- a/xen/include/asm-x86/spec_ctrl_asm.h
> +++ b/xen/include/asm-x86/spec_ctrl_asm.h
> @@ -74,6 +74,43 @@
>   *  - SPEC_CTRL_EXIT_TO_GUEST
>   */
>  
> +.macro DO_OVERWRITE_RSB
> +/*
> + * Requires nothing
> + * Clobbers %rax, %rcx
> + *
> + * Requires 256 bytes of stack space, but %rsp has no net change. Based on
> + * Google's performance numbers, the loop is unrolled to 16 iterations and 
> two
> + * calls per iteration.
> + *
> + * The call filling the RSB needs a nonzero displacement.  A nop would do, 
> but
> + * we use "1: pause, jmp 1b" to safely contains any ret-based speculation,
> + * even if the loop is speculatively executed prematurely.
> + *
> + * %rsp is preserved by using an extra GPR because a) we've got plenty spare,
> + * b) the two movs are shorter to encode than `add $32*8, %rsp`, and c) can 
> be
> + * optimised with mov-elimination in modern cores.
> + */
> +mov $16, %ecx   /* 16 iterations, two calls per loop */
> +mov %rsp, %rax  /* Store the current %rsp */
> +
> +.L\@_fill_rsb_loop:
> +
> +.irp n, 1, 2/* Unrolled twice. */
> +call .L\@_insert_rsb_entry_\n   /* Create an RSB entry. */
> +
> +.L\@_capture_speculation_\n:
> +pause
> +jmp .L\@_capture_speculation_\n /* Capture rogue speculation. */

Have you seen Linux commit 28d437d550e1e39f805d99f9f8ac399c778827b7
("x86/retpoline: Add LFENCE to the retpoline/RSB filling RSB
macros")? I think we want to have the same, to please AMD. I'd
suggest to use alternative patching though (except again on the
IST paths), but then again maybe in a follow-up patch.

Jan


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

[Xen-devel] [PATCH] xen: fix xsm build

[Wei Liu]

Commit e8d461497d9 renamed gcov_op to coverage_op but forgot to change
XSM handles.

Signed-off-by: Wei Liu 
---
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Wei Liu 
Cc: Ian Jackson 
Cc: Roger Pau Monne 
Cc: Daniel De Graaf 
---
 tools/flask/policy/modules/dom0.te  | 2 +-
 xen/xsm/flask/hooks.c   | 4 ++--
 xen/xsm/flask/policy/access_vectors | 4 ++--
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/tools/flask/policy/modules/dom0.te 
b/tools/flask/policy/modules/dom0.te
index 07de3d5083..bf794d9bdd 100644
--- a/tools/flask/policy/modules/dom0.te
+++ b/tools/flask/policy/modules/dom0.te
@@ -16,7 +16,7 @@ allow dom0_t xen_t:xen {
 allow dom0_t xen_t:xen2 {
resource_op psr_cmt_op psr_alloc pmu_ctrl get_symbol
get_cpu_levelling_caps get_cpu_featureset livepatch_op
-   gcov_op set_parameter
+   coverage_op set_parameter
 };
 
 # Allow dom0 to use all XENVER_ subops that have checks.
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 835b3d1a03..3533259f9f 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -825,9 +825,9 @@ static int flask_sysctl(int cmd)
 case XEN_SYSCTL_livepatch_op:
 return avc_current_has_perm(SECINITSID_XEN, SECCLASS_XEN2,
 XEN2__LIVEPATCH_OP, NULL);
-case XEN_SYSCTL_gcov_op:
+case XEN_SYSCTL_coverage_op:
 return avc_current_has_perm(SECINITSID_XEN, SECCLASS_XEN2,
-XEN2__GCOV_OP, NULL);
+XEN2__COVERAGE_OP, NULL);
 case XEN_SYSCTL_set_parameter:
 return avc_current_has_perm(SECINITSID_XEN, SECCLASS_XEN2,
 XEN2__SET_PARAMETER, NULL);
diff --git a/xen/xsm/flask/policy/access_vectors 
b/xen/xsm/flask/policy/access_vectors
index 50dfc36c1c..e74d98d736 100644
--- a/xen/xsm/flask/policy/access_vectors
+++ b/xen/xsm/flask/policy/access_vectors
@@ -99,8 +99,8 @@ class xen2
 get_cpu_featureset
 # XEN_SYSCTL_livepatch_op
 livepatch_op
-# XEN_SYSCTL_gcov_op
-gcov_op
+# XEN_SYSCTL_coverage_op
+coverage_op
 # XEN_SYSCTL_set_parameter
 set_parameter
 }
-- 
2.11.0


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

Re: [Xen-devel] [PATCH v10 05/11] x86/entry: Organise the use of MSR_SPEC_CTRL at each entry/exit point

[Jan Beulich]

>>> On 24.01.18 at 14:12,  wrote:
> We need to be able to either set or clear IBRS in Xen context, as well as
> restore appropriate guest values in guest context.  See the documentation in
> asm-x86/spec_ctrl_asm.h for details.
> 
> With the contemporary microcode, writes to %cr3 are slower when SPEC_CTRL.IBRS
> is set.  Therefore, the positioning of SPEC_CTRL_{ENTRY/EXIT}* is important.
> 
> Ideally, the IBRS_SET/IBRS_CLEAR hunks might be positioned either side of the
> %cr3 change, but that is rather more complicated to arrange, and could still
> result in a guest controlled value in SPEC_CTRL during the %cr3 change,
> negating the saving if the guest chose to have IBRS set.
> 
> Therefore, we optimise for the pre-Skylake case (being far more common in the
> field than Skylake and later, at the moment), where we have a Xen-preferred
> value of IBRS clear when switching %cr3.
> 
> There is a semi-unrelated bugfix, where various asm_defn.h macros have a
> hidden dependency on PAGE_SIZE, which results in an assembler error if used in
> a .macro definition.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 

with a spelling observation and a question / perhaps implied
suggestion:

> @@ -99,6 +109,15 @@ UNLIKELY_END(realmode)
>  .Lvmx_vmentry_fail:
>  sti
>  SAVE_ALL
> +
> +/*
> + * PV variant needed here as no guest code has executed (so
> + * MSR_SPEC_CTRL can't have changed value), and NMIs/MCEs are liable
> + * to hit (in which case the HVM varient might corrupt things).

variant

> +.macro DO_SPEC_CTRL_ENTRY maybexen:req ibrs_val:req
> +/*
> + * Requires %rsp=regs (also cpuinfo if !maybexen)
> + * Requires %r14=stack_end (if maybexen)
> + * Clobbers %rax, %rcx, %rdx
> + *
> + * PV guests can't update MSR_SPEC_CTRL behind Xen's back, so no need to read
> + * it back.  Entries from guest context need to clear SPEC_CTRL shadowing,
> + * while entries from Xen must leave shadowing in its current state.
> + */
> +mov $MSR_SPEC_CTRL, %ecx
> +
> +.if \maybexen
> +testb $3, UREGS_cs(%rsp)
> +jz .L\@_entry_from_xen
> +.endif
> +
> +/*
> + * Clear SPEC_CTRL shadowing *before* loading Xen's value.  If entering
> + * from a possibly-xen context, %rsp doesn't necessarily alias the 
> cpuinfo
> + * block so calculate the position directly.
> + */
> +.if \maybexen
> +movb $0, STACK_CPUINFO_FIELD(use_shadow_spec_ctrl)(%r14)
> +.else
> +movb $0, CPUINFO_use_shadow_spec_ctrl(%rsp)
> +.endif
> +
> +.L\@_entry_from_xen:
> +/* Load Xen's intended value. */
> +mov $\ibrs_val, %eax
> +xor %edx, %edx
> +wrmsr
> +.endm

Did you consider avoiding the conditional branch here altogether,
by doing something like

.if \maybexen
testb $3, UREGS_cs(%rsp)
setz %al
neg %al
and %al, STACK_CPUINFO_FIELD(use_shadow_spec_ctrl)(%r14)
.else

?

It may also be worthwhile again to pull up the zeroing of %edx,
using %dl instead of $0 in the movb (and maybe then also
similarly in DO_SPEC_CTRL_EXIT_TO_XEN, but there I'm less
certain it couldn't have a negative effect).

Jan


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

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

[osstest service owner]

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

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  2375832c7e51b67f076e6b07854c4a541cb4bdc3
baseline version:
 xen  1252e2823117346e1aad0c5f17cc76200194f808

Last test of basis   118312  2018-01-24 21:02:50 Z0 days
Testing same since   118326  2018-01-25 11:01:28 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Kevin Tian 

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
   1252e28231..2375832c7e  2375832c7e51b67f076e6b07854c4a541cb4bdc3 -> smoke

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

Re: [Xen-devel] [PATCH 2/2] xen: add acpi_arch_get_root_pointer() for pvh guests

[Greg KH]

On Thu, Jan 25, 2018 at 01:06:26PM +0100, Juergen Gross wrote:
> On 25/01/18 12:00, Greg KH wrote:
> > On Thu, Jan 25, 2018 at 11:49:35AM +0100, Juergen Gross wrote:
> >> On 25/01/18 11:37, Greg KH wrote:
> >>> On Thu, Jan 25, 2018 at 11:04:54AM +0100, Juergen Gross wrote:
>  Add acpi_arch_get_root_pointer() for Xen PVH guests to communicate
>  the address of the RSDP table given to the kernel via Xen start info.
> 
>  This makes the kernel boot again in PVH mode after on recent Xen the
>  RSDP was moved to higher addresses. So up to that change it was pure
>  luck that the legacy method to locate the RSDP was working when
>  running as PVH mode.
> 
>  Cc:  # 4.11
>  Signed-off-by: Juergen Gross 
>  ---
>   arch/x86/xen/enlighten_pvh.c | 15 ---
>   1 file changed, 12 insertions(+), 3 deletions(-)
> 
>  diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c
>  index 436c4f003e17..9a5c3a7fe673 100644
>  --- a/arch/x86/xen/enlighten_pvh.c
>  +++ b/arch/x86/xen/enlighten_pvh.c
>  @@ -16,15 +16,24 @@
>   /*
>    * PVH variables.
>    *
>  - * xen_pvh and pvh_bootparams need to live in data segment since they
>  - * are used after startup_{32|64}, which clear .bss, are invoked.
>  + * xen_pvh, pvh_bootparams and pvh_start_info need to live in data 
>  segment
>  + * since they are used after startup_{32|64}, which clear .bss, are 
>  invoked.
>    */
>   bool xen_pvh __attribute__((section(".data"))) = 0;
>   struct boot_params pvh_bootparams __attribute__((section(".data")));
>  +struct hvm_start_info pvh_start_info __attribute__((section(".data")));
>   
>  -struct hvm_start_info pvh_start_info;
>   unsigned int pvh_start_info_sz = sizeof(pvh_start_info);
>   
>  +acpi_physical_address acpi_arch_get_root_pointer(void)
>  +{
>  +if (xen_pvh)
>  +return pvh_start_info.rsdp_paddr;
>  +
>  +return 0;
>  +}
>  +EXPORT_SYMBOL_GPL(acpi_arch_get_root_pointer);
> >>>
> >>> Why does this have to be an exported symbol?  Does this code get built
> >>> as a module and will the linker somehow go and rewrite the previous call
> >>> places with this one if it gets loaded?
> >>
> >> With being called by drivers/acpi/... I just wanted to make sure it is
> >> working properly even in case the acpi code is built as a module.
> > 
> > I didn't think the core ACPI code can be built as a module, have you
> > tried that?
> 
> No, but as the build wouldn't break whenever this is changed I wanted
> to make sure the symbol is found.
> 
> If you feel strong about that I can remove the EXPORT_SYMBOL_GPL().

Please don't export symbols that do not need to be exported, that's just
a waste.

thanks,

greg k-h

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

Re: [Xen-devel] Xen Introspection, KPTI, and CR3 bit 63 leads to guest VMENTRY failures during introspection

[Razvan Cojocaru]

On 01/25/2018 02:25 PM, Razvan Cojocaru wrote:
> On 01/25/2018 02:15 AM, Andrew Cooper wrote:
>> On 24/01/2018 22:31, Bitweasil . wrote:
>>> I've recently discovered that if you attempt to use introspection to
>>> capture CR3 changes with the new KPTI enabled kernels, the guest dies
>>> shortly after the start of introspection with failed VM entry due to
>>> invalid guest state.
>>>
>>> I believe the invalid state here is the high bit being set in CR3 -
>>> while this is how one indicates that PCID should not invalidate the
>>> various page table caches, introspection leads to this being set in
>>> the VMCS, which appears to be wrong.
>>>
>>> With the XenServer 4.7.1 code base (which is my working code base at
>>> the moment), I have not found a way around this, as the
>>> vm_event_set_registers function (xen/arch/x86/vm_event.c) does not set
>>> the CR3 value, and vm_event_register_write_resume only allows
>>> inhibiting the write, not writing a modified value.
>>>
>>> I've attempted several ways to work around this with a livepatch, and
>>> have not (yet) been successful.
>>>
>>> Masking at the top of hvm_set_cr3 allows the guest to continue, but
>>> appears to do the wrong thing with regards to the guest (tasks begin
>>> dying quickly from invalid opcode errors).
>>>
>>> In any case, Andrew mentions that this appears to still be an issue in
>>> staging, so this likely needs addressing.  At this point in time, I
>>> believe guests with KPTI enabled cannot be introspected if that
>>> introspection involves capturing CR3 changes.
>>>
>>> Please let me know if you need any more details on this issue!
>>
>> Just as an FYI to people reading this, that is actually XenServer 7.1's
>> hypervisor which is Xen 4.7.1-based but the fact that the HVM CR3 code
>> has little-to-no clue about PCID appears to be unchanged into staging. 
>> Sadly, it doesn't appear to be trivial to fix.
> 
> Well, FWIW we do support masks for CR events since Xen 4.10 - we can
> simply mask whatever bits we _don't_ want events sent out for. I don't
> know if this solves Bitweasil's problem, but it's certainly something to
> take into consideration.
> 
> For example, looking at xen-access.c:
> 
> 629 if ( write_ctrlreg_cr4 )
> 630 {
> 631 /* Mask the CR4.PGE bit so no events will be generated for
> global TLB flushes. */
> 632 rc = xc_monitor_write_ctrlreg(xch, domain_id,
> VM_EVENT_X86_CR3, 1, 1,
> 633   X86_CR3_PGE, 1);

This line says X86_CR4_PGE (as it should) in the original xen-access.c -
I was just messing with it and forgot. Sorry.


Thanks,
Razvan

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

Re: [Xen-devel] [PATCH v10 02/11] x86/msr: Emulation of MSR_{SPEC_CTRL, PRED_CMD} for guests

[Jan Beulich]

>>> On 24.01.18 at 14:12,  wrote:
> As per the spec currently available here:
> 
> https://software.intel.com/sites/default/files/managed/c5/63/336996-Speculative-Execution-Side-Channel-Mitigations.pdf
> 
> MSR_ARCH_CAPABILITIES will only come into existence on new hardware, but is
> implemented as a straight #GP for now to avoid being leaky when new hardware
> arrives.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 



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

Re: [Xen-devel] Xen Introspection, KPTI, and CR3 bit 63 leads to guest VMENTRY failures during introspection

[Razvan Cojocaru]

On 01/25/2018 02:15 AM, Andrew Cooper wrote:
> On 24/01/2018 22:31, Bitweasil . wrote:
>> I've recently discovered that if you attempt to use introspection to
>> capture CR3 changes with the new KPTI enabled kernels, the guest dies
>> shortly after the start of introspection with failed VM entry due to
>> invalid guest state.
>>
>> I believe the invalid state here is the high bit being set in CR3 -
>> while this is how one indicates that PCID should not invalidate the
>> various page table caches, introspection leads to this being set in
>> the VMCS, which appears to be wrong.
>>
>> With the XenServer 4.7.1 code base (which is my working code base at
>> the moment), I have not found a way around this, as the
>> vm_event_set_registers function (xen/arch/x86/vm_event.c) does not set
>> the CR3 value, and vm_event_register_write_resume only allows
>> inhibiting the write, not writing a modified value.
>>
>> I've attempted several ways to work around this with a livepatch, and
>> have not (yet) been successful.
>>
>> Masking at the top of hvm_set_cr3 allows the guest to continue, but
>> appears to do the wrong thing with regards to the guest (tasks begin
>> dying quickly from invalid opcode errors).
>>
>> In any case, Andrew mentions that this appears to still be an issue in
>> staging, so this likely needs addressing.  At this point in time, I
>> believe guests with KPTI enabled cannot be introspected if that
>> introspection involves capturing CR3 changes.
>>
>> Please let me know if you need any more details on this issue!
> 
> Just as an FYI to people reading this, that is actually XenServer 7.1's
> hypervisor which is Xen 4.7.1-based but the fact that the HVM CR3 code
> has little-to-no clue about PCID appears to be unchanged into staging. 
> Sadly, it doesn't appear to be trivial to fix.

Well, FWIW we do support masks for CR events since Xen 4.10 - we can
simply mask whatever bits we _don't_ want events sent out for. I don't
know if this solves Bitweasil's problem, but it's certainly something to
take into consideration.

For example, looking at xen-access.c:

629 if ( write_ctrlreg_cr4 )
630 {
631 /* Mask the CR4.PGE bit so no events will be generated for
global TLB flushes. */
632 rc = xc_monitor_write_ctrlreg(xch, domain_id,
VM_EVENT_X86_CR3, 1, 1,
633   X86_CR3_PGE, 1);
634 if ( rc < 0 )
635 {
636 ERROR("Error %d setting write control register trapping
with vm_event\n", rc);
637 goto exit;
638 }
639 }
640


Thanks,
Razvan

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

Re: [Xen-devel] [PATCH 2/2] xen: add acpi_arch_get_root_pointer() for pvh guests

[Juergen Gross]

On 25/01/18 12:00, Greg KH wrote:
> On Thu, Jan 25, 2018 at 11:49:35AM +0100, Juergen Gross wrote:
>> On 25/01/18 11:37, Greg KH wrote:
>>> On Thu, Jan 25, 2018 at 11:04:54AM +0100, Juergen Gross wrote:
 Add acpi_arch_get_root_pointer() for Xen PVH guests to communicate
 the address of the RSDP table given to the kernel via Xen start info.

 This makes the kernel boot again in PVH mode after on recent Xen the
 RSDP was moved to higher addresses. So up to that change it was pure
 luck that the legacy method to locate the RSDP was working when
 running as PVH mode.

 Cc:  # 4.11
 Signed-off-by: Juergen Gross 
 ---
  arch/x86/xen/enlighten_pvh.c | 15 ---
  1 file changed, 12 insertions(+), 3 deletions(-)

 diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c
 index 436c4f003e17..9a5c3a7fe673 100644
 --- a/arch/x86/xen/enlighten_pvh.c
 +++ b/arch/x86/xen/enlighten_pvh.c
 @@ -16,15 +16,24 @@
  /*
   * PVH variables.
   *
 - * xen_pvh and pvh_bootparams need to live in data segment since they
 - * are used after startup_{32|64}, which clear .bss, are invoked.
 + * xen_pvh, pvh_bootparams and pvh_start_info need to live in data segment
 + * since they are used after startup_{32|64}, which clear .bss, are 
 invoked.
   */
  bool xen_pvh __attribute__((section(".data"))) = 0;
  struct boot_params pvh_bootparams __attribute__((section(".data")));
 +struct hvm_start_info pvh_start_info __attribute__((section(".data")));
  
 -struct hvm_start_info pvh_start_info;
  unsigned int pvh_start_info_sz = sizeof(pvh_start_info);
  
 +acpi_physical_address acpi_arch_get_root_pointer(void)
 +{
 +  if (xen_pvh)
 +  return pvh_start_info.rsdp_paddr;
 +
 +  return 0;
 +}
 +EXPORT_SYMBOL_GPL(acpi_arch_get_root_pointer);
>>>
>>> Why does this have to be an exported symbol?  Does this code get built
>>> as a module and will the linker somehow go and rewrite the previous call
>>> places with this one if it gets loaded?
>>
>> With being called by drivers/acpi/... I just wanted to make sure it is
>> working properly even in case the acpi code is built as a module.
> 
> I didn't think the core ACPI code can be built as a module, have you
> tried that?

No, but as the build wouldn't break whenever this is changed I wanted
to make sure the symbol is found.

If you feel strong about that I can remove the EXPORT_SYMBOL_GPL().


Juergen

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

Re: [Xen-devel] [PATCH] PCI/passthrough: don't discard Dom0 provided information

[Roger Pau Monné]

On Wed, Dec 06, 2017 at 09:19:16AM -0700, Jan Beulich wrote:
> Instead of giving, to subsequent code, the appearance of there not
> having been any "info" data provided, adjust the conditional guarding
> SR-IOV handling.
> 
> Signed-off-by: Jan Beulich 

Reviewed-by: Roger Pau Monné 

> --- a/xen/drivers/passthrough/pci.c
> +++ b/xen/drivers/passthrough/pci.c
> @@ -629,10 +629,7 @@ int pci_add_device(u16 seg, u8 bus, u8 d
>  else if ( info->is_extfn )
>  pdev_type = "extended function";
>  else
> -{
> -info = NULL;
>  pdev_type = "device";
> -}

You could shorten the if ... else if ... with something like:

pdev_type = "device";

if ( info && info->is_virtfn )
...
else if ( info && info->is_extfn )
...

But I'm not sure that's much better, it will just make the source
slightly shorter.

Thanks, Roger.

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

Re: [Xen-devel] [PATCH 5/7] xen/arm32: Invalidate BTB on guest exit for Cortex A17 and 12

[Julien Grall]

Hi Stefano,

On 25/01/18 01:02, Stefano Stabellini wrote:

On Fri, 19 Jan 2018, Julien Grall wrote:

In order to avoid aliasing attackes agains the branch predictor, let's
invalidate the BTB on guest exist. This is made complicated by the fact
that we cannot take a branch invalidating the BTB.

This is based on the first version posrted by Marc Zyngier on Linux-arm
mailing list (see [1]).

This is part of XSA-254.

Signed-off-by: Marc Zyngier 
Signed-off-by: Julien Grall 

[1] https://www.spinics.net/lists/arm-kernel/msg627032.html
---
  xen/arch/arm/arm32/entry.S | 55 ++
  xen/arch/arm/cpuerrata.c   | 19 
  2 files changed, 74 insertions(+)

diff --git a/xen/arch/arm/arm32/entry.S b/xen/arch/arm/arm32/entry.S
index 54a1733f87..c6ec0aa399 100644
--- a/xen/arch/arm/arm32/entry.S
+++ b/xen/arch/arm/arm32/entry.S
@@ -160,6 +160,61 @@ GLOBAL(hyp_traps_vector)
  b trap_irq  /* 0x18 - IRQ */
  b trap_fiq  /* 0x1c - FIQ */
  
+.align 5

+GLOBAL(hyp_traps_vector_bp_inv)
+/*
+ * We encode the exception entry in the bottom 3 bits of
+ * SP, and we have to guarantee to be 8 bytes aligned.
+ */
+add sp, sp, #1  /* Reset7 */
+add sp, sp, #1  /* Undef6 */
+add sp, sp, #1  /* Hypervisor Call  5 */
+add sp, sp, #1  /* Prefetch abort   4 */
+add sp, sp, #1  /* Data abort   3 */
+add sp, sp, #1  /* Hypervisor   2 */
+add sp, sp, #1  /* IRQ  1 */
+nop /* FIQ  0 */


Clever! Things that you don't read every day :-)


Thanks Marc for the idea :).





+mcrp15, 0, r0, c7, c5, 6   /* BPIALL */
+isb
+
+/*
+ * As we cannot use any temporary registers and cannot
+ * clobber SP, we can decode the exception entry using
+ * an unrolled binary search.
+ */
+tst sp, #4
+bne 1f
+
+tst sp, #2
+bne 3f
+
+tst sp, #1
+bic sp, sp, #0x7
+bne trap_irq
+b   trap_fiq


I might be confused, but this is the case where sp == 0x7, right?
Shouldn't we have b trap_reset here?

Similarly the branch just above corresponds to 0x6, which should be
bne trap_undefined_instruction.

What am I getting wrong?


The tst instruction performs a bitwise AND on a register value (here 
sp). The result will be used to update the condition flags.


So with tst sp, #4 the result will either be 0x100 or 0x000. The former 
will clear Z flag while the latter set Z flag.


This means that bne will branch only when bit 2 is set. So the only way 
to end here is because the first 3-bit are equal to 0x00X. This 
corresponds to IRQ/FIQ vector.


Cheers,

--
Julien Grall

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

[Xen-devel] Ping: [PATCH] PCI/passthrough: don't discard Dom0 provided information

[Jan Beulich]

>>> On 06.12.17 at 17:19,  wrote:
> Instead of giving, to subsequent code, the appearance of there not
> having been any "info" data provided, adjust the conditional guarding
> SR-IOV handling.
> 
> Signed-off-by: Jan Beulich 

Anyone caring to take a look? Otherwise I'll commit this without
any ack in a couple of days.

Jan

> --- a/xen/drivers/passthrough/pci.c
> +++ b/xen/drivers/passthrough/pci.c
> @@ -629,10 +629,7 @@ int pci_add_device(u16 seg, u8 bus, u8 d
>  else if ( info->is_extfn )
>  pdev_type = "extended function";
>  else
> -{
> -info = NULL;
>  pdev_type = "device";
> -}
>  
>  ret = xsm_resource_plug_pci(XSM_PRIV, (seg << 16) | (bus << 8) | devfn);
>  if ( ret )
> @@ -660,7 +657,8 @@ int pci_add_device(u16 seg, u8 bus, u8 d
>  if ( pdev->info.is_virtfn )
>  pdev->info.is_extfn = pf_is_extfn;
>  }
> -else if ( !pdev->vf_rlen[0] )
> +
> +if ( !pdev->info.is_virtfn && !pdev->vf_rlen[0] )
>  {
>  unsigned int pos = pci_find_ext_capability(seg, bus, devfn,
> PCI_EXT_CAP_ID_SRIOV);
> 
> 
> 




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

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

[Andrew Cooper]

On 25/01/18 11:24, Wei Liu wrote:
> On Thu, Jan 25, 2018 at 02:51:34AM +, osstest service owner wrote:
>> flight 118296 xen-unstable real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/118296/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>>  test-armhf-armhf-xl-credit2 16 guest-start/debian.repeat fail REGR. vs. 
>> 118174
> There seems to be a genuine bug.
>
> http://logs.test-lab.xenproject.org/osstest/logs/118296/test-armhf-armhf-xl-credit2/serial-cubietruck-braque.log
>
> Jan 24 09:18:48.859356 (XEN) traps.c:2033:d9v0 HSR=0x8006 pc=0xc gva=0xc 
> gpa=0x0c
> Jan 24 09:18:48.865981 (XEN) (XEN) traps.c:2033:d9v0 HSR=0x8006 pc=0xc 
> gva=0xc gpa=0x0c
> Jan 24 09:18:48.873107 (XEN) traps.c:2033:d9v0 HSR=0x8006 pc=0xc gva=0xc 
> gpa=0x0c
> Jan 24 09:18:48.879732 (XEN) traps.c:2033:d9v0 HSR=0x8006 pc=0xc gva=0xc 
> gpa=0x0c
>
>>  test-amd64-amd64-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail REGR. 
>> vs. 118174
> libxl-save-helper: debug: starting restore: Success
> xc: detail: fd 8, dom 18, hvm 0, pae 0, stream_type 0
> xc: info: Found x86 HVM domain from Xen 4.11
> xc: info: Restoring domain
> xc: error: Failed to get types for pfn batch (14 = Bad address): Internal 
> error
> xc: error: Save failed (14 = Bad address): Internal error
>
> This looks familiar to the known issue for Windows migration test.

This is the toolstack getting -EFAULT for a hypercall.  It is a dom0
bug, not a guest bug.

~Andrew

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

Re: [Xen-devel] [PATCH] x86/emul: Split exception handling out of invoke_stub()

[Jan Beulich]

>>> On 25.01.18 at 12:09,  wrote:
> On 25/01/18 10:49, Jan Beulich wrote:
> On 24.01.18 at 19:16,  wrote:
>>> For a release build, bloat-o-meter reports:
>>>
>>>   add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-5111 (-5111)
>>>   function old new   delta
>>>   x86_emulate   126458  121347   -5111
>>>
>>> or in other words, a 4% redunction in code size from this change alone.
>>>
>>> While shuffling things around, drop the use of __LINE__,
>> While the rest of the change is fine, I continue to object to the
>> removal of __LINE__ here - afaict it is awkward to reconstruct the
>> line number when being presented just the address. At the very
>> least you'd have to run a tool like addr2line, which assumes you
>> have the correct binary to hand (which is not very likely based on
>> my experience). However much I can agree that line numbers get
>> in the way of live patching, there are cases where problem
>> analysis is quite a bit harder without them. And this is an example
>> thereof.
> 
> The point of printing the instruction stream at the WARNING is that it
> uniquely identifies the invoke_stub() call, just like the __LINE__
> information does,

I don't think I see why that would be. There are certainly
instructions which we encode in more than one place (first
and foremost {,v}pmovmskb and vmovmskp{s,d}. This set is
liable to grow once we get to support AVX512.

> and this rearrangement makes __LINE__ awkward to use. 
> We'd need another __XEN__-guarded local variable on the stack.

Why? Just add a line number field to stub_exn_info.

> The tradeoff for livepatching is how likely we are to have a
> livepatchable security issue which modifies something in x86_emulate.c
> which results in perturbance of __LINE__, vs the utility of using
> __LINE__ in the first place.
> 
> All uses of __LINE__ here are part of x86_emulate(), but we have had
> issues in the past which are fixed exclusively in the x86_decode() path.

I'm afraid I can't really conclude what you're trying to tell me here.

Jan


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

Re: [Xen-devel] [PATCH 4/7] xen/arm32: Add skeleton to harden branch predictor aliasing attacks

[Julien Grall]

Hi Stefano,

On 24/01/18 23:54, Stefano Stabellini wrote:

On Fri, 19 Jan 2018, Julien Grall wrote:

Aliasing attacked against CPU branch predictors can allow an attacker to
redirect speculative control flow on some CPUs and potentially divulge
information from one context to another.

This patch adds initiatial skeleton code behind a new Kconfig option
to enable implementation-specific mitigations against these attacks
for CPUs that are affected.

Most of mitigations will have to be applied when entering to the
hypervisor from the guest context.

Because the attack is against branch predictor, it is not possible to
safely use branch instruction before the mitigation is applied.
Therefore this has to be done in the vector entry before jump to the
helper handling a given exception.

However, on arm32, each vector contain a single instruction. This means
that the hardened vector tables may rely on the state of registers that
does not hold when in the hypervisor (e.g SP is 8 bytes aligned).
Therefore hypervisor code running with guest vectors table should be
minimized and always have interrupts masked to reduce the risk to use
them.

This patch provides an infrastructure to switch vector tables before
entering to the guest and when leaving it.

Note that alternative could have been used, but older Xen (4.8 or
earlier) doesn't have support. So avoid using alternative to ease
backporting.

This is part of XSA-254.

Signed-off-by: Julien Grall 


I only have a couple of questions. It looks good.



---
  xen/arch/arm/Kconfig   |  3 +++
  xen/arch/arm/arm32/entry.S | 41 -
  xen/arch/arm/cpuerrata.c   | 30 ++
  3 files changed, 73 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 06fd85cc77..2782ee6589 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -191,6 +191,9 @@ config HARDEN_BRANCH_PREDICTOR
  config ARM64_HARDEN_BRANCH_PREDICTOR
  def_bool y if ARM_64 && HARDEN_BRANCH_PREDICTOR
  
+config ARM32_HARDEN_BRANCH_PREDICTOR

+def_bool y if ARM_32 && HARDEN_BRANCH_PREDICTOR
+
  source "common/Kconfig"
  
  source "drivers/Kconfig"

diff --git a/xen/arch/arm/arm32/entry.S b/xen/arch/arm/arm32/entry.S
index c2fad5fe9b..54a1733f87 100644
--- a/xen/arch/arm/arm32/entry.S
+++ b/xen/arch/arm/arm32/entry.S
@@ -34,6 +34,20 @@
  blne save_guest_regs
  
  save_guest_regs:

+#ifdef CONFIG_ARM32_HARDEN_BRANCH_PREDICTOR
+/*
+ * Restore vectors table to the default as it may have been
+ * changed when returning to the guest (see
+ * return_to_hypervisor). We need to do that early (e.g before
+ * any interrupts are unmasked) because hardened vectors requires
+ * SP to be 8 bytes aligned. This does not hold when running in
+ * the hypervisor.
+ */
+ldr r1, =hyp_traps_vector
+mcr p15, 4, r1, c12, c0, 0
+isb
+#endif
+
  ldr r11, =0x  /* Clobber SP which is only valid for 
hypervisor frames. */
  str r11, [sp, #UREGS_sp]
  SAVE_ONE_BANKED(SP_usr)
@@ -179,12 +193,37 @@ return_to_guest:
  RESTORE_ONE_BANKED(R11_fiq); RESTORE_ONE_BANKED(R12_fiq);
  /* Fall thru */
  return_to_hypervisor:
-cpsid i
+cpsid ai


Why?


Asynchronous abort is a kind of interrupt, as we are going to switch to 
the hardened vector tables you don't want an interrupt to come up.


This is because the hardened vector tables requires SP to be 8 bytes 
aligned. When in the hypervisor, and particularly when restoring the 
register (as below), this assumption does not hold.


So masking all interrupts (as mentioned a few time within the patch and 
the commit message) will reduce the risk to use the hardened vectors. I 
say reduce because you may have receive data abort (imagine an unlikely 
error in the few instructions to restore state).


It is also why switching vector tables are done very early in entry path 
and very late in the exit path.






  ldr lr, [sp, #UREGS_lr]
  ldr r11, [sp, #UREGS_pc]
  msr ELR_hyp, r11
  ldr r11, [sp, #UREGS_cpsr]
  msr SPSR_hyp, r11
+#ifdef CONFIG_ARM32_HARDEN_BRANCH_PREDICTOR
+/*
+ * Hardening branch predictor may require to setup a different
+ * vector tables before returning to the guests. Those vectors
+ * may rely on the state of registers that does not hold when
+ * running in the hypervisor (e.g SP is 8 bytes aligned). So setup
+ * HVBAR very late.
+ *
+ * Default vectors table will be restored on exit (see
+ * save_guest_regs).
+ */
+mov r9, #0  /* vector tables = NULL */
+/*
+ * Load vector tables pointer from the per-cpu bp_harden_vecs
+ * when returning to the guest only.
+ */
+and r11, #PSR_MODE_MASK
+cmp 

Re: [Xen-devel] [Xen-users] xen_pt_region_update: Error: create new mem mapping failed! (err: 22)

[Anthony PERARD]

On Thu, Jan 25, 2018 at 10:28:14AM +, George Dunlap wrote:
> On Wed, Jan 24, 2018 at 9:59 PM, Håkon Alstadheim
>  wrote:
> > I'm trying, and failing, to launch a vm with bios = 'ovmf' under xen 4.10.
> >
> > The domain launches OK as long as I do not pass any pci devices through,
> > but with pci devices passed through,
> 
> Anthony,
> 
> Does OVMF support PCI pass-through yet?

I don't think OVMF cares if a PCI device is pass-through or not. Does
the VM works with bios=seabios ?

There is maybe somethings wrong with the way OVMF handles PCI devices
that doesn't work with pass-through.

Håkon, could you add the following in the VM config? With that, we could
get some logs from OVMF:
device_model_args_hvm = [
  '-chardev', 'file,id=debugcon,mux=on,path=/tmp/OVMF.logs,',
  '-device', 'isa-debugcon,iobase=0x402,chardev=debugcon',
]
(Feel free to change the path.)

Thanks,

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH 3/7] xen/arm32: entry: Add missing trap_reset entry

[Julien Grall]

Hi Stefano,

On 24/01/18 23:14, Stefano Stabellini wrote:

On Fri, 19 Jan 2018, Julien Grall wrote:

At the moment, the reset vector is defined as .word 0 (e.g andeq r0, r0,
r0).

This is rather unintuitive and will result to execute the trap
undefined. Instead introduce trap helpers for reset and will generate an
error message in the unlikely case that reset will be called.

This is part of XSA-254.

Signed-off-by: Julien Grall 
---
  xen/arch/arm/arm32/entry.S | 1 +
  xen/arch/arm/arm32/traps.c | 5 +
  2 files changed, 6 insertions(+)

diff --git a/xen/arch/arm/arm32/entry.S b/xen/arch/arm/arm32/entry.S
index c6490d2847..c2fad5fe9b 100644
--- a/xen/arch/arm/arm32/entry.S
+++ b/xen/arch/arm/arm32/entry.S
@@ -146,6 +146,7 @@ GLOBAL(hyp_traps_vector)
  b trap_irq  /* 0x18 - IRQ */
  b trap_fiq  /* 0x1c - FIQ */
  
+DEFINE_TRAP_ENTRY(reset)


This is OK, but shouldn't we also change the entry under
GLOBAL(hyp_traps_vector), from ".word 0" to "b trap_reset" ?


That was my plan but forgot to do it :/ I will update the patch and 
resend it.


Cheers,

--
Julien Grall

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

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

[Wei Liu]

On Thu, Jan 25, 2018 at 02:51:34AM +, osstest service owner wrote:
> flight 118296 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/118296/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-armhf-armhf-xl-credit2 16 guest-start/debian.repeat fail REGR. vs. 
> 118174

There seems to be a genuine bug.

http://logs.test-lab.xenproject.org/osstest/logs/118296/test-armhf-armhf-xl-credit2/serial-cubietruck-braque.log

Jan 24 09:18:48.859356 (XEN) traps.c:2033:d9v0 HSR=0x8006 pc=0xc gva=0xc 
gpa=0x0c
Jan 24 09:18:48.865981 (XEN) (XEN) traps.c:2033:d9v0 HSR=0x8006 pc=0xc 
gva=0xc gpa=0x0c
Jan 24 09:18:48.873107 (XEN) traps.c:2033:d9v0 HSR=0x8006 pc=0xc gva=0xc 
gpa=0x0c
Jan 24 09:18:48.879732 (XEN) traps.c:2033:d9v0 HSR=0x8006 pc=0xc gva=0xc 
gpa=0x0c

>  test-amd64-amd64-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail REGR. 
> vs. 118174

libxl-save-helper: debug: starting restore: Success
xc: detail: fd 8, dom 18, hvm 0, pae 0, stream_type 0
xc: info: Found x86 HVM domain from Xen 4.11
xc: info: Restoring domain
xc: error: Failed to get types for pfn batch (14 = Bad address): Internal error
xc: error: Save failed (14 = Bad address): Internal error

This looks familiar to the known issue for Windows migration test.

Wei.

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

Re: [Xen-devel] [Xen EFI] Impossible to limit the dom0 memory

[Jan Beulich]

>>> On 25.01.18 at 12:16,  wrote:
> On 25/01/18 11:40, Jan Beulich wrote:
>> This tells us (together with the page fault error code) that the
>> Dom0 kernel tried to provide memory as kernel stack which
>> can't be written. This may be a Dom0 kernel stack overflow,
> 
> Really? Why do you think this is related to the stack?

Oh, I didn't look very closely. It's just a common pattern of stack
overruns. In any event I've said "may" for a reason.

Jan


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