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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   5 xen-buildfail REGR. vs. 105963
 build-i3865 xen-buildfail REGR. vs. 105963
 build-i386-xsm5 xen-buildfail REGR. vs. 105963
 build-amd64-xsm   5 xen-buildfail REGR. vs. 105963

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a

version targeted for testing:
 ovmf 58974b6e079746fb9295d24297f62077cd05144f
baseline version:
 ovmf e0307a7dad02aa8c0cd8b3b0b9edce8ddb3fef2e

Last test of basis   105963  2017-02-21 21:43:31 Z6 days
Failing since105980  2017-02-22 10:03:53 Z5 days   15 attempts
Testing same since   106229  2017-02-28 05:31:43 Z0 days1 attempts


People who touched revisions under test:
  Anthony PERARD 
  Ard Biesheuvel 
  Chen A Chen 
  Hao Wu 
  Hegde Nagaraj P 
  Jeff Fan 
  Jiaxin Wu 
  Jiewen Yao 
  Laszlo Ersek 
  Paolo Bonzini 
  Qin Long 
  Ruiyu Ni 
  Star Zeng 
  Wu Jiaxin 
  Yonghong Zhu 
  Zhang Lubo 

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



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

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

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

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


Not pushing.

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

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

Re: [Xen-devel] [PATCH v3] ring.h: introduce macros to handle monodirectional rings with multiple req sizes

[Oleksandr Andrushchenko]

On 02/28/2017 12:17 AM, Stefano Stabellini wrote:

On Mon, 27 Feb 2017, Oleksandr Andrushchenko wrote:

On 02/23/2017 08:45 PM, Stefano Stabellini wrote:

On Thu, 23 Feb 2017, Oleksandr Andrushchenko wrote:

Hi, Stefano!

On 02/22/2017 07:10 PM, Stefano Stabellini wrote:

On Wed, 22 Feb 2017, Oleksandr Andrushchenko wrote:

Hi, Stefano, Jan!
1. Stefano, are you still NOT considering adding
functionality to avoid memory copying? We discussed
this a little bit here [1].

Hi Oleksandr,

these macros are the generic versions of what pvcalls and xen-9pfs need,
and these protocols use memory copies.

These macros will live in generic ring.h. It means that
they can be used not only by pvcalls/9pfs, but others are
allowed to use them too (kbdif/fbif/displif/??).

That's right, but without an additional use case and test case (code I
can test them with), it doesn't make sense for me to add more functions
in this patch now. They would likely not be optimal. Of course they can
be added later.



That being said, I am not convinced that this is a good idea
to introduce a memory copying while dealing with the packets
in an IRQ handler, for example.

Let me premise that I have nothing against memory sharing based
protocols, in fact I welcome them, but these macros are meant for memory
copy based protocols. (It is a pity that the Intel and ARM architecture
differ so much in this regard, copy being faster than mapping in most
cases on Intel, given the high cost of tlb flushes).



So, my point is that we should give a possibility to directly
access ring's contents, which will not be used in your case.

That I can do. I could add a simple macro to make it easy to get a
pointer to the content for reading or writing. Today I am accessing it
with something like:
   data->out + pvcalls_mask(intf->out_prod, array_size);

But I could add some sugar around it.



I cannot introduce memory sharing
interfaces as part of this patch, because they wouldn't comply to
pvcalls or xen-9pfs

Again, you are thinking of pvcalls/9pfs, but none of the macros
say they are for these use-cases: anyone can use them

and I don't have another test case for them.
But if you had a patch to introduce them in ring.h, I would be happy to
help you review it.


No, I don't have any, sorry

2. Will you also provide macros/inlines for fixed sized packets?
So, others do not reinvent the wheel again on top of your code.

I thought I already did: you can read/write fixed sized packets using
the two read/write_packet functions.

I was thinking of something like we have for req/resp
  DEFINE_RING_TYPES(fsif, struct fsif_request, struct fsif_response);
so you don't need to care of sizeof(req/resp/event)

I think that would be very restrictive: with the read/write_packet
functions you can actually read and write packets of the same type or
different types. You could read packets of different sizes. In fact
maybe, instead of a packet_t type parameter, we should pass an opaque
struct pointer and a size, so that they can be used to actually read and
write anything. That way, you get the maximum flexibility out of them.

Also, if you need a traditional ring, what not use the traditional macro
for it?

I use it for req/resp (front->back), but I also need an asynchronous event
channel (back->front)
For that reason, Konrad suggested that I can probably re-use what you
do for pvcalls/9pfs [1]. But, now I am not convinced that I should drop
what I already have in displif and what kbdif/fbif use.

I see. If you use these macros, you'll end up with two mono-directional
rings. One for back->front communications and the other for front->back
communications. You'll also end up with two event channels, one for each
ring. They are used to notify the other end, both producer and consumer
do that. Finally, you'll get two functions (in my latest draft, still to
be sent out):

void $NAME_read_packet(const unsigned char *buf,
 RING_IDX masked_prod, RING_IDX *masked_cons,
 RING_IDX ring_size, void *opaque, size_t size);

void $NAME_write_packet(unsigned char *buf,
 RING_IDX *masked_prod, RING_IDX masked_cons,
 RING_IDX ring_size, const void *opaque, size_t size);

