Re: [Xen-devel] [PATCH] Input: xen-kbdfront - allow better run-time configuration

[Oleksandr Andrushchenko]

On 04/23/2018 09:53 PM, Dmitry Torokhov wrote:

On Thu, Apr 19, 2018 at 02:44:19PM +0300, Oleksandr Andrushchenko wrote:

On 04/19/2018 02:25 PM, Juergen Gross wrote:

On 18/04/18 17:04, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko 

It is now only possible to control if multi-touch virtual device
is created or not (via the corresponding XenStore entries),
but keyboard and pointer devices are always created.

Why don't you want to go that route for keyboard and mouse, too?
Or does this really make no sense?

Well, I would prefer not to touch anything outside Linux and
this driver. And these settings seem to be implementation specific.
So, this is why introduce Linux module parameters and don't extend
the kbdif protocol.

Why do you consider this implementation specific? How other guests
decide to forego creation of relative pointer device or keyboard-like
device?

You already have "features" for absolute pointing device and multitouch,
so please extend the protocol properly so you indeed do not code
something implementation-specific (i.e. module parameters).

Ok, but in order to preserve the default behavior, e.g.
pointer and keyboard devices are always created now, I'll have
to have reverse features in the protocol:
 - feature-no-pointer
 - feature-no-keyboard
The above may be set as a part of frontend's configuration and
if missed are considered to be set to false.



Thanks.




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

Re: [Xen-devel] [RFC 0/2] To introduce xenwatch multithreading (xen mtwatch)

[Dongli Zhang]

Hi Juergen,

On 04/24/2018 01:22 PM, Juergen Gross wrote:
> On 24/04/18 01:55, Dongli Zhang wrote:
>> Hi Wei,
>>
>> On 04/23/2018 10:09 PM, Wei Liu wrote:
>>> On Sat, Apr 07, 2018 at 07:25:53PM +0800, Dongli Zhang wrote:
 About per-domU xenwatch thread create/destroy, a new type of xenstore node 
 is
 introduced: '/local/domain/0/mtwatch/'.

 Suppose the new domid id 7. During the domU (domid=7) creation, the xen
 toolstack writes '/local/domain/0/mtwatch/7' to xenstore before the 
 insertion
 of '/local/domain/7'. When the domid=7 is destroyed, the last xenstore
 operation by xen toolstack is to remove '/local/domain/0/mtwatch/7'.

 The dom0 kernel subscribes a watch at node '/local/domain/0/mtwatch'.  
 Kernel
 thread [xen-mtwatch-7] is created when '/local/domain/0/mtwatch/7' is 
 inserted,
 while this kernel thread is destroyed when the corresponding xenstore node 
 is
 removed.
>>>
>>> Instead of inventing yet another node, can you not watch /local/domain
>>> directly?
>>
>> Would you like to watch at /local/domain directly? Or is your question "is 
>> there
>> any other way to not watch at /local/domain, while no extra xenstore node 
>> will
>> be introduced"?
>>
>> Actually, the first prototype of this idea was to watch at /local/domain
>> directly to get aware of the domU create/destroy, so that xen toolstack will 
>> not
>> get involved. Joao Martins (CCed) had a concern on the performance as 
>> watching
>> at /local/domain would lead to large amount of xenwatch events.
> 
> That's what the special watches "@introduceDomain" and "@releaseDomain"
> are meant for.

I used to consider to watch at "@introduceDomain". However, there is no domain
information appended with "@introduceDomain" and it is still required for dom0
kernel to proactively confirm who is created.

Dongli Zhang

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

Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

[Oleksandr Andrushchenko]

On 04/24/2018 01:41 AM, Boris Ostrovsky wrote:

On 04/23/2018 08:10 AM, Oleksandr Andrushchenko wrote:

On 04/23/2018 02:52 PM, Wei Liu wrote:

On Fri, Apr 20, 2018 at 02:25:20PM +0300, Oleksandr Andrushchenko wrote:

  the gntdev.

I think this is generic enough that it could be implemented by a
device not tied to Xen. AFAICT the hyper_dma guys also wanted
something similar to this.

You can't just wrap random userspace memory into a dma-buf. We've
just had
this discussion with kvm/qemu folks, who proposed just that, and
after a
bit of discussion they'll now try to have a driver which just wraps a
memfd into a dma-buf.

So, we have to decide either we introduce a new driver
(say, under drivers/xen/xen-dma-buf) or extend the existing
gntdev/balloon to support dma-buf use-cases.

Can anybody from Xen community express their preference here?


Oleksandr talked to me on IRC about this, he said a few IOCTLs need to
be added to either existing drivers or a new driver.

I went through this thread twice and skimmed through the relevant
documents, but I couldn't see any obvious pros and cons for either
approach. So I don't really have an opinion on this.

But, assuming if implemented in existing drivers, those IOCTLs need to
be added to different drivers, which means userspace program needs to
write more code and get more handles, it would be slightly better to
implement a new driver from that perspective.

If gntdev/balloon extension is still considered:

All the IOCTLs will be in gntdev driver (in current xen-zcopy
terminology):
  - DRM_ICOTL_XEN_ZCOPY_DUMB_FROM_REFS
  - DRM_IOCTL_XEN_ZCOPY_DUMB_TO_REFS
  - DRM_IOCTL_XEN_ZCOPY_DUMB_WAIT_FREE

Balloon driver extension, which is needed for contiguous/DMA
buffers, will be to provide new *kernel API*, no UAPI is needed.



So I am obviously a bit late to this thread, but why do you need to add
new ioctls to gntdev and balloon? Doesn't this driver manage to do what
you want without any extensions?

1. I only (may) need to add IOCTLs to gntdev
2. balloon driver needs to be extended, so it can allocate
contiguous (DMA) memory, not IOCTLs/UAPI here, all lives
in the kernel.
3. The reason I need to extend gnttab with new IOCTLs is to
provide new functionality to create a dma-buf from grant references
and to produce grant references for a dma-buf. This is what I have as UAPI
description for xen-zcopy driver:

1. DRM_IOCTL_XEN_ZCOPY_DUMB_FROM_REFS
This will create a DRM dumb buffer from grant references provided
by the frontend. The intended usage is:
  - Frontend
    - creates a dumb/display buffer and allocates memory
    - grants foreign access to the buffer pages
    - passes granted references to the backend
  - Backend
    - issues DRM_XEN_ZCOPY_DUMB_FROM_REFS ioctl to map
  granted references and create a dumb buffer
    - requests handle to fd conversion via DRM_IOCTL_PRIME_HANDLE_TO_FD
    - requests real HW driver/consumer to import the PRIME buffer with
  DRM_IOCTL_PRIME_FD_TO_HANDLE
    - uses handle returned by the real HW driver
  - at the end:
    o closes real HW driver's handle with DRM_IOCTL_GEM_CLOSE
    o closes zero-copy driver's handle with DRM_IOCTL_GEM_CLOSE
    o closes file descriptor of the exported buffer

2. DRM_IOCTL_XEN_ZCOPY_DUMB_TO_REFS
This will grant references to a dumb/display buffer's memory provided by the
backend. The intended usage is:
  - Frontend
    - requests backend to allocate dumb/display buffer and grant references
  to its pages
  - Backend
    - requests real HW driver to create a dumb with 
DRM_IOCTL_MODE_CREATE_DUMB

    - requests handle to fd conversion via DRM_IOCTL_PRIME_HANDLE_TO_FD
    - requests zero-copy driver to import the PRIME buffer with
  DRM_IOCTL_PRIME_FD_TO_HANDLE
    - issues DRM_XEN_ZCOPY_DUMB_TO_REFS ioctl to
  grant references to the buffer's memory.
    - passes grant references to the frontend
 - at the end:
    - closes zero-copy driver's handle with DRM_IOCTL_GEM_CLOSE
    - closes real HW driver's handle with DRM_IOCTL_GEM_CLOSE
    - closes file descriptor of the imported buffer

3. DRM_XEN_ZCOPY_DUMB_WAIT_FREE
This will block until the dumb buffer with the wait handle provided be 
freed:

this is needed for synchronization between frontend and backend in case
frontend provides grant references of the buffer via
DRM_XEN_ZCOPY_DUMB_FROM_REFS IOCTL and which must be released before
backend replies with XENDISPL_OP_DBUF_DESTROY response.
wait_handle must be the same value returned while calling
DRM_XEN_ZCOPY_DUMB_FROM_REFS IOCTL.

So, as you can see the above functionality is not covered by the 
existing UAPI

of the gntdev driver.
Now, if we change dumb -> dma-buf and remove DRM code (which is only a 
wrapper

here on top of dma-buf) we get new driver for dma-buf for Xen.

This is why I have 2 options here: either create a dedicated driver for this
(e.g. re-work xen-zcopy to be DRM independent and put it under
drivers/xen/xen-dma-buf, for example) or extend the existing 

Re: [Xen-devel] [RFC 0/2] To introduce xenwatch multithreading (xen mtwatch)

[Juergen Gross]

On 24/04/18 01:55, Dongli Zhang wrote:
> Hi Wei,
> 
> On 04/23/2018 10:09 PM, Wei Liu wrote:
>> On Sat, Apr 07, 2018 at 07:25:53PM +0800, Dongli Zhang wrote:
>>> About per-domU xenwatch thread create/destroy, a new type of xenstore node 
>>> is
>>> introduced: '/local/domain/0/mtwatch/'.
>>>
>>> Suppose the new domid id 7. During the domU (domid=7) creation, the xen
>>> toolstack writes '/local/domain/0/mtwatch/7' to xenstore before the 
>>> insertion
>>> of '/local/domain/7'. When the domid=7 is destroyed, the last xenstore
>>> operation by xen toolstack is to remove '/local/domain/0/mtwatch/7'.
>>>
>>> The dom0 kernel subscribes a watch at node '/local/domain/0/mtwatch'.  
>>> Kernel
>>> thread [xen-mtwatch-7] is created when '/local/domain/0/mtwatch/7' is 
>>> inserted,
>>> while this kernel thread is destroyed when the corresponding xenstore node 
>>> is
>>> removed.
>>
>> Instead of inventing yet another node, can you not watch /local/domain
>> directly?
> 
> Would you like to watch at /local/domain directly? Or is your question "is 
> there
> any other way to not watch at /local/domain, while no extra xenstore node will
> be introduced"?
> 
> Actually, the first prototype of this idea was to watch at /local/domain
> directly to get aware of the domU create/destroy, so that xen toolstack will 
> not
> get involved. Joao Martins (CCed) had a concern on the performance as watching
> at /local/domain would lead to large amount of xenwatch events.

That's what the special watches "@introduceDomain" and "@releaseDomain"
are meant for.


Juergen

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

[Xen-devel] [xen-4.9-testing test] 122355: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
121761
 test-amd64-amd64-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
121761

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail like 121704
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 121728
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 121761
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 121761
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 121761
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 121761
 test-amd64-i386-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail like 121761
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-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-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  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-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-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-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 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-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-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-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  921bff4ea79c5b0d76274c3bb53b08ac4f3cfd55
baseline version:
 xen  ad4fefdd088e47dcc017efefc4857e1610c832af

Last test of basis   121761  2018-04-04 03:55:43 Z   20 days
Testing same since   122355  2018-04-23 11:06:18 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Juergen Gross 
  Kevin Tian 
  Wei Liu 

jobs:
 build-amd64-xsm   

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl  broken
 test-armhf-armhf-xl   4 host-install(4)broken REGR. vs. 122161
 test-xtf-amd64-amd64-4 50 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 122161

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

Tests which did not succeed, but are not blocking:
 test-xtf-amd64-amd64-5  50 xtf/test-hvm64-lbr-tsx-vmentry fail like 122161
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 122161
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 122161
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 122161
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 122161
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 122161
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 122161
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 122161
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 122161
 build-amd64-prev  7 xen-build/dist-test  fail   never pass
 build-i386-prev   7 xen-build/dist-test  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-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-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-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-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  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-libvirt 13 migrate-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-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail 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
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass

version targeted for testing:
 xen  501718a68c04086ba1984563eccf0b18f82d5c0c
baseline version:
 xen  08647952260725344f4e67d2190c2c4c8457cea2

Last test of basis   122161  2018-04-10 12:23:21 Z   13 days
Testing same since   122354  2018-04-23 11:06:06 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

Re: [Xen-devel] [RFC 0/2] To introduce xenwatch multithreading (xen mtwatch)

[Dongli Zhang]

Hi Wei,

On 04/23/2018 10:09 PM, Wei Liu wrote:
> On Sat, Apr 07, 2018 at 07:25:53PM +0800, Dongli Zhang wrote:
>> About per-domU xenwatch thread create/destroy, a new type of xenstore node is
>> introduced: '/local/domain/0/mtwatch/'.
>>
>> Suppose the new domid id 7. During the domU (domid=7) creation, the xen
>> toolstack writes '/local/domain/0/mtwatch/7' to xenstore before the insertion
>> of '/local/domain/7'. When the domid=7 is destroyed, the last xenstore
>> operation by xen toolstack is to remove '/local/domain/0/mtwatch/7'.
>>
>> The dom0 kernel subscribes a watch at node '/local/domain/0/mtwatch'.  Kernel
>> thread [xen-mtwatch-7] is created when '/local/domain/0/mtwatch/7' is 
>> inserted,
>> while this kernel thread is destroyed when the corresponding xenstore node is
>> removed.
> 
> Instead of inventing yet another node, can you not watch /local/domain
> directly?

Would you like to watch at /local/domain directly? Or is your question "is there
any other way to not watch at /local/domain, while no extra xenstore node will
be introduced"?

Actually, the first prototype of this idea was to watch at /local/domain
directly to get aware of the domU create/destroy, so that xen toolstack will not
get involved. Joao Martins (CCed) had a concern on the performance as watching
at /local/domain would lead to large amount of xenwatch events.

Dongli Zhang

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

[Xen-devel] [xen-4.7-testing test] 122353: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-xtf-amd64-amd64-3 50 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 122131
 test-armhf-armhf-xl-vhd   7 xen-boot fail REGR. vs. 122131

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

Last test of basis   122131  2018-04-09 10:53:16 Z   14 days
Testing same since   122353  2018-04-23 11:05:56 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Kevin Tian 

jobs:
 build-amd64-xsm 

Re: [Xen-devel] [PATCH for-4.11] x86/spec_ctrl: Updates to retpoline-safety decision making

[Andrew Cooper]

On 23/04/2018 22:16, Konrad Rzeszutek Wilk wrote:
>> diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
>> index 5b5ec90..aff06f0 100644
>> --- a/xen/arch/x86/spec_ctrl.c
>> +++ b/xen/arch/x86/spec_ctrl.c
>> @@ -113,12 +113,13 @@ static void __init print_details(enum ind_thunk thunk)
>>  printk(XENLOG_DEBUG "Speculative mitigation facilities:\n");
>>  
>>  /* Hardware features which pertain to speculative mitigations. */
>> -printk(XENLOG_DEBUG "  Hardware features:%s%s%s%s%s\n",
>> +printk(XENLOG_DEBUG "  Hardware features:%s%s%s%s%s%s\n",
>> (_7d0 & cpufeat_mask(X86_FEATURE_IBRSB)) ? " IBRS/IBPB" : "",
>> (_7d0 & cpufeat_mask(X86_FEATURE_STIBP)) ? " STIBP" : "",
>> (e8b  & cpufeat_mask(X86_FEATURE_IBPB))  ? " IBPB"  : "",
>> (caps & ARCH_CAPABILITIES_IBRS_ALL)  ? " IBRS_ALL"  : "",
>> -   (caps & ARCH_CAPABILITIES_RDCL_NO)   ? " RDCL_NO"   : "");
>> +   (caps & ARCH_CAPABILITIES_RDCL_NO)   ? " RDCL_NO"   : "",
>> +   (caps & ARCH_CAPS_RSBA)  ? " RBSA"  : "");
> You have RSBA on the left and RBSA on the right. Which one is it?

Bah - these are impossible acronyms to type.  It is RSB-Alternative, so
the LHS is correct and I'll submit a correction for the RHS.

~Andrew

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

Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

[Boris Ostrovsky]

On 04/23/2018 08:10 AM, Oleksandr Andrushchenko wrote:
> On 04/23/2018 02:52 PM, Wei Liu wrote:
>> On Fri, Apr 20, 2018 at 02:25:20PM +0300, Oleksandr Andrushchenko wrote:
>  the gntdev.
>
> I think this is generic enough that it could be implemented by a
> device not tied to Xen. AFAICT the hyper_dma guys also wanted
> something similar to this.
 You can't just wrap random userspace memory into a dma-buf. We've
 just had
 this discussion with kvm/qemu folks, who proposed just that, and
 after a
 bit of discussion they'll now try to have a driver which just wraps a
 memfd into a dma-buf.
>>> So, we have to decide either we introduce a new driver
>>> (say, under drivers/xen/xen-dma-buf) or extend the existing
>>> gntdev/balloon to support dma-buf use-cases.
>>>
>>> Can anybody from Xen community express their preference here?
>>>
>> Oleksandr talked to me on IRC about this, he said a few IOCTLs need to
>> be added to either existing drivers or a new driver.
>>
>> I went through this thread twice and skimmed through the relevant
>> documents, but I couldn't see any obvious pros and cons for either
>> approach. So I don't really have an opinion on this.
>>
>> But, assuming if implemented in existing drivers, those IOCTLs need to
>> be added to different drivers, which means userspace program needs to
>> write more code and get more handles, it would be slightly better to
>> implement a new driver from that perspective.
> If gntdev/balloon extension is still considered:
>
> All the IOCTLs will be in gntdev driver (in current xen-zcopy
> terminology):
>  - DRM_ICOTL_XEN_ZCOPY_DUMB_FROM_REFS
>  - DRM_IOCTL_XEN_ZCOPY_DUMB_TO_REFS
>  - DRM_IOCTL_XEN_ZCOPY_DUMB_WAIT_FREE
>
> Balloon driver extension, which is needed for contiguous/DMA
> buffers, will be to provide new *kernel API*, no UAPI is needed.
>


So I am obviously a bit late to this thread, but why do you need to add
new ioctls to gntdev and balloon? Doesn't this driver manage to do what
you want without any extensions?

-boris

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

Re: [Xen-devel] [PATCH for-4.11] x86/spec_ctrl: Updates to retpoline-safety decision making

[Konrad Rzeszutek Wilk]

> diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
> index 5b5ec90..aff06f0 100644
> --- a/xen/arch/x86/spec_ctrl.c
> +++ b/xen/arch/x86/spec_ctrl.c
> @@ -113,12 +113,13 @@ static void __init print_details(enum ind_thunk thunk)
>  printk(XENLOG_DEBUG "Speculative mitigation facilities:\n");
>  
>  /* Hardware features which pertain to speculative mitigations. */
> -printk(XENLOG_DEBUG "  Hardware features:%s%s%s%s%s\n",
> +printk(XENLOG_DEBUG "  Hardware features:%s%s%s%s%s%s\n",
> (_7d0 & cpufeat_mask(X86_FEATURE_IBRSB)) ? " IBRS/IBPB" : "",
> (_7d0 & cpufeat_mask(X86_FEATURE_STIBP)) ? " STIBP" : "",
> (e8b  & cpufeat_mask(X86_FEATURE_IBPB))  ? " IBPB"  : "",
> (caps & ARCH_CAPABILITIES_IBRS_ALL)  ? " IBRS_ALL"  : "",
> -   (caps & ARCH_CAPABILITIES_RDCL_NO)   ? " RDCL_NO"   : "");
> +   (caps & ARCH_CAPABILITIES_RDCL_NO)   ? " RDCL_NO"   : "",
> +   (caps & ARCH_CAPS_RSBA)  ? " RBSA"  : "");

You have RSBA on the left and RBSA on the right. Which one is it?

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

[Xen-devel] [linux-4.14 baseline test] 122368: tolerable FAIL

[osstest service owner]

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

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu  6 xen-install  fail  never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  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-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-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-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-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-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 16 guest-localmigrate/x10 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-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-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-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-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-ws16-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-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass

version targeted for testing:
 linux64138f0adb25ca8f34baa57af33260b05efe2874
baseline version:
 linux64138f0adb25ca8f34baa57af33260b05efe2874

Last test of basis   122368  2018-04-23 14:20:43 Z0 days
Testing same since  (not found) 0 attempts

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

Re: [Xen-devel] [PATCH 2/8] x86/HVM/SVM: Add AVIC initialization code

[Natarajan, Janakarajan]

On 4/23/2018 2:33 PM, Konrad Rzeszutek Wilk wrote:

