[Xen-devel] [ovmf test] 106229: regressions - FAIL
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
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_EXAMPLE_RING_SIZE)
[Xen-devel] [ovmf test] 106217: regressions - FAIL
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
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 tianqing Yongbok Kim jobs: build-amd64-xsm pass build-arm64-xsm fail build-armhf-xsm pass build-i386-xsm
[Xen-devel] [linux-linus test] 106209: regressions - FAIL
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
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
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 te
[Xen-devel] [PATCH v4] xen/arm: warn if dom0_mem is not specified
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, &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
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 m
Re: [Xen-devel] [PATCH] xen/arm: warn if dom0_mem is not specified
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, &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
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
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
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 Yongbok Kim jobs: build-amd64-xsm pass build-arm64-xsm fail build-armhf-xsm
Re: [Xen-devel] [PATCH v3] ring.h: introduce macros to handle monodirectional rings with multiple req sizes
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; /* opa
[Xen-devel] [linux-next test] 106193: regressions - FAIL
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 test-amd64-amd64-qemu
Re: [Xen-devel] [linux-linus test] 106139: regressions - FAIL
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&m=148822413412388&w=2 -boris ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Crash w/ bios="ovmf"
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
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
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/gi
Re: [Xen-devel] [PATCH v2 06/10] xen: credit2: group the runq manipulating functions.
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&D 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
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 test-amd64-amd64-libvirt
Re: [Xen-devel] OVMF blows up at unless I use pci_platform=0
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
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
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.
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&D 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
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)
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
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]
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
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
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
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 core
[Xen-devel] [PATCH 1/3] xl: rename cpurange_parse to parse_cpurange
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, &vcpu_affinity_array[j]))
+if (parse_cpurange(buf, &vcpu_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, &vcpu_affinity_array[0]))
+if (parse_cpurange(buf, &vcpu_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", &buf, 0)) {
-if (cpurange_parse(buf, &cpumap))
+if (parse_cpurange(buf, &cpumap))
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], &cpumap))
+if (parse_cpurange(argv[optind], &cpumap))
goto out;
if (libxl_cpupool_qualifier_to_cpupoolid(ctx, pool, &poolid, NULL) ||
@@ -8012,7 +8012,7 @@ int main_cpupoolcpuremove(int argc, char **argv)
}
pool = argv[optind++];
-if (cpurange_parse(argv[optind], &cpumap))
+if (parse_cpurange(argv[optind], &cpumap))
goto out;
if (libxl_cpupool_qualifier_to_cpupoolid(ctx, pool, &poolid, 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
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, &nb);
-if (!channels)
-continue;
-for (i = 0; i < nb; ++i) {
-if (!libxl_device_channel_getinfo(ctx, domid, &channels[i],
-&channelinfo)) {
-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(&channelinfo);
-}
-libxl_device_channel_dispose(&channels[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 th
[Xen-devel] [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. 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
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
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, &domid);
-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(&s, 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 flush_stream(FILE *fh)
-{
-
Re: [Xen-devel] OVMF blows up at unless I use pci_platform=0
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
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
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
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
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
>> 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"
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
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
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
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
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
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
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()
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
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&D 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
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 &pg[0]. => &pg-> 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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]
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
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
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
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
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
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
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
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 01/29] xl: remove accidentally committed hunk from Makefile
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
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 04/29] xl: use <> variant to include Xen tools library headers
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 05/29] xl: generate _paths.h
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
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
>>
>> 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(&heap_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, &heap(node, zone, order));
>> +if ( need_scrub )
>> +page_list_add_tail(pg, &heap(node, zone, order));
>> +else
>> +page_list_add(pg, &heap(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(&heap_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(&heap(node, zone, order)) )
>> +{
>> +/* Unscrubbed pages are always at the end of the list. */
>> +pg = page_list_last(&heap(node, zone, order));
>> +if ( !test_bit(_PGC_need_scrub, &pg[0].count_info) )
> &pg->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, &heap(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
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
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
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, &head->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(&heap_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, &heap(node, zone, order));
> +if ( need_scrub )
> +page_list_add_tail(pg, &heap(node, zone, order));
> +else
> +page_list_add(pg, &heap(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(&heap_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(&heap(node, zone, order)) )
> +{
> +/* Unscrubbed pages are always at the end of the list. */
> +pg = page_list_last(&heap(node, zone, order));
> +if ( !test_bit(_PGC_need_scrub, &pg[0].count_info) )
&pg->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]
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&D 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
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(&heap_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
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, &prv->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&D 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
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()
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
>>> 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()
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
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
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:
Re: [Xen-devel] xen/arm: Hiding SMMUs from Dom0 when using ACPI on Xen
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
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), &p2mt);
@@ -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), &p2mt);
@@ -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), &p2mt);
+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), &p2mt);
+}
l1e_propagate_from_guest(v, new_gl1e, gmfn, &new_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
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.
- * 5.The access is to a user page.
- * 6.PKRU.AD=1 or
- * the access is a
[Xen-devel] [PATCH 1/7] x86/hvm: Correctly identify implicit supervisor accesses
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 = &curr->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, &reps, access_type, hvmemul_ctxt, &addr);
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, &pfinfo) :
hvm_copy_from_guest_linear(p_data, addr, bytes, pfec, &pfinfo));
@@ -893,6 +894,11 @@ static int hvmemul_write(
struct hvm_vcpu_io *vio = &curr->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, &reps, hvm_access_write, hvmemul_ctxt, &addr);
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, &pfinfo);
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
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 +250,51 @@ guest_supports_nx(struct vcpu *v)
#define _PAGE_INVALID_BITS _PAGE_INVALID_BIT
[Xen-devel] [PATCH 6/7] x86/pagewalk: Consistently use guest_walk_*() helpers for translation
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(&gw);
struct page_info *page;
page = get_page_from_gfn_p2m(p2m->domain, p2m, gfn_x(gfn), &p2mt,
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(&gw);
gmfn = get_gfn(d, gfn, &p2mt);
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