You can use them to send or receive pretty much anything on the ring,
including request/response structures, but also raw data. The code that
uses them looks like this (frontend side):

   struct xen_example_data_intf *intf; /* pointer to the indexes page */
   unsigned char *in;  /* pointer to ring buffer */
   int irq;/* irq number corresponding to event 
channel */
   struct xen_example_request h;   /* opaque struct to read, could be
  your request struct */

   RING_IDX cons, prod, masked_cons, masked_prod;

   while (1) {
cons = intf->in_cons;
prod = intf->in_prod;
mb();
   
   		if (xen_example_queued(prod, cons, 

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

[osstest service owner]

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

Regressions :-(

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

version targeted for testing:
 ovmf 40f42465891a3d524a2dfb67ee7eccdb05145f20
baseline version:
 ovmf e0307a7dad02aa8c0cd8b3b0b9edce8ddb3fef2e

Last test of basis   105963  2017-02-21 21:43:31 Z6 days
Failing since105980  2017-02-22 10:03:53 Z5 days   14 attempts
Testing same since   106217  2017-02-27 23:16:57 Z0 days1 attempts


People who touched revisions under test:
  Anthony PERARD 
  Ard Biesheuvel 
  Hegde Nagaraj P 
  Jeff Fan 
  Jiaxin Wu 
  Jiewen Yao 
  Laszlo Ersek 
  Paolo Bonzini 
  Star Zeng 
  Wu Jiaxin 
  Yonghong Zhu 
  Zhang Lubo 

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



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

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

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

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


Not pushing.

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

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 106141
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 106141
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 106141
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 106141
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 106141
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 106141

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 build-arm64   5 xen-buildfail   never pass
 build-arm64-xsm   5 xen-buildfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 qemuu8f2d7c341184a95d05476ea3c45dbae2b9ddbe51
baseline version:
 qemuu28f997a82cb509bf4775d4006b368e1bde8b7bdd

Last test of basis   106141  2017-02-26 08:00:26 Z1 days
Failing since106163  2017-02-26 17:45:03 Z1 days4 attempts
Testing same since   106216  2017-02-27 22:51:51 Z0 days1 attempts


People who touched revisions under test:
  Artyom Tarasenko 
  Daniel P. Berrange 
  Greg Kurz 
  Jeff Cody 
  John Snow 
  Kevin Wolf 
  Li Qiang 
  Nir Soffer 
  Paolo Bonzini 
  Paul Burton 
  Peter Lieven 
  Peter Maydell 
  Prasad J Pandit 
  Samuel Thibault 
  

[Xen-devel] [linux-linus test] 106209: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail REGR. vs. 59254
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail REGR. vs. 59254
 test-armhf-armhf-xl   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-xsm   6 xen-boot  fail REGR. vs. 59254
 build-i386-pvops  5 kernel-build  fail REGR. vs. 59254
 test-armhf-armhf-xl-cubietruck 11 guest-start fail REGR. vs. 59254
 test-armhf-armhf-libvirt  6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-credit2   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-arndale   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-libvirt-xsm  6 xen-boot  fail REGR. vs. 59254

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 15 guest-localmigrate/x10 fail in 
106190 pass in 106209
 test-amd64-amd64-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail pass in 
106190

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds  6 xen-boot  fail REGR. vs. 59254
 test-amd64-amd64-xl-rtds  9 debian-installfail REGR. vs. 59254
 test-armhf-armhf-xl-vhd   6 xen-bootfail baseline untested
 test-armhf-armhf-libvirt-raw  6 xen-bootfail baseline untested
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 59254
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 build-arm64-xsm   5 xen-buildfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 build-arm64   5 xen-build   

Re: [Xen-devel] [PATCH] MAINTAINERS: Update VT-d maintainers

[Xuquan (Quan Xu)]

On Tue, 21 Feb 2017 03:29:43 +, Tian, Kevin wrote:
> MAINTAINERS: Update VT-d maintainers
>
> Feng just left Intel.  So remove him from the list.
>
> Signed-off-by: Kevin Tian 
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 6f7ffeb..f14f844 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -215,7 +215,6 @@ F:  xen/include/asm-x86/tboot.h
>
>  INTEL(R) VT FOR DIRECTED I/O (VT-D)
>  M: Kevin Tian 
> -M: Feng Wu 
>  S: Supported
>  F: xen/drivers/passthrough/vtd/

Reviewed-by: Quan Xu 


All the best in Feng's new job!!
Quan


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

[Xen-devel] [xen-4.4-testing test] 106198: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xend-qemut-winxpsp3 15 guest-localmigrate/x10 fail in 106051 
REGR. vs. 105835

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemut-win7-amd64 3 host-install(3) broken in 106018 pass in 
106198
 test-amd64-amd64-xl-qemuu-ovmf-amd64 3 host-install(3) broken in 106018 pass 
in 106198
 test-amd64-amd64-pygrub  3 host-install(3) broken in 106018 pass in 106198
 test-amd64-i386-xl-qemuu-ovmf-amd64 3 host-install(3) broken in 106018 pass in 
106198
 test-amd64-i386-xl   3 host-install(3) broken in 106018 pass in 106198
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 3 host-install(3) broken in 106018 
pass in 106198
 test-amd64-i386-freebsd10-amd64 3 host-install(3) broken in 106051 pass in 
106198
 test-armhf-armhf-xl-multivcpu 16 guest-start.2   fail in 106051 pass in 106130
 test-armhf-armhf-xl-credit2   6 xen-boot fail in 106130 pass in 106198
 test-armhf-armhf-xl-multivcpu 11 guest-start fail in 106183 pass in 106198
 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail in 106183 pass 
in 106198
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail pass in 106018
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail pass in 106051
 test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat fail pass in 106130
 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail pass in 
106183

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop   fail in 106183 like 105835
 test-amd64-i386-xend-qemut-winxpsp3  9 windows-installfail like 105815
 test-xtf-amd64-amd64-2   16 xtf/test-pv32pae-selftestfail  like 105835
 test-xtf-amd64-amd64-4   16 xtf/test-pv32pae-selftestfail  like 105835
 test-xtf-amd64-amd64-3   20 xtf/test-hvm32-invlpg~shadow fail  like 105835
 test-xtf-amd64-amd64-3 33 xtf/test-hvm32pae-invlpg~shadow fail like 105835
 test-xtf-amd64-amd64-3   44 xtf/test-hvm64-invlpg~shadow fail  like 105835
 test-xtf-amd64-amd64-2   54 leak-check/check fail  like 105835
 test-xtf-amd64-amd64-4   54 leak-check/check fail  like 105835
 test-xtf-amd64-amd64-1   54 leak-check/check fail  like 105835
 test-xtf-amd64-amd64-5   54 leak-check/check fail  like 105835
 test-xtf-amd64-amd64-3   54 leak-check/check fail  like 105835
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 105835

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-2   10 xtf-fep  fail   never pass
 test-xtf-amd64-amd64-4   10 xtf-fep  fail   never pass
 test-xtf-amd64-amd64-2   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-4   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-1   10 xtf-fep  fail   never pass
 test-xtf-amd64-amd64-1   16 xtf/test-pv32pae-selftestfail   never pass
 test-xtf-amd64-amd64-1   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-2 31 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-4 31 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-2 37 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-4 37 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-2   41 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-1 31 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-4   41 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-1 37 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-1   41 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-5   10 xtf-fep  fail   never pass
 build-amd64-rumprun   7 xen-buildfail   never pass
 build-i386-rumprun7 xen-buildfail   never pass
 test-xtf-amd64-amd64-3   10 xtf-fep  fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-2   53 xtf/test-hvm64-xsa-195   fail   never pass
 test-xtf-amd64-amd64-4   53 xtf/test-hvm64-xsa-195   fail   never pass
 test-xtf-amd64-amd64-1   53 xtf/test-hvm64-xsa-195   fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail never pass
 

[Xen-devel] [PATCH v4] xen/arm: warn if dom0_mem is not specified

[Stefano Stabellini]

The default dom0_mem is 128M which is not sufficient to boot a Ubuntu
based Dom0. It is not clear what a better default value could be.

Instead, loudly warn the user when dom0_mem is unspecified and wait 3
secs. Then use 512M.

Update the docs to specify that dom0_mem is required on ARM. (The
current xen-command-line document does not actually reflect the current
behavior of dom0_mem on ARM correctly.)

Signed-off-by: Stefano Stabellini 
---
Changes in v4:
- use warning_add

Changes in v3:
- update docs
---
 docs/misc/xen-command-line.markdown |  8 +++-
 xen/arch/arm/domain_build.c | 15 ++-
 2 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index a11fdf9..c0106fb 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -603,7 +603,13 @@ For example, with `dom0_max_vcpus=4-8`:
 >  8|  8
 > 10|  8
 
-### dom0\_mem
+### dom0\_mem (ARM)
+> `= `
+
+Set the amount of memory for the initial domain (dom0). It must be
+greater than zero. This parameter is required.
+
+### dom0\_mem (x86)
 > `= List of ( min: | max: |  )`
 
 Set the amount of memory for the initial domain (dom0). If a size is
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index c97a1f5..7949b2b 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -31,14 +32,11 @@ integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
 
 int dom0_11_mapping = 1;
 
-#define DOM0_MEM_DEFAULT 0x800 /* 128 MiB */
-static u64 __initdata dom0_mem = DOM0_MEM_DEFAULT;
+static u64 __initdata dom0_mem;
 
 static void __init parse_dom0_mem(const char *s)
 {
 dom0_mem = parse_size_and_unit(s, );
-if ( dom0_mem == 0 )
-dom0_mem = DOM0_MEM_DEFAULT;
 }
 custom_param("dom0_mem", parse_dom0_mem);
 
@@ -2125,7 +2123,14 @@ int construct_dom0(struct domain *d)
 BUG_ON(d->vcpu[0] == NULL);
 BUG_ON(v->is_initialised);
 
-printk("*** LOADING DOMAIN 0 ***\n");
+if ( dom0_mem > 0 )
+printk("*** LOADING DOMAIN 0 ***\n");
+else
+{
+warning_add("PLEASE SPECIFY dom0_mem PARAMETER - USING 512M FOR 
NOW\n");
+dom0_mem = MB(512);
+}
+
 
 iommu_hwdom_init(d);
 
-- 
1.9.1


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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-freebsd10-amd64  6 xen-boot  fail REGR. vs. 105933
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  6 xen-boot fail REGR. vs. 105933
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  6 xen-boot fail REGR. vs. 105933
 test-amd64-i386-migrupgrade  10 xen-boot/dst_hostfail REGR. vs. 105933
 test-amd64-i386-libvirt-pair  9 xen-boot/src_hostfail REGR. vs. 105933
 test-amd64-i386-libvirt-pair 10 xen-boot/dst_hostfail REGR. vs. 105933
 test-amd64-i386-xl6 xen-boot fail REGR. vs. 105933
 test-amd64-i386-freebsd10-i386 9 freebsd-install fail in 106138 REGR. vs. 
105933
 test-amd64-i386-libvirt   9 debian-install fail in 106160 REGR. vs. 105933

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl   6 xen-boot fail in 106102 pass in 106186
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail 
in 106102 pass in 106186
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 
guest-localmigrate/x10 fail in 106102 pass in 106186
 test-amd64-i386-freebsd10-i386 8 leak-check/basis(8) fail in 106122 pass in 
106138
 test-amd64-i386-rumprun-i386  6 xen-boot fail in 106122 pass in 106186
 test-armhf-armhf-xl-credit2   6 xen-boot fail in 106122 pass in 106186
 test-amd64-i386-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail in 106138 
pass in 106102
 test-amd64-i386-libvirt   6 xen-boot fail in 106138 pass in 106186
 test-armhf-armhf-xl  11 guest-start  fail in 106138 pass in 106186
 test-armhf-armhf-libvirt-raw 14 guest-start/debian.repeat fail in 106138 pass 
in 106186
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 106138 pass in 
106186
 test-amd64-amd64-xl-qemuu-winxpsp3 17 guest-start/win.repeat fail in 106138 
pass in 106186
 test-amd64-i386-xl-raw6 xen-boot   fail pass in 106102
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  6 xen-boot   fail pass in 106122
 test-amd64-i386-qemuu-rhel6hvm-intel 8 leak-check/basis(8) fail pass in 106138
 test-amd64-i386-xl-qemuu-debianhvm-amd64 8 leak-check/basis(8) fail pass in 
106138
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail pass in 
106138
 test-amd64-i386-freebsd10-i386  6 xen-boot fail pass in 106160
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 6 xen-boot fail pass in 
106160
 test-amd64-i386-libvirt   8 leak-check/basis(8)fail pass in 106160
 test-amd64-i386-xl-qemuu-ovmf-amd64  6 xen-bootfail pass in 106160
 test-amd64-i386-qemut-rhel6hvm-intel  6 xen-boot   fail pass in 106160

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 105933
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 105933
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 105933
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 105933
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 105933
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 105933
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 105933
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 105933

Tests which did not succeed, but are not blocking:
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail in 106138 never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 build-arm64-xsm   5 xen-buildfail   never pass
 build-arm64   5 xen-buildfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 

Re: [Xen-devel] [PATCH] xen/arm: warn if dom0_mem is not specified

[Stefano Stabellini]

On Tue, 21 Feb 2017, Julien Grall wrote:
> Hi Stefano,
> 
> On 21/02/17 17:26, Stefano Stabellini wrote:
> > On Tue, 21 Feb 2017, Wei Liu wrote:
> > > On Mon, Feb 20, 2017 at 10:22:06AM -0800, Stefano Stabellini wrote:
> > > > The default dom0_mem is 128M which is not sufficient to boot a Ubuntu
> > > > based Dom0. It is not clear what a better default value could be.
> > > > 
> > > > Instead, loudly warn the user when dom0_mem is unspecified and wait 3
> > > > secs. Then use 512M.
> > > > 
> > > > Update the docs to specify that dom0_mem is required on ARM. (The
> > > > current xen-command-line document does not actually reflect the current
> > > > behavior of dom0_mem on ARM correctly.)
> > > > 
> > > > Signed-off-by: Stefano Stabellini 
> > > > ---
> > > > Changes in v3:
> > > > - update docs
> > > > ---
> > > >  docs/misc/xen-command-line.markdown |  8 +++-
> > > >  xen/arch/arm/domain_build.c | 22 +-
> > > >  2 files changed, 24 insertions(+), 6 deletions(-)
> > > > 
> > > > diff --git a/docs/misc/xen-command-line.markdown
> > > > b/docs/misc/xen-command-line.markdown
> > > > index a11fdf9..c0106fb 100644
> > > > --- a/docs/misc/xen-command-line.markdown
> > > > +++ b/docs/misc/xen-command-line.markdown
> > > > @@ -603,7 +603,13 @@ For example, with `dom0_max_vcpus=4-8`:
> > > >  >  8|  8
> > > >  > 10|  8
> > > > 
> > > > -### dom0\_mem
> > > > +### dom0\_mem (ARM)
> > > > +> `= `
> > > > +
> > > > +Set the amount of memory for the initial domain (dom0). It must be
> > > > +greater than zero. This parameter is required.
> > > > +
> > > > +### dom0\_mem (x86)
> > > >  > `= List of ( min: | max: |  )`
> > > > 
> > > >  Set the amount of memory for the initial domain (dom0). If a size is
> > > > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > > > index c97a1f5..db7471f 100644
> > > > --- a/xen/arch/arm/domain_build.c
> > > > +++ b/xen/arch/arm/domain_build.c
> > > > @@ -1,4 +1,5 @@
> > > >  #include 
> > > > +#include 
> > > >  #include 
> > > >  #include 
> > > >  #include 
> > > > @@ -31,14 +32,11 @@ integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
> > > > 
> > > >  int dom0_11_mapping = 1;
> > > > 
> > > > -#define DOM0_MEM_DEFAULT 0x800 /* 128 MiB */
> > > > -static u64 __initdata dom0_mem = DOM0_MEM_DEFAULT;
> > > > +static u64 __initdata dom0_mem;
> > > > 
> > > >  static void __init parse_dom0_mem(const char *s)
> > > >  {
> > > >  dom0_mem = parse_size_and_unit(s, );
> > > > -if ( dom0_mem == 0 )
> > > > -dom0_mem = DOM0_MEM_DEFAULT;
> > > >  }
> > > >  custom_param("dom0_mem", parse_dom0_mem);
> > > > 
> > > > @@ -2125,7 +2123,21 @@ int construct_dom0(struct domain *d)
> > > >  BUG_ON(d->vcpu[0] == NULL);
> > > >  BUG_ON(v->is_initialised);
> > > > 
> > > > -printk("*** LOADING DOMAIN 0 ***\n");
> > > > +if ( dom0_mem > 0 )
> > > > +printk("*** LOADING DOMAIN 0 ***\n");
> > > > +else
> > > > +{
> > > > +int i;
> > > > +printk("*** PLEASE SPECIFY dom0_mem PARAMETER - USING 512M FOR
> > > > NOW ***\n");
> > > > +for (i = 0; i < 3; i++)
> > > > +{
> > > > +printk("%d...", i+1);
> > > > +mdelay(1000);
> > > 
> > > There is infrastructure in Xen to print warning messages, so that we
> > > don't add delays unnecessarily.
> > > 
> > > See warning.h:warning_add.
> > 
> > I added the delay on purpose to force the user to specify dom0_mem, as
> > we cannot find a way to set a sensible default. The alternative is to
> > panic.
> 
> warning_add will gather the warning message and then will be printed at the
> end of the boot with a delay. This is what is used for sync_console message
> and also FEP on x86.
> 
> I think this is a good idea to gather all the warnings and print them at the
> end. At least it is not lost in the noise.

Yes, warning_add works very well actually. I'll use it.

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

Re: [Xen-devel] kpartx for raisin hvm tests

[Stefano Stabellini]

On Wed, 22 Feb 2017, Géza Gémes wrote:
> On 2017-02-21 23:10, Stefano Stabellini wrote:
> > On Tue, 21 Feb 2017, Géza Gémes wrote:
> > > Hi,
> > > 
> > > I've tried to run the raisin test suite, while pv tests pass the hvm tests
> > > fail. I've identified a number of problems, starting with two small disk
> > > size
> > > to formating the whole disk and then being unable to install grub to the
> > > boot
> > > sector. I've trace down these problems into the incorrect invocation of
> > > the
> > > _create_loop_device function in scripts/lopartsetup.
> > > 
> > > My question: Will it be acceptable if I would replace this part of the
> > > code
> > > with a kpartx call? Or introducing kpartx is a too big change in the list
> > > of
> > > dependencies?
> >   I understand that kpartx makes things much easier, but before
> > introducing it as a dependency, I would like to understand this problem
> > a bit better.
> > 
> > Why is _create_loop_device invoked incorrectly? Is it index or offset
> > that is calculate incorrectly?
> 
> Hi Stefano,
> 
> In scripts/lopartsetup:56 unit="`fdisk -lu $filename 2>/dev/null | grep -e
> "^Units = " | cut -d " " -f 9`" . Using ubuntu 16.04 (fdisk coming from
> util-linux-2.27.1-6ubuntu3.2) this yields to an empty variable, as:
> 
> $sudo fdisk -lu /tmp/tmp.x9UN6uxaG2/busybox-vm-disk 2>/dev/null
> 
> Disk /tmp/tmp.x9UN6uxaG2/busybox-vm-disk: 60 MiB, 62914560 bytes, 122880
> sectors
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> 
> Because of this both unit and offset are wrong ( offset=`echo $i | tr -s " " |
> cut -d " " -f 2`, where i=fdisk -lu $filename 2>/dev/null | grep -e
> "^$filename")
> 
> As I think that different versions of fdisk will produce different results, we
> either introduce an additional logic for the fdisk version, either change this
> part completely.

It doesn't look like fdisk changed output in this case. It looks like
the disk doesn't have any partitions in it. Am I right?

It would be easy to add support to lopartsetup to detect disks without
partitions, and deal with them correctly, without bringing in kpartx.
However, this scenario shouldn't occur, because lopartsetup is only
called by create_one_partition, right after creating a partition on the
disk.

Do you know why create_one_partition doesn't work as expected?___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[osstest service owner]

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

Regressions :-(

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

version targeted for testing:
 ovmf 4b1dd5c457c8fb07937851c9dc0f38e48d130b14
baseline version:
 ovmf e0307a7dad02aa8c0cd8b3b0b9edce8ddb3fef2e

Last test of basis   105963  2017-02-21 21:43:31 Z6 days
Failing since105980  2017-02-22 10:03:53 Z5 days   13 attempts
Testing same since   106206  2017-02-27 16:14:22 Z0 days1 attempts


People who touched revisions under test:
  Anthony PERARD 
  Ard Biesheuvel 
  Hegde Nagaraj P 
  Jeff Fan 
  Jiaxin Wu 
  Jiewen Yao 
  Laszlo Ersek 
  Paolo Bonzini 
  Star Zeng 
  Wu Jiaxin 
  Yonghong Zhu 
  Zhang Lubo 

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



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

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

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

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


Not pushing.

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

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 14 guest-saverestore.2 fail REGR. 
vs. 106141

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 106141
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 106141
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 106141
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 106141
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 106141
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 106141

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 build-arm64   5 xen-buildfail   never pass
 build-arm64-xsm   5 xen-buildfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 qemuud992f2f1368ceb92e6bfd8efece174110f4236ff
baseline version:
 qemuu28f997a82cb509bf4775d4006b368e1bde8b7bdd

Last test of basis   106141  2017-02-26 08:00:26 Z1 days
Failing since106163  2017-02-26 17:45:03 Z1 days3 attempts
Testing same since   106195  2017-02-27 10:42:08 Z0 days1 attempts


People who touched revisions under test:
  Artyom Tarasenko 
  Jeff Cody 
  John Snow 
  Kevin Wolf 
  Nir Soffer 
  Paul Burton 
  Peter Lieven 
  Peter Maydell 
  Samuel Thibault 
  tianqing 

Re: [Xen-devel] [PATCH v3] ring.h: introduce macros to handle monodirectional rings with multiple req sizes

[Stefano Stabellini]

On Mon, 27 Feb 2017, Oleksandr Andrushchenko wrote:
> On 02/23/2017 08:45 PM, Stefano Stabellini wrote:
> > On Thu, 23 Feb 2017, Oleksandr Andrushchenko wrote:
> > > Hi, Stefano!
> > > 
> > > On 02/22/2017 07:10 PM, Stefano Stabellini wrote:
> > > > On Wed, 22 Feb 2017, Oleksandr Andrushchenko wrote:
> > > > > Hi, Stefano, Jan!
> > > > > 1. Stefano, are you still NOT considering adding
> > > > > functionality to avoid memory copying? We discussed
> > > > > this a little bit here [1].
> > > > Hi Oleksandr,
> > > > 
> > > > these macros are the generic versions of what pvcalls and xen-9pfs need,
> > > > and these protocols use memory copies.
> > > These macros will live in generic ring.h. It means that
> > > they can be used not only by pvcalls/9pfs, but others are
> > > allowed to use them too (kbdif/fbif/displif/??).
> > That's right, but without an additional use case and test case (code I
> > can test them with), it doesn't make sense for me to add more functions
> > in this patch now. They would likely not be optimal. Of course they can
> > be added later.
> > 
> > 
> > > That being said, I am not convinced that this is a good idea
> > > to introduce a memory copying while dealing with the packets
> > > in an IRQ handler, for example.
> > Let me premise that I have nothing against memory sharing based
> > protocols, in fact I welcome them, but these macros are meant for memory
> > copy based protocols. (It is a pity that the Intel and ARM architecture
> > differ so much in this regard, copy being faster than mapping in most
> > cases on Intel, given the high cost of tlb flushes).
> > 
> > 
> > > So, my point is that we should give a possibility to directly
> > > access ring's contents, which will not be used in your case.
> > That I can do. I could add a simple macro to make it easy to get a
> > pointer to the content for reading or writing. Today I am accessing it
> > with something like:
> >   data->out + pvcalls_mask(intf->out_prod, array_size);
> > 
> > But I could add some sugar around it.
> > 
> > 
> > > >I cannot introduce memory sharing
> > > > interfaces as part of this patch, because they wouldn't comply to
> > > > pvcalls or xen-9pfs
> > > Again, you are thinking of pvcalls/9pfs, but none of the macros
> > > say they are for these use-cases: anyone can use them
> > > >and I don't have another test case for them.
> > > > But if you had a patch to introduce them in ring.h, I would be happy to
> > > > help you review it.
> > > > 
> > > No, I don't have any, sorry
> > > > > 2. Will you also provide macros/inlines for fixed sized packets?
> > > > > So, others do not reinvent the wheel again on top of your code.
> > > > I thought I already did: you can read/write fixed sized packets using
> > > > the two read/write_packet functions.
> > > I was thinking of something like we have for req/resp
> > >  DEFINE_RING_TYPES(fsif, struct fsif_request, struct fsif_response);
> > > so you don't need to care of sizeof(req/resp/event)
> > I think that would be very restrictive: with the read/write_packet
> > functions you can actually read and write packets of the same type or
> > different types. You could read packets of different sizes. In fact
> > maybe, instead of a packet_t type parameter, we should pass an opaque
> > struct pointer and a size, so that they can be used to actually read and
> > write anything. That way, you get the maximum flexibility out of them.
> > 
> > Also, if you need a traditional ring, what not use the traditional macro
> > for it?
> I use it for req/resp (front->back), but I also need an asynchronous event
> channel (back->front)
> For that reason, Konrad suggested that I can probably re-use what you
> do for pvcalls/9pfs [1]. But, now I am not convinced that I should drop
> what I already have in displif and what kbdif/fbif use.

I see. If you use these macros, you'll end up with two mono-directional
rings. One for back->front communications and the other for front->back
communications. You'll also end up with two event channels, one for each
ring. They are used to notify the other end, both producer and consumer
do that. Finally, you'll get two functions (in my latest draft, still to
be sent out):

void $NAME_read_packet(const unsigned char *buf,
RING_IDX masked_prod, RING_IDX *masked_cons,
RING_IDX ring_size, void *opaque, size_t size);

void $NAME_write_packet(unsigned char *buf,
RING_IDX *masked_prod, RING_IDX masked_cons,
RING_IDX ring_size, const void *opaque, size_t size);

You can use them to send or receive pretty much anything on the ring,
including request/response structures, but also raw data. The code that
uses them looks like this (frontend side):

  struct xen_example_data_intf *intf; /* pointer to the indexes page */
  unsigned char *in;  /* pointer to ring buffer */
  int irq;/* irq number corresponding to event 
channel */
  struct xen_example_request h;   /* 

[Xen-devel] [linux-next test] 106193: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-debianhvm-amd64 15 guest-localmigrate/x10 fail REGR. 
vs. 106172

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-arndale  11 guest-start fail blocked in 106172
 test-armhf-armhf-xl-rtds 11 guest-start fail blocked in 106172
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-check fail blocked in 
106172
 test-armhf-armhf-libvirt   13 saverestore-support-check fail blocked in 106172
 test-armhf-armhf-xl  11 guest-start fail blocked in 106172
 test-armhf-armhf-xl-multivcpu 11 guest-startfail blocked in 106172
 test-armhf-armhf-xl-xsm  11 guest-start fail blocked in 106172
 test-armhf-armhf-xl-credit2  11 guest-start fail blocked in 106172
 test-armhf-armhf-xl-vhd   9 debian-di-install   fail blocked in 106172
 test-armhf-armhf-libvirt-raw  9 debian-di-install   fail blocked in 106172
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail like 106172
 build-i386-pvops  5 kernel-build fail  like 106172
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 106172
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 106172
 test-armhf-armhf-xl-cubietruck 11 guest-start fail like 106172

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   5 xen-buildfail   never pass
 build-arm64-xsm   5 xen-buildfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 

Re: [Xen-devel] [linux-linus test] 106139: regressions - FAIL

[Boris Ostrovsky]

On 02/26/2017 12:36 PM, Boris Ostrovsky wrote:
>
>
> On 02/26/2017 10:32 AM, osstest service owner wrote:
>> flight 106139 linux-linus real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/106139/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>>   test-amd64-amd64-xl-pvh-intel 11 guest-start  fail
>> REGR. vs. 59254
>>   test-armhf-armhf-xl   6 xen-boot  fail
>> REGR. vs. 59254
>>   test-armhf-armhf-xl-multivcpu  6 xen-boot fail
>> REGR. vs. 59254
>>   test-armhf-armhf-xl-xsm   6 xen-boot  fail
>> REGR. vs. 59254
>>   build-i386-pvops  5 kernel-build  fail
>> REGR. vs. 59254
>
> Linux is broken for i386 due to a recent commit. Don't know yet
> whether it's paravirt-specific or general brokenness.

Should be fixed soon:

http://marc.info/?l=linux-mm=148822413412388=2

-boris

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

Re: [Xen-devel] Crash w/ bios="ovmf"

[jdickens]

This turned out to be a xen install problem. The default install 
location for the build was /usr/local but my system was using /usr.  The 
root cause was hvmloader created by the new build was not actually the 
one being used.



On 2017-02-27 11:59, Konrad Rzeszutek Wilk wrote:

On Wed, Feb 22, 2017 at 03:50:28PM -0500, Jason Dickens wrote:
I'm trying to find a solution to an immediate VM crash which occurs 
by

simply adding "bios='ovmf' to my configuration?

I started with a standard Ubuntu install which contained Xen 4.6.0 
and had
the crash. The VM works fine booting w/ SeaBIOS once the 
configuration line

is removed. It also works fine with OVMF using just QEMU.

Then I was led to believe that i needed to rebuild Xen with 
--enable-ovmf ,
using the source from apt-get source, this proved to be difficult 
and
ultimately I had to disable stub domains to get it to work. (in 
case, that

is relevant)

Still I get the crash almost immediately after the VM is launched. 
With

sdl=1 I can see the window flash up and disappear.
I should mention that ultimately I plan to use a non-standard build 
of the

OVMF kernel, but for now I'm happy to get it working with any one.


Can you try
pci_platform=0 in your guest config pleae?



At this point, I have been studying the source to try and determine 
where
things diverge. I find very little use of LIBXL_BIOS_TYPE_OVMF and 
can't

find  exactly where setting hvm.bios that even matters?

In any case, I would appreciate help on how to avoid the crash 
and/or

understanding the Xen modifications for OVMF.

Jason



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



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

[Xen-devel] [xen-unstable-smoke test] 106208: tolerable trouble: broken/fail/pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   5 xen-buildfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  12f687bf28e23fa662bb518311c4ec71e5b39ab8
baseline version:
 xen  3564f9e400c417fc3d47b732f474019c494434f9

Last test of basis   106199  2017-02-27 13:01:37 Z0 days
Testing same since   106208  2017-02-27 17:01:58 Z0 days1 attempts


People who touched revisions under test:
  Ian Jackson 
  Roger Pau Monne 
  Roger Pau Monné 
  Wei Liu 

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=12f687bf28e23fa662bb518311c4ec71e5b39ab8
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
12f687bf28e23fa662bb518311c4ec71e5b39ab8
+ branch=xen-unstable-smoke
+ revision=12f687bf28e23fa662bb518311c4ec71e5b39ab8
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.8-testing
+ '[' x12f687bf28e23fa662bb518311c4ec71e5b39ab8 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : 

Re: [Xen-devel] [PATCH v2 06/10] xen: credit2: group the runq manipulating functions.

[Dario Faggioli]

On Wed, 2017-02-15 at 14:42 +, George Dunlap wrote:
> Most of the motion makes sense, but moving the option parser along
> too
> seems a bit strange.  Wouldn't it make more sense to leave it with
> the
> other option parsers?  
>
Well, it's a runqueue related parameter, so it's runqueue related code,
and this is why I moved it.

_BUT_ after all, I think I agree with you. More specifically, I think
that either all the option parser are in "sections" where they belong,
depending on the option they take care of, or they all live together.

So, yes, let's keep them together. I'll see about moving each one in a
more specific place in the file and, if I decide to go for it, send a
patch.

Thanks and Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)

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

[Xen-devel] [linux-linus test] 106190: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail REGR. vs. 59254
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail REGR. vs. 59254
 test-armhf-armhf-xl   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-xsm   6 xen-boot  fail REGR. vs. 59254
 build-i386-pvops  5 kernel-build  fail REGR. vs. 59254
 test-armhf-armhf-xl-cubietruck 11 guest-start fail REGR. vs. 59254
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 15 guest-localmigrate/x10 fail REGR. 
vs. 59254
 test-armhf-armhf-libvirt  6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-credit2   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-arndale   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-libvirt-xsm  6 xen-boot  fail REGR. vs. 59254

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds  6 xen-boot  fail REGR. vs. 59254
 test-amd64-amd64-xl-rtds  9 debian-installfail REGR. vs. 59254
 test-armhf-armhf-xl-vhd   6 xen-bootfail baseline untested
 test-armhf-armhf-libvirt-raw  6 xen-bootfail baseline untested
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 59254
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 build-arm64-xsm   5 xen-buildfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 build-arm64   5 xen-buildfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 

Re: [Xen-devel] OVMF blows up at unless I use pci_platform=0

[Anthony PERARD]

On Mon, Feb 27, 2017 at 12:42:47PM -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Feb 20, 2017 at 03:49:31PM +, Anthony PERARD wrote:
> > On Wed, Feb 15, 2017 at 08:37:44PM -0500, Konrad Rzeszutek Wilk wrote:
> > > Hey,
> > > 
> > > I just built today Xen based on  93e1435290867703c50acad1f54b9208df473562
> > > Author: Oleksandr Tyshchenko 
> > > Date:   Wed Feb 15 12:20:01 2017 +
> > > 
> > > IOMMU: always call teardown callback
> > > 
> > [...]
> > > #xl create -c root-image-uefi.xm
> > > I get:
> > > 
> > >  X64 Exception Type - 0E(#PF - Page-Fault)  CPU Apic ID -  
> > > 
> > > RIP  - 3F2658DB, CS  - 0038, RFLAGS - 00010206
> > > ExceptionData - 0002
> > > RAX  - 0001, RCX - 3F2658BB, RDX - 0004
> > > RBX  - , RSP - 3F43B510, RBP - 3E574D18
> > > RSI  - 0003, RDI - 0001
> > > R8   - , R9  - , R10 - 3EA39198
> > > R11  - 0002, R12 - 3E575218, R13 - 
> > > R14  - 3E575220, R15 - 3F269301
> > > DS   - 0030, ES  - 0030, FS  - 0030
> > > GS   - 0030, SS  - 0030
> > > CR0  - C033, CR2 - BF2658BB, CR3 - 3F3DA000
> > > CR4  - 0668, CR8 - 
> > > DR0  - , DR1 - , DR2 - 
> > > DR3  - , DR6 - 0FF0, DR7 - 0400
> > > GDTR - 3F3C8A98 0047, LDTR - 
> > > IDTR - 3EAFD018 0FFF,   TR - 
> > > FXSAVE_STATE - 3F43B170
> > >  Find PE image 
> > > /home/konrad/xen/tools/firmware/ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC5/X64/OvmfPkg/XenBusDxe/XenBusDxe/DEBUG/XenBusDxe.dll
> > >  (ImageBase=3F262000, EntryPoint=3F263FE8) 
> > 
> > Which version of gcc did you compile OVMF with?
> 
> 
> gcc (GCC) 6.3.1 20161221 (Red Hat 6.3.1-1)
> Copyright (C) 2016 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> > 
> > I can reproduce with a "Page-Fault" in the same modules, but with an OVMF
> > binary compiled later, I have a "General Protection" fault in the module
> > PcRtc...
> > 
> > I blame -flto of gcc.
> 
> Oh..
> > 
> > If you have gcc 6.3, to build ovmf without -flto, either:
> > - build using OvmfPkg/build.sh -a X64 -n 4 -t GCC49
> > (that is "-t GCC49" added to ./build.sh call)
> > - or edit OvmfPkg/build.sh, replace GCC5 by GCC49.
> 
> OK, let me try that.

BTW, this should be fix upstream now.
I'll update xen repo once we have a pass of upstream with osstest.

-- 
Anthony PERARD

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

[Xen-devel] Virtual Interrupt Delivery

[Dmitry Rockosov]

Hi guys,

Do you know when *recognized* Virtual Interrupt on VM-Entry will be
delivered if Virtual-Interrupt Delivery is enabled and interrupt delivery
is blocking by STI?

Previously, VMM used Interrupt-Window, but as I see in XEN code,
Interrupt-Window
is not used when Virtual Interrupt Delivery is enabled.

Does it mean, we will get Virtual Interrupt on the next VM-entry?

Thank you!

Best Regards,
Rockosov Dmitry
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 2/2] xl: split out vnc and console related code

[Ian Jackson]

Wei Liu writes ("[PATCH 2/2] xl: split out vnc and console related code"):
> The new file also contains code for channel, which is just a console
> in disguise.

Good.  Except that...

> Replace the call to vncviewer() with libxl_vncviewer_exec() directly in
> main_vncviewer.

... you forgot to remove this from the commit message.

With that change,

Acked-by: Ian Jackson 

Ian.

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

Re: [Xen-devel] [PATCH v2 10/10] xen/tools: tracing: always report how long next slice will be.

[Dario Faggioli]

On Wed, 2017-02-15 at 15:40 +, George Dunlap wrote:
> On Thu, Feb 9, 2017 at 1:59 PM, Dario Faggioli
>  wrote:
> xen: Report next slice time when continuing as well as switching
> 
> We record trace information about the next timeslice when switching
> to
> a different vcpu, but not when continuing to run the same cpu.  This
> information
> is quite useful; so add a trace including that information on the
> 'continue_running' path as well.
> 
> ---
> 
> What do you think?
> 
Ok, I like it.

I did replace my changelog with your proposed one, but I've left the
example output from xenalyze in place.

Not sure whether you were suggesting to also kill that part. I do think
it's useful so I left it there. But if you want it removed too, I can
live with that, so just ask. :-)

Thanks and Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)

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

Re: [Xen-devel] [PATCH 1/2] xl: call libxl_vncviewer_exec in main_vncviewer

[Ian Jackson]

Wei Liu writes ("[PATCH 1/2] xl: call libxl_vncviewer_exec in main_vncviewer"):
> We will need to move main_vncviewer to a different file where it has no
> access to the helper vncviewer.

Acked-by: Ian Jackson 

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

[Xen-devel] (no subject)

[Dmitry Rockosov]

Hi guys,

Do you know when *recognized* Virtual Interrupt on VM-Entry will be
delivered if Virtual-Interrupt Delivery is enabled and interrupt delivery
is blocking by STI?

Previously, VMM used Interrupt-Window, but as I see in XEN code,
Interrupt-Window is not used when Virtual Interrupt Delivery is enabled.

Does it mean, we will get Virtual Interrupt on the next VM-entry?

Thank you!

Best Regards,
Rockosov Dmitry
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] xen/arm: Hiding SMMUs from Dom0 when using ACPI on Xen

[Julien Grall]

On 02/27/2017 04:58 PM, Shanker Donthineni wrote:

Hi Julien,


Hi Shanker,

Please don't drop people in CC. In my case, any e-mail I am not CCed are 
skipping my inbox and I may not read them for a while.




On 02/27/2017 08:12 AM, Julien Grall wrote:



On 27/02/17 13:23, Vijay Kilari wrote:

Hi Julien,


Hello Vijay,


On Wed, Feb 22, 2017 at 7:40 PM, Julien Grall 
wrote:

Hello,

There was few discussions recently about hiding SMMUs from DOM0 when
using
ACPI. I thought it would be good to have a separate thread for this.

When using ACPI, the SMMUs will be described in the IO Remapping Table
(IORT). The specification can be found on the ARM website [1].

For a brief summary, the IORT can be used to discover the SMMUs
present on
the platform and find for a given device the ID to configure
components such
as ITS (DeviceID) and SMMU (StreamID).

The appendix A in the specification gives an example how DeviceID and
StreamID can be found. For instance, when a PCI device is both
protected by
an SMMU and MSI-capable the following translation will happen:
RID -> StreamID -> DeviceID

Currently, SMMUs are hidden from DOM0 because they are been used by
Xen and
we don't support stage-1 SMMU. If we pass the IORT as it is, DOM0
will try
to initialize SMMU and crash.

I first thought about using a Xen specific way (STAO) or extending a
flag in
IORT. But that is not ideal.

So we would have to rewrite the IORT for DOM0. Given that a range of
RID can
mapped to multiple ranges of DeviceID, we would have to translate
RID one by
one to find the associated DeviceID. I think this may end up to
complex code
and have a big IORT table.


Why can't we replace Output base of IORT of PCI node with SMMU output
base?.
I mean similar to PCI node without SMMU, why can't replace output base
of PCI node with
SMMU's output base?.


Because I don't see anything in the spec preventing one RC ID mapping
to produce multiple SMMU ID mapping. So which output base would you use?



Basically, remove SMMU nodes, and replaces output of the PCIe and named
nodes ID mappings with ITS nodes.

RID --> StreamID  --> dviceID  --> ITS device id = RID --> dviceID  -->
ITS device id


Can you detail it? You seem to assume that one RC ID mapping range will 
only produce ID mapping range. AFAICT, this is not mandated by the spec.






The issue I see is RID is [15:0] where is DeviceID is [17:0].


Actuality device id is 32bit field.



However, given that DeviceID will be used by DOM0 to only configure
the ITS.
We have no need to use to have the DOM0 DeviceID equal to the host
DeviceID.
So I think we could simplify our life by generating DeviceID for
each RID
range.


If DOM0 DeviceID != host Device ID, then we cannot initialize ITS
using DOM0
ITS commands (MAPD). So, is it concluded that ITS initializes all the
devices
with platform specific Device ID's in Xen?.


Initializing ITS using DOM0 ITS command is a workaround until we get
PCI passthrough done. It would still be possible to implement that
with vDeviceID != pDeviceID as Xen would likely have the mapping
between the 2 DeviceID.



I believe mapping dom0 ITS commands to XEN ITS commands one to one is
the better approach.  Physical DeviceID is unique per ITS group, not a
system wide unique ID.


As for guest, you don't care about the virtual DeviceID for DOM0 as long 
as you are able to map it to the host ITS and host DeviceID.


> In case of direct VLPI,  LPI number has to be

programmed whenever dom0/domU calls the MAPTI command but not at the
time of PCIe device creation.


I am a bit confused. Why are you speaking about direct vLPI here? This 
has no relation with the IORT.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 3/3] xl: split out xl_parse.[ch]

[Ian Jackson]

Wei Liu writes ("[PATCH 3/3] xl: split out xl_parse.[ch]"):
> Move all parsing code into xl_parse.c. Export the ones needed in
> xl_parse.h.

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH 1/3] xl: rename cpurange_parse to parse_cpurange

[Ian Jackson]

Wei Liu writes ("[PATCH 1/3] xl: rename cpurange_parse to parse_cpurange"):
> We want to consistently prefix functions to parse input with "parse_".

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH 2/3] xl: introduce a function to get shutdown action name

[Ian Jackson]

Wei Liu writes ("[PATCH 2/3] xl: introduce a function to get shutdown action 
name"):
> The array to map libxl_shutdown_action_to_shutdown to string is going to
> be moved to a dedicated file.

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH RESEND RFC 0/8] Memory scrubbing from idle loop

[Andrew Cooper]

On 27/02/17 17:06, Boris Ostrovsky wrote:
>>> This series adds support for scrubbing released pages from idle loop,
>>> making guest destruction significantly faster. For example, destroying a
>>> 1TB guest can now be completed in slightly over 1 minute as opposed to
>>> about 9 minutes using existing scrubbing algorithm.
>> What is this 1m now?  I'd have thought that freeing memory would become
>> an O(1) splice from the domain pagelist onto the to-be-scrubbed list,
>> although I see that isn't quite how you have implemented it.
> I believe we are spending lots of time in relinquish_memory() due to
> hypercall restarts. And in general relinquish_memory() is linear in
> terms of number of pages.

Hmm. There is also no trivial way to make it better than O(n).

Oh well.  For now, a 10x improvement is definitely better than nothing.

>
>
>> As a couple of other thoughts, how about getting rid of the boot time
>> explicit scrub by initialising the entire heap as needing scrubbing? 
>> That way, scrubbing will start happening as soon as the APs hit their
>> idle loops, rather than later in one explicit action once dom0 is
>> constructed.
> I can try this.
>
>> How about marking pages as needing scrubbing at the end of alloc(),
>> rather than in free() ?  That way you don't need to walk the pagelists
>> just to set the pending_scrub flag.
> Do we know that all allocations need a scrubbing at the release time? We
> have 'scrub = !!d->is_dying' so it's possible that not all freed pages
> need to be scrubbed.

The !!d->is_dying is an optimisation for ballooning, where we trust the
balloon driver not to hand back sensitive data.  IMO this is poor
behaviour, especially as it doesn't mitigate the damage of a buggy
balloon driver which frees up the wrong RAM out of a guest.

In reality, all pages freed should be assumed dirty.  Everything
allocation going guest-wards definitely should be zeroed.

Allocations for Xen could come straight off the dirty list if it is
known ahead of time that the code will fully initialise the page
itself.  Otherwise, it would be better to have the alloc() subsystem to
guarantee to hand out zeroed pages (unless dirty is explicitly
requested), at which point we could drop some of the code doing explicit
re-zeroing because we don't know for certain that the allocated page is
actually clear.

(Thinking about it, it might eventually be worth having a
CONFIG_DEBUG_ZEROED_ALLOC option which checks allocations and panics if
we don't hand a zeroed page back.)

>
> I was also thinking that really we need to only mark the head as needing
> a scrub so perhaps we don't need to walk the whole list setting the
> dirty bit.
>
>>> The downside of this series is that we sometimes fail to allocate high-order
>>> sets of pages since dirty pages may not yet be merged into higher-order sets
>>> while they are waiting to be scrubbed.
>> I presume there is no sensible way to try and prioritise the pages which
>> would have greatest effect for recreating higher-order sets?
> I am currently scrubbing as 'for ( order = MAX_ORDER; order >= 0;
> order-- )' but I wonder whether I should do this in ascending order so
> that dirty chunks are merged up sooner.

I am not familiar with the details, so will defer to your judgement.

>>> Briefly, the new algorithm places dirty pages at the end of heap's page list
>>> for each node/zone/order to avoid having to scan full list while searching
>>> for dirty pages. One processor form each node checks whether the node has 
>>> any
>>> dirty pages and, if such pages are found, scrubs them. Scrubbing itself
>>> happens without holding heap lock so other users may access heap in the
>>> meantime. If while idle loop is scrubbing a particular chunk of pages this
>>> chunk is requested by the heap allocator, scrubbing is immediately stopped.
>> Why not maintain two lists?  That way it is O(1) to find either a clean
>> or dirty free page.
> Since dirty pages are always at the tail of page lists we are not really
> searching the lists. As soon as a clean page is found (starting from the
> tail) we can stop.

On this point, ok.  However, multiple lists might make the fine grain
locking easer.

(I guess it will be better not to needlessly optimise this case before
the more obvious changes are made.)

>>> On the allocation side, alloc_heap_pages() first tries to satisfy allocation
>>> request using only clean pages. If this is not possible, the search is
>>> repeated and dirty pages are scrubbed by the allocator.
>>>
>>> This series needs to be fixed up for ARM and may have a few optimizations
>>> added (and possibly some cleanup). I also need to decide what to do about
>>> nodes without processors.
>>>
>>> I originally intended to add per-node heap locks
>> Is this why scrubbing is limited to a single processor per node?  What
>> kind of performance impact does this give?
> My reasoning was that one processor would already make the memory
> controller busy enough so that adding another 

[Xen-devel] [PATCH 1/3] xl: rename cpurange_parse to parse_cpurange

[Wei Liu]

We want to consistently prefix functions to parse input with "parse_".

No functional change.

Signed-off-by: Wei Liu 
---
 tools/xl/xl_cmdimpl.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/tools/xl/xl_cmdimpl.c b/tools/xl/xl_cmdimpl.c
index 2721af317b..86c70f5a22 100644
--- a/tools/xl/xl_cmdimpl.c
+++ b/tools/xl/xl_cmdimpl.c
@@ -697,7 +697,7 @@ static int update_cpumap_range(const char *str, 
libxl_bitmap *cpumap)
  * single cpus or as eintire NUMA nodes) and turns it into the
  * corresponding libxl_bitmap (in cpumap).
  */
-static int cpurange_parse(const char *cpu, libxl_bitmap *cpumap)
+static int parse_cpurange(const char *cpu, libxl_bitmap *cpumap)
 {
 char *ptr, *saveptr = NULL, *buf = xstrdup(cpu);
 int rc = 0;
@@ -808,7 +808,7 @@ static void parse_vcpu_affinity(libxl_domain_build_info 
*b_info,
 exit(EXIT_FAILURE);
 }
 
-if (cpurange_parse(buf, _affinity_array[j]))
+if (parse_cpurange(buf, _affinity_array[j]))
 exit(EXIT_FAILURE);
 
 j++;
@@ -825,7 +825,7 @@ static void parse_vcpu_affinity(libxl_domain_build_info 
*b_info,
 exit(EXIT_FAILURE);
 }
 
-if (cpurange_parse(buf, _affinity_array[0]))
+if (parse_cpurange(buf, _affinity_array[0]))
 exit(EXIT_FAILURE);
 
 for (i = 1; i < b_info->max_vcpus; i++) {
@@ -5522,7 +5522,7 @@ int main_vcpupin(int argc, char **argv)
  */
 if (!strcmp(hard_str, "-"))
 hard = NULL;
-else if (cpurange_parse(hard_str, hard))
+else if (parse_cpurange(hard_str, hard))
 goto out;
 /*
  * Soft affinity is handled similarly. Only difference: we also want
@@ -5530,7 +5530,7 @@ int main_vcpupin(int argc, char **argv)
  */
 if (argc <= optind+3 || !strcmp(soft_str, "-"))
 soft = NULL;
-else if (cpurange_parse(soft_str, soft))
+else if (parse_cpurange(soft_str, soft))
 goto out;
 
 if (dryrun_only) {
@@ -7793,7 +7793,7 @@ int main_cpupoolcreate(int argc, char **argv)
 n_cpus++;
 }
 } else if (!xlu_cfg_get_string(config, "cpus", , 0)) {
-if (cpurange_parse(buf, ))
+if (parse_cpurange(buf, ))
 goto out_cfg;
 
 n_cpus = 0;
@@ -7974,7 +7974,7 @@ int main_cpupoolcpuadd(int argc, char **argv)
 }
 
 pool = argv[optind++];
-if (cpurange_parse(argv[optind], ))
+if (parse_cpurange(argv[optind], ))
 goto out;
 
 if (libxl_cpupool_qualifier_to_cpupoolid(ctx, pool, , NULL) ||
@@ -8012,7 +8012,7 @@ int main_cpupoolcpuremove(int argc, char **argv)
 }
 
 pool = argv[optind++];
-if (cpurange_parse(argv[optind], ))
+if (parse_cpurange(argv[optind], ))
 goto out;
 
 if (libxl_cpupool_qualifier_to_cpupoolid(ctx, pool, , NULL) ||
-- 
2.11.0


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

[Xen-devel] [PATCH 2/2] xl: split out vnc and console related code

[Wei Liu]

The new file also contains code for channel, which is just a console
in disguise.

Replace the call to vncviewer() with libxl_vncviewer_exec() directly in
main_vncviewer.

Signed-off-by: Wei Liu 
---
 tools/xl/Makefile |   2 +-
 tools/xl/xl_cmdimpl.c |  99 --
 tools/xl/xl_console.c | 130 ++
 3 files changed, 131 insertions(+), 100 deletions(-)
 create mode 100644 tools/xl/xl_console.c

diff --git a/tools/xl/Makefile b/tools/xl/Makefile
index bc8cfb3de9..7375d2bfda 100644
--- a/tools/xl/Makefile
+++ b/tools/xl/Makefile
@@ -19,7 +19,7 @@ XL_OBJS = xl.o xl_cmdimpl.o xl_cmdtable.o xl_sxp.o xl_utils.o
 XL_OBJS += xl_tmem.o xl_parse.o xl_cpupool.o xl_flask.o
 XL_OBJS += xl_vtpm.o xl_block.o xl_nic.o xl_usb.o
 XL_OBJS += xl_sched.o xl_pci.o xl_vcpu.o xl_cdrom.o xl_mem.o
-XL_OBJS += xl_psr.o xl_info.o
+XL_OBJS += xl_psr.o xl_info.o xl_console.o
 
 $(XL_OBJS): CFLAGS += $(CFLAGS_libxentoollog)
 $(XL_OBJS): CFLAGS += $(CFLAGS_XL)
diff --git a/tools/xl/xl_cmdimpl.c b/tools/xl/xl_cmdimpl.c
index a42b972d60..958058cadb 100644
--- a/tools/xl/xl_cmdimpl.c
+++ b/tools/xl/xl_cmdimpl.c
@@ -1071,61 +1071,6 @@ void help(const char *command)
 }
 }
 
-int main_console(int argc, char **argv)
-{
-uint32_t domid;
-int opt = 0, num = 0;
-libxl_console_type type = 0;
-
-SWITCH_FOREACH_OPT(opt, "n:t:", NULL, "console", 1) {
-case 't':
-if (!strcmp(optarg, "pv"))
-type = LIBXL_CONSOLE_TYPE_PV;
-else if (!strcmp(optarg, "serial"))
-type = LIBXL_CONSOLE_TYPE_SERIAL;
-else {
-fprintf(stderr, "console type supported are: pv, serial\n");
-return EXIT_FAILURE;
-}
-break;
-case 'n':
-num = atoi(optarg);
-break;
-}
-
-domid = find_domain(argv[optind]);
-if (!type)
-libxl_primary_console_exec(ctx, domid, -1);
-else
-libxl_console_exec(ctx, domid, num, type, -1);
-fprintf(stderr, "Unable to attach console\n");
-return EXIT_FAILURE;
-}
-
-int main_vncviewer(int argc, char **argv)
-{
-static const struct option opts[] = {
-{"autopass", 0, 0, 'a'},
-{"vncviewer-autopass", 0, 0, 'a'},
-COMMON_LONG_OPTS
-};
-uint32_t domid;
-int opt, autopass = 0;
-
-SWITCH_FOREACH_OPT(opt, "a", opts, "vncviewer", 1) {
-case 'a':
-autopass = 1;
-break;
-}
-
-domid = find_domain(argv[optind]);
-
-libxl_vncviewer_exec(ctx, domid, autopass);
-fprintf(stderr, "Unable to execute vncviewer\n");
-
-return EXIT_FAILURE;
-}
-
 static void pause_domain(uint32_t domid)
 {
 libxl_domain_pause(ctx, domid);
@@ -2515,50 +2460,6 @@ int main_debug_keys(int argc, char **argv)
 return EXIT_SUCCESS;
 }
 
-int main_channellist(int argc, char **argv)
-{
-int opt;
-libxl_device_channel *channels;
-libxl_channelinfo channelinfo;
-int nb, i;
-
-SWITCH_FOREACH_OPT(opt, "", NULL, "channel-list", 1) {
-/* No options */
-}
-
-/*  Idx BE state evt-ch ring-ref connection params*/
-printf("%-3s %-2s %-5s %-6s %8s %-10s %-30s\n",
-   "Idx", "BE", "state", "evt-ch", "ring-ref", "connection", "");
-for (argv += optind, argc -= optind; argc > 0; --argc, ++argv) {
-uint32_t domid = find_domain(*argv);
-channels = libxl_device_channel_list(ctx, domid, );
-if (!channels)
-continue;
-for (i = 0; i < nb; ++i) {
-if (!libxl_device_channel_getinfo(ctx, domid, [i],
-)) {
-printf("%-3d %-2d ", channels[i].devid, 
channelinfo.backend_id);
-printf("%-5d ", channelinfo.state);
-printf("%-6d %-8d ", channelinfo.evtch, channelinfo.rref);
-printf("%-10s ", libxl_channel_connection_to_string(
-   channels[i].connection));
-switch (channels[i].connection) {
-case LIBXL_CHANNEL_CONNECTION_PTY:
-printf("%-30s ", channelinfo.u.pty.path);
-break;
-default:
-break;
-}
-printf("\n");
-libxl_channelinfo_dispose();
-}
-libxl_device_channel_dispose([i]);
-}
-free(channels);
-}
-return 0;
-}
-
 #ifndef LIBXL_HAVE_NO_SUSPEND_RESUME
 int main_remus(int argc, char **argv)
 {
diff --git a/tools/xl/xl_console.c b/tools/xl/xl_console.c
new file mode 100644
index 00..0508ddaa32
--- /dev/null
+++ b/tools/xl/xl_console.c
@@ -0,0 +1,130 @@
+/*
+ * Copyright 2009-2017 Citrix Ltd and other contributors
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception 

[Xen-devel] [PATCH 1/2] xl: call libxl_vncviewer_exec in main_vncviewer

[Wei Liu]

We will need to move main_vncviewer to a different file where it has no
access to the helper vncviewer.

Call libxl_vncviewer_exec directly.

Signed-off-by: Wei Liu 
---
 tools/xl/xl_cmdimpl.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/tools/xl/xl_cmdimpl.c b/tools/xl/xl_cmdimpl.c
index 26fd4ab0f5..a42b972d60 100644
--- a/tools/xl/xl_cmdimpl.c
+++ b/tools/xl/xl_cmdimpl.c
@@ -1120,9 +1120,10 @@ int main_vncviewer(int argc, char **argv)
 
 domid = find_domain(argv[optind]);
 
-if (vncviewer(domid, autopass))
-return EXIT_FAILURE;
-return EXIT_SUCCESS;
+libxl_vncviewer_exec(ctx, domid, autopass);
+fprintf(stderr, "Unable to execute vncviewer\n");
+
+return EXIT_FAILURE;
 }
 
 static void pause_domain(uint32_t domid)
-- 
2.11.0


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

[Xen-devel] [PATCH 2/3] xl: introduce a function to get shutdown action name

[Wei Liu]

The array to map libxl_shutdown_action_to_shutdown to string is going to
be moved to a dedicated file.

Provide a function to do the translation so that we don't need to make
the array globally visible.

Signed-off-by: Wei Liu 
---
 tools/xl/xl_cmdimpl.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/tools/xl/xl_cmdimpl.c b/tools/xl/xl_cmdimpl.c
index 86c70f5a22..d027d53a3f 100644
--- a/tools/xl/xl_cmdimpl.c
+++ b/tools/xl/xl_cmdimpl.c
@@ -101,6 +101,11 @@ static const char *action_on_shutdown_names[] = {
 [LIBXL_ACTION_ON_SHUTDOWN_SOFT_RESET] = "soft-reset",
 };
 
+static const char *get_action_on_shutdown_name(libxl_action_on_shutdown a)
+{
+return action_on_shutdown_names[a];
+}
+
 /* Optional data, in order:
  *   4 bytes uint32_t  config file size
  *   n bytes   config file in Unix text file format
@@ -2442,7 +2447,7 @@ static domain_restart_type handle_domain_death(uint32_t 
*r_domid,
 
 LOG("Action for shutdown reason code %d is %s",
 event->u.domain_shutdown.shutdown_reason,
-action_on_shutdown_names[action]);
+get_action_on_shutdown_name(action));
 
 if (action == LIBXL_ACTION_ON_SHUTDOWN_COREDUMP_DESTROY || action == 
LIBXL_ACTION_ON_SHUTDOWN_COREDUMP_RESTART) {
 char *corefile;
-- 
2.11.0


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

[Xen-devel] [PATCH] xl: move some helper functions to xl_utils.c

[Wei Liu]

Move some commonly used functions to a new file.

find_domain requires access to global variable common_domname. Make that
non-static.

No functional change.

Signed-off-by: Wei Liu 
---
 tools/xl/Makefile |   2 +-
 tools/xl/xl_cmdimpl.c | 221 +-
 tools/xl/xl_utils.c   | 258 ++
 tools/xl/xl_utils.h   |  27 ++
 4 files changed, 287 insertions(+), 221 deletions(-)
 create mode 100644 tools/xl/xl_utils.c

diff --git a/tools/xl/Makefile b/tools/xl/Makefile
index 7106009d66..2f740b4789 100644
--- a/tools/xl/Makefile
+++ b/tools/xl/Makefile
@@ -15,7 +15,7 @@ LDFLAGS += $(PTHREAD_LDFLAGS)
 CFLAGS_XL += $(CFLAGS_libxenlight)
 CFLAGS_XL += -Wshadow
 
-XL_OBJS = xl.o xl_cmdimpl.o xl_cmdtable.o xl_sxp.o
+XL_OBJS = xl.o xl_cmdimpl.o xl_cmdtable.o xl_sxp.o xl_utils.o
 $(XL_OBJS): CFLAGS += $(CFLAGS_libxentoollog)
 $(XL_OBJS): CFLAGS += $(CFLAGS_XL)
 $(XL_OBJS): CFLAGS += -include $(XEN_ROOT)/tools/config.h # libxl_json.h needs 
it.
diff --git a/tools/xl/xl_cmdimpl.c b/tools/xl/xl_cmdimpl.c
index d9d947827d..de9e6add65 100644
--- a/tools/xl/xl_cmdimpl.c
+++ b/tools/xl/xl_cmdimpl.c
@@ -19,7 +19,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -48,7 +47,7 @@ libxl_ctx *ctx;
 
 xlchild children[child_max];
 
-static const char *common_domname;
+const char *common_domname;
 static int fd_lock = -1;
 
 static const char savefileheader_magic[32]=
@@ -129,22 +128,6 @@ struct domain_create {
 char **migration_domname_r; /* from malloc */
 };
 
-
-static uint32_t find_domain(const char *p) __attribute__((warn_unused_result));
-static uint32_t find_domain(const char *p)
-{
-uint32_t domid;
-int rc;
-
-rc = libxl_domain_qualifier_to_domid(ctx, p, );
-if (rc) {
-fprintf(stderr, "%s is an invalid domain identifier (rc=%d)\n", p, rc);
-exit(EXIT_FAILURE);
-}
-common_domname = libxl_domid_to_name(ctx, domid);
-return domid;
-}
-
 int child_report(xlchildnum child)
 {
 int status;
@@ -253,47 +236,6 @@ release_lock:
 return rc;
 }
 
-static void *xmalloc(size_t sz) {
-void *r;
-r = malloc(sz);
-if (!r) { fprintf(stderr,"xl: Unable to malloc %lu bytes.\n",
-  (unsigned long)sz); exit(-ERROR_FAIL); }
-return r;
-}
-
-static void *xcalloc(size_t n, size_t sz) __attribute__((unused));
-static void *xcalloc(size_t n, size_t sz) {
-void *r = calloc(n, sz);
-if (!r) {
-fprintf(stderr,"xl: Unable to calloc %zu bytes.\n", sz*n);
-exit(-ERROR_FAIL);
-}
-return r;
-}
-
-static void *xrealloc(void *ptr, size_t sz) {
-void *r;
-if (!sz) { free(ptr); return 0; }
-  /* realloc(non-0, 0) has a useless return value;
-   * but xrealloc(anything, 0) is like free
-   */
-r = realloc(ptr, sz);
-if (!r) { fprintf(stderr,"xl: Unable to realloc to %lu bytes.\n",
-  (unsigned long)sz); exit(-ERROR_FAIL); }
-return r;
-}
-
-static char *xstrdup(const char *x)
-{
-char *r;
-r = strdup(x);
-if (!r) {
-fprintf(stderr, "xl: Unable to strdup a string of length %zu.\n",
-strlen(x));
-exit(-ERROR_FAIL);
-}
-return r;
-}
 
 #define ARRAY_EXTEND_INIT__CORE(array,count,initfn,more)\
 ({  \
@@ -313,46 +255,6 @@ static char *xstrdup(const char *x)
 #define ARRAY_EXTEND_INIT_NODEVID(array,count,initfn) \
 ARRAY_EXTEND_INIT__CORE((array),(count),(initfn), /* nothing */ )
 
-static void dolog(const char *file, int line, const char *func, char *fmt, ...)
- __attribute__((format(printf,4,5)));
-
-static void dolog(const char *file, int line, const char *func, char *fmt, ...)
-{
-va_list ap;
-char *s = NULL;
-int rc;
-
-va_start(ap, fmt);
-rc = vasprintf(, fmt, ap);
-va_end(ap);
-if (rc >= 0)
-/* we ignore write errors since we have no way to report them;
- * the alternative would be to abort the whole program */
-libxl_write_exactly(NULL, logfile, s, rc, NULL, NULL);
-free(s);
-}
-
-static void xvasprintf(char **strp, const char *fmt, va_list ap)
-__attribute__((format(printf,2,0)));
-static void xvasprintf(char **strp, const char *fmt, va_list ap)
-{
-int r = vasprintf(strp, fmt, ap);
-if (r == -1) {
-perror("asprintf failed");
-exit(EXIT_FAILURE);
-}
-}
-
-static void xasprintf(char **strp, const char *fmt, ...)
-__attribute__((format(printf,2,3)));
-static void xasprintf(char **strp, const char *fmt, ...)
-{
-va_list ap;
-va_start(ap, fmt);
-xvasprintf(strp, fmt, ap);
-va_end(ap);
-}
-
 static yajl_gen_status printf_info_one_json(yajl_gen hand, int domid,
 libxl_domain_config *d_config)
 {
@@ -389,19 +291,6 @@ out:
 return s;
 }
 
-static void 

Re: [Xen-devel] OVMF blows up at unless I use pci_platform=0

[Konrad Rzeszutek Wilk]

On Mon, Feb 20, 2017 at 03:49:31PM +, Anthony PERARD wrote:
> On Wed, Feb 15, 2017 at 08:37:44PM -0500, Konrad Rzeszutek Wilk wrote:
> > Hey,
> > 
> > I just built today Xen based on  93e1435290867703c50acad1f54b9208df473562
> > Author: Oleksandr Tyshchenko 
> > Date:   Wed Feb 15 12:20:01 2017 +
> > 
> > IOMMU: always call teardown callback
> > 
> [...]
> > #xl create -c root-image-uefi.xm
> > I get:
> > 
> >  X64 Exception Type - 0E(#PF - Page-Fault)  CPU Apic ID -  
> > RIP  - 3F2658DB, CS  - 0038, RFLAGS - 00010206
> > ExceptionData - 0002
> > RAX  - 0001, RCX - 3F2658BB, RDX - 0004
> > RBX  - , RSP - 3F43B510, RBP - 3E574D18
> > RSI  - 0003, RDI - 0001
> > R8   - , R9  - , R10 - 3EA39198
> > R11  - 0002, R12 - 3E575218, R13 - 
> > R14  - 3E575220, R15 - 3F269301
> > DS   - 0030, ES  - 0030, FS  - 0030
> > GS   - 0030, SS  - 0030
> > CR0  - C033, CR2 - BF2658BB, CR3 - 3F3DA000
> > CR4  - 0668, CR8 - 
> > DR0  - , DR1 - , DR2 - 
> > DR3  - , DR6 - 0FF0, DR7 - 0400
> > GDTR - 3F3C8A98 0047, LDTR - 
> > IDTR - 3EAFD018 0FFF,   TR - 
> > FXSAVE_STATE - 3F43B170
> >  Find PE image 
> > /home/konrad/xen/tools/firmware/ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC5/X64/OvmfPkg/XenBusDxe/XenBusDxe/DEBUG/XenBusDxe.dll
> >  (ImageBase=3F262000, EntryPoint=3F263FE8) 
> 
> Which version of gcc did you compile OVMF with?


gcc (GCC) 6.3.1 20161221 (Red Hat 6.3.1-1)
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

> 
> I can reproduce with a "Page-Fault" in the same modules, but with an OVMF
> binary compiled later, I have a "General Protection" fault in the module
> PcRtc...
> 
> I blame -flto of gcc.

Oh..
> 
> If you have gcc 6.3, to build ovmf without -flto, either:
> - build using OvmfPkg/build.sh -a X64 -n 4 -t GCC49
> (that is "-t GCC49" added to ./build.sh call)
> - or edit OvmfPkg/build.sh, replace GCC5 by GCC49.

OK, let me try that.
> 
> I can try to find out what is wrong, and report it upstream.
> 
> -- 
> Anthony PERARD

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

Re: [Xen-devel] [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

[Michal Hocko]

On Mon 27-02-17 11:28:52, Reza Arbab wrote:
> On Mon, Feb 27, 2017 at 10:28:17AM +0100, Michal Hocko wrote:
> >diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
> >index 134a2f69c21a..a72f7f64ee26 100644
> >--- a/include/linux/memory_hotplug.h
> >+++ b/include/linux/memory_hotplug.h
> >@@ -100,8 +100,6 @@ extern void __online_page_free(struct page *page);
> >
> >extern int try_online_node(int nid);
> >
> >-extern bool memhp_auto_online;
> >-
> >#ifdef CONFIG_MEMORY_HOTREMOVE
> >extern bool is_pageblock_removable_nolock(struct page *page);
> >extern int arch_remove_memory(u64 start, u64 size);
> >@@ -272,7 +270,7 @@ static inline void remove_memory(int nid, u64 start, u64 
> >size) {}
> >
> >extern int walk_memory_range(unsigned long start_pfn, unsigned long end_pfn,
> > void *arg, int (*func)(struct memory_block *, void *));
> >-extern int add_memory(int nid, u64 start, u64 size);
> >+extern int add_memory(int nid, u64 start, u64 size, bool online);
> >extern int add_memory_resource(int nid, struct resource *resource, bool 
> >online);
> >extern int zone_for_memory(int nid, u64 start, u64 size, int zone_default,
> > bool for_device);
> 
> It would be nice if instead of a 'bool online' argument, add_memory() and
> add_memory_resource() took an 'int online_type', ala online_pages().
> 
> That way we could specify offline, online, online+movable, etc.

Sure that would require more changes though and as such it is out of
scope of this patch. But you are right, this is a logical follow up
step.
-- 
Michal Hocko
SUSE Labs

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

Re: [Xen-devel] [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

[Reza Arbab]

On Mon, Feb 27, 2017 at 10:28:17AM +0100, Michal Hocko wrote: 

diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
index 134a2f69c21a..a72f7f64ee26 100644
--- a/include/linux/memory_hotplug.h
+++ b/include/linux/memory_hotplug.h
@@ -100,8 +100,6 @@ extern void __online_page_free(struct page *page);

extern int try_online_node(int nid);

-extern bool memhp_auto_online;
-
#ifdef CONFIG_MEMORY_HOTREMOVE
extern bool is_pageblock_removable_nolock(struct page *page);
extern int arch_remove_memory(u64 start, u64 size);
@@ -272,7 +270,7 @@ static inline void remove_memory(int nid, u64 start, u64 
size) {}

extern int walk_memory_range(unsigned long start_pfn, unsigned long end_pfn,
void *arg, int (*func)(struct memory_block *, void *));
-extern int add_memory(int nid, u64 start, u64 size);
+extern int add_memory(int nid, u64 start, u64 size, bool online);
extern int add_memory_resource(int nid, struct resource *resource, bool online);
extern int zone_for_memory(int nid, u64 start, u64 size, int zone_default,
bool for_device);


It would be nice if instead of a 'bool online' argument, add_memory() 
and add_memory_resource() took an 'int online_type', ala online_pages().


That way we could specify offline, online, online+movable, etc.

--
Reza Arbab


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

Re: [Xen-devel] [PATCH 09/28] ARM: GICv3 ITS: map device and LPIs to the ITS on physdev_op hypercall

[Andre Przywara]

Hi,

On 24/02/17 19:57, Shanker Donthineni wrote:
> Hi Julien,
> 
> 
> On 01/31/2017 10:18 AM, Julien Grall wrote:
>>
>>
>> On 31/01/17 16:02, Jaggi, Manish wrote:
>>>
>>>
>>> On 1/31/2017 8:47 PM, Julien Grall wrote:


 On 31/01/17 14:08, Jaggi, Manish wrote:
> Hi Julien,
>
> On 1/31/2017 7:16 PM, Julien Grall wrote:
>> On 31/01/17 13:19, Jaggi, Manish wrote:
>>> On 1/31/2017 6:13 PM, Julien Grall wrote:
 On 31/01/17 10:29, Jaggi, Manish wrote:
> If you please go back to your comment where you wrote "we need to
> find another way to get the DeviceID", I was referring that we
> should add that another way in this series so that correct DeviceID
> is programmed in ITS.

 This is not the first time I am saying this, just saying "we should
 add that another way..." is not helpful. You should also provide
 some details on what you would do.

>>> Julien, As you suggested we need to find another way, I assumed you
>>> had something in mind.
>>
>> I gave suggestions on my e-mail but you may have missed it...
>>
>>> Since we both agree that sbdf!=deviceID, the current series of ITS
>>> patches will program the incorrect deviceID so there is a need to
>>> have a way to map sbdf with deviceID in xen.
>>>
>>> One option could be to add a new hypercall to supply sbdf and
>>> deviceID to xen.
>>
>> ... as well as the part where I am saying that I am not in favor to
>> implement an hypercall temporarily, and against adding a new hypercall
>> for only a couple of weeks. As you may know PHYSDEV hypercall are part
>> of the stable ABI and once they are added they cannot be removed.
>>
>> So we need to be sure the hypercall is necessary. In this case, the
>> hypercall is not necessary as all the information can be found in the
>> firmware tables. However this is not implemented yet and part of the
>> discussion on PCI Passthrough (see [1]).
>>
>> We need a temporary solution that does not involve any commitment on the
>> ABI until Xen is able to discover PCI.
>>
> 
> Why can't  we handle ITS device creation whenever a virtual ITS driver
> receives the MAPD command from dom0/domU. In case of dom0, it's straight
> forward dom0 always passes the real ITS device through MAPD command.
> This way we can support PCIe devices without hard-coded MSI(x) limit 32,
> and platform devices transparently. I used the below code to platform
> and PCIe device MSI(x) functionality on QDF2400 server platform.

But this breaks our assumption that no ITS commands can ever be
propagated at guest's runtime, which is the cornerstone of this series.
I agree that this is unfortunate and allowing it would simplify things,
but after long discussions we came to the conclusion that it's not
feasible to do so:
A malicious guest could flood the virtual ITS with MAPD commands. Xen
would need to propagate those to the hardware, which relies on the host
command queue to have free slots, which we can't guarantee. For
technical reasons we can't reschedule the guest (because this is an MMIO
trap), also the domain actually triggering the "final" MAPD might not be
the culprit, but an actual legitimate user.
So we agreed upon issuing all hardware ITS commands before a guest
actually starts (DomUs), respectively on hypercalls for Dom0.
I think we can do exceptions for Dom0, since it's not supposed to be
malicious.
So I'd suggest the following:
- To make Dom0 run in this version of the patches, especially with
platform devices, we allow MAPDs to propagate from Dom0.
  - We check whether this device has already  been mapped. If yes, we
map the virtual side and return.
  - If not mapped already, we possibly somehow sanitize the device ID
(using some platform-specific function, for instance) and issue the MAPD
and all the possible MAPTIs to the hardware ITS. We might avoid this in
the future, when we have proper passthrough support in place.

So PCI devices would be mapped by the PHYSOPS hypercall as before, but
platform devices would be handled via this way.

Does this make sense?

I need to work out the details, keep you posted ...

Cheers,
Andre.

> 
> @@ -383,10 +384,17 @@ static int its_handle_mapd(struct virt_its *its,
> uint64_t *cmdptr)
>  int size = its_cmd_get_size(cmdptr);
>  bool valid = its_cmd_get_validbit(cmdptr);
>  paddr_t itt_addr = its_cmd_mask_field(cmdptr, 2, 0, 52) &
> GENMASK(51, 8);
> +int ret;
> 
>  if ( !its->dev_table )
>  return -1;
> 
> +size = size < 4 ? 4 : size;
> +ret = gicv3_its_map_guest_device(hardware_domain, devid, devid,
> size + 1,
> + valid);
> +if (ret < 0)
> +return ret;
> +
> 
> 

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

Re: [Xen-devel] [PATCH RESEND RFC 1/8] mm: Separate free page chunk merging into its own routine

[Boris Ostrovsky]

On 02/27/2017 11:29 AM, Dario Faggioli wrote:
> On Sun, 2017-02-26 at 19:37 -0500, Boris Ostrovsky wrote:
>> This is needed for subsequent changes to memory scrubbing.
>>
> So, this is "just" code motion and factorization, right?
>
> If yes, I think the changelog should say so.

Right, there is no real logic change.

-boris



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

Re: [Xen-devel] [PATCH RESEND RFC 0/8] Memory scrubbing from idle loop

[Boris Ostrovsky]

>> This series adds support for scrubbing released pages from idle loop,
>> making guest destruction significantly faster. For example, destroying a
>> 1TB guest can now be completed in slightly over 1 minute as opposed to
>> about 9 minutes using existing scrubbing algorithm.
> What is this 1m now?  I'd have thought that freeing memory would become
> an O(1) splice from the domain pagelist onto the to-be-scrubbed list,
> although I see that isn't quite how you have implemented it.

I believe we are spending lots of time in relinquish_memory() due to
hypercall restarts. And in general relinquish_memory() is linear in
terms of number of pages.


>
> As a couple of other thoughts, how about getting rid of the boot time
> explicit scrub by initialising the entire heap as needing scrubbing? 
> That way, scrubbing will start happening as soon as the APs hit their
> idle loops, rather than later in one explicit action once dom0 is
> constructed.

I can try this.

>
> How about marking pages as needing scrubbing at the end of alloc(),
> rather than in free() ?  That way you don't need to walk the pagelists
> just to set the pending_scrub flag.

Do we know that all allocations need a scrubbing at the release time? We
have 'scrub = !!d->is_dying' so it's possible that not all freed pages
need to be scrubbed.

I was also thinking that really we need to only mark the head as needing
a scrub so perhaps we don't need to walk the whole list setting the
dirty bit.

>
>> The downside of this series is that we sometimes fail to allocate high-order
>> sets of pages since dirty pages may not yet be merged into higher-order sets
>> while they are waiting to be scrubbed.
> I presume there is no sensible way to try and prioritise the pages which
> would have greatest effect for recreating higher-order sets?

I am currently scrubbing as 'for ( order = MAX_ORDER; order >= 0;
order-- )' but I wonder whether I should do this in ascending order so
that dirty chunks are merged up sooner.

>
>> Briefly, the new algorithm places dirty pages at the end of heap's page list
>> for each node/zone/order to avoid having to scan full list while searching
>> for dirty pages. One processor form each node checks whether the node has any
>> dirty pages and, if such pages are found, scrubs them. Scrubbing itself
>> happens without holding heap lock so other users may access heap in the
>> meantime. If while idle loop is scrubbing a particular chunk of pages this
>> chunk is requested by the heap allocator, scrubbing is immediately stopped.
> Why not maintain two lists?  That way it is O(1) to find either a clean
> or dirty free page.

Since dirty pages are always at the tail of page lists we are not really
searching the lists. As soon as a clean page is found (starting from the
tail) we can stop.


>
>> On the allocation side, alloc_heap_pages() first tries to satisfy allocation
>> request using only clean pages. If this is not possible, the search is
>> repeated and dirty pages are scrubbed by the allocator.
>>
>> This series needs to be fixed up for ARM and may have a few optimizations
>> added (and possibly some cleanup). I also need to decide what to do about
>> nodes without processors.
>>
>> I originally intended to add per-node heap locks
> Is this why scrubbing is limited to a single processor per node?  What
> kind of performance impact does this give?

My reasoning was that one processor would already make the memory
controller busy enough so that adding another core banging on it
wouldn't make things any better. But I haven't made any comparisons with
multiple cores doing this.

-boris


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

Re: [Xen-devel] Crash w/ bios="ovmf"

[Konrad Rzeszutek Wilk]

On Wed, Feb 22, 2017 at 03:50:28PM -0500, Jason Dickens wrote:
> I'm trying to find a solution to an immediate VM crash which occurs by
> simply adding "bios='ovmf' to my configuration?
> 
> I started with a standard Ubuntu install which contained Xen 4.6.0 and had
> the crash. The VM works fine booting w/ SeaBIOS once the configuration line
> is removed. It also works fine with OVMF using just QEMU.
> 
> Then I was led to believe that i needed to rebuild Xen with --enable-ovmf ,
> using the source from apt-get source, this proved to be difficult and
> ultimately I had to disable stub domains to get it to work. (in case, that
> is relevant)
> 
> Still I get the crash almost immediately after the VM is launched. With
> sdl=1 I can see the window flash up and disappear.
> I should mention that ultimately I plan to use a non-standard build of the
> OVMF kernel, but for now I'm happy to get it working with any one.

Can you try
pci_platform=0 in your guest config pleae?

> 
> At this point, I have been studying the source to try and determine where
> things diverge. I find very little use of LIBXL_BIOS_TYPE_OVMF and can't
> find  exactly where setting hvm.bios that even matters?
> 
> In any case, I would appreciate help on how to avoid the crash and/or
> understanding the Xen modifications for OVMF.
> 
> Jason
> 
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

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

Re: [Xen-devel] xen/arm: Hiding SMMUs from Dom0 when using ACPI on Xen

[Shanker Donthineni]

Hi Julien,


On 02/27/2017 08:12 AM, Julien Grall wrote:



On 27/02/17 13:23, Vijay Kilari wrote:

Hi Julien,


Hello Vijay,

On Wed, Feb 22, 2017 at 7:40 PM, Julien Grall  
wrote:

Hello,

There was few discussions recently about hiding SMMUs from DOM0 when 
using

ACPI. I thought it would be good to have a separate thread for this.

When using ACPI, the SMMUs will be described in the IO Remapping Table
(IORT). The specification can be found on the ARM website [1].

For a brief summary, the IORT can be used to discover the SMMUs 
present on
the platform and find for a given device the ID to configure 
components such

as ITS (DeviceID) and SMMU (StreamID).

The appendix A in the specification gives an example how DeviceID and
StreamID can be found. For instance, when a PCI device is both 
protected by

an SMMU and MSI-capable the following translation will happen:
RID -> StreamID -> DeviceID

Currently, SMMUs are hidden from DOM0 because they are been used by 
Xen and
we don't support stage-1 SMMU. If we pass the IORT as it is, DOM0 
will try

to initialize SMMU and crash.

I first thought about using a Xen specific way (STAO) or extending a 
flag in

IORT. But that is not ideal.

So we would have to rewrite the IORT for DOM0. Given that a range of 
RID can
mapped to multiple ranges of DeviceID, we would have to translate 
RID one by
one to find the associated DeviceID. I think this may end up to 
complex code

and have a big IORT table.


Why can't we replace Output base of IORT of PCI node with SMMU output 
base?.

I mean similar to PCI node without SMMU, why can't replace output base
of PCI node with
SMMU's output base?.


Because I don't see anything in the spec preventing one RC ID mapping 
to produce multiple SMMU ID mapping. So which output base would you use?




Basically, remove SMMU nodes, and replaces output of the PCIe and named 
nodes ID mappings with ITS nodes.


RID --> StreamID  --> dviceID  --> ITS device id = RID --> dviceID  --> 
ITS device id




The issue I see is RID is [15:0] where is DeviceID is [17:0].


Actuality device id is 32bit field.



However, given that DeviceID will be used by DOM0 to only configure 
the ITS.
We have no need to use to have the DOM0 DeviceID equal to the host 
DeviceID.
So I think we could simplify our life by generating DeviceID for 
each RID

range.


If DOM0 DeviceID != host Device ID, then we cannot initialize ITS 
using DOM0
ITS commands (MAPD). So, is it concluded that ITS initializes all the 
devices

with platform specific Device ID's in Xen?.


Initializing ITS using DOM0 ITS command is a workaround until we get 
PCI passthrough done. It would still be possible to implement that 
with vDeviceID != pDeviceID as Xen would likely have the mapping 
between the 2 DeviceID.




I believe mapping dom0 ITS commands to XEN ITS commands one to one is 
the better approach.  Physical DeviceID is unique per ITS group, not a 
system wide unique ID. In case of direct VLPI,  LPI number has to be 
programmed whenever dom0/domU calls the MAPTI command but not at the 
time of PCIe device creation.



--
Shanker Donthineni
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.


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

Re: [Xen-devel] [PATCH 20/29] xl: split out cd related code

[Wei Liu]

On Mon, Feb 27, 2017 at 04:44:53PM +, Ian Jackson wrote:
> Wei Liu writes ("Re: [PATCH 20/29] xl: split out cd related code"):
> > On Mon, Feb 27, 2017 at 04:36:16PM +, Ian Jackson wrote:
> > > Yes, indeed, that was the only reason I didn't ack it.
> > 
> > Thanks.  I want to avoid reposting as much as possible because this
> > series is really long and tedious.
> 
> Indeed!
> 
> There were about three other patches that I had small comments on.  If
> you want to repost just those, that would be fine by me.
> 

Sure.

> Ian.

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

Re: [Xen-devel] [PATCH 20/29] xl: split out cd related code

[Ian Jackson]

Wei Liu writes ("Re: [PATCH 20/29] xl: split out cd related code"):
> On Mon, Feb 27, 2017 at 04:36:16PM +, Ian Jackson wrote:
> > Yes, indeed, that was the only reason I didn't ack it.
> 
> Thanks.  I want to avoid reposting as much as possible because this
> series is really long and tedious.

Indeed!

There were about three other patches that I had small comments on.  If
you want to repost just those, that would be fine by me.

Ian.

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

Re: [Xen-devel] [PATCH] [linux-next] xenbus: Remove duplicate inclusion of linux/init.h

[Boris Ostrovsky]

On 02/27/2017 02:56 AM, Juergen Gross wrote:
> On 26/02/17 08:15, Masanari Iida wrote:
>> This patch remove duplicate inclusion of linux/init.h in
>> xenbus_dev_frontend.c.
>> Confirm successfully compile after remove the line.
>>
>> Signed-off-by: Masanari Iida 
> Reviewed-by: Juergen Gross 


Applied to for-linus-4.11.

-boris


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

Re: [Xen-devel] [PATCH 20/29] xl: split out cd related code

[Wei Liu]

On Mon, Feb 27, 2017 at 04:36:16PM +, Ian Jackson wrote:
> Wei Liu writes ("Re: [PATCH 20/29] xl: split out cd related code"):
> > On Mon, Feb 27, 2017 at 03:56:21PM +, Ian Jackson wrote:
> > > Wei Liu writes ("[PATCH 20/29] xl: split out cd related code"):
> > > > Signed-off-by: Wei Liu 
> > > > ---
> > > >  tools/xl/Makefile |   2 +-
> > > >  tools/xl/xl_cd.c  | 114 
> > > > ++
> > > 
> > > Would you mind calling this `libxl_cdrom.c' rather than `_cd' ?
> > > The latter makes me think of chdir...
> > 
> > Can I have your ack if I rename it to libxl_cdrom.c?
> 
> Yes, indeed, that was the only reason I didn't ack it.

Thanks.  I want to avoid reposting as much as possible because this
series is really long and tedious.

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

Re: [Xen-devel] [PATCH 20/29] xl: split out cd related code

[Ian Jackson]

Wei Liu writes ("Re: [PATCH 20/29] xl: split out cd related code"):
> On Mon, Feb 27, 2017 at 03:56:21PM +, Ian Jackson wrote:
> > Wei Liu writes ("[PATCH 20/29] xl: split out cd related code"):
> > > Signed-off-by: Wei Liu 
> > > ---
> > >  tools/xl/Makefile |   2 +-
> > >  tools/xl/xl_cd.c  | 114 
> > > ++
> > 
> > Would you mind calling this `libxl_cdrom.c' rather than `_cd' ?
> > The latter makes me think of chdir...
> 
> Can I have your ack if I rename it to libxl_cdrom.c?

Yes, indeed, that was the only reason I didn't ack it.

Thanks,
Ian.

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

Re: [Xen-devel] [PATCH] libs/devicemodel: free xencall handle in error path in _open()

[Ian Jackson]

Wei Liu writes ("[PATCH] libs/devicemodel: free xencall handle in error path in 
_open()"):
> Change the allocation to use calloc to get zeroed structure. Free
> xencall handler in error path.
> 
> Spotted by Coverity.

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH RESEND RFC 1/8] mm: Separate free page chunk merging into its own routine

[Dario Faggioli]

On Sun, 2017-02-26 at 19:37 -0500, Boris Ostrovsky wrote:
> This is needed for subsequent changes to memory scrubbing.
> 
So, this is "just" code motion and factorization, right?

If yes, I think the changelog should say so.

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)

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

Re: [Xen-devel] [PATCH RESEND RFC 0/8] Memory scrubbing from idle loop

[Andrew Cooper]

On 27/02/17 00:37, Boris Ostrovsky wrote:
> (Resending with corrected Tim's address, sorry)
>
> When a domain is destroyed the hypervisor must scrub domain's pages before
> giving them to another guest in order to prevent leaking the deceased
> guest's data. Currently this is done during guest's destruction, possibly
> causing very lengthy cleanup process.

Thanks for getting around to posting these.

As a general set of notes across the series,

s/bool_t/bool/
More careful use of unsigned long, 1u << order
[0].  =>  >

There are also a few tabs vs spaces issues.

> This series adds support for scrubbing released pages from idle loop,
> making guest destruction significantly faster. For example, destroying a
> 1TB guest can now be completed in slightly over 1 minute as opposed to
> about 9 minutes using existing scrubbing algorithm.

What is this 1m now?  I'd have thought that freeing memory would become
an O(1) splice from the domain pagelist onto the to-be-scrubbed list,
although I see that isn't quite how you have implemented it.

As a couple of other thoughts, how about getting rid of the boot time
explicit scrub by initialising the entire heap as needing scrubbing? 
That way, scrubbing will start happening as soon as the APs hit their
idle loops, rather than later in one explicit action once dom0 is
constructed.

How about marking pages as needing scrubbing at the end of alloc(),
rather than in free() ?  That way you don't need to walk the pagelists
just to set the pending_scrub flag.

> The downside of this series is that we sometimes fail to allocate high-order
> sets of pages since dirty pages may not yet be merged into higher-order sets
> while they are waiting to be scrubbed.

I presume there is no sensible way to try and prioritise the pages which
would have greatest effect for recreating higher-order sets?

>
> Briefly, the new algorithm places dirty pages at the end of heap's page list
> for each node/zone/order to avoid having to scan full list while searching
> for dirty pages. One processor form each node checks whether the node has any
> dirty pages and, if such pages are found, scrubs them. Scrubbing itself
> happens without holding heap lock so other users may access heap in the
> meantime. If while idle loop is scrubbing a particular chunk of pages this
> chunk is requested by the heap allocator, scrubbing is immediately stopped.

Why not maintain two lists?  That way it is O(1) to find either a clean
or dirty free page.

>
> On the allocation side, alloc_heap_pages() first tries to satisfy allocation
> request using only clean pages. If this is not possible, the search is
> repeated and dirty pages are scrubbed by the allocator.
>
> This series needs to be fixed up for ARM and may have a few optimizations
> added (and possibly some cleanup). I also need to decide what to do about
> nodes without processors.
>
> I originally intended to add per-node heap locks

Is this why scrubbing is limited to a single processor per node?  What
kind of performance impact does this give?

> and AVX-based scrubbing but decided that this should be done separately.

I agree that optimising our copying/zeroing routines should be orthogonal.

~Andrew

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

Re: [Xen-devel] [PATCH 20/29] xl: split out cd related code

[Wei Liu]

On Mon, Feb 27, 2017 at 03:56:21PM +, Ian Jackson wrote:
> Wei Liu writes ("[PATCH 20/29] xl: split out cd related code"):
> > Signed-off-by: Wei Liu 
> > ---
> >  tools/xl/Makefile |   2 +-
> >  tools/xl/xl_cd.c  | 114 
> > ++
> 
> Would you mind calling this `libxl_cdrom.c' rather than `_cd' ?
> The latter makes me think of chdir...

Can I have your ack if I rename it to libxl_cdrom.c?

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

Re: [Xen-devel] [PATCH 19/29] xl: split out vcpu related code

[Ian Jackson]

Wei Liu writes ("[PATCH 19/29] xl: split out vcpu related code"):
> Signed-off-by: Wei Liu 

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH 15/29] xl: split out network related code

[Ian Jackson]

Wei Liu writes ("[PATCH 15/29] xl: split out network related code"):
> Signed-off-by: Wei Liu 

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH 12/29] xl: split out flask related code

[Ian Jackson]

Wei Liu writes ("[PATCH 12/29] xl: split out flask related code"):
> Signed-off-by: Wei Liu 

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH 18/29] xl: split out pci related code

[Ian Jackson]

Wei Liu writes ("[PATCH 18/29] xl: split out pci related code"):
> Signed-off-by: Wei Liu 

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH 27/29] xl: split out save/restore related code

[Ian Jackson]

Wei Liu writes ("[PATCH 27/29] xl: split out save/restore related code"):
> Add some function declarations to xl.h because they are now needed in
> multiple files.

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH 21/29] xl: split out memory related code

[Ian Jackson]

Wei Liu writes ("[PATCH 21/29] xl: split out memory related code"):
> Signed-off-by: Wei Liu 

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH 23/29] xl: split out functions to print out information

[Ian Jackson]

Wei Liu writes ("[PATCH 23/29] xl: split out functions to print out 
information"):
> Signed-off-by: Wei Liu 

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH 26/29] xl: split out vm lifecycle control functions

[Ian Jackson]

Wei Liu writes ("[PATCH 26/29] xl: split out vm lifecycle control functions"):
> Including create, reboot, shutdown, pause, unpause and destroy.
> 
> Lift a bunch of core data structures and function declarations to xl.h
> because they are needed in both xl_cmdimpl.c and xl_vmcontrol.c.

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH 16/29] xl: split out usb related code

[Ian Jackson]

Wei Liu writes ("[PATCH 16/29] xl: split out usb related code"):
> Signed-off-by: Wei Liu 

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH 11/29] xl: split out cpupool related code