+++ b/xen/arch/x86/hvm/svm/avic.c
@@ -0,0 +1,191 @@
+/*
+ * avic.c: implements AMD Advanced Virtual Interrupt Controller (AVIC) support
+ * Copyright (c) 2016, Advanced Micro Devices, Inc.

Not 2018?


Ah good catch. Yeah it should be 2018.




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

Re: [Xen-devel] [PATCH 2/8] x86/HVM/SVM: Add AVIC initialization code

[Konrad Rzeszutek Wilk]

> +++ b/xen/arch/x86/hvm/svm/avic.c
> @@ -0,0 +1,191 @@
> +/*
> + * avic.c: implements AMD Advanced Virtual Interrupt Controller (AVIC) 
> support
> + * Copyright (c) 2016, Advanced Micro Devices, Inc.

Not 2018?

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

Re: [Xen-devel] [PATCH v2] Input: xen-kbdfront - allow better run-time configuration

[Dmitry Torokhov]

On Mon, Apr 23, 2018 at 11:29:45AM +0300, Oleksandr Andrushchenko wrote:
> On 04/23/2018 11:23 AM, Juergen Gross wrote:
> > On 23/04/18 10:02, Oleksandr Andrushchenko wrote:
> > > Juergen, Jason, Dmitry
> > > any comment on this?
> > Oleksandr, please give us some time. I can't speak for others, but I am
> > not sitting here idling and hoping that some work (e.g. patches to
> > review) might appear.
> > 
> > I have a lot of other stuff to do and will respond when I find some time
> > to look at your patches.
> > 
> > Pinging others on Monday when having sent out the patch only on Thursday
> > is rather unfriendly.
> Really sorry about this, my bad.
> I had an impression that the only change we need to
> discuss was uint -> bool change which seemed rather trivial

I am sorry I did not respond to the previous version until today, but I
do not think that we should be extending module parameters for this.
Protocol features are already there for absolute pointers and
multi-touch, keyboard and relative pointers should use the same
mechanism.

Thanks.

-- 
Dmitry

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

Re: [Xen-devel] [PATCH] Input: xen-kbdfront - allow better run-time configuration

[Dmitry Torokhov]

On Thu, Apr 19, 2018 at 02:44:19PM +0300, Oleksandr Andrushchenko wrote:
> On 04/19/2018 02:25 PM, Juergen Gross wrote:
> > On 18/04/18 17:04, Oleksandr Andrushchenko wrote:
> > > From: Oleksandr Andrushchenko 
> > > 
> > > It is now only possible to control if multi-touch virtual device
> > > is created or not (via the corresponding XenStore entries),
> > > but keyboard and pointer devices are always created.
> > Why don't you want to go that route for keyboard and mouse, too?
> > Or does this really make no sense?
> Well, I would prefer not to touch anything outside Linux and
> this driver. And these settings seem to be implementation specific.
> So, this is why introduce Linux module parameters and don't extend
> the kbdif protocol.

Why do you consider this implementation specific? How other guests
decide to forego creation of relative pointer device or keyboard-like
device?

You already have "features" for absolute pointing device and multitouch,
so please extend the protocol properly so you indeed do not code
something implementation-specific (i.e. module parameters).

Thanks.

-- 
Dmitry

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

baseline version:
 flight   121088

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



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

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

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

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


Push not applicable.


___
Xen-devel mailing list

Re: [Xen-devel] [PATCH v2] Input: xen-kbdfront - allow better run-time configuration

[Jason Andryuk]

Hi, Oleksandr.

On Thu, Apr 19, 2018 at 9:39 AM, Oleksandr Andrushchenko
 wrote:



> @@ -241,60 +242,84 @@ static int xenkbd_probe(struct xenbus_device *dev,
> }
>
> /* keyboard */
> -   kbd = input_allocate_device();
> -   if (!kbd)
> -   goto error_nomem;
> -   kbd->name = "Xen Virtual Keyboard";
> -   kbd->phys = info->phys;
> -   kbd->id.bustype = BUS_PCI;
> -   kbd->id.vendor = 0x5853;
> -   kbd->id.product = 0x;
> -
> -   __set_bit(EV_KEY, kbd->evbit);
> -   for (i = KEY_ESC; i < KEY_UNKNOWN; i++)
> -   __set_bit(i, kbd->keybit);
> -   for (i = KEY_OK; i < KEY_MAX; i++)
> -   __set_bit(i, kbd->keybit);
> -
> -   ret = input_register_device(kbd);
> -   if (ret) {
> -   input_free_device(kbd);
> -   xenbus_dev_fatal(dev, ret, "input_register_device(kbd)");
> -   goto error;
> +   if (!no_kbd_dev) {

My earlier suggestion on the option name was aimed at replacing the above with:
   if (kbd_dev) {

I find it easier to read then the double negative !no_kbd_dev.  But
it's only used once, so it's not a big deal either way.



>
> -   __set_bit(EV_KEY, ptr->evbit);
> -   for (i = BTN_LEFT; i <= BTN_TASK; i++)
> -   __set_bit(i, ptr->keybit);
> +   ptr = input_allocate_device();
> +   if (!ptr)
> +   goto error_nomem;
> +   ptr->name = "Xen Virtual Pointer";
> +   ptr->phys = info->phys;
> +   ptr->id.bustype = BUS_PCI;
> +   ptr->id.vendor = 0x5853;
> +   ptr->id.product = 0xfffe;
> +
> +   if (abs) {
> +   __set_bit(EV_ABS, ptr->evbit);
> +   input_set_abs_params(ptr, ABS_X, 0, 
> ptr_size[KPARAM_X], 0, 0);
> +   input_set_abs_params(ptr, ABS_Y, 0, 
> ptr_size[KPARAM_Y], 0, 0);

Just noticed these lines now exceed 80 columns.

Otherwise it's just code motion and fine by me.

Regards,
Jason

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

Re: [Xen-devel] [PATCH 3/6] arm: make it possible to disable the SMMU driver

[Andrii Anisov]

Hello Stefano,


On 20.04.18 01:43, Stefano Stabellini wrote:

Let's take this example: SMMUv2. The driver is decently quality, and
definitely some boards will require it. It makes sense to security
support it. However, some boards don't come with an SMMU at all, such as
Pine64

I guess arm passthrough in a whole could be dropped for such platforms.

--

*Andrii Anisov*



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

Re: [Xen-devel] [PATCH 0/6] arm: more kconfig configurability and small default configs

[Andrii Anisov]

Hello Stefano,

I'm really glad to see this series.

In the list of platform-specific bits you are trying to make selectable, 
you missed platform support code itself. Moreover, as it is said in your 
follow-up emails, set of UART, IOMMU, GIC is defined by SoC family. So 
wouldn't it be more natural to introduce platform configs which would 
couple specific drivers support? With a special platform i.e. "other" 
which enables all drivers and platform code.



--

*Andrii Anisov*



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

Re: [Xen-devel] [PATCH v2 03/10] xen/arm: Implement CPU_OFF PSCI call (physical interface)

[Julien Grall]

On 23/04/18 18:12, Mirela Simonovic wrote:

On Mon, Apr 23, 2018 at 1:21 PM, Julien Grall  wrote:

On 20/04/18 13:25, Mirela Simonovic wrote:

+if ( errno )
+panic("PSCI cpu off failed for CPU%d err=%d\n",
get_processor_id(),
+  errno);
+}
+
   void call_psci_system_off(void)
   {
   if ( psci_ver > PSCI_VERSION(0, 1) )
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index b2116f0d2d..1ca3d63261 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -395,6 +395,9 @@ void stop_cpu(void)
   /* Make sure the write happens before we sleep forever */
   dsb(sy);
   isb();
+if ( system_state == SYS_STATE_suspend )



I don't think this should be call only on suspend/resume. System shutdown
could also benefit of PSCI CPU off. This is also paving the way to more use
case of turning off a CPU.


Ok, but then we do need to check for PSCI version here.


Or inside call_psci_off to match the other psci_* functions. However, 
you still need to check the PSCI version in the suspend code to deny any 
suspend/resume functionally on platform without PSCI CPU off support.


Cheers,
--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 03/10] xen/arm: Implement CPU_OFF PSCI call (physical interface)

[Mirela Simonovic]

Hi Julien,

On Mon, Apr 23, 2018 at 1:21 PM, Julien Grall  wrote:
> Hi Mirela,
>
> On 20/04/18 13:25, Mirela Simonovic wrote:
>>
>> During the system suspend to RAM non-boot CPUs will be hotplugged.
>> This will be triggered via disable_nonboot_cpus() call. When
>> hotplugged the CPU will end up in an infinite wfi loop in stop_cpu().
>> This patch adds PSCI CPU_OFF call to the EL3 with the aim to get powered
>> down the calling CPU during the suspend.
>> If PSCI CPU_OFF call to the EL3 succeeds it will not return. Otherwise,
>> when the PSCI CPU_OFF call returns we'll raise panic, because the calling
>> CPU could be enabled afterwards.
>> If a CPU executes stop_cpu() when the system is not suspending the
>> calling CPU will loop in the infinite while/wfi, as it was looping
>> before this change.
>> Note that there is no check for PSCI version in PSCI CPU_OFF
>> implementation because the version will be checked prior to triggering
>> the system suspend.
>
>
> Then the code should contain an ASSERT + comment to make it clear on the
> interface. But I don't think this is the right way to go (see below).
>
>
>>
>> Signed-off-by: Mirela Simonovic 
>>
>> ---
>> CC: Stefano Stabellini 
>> CC: Julien Grall 
>> ---
>> Changes in v2:
>> -Issue PSCI CPU_OFF only if the system is suspending
>> -If PSCI CPU_OFF call fails (unlikely to ever happen) raise panic
>> -Fixed commit message
>> ---
>>   xen/arch/arm/psci.c| 11 +++
>>   xen/arch/arm/smpboot.c |  3 +++
>>   xen/include/asm-arm/psci.h |  1 +
>>   3 files changed, 15 insertions(+)
>>
>> diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c
>> index 94b616df9b..7f7b0695a3 100644
>> --- a/xen/arch/arm/psci.c
>> +++ b/xen/arch/arm/psci.c
>> @@ -46,6 +46,17 @@ int call_psci_cpu_on(int cpu)
>>   return call_smc(psci_cpu_on_nr, cpu_logical_map(cpu),
>> __pa(init_secondary), 0);
>>   }
>>   +void call_psci_cpu_off(void)
>> +{
>> +int errno;
>> +
>> +/* If successfull the PSCI cpu_off call doesn't return */
>> +errno = call_smc(PSCI_0_2_FN32_CPU_OFF, 0, 0, 0);
>
>
> CPU_OFF will only return on error. So the if is not necessary below.
>

Correct

>> +if ( errno )
>> +panic("PSCI cpu off failed for CPU%d err=%d\n",
>> get_processor_id(),
>> +  errno);
>> +}
>> +
>>   void call_psci_system_off(void)
>>   {
>>   if ( psci_ver > PSCI_VERSION(0, 1) )
>> diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
>> index b2116f0d2d..1ca3d63261 100644
>> --- a/xen/arch/arm/smpboot.c
>> +++ b/xen/arch/arm/smpboot.c
>> @@ -395,6 +395,9 @@ void stop_cpu(void)
>>   /* Make sure the write happens before we sleep forever */
>>   dsb(sy);
>>   isb();
>> +if ( system_state == SYS_STATE_suspend )
>
>
> I don't think this should be call only on suspend/resume. System shutdown
> could also benefit of PSCI CPU off. This is also paving the way to more use
> case of turning off a CPU.

Ok, but then we do need to check for PSCI version here.

Thanks,
Mirela

>
> Cheers,
>
> --
> Julien Grall

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

Re: [Xen-devel] [Qemu-devel] [PATCH 16/16] configure: do_compiler: Dump some extra info under bash

[Ian Jackson]

Daniel P. Berrangé writes ("Re: [Qemu-devel] [PATCH 16/16] configure: 
do_compiler: Dump some extra info under bash"):
> Personally I'd suggest we add informative messages throughout the
> configure script for each check being run. If people really hate the
> idea of a verbose output from configure, we could leave it silent by
> default and add a '--verbose' option to turn it on.

Doing that would be a lot of work.  I am not opposed to it, but I am
not going to do it.

My suggestion is a very small change which instantly makes configure
much easier to debug, at least if you have bash available (and the bug
you are fixing doesn't go away with bash).

Please don't let the best be the enemy of an improvement.  If
configure is ever improved (without being simply replaced), the
logging code can easily be removed.

Thanks,
Ian.

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

Re: [Xen-devel] [RFC v2 8/9] HACK libxl_exec: Check QEMU status via QMP instead of xenstore

[Ian Jackson]

Anthony PERARD writes ("Re: [RFC v2 8/9] HACK libxl_exec: Check QEMU status via 
QMP instead of xenstore"):
> But, with the to be release QEMU 2.12, there is a new interface that
> allow to pre-open a socket:
>   -chardev socket,fd=?
> See 
> https://git.qemu.org/?p=qemu.git;a=commit;h=0935700f8544033ebbd41e1f13cd528f8a58d24d
> 
> With that, we could open our usual "/var/run/xen/qmp-libxl-$domid"
> socket for QEMU. That would work when the retricted fonctionnality is
> also available. But that cann't be use unconditionnaly.

Right.

It's a bit ugly having two methods but that's the price of
compatibility.

Ian.

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

Re: [Xen-devel] [RFC v2 8/9] HACK libxl_exec: Check QEMU status via QMP instead of xenstore

[Anthony PERARD]

On Fri, Apr 20, 2018 at 07:37:17PM +0100, Ian Jackson wrote:
> Anthony PERARD writes ("[RFC v2 8/9] HACK libxl_exec: Check QEMU status via 
> QMP instead of xenstore"):
> > When QEMU is restricted, the qemu on the receiving side cann't write
> > anything to xenstore once the migration is started. So it cann't tell
> > libxl that it is ready to continue running the guest.
> ...
> > This patch creates a pipe, give the write-end to qemu, and wait for
> > something to be written to it. (We could check if it is actually the QMP
> > greeting message.)
> 
> This is indeed the kind of thing I had in mind in our IRL
> conversation.

Good, where are heading in the right direction.

> > QEMU is asked to setup a QMP server on this pipe, but even if it is a
> > one-way only, qemu will write the QMP greeting message to the pipe.
> > This is done with:
> > -add-fd, to create a fdset which is use later.
> > -chardev 'file,path=/dev/fdset/1,append=true', this open a char device
> > on the write-end of the pipe, tell qemu that the FD is write-only, and
> > not to run truncate on it.
> > -mon, just start the QMP server on this new chardev.
> 
> Have you considered socketpair() ?  That avoids the oddnes of passing
> qemu a write-only fd.

I did considered to pass an open socket to QEMU, I didn't know that
socketpair() existed. But I don't think that would help with the current
version of QEMU (2.11 and older). There are only two ways to give a
file descriptor to qemu, these are:
  -chardev pipe,..
  -chardev file,...
And in both case, QEMU is only going to write to the fd anyway.

But, with the to be release QEMU 2.12, there is a new interface that
allow to pre-open a socket:
  -chardev socket,fd=?
See 
https://git.qemu.org/?p=qemu.git;a=commit;h=0935700f8544033ebbd41e1f13cd528f8a58d24d

With that, we could open our usual "/var/run/xen/qmp-libxl-$domid"
socket for QEMU. That would work when the retricted fonctionnality is
also available. But that cann't be use unconditionnaly.

-- 
Anthony PERARD

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

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

[osstest service owner]

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

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  d80af845de7a4db01a4a3b4d779e0e0dcb5e738b
baseline version:
 xen  fa9cb90071dbc9a20b01cc6a88d96ba140545af9

Last test of basis   122366  2018-04-23 13:00:39 Z0 days
Testing same since   122371  2018-04-23 15:02:22 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Juergen Gross 
  Roger Pau Monne 
  Roger Pau Monné 
  Wei Liu 

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
   fa9cb90071..d80af845de  d80af845de7a4db01a4a3b4d779e0e0dcb5e738b -> smoke

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

Re: [Xen-devel] [PATCH 16/16] configure: do_compiler: Dump some extra info under bash

[Ian Jackson]

Anthony PERARD writes ("Re: [PATCH 16/16] configure: do_compiler: Dump some 
extra info under bash"):
> On Thu, Apr 19, 2018 at 05:45:19PM +0100, Ian Jackson wrote:
> > +funcs: ${FUNCNAME}
> > +lines: ${BASH_LINENO}
> > +files: ${BASH_SOURCE}"
> >  echo $compiler "$@" >> config.log
> >  $compiler "$@" >> config.log 2>&1 || return $?
> >  # Test passed. If this is an --enable-werror build, rerun
> 
> How is this usefull? All I have in my config.log is a lot of:
>   funcs: do_compiler
>   lines: 91
>   files: ./configure
> 
> And one:
>   funcs: do_compiler
>   lines: 95
>   files: ./configure
> 
> It still don't tell me which test had runned.

You are right.  Perhaps my testing was inadequate.  I wrote this a
long while ago, and if there was a syntax along these lines that DTRT
in both bash and dash in my tests it is long gone.  Starting de novo,
the following code works for me:

(echo >>config.log "
 funcs: ${FUNCNAME[*]}
 lines: ${BASH_LINENO[*]}
 files: ${BASH_SOURCE[*]}") 2>/dev/null ||:

With bash I get the expected information in config.log, which looks
like this:

 funcs: do_compiler do_cc compile_prog cc_has_warning_flag main
 lines: 91 124 1720 1724 0
 files: ./configure ./configure ./configure ./configure ./configure

With dash the script runs but there is nothing from this segment in
the log.  Without the 2>/dev/null, it prints
  ./configure: 63: ./configure: Bad substitution
so the syntax error is indeed being suprresed and ignored.

The ( ) is necessary because syntax errors are not like set -e errors:
they cause the shell process to exit.

I will update the patch and put some of this info in the commit
message.

Ian.

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

Re: [Xen-devel] [Qemu-devel] [PATCH 16/16] configure: do_compiler: Dump some extra info under bash

[Daniel P . Berrangé]

On Mon, Apr 23, 2018 at 05:21:42PM +0100, Anthony PERARD wrote:
> On Thu, Apr 19, 2018 at 05:45:19PM +0100, Ian Jackson wrote:
> > This makes it much easier to find a particular thing in config.log.
> > 
> > The information may be lacking in other shells, resulting in harmless
> > empty output.  (This is why we don't use the proper ${FUNCNAME[*]}
> > array syntax - other shells will choke on that.)
> > 
> > The extra output is only printed if configure is run with bash.  On
> > systems where /bin/sh is not bash, it is necessary to say bash
> > ./configure to get the extra debug info in the log.
> > 
> > Signed-off-by: Ian Jackson 
> > ---
> >  configure | 4 
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/configure b/configure
> > index d5435ff..a4c5292 100755
> > --- a/configure
> > +++ b/configure
> > @@ -60,6 +60,10 @@ do_compiler() {
> >  # is compiler binary to execute.
> >  local compiler="$1"
> >  shift
> > +echo >>config.log "
> > +funcs: ${FUNCNAME}
> > +lines: ${BASH_LINENO}
> > +files: ${BASH_SOURCE}"
> >  echo $compiler "$@" >> config.log
> >  $compiler "$@" >> config.log 2>&1 || return $?
> >  # Test passed. If this is an --enable-werror build, rerun
> 
> How is this usefull? All I have in my config.log is a lot of:
>   funcs: do_compiler
>   lines: 91
>   files: ./configure
> 
> And one:
>   funcs: do_compiler
>   lines: 95
>   files: ./configure
> 
> It still don't tell me which test had runned.

In autoconf, you would generally have a line output to stdout for every
test being run, as it is done so you can see immediately which test it
stopped on. QEMU's configure by comparison is completely silent, except
for the fnal summary at the end which is fine if everything works perfectly,
but not great when it doesn't.

Personally I'd suggest we add informative messages throughout the
configure script for each check being run. If people really hate the
idea of a verbose output from configure, we could leave it silent by
default and add a '--verbose' option to turn it on.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

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

Re: [Xen-devel] [PATCH 16/16] configure: do_compiler: Dump some extra info under bash

[Anthony PERARD]

On Thu, Apr 19, 2018 at 05:45:19PM +0100, Ian Jackson wrote:
> This makes it much easier to find a particular thing in config.log.
> 
> The information may be lacking in other shells, resulting in harmless
> empty output.  (This is why we don't use the proper ${FUNCNAME[*]}
> array syntax - other shells will choke on that.)
> 
> The extra output is only printed if configure is run with bash.  On
> systems where /bin/sh is not bash, it is necessary to say bash
> ./configure to get the extra debug info in the log.
> 
> Signed-off-by: Ian Jackson 
> ---
>  configure | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/configure b/configure
> index d5435ff..a4c5292 100755
> --- a/configure
> +++ b/configure
> @@ -60,6 +60,10 @@ do_compiler() {
>  # is compiler binary to execute.
>  local compiler="$1"
>  shift
> +echo >>config.log "
> +funcs: ${FUNCNAME}
> +lines: ${BASH_LINENO}
> +files: ${BASH_SOURCE}"
>  echo $compiler "$@" >> config.log
>  $compiler "$@" >> config.log 2>&1 || return $?
>  # Test passed. If this is an --enable-werror build, rerun

How is this usefull? All I have in my config.log is a lot of:
  funcs: do_compiler
  lines: 91
  files: ./configure

And one:
  funcs: do_compiler
  lines: 95
  files: ./configure

It still don't tell me which test had runned.

Regards,

-- 
Anthony PERARD

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

Re: [Xen-devel] Xen and safety certification, Minutes of the meeting on Apr 4th (Notes on MISRA, ISO 26262 static code analysis requirements)

[Lars Kurth]

Hi all,

On 06/04/2018, 15:13, "Lars Kurth"  wrote:
 
> 1) Requirements to the code, a subset of MISRA for ASIL B
> Next step: get more information about requirements and publish it to
> xen-devel.

I see a few problems here:

* The MISRA 2012 spec has to be bought and it is rather big (100's of 
pages): 
so, I don't think it is practical to work from the spec

* Some coding style patterns will likely be perceived as odd and 
unreasonable 
by community members: as some common code would be affected we cannot 
treat this in isolation say on ARM only. Although it is recognized that 
some of 
the coding style patterns may not make sense, compliance to MISRA is 
necessary and cannot normally be discussed away.

* PRQA has set up an environment and initial MISRA compliance report for a 
Xen on ARM build 
** The question is what (if anything) can be shared publicly
** The other open question is whether we can come to some sort of longer 
term agreement between the Xen Project and PRQA to use their tools
** As an aside, what PRQA have done would need to reflect what we do in 
step 2 is. We also want to minimize the work for PRQA: in other words, it has 
to be very simple to enable the minimal config coming out of task 2 such that 
PRQA can 
** As far as I recall 90% of all MISRA violations come down to around 70 
issues. A large number are in tools
** Also, I believe that MISRA compliance tools will likely lead to a large 
amount of false positives, due to the distributed nature of Xen: process 
boundaries, kernel/user space boundaries, etc. would all lead to false 
positives, which somehow have to be managed.

ACTION => Lars to follow up with Paul Luperto from PRQA

Hi all. I had a good meeting with Richard and Paul from PRQA today and it looks 
like we came up with a workable plan. There are a few things that will need 
checking, but this should be done in about 2 weeks. 

In essence there is a possibility for PRQA to make an instance of their 
QA·Verify Management Dashboard (see 
http://www.prqa.com/static-analysis-software/qa-verify/) to a small number (to 
be agreed) of community members initially on a suitable baseline for Xen on ARM 
(I would say Xen 4.11 or an RC would be a good starting point). I believe 
access should be restricted to committers, maybe people which committers 
delegate work to. After all, we want to enable an upsell route for PRQA, in 
return for providing a free service to the community. 

In any case, this would allow us to use the tool to follow the process I laid 
out above and get started.

Regards
Lars


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

Re: [Xen-devel] [RFC PATCH 2/8] x86/vlapic: use apic_id array to set initial (x2)APIC ID

[Jan Beulich]

>>> On 08.01.18 at 05:01,  wrote:
> --- a/xen/include/asm-x86/hvm/domain.h
> +++ b/xen/include/asm-x86/hvm/domain.h
> @@ -213,6 +213,9 @@ struct hvm_domain {
>  uint8_t thread_per_core;
>  };
>  
> +#define hvm_vcpu_x2apic_id(v) 
> (v->domain->arch.hvm_domain.apic_id[v->vcpu_id])

I can't seem to find where you set up this array.

> +#define hvm_vcpu_apic_id(v) (hvm_vcpu_x2apic_id(v) % 255)

I don't think the % 255 is appropriate here - the macro simply shouldn't be
invoked in such a case.

On the whole I'm not convinced using a array is appropriate - calculating
the APIC ID should be very involved, and require much less than possibly
multiple kb of storage.

Jan



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

Re: [Xen-devel] [RFC PATCH 1/8] x86/domctl: introduce a pair of hypercall to set and get cpu topology

[Jan Beulich]

>>> On 08.01.18 at 05:01,  wrote:
> Define interface, structures and hypercalls for toolstack to build
> cpu topology and for guest that will retrieve it [1].
> Two subop hypercalls introduced by this patch:
> XEN_DOMCTL_set_cpu_topology to define cpu topology information per domain
> and XENMEM_get_cpu_topology to retrieve cpu topology information.
> 
> [1]: during guest creation, those information helps hvmloader to build ACPI.
> 
> Signed-off-by: Chao Gao 

This will want revisiting once Andrew's domain creation rework series has
landed. In no case do I view XENMEM_get_cpu_topology as something
sensible - XENMEM, as its name says, is about memory.

Jan



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

Re: [Xen-devel] [PATCH 05/16] xen: defer call to xen_restrict until just before os_setup_post

[Anthony PERARD]

On Thu, Apr 19, 2018 at 05:45:08PM +0100, Ian Jackson wrote:
> diff --git a/stubs/xen-hvm.c b/stubs/xen-hvm.c
> index 0067bcc..7787ea2 100644
> --- a/stubs/xen-hvm.c
> +++ b/stubs/xen-hvm.c
> @@ -13,6 +13,7 @@
>  #include "hw/xen/xen.h"
>  #include "exec/memory.h"
>  #include "qapi/qapi-commands-misc.h"
> +#include "sysemu/sysemu.h"

I think this include is not needed anymore, and can go away from the
patch series.

>  
>  int xen_pci_slot_get_pirq(PCIDevice *pci_dev, int irq_num)
>  {

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH RFC for-next] x86/mm: introduce and use virt_to_xen_l4e

[Jan Beulich]

>>> On 31.10.17 at 19:51,  wrote:
> Avoid open-coding in a lot of places.
> 
> No functional change.
> 
> Signed-off-by: Wei Liu 
> ---
> Is this patch useful or is open-coding preferred?

I think we want to revisit this when 5-level paging code arrives.

Jan



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

Re: [Xen-devel] [PATCH RFC 09/10] passthrough/intel: put some code under CONFIG_HVM

[Jan Beulich]

>>> On 21.02.18 at 22:47,  wrote:
> @@ -1873,6 +1876,7 @@ int iommu_pte_flush(struct domain *d, u64 gfn, u64 *pte,
>  return rc;
>  }
>  
> +#ifdef CONFIG_HVM
>  static int __init vtd_ept_page_compatible(struct iommu *iommu)
>  {
>  u64 ept_cap, vtd_cap = iommu->cap;
> @@ -1885,6 +1889,7 @@ static int __init vtd_ept_page_compatible(struct iommu 
> *iommu)
>  return (ept_has_2mb(ept_cap) && opt_hap_2mb) == cap_sps_2mb(vtd_cap) &&
> (ept_has_1gb(ept_cap) && opt_hap_1gb) == cap_sps_1gb(vtd_cap);
>  }
> +#endif

I think the #ifdef here would better move into the function, such that ...

> @@ -2280,7 +2285,9 @@ int __init intel_vtd_setup(void)
>  if ( !cap_intr_post(iommu->cap) || !cpu_has_cx16 )
>  iommu_intpost = 0;
>  
> +#ifdef CONFIG_HVM
>  if ( !vtd_ept_page_compatible(iommu) )
> +#endif
>  iommu_hap_pt_share = 0;

... this one becomes unnecessary. Furthermore iommu_hap_pt_share is a
variable that's meaningful for HVM only, so another alternative would be to
widen the #ifdef here.

Jan



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

Re: [Xen-devel] [RFC v2 6/9] libxl: Have QEMU save its state to a file descriptor

[Anthony PERARD]

On Mon, Apr 23, 2018 at 10:20:42AM +0100, Wei Liu wrote:
> On Mon, Apr 16, 2018 at 06:32:24PM +0100, Anthony PERARD wrote:
> > In case QEMU have restricted access to the system, open the file for it,
> > and QEMU will save its state to this file descritor.
> > 
> > Signed-off-by: Anthony PERARD 
> 
> I think this is going to break FreeBSD?

If the previous patch works on FreeBSD (Learned to send FD through QMP
to QEMU), this patch shouldn't break anything. Looking at how
libxl__sendmsg_fds() is implemented, and how the receive side is
implemented in QEMU, there doesn't seems to be any difference on
FreeBSD, so I guess it's going to work fine.

> And what is /dev/fdset exactly? I don't seem to have it on my Debian
> workstation (with Linux 4.15). So this change can potentially be broken
> on Linux as well?

/dev/fdset is a QEMU internal API. You can add a file descriptor to a
fd-set via QMP or via the command line. And later, you can give a path
to something in QEMU (maybe a block driver) which refer to a fd-set
created earlier. The path would be "/dev/fdset/$fdset_number". There can
be several fd in a fd-set, qemu will just look for the first one which
have the right permission, like read or write permission.

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH RFC 07/10] passthrough/amd: split out hvm code from iommu_map.c

[Jan Beulich]

>>> On 21.02.18 at 22:46,  wrote:
> Move and rename update_paging_mode. Create a local header file for
> this and other functions that need exporting.

Functions you move into global name space need suitable prefixes - neither
hvm_update_paging_mode() nor set_iommu_pde_present() clarify that this
is AMD IOMMU specific code.

Also please don't have bool_t or things like u32 in new code you add (here:
the set_iommu_pde_present() prototype).

Jan



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

Re: [Xen-devel] [PATCH RFC 05/10] x86/passthrough: move hvm_dpci_isairq_eoi

[Jan Beulich]

>>> On 21.02.18 at 22:46,  wrote:
> This function is not Intel specific. Move it to io.c along side its
> sole user. Remove declaration in iommu.h.
> 
> Signed-off-by: Wei Liu 

Acked-by: Jan Beulich 
(with whatever path name adjustments are necessary depending on the
disposition of patches earlier in the series)



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

Re: [Xen-devel] [PATCH 12/16] xen: Remove now-obsolete xen_xc_domain_add_to_physmap

[Anthony PERARD]

On Thu, Apr 19, 2018 at 05:45:15PM +0100, Ian Jackson wrote:
> The last user was just removed; remove this function, accordingly.
> 
> Signed-off-by: Ian Jackson 

Acked-by: Anthony PERARD 

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH RFC 03/10] x86/passthrough: io.c is used for HVM only

[Jan Beulich]

>>> On 21.02.18 at 22:46,  wrote:
> Signed-off-by: Wei Liu 
> ---
> This file has a few functions that are called in other places. We need
> to provide stubs for them at some point. Currently the declarations
> are in different places. What is the preferred name / location for the
> stubs?

Perhaps dpci.h, and maybe this file should also be named dpci.c? I've
never understood on what grounds its current name was chosen.

Jan



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

Re: [Xen-devel] [PATCH RFC 02/10] passthrough: split out x86 PCI code to x86/pci.c

[Jan Beulich]

>>> On 21.02.18 at 22:46,  wrote:
> Move the functions that reference x86 hvm data structures to its own
> file.  Rename pci_clean_dpci_irqs to arch_pci_clean_irqs.
> 
> There is still one location in that file which references
> arch.hvm_domain, but it is fine because ARM guest is HVM.
> 
> Signed-off-by: Wei Liu 
> ---
> Cc: Stefano Stabellini 
> Cc: Julien Grall 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> 
> ARM doesn't select HAS_PCI, that's why ARM build is not broken by
> this. AIUI ARM will select HAS_PCI at some point, hence I only move
> the x86 bits.

The fact that this change doesn't actually affect ARM is again an
indication that the decision whether the code you move here is
x86-specific depends on what parts of PCI pass-through ARM is
actually going to want to (re-)use. I'd again prefer to take that
decision either when ARM actually implements that, or based on
the ARM folks clearly foreseeing that this code is not coming
close to anything they may want use.

> @@ -853,7 +804,7 @@ int pci_release_devices(struct domain *d)
>  int ret;
>  
>  pcidevs_lock();
> -ret = pci_clean_dpci_irqs(d);
> +ret = arch_pci_clean_irqs(d);

One note regarding the naming: I'd prefer if "dpci" remained part of
the name, unless you mean to get rid of it altogether from the code
base. That'll help (a little) with visually separating code pieces
belonging to the host side of PCI from those belonging to the
passed through side of it (granted - they aren't entirely independent
anyway).

Jan



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

Re: [Xen-devel] [PATCH RFC 01/10] passthrough: rearrange x86 code

[Jan Beulich]

>>> On 21.02.18 at 22:46,  wrote:
> Clean up the hierarchy of the directory: put vtd, amd and io.c under
> x86. Adjust makefile and MAINTAINERS.

Considering the history in particular of VT-d, I'm not convinced of this move:
x86 and ia64 did share the bulk of the VT-d code back when ia64 was still in
the tree. Arguably the AMD IOMMU is less likely to be leveraged for some
non-x86 architecture, but I think it would better stay the way it is as well.

As to io.c - it's not currently needed by ARM, but there doesn't look to be
that many x86-specific code in there. I would prefer if the ARM folks could
judge whether that's code they're never going to use, in which case moving
it to x86/ would be fine with me.

What I don't understand here at all is how this movement of code relates
to the PV/HVM splitting.

Jan



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

Re: [Xen-devel] [PATCH 03/16] xen: link against xentoolcore

[Anthony PERARD]

On Thu, Apr 19, 2018 at 05:45:06PM +0100, Ian Jackson wrote:
> From: Anthony PERARD 
> 
> Xen libraries in 4.10 include a new xentoolcore library.  This
> contains the xentoolcore_restrict_all function which we are about to
> want to use.
> 
> Signed-off-by: Ian Jackson 
> Acked-by: Stefano Stabellini 
> ---
> v5: More truthful commit message.
> ---
>  configure | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/configure b/configure
> index 0a19b03..f580255 100755
> --- a/configure
> +++ b/configure
> @@ -2188,7 +2188,7 @@ if test "$xen" != "no" ; then
>$($pkg_config --modversion xencontrol | sed 's/\./ /g') )"
>  xen=yes
>  xen_pc="xencontrol xenstore xenguest xenforeignmemory xengnttab"
> -xen_pc="$xen_pc xenevtchn xendevicemodel"
> +xen_pc="$xen_pc xenevtchn xendevicemodel xentoolcore"

I think we want to check if "xentoolcore" pkg_config exist before trying
to use it. Otherwith, that is not going to work with Xen older than
4.10.

`pkg-config --libs` will throw an error without printing anything if
one of the library doesn't exist.

Instead, we could do this:
if $pkg_config --exists xentoolcore; then
  xen_pc+=" xentoolcore"
fi

>  QEMU_CFLAGS="$QEMU_CFLAGS $($pkg_config --cflags $xen_pc)"
>  libs_softmmu="$($pkg_config --libs $xen_pc) $libs_softmmu"
>  LDFLAGS="$($pkg_config --libs $xen_pc) $LDFLAGS"


-- 
Anthony PERARD

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

Re: [Xen-devel] [RFC v2 4/9] libxl_qmp: Move the buffer realloc to the same scope level as read

[Wei Liu]

On Mon, Apr 23, 2018 at 03:50:27PM +0100, Anthony PERARD wrote:
> On Mon, Apr 23, 2018 at 10:03:39AM +0100, Wei Liu wrote:
> > On Mon, Apr 16, 2018 at 06:32:22PM +0100, Anthony PERARD wrote:
> > > In qmp_next(), the inner loop should only try to parse messages from
> > > QMP, if there is more than one.
> > > 
> > > The handling of the receive buffer ('incomplete'), should be done at the
> > > same scope level as read(). It doesn't need to be handle more that once
> > > after a read.
> > > 
> > 
> > In general I agree this is a better idea than the current code.
> > 
> > > Before this patch, when on message what handled, the inner loop would
> > 
> > Sorry, I failed to parse "when on message what handled".
> 
> I probably wanted to write: "when one message was handled". Is this
> better?

Yes.

> 
> > > restart by adding the 'buffer' into 'incomplete' (after reallocation).
> > > Since 'rd' was not reset, the buffer would be strcat a second time.
> > > After that, the stream from the QMP server would have syntax error, and
> > > the parsor would throw errors.
> > > 
> > > This is unlikely to happen as the receive buffer is very large. And
> > > receiving two messages in a row is unlikely. In the current case, this
> > > could be an event and a response to a command.
> > > 
> > > Signed-off-by: Anthony PERARD 
> > > ---
> > >  tools/libxl/libxl_qmp.c | 31 ---
> > >  1 file changed, 16 insertions(+), 15 deletions(-)
> > > 
> > > diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
> > > index 4d207c3842..a25f445fb6 100644
> > > --- a/tools/libxl/libxl_qmp.c
> > > +++ b/tools/libxl/libxl_qmp.c
> > > @@ -524,23 +524,24 @@ static int qmp_next(libxl__gc *gc, 
> > > libxl__qmp_handler *qmp)
> > >  
> > >  DEBUG_REPORT_RECEIVED(qmp->domid, qmp->buffer, (int)rd);
> > >  
> > > +if (incomplete) {
> > > +size_t current_pos = s - incomplete;
> > > +incomplete = libxl__realloc(gc, incomplete,
> > > +incomplete_size + rd + 1);
> > > +strncat(incomplete + incomplete_size, qmp->buffer, rd);
> > > +s = incomplete + current_pos;
> > 
> > This can be dropped, because s is not changed. It is just the reversal
> > of what is a few lines above.
> 
> No, realloc may change the location of the allocated memory. So, between
> "current_pos = s - incomplete" and "s = incomplete + current_pos", the
> value of 'incomplete' may have changed.

Indeed, I missed that somehow.

Wei.

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

Re: [Xen-devel] Setting up a call to discuss PCI Emulation - Future Direction

[Lars Kurth]

Alright: 17:00-18:00 it is. I will send out a separate mail with call-in details
Lars

On 23/04/2018, 15:24, "Chao Gao"  wrote:

On Mon, Apr 23, 2018 at 10:12:22PM +0800, Chao Gao wrote:
>On Mon, Apr 23, 2018 at 08:26:59AM +, Lars Kurth wrote:
>>Hi all,
>>so it seems we have no perfect slot proposals, but 2 semi-perfect.
>>May 2nd: 16:00 - 17:00 Christopher can't attend
>>May 2nd: 17:00 - 18:00 Chao can't attend
>>Maybe a compromise would be 16:30 to 17:30
>
>Hi Lars,
>
>Your suggestion is fine with me. 16:00-17:00 is also acceptable to me. I

I meant 17:00-18:00 here.

Thanks
Chao

>don't want Christopher can't attend the whole meeting because I am just
>interested in this discussion and won't provide useful suggestions
>during the discussion.
>
>Thanks
>Chao
>
>>Regards
>>Lars
>>
>>On 21/04/2018, 05:47, "Alexey G"  wrote:
>>
>>On Fri, 13 Apr 2018 11:01:49 +0100
>>Roger Pau Monné  wrote:
>>
>>>On Thu, Apr 12, 2018 at 05:50:00PM +0100, Lars Kurth wrote:
>>>> 
>>>> 
>>>> On 12/04/2018, 17:41, "Roger Pau Monne" 
>>>> wrote:
>>>> 
>>>> On Thu, Apr 12, 2018 at 05:32:57PM +0100, Lars Kurth wrote:
>>>> 
>>>>   
>>>> >may work. For me Mon, Wed and Fri’s generally work at 
those
>>>> > time-slots. Next week is a little busy for me, so I would
>>>> > prefer the following week. If you could fill out the 
following
>>>> > Google poll, if this week works that would be great. 
Otherwise
>>>> > please scream.  
>>>> 
>>>> I'm afraid I'm on vacations from the 21st to the 29th of April,
>>>> so I won't be able to join the meeting unless we move it to the 
week
>>>> after. Let's see what people think of the current dates.
>>>> 
>>>> Roger.
>>>> 
>>>> Hi, I changed the dates to the week after. Poll so far has been
>>>> invalidated.
>>>> 
>>>> See https://doodle.com/poll/gdnmcrvnibmw563n  
>>>
>>>Thanks! I've already fixed my vote.
>>>
>>>I guess this will come later, but we need a clear agenda of items
>>>because the x86 and ARM topics are probably going to be completely
>>>different (albeit all related to PCI).
>>>
>>>Roger.
>>
>>1. different approaches to handle some critical chipset-specific
>>   registers (MCH PCIEXBAR first of all), currently emulated by
>>   QEMU. Role of QEMU in the emulation of MMCONFIG accesses.
>>
>>2. MMIO hole sizing in general (for HVM) -- in which PT usecases this 
is
>>   needed, requirements, limitations. It is related to the emulated
>>   chipset-specific resources and depends on the chosen solution for 
#1.
>>
>>I'll try to describe different possible implementations how to make 
the
>>multiple PCI device emulators feature compatible with emulated 
MMCONFIG
>>before the meeting, to have a ground for discussion. There are at 
least
>>3 possible directions currently to solve this problem.
>>
>>
>>___
>>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

[Xen-devel] [OSSTEST PATCH 2/3] ms-planner: include PreviousShare information in Unshare events

[Ian Jackson]

We can't put this in $evt->{Share} because existing clients will see
it there and assume it means the resource is shared.

Signed-off-by: Ian Jackson 
---
 ms-planner | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/ms-planner b/ms-planner
index af0c746..5d20cc2 100755
--- a/ms-planner
+++ b/ms-planner
@@ -234,6 +234,7 @@ sub launder_check_plan () {
Type => Unshare,
Avail => 1,
Info => $cshare->{Type},
+   PreviousShare => $cshare,
};
$cshare= undef;
}
@@ -412,6 +413,7 @@ sub cmd_get_plan () {
my @jevts;
foreach my $evt (@$evts) {
my $share= $evt->{Share};
+   my $previousshare= $evt->{PreviousShare};
my $job= $evt->{Job};
push @jevts, {
Time => $evt->{Time} - $plan->{Start},
@@ -419,6 +421,7 @@ sub cmd_get_plan () {
Avail => $evt->{Avail},
($job ? (Job => $job) : ()),
($share ? (Share => $share) : ()),
+   ($previousshare ? (PreviousShare => $previousshare) : ()),
};
}
$jplan->{Events}{$reso}= \@jevts;
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 1/3] ms-queuedaemon: Support infra-priority

[Ian Jackson]

This will allow a flight to order the queueing its own test jobs more
sensibly without interfering with inter-flight priority.

Signed-off-by: Ian Jackson 
---
 README.planner | 1 +
 ms-queuedaemon | 6 --
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/README.planner b/README.planner
index fec7482..c33aae1 100644
--- a/README.planner
+++ b/README.planner
@@ -238,6 +238,7 @@ ms-queuedaemon commands
 > set-info priority ...  } used for
 > set-info sub-priority ...  } queue adjustment
 > set-info wait-start-adjust ... }
+> set-info infra-priority ...}
 
 > set-info feature-noalloc 1
The client understands `!OK think noalloc'.
diff --git a/ms-queuedaemon b/ms-queuedaemon
index 430860a..f02abf3 100755
--- a/ms-queuedaemon
+++ b/ms-queuedaemon
@@ -599,15 +599,17 @@ proc chan-order-key {chan} {
 
 set priority [chan-get-info $chan {int($info(priority))} 0]
 set subpriority [chan-get-info $chan {int($info(sub-priority))} 0]
+set infrapriority [chan-get-info $chan {int($info(infra-priority))} 0]
 
 set waitstart "$info(wait-start use)"
 incr waitstart [chan-get-info $chan {int($info(wait-start-adjust))} 0]
 
 #puts stderr "priority $chan $priority $emsg"
-return [format "%011d.%011d.%011d" \
+return [format "%011d.%011d.%011d.%011d" \
 [expr {$priority+10}] \
 [expr {$subpriority+10}] \
-$waitstart]
+$waitstart \
+[expr {$infrapriority+10}]]
 }
 
 proc cmd/prod {chan desc} {
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 0/3] ms-*: Support for host reuse

[Ian Jackson]

These three patches help support within-flight test hose reuse.

Currently there is nothing that uses these new features in any public
branch.  I have a private branch with the client side, which has seen
some testing and which I hope will be ready soon.

These daemon changes have been in production in the Citrix Cambridge
instance for quite some time, and have not caused any trouble there.

So I intend to update the Massachussets daemons to this version too.

Ian.

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

[Xen-devel] [OSSTEST PATCH 3/3] ms-planner: Including Unshare event for previous sharing state

[Ian Jackson]

Arrange for the initial plan to contain an Unshare event for resources
which are unallocated, but currently recorded as shared (ie, they
might be ready for reuse).

Specifically, we need to:

 * Include the Wear in the information for a host with no
   unallocatable shares (since the consumers might want to reuse the
   current state).

 * When processing the allocations in cmd_reset, look for sharing
   entries (ie, things we found allocated by magic/shared, and made a
   note in %currentshare) that didn't have any corresponding
   allocations of shares.  Generate an Unshare event for them.

 * When we find an Unshare event in the plan, we used to remove it.
   Now we keep it if it's the first thing in the plan.  (For
   subsequent entries callers don't generally need it because they can
   find the sharing info from previous events.)  When it is the first
   thing in the plan, we do some checks on it.

Signed-off-by: Ian Jackson 
---
 ms-planner | 34 --
 1 file changed, 32 insertions(+), 2 deletions(-)

diff --git a/ms-planner b/ms-planner
index 5d20cc2..2b8b6c2 100755
--- a/ms-planner
+++ b/ms-planner
@@ -151,6 +151,7 @@ END
 OnlyPreparing => 1,
 Shares => $shares->{shares},
 Type => $sharing->{sharetype},
+Wear => $sharing->{wear},
 };
 }
 
@@ -185,8 +186,21 @@ sub launder_check_plan () {
 };
 
my $type= $evt->{Type};
-   next if $type eq Unshare;
-
+   if ($type eq Unshare) {
+   if (!@evts) {
+   # record inherited sharing info
+   $bad->('unshare not in past')
+   unless $evt->{Time} <= $plan->{Start};
+   $bad->('unshare avail')
+   unless $evt->{Avail} == 1;
+   my $eshare = $evt->{PreviousShare};
+   $eshare->{$_} // $bad->("unshare $_")
+   foreach qw(Type Wear Shares);
+   push @evts, $evt;
+   }
+   next;
+   }
+   
push @evts, $evt;
 
 $bad->('type') unless $type eq Start || $type eq End;
@@ -394,6 +408,22 @@ END
};
 }
 
+foreach my $reskey (keys %currentshare) {
+   my $cshare = $currentshare{$reskey};
+   next if $plan->{Events}{$reskey};
+   print DEBUG "document existing quiescent sharing $reskey".
+   " share.Type $cshare->{Type}\n";
+   my $evt = {
+Time => $plan->{Start},
+Type => Unshare,
+   Avail => 1,
+Info => 'recently shared $cshare->{Type}',
+PreviousShare => { %$cshare },
+   };
+   delete $evt->{PreviousShare}{OnlyPreparing};
+   push @{ $plan->{Events}{$reskey} }, $evt;
+}
+
 # Now everything in the plan is good except that we
 # need to sort the lists and compute Avails, which is done by
 # check_write_new_plan.
-- 
2.1.4


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

Re: [Xen-devel] [RFC v2 4/9] libxl_qmp: Move the buffer realloc to the same scope level as read

[Anthony PERARD]

On Mon, Apr 23, 2018 at 10:03:39AM +0100, Wei Liu wrote:
> On Mon, Apr 16, 2018 at 06:32:22PM +0100, Anthony PERARD wrote:
> > In qmp_next(), the inner loop should only try to parse messages from
> > QMP, if there is more than one.
> > 
> > The handling of the receive buffer ('incomplete'), should be done at the
> > same scope level as read(). It doesn't need to be handle more that once
> > after a read.
> > 
> 
> In general I agree this is a better idea than the current code.
> 
> > Before this patch, when on message what handled, the inner loop would
> 
> Sorry, I failed to parse "when on message what handled".

I probably wanted to write: "when one message was handled". Is this
better?

> > restart by adding the 'buffer' into 'incomplete' (after reallocation).
> > Since 'rd' was not reset, the buffer would be strcat a second time.
> > After that, the stream from the QMP server would have syntax error, and
> > the parsor would throw errors.
> > 
> > This is unlikely to happen as the receive buffer is very large. And
> > receiving two messages in a row is unlikely. In the current case, this
> > could be an event and a response to a command.
> > 
> > Signed-off-by: Anthony PERARD 
> > ---
> >  tools/libxl/libxl_qmp.c | 31 ---
> >  1 file changed, 16 insertions(+), 15 deletions(-)
> > 
> > diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
> > index 4d207c3842..a25f445fb6 100644
> > --- a/tools/libxl/libxl_qmp.c
> > +++ b/tools/libxl/libxl_qmp.c
> > @@ -524,23 +524,24 @@ static int qmp_next(libxl__gc *gc, libxl__qmp_handler 
> > *qmp)
> >  
> >  DEBUG_REPORT_RECEIVED(qmp->domid, qmp->buffer, (int)rd);
> >  
> > +if (incomplete) {
> > +size_t current_pos = s - incomplete;
> > +incomplete = libxl__realloc(gc, incomplete,
> > +incomplete_size + rd + 1);
> > +strncat(incomplete + incomplete_size, qmp->buffer, rd);
> > +s = incomplete + current_pos;
> 
> This can be dropped, because s is not changed. It is just the reversal
> of what is a few lines above.

No, realloc may change the location of the allocated memory. So, between
"current_pos = s - incomplete" and "s = incomplete + current_pos", the
value of 'incomplete' may have changed.

> > +incomplete_size += rd;
> > +s_end = incomplete + incomplete_size;
> > +} else {
> > +incomplete = libxl__strndup(gc, qmp->buffer, rd);
> > +incomplete_size = rd;
> > +s = incomplete;
> > +s_end = s + rd;
> > +rd = 0;
> 
> This can be dropped.
> 
> And I think we should take this change to change "incomplete" to
> something more meaningful, like "qmp_msg_buf".

I think that can be done.


-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH V2] x86/p2m: fixed p2m_change_type_range() start / end check

[Razvan Cojocaru]

On 04/23/2018 05:28 PM, George Dunlap wrote:
> On 04/23/2018 12:56 PM, Razvan Cojocaru wrote:
>> On 04/23/2018 02:47 PM, George Dunlap wrote:
>>> On 04/18/2018 02:12 PM, Razvan Cojocaru wrote:
 p2m_change_type_range() handles end > max_mapped_pfn, but not
 start > max_mapped_pfn. Check the latter just after grabbing the
 lock and bail if true.

 Signed-off-by: Razvan Cojocaru 
 Suggested-by: George Dunlap 
>>>
>>> Sorry, I meant to reply to this earlier but I haven't been able to make
>>> the time.
>>>
>>> On reflection, I think this is the wrong approach actually.  First, my
>>> assertion was incorrect: the p2m_altp2m_propagate_change() is gated on
>>> p2m->max_remapped_gfn, not max_mapped_gfn (nb the 're').  So setting
>>> max_mapped_gfn shouldn't cause 'unnecessary' propagations.
>>>
>>> Secondly, we do actually need to keep the logdirty ranges of all the
>>> p2ms in sync, even if they're past the max_remapped_gfn.  Otherwise we
>>> could have the following situation:
>>> * altp2m created, max_remapped_gfn 0x1000
>>> * screen resized, logdirty range [0x2000-0x3000]; change dropped
>>> * guest accesses 0x4000, max_remapped_gfn set to 0x4000
>>> * change_p2m_type happens, and the 0x2000-0x3000 range is not marked
>>> logrdirty #
>>>
>>> So while it would be an improvement to make the assertion more explicit,
>>> I don't (anymore) think it would actually be an improvement to discard
>>> changes that are above max_mapped_gfn.  (And thus your original patch,
>>> which copied max_mapped_gfn into the altp2ms, was probably closer to the
>>> right approach).
>>>
>>> Sorry for the confusion -- we obviously need a bit more thought about
>>> how altp2m and logdirty interact.
>>
>> Thanks for the reply! Fair enough.
>>
>> FWIW, the attached patch works well for me, resizes and all (but it
>> could very well be just luck).
> 
> I think we really want some sort of analysis of all the ways the two
> features might interact, and some justification as to why a solution is
> complete.
> 
> You're not aiming to get a patch like this into 4.11 though, are you?

No (although it would have been nice if possible). A good solution to
the problem is the goal here, 4.11 or not. Nobody wants a rushed hack.

Thanks for all the help so far, and please let me know if you have any
suggestions I should try out.


Thanks,
Razvan

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

Re: [Xen-devel] [PATCH V2] x86/p2m: fixed p2m_change_type_range() start / end check

[George Dunlap]

On 04/23/2018 12:56 PM, Razvan Cojocaru wrote:
> On 04/23/2018 02:47 PM, George Dunlap wrote:
>> On 04/18/2018 02:12 PM, Razvan Cojocaru wrote:
>>> p2m_change_type_range() handles end > max_mapped_pfn, but not
>>> start > max_mapped_pfn. Check the latter just after grabbing the
>>> lock and bail if true.
>>>
>>> Signed-off-by: Razvan Cojocaru 
>>> Suggested-by: George Dunlap 
>>
>> Sorry, I meant to reply to this earlier but I haven't been able to make
>> the time.
>>
>> On reflection, I think this is the wrong approach actually.  First, my
>> assertion was incorrect: the p2m_altp2m_propagate_change() is gated on
>> p2m->max_remapped_gfn, not max_mapped_gfn (nb the 're').  So setting
>> max_mapped_gfn shouldn't cause 'unnecessary' propagations.
>>
>> Secondly, we do actually need to keep the logdirty ranges of all the
>> p2ms in sync, even if they're past the max_remapped_gfn.  Otherwise we
>> could have the following situation:
>> * altp2m created, max_remapped_gfn 0x1000
>> * screen resized, logdirty range [0x2000-0x3000]; change dropped
>> * guest accesses 0x4000, max_remapped_gfn set to 0x4000
>> * change_p2m_type happens, and the 0x2000-0x3000 range is not marked
>> logrdirty #
>>
>> So while it would be an improvement to make the assertion more explicit,
>> I don't (anymore) think it would actually be an improvement to discard
>> changes that are above max_mapped_gfn.  (And thus your original patch,
>> which copied max_mapped_gfn into the altp2ms, was probably closer to the
>> right approach).
>>
>> Sorry for the confusion -- we obviously need a bit more thought about
>> how altp2m and logdirty interact.
> 
> Thanks for the reply! Fair enough.
> 
> FWIW, the attached patch works well for me, resizes and all (but it
> could very well be just luck).

I think we really want some sort of analysis of all the ways the two
features might interact, and some justification as to why a solution is
complete.

You're not aiming to get a patch like this into 4.11 though, are you?

 -George

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

Re: [Xen-devel] [PATCH 05/16] xen: defer call to xen_restrict until just before os_setup_post

[Anthony PERARD]

On Thu, Apr 19, 2018 at 05:45:08PM +0100, Ian Jackson wrote:
> We need to restrict *all* the control fds that qemu opens.  Looking in
> /proc/PID/fd shows there are many; their allocation seems scattered
> throughout Xen support code in qemu.
> 
> We must postpone the restrict call until roughly the same time as qemu
> changes its uid, chroots (if applicable), and so on.
> 
> There doesn't seem to be an appropriate hook already.  The RunState
> change hook fires at different times depending on exactly what mode
> qemu is operating in.
> 
> And it appears that no-one but the Xen code wants a hook at this phase
> of execution.  So, introduce a bare call to a new function
> xen_setup_post, just before os_setup_post.  Also provide the
> appropriate stub for when Xen compilation is disabled.
> 
> We do the restriction before rather than after os_setup_post, because
> xen_restrict may need to open /dev/null, and os_setup_post might have
> called chroot.
> 
> Currently this does not work with migration, because when running as
> the Xen device model qemu needs to signal to the toolstack that it is
> ready.  It currently does this using xenstore, and for incoming
> migration (but not for ordinary startup) that happens after
> os_setup_post.
> 
> It is correct that this happens late: we want the incoming migration
> stream to be processed by a restricted qemu.  The fix for this will be
> to do the startup notification a different way, without using
> xenstore.  (QMP is probably a reasonable choice.)
> 
> So for now this restriction feature cannot be used in conjunction with
> migration.  (Note that this is not a regression in this patch, because
> previously the -xen-restrict-domid call was, in fact, simply
> ineffective!)  We will revisit this in the Xen 4.11 release cycle.
> 
> Signed-off-by: Ian Jackson 

Acked-by: Anthony PERARD 

-- 
Anthony PERARD

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

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

[osstest service owner]

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

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  fa9cb90071dbc9a20b01cc6a88d96ba140545af9
baseline version:
 xen  25b0dad541e31bd892d57cbeafe8e0c0bf4e8385

Last test of basis   122352  2018-04-23 10:13:30 Z0 days
Testing same since   122366  2018-04-23 13:00:39 Z0 days1 attempts


People who touched revisions under test:
  Ian Jackson 

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
   25b0dad541..fa9cb90071  fa9cb90071dbc9a20b01cc6a88d96ba140545af9 -> smoke

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

Re: [Xen-devel] Setting up a call to discuss PCI Emulation - Future Direction

[Chao Gao]

On Mon, Apr 23, 2018 at 10:12:22PM +0800, Chao Gao wrote:
>On Mon, Apr 23, 2018 at 08:26:59AM +, Lars Kurth wrote:
>>Hi all,
>>so it seems we have no perfect slot proposals, but 2 semi-perfect.
>>May 2nd: 16:00 - 17:00 Christopher can't attend
>>May 2nd: 17:00 - 18:00 Chao can't attend
>>Maybe a compromise would be 16:30 to 17:30
>
>Hi Lars,
>
>Your suggestion is fine with me. 16:00-17:00 is also acceptable to me. I

I meant 17:00-18:00 here.

Thanks
Chao

>don't want Christopher can't attend the whole meeting because I am just
>interested in this discussion and won't provide useful suggestions
>during the discussion.
>
>Thanks
>Chao
>
>>Regards
>>Lars
>>
>>On 21/04/2018, 05:47, "Alexey G"  wrote:
>>
>>On Fri, 13 Apr 2018 11:01:49 +0100
>>Roger Pau Monné  wrote:
>>
>>>On Thu, Apr 12, 2018 at 05:50:00PM +0100, Lars Kurth wrote:
>>>> 
>>>> 
>>>> On 12/04/2018, 17:41, "Roger Pau Monne" 
>>>> wrote:
>>>> 
>>>> On Thu, Apr 12, 2018 at 05:32:57PM +0100, Lars Kurth wrote:
>>>> 
>>>>   
>>>> >may work. For me Mon, Wed and Fri’s generally work at those
>>>> > time-slots. Next week is a little busy for me, so I would
>>>> > prefer the following week. If you could fill out the following
>>>> > Google poll, if this week works that would be great. Otherwise
>>>> > please scream.  
>>>> 
>>>> I'm afraid I'm on vacations from the 21st to the 29th of April,
>>>> so I won't be able to join the meeting unless we move it to the week
>>>> after. Let's see what people think of the current dates.
>>>> 
>>>> Roger.
>>>> 
>>>> Hi, I changed the dates to the week after. Poll so far has been
>>>> invalidated.
>>>> 
>>>> See https://doodle.com/poll/gdnmcrvnibmw563n  
>>>
>>>Thanks! I've already fixed my vote.
>>>
>>>I guess this will come later, but we need a clear agenda of items
>>>because the x86 and ARM topics are probably going to be completely
>>>different (albeit all related to PCI).
>>>
>>>Roger.
>>
>>1. different approaches to handle some critical chipset-specific
>>   registers (MCH PCIEXBAR first of all), currently emulated by
>>   QEMU. Role of QEMU in the emulation of MMCONFIG accesses.
>>
>>2. MMIO hole sizing in general (for HVM) -- in which PT usecases this is
>>   needed, requirements, limitations. It is related to the emulated
>>   chipset-specific resources and depends on the chosen solution for #1.
>>
>>I'll try to describe different possible implementations how to make the
>>multiple PCI device emulators feature compatible with emulated MMCONFIG
>>before the meeting, to have a ground for discussion. There are at least
>>3 possible directions currently to solve this problem.
>>
>>
>>___
>>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] tools/kdd: silence gcc 8 warning a different way

[Wei Liu]

On Mon, Apr 16, 2018 at 02:43:32PM +0200, Marek Marczykowski wrote:
> On Mon, Apr 16, 2018 at 06:00:37AM -0600, Jan Beulich wrote:
> > >>> On 16.04.18 at 12:33,  wrote:
> > > On Thu, Apr 12, 2018 at 06:04:49AM -0600, Jan Beulich wrote:
> > >> Older gcc doesn't like "#pragma GCC diagnostic" inside functions.
> > >> 
> > >> Signed-off-by: Jan Beulich 
> > >> 
> > >> --- a/tools/debugger/kdd/kdd.c
> > >> +++ b/tools/debugger/kdd/kdd.c
> > >> @@ -695,10 +695,10 @@ static void kdd_handle_read_ctrl(kdd_sta
> > >>  KDD_LOG(s, "Request outside of known control space\n");
> > >>  len = 0;
> > >>  } else {
> > >> -#pragma GCC diagnostic push
> > >> -#pragma GCC diagnostic ignored "-Warray-bounds"
> > >> -memcpy(buf, ((uint8_t *)) + offset, len);
> > >> -#pragma GCC diagnostic pop
> > >> +/* Suppress bogus gcc 8 "out of bounds" warning. */
> > >> +const uint8_t *src;
> > >> +asm ("" : "=g" (src) : "0" ((uint8_t *) + offset));
> > >> +memcpy(buf, src, len);
> > > 
> > > The code looks correct to me:
> > > 
> > > Reviewed-by: Wei Liu 
> > > 
> > > This will hopefully also fix the issue Boris reported that some older
> > > gcc (<4.6) doesn't support push and pop.
> > > 
> > > This is the first time I see inline assembly is used to silence gcc.
> > > ;-)
> > 
> > And I'm not overly happy about it, but couldn't think of a better way
> > without disabling said warning (or -Werror) altogether for the CU. If
> > Ian's sketched out approach worked, I'd be quite happy to drop the
> > patch here.
> 
> What about changing offset type to uint32_t (or similar), which also
> mute the warning?

That should be fine, since that branch is handling 32 bit case. Tim in
the other sub-thread also hinted something similar.

Wei.

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



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

Re: [Xen-devel] Setting up a call to discuss PCI Emulation - Future Direction

[Chao Gao]

On Mon, Apr 23, 2018 at 08:26:59AM +, Lars Kurth wrote:
>Hi all,
>so it seems we have no perfect slot proposals, but 2 semi-perfect.
>May 2nd: 16:00 - 17:00 Christopher can't attend
>May 2nd: 17:00 - 18:00 Chao can't attend
>Maybe a compromise would be 16:30 to 17:30

Hi Lars,

Your suggestion is fine with me. 16:00-17:00 is also acceptable to me. I
don't want Christopher can't attend the whole meeting because I am just
interested in this discussion and won't provide useful suggestions
during the discussion.

Thanks
Chao

>Regards
>Lars
>
>On 21/04/2018, 05:47, "Alexey G"  wrote:
>
>On Fri, 13 Apr 2018 11:01:49 +0100
>Roger Pau Monné  wrote:
>
>>On Thu, Apr 12, 2018 at 05:50:00PM +0100, Lars Kurth wrote:
>>> 
>>> 
>>> On 12/04/2018, 17:41, "Roger Pau Monne" 
>>> wrote:
>>> 
>>> On Thu, Apr 12, 2018 at 05:32:57PM +0100, Lars Kurth wrote:
>>> 
>>>   
>>> >may work. For me Mon, Wed and Fri’s generally work at those
>>> > time-slots. Next week is a little busy for me, so I would
>>> > prefer the following week. If you could fill out the following
>>> > Google poll, if this week works that would be great. Otherwise
>>> > please scream.  
>>> 
>>> I'm afraid I'm on vacations from the 21st to the 29th of April,
>>> so I won't be able to join the meeting unless we move it to the week
>>> after. Let's see what people think of the current dates.
>>> 
>>> Roger.
>>> 
>>> Hi, I changed the dates to the week after. Poll so far has been
>>> invalidated.
>>> 
>>> See https://doodle.com/poll/gdnmcrvnibmw563n  
>>
>>Thanks! I've already fixed my vote.
>>
>>I guess this will come later, but we need a clear agenda of items
>>because the x86 and ARM topics are probably going to be completely
>>different (albeit all related to PCI).
>>
>>Roger.
>
>1. different approaches to handle some critical chipset-specific
>   registers (MCH PCIEXBAR first of all), currently emulated by
>   QEMU. Role of QEMU in the emulation of MMCONFIG accesses.
>
>2. MMIO hole sizing in general (for HVM) -- in which PT usecases this is
>   needed, requirements, limitations. It is related to the emulated
>   chipset-specific resources and depends on the chosen solution for #1.
>
>I'll try to describe different possible implementations how to make the
>multiple PCI device emulators feature compatible with emulated MMCONFIG
>before the meeting, to have a ground for discussion. There are at least
>3 possible directions currently to solve this problem.
>
>
>___
>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] [RFC 0/2] To introduce xenwatch multithreading (xen mtwatch)

[Wei Liu]

On Sat, Apr 07, 2018 at 07:25:53PM +0800, Dongli Zhang wrote:
> About per-domU xenwatch thread create/destroy, a new type of xenstore node is
> introduced: '/local/domain/0/mtwatch/'.
> 
> Suppose the new domid id 7. During the domU (domid=7) creation, the xen
> toolstack writes '/local/domain/0/mtwatch/7' to xenstore before the insertion
> of '/local/domain/7'. When the domid=7 is destroyed, the last xenstore
> operation by xen toolstack is to remove '/local/domain/0/mtwatch/7'.
> 
> The dom0 kernel subscribes a watch at node '/local/domain/0/mtwatch'.  Kernel
> thread [xen-mtwatch-7] is created when '/local/domain/0/mtwatch/7' is 
> inserted,
> while this kernel thread is destroyed when the corresponding xenstore node is
> removed.

Instead of inventing yet another node, can you not watch /local/domain
directly?

Wei.

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

Re: [Xen-devel] [PATCH v3] xpti: fix bug in double fault handling

[Andrew Cooper]

On 23/04/18 14:59, Juergen Gross wrote:
> When entering the hypervisor via the double fault handler resetting
> xen_cr3 was missing. This led to switching to pv_cr3 when returning
> from the next following exception, so repair this in order to allow
> exception handling to work even after a double fault.
>
> Signed-off-by: Juergen Gross 

Reviewed-by: Andrew Cooper 
Tested-by: Andrew Cooper 

> ---
>  xen/arch/x86/x86_64/entry.S | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/xen/arch/x86/x86_64/entry.S b/xen/arch/x86/x86_64/entry.S
> index 45d9842d09..1cd7d93892 100644
> --- a/xen/arch/x86/x86_64/entry.S
> +++ b/xen/arch/x86/x86_64/entry.S
> @@ -767,12 +767,14 @@ ENTRY(double_fault)
>  /* WARNING! `ret`, `call *`, `jmp *` not safe before this point. */
>  
>  mov   STACK_CPUINFO_FIELD(xen_cr3)(%r14), %rbx
> -test  %rbx, %rbx
> +neg   %rbx
>  jz.Ldblf_cr3_okay
>  jns   .Ldblf_cr3_load
> +mov   %rbx, STACK_CPUINFO_FIELD(xen_cr3)(%r14)
>  neg   %rbx
>  .Ldblf_cr3_load:
>  mov   %rbx, %cr3
> +movq $0, STACK_CPUINFO_FIELD(xen_cr3)(%r14)
>  .Ldblf_cr3_okay:
>  
>  movq  %rsp,%rdi


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

Re: [Xen-devel] [PATCH v3] xpti: fix bug in double fault handling

[Jan Beulich]

>>> On 23.04.18 at 15:59,  wrote:
> When entering the hypervisor via the double fault handler resetting
> xen_cr3 was missing. This led to switching to pv_cr3 when returning
> from the next following exception, so repair this in order to allow
> exception handling to work even after a double fault.
> 
> Signed-off-by: Juergen Gross 

Reviewed-by: Jan Beulich 
(and I'm glad Andrew had noticed the issue before me putting this in)

Jan



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

[Xen-devel] [PATCH v3] xpti: fix bug in double fault handling

[Juergen Gross]

When entering the hypervisor via the double fault handler resetting
xen_cr3 was missing. This led to switching to pv_cr3 when returning
from the next following exception, so repair this in order to allow
exception handling to work even after a double fault.

Signed-off-by: Juergen Gross 
---
 xen/arch/x86/x86_64/entry.S | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/x86_64/entry.S b/xen/arch/x86/x86_64/entry.S
index 45d9842d09..1cd7d93892 100644
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -767,12 +767,14 @@ ENTRY(double_fault)
 /* WARNING! `ret`, `call *`, `jmp *` not safe before this point. */
 
 mov   STACK_CPUINFO_FIELD(xen_cr3)(%r14), %rbx
-test  %rbx, %rbx
+neg   %rbx
 jz.Ldblf_cr3_okay
 jns   .Ldblf_cr3_load
+mov   %rbx, STACK_CPUINFO_FIELD(xen_cr3)(%r14)
 neg   %rbx
 .Ldblf_cr3_load:
 mov   %rbx, %cr3
+movq $0, STACK_CPUINFO_FIELD(xen_cr3)(%r14)
 .Ldblf_cr3_okay:
 
 movq  %rsp,%rdi
-- 
2.13.6


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

Re: [Xen-devel] [PATCH] x86: correct assertion in destroy_perdomain_mapping()

[Juergen Gross]

On 23/04/18 15:39, Andrew Cooper wrote:
> On 20/04/18 16:03, Jan Beulich wrote:
>> hvm_domain_initialise() may call this with nr being zero, which triggers
>> the "does not cross L3 boundary" check.
>>
>> Signed-off-by: Jan Beulich 
> 
> Acked-by: Andrew Cooper 
> 

Release-acked-by: Juergen Gross 


Juergen

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

Re: [Xen-devel] [PATCH-for-4.11 v2] xpti: fix bug in double fault handling

[Juergen Gross]

On 23/04/18 15:06, Andrew Cooper wrote:
> On 23/04/18 13:38, Juergen Gross wrote:
>> When entering the hypervisor via the double fault handler resetting
>> xen_cr3 was missing. This led to switching to pv_cr3 when returning
>> from the next following interrupt. So repair this in order to allow
>> interrupt handling to work even after a double fault.
>>
>> Signed-off-by: Juergen Gross 
>> ---
>>  xen/arch/x86/x86_64/entry.S | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/xen/arch/x86/x86_64/entry.S b/xen/arch/x86/x86_64/entry.S
>> index 45d9842d09..25427b0cec 100644
>> --- a/xen/arch/x86/x86_64/entry.S
>> +++ b/xen/arch/x86/x86_64/entry.S
>> @@ -773,6 +773,7 @@ ENTRY(double_fault)
>>  neg   %rbx
>>  .Ldblf_cr3_load:
>>  mov   %rbx, %cr3
>> +movq $0, STACK_CPUINFO_FIELD(xen_cr3)(%r14)
>>  .Ldblf_cr3_okay:
>>  
>>  movq  %rsp,%rdi
> 
> What about the other write into xen_cr3 with a negated value?  Won't
> this still explode if we get an NMI or MCE at the wrong moment?

Hmm, you mean a NMI between the mov to %cr3 and zeroing xen_cr3?
Could be an issue, yes. Okay, V3 then...


Juergen


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

Re: [Xen-devel] [PATCH] x86: correct assertion in destroy_perdomain_mapping()

[Andrew Cooper]

On 20/04/18 16:03, Jan Beulich wrote:
> hvm_domain_initialise() may call this with nr being zero, which triggers
> the "does not cross L3 boundary" check.
>
> Signed-off-by: Jan Beulich 

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-for-4.11 v2] xpti: fix bug in double fault handling

[Andrew Cooper]

On 23/04/18 13:38, Juergen Gross wrote:
> When entering the hypervisor via the double fault handler resetting
> xen_cr3 was missing. This led to switching to pv_cr3 when returning
> from the next following interrupt. So repair this in order to allow
> interrupt handling to work even after a double fault.
>
> Signed-off-by: Juergen Gross 
> ---
>  xen/arch/x86/x86_64/entry.S | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/xen/arch/x86/x86_64/entry.S b/xen/arch/x86/x86_64/entry.S
> index 45d9842d09..25427b0cec 100644
> --- a/xen/arch/x86/x86_64/entry.S
> +++ b/xen/arch/x86/x86_64/entry.S
> @@ -773,6 +773,7 @@ ENTRY(double_fault)
>  neg   %rbx
>  .Ldblf_cr3_load:
>  mov   %rbx, %cr3
> +movq $0, STACK_CPUINFO_FIELD(xen_cr3)(%r14)
>  .Ldblf_cr3_okay:
>  
>  movq  %rsp,%rdi

What about the other write into xen_cr3 with a negated value?  Won't
this still explode if we get an NMI or MCE at the wrong moment?

~Andrew

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

Re: [Xen-devel] [PATCH-for-4.11 v2] xpti: fix bug in double fault handling

[Juergen Gross]

On 23/04/18 14:49, Jan Beulich wrote:
 On 23.04.18 at 14:38,  wrote:
>> When entering the hypervisor via the double fault handler resetting
>> xen_cr3 was missing. This led to switching to pv_cr3 when returning
>> from the next following interrupt. So repair this in order to allow
>> interrupt handling to work even after a double fault.
>>
>> Signed-off-by: Juergen Gross 
> 
> With s/interrupt/exception/ (or s/interrupt/interruption/) on the
> description (which is easy enough to do while committing)
> Reviewed-by: Jan Beulich 
> 
> I take it that your Rab can be implied here.

Correct. :-)


Juergen

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

Re: [Xen-devel] [PATCH-for-4.11 v2] xpti: fix bug in double fault handling

[Jan Beulich]

>>> On 23.04.18 at 14:38,  wrote:
> When entering the hypervisor via the double fault handler resetting
> xen_cr3 was missing. This led to switching to pv_cr3 when returning
> from the next following interrupt. So repair this in order to allow
> interrupt handling to work even after a double fault.
> 
> Signed-off-by: Juergen Gross 

With s/interrupt/exception/ (or s/interrupt/interruption/) on the
description (which is easy enough to do while committing)
Reviewed-by: Jan Beulich 

I take it that your Rab can be implied here.

Jan



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

Re: [Xen-devel] [PATCH-for-4.11] xpti: fix bug in double fault handling

[Jan Beulich]

>>> On 23.04.18 at 14:22,  wrote:
> On 23/04/18 14:11, Jan Beulich wrote:
> On 23.04.18 at 13:37,  wrote:
>>> --- a/tools/firmware/xen-dir/shim.config
>>> +++ b/tools/firmware/xen-dir/shim.config
>>> @@ -1,6 +1,6 @@
>>>  #
>>>  # Automatically generated file; DO NOT EDIT.
>>> -# Xen/x86 4.11-unstable Configuration
>>> +# Xen/x86 4.11-rc Configuration
>>>  #
>>>  CONFIG_X86_64=y
>>>  CONFIG_X86=y
>> 
>> Stray change?
> 
> Oh, that one again. Sorry. Maybe we should really take my related
> patch to avoid issues like this one.

I agree, but I'm not a maintainer of the file.

Jan



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

[Xen-devel] [PATCH-for-4.11 v2] xpti: fix bug in double fault handling

[Juergen Gross]

When entering the hypervisor via the double fault handler resetting
xen_cr3 was missing. This led to switching to pv_cr3 when returning
from the next following interrupt. So repair this in order to allow
interrupt handling to work even after a double fault.

Signed-off-by: Juergen Gross 
---
 xen/arch/x86/x86_64/entry.S | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/arch/x86/x86_64/entry.S b/xen/arch/x86/x86_64/entry.S
index 45d9842d09..25427b0cec 100644
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -773,6 +773,7 @@ ENTRY(double_fault)
 neg   %rbx
 .Ldblf_cr3_load:
 mov   %rbx, %cr3
+movq $0, STACK_CPUINFO_FIELD(xen_cr3)(%r14)
 .Ldblf_cr3_okay:
 
 movq  %rsp,%rdi
-- 
2.13.6


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

Re: [Xen-devel] [PATCH-for-4.11] xpti: fix bug in double fault handling

[Juergen Gross]

On 23/04/18 14:11, Jan Beulich wrote:
 On 23.04.18 at 13:37,  wrote:
>> When entering the hypervisor via the double fault handler resetting
>> xen_cr3 was missing. This led to switching to pv_cr3 when returning
>> from the next following interrupt, e.g. after re-enabling interrupts
>> in machine_restart().
> 
> Pointing at bad behavior to justify a change is not very helpful, I think.
> Andrew's argument of exception handling wanting to continue to work
> even after a #DF is a better one imo.

Okay.

> 
>> --- a/tools/firmware/xen-dir/shim.config
>> +++ b/tools/firmware/xen-dir/shim.config
>> @@ -1,6 +1,6 @@
>>  #
>>  # Automatically generated file; DO NOT EDIT.
>> -# Xen/x86 4.11-unstable Configuration
>> +# Xen/x86 4.11-rc Configuration
>>  #
>>  CONFIG_X86_64=y
>>  CONFIG_X86=y
> 
> Stray change?

Oh, that one again. Sorry. Maybe we should really take my related
patch to avoid issues like this one.

> 
>> --- a/xen/arch/x86/x86_64/entry.S
>> +++ b/xen/arch/x86/x86_64/entry.S
>> @@ -772,6 +772,7 @@ ENTRY(double_fault)
>>  jns   .Ldblf_cr3_load
>>  neg   %rbx
>>  .Ldblf_cr3_load:
>> +movq $0, STACK_CPUINFO_FIELD(xen_cr3)(%r14)
>>  mov   %rbx, %cr3
>>  .Ldblf_cr3_okay:
> 
> Just like for the other code paths this write should be after the CR3 load,
> or else NMI or #MC occurring between the two would fail to update CR3.

Aah, right.

Will send V2 soon.


Juergen


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

Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

[Oleksandr Andrushchenko]

On 04/23/2018 02:52 PM, Wei Liu wrote:

On Fri, Apr 20, 2018 at 02:25:20PM +0300, Oleksandr Andrushchenko wrote:

 the gntdev.

I think this is generic enough that it could be implemented by a
device not tied to Xen. AFAICT the hyper_dma guys also wanted
something similar to this.

You can't just wrap random userspace memory into a dma-buf. We've just had
this discussion with kvm/qemu folks, who proposed just that, and after a
bit of discussion they'll now try to have a driver which just wraps a
memfd into a dma-buf.

So, we have to decide either we introduce a new driver
(say, under drivers/xen/xen-dma-buf) or extend the existing
gntdev/balloon to support dma-buf use-cases.

Can anybody from Xen community express their preference here?


Oleksandr talked to me on IRC about this, he said a few IOCTLs need to
be added to either existing drivers or a new driver.

I went through this thread twice and skimmed through the relevant
documents, but I couldn't see any obvious pros and cons for either
approach. So I don't really have an opinion on this.

But, assuming if implemented in existing drivers, those IOCTLs need to
be added to different drivers, which means userspace program needs to
write more code and get more handles, it would be slightly better to
implement a new driver from that perspective.

If gntdev/balloon extension is still considered:

All the IOCTLs will be in gntdev driver (in current xen-zcopy terminology):
 - DRM_ICOTL_XEN_ZCOPY_DUMB_FROM_REFS
 - DRM_IOCTL_XEN_ZCOPY_DUMB_TO_REFS
 - DRM_IOCTL_XEN_ZCOPY_DUMB_WAIT_FREE

Balloon driver extension, which is needed for contiguous/DMA
buffers, will be to provide new *kernel API*, no UAPI is needed.


Wei.

Thank you,
Oleksandr

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

Re: [Xen-devel] [PATCH V2] x86/p2m: fixed p2m_change_type_range() start / end check

[Razvan Cojocaru]

On 04/23/2018 02:47 PM, George Dunlap wrote:
> On 04/18/2018 02:12 PM, Razvan Cojocaru wrote:
>> p2m_change_type_range() handles end > max_mapped_pfn, but not
>> start > max_mapped_pfn. Check the latter just after grabbing the
>> lock and bail if true.
>>
>> Signed-off-by: Razvan Cojocaru 
>> Suggested-by: George Dunlap 
> 
> Sorry, I meant to reply to this earlier but I haven't been able to make
> the time.
> 
> On reflection, I think this is the wrong approach actually.  First, my
> assertion was incorrect: the p2m_altp2m_propagate_change() is gated on
> p2m->max_remapped_gfn, not max_mapped_gfn (nb the 're').  So setting
> max_mapped_gfn shouldn't cause 'unnecessary' propagations.
> 
> Secondly, we do actually need to keep the logdirty ranges of all the
> p2ms in sync, even if they're past the max_remapped_gfn.  Otherwise we
> could have the following situation:
> * altp2m created, max_remapped_gfn 0x1000
> * screen resized, logdirty range [0x2000-0x3000]; change dropped
> * guest accesses 0x4000, max_remapped_gfn set to 0x4000
> * change_p2m_type happens, and the 0x2000-0x3000 range is not marked
> logrdirty #
> 
> So while it would be an improvement to make the assertion more explicit,
> I don't (anymore) think it would actually be an improvement to discard
> changes that are above max_mapped_gfn.  (And thus your original patch,
> which copied max_mapped_gfn into the altp2ms, was probably closer to the
> right approach).
> 
> Sorry for the confusion -- we obviously need a bit more thought about
> how altp2m and logdirty interact.

Thanks for the reply! Fair enough.

FWIW, the attached patch works well for me, resizes and all (but it
could very well be just luck).


Thanks,
Razvan
diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index 14b5939..b1df904 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -17,6 +17,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -656,6 +657,9 @@ bool_t ept_handle_misconfig(uint64_t gpa)
 bool_t spurious;
 int rc;
 
+if ( altp2m_active(curr->domain) )
+p2m = p2m_get_altp2m(curr);
+
 p2m_lock(p2m);
 
 spurious = curr->arch.hvm_vmx.ept_spurious_misconfig;
@@ -1209,32 +1213,60 @@ static void ept_tlb_flush(struct p2m_domain *p2m)
 
 static void ept_enable_pml(struct p2m_domain *p2m)
 {
+unsigned int i;
+struct domain *d = p2m->domain;
+
 /* Domain must have been paused */
-ASSERT(atomic_read(>domain->pause_count));
+ASSERT(atomic_read(>pause_count));
 
 /*
  * No need to return whether vmx_domain_enable_pml has succeeded, as
  * ept_p2m_type_to_flags will do the check, and write protection will be
  * used if PML is not enabled.
  */
-if ( vmx_domain_enable_pml(p2m->domain) )
+if ( vmx_domain_enable_pml(d) )
 return;
 
 /* Enable EPT A/D bit for PML */
 p2m->ept.ad = 1;
-vmx_domain_update_eptp(p2m->domain);
+
+if ( altp2m_active(d) )
+for ( i = 0; i < MAX_ALTP2M; i++ )
+{
+if ( d->arch.altp2m_eptp[i] == mfn_x(INVALID_MFN) )
+continue;
+
+p2m = d->arch.altp2m_p2m[i];
+	p2m->ept.ad = 1;
+}
+
+vmx_domain_update_eptp(d);
 }
 
 static void ept_disable_pml(struct p2m_domain *p2m)
 {
+unsigned int i;
+struct domain *d = p2m->domain;
+
 /* Domain must have been paused */
-ASSERT(atomic_read(>domain->pause_count));
+ASSERT(atomic_read(>pause_count));
 
-vmx_domain_disable_pml(p2m->domain);
+vmx_domain_disable_pml(d);
 
 /* Disable EPT A/D bit */
 p2m->ept.ad = 0;
-vmx_domain_update_eptp(p2m->domain);
+
+if ( altp2m_active(d) )
+for ( i = 0; i < MAX_ALTP2M; i++ )
+{
+if ( d->arch.altp2m_eptp[i] == mfn_x(INVALID_MFN) )
+continue;
+
+p2m = d->arch.altp2m_p2m[i];
+	p2m->ept.ad = 0;
+}
+
+vmx_domain_update_eptp(d);
 }
 
 static void ept_flush_pml_buffers(struct p2m_domain *p2m)
@@ -1375,8 +1407,16 @@ void setup_ept_dump(void)
 void p2m_init_altp2m_ept(struct domain *d, unsigned int i)
 {
 struct p2m_domain *p2m = d->arch.altp2m_p2m[i];
+struct p2m_domain *hostp2m = p2m_get_hostp2m(d);
 struct ept_data *ept;
 
+p2m->max_mapped_pfn = hostp2m->max_mapped_pfn;
+p2m->default_access = hostp2m->default_access;
+p2m->domain = hostp2m->domain;
+p2m->logdirty_ranges = hostp2m->logdirty_ranges;
+p2m->global_logdirty = hostp2m->global_logdirty;
+p2m->ept.ad = hostp2m->ept.ad;
+
 p2m->min_remapped_gfn = gfn_x(INVALID_GFN);
 p2m->max_remapped_gfn = 0;
 ept = >ept;
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index c53cab4..c8f4d8f 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -248,7 +249,6 @@ int p2m_init(struct domain *d)
 int 

Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

[Wei Liu]

On Fri, Apr 20, 2018 at 02:25:20PM +0300, Oleksandr Andrushchenko wrote:
> > > the gntdev.
> > > 
> > > I think this is generic enough that it could be implemented by a
> > > device not tied to Xen. AFAICT the hyper_dma guys also wanted
> > > something similar to this.
> > You can't just wrap random userspace memory into a dma-buf. We've just had
> > this discussion with kvm/qemu folks, who proposed just that, and after a
> > bit of discussion they'll now try to have a driver which just wraps a
> > memfd into a dma-buf.
> So, we have to decide either we introduce a new driver
> (say, under drivers/xen/xen-dma-buf) or extend the existing
> gntdev/balloon to support dma-buf use-cases.
> 
> Can anybody from Xen community express their preference here?
> 

Oleksandr talked to me on IRC about this, he said a few IOCTLs need to
be added to either existing drivers or a new driver.

I went through this thread twice and skimmed through the relevant
documents, but I couldn't see any obvious pros and cons for either
approach. So I don't really have an opinion on this.

But, assuming if implemented in existing drivers, those IOCTLs need to
be added to different drivers, which means userspace program needs to
write more code and get more handles, it would be slightly better to
implement a new driver from that perspective.

Wei.

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

Re: [Xen-devel] [PATCH V2] x86/p2m: fixed p2m_change_type_range() start / end check

[George Dunlap]

On 04/18/2018 02:12 PM, Razvan Cojocaru wrote:
> p2m_change_type_range() handles end > max_mapped_pfn, but not
> start > max_mapped_pfn. Check the latter just after grabbing the
> lock and bail if true.
> 
> Signed-off-by: Razvan Cojocaru 
> Suggested-by: George Dunlap 

Sorry, I meant to reply to this earlier but I haven't been able to make
the time.

On reflection, I think this is the wrong approach actually.  First, my
assertion was incorrect: the p2m_altp2m_propagate_change() is gated on
p2m->max_remapped_gfn, not max_mapped_gfn (nb the 're').  So setting
max_mapped_gfn shouldn't cause 'unnecessary' propagations.

Secondly, we do actually need to keep the logdirty ranges of all the
p2ms in sync, even if they're past the max_remapped_gfn.  Otherwise we
could have the following situation:
* altp2m created, max_remapped_gfn 0x1000
* screen resized, logdirty range [0x2000-0x3000]; change dropped
* guest accesses 0x4000, max_remapped_gfn set to 0x4000
* change_p2m_type happens, and the 0x2000-0x3000 range is not marked
logrdirty #

So while it would be an improvement to make the assertion more explicit,
I don't (anymore) think it would actually be an improvement to discard
changes that are above max_mapped_gfn.  (And thus your original patch,
which copied max_mapped_gfn into the altp2ms, was probably closer to the
right approach).

Sorry for the confusion -- we obviously need a bit more thought about
how altp2m and logdirty interact.

 -George

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

Re: [Xen-devel] [PATCH v2 10/10] xen/arm: Call check_local_cpu_errata for secondary CPU only on boot

[Julien Grall]

Hi,

On 20/04/18 13:25, Mirela Simonovic wrote:

Checking CPU errata should be done only when a CPU is initially booted.
It is assumed that the CPU which is hotplugged after the system/Xen boots,
was initially hotplugged during the system/Xen boot, so errata is checked
by each CPU only once, on boot.


It is a good idea to document the assumption in the code. This will help 
to know what is missing for other use case.




Signed-off-by: Mirela Simonovic 

---
CC: Stefano Stabellini 
CC: Julien Grall 
---
  xen/arch/arm/smpboot.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index d01b51592d..5d6c6cadec 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -366,8 +366,8 @@ void start_secondary(unsigned long boot_phys_offset,
  
  if ( system_state != SYS_STATE_boot )

  setup_virt_paging_secondary();
-
-check_local_cpu_errata();
+else
+check_local_cpu_errata();


No, check_local_cpu_errata should be called for everyone. This check 
should be moved in the function with a TODO explaining what needs to be 
done. Likely this will be go over the CPU errata and see if there are 
any issue with the one currently selected.


Also, I just realized that any "cpu capability" (e.g spectre workaround) 
 that requires to be enabled will not be done on hotplugged CPU. You 
likely need to implement a version of enable_errata_workaround for them.


Cheers,

  
  printk(XENLOG_DEBUG "CPU %u booted.\n", smp_processor_id());
  



--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 09/10] xen/arm: Free memory allocated for sibling/core maps on CPU hot-unplug

[Julien Grall]

Hi,

On 20/04/18 13:25, Mirela Simonovic wrote:

The memory allocated in setup_cpu_sibling_map() when a CPU is hotplugged
has to be freed when the CPU is hot-unplugged. This is done in
remove_cpu_sibling_map() and called from __cpu_disable() on CPU hot-unplug.

Signed-off-by: Mirela Simonovic 

---
CC: Stefano Stabellini 
CC: Julien Grall 
---
  xen/arch/arm/smpboot.c | 8 
  1 file changed, 8 insertions(+)

diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index b4ed479dc6..d01b51592d 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -89,6 +89,12 @@ static void setup_cpu_sibling_map(int cpu)
  cpumask_set_cpu(cpu, per_cpu(cpu_core_mask, cpu));
  }
  
+static void remove_cpu_sibling_map(int cpu)

+{
+free_cpumask_var(per_cpu(cpu_sibling_mask, cpu));
+free_cpumask_var(per_cpu(cpu_core_mask, cpu));
+}
+
  void __init
  smp_clear_cpu_maps (void)
  {
@@ -391,6 +397,8 @@ void __cpu_disable(void)
  /* It's now safe to remove this processor from the online map */
  cpumask_clear_cpu(cpu, _online_map);
  
+remove_cpu_sibling_map(cpu);


I don't think this is the right place. Those cpumask might be used by 
the scheduler. So you want to free them only when the scheduler has been 
disabled.


Looking at x86, they will free them when the CPU is completely dead (see 
cpu_smpboot_callback). So I think a notifier would be the solution for 
arm as well.


Cheers,


+
  if ( cpu_disable_scheduler(cpu) )
  BUG();
  smp_mb();



--
Julien Grall

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

[Xen-devel] [PATCH-for-4.11] xpti: fix bug in double fault handling

[Juergen Gross]

When entering the hypervisor via the double fault handler resetting
xen_cr3 was missing. This led to switching to pv_cr3 when returning
from the next following interrupt, e.g. after re-enabling interrupts
in machine_restart().

Signed-off-by: Juergen Gross 
---
 tools/firmware/xen-dir/shim.config | 2 +-
 xen/arch/x86/x86_64/entry.S| 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/firmware/xen-dir/shim.config 
b/tools/firmware/xen-dir/shim.config
index 4d5630f87a..0b9e001436 100644
--- a/tools/firmware/xen-dir/shim.config
+++ b/tools/firmware/xen-dir/shim.config
@@ -1,6 +1,6 @@
 #
 # Automatically generated file; DO NOT EDIT.
-# Xen/x86 4.11-unstable Configuration
+# Xen/x86 4.11-rc Configuration
 #
 CONFIG_X86_64=y
 CONFIG_X86=y
diff --git a/xen/arch/x86/x86_64/entry.S b/xen/arch/x86/x86_64/entry.S
index 45d9842d09..d12fbcb55d 100644
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -772,6 +772,7 @@ ENTRY(double_fault)
 jns   .Ldblf_cr3_load
 neg   %rbx
 .Ldblf_cr3_load:
+movq $0, STACK_CPUINFO_FIELD(xen_cr3)(%r14)
 mov   %rbx, %cr3
 .Ldblf_cr3_okay:
 
-- 
2.13.6


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

Re: [Xen-devel] [PATCH v2 07/10] xen/arm: Release maintenance interrupt when CPU is hot-unplugged

[Julien Grall]

Hi Mirela,

On 20/04/18 13:25, Mirela Simonovic wrote:

When a CPU is hot-unplugged the maintenance interrupt has to be
released in order to free the memory that was allocated when the CPU
was hotplugged and interrupt requested. The interrupt was requested
using request_irq() which is called from start_secondary->
init_maintenance_interrupt.

Signed-off-by: Mirela Simonovic 

---
CC: Stefano Stabellini 
CC: Julien Grall 
---
  xen/arch/arm/gic.c| 5 +
  xen/arch/arm/smpboot.c| 7 +++
  xen/include/asm-arm/gic.h | 1 +
  3 files changed, 13 insertions(+)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 653a815127..e536b99e84 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -431,6 +431,11 @@ void init_maintenance_interrupt(void)
  "irq-maintenance", NULL);
  }
  
+void deinit_maintenance_interrupt(void)

+{
+release_irq(gic_hw_ops->info->maintenance_irq, NULL);
+}
+
  int gic_make_hwdom_dt_node(const struct domain *d,
 const struct dt_device_node *gic,
 void *fdt)
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index abc642804f..449fefc77d 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -375,11 +375,18 @@ void __cpu_disable(void)
  
  local_irq_disable();

  gic_disable_cpu();
+


Spurious change.


  /* Allow any queued timer interrupts to get serviced */
  local_irq_enable();
  mdelay(1);
  local_irq_disable();
  
+/*

+ * Deinitialize interrupts (this will free the memory that was allocated
+ * in respective init interrupt functions called from start_secondary)
+ */
+deinit_maintenance_interrupt();


Can you have a look at using a notifier (see CPU_DIYING)? This would 
avoid exporting too much new function.



+
  /* It's now safe to remove this processor from the online map */
  cpumask_clear_cpu(cpu, _online_map);
  
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h

index 58b910fe6a..0db42e6cce 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -254,6 +254,7 @@ extern void gic_clear_pending_irqs(struct vcpu *v);
  extern int vgic_vcpu_pending_irq(struct vcpu *v);
  
  extern void init_maintenance_interrupt(void);

+extern void deinit_maintenance_interrupt(void);
  extern void gic_raise_guest_irq(struct vcpu *v, unsigned int irq,
  unsigned int priority);
  extern void gic_raise_inflight_irq(struct vcpu *v, unsigned int virtual_irq);



Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 05/10] xen/arm: Setup virtual paging for non-boot CPUs on hotplug/resume

[Julien Grall]

Hi Mirela,

On 20/04/18 13:25, Mirela Simonovic wrote:

In existing code the paging for non-boot CPUs is setup only on boot. The
setup is triggered from start_xen() after all CPUs are brought online.
In other words, the initialization of VTCR_EL2 register is done out of the
cpu_up/start_secondary() control flow. However, the cpu_up flow is also used
to hotplug non-boot CPUs on resume from suspend to RAM state, in which case
the virtual paging will not be configured.
With this patch the setting of paging is triggered from start_secondary()
function if the current system state is not boot. This way, the paging
for secondary CPUs will be setup in non-boot scenarios as well, while the
setup in boot scenario remains unchanged.
It is assumed here that after the system completed the boot, CPUs that
execute start_secondary() were booted as well when the Xen itself was
booted. According to this assumption non-boot CPUs will always be compliant
with the VTCR_EL2 value that was selected by Xen on boot.
Currently, these in no mechanism to trigger hotplugging of a CPU. This
will be added with the suspend to RAM support for ARM, where the hotplug
of non-boot CPUs will be triggered via enable_nonboot_cpus() call.

Signed-off-by: Mirela Simonovic 

---
CC: Stefano Stabellini 
CC: Julien Grall 
---
Changes in v2:
-Fix commit message
-Save configured VTCR_EL2 value into static variable that will be used
  by non-boot CPUs on hotplug
-Add setup_virt_paging_secondary() and invoke it from start_secondary()
  if that CPU has to setup virtual paging (if the system state is not boot)
---
  xen/arch/arm/p2m.c| 13 -
  xen/arch/arm/smpboot.c|  3 +++
  xen/include/asm-arm/p2m.h |  3 +++
  3 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index d43c3aa896..9bb62c13cd 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1451,13 +1451,21 @@ err:
  return page;
  }
  
-static void __init setup_virt_paging_one(void *data)

+static void setup_virt_paging_one(void *data)
  {
  unsigned long val = (unsigned long)data;
  WRITE_SYSREG32(val, VTCR_EL2);
  isb();
  }
  
+/* VTCR value to be configured by all CPUs. Set only once by the boot CPU */

+static unsigned long __read_mostly vtcr_value;


VTCR is a register, so the type should be represented in term of bits 
(i.e uint*_t).



+
+void setup_virt_paging_secondary(void)
+{
+setup_virt_paging_one((void *)vtcr_value);


That's fairly ugly. Is there any way to rework the interface? For 
instance, because you have a static variable which contain the VTCR, you 
could just use the variable in setup_virt_paging one.



+}
+
  void __init setup_virt_paging(void)
  {
  /* Setup Stage 2 address translation */
@@ -1540,6 +1548,9 @@ void __init setup_virt_paging(void)
  BUG_ON( P2M_ROOT_LEVEL == 0 && P2M_ROOT_ORDER > 0 );
  setup_virt_paging_one((void *)val);
  smp_call_function(setup_virt_paging_one, (void *)val, 1);
+
+/* Save configured value (to be used later for secondary CPUs hotplug) */
+vtcr_value = val;
  }
  
  /*

diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index 38b665a6d2..abc642804f 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -358,6 +358,9 @@ void start_secondary(unsigned long boot_phys_offset,
  local_irq_enable();
  local_abort_enable();
  
+if ( system_state != SYS_STATE_boot )

+setup_virt_paging_secondary();
I think this code needs some documentation. So people understand why you 
only call setup_virt_paging_secondary() after boot. But is there any 
reason to not use a notifier (see notify_cpu_starting)? This would avoid 
yet another export.



+
  check_local_cpu_errata();
  
  printk(XENLOG_DEBUG "CPU %u booted.\n", smp_processor_id());

diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index 8823707c17..85b66a1196 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -153,6 +153,9 @@ void p2m_altp2m_check(struct vcpu *v, uint16_t idx)
  /* Second stage paging setup, to be called on all CPUs */
  void setup_virt_paging(void);
  
+/* To be called by secondary CPU on hotplug */

+void setup_virt_paging_secondary(void);
+
  /* Init the datastructures for later use by the p2m code */
  int p2m_init(struct domain *d);
  



Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 04/10] xen/arm: Remove __initdata and __init to enable CPU hotplug

[Julien Grall]

Hi Mirela,

On 20/04/18 13:25, Mirela Simonovic wrote:

CPU up flow is currently used during the initial boot to start secondary
CPUs. However, the same flow should be used for CPU hotplug, e.g. when
hotplugging secondary CPUs within the resume procedure (resume from the
suspend to RAM). Therefore, prefixes __initdata and __init had to be removed
from few data structures and functions that are used within the cpu up flow.

Signed-off-by: Mirela Simonovic 


Acked-by: Julien Grall 

Cheers,



---
CC: Stefano Stabellini 
CC: Julien Grall 
---
  xen/arch/arm/arm64/smpboot.c   | 2 +-
  xen/arch/arm/irq.c | 2 +-
  xen/arch/arm/processor.c   | 2 +-
  xen/arch/arm/smpboot.c | 4 ++--
  xen/include/asm-arm/procinfo.h | 4 ++--
  5 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/arm64/smpboot.c b/xen/arch/arm/arm64/smpboot.c
index 4fd0ac68b7..694fbf67e6 100644
--- a/xen/arch/arm/arm64/smpboot.c
+++ b/xen/arch/arm/arm64/smpboot.c
@@ -104,7 +104,7 @@ int __init arch_cpu_init(int cpu, struct dt_device_node *dn)
  return smp_psci_init(cpu);
  }
  
-int __init arch_cpu_up(int cpu)

+int arch_cpu_up(int cpu)
  {
  if ( !smp_enable_ops[cpu].prepare_cpu )
  return -ENODEV;
diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index aa4e832cae..098281f8ab 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -65,7 +65,7 @@ irq_desc_t *__irq_to_desc(int irq)
  return _desc[irq-NR_LOCAL_IRQS];
  }
  
-int __init arch_init_one_irq_desc(struct irq_desc *desc)

+int arch_init_one_irq_desc(struct irq_desc *desc)
  {
  desc->arch.type = IRQ_TYPE_INVALID;
  return 0;
diff --git a/xen/arch/arm/processor.c b/xen/arch/arm/processor.c
index ce4385064a..acad8b31d6 100644
--- a/xen/arch/arm/processor.c
+++ b/xen/arch/arm/processor.c
@@ -20,7 +20,7 @@
  
  static DEFINE_PER_CPU(struct processor *, processor);
  
-void __init processor_setup(void)

+void processor_setup(void)
  {
  const struct proc_info_list *procinfo;
  
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c

index 1ca3d63261..38b665a6d2 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -52,8 +52,8 @@ nodemask_t __read_mostly node_online_map = { { [0] = 1UL } };
  static unsigned char __initdata cpu0_boot_stack[STACK_SIZE]
 __attribute__((__aligned__(STACK_SIZE)));
  
-/* Initial boot cpu data */

-struct init_info __initdata init_data =
+/* Boot cpu data */
+struct init_info init_data =
  {
  .stack = cpu0_boot_stack,
  };
diff --git a/xen/include/asm-arm/procinfo.h b/xen/include/asm-arm/procinfo.h
index 26306b35f8..02be56e348 100644
--- a/xen/include/asm-arm/procinfo.h
+++ b/xen/include/asm-arm/procinfo.h
@@ -35,9 +35,9 @@ struct proc_info_list {
  struct processor*processor;
  };
  
-const __init struct proc_info_list *lookup_processor_type(void);

+const struct proc_info_list *lookup_processor_type(void);
  
-void __init processor_setup(void);

+void processor_setup(void);
  void processor_vcpu_initialise(struct vcpu *v);
  
  #endif




--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 03/10] xen/arm: Implement CPU_OFF PSCI call (physical interface)

[Julien Grall]

Hi Mirela,

On 20/04/18 13:25, Mirela Simonovic wrote:

During the system suspend to RAM non-boot CPUs will be hotplugged.
This will be triggered via disable_nonboot_cpus() call. When
hotplugged the CPU will end up in an infinite wfi loop in stop_cpu().
This patch adds PSCI CPU_OFF call to the EL3 with the aim to get powered
down the calling CPU during the suspend.
If PSCI CPU_OFF call to the EL3 succeeds it will not return. Otherwise,
when the PSCI CPU_OFF call returns we'll raise panic, because the calling
CPU could be enabled afterwards.
If a CPU executes stop_cpu() when the system is not suspending the
calling CPU will loop in the infinite while/wfi, as it was looping
before this change.
Note that there is no check for PSCI version in PSCI CPU_OFF
implementation because the version will be checked prior to triggering
the system suspend.


Then the code should contain an ASSERT + comment to make it clear on the 
interface. But I don't think this is the right way to go (see below).




Signed-off-by: Mirela Simonovic 

---
CC: Stefano Stabellini 
CC: Julien Grall 
---
Changes in v2:
-Issue PSCI CPU_OFF only if the system is suspending
-If PSCI CPU_OFF call fails (unlikely to ever happen) raise panic
-Fixed commit message
---
  xen/arch/arm/psci.c| 11 +++
  xen/arch/arm/smpboot.c |  3 +++
  xen/include/asm-arm/psci.h |  1 +
  3 files changed, 15 insertions(+)

diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c
index 94b616df9b..7f7b0695a3 100644
--- a/xen/arch/arm/psci.c
+++ b/xen/arch/arm/psci.c
@@ -46,6 +46,17 @@ int call_psci_cpu_on(int cpu)
  return call_smc(psci_cpu_on_nr, cpu_logical_map(cpu), 
__pa(init_secondary), 0);
  }
  
+void call_psci_cpu_off(void)

+{
+int errno;
+
+/* If successfull the PSCI cpu_off call doesn't return */
+errno = call_smc(PSCI_0_2_FN32_CPU_OFF, 0, 0, 0);


CPU_OFF will only return on error. So the if is not necessary below.


+if ( errno )
+panic("PSCI cpu off failed for CPU%d err=%d\n", get_processor_id(),
+  errno);
+}
+
  void call_psci_system_off(void)
  {
  if ( psci_ver > PSCI_VERSION(0, 1) )
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index b2116f0d2d..1ca3d63261 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -395,6 +395,9 @@ void stop_cpu(void)
  /* Make sure the write happens before we sleep forever */
  dsb(sy);
  isb();
+if ( system_state == SYS_STATE_suspend )


I don't think this should be call only on suspend/resume. System 
shutdown could also benefit of PSCI CPU off. This is also paving the way 
to more use case of turning off a CPU.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 02/10] xen/arm: Ignore write to GICD_ISACTIVERn registers (vgic-v2)

[Julien Grall]

Hi Mirela,

On 20/04/18 13:25, Mirela Simonovic wrote:

Guests attempt to write into these registers on resume (for example Linux).
Without this patch a data abort exception will be raised to the guest.
This patch handles the write access by ignoring it, but only if the value
to be written is zero. This should be fine because reading these registers
is already handled as 'read as zero'.

Signed-off-by: Mirela Simonovic 

---
CC: Stefano Stabellini 
CC: Julien Grall 
---
Changes in v2:
- Write should be ignored only if the value to be written is zero
  (in v1 the write was ignored regardless of the value)
---
  xen/arch/arm/vgic-v2.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/vgic-v2.c b/xen/arch/arm/vgic-v2.c
index 646d1f3d12..afd3e89883 100644
--- a/xen/arch/arm/vgic-v2.c
+++ b/xen/arch/arm/vgic-v2.c
@@ -488,7 +488,9 @@ static int vgic_v2_distr_mmio_write(struct vcpu *v, 
mmio_info_t *info,
  printk(XENLOG_G_ERR
 "%pv: vGICD: unhandled word write %#"PRIregister" to 
ISACTIVER%d\n",
 v, r, gicd_reg - GICD_ISACTIVER);
-return 0;
+if ( r != 0 )
+return 0;


It would be better to move the check before the printk. So a warning is 
avoided when the guest is writing 0.


Cheers,


+goto write_ignore_32;
  
  case VRANGE32(GICD_ICACTIVER, GICD_ICACTIVERN):

  printk(XENLOG_G_ERR



Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 01/10] xen/arm64: Added handling of the trapped access to OSLSR register

[Julien Grall]

Hi Mirela,

On 20/04/18 13:25, Mirela Simonovic wrote:

Linux/dom0 accesses OSLSR register when saving CPU context during the
suspend procedure. Xen traps access to this register, but has no handling
for it. Consequently, Xen injects undef exception to linux, causing it to
crash. This patch adds handling of the trapped access to OSLSR as ro/raz.

Signed-off-by: Mirela Simonovic 
Reviewed-by: Stefano Stabellini 


Acked-by: Julien Grall 

Cheers,



---
CC: Stefano Stabellini 
CC: Julien Grall 
---
Changes in v2:
- Commit message fix (arm64 related change instead of arm)
- Add Stefano's reviewed-by
---
  xen/arch/arm/arm64/vsysreg.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/arm64/vsysreg.c b/xen/arch/arm/arm64/vsysreg.c
index c57ac12503..8f80e1735e 100644
--- a/xen/arch/arm/arm64/vsysreg.c
+++ b/xen/arch/arm/arm64/vsysreg.c
@@ -57,13 +57,14 @@ void do_sysreg(struct cpu_user_regs *regs,
   * ARMv8 (DDI 0487A.d): D1-1509 Table D1-58
   *
   * Unhandled:
- *OSLSR_EL1
   *DBGPRCR_EL1
   */
  case HSR_SYSREG_OSLAR_EL1:
  return handle_wo_wi(regs, regidx, hsr.sysreg.read, hsr, 1);
  case HSR_SYSREG_OSDLR_EL1:
  return handle_raz_wi(regs, regidx, hsr.sysreg.read, hsr, 1);
+case HSR_SYSREG_OSLSR_EL1:
+return handle_ro_raz(regs, regidx, hsr.sysreg.read, hsr, 1);
  
  /*

   * MDCR_EL2.TDA



--
Julien Grall

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

Re: [Xen-devel] osstest outage,

[Ian Jackson]

The work is complete and a test job seems to have gone well.  I have
therefore un-stopped it.  The Xen Project osstest is now operational
and will start picking up work from the staging branches.

Please let me know if you spot anything untoward.

Ian.

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

Re: [Xen-devel] RFC Xen signature verification for kexec

[Jan Beulich]

>>> On 23.04.18 at 12:25,  wrote:
> On Mon, Apr 23, 2018 at 12:55:45AM -0600, Jan Beulich wrote:
>> >>> On 20.04.18 at 21:12,  wrote:
>> > Two options for signature verification in Xen
>> >
>> > This proposal outlines two options under consideration for enhancing
>> > Xen to support signature verification of kexec loaded images. The
>> > first option is essentially to mirror Linux signature verification
>> > code into Xen. The second option utilizes components from sources
>> > other than Linux (for example, libgcrypt rather than linux/crypto).
>> >
>> > NOTE: An option to utilize dom0 kernel signature verification does not
>> > prevent the exploit as user space can invoke the hypercall directly,
>> > bypassing dom0.
>>
>> Not exactly - this option nevertheless exists, albeit is perhaps
>> unattractive: No user space component can issue hypercalls
>> directly, they always go through the privcmd driver. Hence the
>> driver cold snoop the kexec hypercall.
> 
> Hmmm... Is not it a problem from security point of view for us in this
> case? It should not if dom0 kernel is signed. It have to be signed here.
> Just thinking a loud...

I'm afraid I don't understand: If the Dom0 kernel isn't signed (or hasn't
been verified), the system is insecure in the first place. No reason to
bother measuring the kexec kernel then.

>> > #
>> > Option 2: Enable signature verification in Xen utilizing libgcrypt
>> >
>> > This option is similar to Option 1, but utilizes libgcrypt
>> > crytpo library rather than linux/crypto files.
>> >
>> > Pros:
>> > - Libgcrypt is LGPLv2.1+ license.
>> > - Eliminates problematic scenario of tracking changes to
>> >linux/crypto sources in Xen, and vice versa in Linux.
>>
>> As an initial reaction, of the two options presented I'd prefer this
>> 2nd one, for this specific reason.
>>
>> > Cons:
>> > - Introduces a dependency on libgcrypt
>> > - Still relying on lifting many Linux kernel sources for PE file
>> >handling, certificate handling, etc. However, an alternative
>> >source for PE file handling is shim.
>>
>> That's under the assumption that PE files are the only containers usable
>> to carry certificates, which I consider odd, not the least because Linux
>> kernel modules aren't PE either. If the kernel was carrying its certificate
> 
> I do not think that we care about kernel modules format here...

This was just meant to give an example of a case where PE is not required
for carrying certificates.

Jan



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

Re: [Xen-devel] RFC Xen signature verification for kexec

[Daniel Kiper]

On Mon, Apr 23, 2018 at 12:55:45AM -0600, Jan Beulich wrote:
> >>> On 20.04.18 at 21:12,  wrote:
> > Two options for signature verification in Xen
> >
> > This proposal outlines two options under consideration for enhancing
> > Xen to support signature verification of kexec loaded images. The
> > first option is essentially to mirror Linux signature verification
> > code into Xen. The second option utilizes components from sources
> > other than Linux (for example, libgcrypt rather than linux/crypto).
> >
> > NOTE: An option to utilize dom0 kernel signature verification does not
> > prevent the exploit as user space can invoke the hypercall directly,
> > bypassing dom0.
>
> Not exactly - this option nevertheless exists, albeit is perhaps
> unattractive: No user space component can issue hypercalls
> directly, they always go through the privcmd driver. Hence the
> driver cold snoop the kexec hypercall.

Hmmm... Is not it a problem from security point of view for us in this
case? It should not if dom0 kernel is signed. It have to be signed here.
Just thinking a loud...

> > #
> > Option 2: Enable signature verification in Xen utilizing libgcrypt
> >
> > This option is similar to Option 1, but utilizes libgcrypt
> > crytpo library rather than linux/crypto files.
> >
> > Pros:
> > - Libgcrypt is LGPLv2.1+ license.
> > - Eliminates problematic scenario of tracking changes to
> >linux/crypto sources in Xen, and vice versa in Linux.
>
> As an initial reaction, of the two options presented I'd prefer this
> 2nd one, for this specific reason.
>
> > Cons:
> > - Introduces a dependency on libgcrypt
> > - Still relying on lifting many Linux kernel sources for PE file
> >handling, certificate handling, etc. However, an alternative
> >source for PE file handling is shim.
>
> That's under the assumption that PE files are the only containers usable
> to carry certificates, which I consider odd, not the least because Linux
> kernel modules aren't PE either. If the kernel was carrying its certificate

I do not think that we care about kernel modules format here...

> in a way (also) accessible without parsing PE structures, this dependency
> could be dropped.

IIRC kexec-tools feeds one file with signature attached into Linux
kernel via syscall. It does not support detached signatures. Does it?
Eric, could you check it? If it does not then we have to add some
code into kexec-tools too. However, I do not think that gain in Xen
code will be significant. PE file parsing in this case should be simple.
The largest part still would be PKCS#7 and/or PEM parser. Hmmm...
There is a chance that there is a lib floating around which does that.
Eric, please double check it.

Daniel

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

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

[Wei Liu]

On Mon, Apr 23, 2018 at 11:00:50AM +0300, Alexandru Isaila wrote:
> This patch is adding a way to enable/disable inguest pagefault
> events. It introduces the xc_monitor_inguest_pagefault function
> and adds the inguest_pagefault_disabled in the monitor structure.
> This is needed by the introspection so it will only get gla
> faults and not get spammed with other faults.
> In p2m_mem_access_check() we emulate so no event will get sent.
> 
> Signed-off-by: Alexandru Isaila 
> 
> ---
> Changes since V4:
>   - Added the hvm_emulate_one_vm_event() call in
> p2m_mem_access_check()
> - Removed p2m_set_ad_bits().
> ---
>  tools/libxc/include/xenctrl.h |  2 ++
>  tools/libxc/xc_monitor.c  | 14 ++

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH 2/3] xen netback: add fault injection facility

[Wei Liu]

On Fri, Apr 20, 2018 at 10:47:31AM +, Stanislav Kinsburskii wrote:
>  
>  #include 
>  #include 
> @@ -1649,6 +1650,7 @@ static int __init netback_init(void)
>   PTR_ERR(xen_netback_dbg_root));
>  #endif /* CONFIG_DEBUG_FS */
>  
> + (void) xen_netbk_fi_init();

If you care about the return value, please propagate it to
netback_init's caller. Otherwise you can just make the function return
void.

> +
> +int xenvif_fi_init(struct xenvif *vif)
> +{
> + struct dentry *parent;
> + struct xenvif_fi *vfi;
> + int fi, err = -ENOMEM;
> +
> + parent = vif_fi_dir;
> + if (!parent)
> + return -ENOMEM;
> +
> + vfi = kmalloc(sizeof(*vfi), GFP_KERNEL);
> + if (!vfi)
> + return -ENOMEM;
> +
> + vfi->dir = debugfs_create_dir(vif->dev->name, parent);
> + if (!vfi->dir)
> + goto err_dir;
> +
> + for (fi = 0; fi < XENVIF_FI_MAX; fi++) {
> + vfi->faults[fi] = xen_fi_dir_add(vfi->dir,
> + xenvif_fi_names[fi]);
> + if (!vfi->faults[fi])
> + goto err_fault;
> + }
> +
> + vif->fi_info = vfi;
> + return 0;
> +
> +err_fault:
> + for (; fi > 0; fi--)

fi >= 0

Wei.

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

[Xen-devel] [distros-debian-sid test] 74636: tolerable FAIL

[Platform Team regression test user]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-i386-i386-sid-netboot-pvgrub 10 debian-di-install   fail like 74625
 test-armhf-armhf-armhf-sid-netboot-pygrub 10 debian-di-install fail like 74625
 test-amd64-i386-amd64-sid-netboot-pygrub 10 debian-di-install  fail like 74625
 test-amd64-amd64-amd64-sid-netboot-pvgrub 10 debian-di-install fail like 74625
 test-amd64-amd64-i386-sid-netboot-pygrub 10 debian-di-install  fail like 74625

baseline version:
 flight   74625

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-sid-netboot-pvgrubfail
 test-amd64-i386-i386-sid-netboot-pvgrub  fail
 test-amd64-i386-amd64-sid-netboot-pygrub fail
 test-armhf-armhf-armhf-sid-netboot-pygrubfail
 test-amd64-amd64-i386-sid-netboot-pygrub fail



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

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

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


Push not applicable.


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

Re: [Xen-devel] [RFC v2 7/9] libxl_qmp: Implement query-status command

[Wei Liu]

On Mon, Apr 16, 2018 at 06:32:25PM +0100, Anthony PERARD wrote:
> It check via QMP if QEMU as reach the intended status.

Some typos.

"... checks ... if QEMU has reached ..."

> 
> Signed-off-by: Anthony PERARD 
> ---
>  tools/libxl/libxl_internal.h |  3 +++
>  tools/libxl/libxl_qmp.c  | 39 
>  2 files changed, 42 insertions(+)
> 
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 6352380644..3764d26463 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -1857,6 +1857,9 @@ _hidden int libxl__qmp_nbd_server_stop(libxl__gc *gc, 
> int domid);
>  _hidden int libxl__qmp_x_blockdev_change(libxl__gc *gc, int domid,
>   const char *parant,
>   const char *child, const char 
> *node);
> +_hidden int libxl__qmp_query_status(libxl__gc *gc,
> +int domid,
> +const char *intended_status);
>  /* run a hmp command in qmp mode */
>  _hidden int libxl__qmp_hmp(libxl__gc *gc, int domid, const char 
> *command_line,
> char **out);
> diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
> index 3bb0f28bea..83bd804219 100644
> --- a/tools/libxl/libxl_qmp.c
> +++ b/tools/libxl/libxl_qmp.c
> @@ -1246,6 +1246,45 @@ int libxl__qmp_x_blockdev_change(libxl__gc *gc, int 
> domid, const char *parent,
>  return qmp_run_command(gc, domid, "x-blockdev-change", args, NULL, NULL);
>  }
>  
> +static int qmp_check_status(libxl__qmp_handler *qmp,
> +const libxl__json_object *response,
> +void *opaque)
> +{
> +char **status = opaque;
> +GC_INIT(qmp->ctx);
> +const libxl__json_object *o;
> +
> +o = libxl__json_map_get("status", response, JSON_STRING);
> +if (!o)
> +return 1;
> +*status = libxl__strdup(gc, libxl__json_object_get_string(o));

Missing GC_FREE in the exit paths.

The rest looks OK.

Wei.

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

Re: [Xen-devel] [RFC v2 5/9] libxl: Learned to send FD through QMP to QEMU

[Wei Liu]

On Mon, Apr 16, 2018 at 06:32:23PM +0100, Anthony PERARD wrote:
> Adding the ability to send a file descriptor from libxl to QEMU via the
> QMP interface. This will be use with the "add-fd" QMP command.
> 
> Signed-off-by: Anthony PERARD 
> ---

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v3] shim: don't let build modify shim.config

[Wei Liu]

On Fri, Apr 20, 2018 at 05:47:55PM +0200, Juergen Gross wrote:
> Currently building the shim will modify shim.config in case some config
> option was added or modified in the hypervisor.
> 
> Avoid that by copying shim.config to an intermediate file instead.
> 
> Signed-off-by: Juergen Gross 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v2 for-4.11] libxl: fix memory map reported to PVH guests

[Wei Liu]

On Fri, Apr 20, 2018 at 03:57:19PM +0100, Roger Pau Monne wrote:
> PVH guests with 4GB of RAM or more get a memory map like the
> following:
> 
> 0x00 - 0x00fee0 RAM
> 0x00fee0 - 0x01 RESERVED
> 0x00fc009000 - 0x00fc009040 ACPI
> 0x00fc00 - 0x00fc001000 ACPI
> 0x00fc001000 - 0x00fc009000 ACPI
> 0x01 - 0x01fb200400 RAM
> 
> This is wrong because ACPI regions overlap with RAM regions. The cause
> of this issue is not setting a big enough MMIO hole and marking the
> whole MMIO hole as reserved, when it actually contains several pieces:
> 
>  - local APIC page.
>  - ACPI tables.
>  - HVM special pages.
> 
> Of those items only HVM special pages need to be marked as reserved in
> order to advise the guest against using them for example for memory
> hotplug.
> 
> After the fix the layout reported for the same guest is:
> 
> 0x00 - 0x00fc00 RAM
> 0x00feff8000 - 0x00ff00 RESERVED
> 0x00fc009000 - 0x00fc009040 ACPI
> 0x00fc00 - 0x00fc001000 ACPI
> 0x00fc001000 - 0x00fc009000 ACPI
> 0x01 - 0x01fe000400 RAM
> 
> Signed-off-by: Roger Pau Monné 


Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v2] Input: xen-kbdfront - allow better run-time configuration

[Oleksandr Andrushchenko]

On 04/23/2018 11:23 AM, Juergen Gross wrote:

On 23/04/18 10:02, Oleksandr Andrushchenko wrote:

Juergen, Jason, Dmitry
any comment on this?

Oleksandr, please give us some time. I can't speak for others, but I am
not sitting here idling and hoping that some work (e.g. patches to
review) might appear.

I have a lot of other stuff to do and will respond when I find some time
to look at your patches.

Pinging others on Monday when having sent out the patch only on Thursday
is rather unfriendly.

Really sorry about this, my bad.
I had an impression that the only change we need to
discuss was uint -> bool change which seemed rather trivial


Juergen



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

Re: [Xen-devel] Setting up a call to discuss PCI Emulation - Future Direction

[Lars Kurth]

Hi all,
so it seems we have no perfect slot proposals, but 2 semi-perfect.
May 2nd: 16:00 - 17:00 Christopher can't attend
May 2nd: 17:00 - 18:00 Chao can't attend
Maybe a compromise would be 16:30 to 17:30
Regards
Lars

On 21/04/2018, 05:47, "Alexey G"  wrote:

On Fri, 13 Apr 2018 11:01:49 +0100
Roger Pau Monné  wrote:

>On Thu, Apr 12, 2018 at 05:50:00PM +0100, Lars Kurth wrote:
>> 
>> 
>> On 12/04/2018, 17:41, "Roger Pau Monne" 
>> wrote:
>> 
>> On Thu, Apr 12, 2018 at 05:32:57PM +0100, Lars Kurth wrote:
>> 
>>   
>> >may work. For me Mon, Wed and Fri’s generally work at those
>> > time-slots. Next week is a little busy for me, so I would
>> > prefer the following week. If you could fill out the following
>> > Google poll, if this week works that would be great. Otherwise
>> > please scream.  
>> 
>> I'm afraid I'm on vacations from the 21st to the 29th of April,
>> so I won't be able to join the meeting unless we move it to the week
>> after. Let's see what people think of the current dates.
>> 
>> Roger.
>> 
>> Hi, I changed the dates to the week after. Poll so far has been
>> invalidated.
>> 
>> See https://doodle.com/poll/gdnmcrvnibmw563n  
>
>Thanks! I've already fixed my vote.
>
>I guess this will come later, but we need a clear agenda of items
>because the x86 and ARM topics are probably going to be completely
>different (albeit all related to PCI).
>
>Roger.

1. different approaches to handle some critical chipset-specific
   registers (MCH PCIEXBAR first of all), currently emulated by
   QEMU. Role of QEMU in the emulation of MMCONFIG accesses.

2. MMIO hole sizing in general (for HVM) -- in which PT usecases this is
   needed, requirements, limitations. It is related to the emulated
   chipset-specific resources and depends on the chosen solution for #1.

I'll try to describe different possible implementations how to make the
multiple PCI device emulators feature compatible with emulated MMCONFIG
before the meeting, to have a ground for discussion. There are at least
3 possible directions currently to solve this problem.


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

Re: [Xen-devel] [PATCH v2] Input: xen-kbdfront - allow better run-time configuration

[Juergen Gross]

On 23/04/18 10:02, Oleksandr Andrushchenko wrote:
> Juergen, Jason, Dmitry
> any comment on this?

Oleksandr, please give us some time. I can't speak for others, but I am
not sitting here idling and hoping that some work (e.g. patches to
review) might appear.

I have a lot of other stuff to do and will respond when I find some time
to look at your patches.

Pinging others on Monday when having sent out the patch only on Thursday
is rather unfriendly.


Juergen

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

Re: [Xen-devel] [Bug 198497] handle_mm_fault / xen_pmd_val / radix_tree_lookup_slot Null pointer

[Juergen Gross]

On 20/04/18 17:20, Jason Andryuk wrote:
> Adding xen-devel and the Linux Xen maintainers.
> 
> Summary: Some Xen users (and maybe others) are hitting a BUG in
> __radix_tree_lookup() under do_swap_page() - example backtrace is
> provided at the end.  Matthew Wilcox provided a band-aid patch that
> prints errors like the following instead of triggering the bug.
> 
> Skylake 32bit PAE Dom0:
> Bad swp_entry: 8000
> mm/swap_state.c:683: bad pte d3a39f1c(8004)
> 
> Ivy Bridge 32bit PAE Dom0:
> Bad swp_entry: 4000
> mm/swap_state.c:683: bad pte d3a05f1c(8002)
> 
> Other 32bit DomU:
> Bad swp_entry: 400
> mm/swap_state.c:683: bad pte e2187f30(8002)
> 
> Other 32bit:
> Bad swp_entry: 200
> mm/swap_state.c:683: bad pte ef3a3f38(8001)
> 
> The Linux bugzilla has more info
> https://bugzilla.kernel.org/show_bug.cgi?id=198497
> 
> This may not be exclusive to Xen Linux, but most of the reports are on
> Xen.  Matthew wonders if Xen might be stepping on the upper bits of a
> pte.
> 
> On Fri, Apr 20, 2018 at 9:39 AM, Matthew Wilcox  wrote:
>> On Fri, Apr 20, 2018 at 09:10:11AM -0400, Jason Andryuk wrote:
 Given that this is happening on Xen, I wonder if Xen is using some of the
 bits in the page table for its own purposes.
>>>
>>> The backtraces include do_swap_page().  While I have a swap partition
>>> configured, I don't think it's being used.  Are we somehow
>>> misidentifying the page as a swap page?  I'm not familiar with the
>>> code, but is there an easy way to query global swap usage?  That way
>>> we can see if the check for a swap page is bogus.
>>>
>>> My system works with the band-aid patch.  When that patch sets page =
>>> NULL, does that mean userspace is just going to get a zero-ed page?
>>> Userspace still works AFAICT, which makes me think it is a
>>> mis-identified page to start with.
>>
>> Here's how this code works.
> 
> Thanks for the description.
> 
>> When we swap out an anonymous page (a page which is not backed by a
>> file; could be from a MAP_PRIVATE mapping, could be brk()), we write it
>> to the swap cache.  In order to be able to find it again, we store a
>> cookie (called a swp_entry_t) in the process' page table (marked with
>> the 'present' bit clear, so the CPU will fault on it).  When we get a
>> fault, we look up the cookie in a radix tree and bring that page back
>> in from swap.
>>
>> If there's no page found in the radix tree, we put a freshly zeroed
>> page into the process's address space.  That's because we won't find
>> a page in the swap cache's radix tree for the first time we fault.
>> It's not an indication of a bug if there's no page to be found.
> 
> Is "no page found" the case for a lazy, un-allocated MAP_ANONYMOUS page?
> 
>> What we're seeing for this bug is page table entries of the format
>> 0x8000'0004''.  That would be a zeroed entry, except for the
>> fact that something's stepped on the upper bits.
> 
> Does a totally zero-ed entry correspond to an un-allocated MAP_ANONYMOUS page?
> 
>> What is worrying is that potentially Xen might be stepping on the upper
>> bits of either a present entry (leading to the process loading a page
>> that belongs to someone else) or an entry which has been swapped out,
>> leading to the process getting a zeroed page when it should be getting
>> its page back from swap.
> 
> There was at least one report of non-Xen 32bit being affected.  There
> was no backtrace, so it could be something else.  One report doesn't
> have any swap configured.
> 
>> Defending against this kind of corruption would take adding a parity
>> bit to the page tables.  That's not a project I have time for right now.
> 
> Understood.  Thanks for the response.
> 
> Regards,
> Jason
> 
> 
> [ 2234.939079] BUG: unable to handle kernel NULL pointer dereference at 
> 0008
> [ 2234.942154] IP: __radix_tree_lookup+0xe/0xa0
> [ 2234.945176] *pdpt = 08cd5027 *pde = 
> [ 2234.948382] Oops:  [#1] SMP
> [ 2234.951410] Modules linked in: hp_wmi sparse_keymap rfkill wmi_bmof
> pcspkr i915 wmi hp_accel lis3lv02d input_polldev drm_kms_helper
> syscopyarea sysfillrect sysimgblt fb_sys_fops drm hp_wireless
> i2c_algo_bit hid_multitouch sha256_generic xen_netfront v4v(O) psmouse
> ecb xts hid_generic xhci_pci xhci_hcd ohci_pci ohci_hcd uhci_hcd
> ehci_pci ehci_hcd usbhid hid tpm_tis tpm_tis_core tpm
> [ 2234.960816] CPU: 1 PID: 2338 Comm: xenvm Tainted: G   O4.14.18 
> #1
> [ 2234.963991] Hardware name: Hewlett-Packard HP EliteBook Folio
> 9470m/18DF, BIOS 68IBD Ver. F.40 02/01/2013
> [ 2234.967186] task: d4370980 task.stack: cf8e8000
> [ 2234.970351] EIP: __radix_tree_lookup+0xe/0xa0
> [ 2234.973520] EFLAGS: 00010286 CPU: 1
> [ 2234.976699] EAX: 0004 EBX: b590 ECX:  EDX: 
> [ 2234.979887] ESI:  EDI: 0004 EBP: cf8e9dd0 ESP: cf8e9dc0
> [ 2234.983081]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0069
> [ 

Re: [Xen-devel] [PATCH V2] x86/p2m: fixed p2m_change_type_range() start / end check

[Jan Beulich]

>>> On 23.04.18 at 09:23,  wrote:
> On 04/18/2018 04:12 PM, Razvan Cojocaru wrote:
>> p2m_change_type_range() handles end > max_mapped_pfn, but not
>> start > max_mapped_pfn. Check the latter just after grabbing the
>> lock and bail if true.
>> 
>> Signed-off-by: Razvan Cojocaru 
>> Suggested-by: George Dunlap 
>> 
>> ---
>> Changes since V1:
>>  - Added ASSERT()s.
>>  - Wrapped the new condition in an unlikely().
>> ---
>>  xen/arch/x86/mm/p2m.c | 11 +++
>>  1 file changed, 11 insertions(+)
>> 
>> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
>> index c53cab4..e09b256 100644
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -978,8 +978,19 @@ void p2m_change_type_range(struct domain *d,
>>  p2m_lock(p2m);
>>  p2m->defer_nested_flush = 1;
>>  
>> +ASSERT(start < end);
>> +
>> +if ( unlikely(start > p2m->max_mapped_pfn) )
>> +{
>> +ASSERT(!p2m_is_hostp2m(p2m));
>> +p2m_unlock(p2m);
>> +return;
>> +}
>> +
>>  if ( unlikely(end > p2m->max_mapped_pfn) )
>>  {
>> +ASSERT(end == ~0UL || !p2m_is_hostp2m(p2m));
>> +
>>  if ( !gfn )
>>  {
>>  p2m->change_entry_type_global(p2m, ot, nt);
>> 
> 
> I think I've addressed George's comments on the altp2m VGA logdirty
> issue and I'm ready to send the current version of the patch, however it
> depends on this one.
> 
> Is the above patch uncontroversial enough to find its way into staging
> soon (in which case I should probably wait until it's in to send out the
> other patch), or should I perhaps create a series of two patches and
> send that out?

Well, you'll need George's ack and (for the tree being frozen) you'd need
to justify why this is important to fix for 4.11 (to convince Jürgen to give
a release ack).

> Or is it maybe customary to proceed somehow else in a situation like this?

A series is one way. Adding a post-commit-message note to clarify the
dependency (textual and/or functional) is another.

Jan


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

Re: [Xen-devel] [PATCH v2] Input: xen-kbdfront - allow better run-time configuration

[Oleksandr Andrushchenko]

Juergen, Jason, Dmitry
any comment on this?

Thank you,
Oleksandr
On 04/19/2018 04:39 PM, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko 

It is now only possible to control if multi-touch virtual device
is created or not (via the corresponding XenStore entries),
but keyboard and pointer devices are always created.
In some cases this is not desirable. For example, if virtual
keyboard device is exposed to Android then the latter won't
automatically show on-screen keyboard as it expects that a
physical keyboard device can be used for typing.

Make it possible to configure which virtual devices are created
with module parameters:
   - provide no_ptr_dev if no pointer device needs to be created
   - provide no_kbd_dev if no keyboard device needs to be created
Keep old behavior by default.

Signed-off-by: Oleksandr Andrushchenko 
Suggested-by: Andrii Chepurnyi 
Tested-by: Andrii Chepurnyi 
---
Changes since v1:
   - changed module parameters from uint to bool

  drivers/input/misc/xen-kbdfront.c | 159 +-
  1 file changed, 92 insertions(+), 67 deletions(-)

diff --git a/drivers/input/misc/xen-kbdfront.c 
b/drivers/input/misc/xen-kbdfront.c
index d91f3b1c5375..d8cca212f737 100644
--- a/drivers/input/misc/xen-kbdfront.c
+++ b/drivers/input/misc/xen-kbdfront.c
@@ -51,6 +51,16 @@ module_param_array(ptr_size, int, NULL, 0444);
  MODULE_PARM_DESC(ptr_size,
"Pointing device width, height in pixels (default 800,600)");
  
+static bool no_ptr_dev;

+module_param(no_ptr_dev, bool, 0);
+MODULE_PARM_DESC(no_ptr_dev,
+   "If set then no virtual pointing device exposed to the guest");
+
+static bool no_kbd_dev;
+module_param(no_kbd_dev, bool, 0);
+MODULE_PARM_DESC(no_kbd_dev,
+   "If set then no virtual keyboard device exposed to the guest");
+
  static int xenkbd_remove(struct xenbus_device *);
  static int xenkbd_connect_backend(struct xenbus_device *, struct xenkbd_info 
*);
  static void xenkbd_disconnect_backend(struct xenkbd_info *);
@@ -63,6 +73,9 @@ static void xenkbd_disconnect_backend(struct xenkbd_info *);
  static void xenkbd_handle_motion_event(struct xenkbd_info *info,
   struct xenkbd_motion *motion)
  {
+   if (unlikely(!info->ptr))
+   return;
+
input_report_rel(info->ptr, REL_X, motion->rel_x);
input_report_rel(info->ptr, REL_Y, motion->rel_y);
if (motion->rel_z)
@@ -73,6 +86,9 @@ static void xenkbd_handle_motion_event(struct xenkbd_info 
*info,
  static void xenkbd_handle_position_event(struct xenkbd_info *info,
 struct xenkbd_position *pos)
  {
+   if (unlikely(!info->ptr))
+   return;
+
input_report_abs(info->ptr, ABS_X, pos->abs_x);
input_report_abs(info->ptr, ABS_Y, pos->abs_y);
if (pos->rel_z)
@@ -97,6 +113,9 @@ static void xenkbd_handle_key_event(struct xenkbd_info *info,
return;
}
  
+	if (unlikely(!dev))

+   return;
+
input_event(dev, EV_KEY, key->keycode, value);
input_sync(dev);
  }
@@ -192,7 +211,7 @@ static int xenkbd_probe(struct xenbus_device *dev,
  const struct xenbus_device_id *id)
  {
int ret, i;
-   unsigned int abs, touch;
+   unsigned int touch;
struct xenkbd_info *info;
struct input_dev *kbd, *ptr, *mtouch;
  
@@ -211,24 +230,6 @@ static int xenkbd_probe(struct xenbus_device *dev,

if (!info->page)
goto error_nomem;
  
-	/* Set input abs params to match backend screen res */

-   abs = xenbus_read_unsigned(dev->otherend,
-  XENKBD_FIELD_FEAT_ABS_POINTER, 0);
-   ptr_size[KPARAM_X] = xenbus_read_unsigned(dev->otherend,
- XENKBD_FIELD_WIDTH,
- ptr_size[KPARAM_X]);
-   ptr_size[KPARAM_Y] = xenbus_read_unsigned(dev->otherend,
- XENKBD_FIELD_HEIGHT,
- ptr_size[KPARAM_Y]);
-   if (abs) {
-   ret = xenbus_write(XBT_NIL, dev->nodename,
-  XENKBD_FIELD_REQ_ABS_POINTER, "1");
-   if (ret) {
-   pr_warn("xenkbd: can't request abs-pointer\n");
-   abs = 0;
-   }
-   }
-
touch = xenbus_read_unsigned(dev->nodename,
 XENKBD_FIELD_FEAT_MTOUCH, 0);
if (touch) {
@@ -241,60 +242,84 @@ static int xenkbd_probe(struct xenbus_device *dev,
}
  
  	/* keyboard */

-   kbd = input_allocate_device();
-   if (!kbd)
-   goto error_nomem;
-   kbd->name = "Xen Virtual Keyboard";
-   kbd->phys = info->phys;
-   

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

[Alexandru Isaila]

This patch is adding a way to enable/disable inguest pagefault
events. It introduces the xc_monitor_inguest_pagefault function
and adds the inguest_pagefault_disabled in the monitor structure.
This is needed by the introspection so it will only get gla
faults and not get spammed with other faults.
In p2m_mem_access_check() we emulate so no event will get sent.

Signed-off-by: Alexandru Isaila 

---
Changes since V4:
- Added the hvm_emulate_one_vm_event() call in
  p2m_mem_access_check()
- Removed p2m_set_ad_bits().
---
 tools/libxc/include/xenctrl.h |  2 ++
 tools/libxc/xc_monitor.c  | 14 ++
 xen/arch/x86/mm/mem_access.c  |  9 +
 xen/arch/x86/monitor.c| 13 +
 xen/include/asm-x86/domain.h  |  5 +
 xen/include/asm-x86/monitor.h |  3 ++-
 xen/include/public/domctl.h   |  2 ++
 7 files changed, 47 insertions(+), 1 deletion(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 09e1363..20c2813 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2056,6 +2056,8 @@ int xc_monitor_descriptor_access(xc_interface *xch, 
uint32_t domain_id,
  bool enable);
 int xc_monitor_guest_request(xc_interface *xch, uint32_t domain_id,
  bool enable, bool sync, bool allow_userspace);
+int xc_monitor_inguest_pagefault(xc_interface *xch, uint32_t domain_id,
+ bool disable);
 int xc_monitor_debug_exceptions(xc_interface *xch, uint32_t domain_id,
 bool enable, bool sync);
 int xc_monitor_cpuid(xc_interface *xch, uint32_t domain_id, bool enable);
diff --git a/tools/libxc/xc_monitor.c b/tools/libxc/xc_monitor.c
index 0233b87..4ac823e 100644
--- a/tools/libxc/xc_monitor.c
+++ b/tools/libxc/xc_monitor.c
@@ -163,6 +163,20 @@ int xc_monitor_guest_request(xc_interface *xch, uint32_t 
domain_id, bool enable,
 return do_domctl(xch, );
 }
 
+int xc_monitor_inguest_pagefault(xc_interface *xch, uint32_t domain_id,
+bool disable)
+{
+DECLARE_DOMCTL;
+
+domctl.cmd = XEN_DOMCTL_monitor_op;
+domctl.domain = domain_id;
+domctl.u.monitor_op.op = disable ? XEN_DOMCTL_MONITOR_OP_ENABLE
+: XEN_DOMCTL_MONITOR_OP_DISABLE;
+domctl.u.monitor_op.event = XEN_DOMCTL_MONITOR_EVENT_INGUEST_PAGEFAULT;
+
+return do_domctl(xch, );
+}
+
 int xc_monitor_emulate_each_rep(xc_interface *xch, uint32_t domain_id,
 bool enable)
 {
diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c
index c0cd017..febe38d 100644
--- a/xen/arch/x86/mm/mem_access.c
+++ b/xen/arch/x86/mm/mem_access.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "mm-locks.h"
@@ -207,6 +208,14 @@ bool p2m_mem_access_check(paddr_t gpa, unsigned long gla,
 return true;
 }
 }
+if ( vm_event_check_ring(d->vm_event_monitor) &&
+ d->arch.monitor.inguest_pagefault_disabled &&
+ npfec.kind != npfec_kind_with_gla ) /* don't send a mem_event */
+{
+hvm_emulate_one_vm_event(EMUL_KIND_NORMAL, TRAP_invalid_op, 
X86_EVENT_NO_EC);
+
+return true;
+}
 
 *req_ptr = NULL;
 req = xzalloc(vm_event_request_t);
diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c
index f229e69..ce5d1ba 100644
--- a/xen/arch/x86/monitor.c
+++ b/xen/arch/x86/monitor.c
@@ -241,6 +241,19 @@ int arch_monitor_domctl_event(struct domain *d,
 break;
 }
 
+case XEN_DOMCTL_MONITOR_EVENT_INGUEST_PAGEFAULT:
+{
+bool old_status = ad->monitor.inguest_pagefault_disabled;
+
+if ( unlikely(old_status == requested_status) )
+return -EEXIST;
+
+domain_pause(d);
+ad->monitor.inguest_pagefault_disabled = requested_status;
+domain_unpause(d);
+break;
+}
+
 case XEN_DOMCTL_MONITOR_EVENT_DESC_ACCESS:
 {
 bool old_status = ad->monitor.descriptor_access_enabled;
diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index 4679d54..fbdc392 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -412,6 +412,11 @@ struct arch_domain
 unsigned int descriptor_access_enabled : 1;
 unsigned int guest_request_userspace_enabled   : 1;
 unsigned int emul_unimplemented_enabled: 1;
+/*
+ * By default all events are sent.
+ * This is used to filter out pagefaults.
+ */
+unsigned int inguest_pagefault_disabled: 1;
 struct monitor_msr_bitmap *msr_bitmap;
 uint64_t write_ctrlreg_mask[4];
 } monitor;
diff --git a/xen/include/asm-x86/monitor.h b/xen/include/asm-x86/monitor.h
index a0444d1..647df4a 100644
---