[Ian Jackson]

Wei Liu writes ("[PATCH 11/29] xl: split out cpupool related code"):
> Signed-off-by: Wei Liu 

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH 28/29] xl: split out migration related code

[Ian Jackson]

Wei Liu writes ("[PATCH 28/29] xl: split out migration related code"):
> Include COLO / Remus code because they are built on top of the existing
> migration protocol.

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH 24/29] xl: split out vnc and console related code

[Ian Jackson]

Wei Liu writes ("[PATCH 24/29] xl: split out vnc and console related code"):
> The new file also contains code for channel, which is just a console
> in disguise.
> 
> Replace the call to vncviewer() with libxl_vncviewer_exec() directly in
> main_vncviewer.

Again, please separate out the non-code-motion change.

Thanks,
Ian.

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

Re: [Xen-devel] [PATCH 29/29] xl: merge xl_cmdimpl.c into xl.c

[Ian Jackson]

Wei Liu writes ("[PATCH 29/29] xl: merge xl_cmdimpl.c into xl.c"):
> After splitting out all the meaty bits, xl_cmdimpl.c doesn't contain
> much. Merge the rest into xl.c and delete the file.

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH 25/29] xl: split out miscellaneous functions

[Ian Jackson]

Wei Liu writes ("[PATCH 25/29] xl: split out miscellaneous functions"):
> A collections of functions that don't warrant their own files.
> 
> Moving main_devd there requires lifting do_daemonize to xl_utils.c.

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH 14/29] xl: split out block related code

[Ian Jackson]

Wei Liu writes ("[PATCH 14/29] xl: split out block related code"):
> Signed-off-by: Wei Liu 

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH 17/29] xl: split out scheduler related code

[Ian Jackson]

Wei Liu writes ("[PATCH 17/29] xl: split out scheduler related code"):
> Signed-off-by: Wei Liu 

Acked-by: Ian Jackson 

BTW, for all of these code motion patches: it would be nice if the
comment said `code motion only, apart from the obvious Makefile
change' or something.

Ian.

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

Re: [Xen-devel] [PATCH 10/29] xl: split out xl_parse.[ch]

[Ian Jackson]

Wei Liu writes ("[PATCH 10/29] xl: split out xl_parse.[ch]"):
> Some notable changes other than code movement:
> 1. rename cpurange_parse to parse_cpurange;
> 2. provide a function to return shutdown action name.

Can you split that out so that I can review it separately from the
code motion ?

Thanks,
Ian.

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

Re: [Xen-devel] [PATCH 20/29] xl: split out cd related code

[Ian Jackson]

Wei Liu writes ("[PATCH 20/29] xl: split out cd related code"):
> Signed-off-by: Wei Liu 
> ---
>  tools/xl/Makefile |   2 +-
>  tools/xl/xl_cd.c  | 114 
> ++

Would you mind calling this `libxl_cdrom.c' rather than `_cd' ?
The latter makes me think of chdir...

Thanks,
Ian.


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

Re: [Xen-devel] [PATCH 22/29] xl: split out psr related code

[Ian Jackson]

Wei Liu writes ("[PATCH 22/29] xl: split out psr related code"):
> Signed-off-by: Wei Liu 

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH 13/29] xl: split out vtpm related code

[Ian Jackson]

Wei Liu writes ("[PATCH 13/29] xl: split out vtpm related code"):
> Signed-off-by: Wei Liu 

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH 07/29] xl: lift a bunch of macros to xl_utils.h

[Ian Jackson]

Wei Liu writes ("[PATCH 07/29] xl: lift a bunch of macros to xl_utils.h"):
> We're going to split xl_cmdimpl.c into multiple files. Lift the commonly
> used macros to xl_utils.h.

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH 09/29] xl: split out tmem related code to xl_tmem.c

[Ian Jackson]

Wei Liu writes ("[PATCH 09/29] xl: split out tmem related code to xl_tmem.c"):
> Signed-off-by: Wei Liu 

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH 06/29] xl: remove trailing spaces in xl_cmdimpl.c

[Ian Jackson]

Wei Liu writes ("[PATCH 06/29] xl: remove trailing spaces in xl_cmdimpl.c"):
> Signed-off-by: Wei Liu 

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH 02/29] xl: update copyright information

[Ian Jackson]

Wei Liu writes ("[PATCH 02/29] xl: update copyright information"):
> Signed-off-by: Wei Liu 

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH 04/29] xl: use <> variant to include Xen tools library headers

[Ian Jackson]

Wei Liu writes ("[PATCH 04/29] xl: use <> variant to include Xen tools library 
headers"):
> They should be treated like any other libraries installed on the build
> host. Compiler options are set correctly to point to their locations.

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH 01/29] xl: remove accidentally committed hunk from Makefile

[Ian Jackson]

Wei Liu writes ("[PATCH 01/29] xl: remove accidentally committed hunk from 
Makefile"):
> It was never intended to be committed. Lucky the high level Makefile was
> correct so it didn't cause us problem when building xl.

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH 03/29] xl: remove inclusion of libxl_osdeps.h

[Ian Jackson]

Wei Liu writes ("[PATCH 03/29] xl: remove inclusion of libxl_osdeps.h"):
> There is no reason for a client to include a private header from libxl.
> Remove the inclusion and define _GNU_SOURCE for {v,}asprintf in
> xl_cmdimpl.c.

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH 05/29] xl: generate _paths.h

[Ian Jackson]

Wei Liu writes ("[PATCH 05/29] xl: generate _paths.h"):
> It is included by xl.h. Previously it was using _paths.h from some other
> place. We'd better generate one for xl as well.

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH 08/29] xl: move some helper functions to xl_utils.c

[Ian Jackson]

Wei Liu writes ("[PATCH 08/29] xl: move some helper functions to xl_utils.c"):
> Move some commonly used functions to a new file. Prepend "x" to
> function names to stick to consistent naming scheme.

The `xfoo' naming scheme is a reference to `xmalloc' et al, which
conventionally crash the program on failure.

I don't think you need to add this to every function in xl.  It is
applicable only when there is an existing function which returns an
error code, which is wrapped by one which never fails.

Thanks,
Ian.

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

Re: [Xen-devel] [PATCH RESEND RFC 2/8] mm: Place unscrubbed pages at the end of pagelist

[Boris Ostrovsky]

>>  
>>  static void merge_chunks(struct page_info *pg, unsigned int node,
>> - unsigned int zone, unsigned int order)
>> + unsigned int zone, unsigned int order,
>> + bool_t need_scrub)
> Can't you calculate need_scrub from *pg rather than passing an extra
> parameter?

Right, I can just look at the head's PGC_need_scrub bit.

>>  {
>>  ASSERT(spin_is_locked(_lock));
>>  
>> @@ -970,12 +982,49 @@ static void merge_chunks(struct page_info *pg, 
>> unsigned int node,
>>  }
>>  
>>  PFN_ORDER(pg) = order;
>> -page_list_add_tail(pg, (node, zone, order));
>> +if ( need_scrub )
>> +page_list_add_tail(pg, (node, zone, order));
>> +else
>> +page_list_add(pg, (node, zone, order));
>> +}
>> +
>> +static void scrub_free_pages(unsigned int node)
>> +{
>> +struct page_info *pg;
>> +unsigned int i, zone;
>> +int order;
>> +
>> +ASSERT(spin_is_locked(_lock));
>> +
>> +if ( !node_need_scrub[node] )
>> +return;
>> +
>> +for ( zone = 0; zone < NR_ZONES; zone++ )
>> +{
>> +for ( order = MAX_ORDER; order >= 0; order-- )
>> +{
>> +while ( !page_list_empty((node, zone, order)) )
>> +{
>> +/* Unscrubbed pages are always at the end of the list. */
>> +pg = page_list_last((node, zone, order));
>> +if ( !test_bit(_PGC_need_scrub, [0].count_info) )
> >count_info
>
>> +break;
>> +
>> +for ( i = 0; i < (1 << order); i++)
> 1U, and probably unsigned long.  Similarly later.

I'll update sizing throughout the series.

I just noticed, BTW, that this routine lost something like

   page_list_del(pg, (node, zone, order));
   merge_chunks(pg, node, zone, chunk_order, 0);

otherwise we just scrub the last chunk on each list.

This is all rewritten in a later patch which is why I missed this during
testing.

-boris




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

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

[osstest service owner]

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

Regressions :-(

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

version targeted for testing:
 ovmf 29c90f14c91bf134a202c1b4ed600c9766bc1411
baseline version:
 ovmf e0307a7dad02aa8c0cd8b3b0b9edce8ddb3fef2e

Last test of basis   105963  2017-02-21 21:43:31 Z5 days
Failing since105980  2017-02-22 10:03:53 Z5 days   12 attempts
Testing same since   106187  2017-02-27 06:33:44 Z0 days1 attempts


People who touched revisions under test:
  Anthony PERARD 
  Ard Biesheuvel 
  Jeff Fan 
  Jiewen Yao 
  Laszlo Ersek 
  Paolo Bonzini 
  Star Zeng 
  Yonghong Zhu 
  Zhang Lubo 

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



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

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

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

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


Not pushing.

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

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

Re: [Xen-devel] [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

[Michal Hocko]

On Mon 27-02-17 12:25:10, Heiko Carstens wrote:
> On Mon, Feb 27, 2017 at 11:02:09AM +0100, Vitaly Kuznetsov wrote:
> > A couple of other thoughts:
> > 1) Having all newly added memory online ASAP is probably what people
> > want for all virtual machines.
> 
> This is not true for s390. On s390 we have "standby" memory that a guest
> sees and potentially may use if it sets it online. Every guest that sets
> memory offline contributes to the hypervisor's standby memory pool, while
> onlining standby memory takes memory away from the standby pool.
> 
> The use-case is that a system administrator in advance knows the maximum
> size a guest will ever have and also defines how much memory should be used
> at boot time. The difference is standby memory.
> 
> Auto-onlining of standby memory is the last thing we want.
> 
> > Unfortunately, we have additional complexity with memory zones
> > (ZONE_NORMAL, ZONE_MOVABLE) and in some cases manual intervention is
> > required. Especially, when further unplug is expected.
> 
> This also is a reason why auto-onlining doesn't seem be the best way.

Can you imagine any situation when somebody actually might want to have
this knob enabled? From what I understand it doesn't seem to be the
case.

-- 
Michal Hocko
SUSE Labs

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

Re: [Xen-devel] [PATCH RESEND RFC 2/8] mm: Place unscrubbed pages at the end of pagelist

[Andrew Cooper]

On 27/02/17 00:37, Boris Ostrovsky wrote:
> . so that it's easy to find pages that need to be scrubbed (those pages are
> now marked with _PGC_need_scrub bit).
>
> Signed-off-by: Boris Ostrovsky 
> ---
>  xen/common/page_alloc.c  |   97 +++--
>  xen/include/asm-x86/mm.h |4 ++
>  2 files changed, 79 insertions(+), 22 deletions(-)
>
> diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
> index 352eba9..653bb91 100644
> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -385,6 +385,8 @@ typedef struct page_list_head 
> heap_by_zone_and_order_t[NR_ZONES][MAX_ORDER+1];
>  static heap_by_zone_and_order_t *_heap[MAX_NUMNODES];
>  #define heap(node, zone, order) ((*_heap[node])[zone][order])
>  
> +static unsigned node_need_scrub[MAX_NUMNODES];

This will overflow if there is 16TB of ourstanding memory needing
scrubbed per node.

In the worst case, all available patches could be oustanding for
scrubbing, so should be counted using the same types.

> +
>  static unsigned long *avail[MAX_NUMNODES];
>  static long total_avail_pages;
>  
> @@ -935,11 +942,16 @@ static bool_t can_merge(struct page_info *head, 
> unsigned int node,
>(phys_to_nid(page_to_maddr(head)) != node) )
>  return 0;
>  
> +if ( !!need_scrub ^
> + !!test_bit(_PGC_need_scrub, >count_info) )
> +return 0;
> +
>  return 1;
>  }
>  
>  static void merge_chunks(struct page_info *pg, unsigned int node,
> - unsigned int zone, unsigned int order)
> + unsigned int zone, unsigned int order,
> + bool_t need_scrub)

Can't you calculate need_scrub from *pg rather than passing an extra
parameter?

>  {
>  ASSERT(spin_is_locked(_lock));
>  
> @@ -970,12 +982,49 @@ static void merge_chunks(struct page_info *pg, unsigned 
> int node,
>  }
>  
>  PFN_ORDER(pg) = order;
> -page_list_add_tail(pg, (node, zone, order));
> +if ( need_scrub )
> +page_list_add_tail(pg, (node, zone, order));
> +else
> +page_list_add(pg, (node, zone, order));
> +}
> +
> +static void scrub_free_pages(unsigned int node)
> +{
> +struct page_info *pg;
> +unsigned int i, zone;
> +int order;
> +
> +ASSERT(spin_is_locked(_lock));
> +
> +if ( !node_need_scrub[node] )
> +return;
> +
> +for ( zone = 0; zone < NR_ZONES; zone++ )
> +{
> +for ( order = MAX_ORDER; order >= 0; order-- )
> +{
> +while ( !page_list_empty((node, zone, order)) )
> +{
> +/* Unscrubbed pages are always at the end of the list. */
> +pg = page_list_last((node, zone, order));
> +if ( !test_bit(_PGC_need_scrub, [0].count_info) )

>count_info

> +break;
> +
> +for ( i = 0; i < (1 << order); i++)

1U, and probably unsigned long.  Similarly later.

~Andrew

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

Re: [Xen-devel] RFC/PATCH: xen: race during domain destruction [Re: [xen-4.7-testing test] 105948: regressions - FAIL]

[Dario Faggioli]

On Sun, 2017-02-26 at 16:53 +0100, Dario Faggioli wrote:
> On Fri, 2017-02-24 at 17:14 +0100, Dario Faggioli wrote:
> > On Wed, 2017-02-22 at 01:46 -0700, Jan Beulich wrote:
> > > 
> > > However, comparing with the staging version of the file
> > > (which is heavily different), the immediate code involved here
> > > isn't
> > > all that different, so I wonder whether (a) this is a problem on
> > > staging too or (b) we're missing another backport. Dario?
> > > 
> > So, according to my investigation, this is a genuine race. It
> > affects
> > this branch as well as staging, but it manifests less frequently
> > (or,
> > I
> > should say, very rarely) in the latter.
> > 
> Actually, this is probably wrong. It looks like the following commit:
> 
>  f3d47501db2b7bb8dfd6a3c9710b7aff4b1fc55b
>  xen: fix a (latent) cpupool-related race during domain destroy
> 
> is not in staging-4.7.
> 
And my testing confirms that backporting the changeset above (which
just applies cleanly on staging-4.7, AFAICT) make the problem go away.

As the changelog of that commit says, I've even seen something similar
happening already during my development... Sorry I did not recognise it
sooner, and for failing to request backport of that change in the first
place.

I'm therefore doing that now: I ask for backport of:

 f3d47501db2b7bb8dfd6a3c9710b7aff4b1fc55b
 xen: fix a (latent) cpupool-related race during domain destroy

to 4.7.

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)

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

Re: [Xen-devel] [PATCH RESEND RFC 1/8] mm: Separate free page chunk merging into its own routine

[Andrew Cooper]

On 27/02/17 00:37, Boris Ostrovsky wrote:
> +static void merge_chunks(struct page_info *pg, unsigned int node,
> + unsigned int zone, unsigned int order)
> +{
> +ASSERT(spin_is_locked(_lock));
> +
> +/* Merge chunks as far as possible. */
> +while ( order < MAX_ORDER )
> +{
> +unsigned int mask = 1UL << order;

This was unsigned long before.  If order is guaranteed never to be
larger than 31, we are ok.  If not, it needs correctly.

~Andrew

>  /* Free 2^@order set of pages. */
>  static void free_heap_pages(
>  struct page_info *pg, unsigned int order)
>  {
> -unsigned long mask, mfn = page_to_mfn(pg);
> +unsigned long mfn = page_to_mfn(pg);
>  unsigned int i, node = phys_to_nid(page_to_maddr(pg)), tainted = 0;
>  unsigned int zone = page_to_zone(pg);
>  
> @@ -977,38 +1024,7 @@ static void free_heap_pages(
>  midsize_alloc_zone_pages = max(
>  midsize_alloc_zone_pages, total_avail_pages / 
> MIDSIZE_ALLOC_FRAC);
>  
> -/* Merge chunks as far as possible. */
> -while ( order < MAX_ORDER )
> -{
> -mask = 1UL << order;
> -


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

Re: [Xen-devel] [RTDS Patch v2 for Xen4.8] xen: rtds: only tickle non-already tickled CPUs

[Dario Faggioli]

On Fri, 2017-02-24 at 15:54 -0600, Haoran Li wrote:
> From: naroahlee 
> 
> Bug Analysis:
>
Just kill this line above.

> When more than one idle VCPUs that have the same PCPU as their
> previous running core invoke runq_tickle(), they will tickle the same
> PCPU. The tickled PCPU will only pick at most one VCPU, i.e., the
> highest-priority one, to execute. The other VCPUs will not be
> scheduled for a period, even when there is an idle core, making these
> VCPUs unnecessarily starve for one period.
> Therefore, always make sure that we only tickle PCPUs that have not
> been tickled already.
>
And I'd say to wrap around the lines at a shorter threshold. `git log',
for instance, indents the changelogs, and the idea would be for them to
look good on 80 characters terminal.

> --- a/xen/common/sched_rt.c
> +++ b/xen/common/sched_rt.c
> @@ -1144,9 +1144,10 @@ rt_vcpu_sleep(const struct scheduler *ops,
> struct vcpu *vc)
>   * Called by wake() and context_saved()
>   * We have a running candidate here, the kick logic is:
>   * Among all the cpus that are within the cpu affinity
> - * 1) if the new->cpu is idle, kick it. This could benefit cache hit
> - * 2) if there are any idle vcpu, kick it.
> - * 3) now all pcpus are busy;
> + * 1) if there are any idle vcpu, kick it.
> + *For cache benefit, we first search new->cpu.
> + * 
> + * 2) now all pcpus are busy;
>
As Meng said, no blank line here.

>   *among all the running vcpus, pick lowest priority one
>   *if snext has higher priority, kick it.
>   *
> @@ -1174,17 +1175,11 @@ runq_tickle(const struct scheduler *ops,
> struct rt_vcpu *new)
>  cpumask_and(_tickled, online, new->vcpu->cpu_hard_affinity);
>  cpumask_andnot(_tickled, _tickled, >tickled);
>  
> -/* 1) if new's previous cpu is idle, kick it for cache benefit
> */
> -if ( is_idle_vcpu(curr_on_cpu(new->vcpu->processor)) )
> -{
> -SCHED_STAT_CRANK(tickled_idle_cpu);
> -cpu_to_tickle = new->vcpu->processor;
> -goto out;
> -}
> -
> -/* 2) if there are any idle pcpu, kick it */
> +/* 1) if there are any idle pcpu, kick it */
>
While there, do you mind adding a full stop at the end of the sentence?

>  /* The same loop also find the one with lowest priority */
> -for_each_cpu(cpu, _tickled)
> + /* For cache benefit, we search new->cpu first */
>
And this looks to me to be misindented.

If you fix these things and resend, you can add (together to Meng's
one):

Reviewed-by: Dario Faggioli 

And I'm Cc-ing George, so he can also adivse if he wants, as hee is
also a scheduler maintainer... not to mention that he will most likely
be the one that will commit the change, so please do Cc him yourself as
well when you resend the patch (I should have asked to do that before,
but did not notice he was not there).

Thanks and Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)

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

Re: [Xen-devel] [PATCH 10/10] x86/cpuid: Always enable faulting for the control domain

[Andrew Cooper]

On 22/02/17 10:10, Jan Beulich wrote:
 On 22.02.17 at 11:00,  wrote:
>> On 22/02/17 09:23, Jan Beulich wrote:
>> On 20.02.17 at 12:00,  wrote:
 The domain builder in libxc no longer depends on leaked CPUID information 
 to
 properly construct HVM domains.  Remove the control domain exclusion.
>>> Am I missing some intermediate step? As long as there's a raw
>>> CPUID invocation in xc_cpuid_x86.c (which is still there in staging
>>> and I don't recall this series removing it) it at least _feels_ unsafe.
>> Strictly speaking, the domain builder part of this was completed after
>> my xsave adjustments.  All the guest-type-dependent information now
>> comes from non-cpuid sources in libxc, or Xen ignores the toolstack
>> values and recalculates information itself.
>>
>> However, until the Intel leaves were complete, dom0 had a hard time
>> booting with this change as there were no toolstack-provided policy and
>> no leakage from hardware.
> So what are the CPUID uses in libxc then needed for at this point?
> Could they be removed in a prereq patch to make clear all needed
> information is now being obtained via hypercalls?

I'd prefer to defer that work.  The next chunk of CPUID work is going to
be redesigning and reimplementing the hypervisor/libxc interface, and
all cpuid() calls in libxc will fall out there, but its not a trivial
set of changes to make.

>
>>> Also the change here then results in Dom0 observing different
>>> behavior between faulting-capable and faulting-incapable hosts.
>>> I'm not convinced this is desirable.
>> I disagree.  Avoiding the leakage is very desirable moving forwards.
>>
>> Other side effects are that it makes PV and PVH dom0 functionally
>> identical WRT CPUID, and PV userspace (which, unlikely the kernel, tends
>> not to be Xen-aware) sees sensible information.
> I can see the upsides too, hence the "I'm not convinced" ...

So is that an ack or a nack?  I am afraid that this isn't very helpful.

~Andrew

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

Re: [Xen-devel] [PATCH 08/10] x86/cpuid: Handle leaf 0xb in guest_cpuid()

[Andrew Cooper]

On 22/02/17 10:37, Jan Beulich wrote:
 On 22.02.17 at 11:22,  wrote:
>> On 22/02/17 09:16, Jan Beulich wrote:
>> On 20.02.17 at 12:00,  wrote:
 Leaf 0xb is reserved by AMD, and uniformly hidden from guests by the 
>> toolstack
 logic and hypervisor PV logic.

 The previous dynamic logic filled in the x2APIC ID for all HVM guests.  
 This
 is modified to respect the entire leaf being reserved by AMD, but is 
 altered
 to include PV Intel guests, so they get more sensible values in their 
 emulated
 and faulted view of CPUID.
>>> Don't we expose x2APIC to HVM guests even on AMD systems? In
>>> which case we surely will want to also expose the x2APIC ID.
>> The x2apic feature bit is still listed as reserved in the latest AMD
>> SDM, and I haven't seen a piece of hardware which supports it.
> This doesn't seem to answer my question, as hardware behavior is
> of no interest here (our emulation works on old Intel hardware too).
> Just to be sure I've checked a HVM guest on an AMD box, and this
> is what Linux reports:
>
> <6>Enabling x2apic
> <6>Enabled x2apic
> <6>Switched APIC routing to physical x2apic.

Hmm - that is a good point - we do offer x2apic even to AMD HVM guests.

However, this is problematic and highlights another can of worms.  We
cannot turn on APICV/AVIC for guests if our cpuid features claim a
greater featureset than hardware can support.  (Looking at c/s
3e0c8272f, TSC_DEADLINE is a feature in a similar position.)

I think the only feasible way of making this work is to ensure that the
default policy exactly matches hardware, and the max policy contains all
features we are able to emulate.  Determination of whether to use
APICV/AVIC or not must be on whether the chosen featureset is compatible
with hardware or not.

>
>> Also, x2apic or not, this leaf is documented as fully reserved, so we
>> shouldn't be filling it in anyway.
> While guests appear to do fine without, I think this is inconsistent
> with providing x2APIC support. But as current behavior is the same,
> we can as well leave this for the future.
>
 @@ -959,6 +950,14 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
  }
  break;
  
 +case 0xb:
 +if ( p->x86_vendor == X86_VENDOR_INTEL )
 +{
 +/* Fix the x2APIC identifier. */
 +res->d = v->vcpu_id * 2;
 +}
 +break;
>>> Irrespective of the comment above, wouldn't the if() here better
>>> look at the x2APIC feature flag of the domain?
>> Perhaps.  There isn't a formal link called out, but looking at the
>> content, I am guessing that real hardware is consistent with their
>> support of x2apic and the availability of this leaf?
> I suppose so, at least they've got introduced together iirc.

Ok.  I will change the determination to be based exclusively on x2apic
being advertised, and leave a comment explaining why.

~Andrew

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

Re: [Xen-devel] [RFC PATCH v1 02/21] x86: NUMA: Refactor NUMA code

[Jan Beulich]

>>> Vijay Kilari  02/27/17 12:43 PM >>>
>On Thu, Feb 9, 2017 at 9:41 PM, Jan Beulich  wrote:
> On 09.02.17 at 16:56,  wrote:
>>> +struct node_data node_data[MAX_NUMNODES];
>>> +
>>> +/* Mapping from pdx to node id */
>>> +int memnode_shift;
>>> +unsigned long memnodemapsize;
>>> +u8 *memnodemap;
>>> +typeof(*memnodemap) _memnodemap[64];
>>
>> Careful with removing any "static" please. For the last one in
>> particular you would need to change the name if it's really necessary
>> to make non-static. Even better would be though to keep it static
>> and provide suitable accessors.
>>
>> Also please sanitize types as you're moving stuff: memnode_shift
>> looks like it really wants to be unsigned int, and u8 should really
>> be uint8_t (as we're trying to phase out u8 & Co). This also applies
>> to code further down.
>
>You mean to change all occurrences of
>s/u8/uint8_t
>s/u32/uint32_t
>s/u64/uint64_t

Yes.

>Also, I see that xen/arch/x86/srat.c coding style is not adhere to xen
>coding style.
>Shall I clean up before I move the code?

If you want to take the time - sure. All I'd like to ask for is that at least 
the
file(s) you move the code _to_ end up with consistent style.

Jan


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

Re: [Xen-devel] [PATCH 06/10] x86/cpuid: Handle leaf 0x6 in guest_cpuid()

[Andrew Cooper]

On 22/02/17 09:26, Jan Beulich wrote:
 On 22.02.17 at 10:12,  wrote:
>> On 22/02/17 08:23, Andrew Cooper wrote:
>>> On 22/02/17 07:31, Jan Beulich wrote:
>>> On 21.02.17 at 18:40,  wrote:
> On 21/02/17 17:25, Jan Beulich wrote:
> On 20.02.17 at 12:00,  wrote:
>>> The PV MSR handling logic as minimal support for some thermal/perf 
>>> operations
>>> from the hardware domain, so leak through the implemented subset of 
>>> features.
>> Does it make sense to continue to special case PV hwdom here?
> Being able to play with these MSRs will be actively wrong for HVM
> context.  It is already fairly wrong for PV context, as nothing prevents
> you being rescheduled across pcpus while in the middle of a read/write
> cycle on the MSRs.
 So the MSRs in question are, afaics
 - MSR_IA32_MPERF, MSR_IA32_APERF, MSR_IA32_PERF_CTL (all
   of which are is_cpufreq_controller() dependent)
 - MSR_IA32_THERM_CONTROL, MSR_IA32_ENERGY_PERF_BIAS
   (both of which are is_pinned_vcpu() dependent)
 For the latter your argument doesn't apply. For the former, I've
 been wondering for a while whether we shouldn't do away with
 "cpufreq=dom0-kernel".
>>> Hmm.  All good points.  If I can get away without leaking any of this,
>>> that would be ideal.  (Lets see what Linux thinks of such a setup.)
>> Linux seems fine without any of this leakage.
> But is that for a broad range of versions, or just the one you had
> to hand?

3.10 and 4.4 PVOps.  Looking at the 2.6.32-classic source, I can't see
anything which would be a problem.

~Andrew

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

[Xen-devel] [xen-unstable-smoke test] 106199: tolerable trouble: broken/fail/pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   5 xen-buildfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  3564f9e400c417fc3d47b732f474019c494434f9
baseline version:
 xen  d6e9f8d4f35d938417f9dc2ea50f6e8004e26725

Last test of basis   106196  2017-02-27 11:02:16 Z0 days
Testing same since   106199  2017-02-27 13:01:37 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Haozhong Zhang 
  Juergen Gross 
  Tim Deegan 
  Wei Liu 

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=3564f9e400c417fc3d47b732f474019c494434f9
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
3564f9e400c417fc3d47b732f474019c494434f9
+ branch=xen-unstable-smoke
+ revision=3564f9e400c417fc3d47b732f474019c494434f9
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.8-testing
+ '[' x3564f9e400c417fc3d47b732f474019c494434f9 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : 

Re: [Xen-devel] xen/arm: Hiding SMMUs from Dom0 when using ACPI on Xen

[Julien Grall]

On 27/02/17 13:23, Vijay Kilari wrote:

Hi Julien,


Hello Vijay,


On Wed, Feb 22, 2017 at 7:40 PM, Julien Grall  wrote:

Hello,

There was few discussions recently about hiding SMMUs from DOM0 when using
ACPI. I thought it would be good to have a separate thread for this.

When using ACPI, the SMMUs will be described in the IO Remapping Table
(IORT). The specification can be found on the ARM website [1].

For a brief summary, the IORT can be used to discover the SMMUs present on
the platform and find for a given device the ID to configure components such
as ITS (DeviceID) and SMMU (StreamID).

The appendix A in the specification gives an example how DeviceID and
StreamID can be found. For instance, when a PCI device is both protected by
an SMMU and MSI-capable the following translation will happen:
RID -> StreamID -> DeviceID

Currently, SMMUs are hidden from DOM0 because they are been used by Xen and
we don't support stage-1 SMMU. If we pass the IORT as it is, DOM0 will try
to initialize SMMU and crash.

I first thought about using a Xen specific way (STAO) or extending a flag in
IORT. But that is not ideal.

So we would have to rewrite the IORT for DOM0. Given that a range of RID can
mapped to multiple ranges of DeviceID, we would have to translate RID one by
one to find the associated DeviceID. I think this may end up to complex code
and have a big IORT table.


Why can't we replace Output base of IORT of PCI node with SMMU output base?.
I mean similar to PCI node without SMMU, why can't replace output base
of PCI node with
SMMU's output base?.


Because I don't see anything in the spec preventing one RC ID mapping to 
produce multiple SMMU ID mapping. So which output base would you use?




The issue I see is RID is [15:0] where is DeviceID is [17:0].



However, given that DeviceID will be used by DOM0 to only configure the ITS.
We have no need to use to have the DOM0 DeviceID equal to the host DeviceID.
So I think we could simplify our life by generating DeviceID for each RID
range.


If DOM0 DeviceID != host Device ID, then we cannot initialize ITS using DOM0
ITS commands (MAPD). So, is it concluded that ITS initializes all the devices
with platform specific Device ID's in Xen?.


Initializing ITS using DOM0 ITS command is a workaround until we get PCI 
passthrough done. It would still be possible to implement that with 
vDeviceID != pDeviceID as Xen would likely have the mapping between the 
2 DeviceID.


Cheers,

--
Julien Grall

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

[Xen-devel] [PATCH 5/7] x86/shadow: Use the pagewalk reserved bits helpers

[Andrew Cooper]

The shadow logic should never create a shadow of a guest PTE which contains
reserved bits from the guests point of view.  Such a shadowed entry might not
cause #PF[RSVD] when walked by hardware, thus won't behave architecturally
from the guests point of view.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Tim Deegan 
CC: George Dunlap 
---
 xen/arch/x86/mm/shadow/multi.c | 21 ++---
 1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index 7c6b017..702835b 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -2157,7 +2157,8 @@ static int validate_gl4e(struct vcpu *v, void *new_ge, 
mfn_t sl4mfn, void *se)
 
 perfc_incr(shadow_validate_gl4e_calls);
 
-if ( guest_l4e_get_flags(new_gl4e) & _PAGE_PRESENT )
+if ( (guest_l4e_get_flags(new_gl4e) & _PAGE_PRESENT) &&
+ !guest_l4e_rsvd_bits(v, new_gl4e) )
 {
 gfn_t gl3gfn = guest_l4e_get_gfn(new_gl4e);
 mfn_t gl3mfn = get_gfn_query_unlocked(d, gfn_x(gl3gfn), );
@@ -2215,7 +2216,8 @@ static int validate_gl3e(struct vcpu *v, void *new_ge, 
mfn_t sl3mfn, void *se)
 
 perfc_incr(shadow_validate_gl3e_calls);
 
-if ( guest_l3e_get_flags(new_gl3e) & _PAGE_PRESENT )
+if ( (guest_l3e_get_flags(new_gl3e) & _PAGE_PRESENT) &&
+ !guest_l3e_rsvd_bits(v, new_gl3e) )
 {
 gfn_t gl2gfn = guest_l3e_get_gfn(new_gl3e);
 mfn_t gl2mfn = get_gfn_query_unlocked(d, gfn_x(gl2gfn), );
@@ -2248,7 +2250,8 @@ static int validate_gl2e(struct vcpu *v, void *new_ge, 
mfn_t sl2mfn, void *se)
 
 perfc_incr(shadow_validate_gl2e_calls);
 
-if ( guest_l2e_get_flags(new_gl2e) & _PAGE_PRESENT )
+if ( (guest_l2e_get_flags(new_gl2e) & _PAGE_PRESENT) &&
+ !guest_l2e_rsvd_bits(v, new_gl2e) )
 {
 gfn_t gl1gfn = guest_l2e_get_gfn(new_gl2e);
 if ( guest_supports_superpages(v) &&
@@ -2288,8 +2291,7 @@ static int validate_gl1e(struct vcpu *v, void *new_ge, 
mfn_t sl1mfn, void *se)
 shadow_l1e_t new_sl1e;
 guest_l1e_t new_gl1e = *(guest_l1e_t *)new_ge;
 shadow_l1e_t *sl1p = se;
-gfn_t gfn;
-mfn_t gmfn;
+mfn_t gmfn = INVALID_MFN;
 p2m_type_t p2mt;
 int result = 0;
 #if (SHADOW_OPTIMIZATIONS & SHOPT_OUT_OF_SYNC)
@@ -2298,8 +2300,13 @@ static int validate_gl1e(struct vcpu *v, void *new_ge, 
mfn_t sl1mfn, void *se)
 
 perfc_incr(shadow_validate_gl1e_calls);
 
-gfn = guest_l1e_get_gfn(new_gl1e);
-gmfn = get_gfn_query_unlocked(d, gfn_x(gfn), );
+if ( (guest_l1e_get_flags(new_gl1e) & _PAGE_PRESENT) &&
+ !guest_l1e_rsvd_bits(v, new_gl1e) )
+{
+gfn_t gfn = guest_l1e_get_gfn(new_gl1e);
+
+gmfn = get_gfn_query_unlocked(d, gfn_x(gfn), );
+}
 
 l1e_propagate_from_guest(v, new_gl1e, gmfn, _sl1e, ft_prefetch, p2mt);
 result |= shadow_set_l1e(d, sl1p, new_sl1e, p2mt, sl1mfn);
-- 
2.1.4


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

[Xen-devel] [PATCH 7/7] x86/pagewalk: Re-implement the pagetable walker

[Andrew Cooper]

The existing pagetable walker has complicated return semantics, which squeeze
multiple pieces of information into single integer.  This would be fine if the
information didn't overlap, but it does.

Specifically, _PAGE_INVALID_BITS for 3-level guests alias _PAGE_PAGED and
_PAGE_SHARED.  A guest which constructs a PTE with bits 52 or 53 set (the
start of the upper software-available range) will create a virtual address
which, when walked by Xen, tricks Xen into believing the frame is paged or
shared.  This behaviour was introduced by XSA-173 (c/s 8b17648).

It is also complicated to turn rc back into a normal pagefault error code.
Instead, change the calling semantics to return a boolean indicating success,
and have the function accumulate a real pagefault error code as it goes
(including synthetic error codes, which do not alias hardware ones).  This
requires an equivalent adjustment to map_domain_gfn().

Issues fixed:
 * 2-level PSE36 superpages now return the correct translation.
 * 2-level L2 superpages without CR0.PSE now return the correct translation.
 * SMEP now inhibits a user instruction fetch even if NX isn't active.
 * Supervisor writes without CR0.WP now set the leaf dirty bit.
 * L4e._PAGE_GLOBAL is strictly reserved on AMD.
 * 3-level l3 entries have all reserved bits checked.
 * 3-level entries can no longer alias Xen's idea of paged or shared.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Tim Deegan 
CC: George Dunlap 
---
 xen/arch/x86/mm/guest_walk.c  | 448 +++---
 xen/arch/x86/mm/hap/guest_walk.c  |  21 +-
 xen/arch/x86/mm/hap/nested_ept.c  |   2 +-
 xen/arch/x86/mm/p2m.c |  17 +-
 xen/arch/x86/mm/shadow/multi.c|  27 +--
 xen/include/asm-x86/guest_pt.h|  63 --
 xen/include/asm-x86/p2m.h |   2 +-
 xen/include/asm-x86/page.h|   3 -
 xen/include/asm-x86/processor.h   |   2 +
 xen/include/asm-x86/x86_64/page.h |   6 -
 10 files changed, 303 insertions(+), 288 deletions(-)

diff --git a/xen/arch/x86/mm/guest_walk.c b/xen/arch/x86/mm/guest_walk.c
index 4f8d0e3..01bcb1d 100644
--- a/xen/arch/x86/mm/guest_walk.c
+++ b/xen/arch/x86/mm/guest_walk.c
@@ -32,44 +32,6 @@ asm(".file \"" __OBJECT_FILE__ "\"");
 #include 
 #include 
 
-extern const uint32_t gw_page_flags[];
-#if GUEST_PAGING_LEVELS == CONFIG_PAGING_LEVELS
-const uint32_t gw_page_flags[] = {
-/* I/F -  Usr Wr */
-/* 0   0   0   0 */ _PAGE_PRESENT,
-/* 0   0   0   1 */ _PAGE_PRESENT|_PAGE_RW,
-/* 0   0   1   0 */ _PAGE_PRESENT|_PAGE_USER,
-/* 0   0   1   1 */ _PAGE_PRESENT|_PAGE_RW|_PAGE_USER,
-/* 0   1   0   0 */ _PAGE_PRESENT,
-/* 0   1   0   1 */ _PAGE_PRESENT|_PAGE_RW,
-/* 0   1   1   0 */ _PAGE_PRESENT|_PAGE_USER,
-/* 0   1   1   1 */ _PAGE_PRESENT|_PAGE_RW|_PAGE_USER,
-/* 1   0   0   0 */ _PAGE_PRESENT|_PAGE_NX_BIT,
-/* 1   0   0   1 */ _PAGE_PRESENT|_PAGE_RW|_PAGE_NX_BIT,
-/* 1   0   1   0 */ _PAGE_PRESENT|_PAGE_USER|_PAGE_NX_BIT,
-/* 1   0   1   1 */ _PAGE_PRESENT|_PAGE_RW|_PAGE_USER|_PAGE_NX_BIT,
-/* 1   1   0   0 */ _PAGE_PRESENT|_PAGE_NX_BIT,
-/* 1   1   0   1 */ _PAGE_PRESENT|_PAGE_RW|_PAGE_NX_BIT,
-/* 1   1   1   0 */ _PAGE_PRESENT|_PAGE_USER|_PAGE_NX_BIT,
-/* 1   1   1   1 */ _PAGE_PRESENT|_PAGE_RW|_PAGE_USER|_PAGE_NX_BIT,
-};
-#endif
-
-/* Flags that are needed in a pagetable entry, with the sense of NX inverted */
-static uint32_t mandatory_flags(struct vcpu *v, uint32_t pfec) 
-{
-/* Don't demand not-NX if the CPU wouldn't enforce it. */
-if ( !guest_supports_nx(v) )
-pfec &= ~PFEC_insn_fetch;
-
-/* Don't demand R/W if the CPU wouldn't enforce it. */
-if ( is_hvm_vcpu(v) && unlikely(!hvm_wp_enabled(v)) 
- && !(pfec & PFEC_user_mode) )
-pfec &= ~PFEC_write_access;
-
-return gw_page_flags[(pfec & 0x1f) >> 1] | _PAGE_INVALID_BITS;
-}
-
 /* Modify a guest pagetable entry to set the Accessed and Dirty bits.
  * Returns non-zero if it actually writes to guest memory. */
 static uint32_t set_ad_bits(void *guest_p, void *walk_p, int set_dirty)
@@ -90,62 +52,33 @@ static uint32_t set_ad_bits(void *guest_p, void *walk_p, 
int set_dirty)
 return 0;
 }
 
-#if GUEST_PAGING_LEVELS >= 4
-static bool_t pkey_fault(struct vcpu *vcpu, uint32_t pfec,
-uint32_t pte_flags, uint32_t pte_pkey)
-{
-uint32_t pkru;
-
-/* When page isn't present,  PKEY isn't checked. */
-if ( !(pfec & PFEC_page_present) || is_pv_vcpu(vcpu) )
-return 0;
-
-/*
- * PKU:  additional mechanism by which the paging controls
- * access to user-mode addresses based on the value in the
- * PKRU register. A fault is considered as a PKU violation if all
- * of the following conditions are true:
- * 1.CR4_PKE=1.
- * 2.EFER_LMA=1.
- * 3.Page is present with no reserved bit violations.
- * 4.The access is not an instruction fetch.
- 

[Xen-devel] [PATCH 1/7] x86/hvm: Correctly identify implicit supervisor accesses

[Andrew Cooper]

All actions which refer to the active ldt/gdt/idt or task register
(e.g. loading a new segment selector) are known as implicit supervisor
accesses, even when the access originates from user code.

The distinction is necessary in the pagewalk when SMAP is enabled.  Refer to
Intel SDM Vol 3 "Access Rights" for the exact details.

Introduce a new pagewalk input, and make use of the new system segment
references in hvmemul_{read,write}().  While modifying those areas, move the
calculation of the appropriate pagewalk input before its first use.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Paul Durrant 
CC: George Dunlap 
CC: Tim Deegan 
---
 xen/arch/x86/hvm/emulate.c  | 18 ++
 xen/arch/x86/mm/guest_walk.c|  4 
 xen/include/asm-x86/processor.h |  1 +
 3 files changed, 15 insertions(+), 8 deletions(-)

diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index f24d289..9b32bca 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -783,6 +783,11 @@ static int __hvmemul_read(
 struct hvm_vcpu_io *vio = >arch.hvm_vcpu.hvm_io;
 int rc;
 
+if ( is_x86_system_segment(seg) )
+pfec |= PFEC_implicit;
+else if ( hvmemul_ctxt->seg_reg[x86_seg_ss].attr.fields.dpl == 3 )
+pfec |= PFEC_user_mode;
+
 rc = hvmemul_virtual_to_linear(
 seg, offset, bytes, , access_type, hvmemul_ctxt, );
 if ( rc != X86EMUL_OKAY || !bytes )
@@ -793,10 +798,6 @@ static int __hvmemul_read(
  (vio->mmio_gla == (addr & PAGE_MASK)) )
 return hvmemul_linear_mmio_read(addr, bytes, p_data, pfec, 
hvmemul_ctxt, 1);
 
-if ( (seg != x86_seg_none) &&
- (hvmemul_ctxt->seg_reg[x86_seg_ss].attr.fields.dpl == 3) )
-pfec |= PFEC_user_mode;
-
 rc = ((access_type == hvm_access_insn_fetch) ?
   hvm_fetch_from_guest_linear(p_data, addr, bytes, pfec, ) :
   hvm_copy_from_guest_linear(p_data, addr, bytes, pfec, ));
@@ -893,6 +894,11 @@ static int hvmemul_write(
 struct hvm_vcpu_io *vio = >arch.hvm_vcpu.hvm_io;
 int rc;
 
+if ( is_x86_system_segment(seg) )
+pfec |= PFEC_implicit;
+else if ( hvmemul_ctxt->seg_reg[x86_seg_ss].attr.fields.dpl == 3 )
+pfec |= PFEC_user_mode;
+
 rc = hvmemul_virtual_to_linear(
 seg, offset, bytes, , hvm_access_write, hvmemul_ctxt, );
 if ( rc != X86EMUL_OKAY || !bytes )
@@ -902,10 +908,6 @@ static int hvmemul_write(
  (vio->mmio_gla == (addr & PAGE_MASK)) )
 return hvmemul_linear_mmio_write(addr, bytes, p_data, pfec, 
hvmemul_ctxt, 1);
 
-if ( (seg != x86_seg_none) &&
- (hvmemul_ctxt->seg_reg[x86_seg_ss].attr.fields.dpl == 3) )
-pfec |= PFEC_user_mode;
-
 rc = hvm_copy_to_guest_linear(addr, p_data, bytes, pfec, );
 
 switch ( rc )
diff --git a/xen/arch/x86/mm/guest_walk.c b/xen/arch/x86/mm/guest_walk.c
index faaf70c..4f8d0e3 100644
--- a/xen/arch/x86/mm/guest_walk.c
+++ b/xen/arch/x86/mm/guest_walk.c
@@ -161,6 +161,10 @@ guest_walk_tables(struct vcpu *v, struct p2m_domain *p2m,
 bool_t pse1G = 0, pse2M = 0;
 p2m_query_t qt = P2M_ALLOC | P2M_UNSHARE;
 
+/* Only implicit supervisor data accesses exist. */
+ASSERT(!(pfec & PFEC_implicit) ||
+   !(pfec & (PFEC_insn_fetch|PFEC_user_mode)));
+
 perfc_incr(guest_walk);
 memset(gw, 0, sizeof(*gw));
 gw->va = va;
diff --git a/xen/include/asm-x86/processor.h b/xen/include/asm-x86/processor.h
index dda8b83..d3ba8ea 100644
--- a/xen/include/asm-x86/processor.h
+++ b/xen/include/asm-x86/processor.h
@@ -76,6 +76,7 @@
 /* Internally used only flags. */
 #define PFEC_page_paged (1U<<16)
 #define PFEC_page_shared(1U<<17)
+#define PFEC_implicit   (1U<<18) /* Pagewalk input for ldt/gdt/idt/tr 
accesses. */
 
 /* Other exception error code values. */
 #define X86_XEC_EXT (_AC(1,U) << 0)
-- 
2.1.4


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

[Xen-devel] [PATCH 3/7] x86/pagewalk: Helpers for reserved bit handling

[Andrew Cooper]

Some bits are unconditionally reserved in pagetable entries, or reserved
because of alignment restrictions.  Other bits are reserved because of control
register configuration.

Introduce helpers which take an individual vcpu and guest pagetable entry, and
calculates whether any reserved bits are set.

While here, add a couple of newlines to aid readability, drop some trailing
whitespace and bool/const correct the existing helpers to allow the new
helpers to take const vcpu pointers.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: George Dunlap 
CC: Tim Deegan 
---
 xen/include/asm-x86/guest_pt.h | 98 ++
 1 file changed, 90 insertions(+), 8 deletions(-)

diff --git a/xen/include/asm-x86/guest_pt.h b/xen/include/asm-x86/guest_pt.h
index 0bf6cf9..1c3d384 100644
--- a/xen/include/asm-x86/guest_pt.h
+++ b/xen/include/asm-x86/guest_pt.h
@@ -44,6 +44,18 @@ gfn_to_paddr(gfn_t gfn)
 #undef get_gfn
 #define get_gfn(d, g, t) get_gfn_type((d), gfn_x(g), (t), P2M_ALLOC)
 
+/* Mask covering the reserved bits from superpage alignment. */
+#define SUPERPAGE_RSVD(bit) \
+(((1ULL << (bit)) - 1) & ~(_PAGE_PSE_PAT | (_PAGE_PSE_PAT - 1)))
+
+static inline uint32_t fold_pse36(uint64_t val)
+{
+return (val & ~(0x1ffULL << 13)) | ((val & (0x1ffULL << 32)) >> (32 - 13));
+}
+static inline uint64_t unfold_pse36(uint32_t val)
+{
+return (val & ~(0x1ffULL << 13)) | ((val & (0x1ffULL << 13)) << (32 - 13));
+}
 
 /* Types of the guest's page tables and access functions for them */
 
@@ -51,9 +63,13 @@ gfn_to_paddr(gfn_t gfn)
 
 #define GUEST_L1_PAGETABLE_ENTRIES 1024
 #define GUEST_L2_PAGETABLE_ENTRIES 1024
+
 #define GUEST_L1_PAGETABLE_SHIFT 12
 #define GUEST_L2_PAGETABLE_SHIFT 22
 
+#define GUEST_L1_PAGETABLE_RSVD   0
+#define GUEST_L2_PAGETABLE_RSVD   0
+
 typedef uint32_t guest_intpte_t;
 typedef struct { guest_intpte_t l1; } guest_l1e_t;
 typedef struct { guest_intpte_t l2; } guest_l2e_t;
@@ -88,21 +104,39 @@ static inline guest_l2e_t guest_l2e_from_gfn(gfn_t gfn, 
u32 flags)
 #else /* GUEST_PAGING_LEVELS != 2 */
 
 #if GUEST_PAGING_LEVELS == 3
+
 #define GUEST_L1_PAGETABLE_ENTRIES  512
 #define GUEST_L2_PAGETABLE_ENTRIES  512
 #define GUEST_L3_PAGETABLE_ENTRIES4
+
 #define GUEST_L1_PAGETABLE_SHIFT 12
 #define GUEST_L2_PAGETABLE_SHIFT 21
 #define GUEST_L3_PAGETABLE_SHIFT 30
+
+#define GUEST_L1_PAGETABLE_RSVD0x7ff0UL
+#define GUEST_L2_PAGETABLE_RSVD0x7ff0UL
+#define GUEST_L3_PAGETABLE_RSVD  \
+(0xfff0UL | _PAGE_GLOBAL | _PAGE_PSE | _PAGE_DIRTY | \
+ _PAGE_ACCESSED | _PAGE_USER | _PAGE_RW)
+
 #else /* GUEST_PAGING_LEVELS == 4 */
+
 #define GUEST_L1_PAGETABLE_ENTRIES  512
 #define GUEST_L2_PAGETABLE_ENTRIES  512
 #define GUEST_L3_PAGETABLE_ENTRIES  512
 #define GUEST_L4_PAGETABLE_ENTRIES  512
+
 #define GUEST_L1_PAGETABLE_SHIFT 12
 #define GUEST_L2_PAGETABLE_SHIFT 21
 #define GUEST_L3_PAGETABLE_SHIFT 30
 #define GUEST_L4_PAGETABLE_SHIFT 39
+
+#define GUEST_L1_PAGETABLE_RSVD0
+#define GUEST_L2_PAGETABLE_RSVD0
+#define GUEST_L3_PAGETABLE_RSVD0
+/* NB L4e._PAGE_GLOBAL is reserved for AMD, but ignored for Intel. */
+#define GUEST_L4_PAGETABLE_RSVD_PAGE_PSE
+
 #endif
 
 typedef l1_pgentry_t guest_l1e_t;
@@ -170,27 +204,30 @@ static inline guest_l4e_t guest_l4e_from_gfn(gfn_t gfn, 
u32 flags)
 
 /* Which pagetable features are supported on this vcpu? */
 
-static inline int
-guest_supports_superpages(struct vcpu *v)
+static inline bool guest_supports_superpages(const struct vcpu *v)
 {
 /* The _PAGE_PSE bit must be honoured in HVM guests, whenever
- * CR4.PSE is set or the guest is in PAE or long mode. 
+ * CR4.PSE is set or the guest is in PAE or long mode.
  * It's also used in the dummy PT for vcpus with CR4.PG cleared. */
 return (is_pv_vcpu(v)
 ? opt_allow_superpage
-: (GUEST_PAGING_LEVELS != 2 
+: (GUEST_PAGING_LEVELS != 2
|| !hvm_paging_enabled(v)
|| (v->arch.hvm_vcpu.guest_cr[4] & X86_CR4_PSE)));
 }
 
-static inline int
-guest_supports_1G_superpages(struct vcpu *v)
+static inline bool guest_has_pse36(const struct vcpu *v)
+{
+ /* No support for 2-level PV guests. */
+return is_pv_vcpu(v) ? 0 : paging_mode_hap(v->domain);
+}
+
+static inline bool guest_supports_1G_superpages(const struct vcpu *v)
 {
 return (GUEST_PAGING_LEVELS >= 4 && hvm_pse1gb_supported(v->domain));
 }
 
-static inline int
-guest_supports_nx(struct vcpu *v)
+static inline bool guest_supports_nx(const struct vcpu *v)
 {
 if ( GUEST_PAGING_LEVELS == 2 || !cpu_has_nx )
 return 0;
@@ -213,6 

[Xen-devel] [PATCH 6/7] x86/pagewalk: Consistently use guest_walk_*() helpers for translation

[Andrew Cooper]

hap_p2m_ga_to_gfn() and sh_page_fault() currently use guest_l1e_get_gfn() to
obtain the translation of a pagewalk.  This is conceptually wrong (the
semantics of gw.l1e is an internal detail), and will actually be wrong when
PSE36 superpage support is fixed.  Switch them to using guest_walk_to_gfn().

Take the opportunity to const-correct the walk_t parameter of the
guest_walk_to_*() helpers, and implement guest_walk_to_gpa() in terms of
guest_walk_to_gfn() to avoid duplicating the actual translation calculation.

While editing guest_walk_to_gpa(), fix a latent bug by causing it to return
INVALID_PADDR rather than 0 for a failed translation, as 0 is also a valid
successful result.  The sole caller, sh_page_fault(), has already confirmed
that the translation is valid, so this doesn't cause a behavioural change.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Tim Deegan 
CC: George Dunlap 
---
 xen/arch/x86/mm/hap/guest_walk.c |  2 +-
 xen/arch/x86/mm/shadow/multi.c   |  2 +-
 xen/include/asm-x86/guest_pt.h   | 19 +--
 3 files changed, 11 insertions(+), 12 deletions(-)

diff --git a/xen/arch/x86/mm/hap/guest_walk.c b/xen/arch/x86/mm/hap/guest_walk.c
index 569a495..313f82f 100644
--- a/xen/arch/x86/mm/hap/guest_walk.c
+++ b/xen/arch/x86/mm/hap/guest_walk.c
@@ -98,7 +98,7 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PAGING_LEVELS)(
 /* Interpret the answer */
 if ( missing == 0 )
 {
-gfn_t gfn = guest_l1e_get_gfn(gw.l1e);
+gfn_t gfn = guest_walk_to_gfn();
 struct page_info *page;
 page = get_page_from_gfn_p2m(p2m->domain, p2m, gfn_x(gfn), ,
  NULL, P2M_ALLOC | P2M_UNSHARE);
diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index 702835b..f73b553 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -3109,7 +3109,7 @@ static int sh_page_fault(struct vcpu *v,
 }
 
 /* What mfn is the guest trying to access? */
-gfn = guest_l1e_get_gfn(gw.l1e);
+gfn = guest_walk_to_gfn();
 gmfn = get_gfn(d, gfn, );
 
 if ( shadow_mode_refcounts(d) &&
diff --git a/xen/include/asm-x86/guest_pt.h b/xen/include/asm-x86/guest_pt.h
index 1c3d384..1aa383f 100644
--- a/xen/include/asm-x86/guest_pt.h
+++ b/xen/include/asm-x86/guest_pt.h
@@ -323,8 +323,7 @@ struct guest_pagetable_walk
 
 /* Given a walk_t, translate the gw->va into the guest's notion of the
  * corresponding frame number. */
-static inline gfn_t
-guest_walk_to_gfn(walk_t *gw)
+static inline gfn_t guest_walk_to_gfn(const walk_t *gw)
 {
 if ( !(guest_l1e_get_flags(gw->l1e) & _PAGE_PRESENT) )
 return INVALID_GFN;
@@ -333,19 +332,19 @@ guest_walk_to_gfn(walk_t *gw)
 
 /* Given a walk_t, translate the gw->va into the guest's notion of the
  * corresponding physical address. */
-static inline paddr_t
-guest_walk_to_gpa(walk_t *gw)
+static inline paddr_t guest_walk_to_gpa(const walk_t *gw)
 {
-if ( !(guest_l1e_get_flags(gw->l1e) & _PAGE_PRESENT) )
-return 0;
-return ((paddr_t)gfn_x(guest_l1e_get_gfn(gw->l1e)) << PAGE_SHIFT) +
-   (gw->va & ~PAGE_MASK);
+gfn_t gfn = guest_walk_to_gfn(gw);
+
+if ( gfn_eq(gfn, INVALID_GFN) )
+return INVALID_PADDR;
+
+return (gfn_x(gfn) << PAGE_SHIFT) | (gw->va & ~PAGE_MASK);
 }
 
 /* Given a walk_t from a successful walk, return the page-order of the 
  * page or superpage that the virtual address is in. */
-static inline unsigned int 
-guest_walk_to_page_order(walk_t *gw)
+static inline unsigned int guest_walk_to_page_order(const walk_t *gw)
 {
 /* This is only valid for successful walks - otherwise the 
  * PSE bits might be invalid. */
-- 
2.1.4


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